The document discusses different software development process models including waterfall, evolutionary development, incremental development, and spiral models. The waterfall model involves sequential phases of requirements, design, implementation, testing and maintenance. However, it does not handle changes well. Evolutionary and incremental models incorporate feedback loops and iterative development. The spiral model is risk-driven and guides teams to adopt elements of other models based on a project's risk assessment.

1. THE SOFTWARE PROCESS
CSE 470 : Software Engineering
Ashis Kumar Chanda
Lecturer, BRACU

2. 2
What is a Process?
We can think of a series of activities as a process
Any process has the following characteristics
 It prescribes all of the major activities
 It uses resources and produces intermediate and final products
 It may include sub-processes and has entry and exit criteria
 The activities are organized in a sequence
 Constraints or control may apply to activities
(budget control, availability of resources )

3. 3
Software Processes
Coherent sets of activities for
Specifying,
Designing,
Implementing and
Testing software systems
When the process involves the building of some product,
we refer to the process as a life cycle
Software development life cycle (SDLC)

4. 4
The Software Process
A structured set of activities required to
develop a software system
 Specification
 Design
 Validation
 Evolution
Fundamental Assumptions:
 Good processes lead to good software
 Good processes reduce risk

5. 5
Generic software process models
The waterfall model
 Separate and distinct phases of specification and development
Evolutionary development
 Specification and development are interleaved
Formal systems development
 A mathematical system model is formally transformed to an
implementation
Reuse-based development
 The system is assembled from existing components

6. 6
Fundamental activities
Requirements
System & Software Design
Implementation (Programming)
Integration & Testing
Maintenance

7. 7
Requirements Analysis and Definition
The system's services, constraints and goals are established by
consultation with system users. They are then defined in a
manner that is understandable by both users and development
staff.
This phase can be divided into:
 Feasibility study (often carried out separately)
 Requirements analysis
 Requirements definition
 Requirements specification

8. 8
System and Software Design
System design: Partition the requirements to hardware or
software systems. Establishes an overall system
architecture
Software design: Represent the software system
functions in a form that can be transformed into one or
more executable programs
 Unified Modeling Language (UML)

11. 11
Programming and Unit Testing
The software design is realized as a set of programs or
program units. (Written specifically, acquired from
elsewhere, or modified.)
Individual components are tested against specifications.

12. 12
Integration and System Testing
The individual program units are:
 integrated and tested as a complete system
 tested against the requirements as specified
 delivered to the client

13. 13
Operation and Maintenance
 Operation: The system is put into practical use.
 Maintenance: Errors and problems are identified and
fixed.
 Evolution: The system evolves over time as
requirements change, to add new functions or adapt the
technical environment.
 Phase out: The system is withdrawn from service.

14. 14
Deployment &
Maintenance
Requirements
Design
Implementation
Testing
Waterfall
method
The Waterfall Model

15. 15
Advantages of the Waterfall Approach
Develop requirements before design
Design before writing code
Write code before integrating it
Test programs after integrating them
Have milestone reviews

16. 16
Any problems?
Real life is not a straight line

17. 17
Some Realities of Software Development
1. Requirements always change because of:
 changing customer desires and user needs
 initial requirements analysis inadequate
 understandings and insights gained through experience
 changing technology
 changing competitive situation
 personnel turnover: engineering, management, marketing, customer
2. The design is never right the first time
 design is a creative, problem solving process
3. Frequent demonstrations of progress and early
warning of problems are desirable

18. 18
The Waterfall Approach
The Waterfall Model requires that we (attempt to):
 specify the requirements completely, consistently, correctly,
and unambiguously on the first attempt
 design the software completely and correctly on the first
attempt
 write all of the software interfaces and internal details correctly
on the first attempt
 integrate the components in one large step
 do system testing and acceptance testing at the end
The linear waterfall model is a one-pass process

19. 19
Discussion of the Waterfall Model
Advantages:
-Identifies systems requirements long before programming
begins.
- Only appropriate when the requirements are well-understood
Disadvantages:
-Takes long time to deliver since developing requirements.
- Difficult to adapt to changing requirements
- Each stage in the process reveals new understanding of the
previous stages, that requires the earlier stages to be revised.

20. 20
Relative Cost to Fix a Software Defect

21. 21
Feedback in the Waterfall Model
Requirements
Definition
System and
Software design
Programming
and Unit Testing
Integration and
System Testing
Operation and
Maintenance

