Software Development Phases and Process - PowerPoint PPT Presentation

1 / 28
About This Presentation
Title:

Software Development Phases and Process

Description:

(In case you are wondering why testing is not in the list we'll come back to that. ... Process (life-cycle) models can help understand and manage the process ... – PowerPoint PPT presentation

Number of Views:21
Avg rating:3.0/5.0
Slides: 29
Provided by: drkeit9
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com