Development Life Cycles: Models, Phases, and Testing
A development life cycle is the structured path from an idea to a maintained system. The exam tests whether you can name the phases, match a project situation to a suitable model, and place testing activities correctly. Questions often describe a project with fixed requirements, high risk, or changing user feedback, and ask which approach fits.
Core phases
- Planning and requirements gathering define scope, users, and constraints.
- Design covers architecture, data, interfaces, and security.
- Implementation is coding and configuration.
- Testing verifies and validates the result.
- Deployment releases it, and maintenance fixes, adapts, and improves it. Maintenance typically consumes the largest share of lifetime cost.
Models
- Waterfall runs phases sequentially with formal sign-off; it suits stable, well-understood requirements and regulated work.
- The V-model pairs each build stage with a matching test level and is common in safety-critical systems.
- Iterative and incremental models deliver in repeated cycles, adding features each pass.
- Spiral adds explicit risk analysis to each cycle and suits large, risky projects.
- Prototyping and RAD emphasize early user feedback and rapid delivery.
- Agile methods such as Scrum use short sprints, a prioritised backlog, daily stand-ups, and retrospectives; DevOps adds continuous integration and delivery.
Testing levels
- Unit testing checks individual components; integration testing checks interfaces between them.
- System testing checks the whole product against requirements; acceptance testing confirms the customer's needs.
- Verification asks whether the product was built correctly; validation asks whether the right product was built.
Worked example
A hospital needs a patient-records module with fixed regulatory requirements, extensive documentation, and hardware interfaces that must be specified before coding. Reasoning: requirements are stable and formal verification is required, so a plan-driven model with matched test stages, such as the V-model, fits best. An agile approach would still need heavy documentation and formal verification, undercutting its advantages. Conversely, a consumer app with uncertain features and frequent user feedback suits iterative or agile delivery, where working software and short feedback loops reduce the risk of building the wrong thing.
Traps that cost marks
- Claiming waterfall forbids all change; it permits change through formal change control, which is slow and costly.
- Placing acceptance testing before system testing, or treating verification and validation as synonyms.
- Assuming agile means no planning or documentation at all.
- Ignoring maintenance as a life-cycle phase and its share of total cost.