22. 22
Evolutionary development
Exploratory development
- Objective is to work with customers and to evolve a final
system from an initial outline specification.
- The system evolves by adding new features as they are
proposed by customer.

23. 23
Evolutionary development
Rapid prototyping
 Objective is to understand the system requirements.
 Develop “quick and dirty” system in short time;
 Expose to user comment & feedback;
 Refine;
Repeat until adequate system developed.
 Particularly suitable where:
- detailed requirements not possible;
- powerful development tools (CASE) available

24. 24
Evolutionary development
Outline
Description
Concurrent
Activities
Requirements
Design
Implementation
Initial
Version
Intermediate
Versions
Final
Version

25. 25
Evolutionary development
Requirements
Design
Implementation
(prototype)
Evaluation

26. 26
Evolutionary development
Problems
 Lack of process visibility
 Systems are often poorly structured
 Special skills (e.g. in languages for rapid prototyping)
may be required
Applicability
 For small or medium-size interactive systems
 For parts of large systems (e.g. the user interface)

27. 27
Process iteration
• Modern development processes take iteration as a fundamental
concept.
•System requirements ALWAYS evolve during the course of a
project; so process iteration where earlier stages are reworked is
always part of the process for large systems.
•Iteration can be applied to any of the generic process models.
•Two (related) approaches:
• Incremental development
• Spiral development

28. 28
Incremental development
 System is not a single delivery; the development and
delivery broken down into increments delivering part of
the required functionality.
 User requirements are prioritized and the highest
priority requirements are included in early increments.
 Once the development of an increment is started,
the requirements are frozen though requirements
for later increments can continue to evolve.

29. 29
Incremental development
Validate
increment
Develop system
increment
Design system
architecture
Integrate
increment
Validate
system
Define outline
requirements
Assignrequirements
to increments
Systemincomplete
Final
system

30. 30
The Incremental Model

31. 31
Incremental development advantages
 Customer value can be delivered with each increment so
system functionality is available earlier.
 Early increments act as a prototype to help elicit
requirements for later increments
 Lower risk of overall project failure
 The highest priority system services tend to receive the
most testing

32. 32
Incremental development problems
 The process is not visible.
o Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not cost-
effective to produce documents that reflect every version
of the system.
 System structure tends to degrade as new increments are
added.
o Unless time and money is spent on refactoring to
improve the software, regular change tends to corrupt its
structure. Incorporating further software changes becomes
increasingly difficult and costly.

33. 33
Spiral Model
 The spiral model is a risk-driven process model
generator for software projects. Based on the unique risk
patterns of a given project, the spiral model guides a team to
adopt elements of one or more process models, such as
incremental, waterfall, or evolutionary prototyping.
This model was first described by Barry Boehm in his
1986 paper "A Spiral Model of Software Development and
Enhancement".

34. 34
Spiral development
 Process is represented as a spiral rather than as a sequence of
activities with backtracking.
 Each loop in the spiral represents a phase in the process.
 No fixed phases such as specification or design – loops in the
spiral are chosen depending on what is required.
 Risks are explicitly assessed and resolved throughout the
process.

35. 35
Spiral model of the software process
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysisProto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Conceptof
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unittest
Integration
testAcceptance
testService Develop, verify
next-levelproduct
Evaluate alternatives
identify, resolve risks
Determine objectives
alternativesand
constraints
Plannextphase
Integration
andtestplan
Development
plan
Requirementsplan
Life-cycle plan
REVIEW

36. 36
Spiral model sectors
 Objective setting
• Specific objectives for the phase are identified
 Risk assessment and reduction
• Risks are assessed and activities put in place to reduce key risks
 Development and validation
• A development model for the system is chosen which can be
any of the generic models
 Planning
• The project is reviewed and next phase of the spiral is planned

37. 37
Spiral model usage
 Spiral model has been very influential in helping
people think about iteration in software processes and
introducing the risk-driven approach to development.
 In practice, however, the model is rarely used as
published for practical software development.

38. 38
References
Cornell University, USA
http://www.cs.cornell.edu/courses/cs501/2000fa/slides.html
Picture collect from: Ivan Marsic, Rutgers
University
Ian Sommerville, Software Engineering, 9th
edition, Pearson, 2011
Roger s. pressman, Software Engineering a
practitioners approach, 7th
ed