Software Development Phases and Process

1
Software Development Phases and Process

• In essence, it is just like making anything else,
  and very simple.
• 1. Decide what you are going to build.
• 2. Work out how to build it.
• 3. Build it.
• The commonest mistake is (almost incredibly) to
  start with 3 !
• (In case you are wondering why testing is not in
  the list well come back to that.)

2
Software Development Phases and Process

• The starting point is (usually) a problem. eg. -
• We could use a more efficient way of drawing and
  storing architectural plans
• The race officers keep making mistakes when
  working out race results
• We need an on-line catalogue to expand sales
• We are wasting fuel by not controlling the
  heating system very effectively

3
Well-defined problems

• These problems are ill-formed - they are poorly
  defined and a solution cannot be unambiguously
  recognised.
• The first step is to convert the problem to a
  well-defined problem.
• We can then devise and build a solution (and test
  that we have succeeded)

4
The Basic Steps
5
Steps and Units

• We give the development steps fancy names and
  they correspond to some unit titles-
• 1 Requirements Engineering (RE - yr2)
• 2 Software Design (SDT etc.)
• 3 Programming (P etc.)
• We teach steps 2 and 3 in parallel and before
  step 1
• Other units in year 2 4 extend steps 2 3
• This year (only !) we mostly do step 1 for you.
  For each exercise, we provide the relevant output
  from step 1 a well defined problem, aka a
  specification

6
Development Process Models

• Computer Scientists and Software Engineers like
  to develop models of the development process
  why?
• To understand and, ultimately, control and
  optimise, the process.
• And, hence, improve quality and productivity
  (i.e., profitability).
• Process Modelling is a discipline in its own
  right.

7
Pragmatic Modelling Goals

• To define the activities to be performed
• To identify the outputs (deliverables) that must
  be produced
• To provide checkpoints for project management
• To introduce consistency across and repeatability
  within the organisation

8
History (Models of the Software Development
Process)

• Lifecycle Models
• Process modelling developments
• Related areas of work. E.g., CMM
• IPSEs and other tools
• The move towards modelling business processes
  (and why)

9
Lifecycles

• Process as phases or chunks of different
  activity types
• (earliest Bennington, 9 phases, 1956).
• Waterfall model (Royce 1970) is perhaps the best
  known of all the lifecycle models
• Sommerville uses a waterfall model which consists
  of five distinct stages.
• (Software Engineering Third edition).

10
Waterfall Model
11
Advantages and Disadvantages

• Simplicity.
• Conveys major software engineering activities to
  the uninitiated
• Clear high level view of the process
• Provides crude milestones

• Does not accommodate-
• Iteration
• Concurrency
• Levels of detail or abstraction
• Deliverables
• Ongoing validation
• Feasibility determination

12
Life-cycle models might include..

• Basic stages (reminder)
• 1 Requirements engineering.
• 2 Design.
• 3 Implementation.
• Usually fleshed out in more detail (next slide).

13
General Life-cycle tasks

• Strategic planning, bright idea
• Preliminary investigation of problem area
• Requirements Engineering
• Discover requirements
• (Requirements Elicitation)
• Analyse requirements
• (Systems Analysis)
• Determine feasibility
• Specify the Required System
• (Specification)

• Design
• High level design (HLL)
• Low level design (LLD)
• Implementation
• Coding
• Integration
• System testing
• Installation (hand-over / commissioning)
• Maintenance
• De-commission (scrap)

14
Concurrent activities

• Often omitted from such process models.
• Project management
• Configuration Management
• Quality Assurance
• Feasibility (cost benefit) assessment
• Testing.
• Most of these are covered later, in other units
  (but we introduce QA / testing)

15
Principal Deliverables

• Requirements Engineering
• Analysis/requirements document
• System specification
• Acceptance test plan
• Cost benefit analysis
• Design
• High level design documents
• Low level design documents
• Functional/integration test plan

• Implementation
• Source code
• Integrated/tested system
• User documentation

16
Other Process Models

• Some questions to ask.
• What are the fundamental differences?
• Are the stages and their ordering "real?
• Does it reflect what actually happens?
• Is it applicable to all projects?
• Examples . . . . . .

17
The V life-cycle
REQUIREMENTS SPECIFICATION
EVOLUTION
Initiation
Phaseout
Testedsystem
Specification
Verified System
ARCHITECTURAL DESIGN
SYSTEM INTEGRATION AND TEST
Testedsoftware
Design
Integrated Software
DETAILED SWARE DESIGN
SWARE INTEGRATION AND TEST
Testedsoftwaremodules
Module Designs
Debugged Modules
CODE AND UNIT TEST
18
The Spiral model
Planning
Riskanalysis
Initial requirements gathering and project
planning
Risk analysis based on initial requirements
Risk analysis based on customer reaction
Planning based on customer comments
Go, no go decision
Towards a completed system
Customerevaluation
Initial prototypeNext level prototypeEngineered
system
Customerevaluation
Engineering
19
Agile methods

• Relatively new
• Emphasise
• iteration
• user involvement
• ongoing requirements refinement
• early testing
• multiple, small delivery phases
• early delivery of initial phases
• ongoing re-factoring (re-design)

20
Agile methods Example -
See http//www.extremeprogramming.org/map/project.
html for further details(The jury is still out
on when such approaches are profitable!)
21
Process Maturity

• Software Engineering Institute (SEI) at
  Carnegie Mellon University proposed a Capability
  Maturity Model.
• Categorises (and ranks) an organisation in terms
  of its process capability.
• Later versions move towards profiles rather than
  levels - but the idea of levels has stuck.
• Many similar models (e.g., SPICE in EU).
• CMM hugely influential.

22
CMM Levels
23
Specification

• The specification defines what the new system
  will do (or allow) to produce those effects (the
  behaviour of the new system)
• E.g. - the system will calculate the average
  (mean) of the entered numbers
• the system will take user input from the keyboard
• the user may enter up to 20 numbers
• the result (mean) is calculated to 2 places of
  decimals

24
Specification

• Such behavioural descriptions are sometimes
  called black box models
• They define input, output and the way in which
  they must be related
• They dont tell you what is actually inside the
  black box (the system!)

25
Specification

• As part of specification, it is generally useful
  to define the format of the input and output.
  Eg.-
• Input number up to 5 digits, no fractions
• (OR ddddd)
• Result ddddd.dd
• (there are rather better ways of doing this but
  well come to that later!)

26
Specification

• There are also various techniques for defining
  the required relationships between input and
  output
• We will look at those techniques later, for now
  we will just use text, eg.
• The journey average speed is defined as the
  journey distance divided by the journey time

27
Clear box models

• In the design phase we use clear box (or white
  box) model (opposite of a black box model)
• These show what the system is made of (its
  structure) and how the system works.

28
Summary

• The 3 essential steps are-
• decide upon (specify) what is required
• design a solution
• build that solution
• Process (life-cycle) models can help understand
  and manage the process
• The main input to the design phase is (should
  be!) a behavioural specification (a black box
  description)
• In the design phase we invent (and, using clear
  box models, document) a suitable structure.