Chapter_2_Software_Development_Life_Cycle_and_Process_Models.pptx

Chapter 2 - Software
Development Life
Cycle Models
1
Software Engineering By Gadisa A.
3/4/2024

• A structured set of activities required to develop a
software system
• A software process (also knows as software methodology)
is a set of related activities that leads to the production of
the software.
• These activities may involve the development of the
software from the scratch, or, modifying an existing
system.
Softwareprocesses
2
3/4/2024

3
Software processes….Cont.
Any software process must include the following four activities:
1. Software specification (or requirements engineering):
Define the main functionalities of the software and the
constrains around them.
2. Software design and implementation: The software is to
be designed and programmed.
3. Software verification and validation: The software must
conforms to it’s specification and meets the customer
needs.
3/4/2024

4
Software processes….Cont.
4. Software evolution (software maintenance): The
software is being modified to meet customer and
market requirements changes.
• In practice, they include sub-activities such as
requirements validation, architectural design, unit
testing, …etc.
3/4/2024

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.
Software Development Life Cycle
5
3/4/2024

“The period of time that starts when a software
product is conceived and ends when the product
is no
life cycle typically includes a
longer available for use. The software
requirement
phase, design phase, implementation phase, test
phase, installation and check out phase, operation
and maintenance phase, and sometimes retirement
phase”.
Software Life Cycle Models
6
3/4/2024

• A software process model is a
representation of a software process.
simplified
• Each model represents a process from a specific
perspective.
• Those methodologies are sometimes known as
software development life cycle (SDLC)
methodologies, though this term could also be used
more generally to refer to any methodology.
SoftwareProcessModels
7
3/4/2024

Build & Fix Model
• Product is constructed
without specifications or any
attempt at design
• Ad hoc approach and not
well defined
• Simple two phase model Fix
Build
Code
8
3/4/2024

• 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
Build & Fix Model
9
3/4/2024

10
1. Waterfall Model
• This model is named “waterfall model” because it is
diagrammatic representation resembles a cascade of waterfalls.
• In the waterfall model, you must plan and schedule all of the
activities before starting working on them (plan-driven
process).
• This model is easy to understand and reinforces the notion
of “define before design” and “design before code”.
• The model expects complete and accurate requirements early in
the process, which is unrealistic
3/4/2024

1
1
The Nature of Waterfall Phases
• In principle, the result of each phase is one or more documents
that should be approved and the next phase shouldn’t be started
until the previous phase has completely been finished.
• In practice, however, these phases overlap and feed information
to each other. For example, during design, problems with
requirements can be identified, and during coding, some of the
design problems can be found, etc.
• The software process therefore is not a simple linear but involves
feedback from one phase to another. So, documents produced in
each phase may then have to be modified to reflect the changes
made.
3/4/2024

Waterfall Model
12
3/4/2024

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.
Waterfall Model
13
3/4/2024

2.Incremental Process Models
• They are effective in the situations where requirements are
defined precisely and there is no confusion about the
functionality of the final product.
• After every cycle a useable product is given to the customer.
• Popular particularly when we have to quickly deliver a limited
functionality system.
• Incremental development is based on the idea of developing an
initial implementation, exposing this to user feedback, and
evolving it through several versions until an acceptable system
has been developed.
14
3/4/2024

2.Incremental Process Models
15
3/4/2024

3. Iterative Enhancement Model
This model has the same phases as the waterfall model, but
with fewer restrictions. Generally the phases occur in the same
order as in the waterfall model, but they may be conducted in
several cycles. Useable product is released at the end of the each
cycle, with each release providing additional functionality.
• Customers anddevelopers specify as many requirements as
possible and prepare a SRS document.
• Developers and customers then prioritize these requirements
• Developers implement the specified requirements in one or
more cycles of design, implementation and test based on the
defined priorities.
16
3/4/2024

Requirements
specification
Architectural
design
Detailed
design
Implementation
and unit testing
Integration
and testing
Operation and
Maintenance
Iterative Enhancement Model
17
3/4/2024

That is the program after
debugging
4. The Rapid Application Development (RAD) Model
o Developed by IBM in 1980
o User participation is essential
The requirements
specification was
defined like this
The developers
understood it in
that way
This is how the
problem was
solved before.
This is how the
problem is
solved now
This is how the program is
described by marketing
department
This, in fact, is what the
customer wanted …
18
3/4/2024

The Rapid Application Development (RAD) Model
• Build a rapid prototype
• Give it to user for evaluation & obtain feedback
• Prototype is refined
With active participation of users
Requirements
Planning
User
Description
Construc
tion
Cut over
19
3/4/2024

2
0
• 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.
3/4/2024

RAD Phases
2
1
3/4/2024

The phases in the rapid application development (RAD) model are:
• Business modeling: The information flow is identified between various
business functions.
• Data modeling: Information gathered from business modeling is used to
define data objects that are needed for the business.
• Process modeling: Data objects defined in data modeling are converted
to achieve the business information flow to achieve some specific
business objective.
• Application generation: Automated tools are used to convert process
models into code and the actual system.
• Testing and turnover: Test new components and all the interfaces.
22
3/4/2024

5. 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.
23
3/4/2024

V
alidation
Final
version
Development Intermediate
versions
Specification
Initial
version
Outline
description
Concurrent
activities
Evolutionary Process Model
24
3/4/2024

5.1 Prototyping Model
Y The prototype may be a usable program but is not suitable
as the final software product.
Y The code for the prototype is thrown away.
However experience gathered helps in developing the actual
system.
Y 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.
25
3/4/2024

• Linear mode
• “Rapid”
l
Prototyping Model…Con’t
26
3/4/2024

