SOFTWARE
DEVELOPMENT
LIFE CYCLE
MODELS
PREDICTIVE MODELS
BUILDING SOFTWARE - SIMPLE LIFE CYCLE MODEL
Design Testing
Problem Model Working System
Req. Specification System
Requirements
Engineering
Implementation Maintenance
2
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Milestones identified in a software development project correspond to
points in time at which certain output is available
Requirements Engineering ➔ SRS Document
Design ➔ FSD Document
Implementation ➔ Programs / Components
Testing ➔ Test Report
Development process is seen as a series of transformations
Starts with clear requirements document
Ends with running code
3
DOCUMENTATION
Includes
Project Plan / Business Requirements
Quality Assurance Plan
Software Requirements Specification
Functional Specification
Architecture Description
Design Documentation
User Interface Requirements
Test plan
Often seen as a balancing item
Important element: user manuals (task oriented)
4
GLOBAL DISTRIBUTION OF EFFORT
testing
implementation
design
requirement
engineering
maintenance
70%
5
KINDS OF MAINTENANCE ACTIVITIES
Corrective
correcting errors
Adaptive
adapting to changes in the environment
(both hardware and software)
Perfective
adapting to changing user requirements
Preventive
Increasing future maintainability (adding
comments, updating documentation)
6
SOFTWARE ENGINEERING ETHICS - PRINCIPLES
▪ Act consistently with the public interest
▪ Act in a manner that is in the best interest of the client and employer
▪ Ensure products meet the highest professional standards possible
▪ Maintain integrity in professional judgment
▪ Managers shall promote an ethical approach
▪ Advance the integrity and reputation of the profession
▪ Be fair to and supportive of colleagues
▪ Participate in lifelong learning and promote an ethical approach for
yourself
7
A BROADER VIEW ON SOFTWARE DEVELOPMENT
Meta-project planning information planning Overall guidelines set by organization
boundary • Use of certain standards
• Data interchange formats
conditions • Security policies
• Webpage layout
documentation people
software
program
input output
program
Interact with existing software
Software development project is Extend existing software
a misnomer Use existing subroutine libraries
procedures
➔ Develop full systems
8
PROJECT CONTROL
Exert control along the following dimensions during project execution
Time
Informa
Money
tion
Project
Control
Organi
Quality
zation
9
CONTENTS OF PROJECT PLAN
Standards,
Process Organization Management
Introduction Guidelines,
Model of Project Activities
Procedures
Methods and Quality Work
Risks Staffing
Techniques Assurance Packages
Budget and
Resources Changes Delivery
Schedule
10
CONTENTS OF PROJECT PLAN
Standards,
Process Organization Management
Introduction Guidelines,
Model of Project Activities
Procedures
Methods and Quality Work
Risks Staffing
Techniques Assurance Packages
Budget and
Resources Changes Delivery
Schedule
11
SOFTWARE PROCESS MODEL
A software process is an application of a model for a specific
project, which may include some adaptation
Software Process Model
an abstract representation of the software process
represents a description of a process from some perspective
12
BAKING PROCESS MODELS
List Measure Measure
ingredients Ingredients and mix dry
Measure ingredients
and mix wet
components
Mix the wet Mix the dry
components components vs. Combine in
tray
Combine in
Bake
Tray
Bake
13
WHY PROCESS MODELS?
To manage large projects
To divide the project and properly assign tasks
To anticipate and manage the risks
14
CHOOSING A MODEL
No model is better than the other
The choice is made according to certain criteria
nature of the project
project size
nature of the client
Team skills
15
SOFTWARE DEVELOPMENT MODELS
SDLC Models
Heavyweight Lightweight
(Predictive) (Adaptive)
Waterfall Incremental Iterative RAD and Agile
Models Models Model DSDM Frameworks
Waterfall Sashimi Prototype Extreme
V Model Spiral Model Scrum Lean
Model Model model Programming
16
SOFTWARE DEVELOPMENT MODELS
Planning driven or document driven Agile methods
Emphasis on plan of whole process Deal with rapidly changing
circumstances
Better fit large projects
Small projects (less than 50 people)
Requirements can be decided at an
early stage
17
PREDICTIVE VS ADAPTIVE MODELS
18
SOFTWARE DEVELOPMENT MODELS
SDLC Models
Heavyweight Lightweight
(Predictive) (Adaptive)
Waterfall Incremental Iterative RAD and Agile
Models Models Model DSDM Frameworks
Waterfall Sashimi Prototype Extreme
V Model Spiral Model Scrum Lean
Model Model model Programming
19
WATERFALL MODEL
Also called linear model
includes iteration and feedback
V&V
The result of each phase is a set of deliverables
V&V
(product or document)
Verification and Validation (V & V) after each
step
V&V
V&V
V&V
20
WATERFALL MODEL
Careful analysis before software is built
Team has experience building similar software
V&V
Translation from requirement to product is going
V&V
to be perfect
V&V
V&V
V&V
21
WATERFALL MODEL
advantages disadvantage
Simple, easy to understand Not flexible for change
Predictability: Milestones are First release takes long time
well understood Risks shift to the end
Efficient Very low customer involvement
Good for management
control (plan, staff, track)
22
WHEN TO USE THE WATERFALL MODEL?
Any project where complete and stable requirements is
available.
Large projects as long as:
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
Example: Creating a new Web site for a company that uses
existing technology
23
V MODEL
Emphasis on validation earlier
in the project
abstraction
Introducing the testing
activities earlier in the model
Doesn’t allow feedback or
changes between phases
Project completion
24
V MODEL
advantages disadvantage
Earlier detection of potential More upfront work
defects/issues
25
SASHIMI MODEL
Overlapping phases
A phase can start before previous
phase ends
Example
instead of waiting for the
requirement phase to complete,
you will start with your design
while the requirements are being
created
26
SASHIMI MODEL
advantages disadvantage
Shorten development time May result in rework
People with different skill can
start working without waiting
Can do a learning spike early
27
WATERFALL MODELS
Phase Implement Integration Acceptance
Design ation testing testing
Activity
Integration
testing
4.7 43.4 26.1 25.8
Implementation
(& unit testing)
6.9 70.3 15.9 6.9
Design 49.2 34.1 10.3 6.4
28
SOFTWARE DEVELOPMENT MODELS
SDLC Models
Heavyweight Lightweight
(Predictive) (Adaptive)
Waterfall Incremental Iterative RAD and Agile
Models Models Model DSDM Frameworks
Waterfall Sashimi Prototype Extreme
V Model Spiral Model Scrum Lean
Model Model model Programming
29
INCREMENTAL MODELS
The requirements are divided into small
modules
Multiple mini waterfalls
The software is built with several
(overlapping) increments
Each increment is a partial construction of
software
Each construction part goes through the
phases of requirements analysis, design,
implementation and testing
A functional version of the software is
produced at the end of the first
increment
30
INCREMENTAL MODEL
advantages disadvantage
Features with high risk are developed Requires good planning
first
Requires a vision of the finished product
The increments can be planned to to be able to divide it into increments
manage technical risks
Each increment is a functional product
The customer can evaluate the product
at the end of each increment
Lower risk of overall project failure
31
WHEN TO USE INCREMENTAL MODEL
When most specifications are known in advance and are
subject to small changes
Need to deliver a product to market quickly
When there are not enough developers to finish the project
on time, so an almost complete functional software can be
the solution
32
ITERATIVE MODEL
initial, simplified implementation
progressively gains more complexity
and a broader feature set until the
final system is complete
incremental alterations made during
the design and implementation of
each new iteration
33
RATIONAL UNIFIED PROCESS (RUP)
establish scope,
foundation of
feasibility, critical use release to user
architecture, establish manufacturing process,
cases, candidate community, often
tool support, get all use one or more releases
architectures, schedule several releases
cases
and cost estimates
• Complement to UML
(Unified Modeling
Language)
• Iterative approach for
object-oriented systems,
strongly embraces use
cases for modeling
requirements
34
ITERATIVE MODEL (RUP)
advantages disadvantage
Includes some adaptivity Complicated
Quality and reuse Need more resources
Focus on risk mitigation Too much overhead for small
increases chances of success projects
Flexible to incorporate other
SDLC models
35
WHEN TO USE ITERATIVE MODEL
Bigger and riskier projects
All requirements not known early in the
project
Desire to deliver value earlier
36
PROTOTYPE MODEL
The project is done over several iterations
The client and the developer meet and define the
goals and needs of software and items that are not
yet clear.
The developer builds a prototype according to client
expectations
The prototype is evaluated by the customer
The customer gives his feedback
Developers adapt the prototype according to
customer requirements
When the prototype meets the client requirements,
the code is normalized according to the standards
and best practices
37
PROTOTYPING
requirements elicitation is difficult
software is developed because the present situation is unsatisfactory
however, the desirable new situation is as yet unknown
prototyping is used to obtain the requirements of some aspects of the
system
prototyping should be a relatively cheap process
use rapid prototyping languages and tools
not all functionality needs to be implemented
production quality is not required
38
PROTOTYPING TYPES
Evolutionary Prototyping Throw-away prototyping
The prototype may evolve into the final Objective is to understand the
product. system requirements and
The user starts by formulating raw outline a better definition of
requirements and a first version of the requirements.
system is produced.
Should start with poorly
The user starts to work with this system,
which leads to new or changed
understood requirements to
requirements. clarify what is really needed
After numbers of iteration, and when the
user is satisfied, the last version
developed is the product to be
delivered.
39
PROTOTYPE MODEL
advantages disadvantage
The resulting system is easier to use Prototype developed
User needs are better without quality assurance
accommodated
Implementation
The design is of higher quality
compromises
Problems are detected earlier
The development incurs less effort Maintainability is overlooked
40
SPIRAL MODEL
risk-driven iterative model
a combination of the waterfall
model and the iterative model
At the end of each cycle the
objectives of the next cycle are
determined
Each cycle consists of the same
activities as the waterfall model
41
SPIRAL MODEL
advantages disadvantage
Early identification of risks => The model is very complex
Minimal impacts of risks on projects The spiral can go on forever
Critical features are developed first
Risk assessment can be time
Software is produced early in the life consuming
cycle
Risk analysis requires very specific
Rapid customer feedback
expertise
An ongoing assessment of the
development process
42
WHEN TO USE SPIRAL MODEL
Any project for which the requirements are not stable and can be
modified
When the risks are considerable (financial, technological, human,
..).
Generally, these are projects that relates to a new and complex
software that requires extensive research and investigation
43
READING REFERENCE
44
AGILE METHODS
45
