1
Software Life Cycle Models
The goal of Software Engineering is to provide
models and processes that lead to the
production of well-documented maintainable
software in a manner that is predictable.
2
Software Life Cycle Models
“The period of time that starts when a software product is conceived
and ends when the product is no longer available for use. The
software life cycle typically includes a requirement phase, design
phase, implementation phase, test phase, installation and check out
phase, operation and maintenance phase, and sometimes retirement
phase”.
3
Build & Fix
Model
❖ Product is constructed without
specifications or any attempt at
design
Build
❖ Adhoc approach and not
Code
well defined
❖ Simple two phase model Fix
4
Build & Fix
Model
❖ Suitable for small programming exercises of 100 or 200 lines
❖ Unsatisfactory for software for any reasonable size
❖ Code soon becomes unfixable & unenhanceable
❖ No room for structured design
❖ Maintenance is practically not possible
5
Waterfall Model
Requirement This model is named
Analysis & Specification
model” because its diagrammatic
“waterfall
representation resembles a cascade of
Design waterfalls.
Implementatio
n and unit
testing
Integr ation
and system
testing
Operation
and
maintenance
6
Waterfall Model
This model is easy to understand and reinforces
the notion of “define before design” and “design
before code”.
The model expects complete &
requirements accurate early process,
in the which is
unrealistic
7
Waterfall Model
Problems of waterfall model
i. It is difficult to define all requirements at the beginning of a
project
ii. This model is not suitable for accommodating any change
iii. A working version of the system is not seen until late in
the project’s life
iv. It does not scale up well to large projects.
v. Real projects are rarely sequential.
8
Iterative Models
• This model leads the software development process in
iterations.
• The software is first developed on very small scale
and all the steps are followed which are taken into
consideration.
• Then, on every next iteration, more features and
modules are designed, coded, tested, and added to the
software.
• Every cycle produces a software, which is complete
in itself and has more features and capabilities than
that of the previous one. 9
The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase,
requirements are gathered from customers and check by an
analyst whether requirements will fulfil or not. Analyst
checks that need will achieve within budget or not. After all
of this, the software team skips to the next phase.
2. Design: In the design phase, team design the software by the
different diagrams like Data Flow diagram, activity diagram,
class diagram, state transition diagram, etc.
3. Implementation: In the implementation, requirements are
written in the coding language and transformed into computer
programmes which are called Software.
10
4. Testing: After completing the coding phase, software testing
starts using different test methods. There are many test methods, but
the most common are white box, black box, and grey box test
methods.
5. Deployment: After completing all the phases, software is
deployed to its work environment.
6. Review: In this phase, after the product deployment, review
phase is performed to check the behaviour and validity of the
developed product. And if there are any error found then the process
starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the
software in the working environment there may be some bugs, some
errors or new updates are required. Maintenance involves
debugging and new addition options.
11
Advantage(Pros) of Iterative Model:
1.Testing and debugging during smaller iteration is easy.
2.A Parallel development can plan.
3.It is easily acceptable to ever-changing needs of the project.
4.Risks are identified and resolved during iteration.
5.Limited time spent on documentation and extra time on designing.
Disadvantage(Cons) of Iterative Model:
6.It is not suitable for smaller projects.
7.More Resources may be required.
8.Design can be changed again and again because of imperfect
requirements.
9.Requirement changes can cause over budget.
10.Project completion date not confirmed because of changing
requirements.
12
13
SDLC V-Model
Verification: It involves static analysis technique (review)
done without executing code. It is the process of
evaluation of the product development phase to find
whether specified requirements meet.
Validation: It involves dynamic analysis technique
(functional, non-functional), testing done by executing
code. Validation is the process to evaluate the software
after the completion of the development phase to
determine whether software meets the customer
expectations and requirements.
So V-Model contains Verification phases on one side of the
Validation phases on the other side. Verification and
Validation phases are joined by coding phase in V-shape.
Thus it is called V-Model.
14
V-MODEL
15
Design Phase:
•Requirement Analysis: This phase contains detailed
communication with the customer to understand their
requirements and expectations. This stage is known as
Requirement Gathering.
•System Design: This phase contains the system design
and the complete hardware and communication setup for
developing product.
•Architectural Design: System design is broken down
further into modules taking up different functionalities.
The data transfer and communication between the internal
modules and with the outside world (other systems) is
clearly understood.
•Module Design: In this phase the system breaks dowm
into small modules. The detailed design of modules is
specified, also known as Low-Level Design (LLD).
16
Testing Phases:
•Unit Testing: Unit Test Plans are developed during
module design phase. These Unit Test Plans are executed
to eliminate bugs at code or unit level.
•Integration testing: After completion of unit testing
Integration testing is performed. In integration testing, the
modules are integrated and the system is tested.
Integration testing is performed on the Architecture
design phase. This test verifies the communication of
modules among themselves.
•System Testing: System testing test the complete
application with its functionality, inter dependency, and
communication.It tests the functional and non-functional
requirements of the developed application.
•User Acceptance Testing (UAT): UAT is performed in a
user environment that resembles the production
environment. UAT verifies that the delivered system
meets user’s requirement and system is ready for use 17 in
real world.
Advantages of the V-Model
•This is a highly-disciplined model and Phases are completed
one at a time.
•Works well for smaller projects where requirements are very
well understood.
•Simple and easy to understand and use.
•Easy to manage due to the rigidity of the model. Each phase
has specific deliverables and a review process.
18
Disadvantages of the V-Model
•High risk and uncertainty.
•Not a good model for complex and object-oriented projects.
•Poor model for long and ongoing projects.
•Not suitable for the projects where requirements are at a
moderate to high risk of changing.
•Once an application is in the testing stage, it is difficult to go
back and change a functionality.
•No working software is produced until late during the life
cycle.
19
The Rapid Application Development (RAD)
Model
o Developed by IBM in 1980
o User participation is essential
o Build a rapid prototype
o Give it to user for evaluation & obtain feedback
o Prototype is refined
With active participation of users
Requirements User Construction Cut over
Planning Description
20
The Rapid Application Development (RAD)
Model
Not an appropriate model in the absence of
user participation.
Reusable components are required to reduce development
time.
Highly specialized & skilled developers are required and
such developers are not easily available.
21
Advantages of the RAD Model
•Changing requirements can be accommodated.
•Progress can be measured.
•Iteration time can be short with use of powerful RAD tools.
•Productivity with fewer people in a short time.
•Reduced development time.
•Increases reusability of components.
•Quick initial reviews occur.
•Encourages customer feedback.
•Integration from very beginning solves a lot of integration
issues.
22
Disadvantages of RAD Model
•Dependency on technically strong team members for
identifying business requirements.
•Only system that can be modularized can be built using
RAD.
•Requires highly skilled developers/designers.
•High dependency on Modelling skills.
•Inapplicable to cheaper projects as cost of Modelling and
automated code generation is very high.
•Management complexity is more.
•Suitable for systems that are component based and scalable.
•Requires user involvement throughout the life cycle.
•Suitable for project requiring shorter development times.
23
Evolutionary Process Models
Evolutionary process model resembles iterative enhancement
model. The same phases as defined for the waterfall model occur
here in a cyclical fashion. This model differs from iterative
enhancement model in the sense that this does not require a
useable product at the end of each cycle. In evolutionary
development, requirements are implemented by category rather
than by priority.
This model is useful for projects using new technology that is not
well understood. This is also used for complex projects where all
functionality must be delivered at one time, but the requirements
are unstable or not well understood at the beginning.
24
Evolutionary Process Model
Concurr en
t
activities
Initial
Specification
versio
n
Outline Intermediate
Developmen
descriptio versions
t
n
Final
Validation
versio
n
25
Advantages of
Evolutionary
•Large project: Model
Evolutionary model is normally
useful for very large products.
•User gets a chance to experiment with a
partially developed software much before the
complete version of the system is released.
•Evolutionary model helps to accurately elicit user
requirements during the delivery of different
versions of the software.
•The core modules get tested thoroughly,
thereby reducing the chances of errors in the core
modules of the final products.
•Evolutionary model avoids the need to commit
large resources in one go for development of the 26
system.
Disadvantages of
Evolutionary Model
•Difficult to divide the problem into several
versions that would be acceptable to the customer
and which can be incrementally implemented and
delivered.
27
Prototyping Model
➢ The prototype may be a usable program but is not suitable as
the final software product.
➢ The code for the prototype is thrown away. However
experience gathered helps in developing the actual system.
➢ The development of a prototype might involve extra cost, but
overall cost might turnout to be lower than that of an
equivalent system developed using the waterfall model.
28
Prototyping Model
• Linear model
• “Rapid”
29
Advantages –
•The customers get to see the partial product early
in the life cycle. This ensures a greater level of
customer satisfaction and comfort.
•New requirements can be easily accommodated as
there is scope for refinement.
•Missing functionalities can be easily figured out.
•Errors can be detected much earlier thereby
saving a lot of effort and cost, besides enhancing
the quality of the software.
•The developed prototype can be reused by the
developer for more complicated projects in the
future.
•Flexibility in design.
30
Disadvantages –
•Costly w.r.t time as well as money.
•There may be too much variation in requirements each
time the prototype is evaluated by the customer.
•Poor Documentation due to continuously changing
customer requirements.
•It is very difficult for the developers to accommodate all the
changes demanded by the customer.
•There is uncertainty in determining the number of
iterations that would be required before the prototype is
finally accepted by the customer.
•After seeing an early prototype, the customers sometimes
demand the actual product to be delivered soon.
•Developers in a hurry to build prototypes may end up with
sub-optimal solutions.
•The customer might lose interest in the product if he/she is
not satisfied with the initial prototype.
31
Spiral Model
Models do not deal with uncertainly which is inherent to software
projects.
Important software projects have failed because project risks were
neglected & nobody was prepared when something unforeseen
happened.
Barry Boehm recognized this and tired to incorporate the “project
risk” factor into a life cycle model.
The result is the spiral model, which was presented in 1986.
32
Spiral Model
33
Spiral Model
The radial dimension of the model represents the cumulative costs.
Each path around the spiral is indicative of increased costs. The
angular dimension represents the progress made in completing each
cycle. Each loop of the spiral from X-axis clockwise through 360o
represents one phase. One phase is split roughly into four sectors of
major activities.
▪ Planning: Determination of objectives,
alternatives & constraints.
▪ Risk Analysis: Analyze alternatives and attempts to
identify and resolve the risks involved.
▪ Development: Product development and testing product.
▪ Assessment: Customer evaluation
34
Spiral Model
▪ An important feature of the spiral model is that each phase is
completed with a review by the people concerned with the
project (designers and programmers)
▪ The advantage of this model is the wide range of options to
accommodate the good features of other life cycle models.
▪ It becomes equivalent to another life cycle
appropriate
model in situations.
The spiral model has some difficulties that need to be resolved
before it can be a universally applied life cycle model. These
difficulties include lack of explicit process guidance in determining
objectives, constraints, alternatives; relying on risk assessment
expertise; and provides more flexibility than required for many
applications.
35
