S OFTWARE L IFECYCLES
•
•
These notes cannot be used, shared or posted without prior written approval from the author and the University of Texas at
Dallas.
RYM Z WENKSTERN
1
O UTLINE
1. Definitions
2. Traditional Lifecycle Models
3. The Iterative Evolutionary Agile Models
RYM Z WENKSTERN
2
2
1
D EFINITIONS
Lifecycle
The period of time that begins when a software product is
conceived and ends when the software is no longer available for
use. The software lifecycle typically includes a concept phase,
requirements phase, design phase, implementation phase, test
phase, installation and checkout phase, operation and
maintenance phase, and, sometimes, retirement phase.
IEEE Standard Glossary of Software Engineering Terminology

Addresses the What? When? and expected deliverables
RYM Z WENKSTERN
3
3
D EFINITIONS
Software Process
The process by which user needs are translated into a software
product. The process involves translating user needs into
software requirements, transforming the software requirements
into design, implementing the design in code, testing the code,
and sometimes, installing and checking out the software for
operational use.
IEEE Standard Glossary of Software Engineering Terminology
The set of activities, methods, practices, notations and tools that
are used in the production and evolution of software.

Addresses the What? When? Who? How?
RYM Z WENKSTERN
4
4
2
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Phase deliverables

Activities

Phases and Activities

Assessment of the Waterfall Model

Variations on the Waterfall Model

Incremental Model

Spiral Model

Cleanroom model
3. The Iterative Evolutionary Agile Approach
RYM Z WENKSTERN
5
5
W ATERFALL M ODEL

popularized in the 1970s => discussed in every software
engineering textbook and used in standard industrial practices

First appearance: late 1950s result of experience gained on SAGE
(Semi Automated Ground Environment) system
RYM Z WENKSTERN
6
6
3
T HE W ATERFALL M ODEL
Feasibility
System
Feasibility
Analysis
Validation
Plans and
requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Verification
Deployment
System Tes
t
Maintenance
Revalidation
RYM Z WENKSTERN
7
7
W ATERFALL M ODEL : F EASIBILITY A NALYSIS

Three primary areas of interest are considered:

Economic feasibility. An evaluation of development cost
weighed against the ultimate income or benefit derived from
the developed system or product.

Technical feasibility. A study of function, performance, and
constraints that may affect the ability to achieve an acceptable
system.

Legal feasibility. A determination of any infringement, violation,
or liability that could result from development of the system.
RYM Z WENKSTERN
8
8
4
W ATERFALL M ODEL : F EASIBILITY A NALYSIS

Checklist: the more questions elicit a negative response, the
higher the risk that project/ product feasibility is questionable.
Economic feasibility

Have the benefits associated with the product/
system/service been identified explicitly?

Have the benefits been quantified in dollar terms?

Does the configuration represent the most profitable
solution? Can it be marketed successfully? Will ultimate
payoff justify development risk?

What is the risk associated with cost and schedule estimates?
RYM Z WENKSTERN
9
9
W ATERFALL M ODEL : F EASIBILITY A NALYSIS
Technical feasibility












RYM Z WENKSTERN
Are all elements of the system configuration understood?
Can the configuration be built within pre-established cost and schedule
bounds?
Does the technology exist to develop all elements of the system?
Does the system rely on proven technologies?
Are all interfaces clearly defined?
Are function and performance assured?
Can the configuration be adequately maintained?
Do technical resources exist?
What is the risk associated with the technology?
Can quality assurance be adequately performed on all elements of the
system?
Does the proposed configuration properly interface with the system's
external environment?
Are machine to machine and human to machine communication handled
in an intelligent manner?
10
10
5
W ATERFALL M ODEL : F EASIBILITY A NALYSIS
Legal feasibility
 Does this configuration introduce undue liability risk?
 Can proprietary aspects be adequately protected?
 Is there potential infringement?
RYM Z WENKSTERN
11
11
T HE W ATERFALL M ODEL
System
Feasibility
Validation
Plans and
requirements
Validation
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Verification
Deployment
System Test
Maintenance
V&V
RYM Z WENKSTERN
12
12
6
T HE W ATERFALL M ODEL
Lifecycle =What to do When + Expected deliverables
RYM Z WENKSTERN
13
13
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Phase deliverables

