1. The Software Life Cycle

2. Outline
Review
Life cycle models
Improving the SE process

3. Review What is the software process?
the activities, techniques, tools, and individuals to produce software
Documentation important for each phase. Why?
people & products change
Testing is essential throughout life cycle
traceability?
tying a piece of doc/design back to previous doc
Why are there no “silver bullets”?
software is inherently hard because of complexity, conformity, changeability, invisibility

4. Software Life-Cycle Model
Definition
The series of steps through which the product progresses
The models specifies
the various phases of the process
e.g., requirements, specification, design…
the order in which they are carried out

5. Importance of Lifecycle Models
Provide guidance for project management
what major tasks should be tackled next? milestones!
what kind of progress has been made?
The necessity of lifecycle models
character of software development has changed
early days: programmers were the primary users
modest designs; potential of software unknown
more complex systems attempted
more features, more sophistication  greater complexity, more chances for error
heterogeneous users

6. Lifecycle Models Build-and-fix Why doesn’t build-and-fix scale?
develop system
without specs or design
modify until customer is satisfied
Why doesn’t build-and-fix scale?
changes during maintenance
most expensive!

7. Software Lifecycle Models
A software lifecycle model is a standardised
format for
planning
organising, and
Running a new development project.

8. Hundreds of different kinds of models are
known and used.
Many are minor variations on just a small
number of basic models. In this section we:
survey the main types of model, and
consider how to choose between them.

9. Planning with Models
SE projects usually live with a fixed financial budget. (An exception is maintainance?)
Additionally, time-to-market places a strong
time constraint.
There will be other project constraints such
as staff.

10. Examples of Project Constraints
designers
programmers
managers
money
staff
Project constraints
Computing
resources
time
Examples of Project Constraints

11. Project planning is the art of scheduling the
necessary activities, in time, space and across staff in order to optimise:
project risk [low] (see later)
profit [high]
customer satisfaction [high]
worker satisfaction [high]
long-term company goals

12. Questions:
1. What are these necessary activities?
(besides programming)
2. Are there good patterns of organisation
that we could copy?

13. A project plan contains much information,
but must at least describe:
resources needed
(people, money, equipment, etc)
dependency & timing of work
(flow graph, work packages)
rate of delivery (reports, code, etc)
It is impossible to measure rate of progress
except with reference to a plan.

14. In addition to project members, the following
may need access to parts of the project plan:
Management,
Customers
Subcontractors
Suppliers
Investors
Banks

15. Project Visibility Unlike other engineers
(e.g. civil, electronic, chemical … etc.)
software engineers do not produce anything
physical.
It is inherently difficult to monitor an SE
project due to lack of visibility.

16. additional deliverables (artifacts)
This means that SE projects must produce
additional deliverables (artifacts)
which are visible, such as:
Design documents/ prototypes
Reports
Project/status meetings
Client surveys (e.g. satisfaction level)

17. What is a Lifecycle Model?
Definition.
A (software/system) lifecycle model is a
description of the sequence of activities
carried out in an SE project, and the relative
order of these activities.

18. It provides a fixed generic framework that
can be tailored to a specific project.
Project specific parameters will include:
Size, (person-years)
Budget,
Duration.
project plan = lifecycle model + project parameters

19. There are hundreds of different lifecycle models
to choose from, e.g:
waterfall,
code-and-fix
spiral
rapid prototyping
unified process (UP)
agile methods, extreme programming (XP)
COTS …
but many are minor variations on a smaller
number of basic models.

20. By changing the lifecycle model, we can
improve and/or tradeoff:
Development speed (time to market)
Product quality
Project visibility
Administrative overhead
Risk exposure
Customer relations, etc, etc.

21. Normally, a lifecycle model covers the entire
lifetime of a product.
From birth of a commercial idea
to final de-installation of last release
i.e. The three main phases:
design,
build,
maintain.

22. Note that we can sometimes combine
lifecycle models,
e.g. waterfall inside evolutionary – onboard shuttle software
We can also change lifecycle model between
releases as a product matures,
e.g. rapid prototyping  waterfall

23. Code-and-Fix This model starts with an informal general
product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order.
Corresponds with no plan! (Hacking!)

24. Code-and-Fix Model The easiest way to develop software
No design
No specifications
Maintenance nightmare
The easiest way to develop software
The most expensive way

25. Advantages No administrative overhead Signs of progress (code) early.
Low expertise, anyone can use it!
Useful for small “proof of concept” projects, e.g. as part of risk reduction.

26. Disadvantages Dangerous! 2. Impossible for large projects,
No visibility/control
No resource planning
No deadlines
Mistakes hard to detect/correct
2. Impossible for large projects,
communication breakdown, chaos.

27. Lifecycle Models Staged models successive stages of development
e.g., waterfall model
Requirements
Phase
Specification
Design
Implementation
& Integration
Description
Design Docs
Product
(What needs to be done)
(How to do)

