Software Development Life Cycle and Methodologies
Domain 1 covers how software work is organized end to end: lifecycle phases, process models, and the agile frameworks you must match to project conditions. Questions usually give a scenario and ask which model fits, or test precise terminology for Scrum, XP and the V-model.
Lifecycle phases and their artifacts
- Planning/feasibility produces a business case and initial risk list.
- Requirements produce a specification, use cases and acceptance criteria.
- Design produces the architecture description, interface specs and data model.
- Implementation produces source code and unit tests.
- Testing produces test plans, defect reports and coverage evidence.
- Deployment and maintenance produce release notes and runbooks; maintenance typically consumes the largest share of lifetime cost.
Process models
Waterfall runs sequentially with phase gates, so change late in the cycle is expensive. The V-model mirrors each development phase with a verification or validation level: unit testing against detailed design, integration testing against architecture, system testing against requirements, acceptance testing against user needs. Incremental delivery ships functionality in slices; iterative development reworks and refines the same slice. Most real projects do both. Spiral is risk-driven: each loop covers objectives, risk analysis and prototyping, engineering, then planning. Scrum defines roles (Product Owner owns backlog value, Scrum Master removes impediments and coaches process, Developers self-organize), artifacts (Product Backlog, Sprint Backlog, Increment) and events (Sprint Planning, 15-minute Daily Scrum, Sprint Review of the increment, Retrospective on the process).
Worked example
Scenario: fixed-price contract, a regulator requires documented traceability from every requirement to test evidence, and the technology is well understood. Reasoning: requirement volatility is low and audit need is high, so choose the V-model with formal review gates, a requirement-to-test traceability matrix, and configuration baselines. Contrast with a scenario of unclear user needs and frequent market feedback, where iterative increments with short sprints and a re-prioritized backlog fit better. State the differentiator explicitly: volatility of requirements multiplied by the cost of late change.
Traps that cost marks
- Claiming Scrum means no design or documentation; it means just enough, and regulated work still needs traceability.
- Confusing Sprint Review (inspect the product increment with stakeholders) with Retrospective (inspect the team process).
- Treating iterative and incremental as synonyms.
- Assuming the V-model forbids prototyping, or that Waterfall permits free backtracking.
- Choosing a model without justifying it against requirement volatility and risk.