Software Processes

 When we provide a service or create a

product we always follow a sequence of
steps to accomplish a set of tasks
◦ E.g You do not usually
 put up the drywall before the wiring
for a house is installed or
 bake a cake before all the ingredients
are mixed together
 We can think of a series of activities as
a process
◦ 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 )
 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
◦ It presents a description of a process from
some particular perspective
 Requirement 08.34%
 Design 13.61%
 Coding 18.00%
 Unit Testing 09.00%
 Integration Testing 09.93%
 Project Management 08.08%
 Configuration Management 08.65%
 Software Quality assurance 04.50%
 Use Documentation 09.67%
 Rest of the activities 10.22%
 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
Any Engineering approach must be founded on
organizational commitment to quality.

The quality focus demands that processes be

defined for rational and timely development of
software.

The processes make framework for a set of key

process areas (KPAs) for effectively manage and
deliver quality software in a cost effective manner.
A Software Engineering
Framework

Method T
O
Task Set Process O
L
Quality Focus S
 A Software Engineering
Framework
Methods provide the
technical “how-to’s” to
The processes
carry-out these tasks
define the tasks to
be performed and Method T
the order in which O
they are to be Process O
performed along L
with the milestones Quality Focus S
and deliverables at
these The quality control defines the
milestones. SQA points within those tasks and
the quality parameters
A Software Engineering
Framework Tools provide
Method T automated or semi-
O automated support
Process O for software
L processes, methods,
Quality Focus S and quality control.

The difference between a tool and a method:

Standard deviation is a method to estimate and measure
dispersion of data
Excel is a tool that can be used to calculate standard
deviation
Software Development Loop

Problem
Definition

Technical
Status Quo
Development

Solution
Integration
 Maintenance

 Correction, adaptation, enhancement

◦ For most large, long life time software
systems, maintenance cost normally exceeds
development cost by factors ranging from 2
to 3.

◦ Boehm (1975) quotes a pathological case

where the development cost of an avionics
system was $30 per line of code but the
maintenance cost was $4000 per instruction
 Software Engineering Phases

1. Vision – focus on why

2. Definition – focus on what
2. Development – focus on how
3. Maintenance – focus on change

Vision Definition Development Maintenance

Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
 Requirements analysis and
definition
 System and software design
 Implementation and unit
testing
 Integration and system testing
 Operation and maintenance
 Inflexible partitioning of the project into distinct
stages
 This makes it difficult to respond to changing
customer requirements
 Therefore, this model is only appropriate when
the requirements are well-understood

Waterfall model describes a

process of stepwise refinement
 Based on hardware engineering models
 Widely used in military and aerospace
industries
No fabrication step
 Program code is another design level
 Hence, no “commit” step – software can always be
changed…!
No body of experience for design analysis (yet)
 Most analysis (testing) is done on program code
 Hence, problems not detected until late in the process
Waterfall model takes a static view of requirements
 Ignore changing needs
 Lack of user involvement once specification is written
Unrealistic separation of specification from the design
Doesn’t accommodate prototyping, reuse, etc
 To overcome the major shortcomings of the
classical waterfall model, we come up with the
iterative waterfall model.
 A prototype is a toy implementation of the system.
A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient
performance compared to the actual software. A
prototype is usually built using several shortcuts.
The shortcuts might involve using inefficient,
inaccurate, or dummy functions. The shortcut
implementation of a function, for example, may
produce the desired results by using a table look-
up instead of performing the actual computations.
A prototype usually turns out to be a very crude
version of the actual system.
 how the screens might look like
 how the user interface would behave
 how the system would produce outputs

A prototype of the actual product is preferred

in situations such as:
 User requirements are not complete
 Technical issues are not clear
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.
 The system evolves by adding new
features as they are proposed by
customer.
Throw-away prototyping
 Should start with poorly understood
requirements
 Develop “quick and dirty” system quickly;
 Expose to user comment;
 Refine;
Until adequate system developed.
◦ Particularly suitable where:
-detailed requirements not possible;
-powerful development tools (e.g. GUI)
available
 Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
 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)
◦ For short-lifetime systems
 Based 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

(which was originally developed by IBM) to
software development
Requirements Formal Formal Integration and
definition specification transformation system testing
 Formal transformations
T1 T2 T3 T4

Formal R1 Executable
R2 R3
specification program

P1 P2 P3 P4

Proofs of transformation correctness

 Problems
◦ 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
 Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems
 Process stages
◦ Component analysis
◦ Requirements modification
◦ System design with reuse
◦ Development and integration

This approach is becoming more important

but still limited experience with it
Requirements Component Requirements System design
specification analysis modification with reuse

Development System
and integration validation
 Modern development processes take iteration
as fundamental, and try to provide ways of
managing, rather than ignoring, the risk
 System requirements ALWAYS evolve in 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
 Rather than delivering the system as a single
delivery, the development and delivery is
broken down into increments with each
increment delivering part of the required
functionality
 User requirements are prioritised 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
Define outline Assign requirements Design system
requirements to increments architecture

Develop system Valida te Integrate Valida te

increment increment increment system
Final
system
System incomplete
 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
 New approach to development based on the
development and delivery of very small
increments of functionality

 Relies on constant code improvement, user

involvement in the development team and
pairwise programming

 Design of the test suits first !

Then you perform testing of the system after
each small increment
 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
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
anaysis
l Proto-
REVIEW type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
 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
 Planning
◦ The project is reviewed and the next phase of the
spiral is planned