Software Engineering

Lecture 2
Software Lifecycle Models

Reading:
Ian Summerville, Software Engineering (Chapter 2) Must
Read
 Lecture outline
• Software process
• The software lifecycle
– evaluating models

• Lifecycle models
– code-and-fix
– waterfall
– spiral
– evolutionary prototyping
– staged delivery
– design-to-schedule

2
• A software process is a set of related activities that
leads to the production of a software product.
• There are many different software processes but all
must include four activities that are fundamental to
software engineering:
1. Software specification: The functionality of the
software and constraints on its operation must be
defined.
2. Software design and implementation: The
software to meet the specification must be produced.
3. Software validation: The software must be
validated to ensure that it does what the customer
wants.
4. Software evolution: The software must evolve to 3
Verification: are we building the product right?
Validation: are we building the right product?

4
 software engineering
objectives
1. optimality

Optimality means that the process should be able to

produce high-quality software at low cost

2. scalability.

It should also be applicable for large software projects.

5
 Software process xics
• Functionality: the degree of performance of the
software against its intended purpose.
Required functions are:
 suitability
Accuracy
Interoperability
Compliance
Security

6
• Reliability:
A set of attributes that bears on the capability of
software to maintain its level of performance under the
given condition for a stated period of time.
Required functions are
 recoverability
Fault tolerance
maturity

7
• Efficiency:
It refers to the ability of the software to use system
resources in the most effective and efficient manner.
• The software should make effective use of storage
space and executive command as per desired timing
requirements.
Required functions are:
efficiency In time
In resource
8
• Usability: to the extent to which the software can be
used with ease.
• The amount of effort or time required to learn how to
use the software.
Required functions are:
Understandability
Learnability
Operability

9
• Maintainability:
It refers to the ease with which the modifications can
be made in a software system to extend its
functionality, improve its performance, or correct
errors.
• Required functions are:
Testability
Stability
Changeability
10
• Portability:
A set of attributes that bears on the ability of software
to be transferred from one environment to another,
without or minimum changes.
Required functions are:
Adaptability
Install ability
Replace ability

11
 Big questions
• What is a software lifecycle model? When and why
should we use such models?

• Briefly describe each of these models:

– code-and-fix, waterfall, spiral, evolutionary prototyping,
staged delivery, design-to-schedule

• How do we decide which model is the best one to use?

• What are some benefits and drawbacks of each model?

12
 The "Software Lifecycle"
• software lifecycle: The entire process of creating a
software product from an initial concept until the last
user stops using it.
– often divided into "phases":
• Requirements – what does the customer want
• Design – Describe how a solution that meets the
requirements
• Implementation – Convert the design (description) into code
• Testing – Make sure the code meets the requirements
• Maintenance – Fix problems while operating
• other possibilities: Risk Assessment, Prototyping

– goals of each phase:

• mark out a clear set of steps to perform
• produce a tangible document or item
• allow for review of work
• specify actions to perform in the next phase 13
 Software is complex
• Measures of complexity:
– lines of code
– number of classes
– number of modules
– module interconnections and dependencies
– time to understand
– # of authors

– … many more

14
 Life without software
process
• Advantages:
– nothing to learn or plan!
– work on whatever is interesting, ignore
the rest.

• Disadvantages:
– may ignore some important tasks (testing, design)
– not clear when to start or stop doing each task
– scales poorly to multiple people
– hard to review or evaluate one's work
– code may not match user's needs (no requirements!)
– code was not planned for modification, not flexible

15
 Software process models

• Linear: sequential model

• Prototyping model: identify whatever requirements are
known, and outline areas where further definition is
mandatory. A "quick design" then occurs.
• Rapid application development (RAD): an incremental
software development process model that emphasizes
an extremely short development cycle. “high-speed”
adaptation of the linear sequential model
• Evolutionary : develop increasingly more complete
versions of the software. 16
 Some lifecycle models
• code-and-fix: write some code, fix it when it breaks

• waterfall: standard phases (req., design, code, test) in

order

• spiral: assess risks at each step; do most critical action

first

• evolutionary prototyping: build an initial small

requirement spec, code it, then "evolve" the spec and
code as needed

• staged delivery: build initial requirement specs for

several releases, then design-and-code each in
sequence 17
 Ad-hoc development
