F28SD2 Software Design
L01. Overview of Software Processes
Monica Farrow firstname.lastname@example.org
Modified by Lu Fan L.Fan@hw.ac.uk
Introduction to the module
Lu Fan (Tue) Andrew Ireland (Wed)
Intro to Software Processes Architectural Design
UML – Use Case & Activity Function-oriented Design
UML – State Machine Object-oriented Design
UML – Class & Interaction Component-based Design
Design Patterns Verification & Validation
(IS) Feasibility Studies Testing & Analysis (CS)
Revision & looking ahead
Not very long ago in the history…
The 1940s – modern computers appeared
The 1950s – programming languages appeared
The 1960s – software crisis!
As a result of “chaotic software development process”
Projects ran over-time/budget
Software was inefficient/not able to meet requirements/never delivered
Codes were unmanageable/difficult to maintain
Firstly proposed in 1968, NATO Software Engineering Conference
Cost-effective development of high-quality software systems
Frederick Phillips Brooks, Jr.
“The Mythical Man-Month”
Essays on software engineering, published in 1975
Many important ideas, including:
Adding manpower to a late software project makes it later
The second-system effect
Advocacy of prototyping
“No Silver Bullet”
Essence and accidents of software engineering, published in 1986
Many important arguments, including:
Essential complexity – caused by the problem to be solved – cannot be removed
Accidental complexity – problems that we create on our own – can be fixed
Much of the accidental complexity has already been cleaned up – no silver bullet
The software process
A structured set of activities required to develop a software
system – Sommerville
Specification Design Validation Evolution
A framework for the tasks that are required to build high-
quality software – Pressman
A process defines who is doing what, when and how to reach a
certain goal – Jacobson, Booch, Rumbaugh
Several models for such processes, e.g. waterfall, spiral, agile
and extreme programming
A.k.a. software lifecycle models, software development methodologies…
Waterfall process model
A sequential software development process
Create a team, follow a well-documented process with fixed milestones
Described by Winston Royce in 1970.
1) Collect & document all of
the system requirements
2) Produce a set of design
3) Write code that implements
the pieces specified in the
4) Integrate all of the pieces
and test to make sure the
system satisfies the
5) Package the system & ship
to the customer
For conventional projects, typically:
2% of budget is spent on requirements Design
4% on specification Implementation
1% on planning Maintenance
6% on design
20% on implementation
and 67% on maintenance
including correction of defects Planning
Projects are seldom so clear-cut and linear
It’s usually late in the project before a working version is available for
user to test and criticise.
Misunderstandings are not discovered until nearly complete and the
problems are expensive to fix.
The earlier an issue is identified, the smaller the cost – errors detected in
testing phase may be 50 times more costly to fix than if they were
detected during requirements or design phases.
Most require some iteration
Waterfall is often modified with arrows back to any stage to show this.
Waterfall model with iterations
Requirements Iterative processes
capture Incremental delivery
software Rapid application development
and unit testing
Rework the earlier stages
The development & delivery is broken down into increments, each
delivering part of the required functionality.
User requirements are prioritised & 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.
System functionality is available earlier – accelerated delivery
Early increments help elicit requirements for later increments
The highest priority system services tend to receive the most testing
Lower risk of overall project failure
Progress can be hard to judge & problems hard to find, because there is
no documentation to demonstrate what has been done.
The normal contract may include a specification; without a specification,
different forms of contract have to be used.
Without a specification, what is the system being tested against?
Continual change tends to corrupt software structure, making it more
expensive to change & evolve to meet new requirements.
The spiral model
Analyze a little, design a little, code a little
Defined by Barry Boehm in 1988
Incremental development, delivery, iteration, evaluation & feedback.
The project moves continually from planning of the next increment, to
risk assessment, through implementation and evaluation.
PM can terminate project at any point, while ensuring that the user gains
some benefit from each increment.
Focuses on prototyping and formalises an evolutionary approach to
Requires an explicit risk analysis during each cycle.
User involvement throughout the development process.
Validation and prioritisation of requirements.
Tends to work best for small projects.
simulates some of the features of the eventual program
may be completely different from the eventual implementation
enables software engineers to understand the problem domain and the
allows users to provide better & more complete feedbacks
Throwaway prototyping – the model will eventually be discarded
Evolutionary prototyping – constantly refine a functional model
Incremental prototyping – merge several prototypes in an overall design
Rapid Application Development (RAD)
RAD was Initiated in the 1990s for projects with a rapidly
changing business environment, where to arrive at a stable,
consistent set of system requirements is often impossible.
In these cases, a waterfall model of development is impractical.
An approach to development based on iterative specification
and delivery is the only way to deliver software quickly.
Concurrent specification, design & implementation
Minimal planning, specification & documentation
End users evaluate each increment & make proposals for later increments
Dissatisfaction with the overheads involved in design methods
led to the creation of ‘agile’ methods
Agile manifesto www.agilemanifesto.org
Individuals and interactions rather than processes and tools
Software development rather than exhaustive documentation
Working with the customer rather than contract negotiation
Openness to change rather than following inflexible plans
Agile methods are probably best suited to small/medium-sized
business systems or PC products.
Individuals & interactions
In the development world, people are more valuable than computer tools
Face-to-face conversation is the most efficient form of communication
Deliver software often (weekly)
Working software is the primary measure of progress
Customer needs come first
Feedback from customer rather than planning
Responding to change
Even late changes in requirements are welcomed
Extreme Programming (XP)
One of the best known agile methods
Small team (2 to 12)
Continuous access to customers – needs an “on-site customer”
OO design and code – Smalltalk, Java
Change management system – code and tests
The system is always “working” (growing functionality over time)
Development cycle – 4 to 12 months (new release every 2-3 months,
internal iterations every two weeks)
Not for life-critical systems (heart monitor, nuclear power plant,
avionics systems, etc.)
Extreme Programming (XP)
Do project planning via “user stories” – interview the customer
Start each day with a “stand-up meeting” – choose task & partner for the day
Keep the design simple – use the simplest thing that could work
Code refactor as needed
Pair programming – all code is reviewed as it is written
Code unit tests first – test-driven development
Unit tests for all code
Acceptance tests for each user story
Agile vs. XP
Agile is a generalisation of XP, featuring
Small team sizes
Short development iterations – release at regular intervals
Continuous testing, e.g. daily regression tests
Collecting customer requirements using scenarios
Informal modeling techniques, e.g. CRC cards, simple drawings
Adaptive planning based on reprioritisation by the customers
XP is a radical agile method, requiring
On-site customer & planning by user stories
Unit tests for everything
Existing processes can be adapted to be more “agile”
Key points so far
Software processes are the activities involved in producing and
evolving a software system.
specification, design, implementation, validation and evolution.
Waterfall model describes the software development as a
Iterative models describe the software development as a cycle
RAD, including Agile & XP, have concurrent specification,
design and implementation.
There is no ideal process model
Largest software vendors, e.g. Microsoft & IBM, still primarily rely on
traditional waterfall methodologies with some degree of spiraling.
Information systems lifecycle
Software lifecycle models
concentrate on design & implementation of a software system
lack an overall picture of the organisation and its business processes
Information systems lifecycle models extend software
lifecycle models by adding
Review during maintenance
System is an open one
Operation feeds back to design
Problems with New business Information Systems
existing system opportunities IS
planning Development Lifecycle
Managerial David Avison & Hanifa Shah
directive Feasibility Feasibility
study study report 1997
Systems User Project Resource Staff Methods
investigation requirements plans requirements assignment and tools
Systems New system System Training and
design data flow specification test plans
Implementation Programs Procedures Documentation
Review Evaluation New problem in operation
maintenance report statement?
Andrew on Wednesdays
No tutorial on this Friday
3 Tuesday lectures on UML
Use cases & activity diagrams
State machine diagrams
Class & interaction diagrams