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
 Simple, easy to understand
 Predictability: Milestones are
well understood
 Efficient
 Good for management
control (plan, staff, track)
disadvantage
 Not flexible for change
 First release takes long time
 Risks shift to the end
 Very low customer involvement
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