Week 17: Software Engineering & Project Management

1. SDLC Models

The Waterfall model runs requirements → design → implementation → testing → deployment → maintenance strictly in sequence, with no going back — simple to manage, but poorly suited to projects where requirements are likely to change. The Spiral model combines iterative development with explicit risk analysis at each cycle (making a fresh pass through planning, risk analysis, engineering and evaluation every loop) — well suited to large, high-risk projects. The Agile model (Scrum, XP) develops in short iterations ("sprints"), continuously incorporating customer feedback and welcoming changing requirements even late in development, at the cost of being harder to fix a firm cost/schedule upfront.

The V-model pairs each development phase with a corresponding testing phase (e.g. requirements pair with acceptance testing, design pairs with system testing), emphasising that testing planning starts early rather than only after coding. The Incremental model delivers the system in usable functional chunks (increments) rather than all at once.

Requirements clear, stable, unlikely to change     -> Waterfall
Large project, high risk, needs risk analysis loops -> Spiral
Requirements likely to evolve; customer wants early,
  frequent working software                          -> Agile
Testing must be planned alongside each dev phase     -> V-model
Want to deliver working subsets of the system early  -> Incremental

2. Requirements, Design & Testing

Verification asks "are we building the product right?" — checking that each phase's output correctly implements its input specification (reviews, walkthroughs, static analysis, done throughout development). Validation asks "are we building the right product?" — checking the finished product against actual user needs (typically via dynamic testing, at the end). This single distinction (right vs. correct, process vs. product) is one of the most repeated Software Engineering exam questions.

Black-box testing tests functionality against specifications with no knowledge of internal code structure (equivalence partitioning, boundary value analysis). White-box testing tests internal logic paths with full knowledge of the code (statement coverage, branch coverage, path coverage). Testing levels, smallest to largest scope: unit testing (a single function/module in isolation) → integration testing (interactions between combined modules) → system testing (the whole integrated system against requirements) → acceptance testing (validation by/for the actual customer, typically the final gate before release).

3. Software Project Management: Estimation, Risk & Quality

COCOMO (COnstructive COst MOdel) estimates development effort (person-months) from estimated lines of code or function points, in three modes of increasing complexity: organic (small, familiar, experienced team), semi-detached (medium size/complexity, mixed experience), and embedded (large, complex, tight constraints, e.g. real-time systems) — each mode uses different constants in the same underlying effort formula, reflecting how much harder effort scales with size as project complexity grows.

Software risk management follows: risk identification → risk analysis (assessing probability and impact) → risk planning (mitigation/contingency strategy) → risk monitoring (ongoing tracking as the project proceeds). Software quality is often summarised via McCall's or ISO 9126 quality models, covering attributes like reliability, usability, efficiency, maintainability and portability — the syllabus expects you to recognise these named attribute categories, since exam questions often give a quality complaint and ask which attribute it violates.

4. Hands-on Exercise

5. Exam-Style Practice (UGC NET Pattern)

Five NTA-pattern questions on SDLC models, testing and project management.