Software Processes
Chapter 4
Lecture 5
1
The software process
• A structured set of activities required to develop a
software system:
– Specification;
– Design;
– Implementation;
– Validation;
– Evolution.
• A software process model is an abstract representation
of a software process.
2
Generic software process models
• The waterfall model
– Separate and distinct phases of specification and
development.
• Evolutionary development
– An initial system is rapidly developed from abstract
specifications then refined according to customer input.
• Component-based software engineering
– The system is assembled from existing components.
The development process focuses on the integration of
the components into the system.
• In practice, the models are often combined.
3
Waterfall model (with iterations)
Requirements
definition
System and
software design
Implementa tion
and unit testing
Integration and
system testing
Operation and
maintenance
4
Waterfall model problems
• Difficult to respond to changing customer
requirements.
– Few business systems have stable requirements.
• Therefore, this model is only appropriate
when the requirements are well-understood
and changes will be fairly limited during the
design process.
• The waterfall model is mostly used for large
systems engineering projects where a system
is developed at several sites.
5
Evolutionary development
• Based on the idea of developing an initial
implementation, exposing it to the customer’s
feedback and then refining it through many versions.
• Two fundamental types of evolutionary development:
– Exploratory development
• Start with well-understood requirements and add new features as
proposed by the customer.
• Hence, requirements are well-understood but not complete.
– Throw-away prototyping
• Objective is to understand the system requirements. Should start with
poorly understood requirements to clarify what is really needed.
– Faster
– Requirements are sometimes poorly understood by the client
him/herself.
6
Evolutionary development
Concurrent
activities
Develop one
requirement
while Initial
Specification version
specifying
another
Outline Intermediate
Development
description You develop one requirement while specifyinganother
versions
Validate one
Final
requirement Validation version
while specifying
another or
developing
another
7
Evolutionary development
• Problems
– Lack of process visibility - managers need regular
deliverables to measure progress;
• This is not possible since after releasing a version you might
go back to specification-development-validation.
– Systems are often poorly structured – continuous change
tends to corrupt the software structure;
– Special skills are required (e.g. in languages for rapid
prototyping).
• Applicability
– For small or medium-size systems;
– For parts of large systems (e.g. the user interface), other
parts will have a different development process.
8
Component-based software engineering
(CBSE)
• Based on systematic reuse where systems
are integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
• This approach is becoming increasingly
used as component standards have emerged.
9
The generic process model for CBSE
Requirements Component Requirements System design
specification analysis modification with reuse
Development System
and integ
ration validation
• Requirement specification: similar to any other process.
• Component analysis: Given the requirements specification, search for components that implement the
specifications.
• Requirements modification: requirements are analyzed and changed according to the components that were found
at the previous stage.
• System design with reuse: establish a framework for all the components that were found. If none is found for
some functionality, new software has to be designed.
• Development and integration: software that cannot be externally procured is developed and COTS systems are
integrated to create the new system.
10
(Dis)Advantages of CBSE
• Advantages:
– reduces the amount of software that has to be developed
– results in reducing cost and risks
– fast delivery
• Disadvantages:
– requirements may have to be compromised if they cannot
be matched exactly.
– control over the evolution of the system is a bit
compromised (cannot control the evolution of the already-
existing components that were integrated in the system).
11
Process iteration
• Whatever software process model you choose, iteration
can be applied.
• During the lifetime of a software, change is inevitable.
– Requirements change as the business changes, management
priorities change, etc.
• So, process iteration where earlier stages are reworked is
always part of the process for large systems.
• One approach to support process iteration:
– Incremental delivery
12
Incremental delivery
• Recall
– The Waterfall model :
• requires customers of a system to commit to a set of requirements
before design begins and the developer to commit to design
strategies before implementation.
• However, it gives well-documented systems easy to maintain.
– Evolutionary development:
• allows requirement and design to be delayed
• but also leads to software that may be poorly-structured and difficult
to understand and maintain.
• Incremental delivery :
• is an in-between approach that combines the advantages of these
models.
13
Incremental delivery (Cont’d)
• Rather than deliver the system in a single shot, 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 for this increment are frozen though
requirements for later increments can continue to
evolve.
14
Incremental delivery
Define outline Assign requirements Design system
requirements to increments architecture
Develop system Validate Integrate Validate
increment increment increment system
Final
system
System incomplete
15
Incremental development advantages
• Advantages:
– Customers do not have to wait for the entire system to be
delivered before they can start gaining value from it.
– Customers can start working with early increments as prototypes
and gain experience that informs their requirements for later
system increments.
– Lower risk of overall project failure.
– The highest priority system services tend to receive the most
testing since they are delivered first.
16
Incremental development
disadvantages
• Disadvantages:
– Increments should be relatively small.
• It’s hard to map the customer’s requirements with code of this size.
• It’s hard to identify common facilities that will be needed by all
increments.
17
Process activities
In detail
• Software specification
• Software design and implementation
• Software validation
• Software evolution
18
Software specification
• The process of establishing:
1. what services are required and
2. the constraints on the system’s operation and
development.
• Requirements engineering process is critical
– errors in requirements will lead to later problems in design and
implementation.
19
The requirements engineering process
Discussion with users, Check the
Study if the system is understand the requirements for
You write these in a
feasible or not. Done requirements very well realism, consistency
formal way. You should
be doing this now! and completeness.
Requirements
Feasibility
elicitation and
study
analy sis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements
Requirements
document
20
Software design and implementation
• The process of converting the system specification into an
executable system.
• Software design
– Design a software structure that realises the specification;
• Implementation
– Translate this structure into an executable program;
– Your submission 3.
• The activities of design and implementation are closely
related and may be inter-leaved.
21
b-systems and their
The software design process
lationship. For each sub-
Egs, HR, system, design
Registrar, and document its
Payroll For each sub-system,
give an abstract interface with Allocate services
other subsystems
specification of its to components
services and and design the
constraints. Egs. HR: interface of the
R
equir
ements issue contracts, components
specifica
tion terminate contracts,
manage NSSF
Data
Ar
chitectural Abstract Interface Component Algorithm
structure
design specifica
tion design design design
design
Design activities
Data
y
Sstem Software Interface Component Algorithm
structure
ar
chitecture specifica
tion specifica
tion specifica
tion specifica
tion
specifica
tion
The last two phases
may be delayed to the
implementation phase. 22
Structured methods for design
• There are systematic approaches to developing a software design.
• UML (Unified Modeling Language) is a structured method that
supports object-oriented design.
• A structured method includes:
– notations to represent the design,
– report formats,
– rules and design guidelines.
• The design is usually documented as a set of graphical models.
23
Structured methods for design
Five Possible models:
– Object model;
• shows the object classes used in the system and their dependencies
– Sequence model;
• shows how objects in the system interact when the system is
executing
– State transition model;
• shows system states and the triggers for the transition from one state
to another
– Structural model;
• where the system components and their aggregations are documented
– Data-flow model.
• the system is modelled using the data transformations that take place
as it is processed. Not used in object-oriented methods.
24
Programming and debugging
• Translating a design into a program and
removing errors from that program.
• Programming is a personal activity - there is
no generic programming process.
• Programmers carry out some program
testing to discover faults in the program and
remove these faults in the debugging
process.
25
The debugging process
Locate Design Repair Re-test
error error repair error program
26
Software validation
• Verification and validation (V & V) is
intended to show that:
1. a system conforms to its specification and
2. meets the requirements of the system customer.
• System testing involves executing the system
with test cases that are derived from the
specification of the real data to be processed
by the system.
27
The testing process
Testing with customer data
to check that the system
meets the customer’s needs.
Component System Acceptance
testing testing testing
Testing of the system as a whole.
Individual components are
Testing of emergent properties is
tested independently;
particularly important (test for
Components may be
reliability, size, etc.).
functions or objects or
coherent groupings of
these entities.
28
Software evolution
• Software is inherently flexible and can change.
– Business circumstances might change. Hence, business
requirements change and the software that supports the
business must also evolve and change.
• As already clarified, evolution consumes more
time and money than development itself.
• Evolving the system is a process in its own right.
29
System evolution
Define system Assess existing Propose system Modify
requirements systems changes systems
Existing New
systems system
30
Computer-aided software engineering
• Computer-aided software engineering (CASE) is
software to support software development and evolution
processes.
• Activity automation
– Graphical editors for system model development;
– Data dictionary to manage design entities;
– Graphical UI builder for user interface construction;
– Debuggers to support program fault finding;
– Automated translators to generate new versions of a
program.
31
Case technology
• Case technology has led to significant
improvements in the software process.
– But not as much as it was hoped
• Software engineering requires creative thought - this is
not readily automated;
• Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support these.
32
Next
• Finish the user and requirements
specification
• Make sure you have all required CASE
tools
33