Activities

Phases and Activities

Assessment of the Waterfall Model

Variations on the Waterfall Model

Incremental Model

Spiral Model

Cleanroommodel
3. The Iterative Evolutionary Agile Approach
4. Reuse Model
RYM Z WENKSTERN
14
14
7
T HE W ATERFALL M ODEL – P HASE D ELIVERABLES
System
Feasibility
Feasibility Report
Validation
Plans and
requirements
Validation
Requirements Specification
Software Architecture
Product Design
Verification
Data Structures and Algorithms
Detailed Design
Verification
Code (components)
Code
Unit Test
Complete Program
Integration
Verification
Deployment
Tested Complete Program
System Test
Maintenance
Updated Program
V&V
RYM Z WENKSTERN
15
15
T HE W ATERFALL M ODEL – P HASE D ELIVERABLES
Phase
Deliverable
Feasibility
Feasibility report
Requirements
A complete, validated specification of the required
functions, interfaces, and performance for the
software product
Product Design
A complete, verified specification of the overall
hardware-software architecture, control structure,
and data structure for the product, along with such
other necessary components as draft user’s manual
and test plans
Detailed Design
A complete verified specification of the control
structure, data structure, interface relations, sizing,
key algorithms, and assumptions of each program
component
RYM Z WENKSTERN
16
16
8
T HE W ATERFALL M ODEL – P HASE D ELIVERABLES ( CONT ’ D )
Phase
Deliverable
Coding
A complete, verified set of program components
Integration
A properly functioning software product composed
of the software components
Implementation
A fully functioning operational hardware-software
system, including such objectives as program and
data conversion, installation, and training
Maintenance
A fully functioning update of the hardware-software
system
RYM Z WENKSTERN
17
17
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Phase deliverables

Activities

Phases and Activities

Assessment of the Waterfall Model

Variations on the Waterfall Model

Incremental Model

Spiral Model

Cleanroommodel
3. The Iterative Evolutionary Agile Approach
4. Reuse Model
RYM Z WENKSTERN
18
18
9
W ATERFALL -- A CTIVITIES

Activity
A set of related tasks assigned to a team of software engineers
(or an individual) which consumes resources and produces work
products.
RYM Z WENKSTERN
19
19
W ATERFALL -- A CTIVITIES

Eight major project activities:
1. Requirements Analysis
2. Product Design
3. Detailed Design & Programming
4. Test Planning
5. Verification and Validation
6. Project Office Functions
7. Configuration Management and
Quality Assurance
8. Documentation/Manuals
RYM Z WENKSTERN
20
20
10
W ATERFALL – A CTIVITY D EFINITIONS
Activity
Description
Requirements Elicitation, specification, review and update of software
Analysis
requirements
RYM Z WENKSTERN
21
21
W ATERFALL – A CTIVITY D EFINITIONS
Activity
Description
Requirements Elicitation, specification, review and update of software
Analysis
requirements
Product
Design
RYM Z WENKSTERN
22
Definition, review and update of hardware-software
architecture and database design
22
11
W ATERFALL – A CTIVITY D EFINITIONS
Activity
Description
Requirements Elicitation, specification, review and update of software
Analysis
requirements
Product
Design
Definition, review and update of hardware-software
architecture and database design
Detailed
Design &
Programming
Detailed design, code, unit test and integration of individual
program components. Includes tool acquisition, data base
development, and component level documentation
RYM Z WENKSTERN
23
23
W ATERFALL – A CTIVITY D EFINITIONS
Activity
Description
Requirements Elicitation, specification, review and update of software
Analysis
requirements
Product
Design
Definition, review and update of hardware-software
architecture and database design
Detailed
Design &
Programming
Detailed design, code, unit test and integration of individual
program components. Includes tool acquisition, data base
development, and component level documentation
Test Planning
Specification, review and update of test cases and acceptance
test plans. Acquisition of associated test tools and test data
RYM Z WENKSTERN
24
24
12
W ATERFALL – A CTIVITY D EFINITIONS
Activity
Description
Requirements Elicitation, specification, review and update of software
Analysis
requirements
Product
Design
Definition, review and update of hardware-software
architecture and database design
Detailed
Design &
Programming
Detailed design, code, unit test and integration of individual
program components. Includes tool acquisition, data base
development, and component level documentation
Test Planning
Specification, review and update of test cases and acceptance
test plans. Acquisition of associated test tools and test data
V&V
Requirements validation, design V&V, product test and
acceptance test. Acquisition of V&V tools
RYM Z WENKSTERN
25
25
W ATERFALL – A CTIVITY D EFINITIONS ( CONT ’ D )
System
Feasibility
Validation: “Are we building the
right product?”

