The Software Process
A structured set of activities required to develop a
software system.
Many different software processes but all involve:
Specification – defining what the system should do;
Design and implementation – defining the organization of the system
and implementing the system;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer
needs.
A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.
Chapter 2 Software Processes 3
Software Process Descriptions
When we describe and discuss processes, we usually
talk about the activities in these processes such as
specifying a data model, designing a user interface, etc.
and the ordering of these activities.
Process descriptions may also include:
Products, which are the outcomes of a process activity;
Roles, which reflect the responsibilities of the people involved in
the process;
Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a product
produced.
Chapter 2 Software Processes 4
Software Process Models - heavyweight model
Example: The Waterfall Model
Plan-driven model.
Separate and distinct phases of specification and development.
Heavily oriented toward documentation (documentation-intensive)
Progress often measured thru documentation completion and
reviews (many)
Garnett charts
Lockstep approach
Little chance for Change!
Oftentimes discover major flaws too late.
Delivered as Big Bang
Still exists in spades – but modified to a degree.
Chapter 2 Software Processes 6
The Waterfall Model
Notice the feedback loops
Chapter 2 Software Processes 8
Waterfall Model Phases
There are separate identified phases in the waterfall model:
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
The main drawback of the waterfall model is the difficulty
of accommodating change after the process is underway.
In principle, a phase has to be complete before moving
onto the next phase.
But many issues are true too, such as risk addressing.
War Stories but true.
Chapter 2 Software Processes 9
Waterfall Model Problems
Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
Therefore, this model is only appropriate when the requirements
are well-understood and changes will be fairly limited during
the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.
Chapter 2 Software Processes 10
Boehm’s Spiral Model - heavyweight model
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.
This was the motivation behind developing the Spiral Model - Risk
Chapter 2 Software Processes 11
Boehm’s Spiral Model of the Software Process
Chapter 2 Software Processes 12
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 the key
risks.
Development and validation
A development model for the system is chosen which can be any
of the generic models. Development takes place.
Planning
The project is reviewed and the next phase of the spiral is
planned.
Chapter 2 Software Processes 13
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.
Chapter 2 Software Processes 14