Below are exam-oriented notes + 60 important MCQs covering Software Development Life Cycle (SDLC), Software Analysis, Design, Testing, and Project Management. These topics are particularly useful for Bihar STET Computer Science and other competitive exams.
1. Software Engineering
Software Engineering is the systematic, disciplined and measurable approach to the development, operation and maintenance of software.
Main objectives
- Develop quality software
- Reduce development cost
- Complete projects on time
- Make software maintainable
- Improve reliability
- Meet user requirements
Characteristics of good software
A good software system should be:
- Correct
- Reliable
- Efficient
- Maintainable
- Usable
- Secure
- Scalable
- Portable
2. Software Development Life Cycle (SDLC)
SDLC is a systematic process used to develop software from the initial idea/requirements through deployment and maintenance.
Major phases
- Planning / Feasibility
- Requirement Analysis
- System Design
- Implementation / Coding
- Testing
- Deployment
- Maintenance
SDLC Flow
Planning → Analysis → Design → Coding → Testing → Deployment → Maintenance
3. Planning and Feasibility Study
Before development begins, the organization determines whether the proposed system is feasible.
Types of feasibility
1. Technical Feasibility
Determines whether the required:
- Hardware
- Software
- Technology
- Technical expertise
are available.
2. Economic Feasibility
Determines whether the project is economically worthwhile.
It compares:
Expected benefits vs. Development costs
3. Operational Feasibility
Determines whether the proposed system can operate effectively within the organization.
4. Schedule Feasibility
Determines whether the project can be completed within the required time.
5. Legal Feasibility
Checks compliance with applicable laws, regulations and contractual requirements.
4. Requirement Analysis
Requirement analysis determines what the software should do.
Requirements are collected from:
- Customers
- End users
- Managers
- Domain experts
- Existing systems
- Documents
Requirement Engineering
The major activities include:
- Elicitation
- Analysis
- Specification
- Validation
- Management
5. Functional Requirements
Functional requirements describe what the system should do.
Examples:
- User can register.
- User can log in.
- System generates reports.
- Customer can place an order.
- Administrator can add users.
6. Non-Functional Requirements
Non-functional requirements describe how the system should perform or constraints on the system.
Examples:
- Performance
- Security
- Reliability
- Usability
- Scalability
- Availability
- Maintainability
Example
Functional: User can upload a file.
Non-functional: File upload must complete within 5 seconds.
7. SRS
SRS = Software Requirements Specification
It is a formal document describing software requirements.
An SRS generally contains:
- Functional requirements
- Non-functional requirements
- Interfaces
- Constraints
- Assumptions
- External requirements
Characteristics of a good SRS
It should be:
- Correct
- Complete
- Unambiguous
- Consistent
- Verifiable
- Modifiable
- Traceable
8. Software Design
Software design converts requirements into a blueprint for implementation.
Two important levels are:
High-Level Design (HLD)
Describes the overall system architecture.
Includes:
- Major modules
- Components
- Database architecture
- Interfaces
- System architecture
Low-Level Design (LLD)
Describes the detailed internal design of individual modules.
Includes:
- Algorithms
- Classes
- Functions
- Data structures
- Detailed interfaces
9. Modular Design
A complex software system is divided into smaller modules.
Advantages
- Easier development
- Easier testing
- Easier maintenance
- Better understanding
- Reusability
10. Cohesion
Cohesion measures how closely related the responsibilities of elements within a module are.
High cohesion is desirable.
A highly cohesive module performs closely related tasks.
Types of cohesion
From generally weaker to stronger:
- Coincidental
- Logical
- Temporal
- Procedural
- Communicational
- Sequential
- Functional
Functional cohesion is generally considered the strongest.
11. Coupling
Coupling measures the degree of dependency between modules.
Low coupling is desirable.
A system with low coupling is easier to:
- Modify
- Test
- Maintain
- Reuse
Important principle
High Cohesion + Low Coupling = Good Design
12. Architectural Design
Software architecture defines the overall organization of the system.
Common architectures include:
Layered Architecture
System is divided into layers.
Example:
Presentation → Business Logic → Data Access → Database
Client-Server Architecture
Clients request services from servers.
Three-Tier Architecture
- Presentation Layer
- Application/Business Logic Layer
- Data Layer
13. UML
UML = Unified Modeling Language
UML is used for visualizing, specifying and documenting software systems.
Important UML diagrams:
- Use Case Diagram
- Class Diagram
- Sequence Diagram
- Activity Diagram
- State Machine Diagram
- Component Diagram
- Deployment Diagram
14. Use Case Diagram
A use case diagram represents interactions between:
- Actors
- System
Actor
An actor is an external entity interacting with the system.
Example:
For an online banking system:
Customer → Login → Banking System
15. Class Diagram
A class diagram represents:
- Classes
- Attributes
- Methods
- Relationships
It is widely used in object-oriented design.
16. Sequence Diagram
A sequence diagram shows interactions between objects/components over time.
It focuses on the sequence of messages exchanged.
17. Software Development Models
Important SDLC models include:
- Waterfall Model
- Prototype Model
- Incremental Model
- Spiral Model
- V-Model
- Agile Model
18. Waterfall Model
The Waterfall model follows a largely sequential approach.
Typical flow:
Requirements → Design → Implementation → Testing → Deployment → Maintenance
Advantages
- Simple
- Easy to understand
- Well-defined phases
- Useful when requirements are stable
Disadvantages
- Difficult to accommodate changing requirements
- Testing occurs relatively late
- Customer feedback may come late
19. Prototype Model
A prototype is an early working model of the system.
Useful when:
- Requirements are unclear
- User needs are not fully understood
Basic process
Requirements → Prototype → User Feedback → Refinement → Final System
20. Spiral Model
The Spiral Model emphasizes:
Risk analysis
Each cycle generally includes:
- Planning
- Risk analysis
- Engineering
- Evaluation
It is suitable for large and high-risk projects.
21. V-Model
The V-Model emphasizes verification and validation.
A simplified representation:
Requirements ↔ Acceptance Testing
System Design ↔ System Testing
Architecture Design ↔ Integration Testing
Module Design ↔ Unit Testing
Coding is at the bottom of the V.
22. Agile Development
Agile development emphasizes:
- Iterative development
- Incremental delivery
- Customer collaboration
- Continuous feedback
- Responding to change
Instead of waiting until the entire product is finished, working software is delivered frequently.
23. Scrum
Scrum is a popular Agile framework.
Important roles:
- Product Owner
- Scrum Master
- Developers
Important concepts:
- Product Backlog
- Sprint
- Sprint Backlog
- Increment
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Sprint
A Sprint is a fixed development period during which a usable increment is produced.
24. Software Testing
Software testing is the process of evaluating software to identify defects and determine whether requirements are satisfied.
Objectives
- Find defects
- Verify requirements
- Validate behavior
- Improve quality
- Reduce risk
25. Verification vs Validation
Verification
"Are we building the product right?"
It checks whether software artifacts conform to specifications.
Examples:
- Reviews
- Inspections
- Walkthroughs
Validation
"Are we building the right product?"
It checks whether the final software meets user needs.
Examples:
- Testing the running software
- Acceptance testing
26. Levels of Testing
Four important testing levels are:
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
27. Unit Testing
Tests individual units/modules.
Usually performed by:
Developers
Example:
Testing a single login function.
28. Integration Testing
Tests interactions between integrated modules.
Example:
Testing whether:
Login Module ↔ User Database
works correctly.
29. System Testing
Tests the complete integrated system.
Usually evaluates the system against specified requirements.
30. Acceptance Testing
Determines whether the software is acceptable to the customer/user.
Common types:
- User Acceptance Testing (UAT)
- Alpha testing
- Beta testing
31. Black-Box Testing
Tester focuses on:
Input → Output
without requiring knowledge of internal implementation.
Techniques include:
- Equivalence partitioning
- Boundary value analysis
- Decision table testing
- State transition testing
32. White-Box Testing
Tester examines the internal logic/code structure.
Techniques include:
- Statement coverage
- Branch coverage
- Path coverage
- Condition coverage
33. Regression Testing
Regression testing checks whether recent changes have introduced defects into previously working functionality.
It is especially important after:
- Bug fixes
- Feature additions
- Code changes
34. Smoke Testing
Smoke testing is a preliminary test to determine whether a build is stable enough for more detailed testing.
It is often called:
Build Verification Testing
35. Sanity Testing
Sanity testing is focused testing performed after specific changes or fixes to verify that the affected functionality works correctly.
36. Alpha and Beta Testing
Alpha Testing
Usually performed in a controlled environment by the development organization or internal testers.
Beta Testing
Performed by selected external users/customers in a real or realistic environment.
37. Debugging
Testing identifies defects; debugging finds and fixes their causes.
Typical debugging process:
- Identify failure
- Locate defect
- Determine root cause
- Fix defect
- Retest
- Perform regression testing
38. Software Maintenance
After deployment, software requires maintenance.
Types:
Corrective Maintenance
Fixes discovered defects.
Adaptive Maintenance
Adapts software to changes in:
- Operating system
- Hardware
- Regulations
- External environment
Perfective Maintenance
Improves functionality or performance based on user needs.
Preventive Maintenance
Improves maintainability and reduces future problems.
39. Project Management
Software project management involves planning, organizing, monitoring and controlling software projects.
Major areas:
- Scope
- Schedule
- Cost
- Quality
- Resources
- Risk
- Communication
40. Project Scope
Scope defines:
- What is included
- What is excluded
- Project boundaries
- Deliverables
Scope creep occurs when project requirements expand without appropriate control.
41. Work Breakdown Structure (WBS)
WBS divides a project into smaller manageable tasks/work packages.
Example:
Website Project
→ Requirement Analysis
→ UI Design
→ Backend Development
→ Database
→ Testing
→ Deployment
42. Gantt Chart
A Gantt chart visually represents:
- Tasks
- Start dates
- End dates
- Duration
- Progress
It is commonly used for project scheduling.
43. PERT
PERT = Program Evaluation and Review Technique
PERT is useful when task duration estimates are uncertain.
Three estimates:
- Optimistic (O)
- Most Likely (M)
- Pessimistic (P)
Expected time:
TE = (O + 4M + P) / 6
44. Critical Path Method (CPM)
CPM identifies the critical path in a project.
The critical path determines the minimum project completion time.
Activities on the critical path generally have:
Zero total float/slack.
A delay in a critical-path activity can delay the entire project.
45. Risk Management
Risk management involves:
- Risk Identification
- Risk Analysis
- Risk Response/Planning
- Risk Monitoring
Common software risks
- Requirement changes
- Technology failure
- Schedule delays
- Budget overruns
- Staff turnover
- Security problems
46. Risk Exposure
A commonly used simplified formula is:
Risk Exposure = Probability × Impact
Example:
If probability = 0.2 and impact = ₹1,00,000:
Risk Exposure = 0.2 × 1,00,000 = ₹20,000
47. COCOMO
COCOMO = Constructive Cost Model
It is used for estimating software development effort, cost and schedule.
The model was developed by:
Barry Boehm
Basic COCOMO
Effort is commonly represented as:
Effort = a × (KLOC)^b
where:
KLOC = Thousand Lines of Code
48. Software Quality
Important software quality attributes include:
- Correctness
- Reliability
- Usability
- Efficiency
- Maintainability
- Portability
- Security
49. Important Formulas
PERT
TE = (O + 4M + P) / 6
Risk Exposure
RE = Probability × Impact
Basic COCOMO
Effort = a × (KLOC)^b
Bihar STET Most Important One-Liners
For quick revision, remember these:
- SDLC → Software Development Life Cycle
- SRS → Software Requirements Specification
- Functional requirement → What the system does
- Non-functional requirement → Quality/constraint of the system
- HLD → High-Level Design
- LLD → Low-Level Design
- Good design → High cohesion + Low coupling
- UML → Unified Modeling Language
- Use Case → Actors + System interactions
- Class Diagram → Classes, attributes, methods
- Sequence Diagram → Interaction over time
- Waterfall → Sequential model
- Spiral → Risk-oriented model
- Prototype → Useful when requirements are unclear
- V-Model → Verification + Validation
- Agile → Iterative + Incremental + adaptive
- Scrum → Agile framework
- Sprint → Fixed development iteration
- Unit Testing → Individual module
- Integration Testing → Interaction between modules
- System Testing → Complete system
- Acceptance Testing → Customer/user acceptance
- Black-box → No need to know internal code
- White-box → Internal code/logic
- Regression Testing → Checks impact of changes
- Smoke Testing → Basic build stability
- Debugging → Finds and fixes defect causes
- Verification → "Building the product right"
- Validation → "Building the right product"
- Corrective maintenance → Fix defects
- Adaptive maintenance → Environmental changes
- Perfective maintenance → Improve functionality/performance
- Preventive maintenance → Reduce future problems
- WBS → Work Breakdown Structure
- Gantt Chart → Project schedule
- PERT → Handles uncertain activity times
- CPM → Critical Path
- Critical path → Determines minimum project duration
- Risk Exposure → Probability × Impact
- COCOMO → Software cost/effort estimation
- KLOC → Thousand Lines of Code