Validation
Plans and
requirements
Validation

Product Design
Verification
Verification: “Are we building the
product right?”
Detailed Design
Verification
Code
Unit Test
Integration
Verification
Deployment
System Test
Maintenance
V&V
RYM Z WENKSTERN
26
26
13
W ATERFALL – A CTIVITY D EFINITIONS ( CONT ’ D )
Activity
Description
POF
Project level management functions. Includes project level
planning and control, contract and subcontract management,
and customer interface.
RYM Z WENKSTERN
27
27
W ATERFALL – A CTIVITY D EFINITIONS ( CONT ’ D )
Activity
Description
POF
Project level management functions. Includes project level
planning and control, contract and subcontract management,
and customer interface.
CM/QA
Configuration management includes product identification,
change control, version control and status accounting. Quality
Assurance includes development and monitoring of project
standards and technical audits of software products and
processes
RYM Z WENKSTERN
28
28
14
W ATERFALL – A CTIVITY D EFINITIONS ( CONT ’ D )
Activity
Description
POF
Project level management functions. Includes project level
planning and control, contract and subcontract management,
and customer interface.
CM/QA
Configuration management includes product identification,
change control, version control and status accounting. Quality
Assurance includes development and monitoring of project
standards and technical audits of software products and
processes
Manuals
Development and update of users’ manuals, operator’s
manuals and maintenance manuals
RYM Z WENKSTERN
29
29
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Phase deliverables

Activities

Phases and Activities

Assessment of the Waterfall Model

Variations on the Waterfall Model

Incremental Model

Spiral Model

Cleanroommodel
3. The Iterative Evolutionary Agile Approach
4. Reuse Model
RYM Z WENKSTERN
30
30
15
W ATERFALL – P HASES AND A CTIVITIES

Phases:
chronological structure of the lifecycle