5.2 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.
27
3/4/2024

Spiral Model…Con’t
28
3/4/2024

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
29
3/4/2024

• 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 model in
appropriate 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.
3/4/2024

6. The Unified Process
• Developed by I.Jacobson, G.Booch and J.Rumbaugh.
• Software engineering process with the goal of producing good
quality maintainable software within specified time and budget.
• Developed through a series of fixed length mini projects called
iterations.
• Maintained and enhanced by Rational Software Corporation and
thus referred to as Rational Unified Process (RUP).
3/4/2024

Phases of the Unified Process
Definition of
objectives
of the project
Planning &
architecture
for the project
Initial
operational
capability
Inception
Inception Elaboration
Elaboration Construction
Construction Transition
Transition
Release of
the Software
product
Time
3/4/2024

• Inception: defines scope of the project.
• Elaboration
- How do we plan & design the project?
- What resources are required?
- What type of architecture may be suitable?
• Construction: the objectives are translated in design &
architecture documents.
• Transition : involves many activities like delivering, training,
supporting, and maintaining the product.
Phases of the Unified Process
3/4/2024

Initial development & Evolution Cycles
Initial development Cycle
Evolution Cycle
Inception Elaboration Construction Transition
Construction Transition
Inception
Construction Trranssiittiion
V1
Inception
Construction Trranssiittiion
V2
Continue till the product is retired
V1=version1, V2 =version2, V3=version3
V3
3/4/2024

Iterations & Workflow of Unified Process
3/4/2024

Inception Phase
The inception phase has the following objectives:
• Gathering and analyzing the requirements.
• Planning and preparing a business case and evaluating
alternatives for risk management, scheduling resources etc.
• Estimating the overall cost and schedule for the project.
• Studying the feasibility and calculating profitability of the
project.
3/4/2024

Outcomes of Inception Phase
Inception
Project plan
Initial risk
assessment
Initial business
case
Vision
document Initial use
case model
Initial
project
Glossary
Business
model
Prototypes
3/4/2024

Elaboration Phase
infrastructure
& development
• Establishing architectural foundations.
• Design of use case model.
• Elaborating the process,
environment.
• Selecting component.
• Demonstrating that architecture support
reasonable cost & within specified time.
the vision at
The elaboration phase has the following objectives:
3/4/2024

Outcomes of Elaboration Phase
Elaboration
Revised risk
document
An executable
architectural
prototype
Architecture
Description
document
Use case
model Supplementary
Requirements
with non functional
requirement
Preliminary
User manual
Development plan
3/4/2024

Construction Phase
The construction phase has the following objectives:
• Implementing the project.
• Minimizing development cost.
• Management and optimizing resources.
• Testing the product
• Assessing the product releases against acceptance criteria
3/4/2024

Outcomes of Construction Phase
Construction
Operational
manuals
Test Suite
Adescription
of the
current release
Software
product User manuals
Documentation
manuals
Test
Outline
3/4/2024

Transition Phase
The transition phase has the following objectives:
• Starting of beta testing
• Analysis of user’s views.
• Training of users.
• Tuning activities including bug fixing and enhancements for
performance & usability
• Assessing the customer satisfaction.
3/4/2024

Outcomes of Transition Phase
Transition
Product
release
Beta test reports
User feedback
3/4/2024

Selection of a Life Cycle Model
Selection of a model is based on:
a) Requirements
b) Development team
c) Users
d) Project type and associated risk
3/4/2024

BasedOn CharacteristicsOf Requirements
Requirements Waterfall Prototype Iterative
enhancement
Evolutionary
development
Spiral RAD
Are requirements
easily understandable
and defined?
Yes No No No No Yes
Do we change
requirements quite
often?
No Yes No No Yes No
Can we define
requirements early
in the cycle?
Yes No Yes Yes No Yes
Requirements are
indicating a complex
system to be built
No Yes Yes Yes Yes No
3/4/2024

BasedOnStatusOf Development Team
Development
team
Waterfall Prototype Iterative
enhancement
Evolutionary
development
Spiral RAD
Less experience on
similar projects?
No Yes No No Yes No
Less domain
knowledge (new to
the technology)
Yes No Yes Yes Yes No
Less experience on
tools to be used
Yes No No No Yes No
Availability of
training if required
No No Yes Yes No Yes
3/4/2024

Based On User’sParticipation
Involvement
of Users
enhancement
Evolutionary
development
Spiral RAD
User involvement
in all phases
No Yes No No No Yes
Limited user
participation
Yes No Yes Yes Yes No
User have no
previous experience
of participation in
similar projects
No Yes Yes Yes Yes No
Users are experts
of problem domain
No Yes Yes Yes No Yes
3/4/2024

BasedOnTypeOf ProjectWith AssociatedRisk
Project type
and risk
enhancement
Evolutionary
development
Spiral RAD
Project is the
enhancement of the
existing system
No No Yes Yes No Yes
Funding is stable
for the project
Yes Yes No No No Yes
High reliability
requirements
No No Yes Yes Yes No
Tight project
schedule
No Yes Yes Yes Yes Yes
Use of reusable
components
No Yes No No Yes Yes
Are resources
(time, money,
people etc.) scare?
No Yes No No Yes No
3/4/2024

Thank You
3/4/2024

Chapter_2_Software_Development_Life_Cycle_and_Process_Models.pptx

More Related Content

Similar to Chapter_2_Software_Development_Life_Cycle_and_Process_Models.pptx (20)

More from gadisaAdamu (20)

Recently uploaded (20)

Chapter_2_Software_Development_Life_Cycle_and_Process_Models.pptx