Software Process

Software Processes
sets of activities for
specifying,
designing,
implementing
testing
Evolution of software systems
Model??
Abstraction / template
%e software process
A structured set of activities required to develop a
software system
Specification
Design
Validation
Evolution
A software process model is an abstract
representation of a process. t presents a description
of a process from some particular perspective
8ystem||nformat|on
eng|neer|ng
eneric software process modeI
ana|ys|s
des|gn
code test
eneric software process modeIs
inear Sequential
terative
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
aterfaII modeI
Requirements
deIinition
System and
soItware design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
aterfaII modeI pases
Pases
#equirements anaIysis and definition
System and software design
ImpIementation and unit testing
Integration and system testing
Operation and maintenance
%e drawback of te waterfaII modeI is te difficuIty of
accommodating cange after te process is underway
real projects rarely Iollow it
diIIicult to establish all requirements explicitly, no room Ior
uncertainty
customer must have patience, not Iast enough Ior delivery oI
modern internet based soItware
major mistake can be disastrous
unnecessary delays, 'blocking states
InIlexible partitioning oI the project into distinct stages
Model is appropriate when requirements are well-understood
!74-028
;oIutionary ModeIs /
Proto types
:||d|Rev|se
mock-:5
|sten to
6:stomer
6:stomer test
dr|ves
mock-:5
!rototy5|ng
Wvo|:t|onary
W:||d to kee5
W%rowaway
W:||t not to kee5
$42207;0
;oIutionary de;eIopment
Exploratory development
Objective is to work with customers
and to evolve a final system from an
initial outline specification. Should
start with well-understood
requirements
Throw-away prototyping
Objective is to understand the
system requirements. Should start
with poorly understood requirements
:||d|Rev|se
mock-:5
|sten to
6:stomer
6:stomer test
dr|ves
mock-:5
;oIutionary de;eIopment
!roblems
ack of process visibility
Systems are often poorly structured
Quality Compromised
Special skills (e.g. in languages for rapid
prototyping) may be required
Should not be taken as a complete process model
Applicability
For small or medium-size interactive systems
For parts of large systems (e.g. the user interface)
For short-lifetime systems
For Analysis Only
Process iteration
iteration?
teration can be applied to any of the generic
process models
Two (related) approaches
ncremental development
Spiral development
IncrementaI de;eIopment
Do not deliver the system as a single delivery
development and delivery broken down into increments
each increment delivering part of the required functionality
User requirements are prioritized (highest first)
Once an increment is started, requirements are frozen
requirements for later increments can continue to evolve
'alidate
increment
Develop system
increment
Design system
architecture
Integrate
increment
'alidate
system
DeIine outline
requirements
Assign requirements
to increments
System incomplete
Final
system
IncrementaI de;eIopment
Obfect-Oriented and Classical Software Engineering, FiIth Edition, WCB/McGraw-Hill,
2002Stephen R. Schach
IncrementaI de;eIopment ad;antages
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
ower risk of overall project failure
The highest priority system services tend to
receive the most testing
SpiraI de;eIopment
spiral??
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
SpiraI modeI 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
!lanning
The project is reviewed and the next phase of the spiral
is planned
d;antages
%e #ationaI Unified Process
A modern process model derived from the
work on the UM and associated process.
Normally described from 3 perspectives
A dynamic perspective that shows phases over
time;
A static perspective that shows process
activities;
A perspective that suggests good practice.
%e (#ationaI) Unified Process
#UP good practice
Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software
ormaI systems de;eIopment
ased on the transformation of a mathematical
specification through different representations to
an executable program
Transformations are 'correctness-preserving' so it
is straightforward to show that the program
conforms to its specification
Embodied in the 'Cleanroom' approach to
software development
Requirements
deIinition
Formal
speciIication
Formal
transIormation
Integration and
system testing
ormaI systems de;eIopment
!roblems
Need for specialised skills and training to apply
the technique
Difficult to formally specify some aspects of the
system such as the user interface
Applicability
Critical systems especially those where a safety
or security case must be made before the
system is put into operation
giIe Metods
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work
performed
Yielding .
Rapid, incremental delivery of software
Extreme !rogramming (X!)
Test First, !air !rogramming