Activities: organizational structure of the lifecycle
RA
PD
Prog
…
CM/QA
RA
PD
Prog
…
CM/QA
RA
PD
Prog
…
CM/QA
…
RA
PD
Prog
…
CM/QA
RYM Z WENKSTERN
31
31
T HE W ATERFALL M ODEL
Specifiers
System
Feasibility
Requirements
Specification
Requi rements Analysis Activity:
Elicitation, specification, review and
update of software requirements
Validation
Plans and
requirements
alidation
V
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Verification
Deployment
System Test
Maintenance
V&V
RYM Z WENKSTERN
32
32
16
T HE W ATERFALL M ODEL
Specifiers
System
Feasibility
Requi rements Analysis Activity:
Elicitation, specification, review and
update of software requirements
Validation
Plans and
requirements
Validation
Software
Architecture
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Verification
Deployment
System Test
Maintenance
V&V
RYM Z WENKSTERN
33
33
T HE W ATERFALL M ODEL
Specifiers
System
Feasibility
Requi rements Analysis Activity:
Elicitation, specification, review and
update of software requirements
Validation
Plans and
requirements
Validation
Product Design
Verification
Data Structures and
Algorithms
Detailed Design
Code (components)
Verification
Code
Complete Program
Tested Complete
Program
Unit Test
Integration
Verification
Deployment
System Test
Maintenance
V&V
RYM Z WENKSTERN
34
34
17
P ROJECT T ASK BY A CTIVITY AND P HASE
Activity
RA
PD
DD & Prog
TP
Plans &
Req
Determi
ne user
reqs
Develop
basic
architecture,
models,proto
types
Top level
personnel, tool
planning
Acceptanc
e test reqs,
top level
test plans
Product
Design
Update
reqs
Develop
product
design,
models,
prototypes
Personnel
planning,
acquire tools,
analyze design
Coding
Update
reqs
Update
design
Integration
& Test
Update
reqs
Update
design
V&V
POF
CM/QA
Manuals
Validate
reqs,
acquire
tools
Project level
management,
planning,
contract,
liaison, etc.
CM/QA
plans,
procedures,
acceptance
plan, tools
Outline
portions of
user’s
manuals
Draft test
plans,
acquire
test tools
V&V
product
design
Management,
status
monitoring,
etc.
CM/QA of
reqs, design,
project
standards
Darft user’s
and
operator’s
manuals
Detailed design,
code, unit
testing,
component
documentation,
integration
planning
Detailed
test plans,
testing
V&V
portions of
code,
V&V design
changes
Management,
status
monitoring,
etc.
CM/QA of
reqs, design,
code
Full draft
manuals
Integrate
software,
update
components
Testing
Perform
product
test,
acceptance
test
Management,
status
monitoring,
etc.
CM/QA of
reqs, design,
code,
acceptance
plan
Final
manuals
Phase
RYM Z WENKSTERN
35
35
P ROJECT T ASK BY A CTIVITY AND P HASE
Activity
RA
PD
DD & Prog
TP
Plans &
Req
Determi
ne user
reqs
Develop
basic
architecture,
models,proto
types
Top level
personnel, tool
planning
Acceptanc
e test reqs,
top level
test plans
Product
Design
Update
reqs
Develop
product
design,
models,
prototypes
Personnel
planning,
acquire tools,
analyze design
Coding
Update
reqs
Update
design
Integration
& Test
Update
reqs
Update
design
V&V
POF
CM/QA
Manuals
Validate
reqs,
acquire
tools
Project level
management,
planning,
contract,
liaison, etc.
CM/QA
plans,
procedures,
acceptance
plan, tools
Outline
portions of
user’s
manuals
Draft test
plans,
acquire
test tools
V&V
product
design
Management,
status
monitoring,
etc.
CM/QA of
reqs, design,
project
standards
Darft user’s
and
operator’s
manuals
Detailed design,
code, unit
testing,
component
documentation,
integration
planning
Detailed
test plans,
testing
V&V
portions of
code,
V&V design
changes
Management,
status
monitoring,
etc.
CM/QA of
reqs, design,
code
Full draft
manuals
Integrate
software,
update
components
Testing
Perform
product
test,
acceptance
test
Management,
status
monitoring,
etc.
CM/QA of
reqs, design,
code,
acceptance
plan
Final
manuals
Phase
RYM Z WENKSTERN
36
36
18
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Phase deliverables

Activities

Phases and Activities

Assessment of the Waterfall Model

Variations on the Waterfall Model

Incremental Model

Spiral Model

Cleanroom model
3. The Iterative Evolutionary Agile Approach
RYM Z WENKSTERN
37
37
A SSESSMENT OF THE W ATERFALL M ODEL
System
Feasibility
Validation
Plans and
requirements
Validation

Strengths?

Weaknesses?
Product Design
Verification
Detailed Design
Verification
Code
Unit Test
Integration
Verification
Deployment
System Test
Maintenance
V&V
RYM Z WENKSTERN
38
38
19
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Phase deliverables

Activities

Phases and Activities

Assessment of the Waterfall Model

Variations on the Waterfall Model

Incremental Model

Spiral Model

Cleanroom model
3. The Iterative Evolutionary Agile Approach
RYM Z WENKSTERN
39
39
V ARIATIONS ON THE W ATERFALL : T HE V M ODEL
Requirements
Analysis
Acceptance
testing
Product
Design
Integration and
system testing
Detailed
Design
Unit testing
Coding

Unit test validates units against detailed design

Integration and system testing validates components
against product design
RYM Z WENKSTERN
40
40
20
V ARIATIONS ON THE WATERFALL : THE S AW TOOTH M ODEL
System
Requirements
Analysis
Prototype
Demo 1
Prototype
Demo 2
Prototype
Demo 3
User
Acceptance
User
Requirements
Analysis
Product
Design
Integration
and Test
Detailed
Design
Software
Engineer
Coding/Unit
testing
RYM Z WENKSTERN
41
41
V ARIATIONS ON THE WATERFALL : THE S HARK TOOTH
M ODEL
System
Requirements
Analysis
Prototype
Demo 1
Prototype
Demo 2
User
Acceptance
User
System Integration
and test
Design Review
Manager
Requirements
Analysis
Integration
and Test
Product
Design
Detailed
Design
Coding/Unit
testing
RYM Z WENKSTERN
Software
Engineer
42
42
21
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Incremental Model