• ad-hoc development: no formal process (aka "code
and fix")
– Sounds great! No learning required.
– Applicable for very small projects and short-lived
prototypes

• Drawbacks?
– No way to asses progress, quality, or risks
– Unlikely to accommodate changes without a major design
Examine
– Unclear delivery features (scope),
timing, and support

18
 Waterfall
• The first published model of the software development
process
• derived from more general engineering processes
• Perform each phase in order

19
1. Requirements analysis and definition
• The system’s services, constraints, and goals are
established by consultation with system users.
• They are then defined in detail and serve as a system
specification.
2. System and software design
• The systems design process allocates the requirements
to either hardware or software systems by establishing
an overall system architecture.
20
3. Implementation and unit testing
• During this stage, the software design is realized as a
set of programs or program units.
• Unit testing involves verifying that each unit meets its
specification.
4. Integration and system testing
• The individual program units or programs are
integrated and tested as a complete system to
ensure that the software requirements have been
met. 21
5. Operation and maintenance
• involves correcting errors which were not discovered in
earlier
stages of the life cycle.
In waterfall
• The following phase should not start until the previous
phase has finished.
• In practice, these stages overlap and feed information
to each other.
• During design, problems with requirements are
identified. During coding, design problems are found
and so on. 22
 Waterfall model
advantages
• Suitable for projects that are very well understood but
complex
– Tackles all planning upfront
– The ideal of no midstream changes equates to an efficient
software development process

• Supports inexperienced teams

– Orderly, easy-to-follow sequential model
– Reviews at each stage determine if the product is ready
to advance

23
 Drawbacks of waterfall
req. change
requirements
verify
design
verify
implement
test

operations
• drawbacks?
retirement
– assumes requirements will be clear and well-understood
• requires a lot of planning up front (not always easy)
– rigid, linear; not adaptable to change in the product
• costly to go back to a previous phase
– nothing to show until almost done

24
 Spiral
Barry Boehm, USC
• steps taken at each loop:
– determine objectives
and constraints
– identify risks
– evaluate options to
resolve risks
– develop and verify
deliverables

• benefits?
– provides early indication of unforeseen problems
– always addresses the biggest risk first
– accommodates changes, growth
– eliminates errors and unattractive choices early
25
 Drawbacks of spiral
Barry Boehm, USC
• steps taken at each loop:
– determine objectives
and constraints
– identify risks
– evaluate options to
resolve risks
– develop and verify
deliverables
• drawbacks?
– relies on developers to have risk-assessment expertise
– perhaps over-focuses on risk and "putting out fires"; other
features may go ignored because they are not "risky"
enough
– complex; how do you actually follow this?
26
–
 comparison

Waterfall model Spiral model

• Risk factors are not • Risk factors are
considered considered
• The requirements are • Requirements are not
freeze freeze
• Is linear sequential • Works in loop
• Not much costly • Costly as risk factor is
• Communication level is covered
not high • Better Communication

27
 Evolutionary prototyping
• Develop a skeleton system and evolve it for delivery

Refine
Design and
Initial concept prototype until Complete and
implement
acceptable release
initial
prototype prototype

• build initial requirements, design/code it, "evolve" as

needed

28
 Evolutionary prototyping
for each build:
requirements arch. design operations
detailed design,
implement,
verify verify test, deliver
retirement

• build initial requirements, design/code it, "evolve" as

needed

• benefits?
– produces steady signs of progress, builds customer
confidence
– useful when requirements are not well known or change
rapidly
– customer involvement ("What do you think of this
version?") 29
 Drawbacks of
evolutionary
for each build:
requirements arch. design operations
detailed design,
implement,
verify verify test, deliver
retirement

• drawbacks?
– assumes user's initial spec will be flexible
– Problems with planning
• unclear how much iteration/time will be needed to finish
• feature creep
– fails for separate pieces that must then be integrated
– temporary fixes become permanent constraints

30
 Staged delivery
waterfall-like beginnings, then
Requirements develop in short stages
plan, design, execute, test, release
– can ship at any time at the end of
any cycle
Design

Stage 1: detailed design, code, test, deliver

Stage n: detailed design, code, test, deliver

31
 Staged delivery model
advantages
• Can ship at the end of any release cycle
– Looks like success to customers, even if not original goal

• Intermediate deliveries show progress, satisfy

customers, and lead to feedback

• Problems are visible early (e.g., integration)

• Facilitates shorter, more predictable release cycles

Very practical, widely used and

successful
32
 Staged delivery model
disadvantages
• Disadvantages
– Requires tight coordination with documentation,
management, marketing
– Product must be decomposable
– Extra releases cause overhead

• How does staged delivery differ from evolutionary

prototyping?
– In staged delivery, requirements are better known ahead
of time rather than discovered by customer feedback on
each release.

33
 Embracing or fighting
timelines
• Fit-to-schedule
– “We will ship on a certain date and cut until it fits”
– useful when you absolutely need to ship by a certain date
– similar to the staged delivery model
• but less flexible because of the fixed shipping date
– requires careful prioritization of features and risks to
address
– not recommended

• Fit-to-features/quality
– “We’ll ship the product when it is ready”
– Trade predictable schedules for quality control

34
 Why are there so many
models?
• The choice of a model depends on the project
circumstances and requirements.

• A good choice of a model can result in a vastly more

productive environment than a bad choice.

• A cocktail of models is frequently used in practice to

get the best of all worlds. Models are often combined or
tailored to environment

35
 What’s the best model?
• Consider
– The task at hand
– Risk management
– Quality / cost control
– Predictability
– Visibility of progress
– Customer involvement and feedback

Aim for good, fast, and cheap.

But you can’t have all three at the same
time.
REMEMBER THE TERRIBLE TRIANGLE
36
 Model category matrix
• Rate each model 1-5 in each of the categories shown:
Risk Quality/ Predict- Visibility Customer
mgmt. cost ctrl. ability of progress involvemen
t
code-and-fix
1 1 1 3 1
waterfall
3 4 4 1 2
spiral
5 5 3 3 3
evolutionary
prototyping 3 3 2 5 5
staged delivery
4 5 4 4 4
design-to-
schedule 4 3 5 3 2
37
 Other Models
• Rapid application development (RAD) Model
– incremental software development process model
– emphasizes an extremely short development cycle
– achieved by using component-based construction
• Piece together already existing components to create what
you need
• The Formal-methods model
– formal mathematical specification of computer software
– specify, develop, and verify systems by a rigorous,
mathematical notation
– SE M.Sc. And PhD researches focus here
• Agile Model (Covered in another class)

38
 Software process metrics
Software Measurement Size-Oriented Metrics(PL
dependent)
• Errors per KLOC (thousand lines of code).
• Defects per KLOC.
• per LOC.
• Page of documentation per KLOC.
In addition, other interesting metrics can be
computed
• Errors per person-month.
• LOC per person-month.
• per page of documentation.

39
Function oriented metrics(programming language
independent)
• Does the system require reliable backup and recovery?
• number of user inputs
• number of user outputs
• Measures of errors uncovered before release
• Defects delivered to and reported by end users

40