Software Processes

The 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. It presents a
description of a process from some particular
perspective.
Generic software process models
• The waterfall model
– Separate and distinct phases of specification and
development.
• Evolutionary development
– Specification, development and validation are
interleaved.
• Component-based software engineering
– The system is assembled from existing
components.
• There are many variants of these models e.g. formal development where a
waterfall-like process is used but the specification is a formal specification that is
refined through several stages to an implementable design .
 Waterfall model
Requir ements
definition

System and
software design

Implementa tion
and unit testing

Integ ration and

system testing

Oper ation and

maintenance
 Waterfall model phases
• 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. One phase has to
be complete before moving onto the next
phase.
 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.
 Component-based software
engineering
• 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 increasingly used
as component standards have emerged.
Reuse-oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integ ration validation
 Agile Methodologies
Extreme programming
• An 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.
• Extreme programming is an approach to
development based on the development and delivery
of very small increments of functionality. It relies on
constant code improvement, user involvement in the
development team and pair wise programming.
• Scrum involves teams working together in
development. Their work in broken down into actions
and can be completed within sprints(iterations).
Rechecking and planning is down daily (daily
scrums). Development in XP is iterative and flexible.
Hence widely used these days.
 Evolutionary development
• 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
and add new features as proposed by the
customer.
• Throw-away prototyping
– Objective is to understand the system
requirements. Should start with poorly understood
requirements to clarify what is really needed.
Evolutionary development
Concurr ent
acti vities

Initial
Specification version

Outline Intermedia te
Development versions
description

Final
Valida tion version
 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);
– For short-lifetime systems.
 Process iteration
• 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 delivery;
– Spiral development.
 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.
 Spiral model
Deter mine objecti ves,
Evalua te alterna tives,
alterna tives and
identify, resolv e risks
constr aints Risk
anal ysis

Risk
anal ysis

Risk
Oper a-
anal ysis
Pr ototype 3 tional
Prototype 2 protoype
Risk
REVIEW anal ysis Proto-
type 1
Requir ements plan Simula tions , models , benchmar ks
Life-cy cle plan Concept of
Oper a tion S/W
requir ements Product
design Detailed
Requir ement design
De velopment
plan valida tion Code
Unit test
Integ ra tion Design
V&V Integ ra tion
and test plan
Plan ne xt phase test
Acceptance
Service test De velop , verify
ne xt-le vel pr oduct
 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.
• Planning
– The project is reviewed and the next phase of the
spiral is planned.
 Incremental delivery
• Rather than deliver 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.
 Incremental development

Define outline Assign requirements Design system

requirements to increments architectur e

Develop system Valida te Integ rate Validate

increment increment increment system
Final
system
System incomplete
 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.
 The Rational Unified Process
• A modern process model derived from the
work on the UML and associated process.
• Normally described from 3 perspectives
– A dynamic perspective that shows phases
over time;
– A static perspective that shows process
activities;
– A practive perspective that suggests good
practice.
 RUP phase model

Phase iteration

Inception Elaboration Construction Transition

 RUP phases
• Inception
– Establish the business case for the system.
• Elaboration
– Develop an understanding of the problem domain
and the system architecture.
• Construction
– System design, programming and testing.
• Transition
– Deploy the system in its operating environment.
 RUP good practice
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software
 Process activities
• Software specification
• Software design and implementation
• Software validation
• Software evolution
 Key points
• Software processes are the activities involved in
producing and evolving a software system.
• Software process models are abstract
representations of these processes.
• General activities are specification, design and
implementation, validation and evolution.
• Generic process models describe the organisation of
software processes. Examples include the waterfall
model, evolutionary development and component-
based software engineering.
• Iterative process models describe the software
process as a cycle of activities.
 Key points
• Requirements engineering is the process of
developing a software specification.
• Design and implementation processes transform the
specification to an executable program.
• Validation involves checking that the system meets to
its specification and user needs.
• Evolution is concerned with modifying the system after
it is in use.
• The Rational Unified Process is a generic process
model that separates activities from phases.
• CASE technology supports software process
activities.