Spiral Model

Cleanroom model
3. The Iterative Evolutionary Agile Approach
RYM Z WENKSTERN
43
43
I NCREMENTAL M ODEL

Stepwise development: parts of some stages postponed in
order to produce useful set of functions earlier

Deliver increments to the user
DEFINITIONDelivered Increment
A self-contained functional unit of software that
performs some useful purpose for the customer, along
with all supporting material (requirements and design
specifications, test plans and test cases, user manual,
training material, etc.)
RYM Z WENKSTERN
44
44
22
I NCREMENTAL M ODEL
RYM Z WENKSTERN
45
45
A SSESSMENT OF THE I NCREMENTAL M ODEL
RYM Z WENKSTERN
46

Strength?

Weaknesses?
46
23
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Incremental Model

Spiral Model

Cleanroom model
3. The Iterative Evolutionary Agile Approach
4. Reuse Model
RYM Z WENKSTERN
47
47
S PIRAL M ODEL

Guiding principle: risk level
DEFINITION
Risk
potentially adverse circumstances that may impair the
development process and the quality of software products.
RYM Z WENKSTERN
48
48
24
S PIRAL M ODEL
DEFINITIONRisk Management
"Discipline whose objectives are to identify, address, and
eliminate software risk items before they become either
threats to successful software operation or a major
source of expensive software rework“
B. Boehm
RYM Z WENKSTERN
49
49
S PIRAL M ODEL
1
2
4
RYM Z WENKSTERN
3
50
50
25
O UTLINE
1. Definitions
2. Traditional Lifecycle Models

Waterfall model

Incremental Model

Spiral Model

Cleanroom model
3. The Iterative Evolutionary Agile Approach
4. Reuse Model
RYM Z WENKSTERN
51
51
C LEANROOM M ODEL
“Cleanroom” in hardware technologies:
Rather than fabricating a product and then working to remove
defects, eliminate defects in specification and design and then
fabricate in a “clean” manner.
“Cleanroom” in Software Engineering:
“The philosophy behind cleanroom software engineering is to avoid
dependence on costly defect removal processes by writing code
increments right the first time and verifying their correctness before
testing. Its process model incorporates the statistical quality
certification of code increments as they accumulate into a system.”
Linger, 1994
RYM Z WENKSTERN
52
52
26
C LEANROOM M ODEL

Cleanroom focuses on defect prevention rather than defect
removal

Cleanroom uses


Mathematical methods and notations for

Software specification

Software design

Correctness verification
Statistical usage-based testing to

Certify software fitness for use
RYM Z WENKSTERN
53
53
C LEANROOM M ODEL

In SE, cleanroom process emphasizes:
1. Incrementaldevelopment
2. Use of formal methods for specification and design
3. Formal correctness verification of developed code
4. Statistically based, independent testing
 near zero-defect software
RYM Z WENKSTERN
54
54
27
C LEANROOM S TRATEGY

Formal specification, design and verification
Computer program:
Output =processing (input history)
y=f(x)
 a program is a mathematical function
RYM Z WENKSTERN
55
55
C LEANROOM S TRATEGY
Functional
Specification
Black Box
State box
State Data
Clear box
State Data
+
Procedure
Implementation
as Program
+
3. Formal correctness verification of developed code
RYM Z WENKSTERN
56
56
28
C LEANROOM S TRATEGY
 Statistical Reliability Certification
 certification of reliability for an intended usage environment
Method: Scientific experiment, allowing valid generalization of findings from
testing environment to operational environment
1.
Usage modeling

2.
Statistical test planning

3.
Cleanroom testing teams (also called certification teams) determine a
usage probability distribution for the software
Generate test cases, identify oracle, prepare test environment and
train testers
Certification testing

Test cases are executed and failure data are recorded and analyzed

Reliability is computed and certified
RYM Z WENKSTERN
57
57
C LEANROOM Q UALITY R ESULTS

Improved quality


“software code developed with CSE only had 2.3 defects per
thousand lines of code measured from the first time of execution.
In contrast, industry averages using traditional software
development methods were estimated at 10 defects per thousand
lines of code after unit testing” (Stavely, 1999).
Increased productivity

