Software Life Cycle (SDLC) Models

 Waterfall Model
 V Model
 Agile / Iterative Model

Waterfall Model – Pros & Cons
Pros
 Simple and easy to use.
 Easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood
Cons
 Adjusting scope during the life cycle can kill a project
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Poor model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Poor model where requirements are at a moderate to high risk of changing
 Requirements change over time
 Maintenance not handled well

V-Model
 It emphasizes the significance of quality activities by defining several distinct
testing levels and illustrating how each level addresses a different stage of the
lifecycle
 V-Shaped life cycle is a sequential path of execution of processes

V-model - Stages
Business Case
 The first step in development is a business investigation followed by a "Business Case" produced by the
customer for a system.
Requirements
 The next broad step is to define a set of "Requirements", which is a statement by the customer of what the
system shall achieve in order to meet the need both functional and non-functional requirements. This is done
in collaboration with service providers Business Analysts.
System Specification - Check
 "Requirements" are then passed to developers, who produce a "System Specification".
 System specifications are compiled by Business Analysts, based on the Requirement captured during Fusion
workshops. This document has to be signed off by the customer.
System Design - Check
 Architects produce a "System Design" from the "System Specification".
Component Design
 Each component then has a "Component Design", which describes in detail exactly how it will perform its piece
of processing. This is also done by Senior developers and Architects.
Component Construction
 Based on Requirements and Design, the developers do their coding and Finally each component is built, and
then is ready for the test process.
Component Testing
 Starting from the bottom the first test level is "Component Testing", sometimes called Unit Testing. It involves
checking that each feature specified in the "Component Design" has been implemented in the component.
This is done by Developers.
Interface Testing
 As the components are constructed and tested they are then linked together to check if they work with each
other.
System Testing
 Once the entire system has been built then it has to be tested against the "System Specification" to check if
it delivers the features required.
Acceptance Testing
 Acceptance Testing checks the system against the "Requirements". This is done by the clients to confirm if
the system has been developed as per their expectations..
Release Testing
 Release Testing is about seeing if the new or changed system will work in the existing business
environment.
Regression Tests – Check
It seeks to uncover new software bugs in existing functional and non-functional areas of a system after
changes such as enhancements, patches or configuration changes, have been made to them.
One of the main reasons for regression testing is to determine whether a change in one part of the software
affects other parts of the software.
 It follows that all the above types of testing could be repeated at many levels in order to deliver the final
value to the business. In fact every time a system is altered.
V Model – Pros & Cons –
Pros
 Simple and easy to use.
 Each phase has specific deliverables.
 Higher chance of success over the waterfall model due to the development of test plans
early on during the life cycle.
 Works well for small projects where requirements are easily understood
Cons
 Very rigid, like the waterfall model.
 Little flexibility and adjusting scope is difficult and expensive.
 Software is developed during the implementation phase, so no early prototypes of the
software are produced.
 Model doesn’t provide a clear path for problems found during testing phases