28. Lifecycle Models Rapid prototyping
build something users can understand & assess
often focuses on the interface
waterfall model follows the prototype
Incremental (aka Evolutionary) development
incrementally expand the system
can be used to do a “phased delivery” to users
more expectation management needed!
build-and-fix revisited?

29. Waterfall Model Verify Flaw? Design Phase output of stages
Feasibility Study
Phase
Requirements
Analysis &
Specification Phase
Design
Phase
Verify
output of stages
The major flaw with the original model is that it didn’t support iteration…
what if there was an incompleteness, contradiction, or ambiguity in the specification?
Implementation
& Unit testing
Phase
Flaw?
original model didn’t
let you go back!
Integration
& System
testing
Maintenance

30. Advantages of Waterfall Model
Enforced discipline through documents
no phase is complete until the docs are done & checked by SQA group
concrete evidence of progress
makes which costly phase easier?
Testing is inherent in every phase
continuously as well as at end of phases

31. Advantages Easy to understand and implement.
Widely used and known (in theory!)
Reinforces good habits: define-before- design, design-before-code
Identifies deliverables and milestones
Document driven, SRS … etc..
Works well on mature products and weak teams.

32. Disadvantages I Idealised, doesn’t match reality well.
Doesn’t reflect iterative nature of exploratory development.
Unrealistic to expect accurate requirements so early in project
Software is delivered late in project, delays discovery of serious errors.

33. Disadvantages II 5. Difficult to integrate risk management
Difficult and expensive to make changes
to documents, ”swimming upstream”.
Significant administrative overhead,
costly for small teams and projects.

34. Drawbacks of Waterfall Model
Document-driven model
customers cannot understand these
imagine an architect just showing you a textual spec!
first time client sees a working product is after it has been coded. Problem here?
leads to products that don’t meet customers needs
Assumes feasibility before implementation
re-design is problematic
works best when you know what you’re doing
when requirements are stable & problem is well-known

35. Rapid Prototyping Rapid prototyping as a requirements tool
allow users to “see” & use proposed solutions
develop specification from the prototype/requirements
proceed with rest of stages in waterfall model
Prototype must be constructed & changed quickly
do not spend a lot of time perfecting the code/structure
plan to throw it away! because you will!
put in front of customer ASAP
user interface prototyping & other rapid dev tools make this easier

36. Rapid Prototyping Model
Linear model
“Rapid”
Figure 2.9

37. Rapid Prototyping Key idea: Customers are non-technical and
usually don’t know what they want/can have.
Rapid prototyping emphasises requirements
analysis and validation, also called:
customer oriented development,
evolutionary prototyping

38. The Rapid Prototype Workflow Requirements Capture Iterate Quick Design
Build Prototype
Customer Evaluation of
Prototype
The Rapid
Prototype Workflow
Engineer Final
Product

39. Advantages Reduces risk of incorrect user requirements
Good where requirements are changing/uncommitted
Regular visible progress aids management
Supports early product marketing

40. Disadvantages I
An unstable/badly implemented prototype often becomes the final product.
Requires extensive customer collaboration
Costs customers money
Needs committed customers
Difficult to finish if customer withdraws
May be too customer specific, no broad market

41. Disadvantages II 3. Difficult to know how long project will last
4. Easy to fall back into code-and-fix without proper requirements analysis, design, customer evaluation and feedback.

42. Assessment of RP Model Advantages ? Disadvantages
process proceeds linearly (less need for feedback loops)
easier to take technology risks with the prototype
Disadvantages
expectation management
delivering “everything” properly takes time
turning prototypes into production code
quite controversial...
will turn into build-and-fix

43. Incremental Model Divide project into builds Advantages ?
Verify
Requirements
phase
Specification
Architectural
design
Operations mode
Development
Maintenance
Retirement
Perform detailed
design, imple-
mentation, and
integration. Test.
Deliver to client.
For each build:
Divide project into builds
each adds new functions
each build integrated w/ structure & product tested as a whole
Advantages ?
operation product in weeks
less traumatic to organization
smaller capital outlay
Disadvantages ?
need an open architecture
a big advantage come maintenance!
too few builds  build-and-fix
too many builds  overhead

44. Other Incremental Models
Advantages ?
more parallelism saves lots of time!
Risks ?
no overall design at start  pieces might not fit together

45. Synchronize & Stabilize Model (Microsoft)
Requirements analysis
interview potential customers
Draw up overall product specifications
Divide project into 3 or 4 builds
each adds new functionality (1st gives base)
each build carried out by small parallel teams
At the end of day – synchronize (test & debug)
At end of build – stabilize (fix & freeze build)
Who has worked for MS?

46. Lifecycle Models Spiral Model OO Models risk-driven approach
assess risks before each phase
what is the difficulty here?
re-assess in frequent cycles
OO Models
more interaction between phases
more iteration within phases
assessing risk takes skill and lots of things can’t easily be accessed
costs of assessing risk may be higher than development