due to the reduced time required to debug and rework software
(Kelly & Oshana, 1996).

The industry productivity rate for non-comment source statements
(NCSS) per engineer month is 120. With a trained cleanroom team,
the productivity rate is 800 NCSS (Head, 1994). That is an additional
680 NCSS
RYM Z WENKSTERN
58
58
29
C LEANROOM Q UALITY R ESULTS

Improved software maintainability

“software developed with CSE has clear, well-defined specifications
with a less-complicated design allowing for easier maintenance”
(Kelly & Oshana, 1996).

“This is because CSE incorporates team reviews as part of the
process and uses the box structure method for creating
specifications. Team reviews generally are a more cost-effective
means of improving quality and disseminating knowledge” (Deck,
1997).
RYM Z WENKSTERN
59
59
C LEANROOM M ODEL D ISADVANTAGES

Cleanroom has not gained widespread usage:

Belief that it is too theoretical, mathematical and radical for use in
real software development.

It advocates no unit testing. Replaces it with correctness
verification and statistical quality control
=> major departure from common development approaches.

RYM Z WENKSTERN
It requires rigorous application of defined processes, and software
industry is not mature.
60
60
30
O UTLINE
1. Definitions
2. Traditional Lifecycles
3. The Iterative Evolutionary Agile Approach

Definitions

Rapid Application Development (RAD) model

Assessment of The Iterative Evolutionary Agile Approach
RYM Z WENKSTERN
61
61
T HE I TERATIVE E VOLUTIONARY A GILE A PPROACH

Iterative

Development organized into a series of short, fixed –length miniprojects called iterations.
Deliverable:
A tested, integrated and executable partial system

Evolutionary

RYM Z WENKSTERN
System grows incrementally over time, iteration by iteration
62
62
31
T HE I TERATIVE E VOLUTIONARY A GILE A PPROACH : D EFINITIONS
Requirements
Requirements
Design
Design
Time
Implementation &
Test & Integration
& More Design
Implementation &
Test & Integration
& More Design
Final Integration
& System Test
Final Integration
& System Test
Feedback from
iteration N leads to
refinement and
adaptation of the
requirements and
design in iteration
N+1.
3 weeks (for example)
Iterations are fixed in
length, or timeboxed.
The system grows
incrementally.
RYM Z WENKSTERN
63
63
T HE I TERATIVE E VOLUTIONARY A GILE A PPROACH : D EFINITIONS

Agile

Short, time-boxed iterations with evolutionary refinement of plans,
requirements and design.

Practices and principles that encourage agility: rapid and flexible
response to change
RYM Z WENKSTERN

Simplicity

Communication

Self organizing teams, etc.
64
64
32
T HE A GILE M ANIFESTO AND P RINCIPLES
Individuals and interactions over
processes and tools
Working software
over
comprehensive documentation
Customer collaboration
over
contract negotiation
Responding to change
over
following a plan
RYM Z WENKSTERN
65
65
O UTLINE
1. Definitions
2. Traditional Lifecycles
3. The Iterative Evolutionary Agile Approach

Definitions

Rapid Application Development (RAD) model

Assessment of The Iterative Evolutionary Agile Approach
4. Reuse Model
RYM Z WENKSTERN
66
66
33
R APID A PPLICATION D EVELOPMENT (RAD) MODEL

Process that allows usable systems to be built
in as little as 60-90 days, often with some compromises
Principles

In certain situations,

a usable 80% solution can be produced in 20% of the time that
would be required to produce a total solution.

the business requirements for a system can be fully satisfied even
if some of its operational requirements are not satisfied.

the acceptability of a system can be assessed against the agreed
minimum useful set of requirements rather than all requirements.
RYM Z WENKSTERN
67
67
RAD C HARACTERISTICS
Uses Hybrid teams

Teams consist of about 6 people, including both developers and
full-time users of the system plus anyone else who has a stake
in the requirements.

Developers chosen for RAD teams are multi-talented
"renaissance" people who are analysts, designers and
programmers all rolled into one.
Uses "Time-boxing”

RYM Z WENKSTERN
Secondary features are dropped as necessary to stay on
schedule.
68
68
34
RAD C HARACTERISTICS
Uses specialized tools that support:

"visual" development

creation of fake and working prototypes

multiple languages

teamwork and collaboration

use of reusable components

version control
RYM Z WENKSTERN
69
69
RAD C HARACTERISTICS
Uses iterative, evolutionary prototyping
a) JAD (Joint Application Development) meetings:
High-level end-users and designers meet in a brainstorming
session to generate a rough list of initial requirements.
RYM Z WENKSTERN
70
70
35
RAD C HARACTERISTICS
b) ITERATE UNTIL DONE
•
Developers build / evolve prototype based on current requirements.
•
Designers review the prototype.
•
End users try out the prototype, evolve their requirements.
•
FOCUS GROUP meeting
End users, customers and developers meet to review product together,
refine requirements, generate change requests. Developers listen. End
users/Customers talk.
•
Requirements and change requests are "timeboxed".
•
Changes that cannot be accommodated within existing timeboxes are
eliminated.
•
If necessary to stay "in the box," secondary requirements are dropped.
RYM Z WENKSTERN
71
71
RAD L IFECYCLE
RYM Z WENKSTERN
72
72
36
RAD -- N OTES

Iterations require between 1 day and 3 weeks.

At some stage, exploratory prototypes may evolve into operational
prototypes.

Focus Group Sessions

last about 2 hours and are led by an experienced facilitator, who
keeps the group "on focus"





by having clear goals regarding the kind of
information that needs to be elicited
by preparing an issue-oriented agenda in advance of the
meeting
by ensuring that adequate discussion is directed toward
each issue
by ensuring everyone has an adequate opportunity to
participate
are followed by a report from the facilitator
RYM Z WENKSTERN
73
73
O UTLINE
1. Definitions
2. Traditional Lifecycles
3. The Iterative Evolutionary Agile Approach

Definitions

Rapid Application Development (RAD) model

Assessment of The Iterative Evolutionary Agile Approach
RYM Z WENKSTERN
74
74
37
A GILE A PPROACH : S CHEDULE , E CONOMY , Q UALITY



Efficient Development balances economy, schedule, and quality

Schedule -- faster than average

Economy-- costs less than average

Product -- better than average quality
Sensible RAD tilts away from economy and quality toward fastest
schedule

Schedule -- much faster than average

Economy-- costs a little less than average

Product -- a little better than average quality
All-out RAD "code like hell" (extreme programming)

Schedule -- fastest possible

Economy-- costs more than average

Product -- worse than average quality
RYM Z WENKSTERN
75
75
A SSESSMENT OF T HE I TERATIVE E VOLUTIONARY A GILE A PPROACH

Flexible

Addresses real world software development constraints
But

Does not allow traditional project management

If not used properly can lead to poor quality software
RYM Z WENKSTERN
76
76
38
S UMMARY
We talked about the

Waterfall Model

Incremental Model

Spiral Model

Cleanroom Process

RAD
Which one is the best?
RYM Z WENKSTERN
77
77
HOMEWORK
1. Consider the following software projects: a) developing a conventional
compiler for a known programming language (e.g., Java) for a new machine;
and b) developing an application to automate a doctor’s office. Which
lifecycle model would you chose for each project? Why?
2.
a) What is Scrum in software development?
b) What is the lifecycle model followed by Scrum?
c) Summarize the approach.
d)When would you recommend against the use of Scrum for software
development?
RYM Z WENKSTERN
78
39
H OMEWORK ( CONT ’ D )
4.
Fill in the table below, which describes the level of effort invested in each
activity at each phase of the waterfall model.
Activities
RA
PD
Phases
DD&
Prog
TP
V&V
POF
CM/A
Man
Plans &
Req.
Prod.
Design
Detailed
Design
Code &
Unit Test.
Integration
& Test
RYM Z WENKSTERN
79
H OMEWORK ( CONT ’ D )
4.
Fill in the table below, which describes the level of effort invested in each
activity at each phase of the waterfall model.
Activities
Phases
RA
PD
DD&
Prog
TP
V&V
POF
CM/A
Man
Plans &
Req.
Prod.
Design
Detailed
Design
Code &
Unit Test.
Integration
& Test
RYM Z WENKSTERN
80
40
QUESTIONS?
RYM Z WENKSTERN
81
81
41