47. Spiral Model Always some risk involved in software development
people leave… other products not delivered on time…
Key idea
minimize risk
e.g., building prototypes & simulations minimizes risks
Precede each phase by
looking at alternatives
risk analysis
Follow each phase by
evaluation
planning of next phase

48. Spiral Model Since end-user requirements are hard to
obtain/define, it is natural to develop software
in an experimental way: e.g.
Build some software
See if it meets customer requirements
If no goto 1 else stop.

49. iterative lifecycle models.
This loop approach gives rise to structured
iterative lifecycle models.
In 1988 Boehm developed the spiral model as an iterative model which includes risk
analysis and risk management.
Key idea: on each iteration identify and solve the sub-problems with the highest risk.

50. Each cycle follows a waterfall model by:
Determining objectives
Specifying constraints
Generating alternatives
Identifying risks
Resolving risks
Developing next-level product
Planning next cycle

51. Spiral Model

52. Risk Assessment Risk-driven approach; in each spiral:
identify potential risks
plan next step based on risk analysis
refine design in highest-risk areas
Explicitly attempts to identify potential problems
not just in initial stages of design
also later, when more has been learned about the problem and the design
What are the “risky” parts of the system
relies on developer experience

53. Spiral Model

54. Assessing the Spiral Model
Risk assessment
how does one do it?
how is it known that “proper” risks have been identified?
“experience” is a critical factor
what if a new software system is being attempted?
model fails if risks are inaccurately assessed
Not clear it works for contract projects
how do you cancel a contract in the middle?
Mainly for very large projects
risk assessment could cost more than development!

55. Advantages
Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements
Flexible: incoporates the advantages of the waterfal and rapid prototyping methods
Comprehensive model decreases risk
Good project visibility.

56. Disadvantages
Needs technical expertise in risk analysis to really work
Model is poorly understood by non-technical management, hence not so widely used
Complicated model, needs competent professional management. High administrative overhead.

57. Extreme Programming and Agile Processes
Somewhat controversial new approach
Stories (features client wants)
Estimate duration and cost of each story
Select stories for next build
Each build is divided into tasks
Test cases for a task are drawn up first
Pair programming
Continuous integration of tasks

58. Unusual Features of XP
The computers are put in the center of a large room lined with cubicles
A client representative is always present
Software professionals cannot work overtime for 2 successive weeks
No specialization
Refactoring (design modification)

59. Agile Processes A collection of new paradigms characterized by
Less emphasis on analysis and design
Earlier implementation (working software is considered more important than documentation)
Responsiveness to change
Close collaboration with the client

60. Evaluating Agile Processes and XP
XP has had some successes with small-scale software development
However, medium- and large-scale software development is very different
The key decider: the impact of agile processes on postdelivery maintenance
Refactoring is an essential component of agile processes
Refactoring continues during maintenance
Will refactoring increase the cost of post-delivery maintenance, as indicated by preliminary research?

61. Evaluating Agile Processes and XP (contd)
Agile processes are good when requirements are vague or changing
It is too soon to evaluate agile processes
There are not enough data yet
Even if agile processes prove to be disappointing
Some features (such as pair programming) may be adopted as mainstream software engineering practices

62. Synchronize-and Stabilize Model
Microsoft’s life-cycle model
Requirements analysis — interview potential customers
Draw up specifications
Divide project into 3 or 4 builds
Each build is carried out by small teams working in parallel

63. Synchronize-and Stabilize Model (contd)
At the end of the day — synchronize (test and debug)
At the end of the build — stabilize (freeze the build)
Components always work together
Get early insights into the operation of the product

64. Comparison of Life cycle models
Classical waterfall model is the basic. However, it cannot be used in practical development projects– no method to handle error
Iterative model overcomes this problem. Simple to use and understandable. However, it is suitable for well-understood problems and is unsuitable for large projects and projects subject to many risks.
Prototyping model suitable for projects where user requirements or the underlying technical aspects are not well-understood. Popular for user-interface part of the projects
Evolutionary model suitable for large projects which can be decomposed into modules for incremental development and delivery. Also widely used for OO development projects.
Spiral model also called meta model since it encompasses all other life cycle models. Risk handling is inherently built into it. Suitable for technically challenging s/w projects that are prone to several kinds of risks. However, it is more complex.

65. Comparison of Life-Cycle Models
Different life-cycle models have been presented
Each with its own strengths and weaknesses
Criteria for deciding on a model include:
The organization
Its management
The skills of the employees
The nature of the product
Best suggestion
“Mix-and-match” life-cycle model

66. Comparison of Life-Cycle Models (contd)

67. Perils & Promises of Lifecycles
Managers love ‘em
defines a set of “deliverables”
sound bites – can tell upper management that “stage so-and-so is completed”
formally mandated by many government agencies
Programmers find them inadequate
not representative of what happens in the “trenches”
customers can’t adequately state requirements up-front
stages become intermixed w/ others
e.g., design reveals that part of specification can’t be cost-effectively implemented

68. Next Time
Questions?
Next lecture on The Software Project Management