Wake Forest University Computer Science Department

Software Life Cycle

CSC 331/631

V. P. Pauca

Spring 2003 1
Wake Forest University Computer Science Department

Outline
• Software Development Models
– Waterfall model
– V model
– Prototyping model
– Operational specification model
– Transformational model
– Phased development models
– Spiral model
• Summary
• References

Spring 2003 2
Wake Forest University Computer Science Department

The Waterfall Model (Royce 1970)

Requirements • One development stage should end before the other begins
Analysis • Milestones and deliverables associated with each process
System
• Validation and verification at every stage
Design • Model focused on documents and artifacts
Program
Design

Coding

Unit & Inte-

gration Testing

System
Testing
• Basis for software development in DoD contracts
Acceptance
Testing

Operation
& Maintenance

Spring 2003 3
Wake Forest University Computer Science Department

Why not a Waterfall Model?

• Provides no guidance on how to handle changes
– Does not account for prototyping and iteration

• Presents a manufacturing view of software engineering

– Derived from the hardware world

• Does not reflect the way code is really developed

Spring 2003 4
Wake Forest University Computer Science Department

Software Development in Reality?

Requirements
Analysis
Operation System
& Maintenance Design

Acceptance Program
Testing Design

System
Testing Coding
Unit & Inte-
gration Testing

• Thrashing from one activity to the next to gather knowledge about the problem and
how the proposed solution addresses it
• Control thrashing by including activities to enhance understanding
– Prototyping to examine specific aspects of the proposed system

Spring 2003 5
Wake Forest University Computer Science Department

V Model (German MoD 1992)

Operation
Requirements & Maintenance
Analysis

Acceptance
Testing
System
Design
System
Testing
Program
Design Unit & Inte-
gration Testing

Coding
• Testing activities (right) are related to analysis and design (left)
– Verification: Unit & integration testing used for verification of program design
– Validation: Acceptance testing is conducted by customer for validation of requirements
• Iteration is explicitly specified
– If problems arise during verification or validation (right), stages on left side can be re-
executed to fix and improve requirements, design, and code
• Model focused on activity and correctness

Spring 2003 6
Wake Forest University Computer Science Department

Prototyping Model
List of List of List of
Revisions Revisions Revisions

Revise User/Customer
Prototype Review

Prototype Prototype Prototype System

Requirements Design System Testing

System Deliver
Requirements System

• Prototyping allows all or part of a system to be constructed quickly to understand or

clarify issues
• Want to ensure that the developer, user and customer have common
understanding of what is needed and what is proposed
• Overall goal: reducing risk and uncertainty
Spring 2003 7
Wake Forest University Computer Science Department

Operational Specification Model (Zave 1984)

Execute &
Revise

Transformed
Operational
Specification Test
Specification
(implementation-
(problem-oriented)
oriented)

System Deliver
Requirements System
• Allows early examination of requirements and their implications
• System requirements are evaluated or executed to demonstrate and analyze the
behavior of the system
• Allows system functionality and design to be merged
– In the waterfall model, functionality and design are clearly separated

Spring 2003 8
Wake Forest University Computer Science Department

Transformational Model (Balzer 1981)

Compare with
requirements; Formal Development Record
update as needed
Sequence of transformations
plus rationale for them
Transform n

Formal Transform 2 Test

Specification
Transform 1

System Deliver
Requirements System
(informal)
• Attempts to reduce opportunity for error by eliminating major development steps
• Applies series of transformations using automated support to change a
specification into a deliverable
– Data representation, compiling, optimizing
• Sequence of transformations and associated decisions kept carefully
• Relies heavily in availability of formal specification methods
Spring 2003 9
Wake Forest University Computer Science Department

Phased Development Models

Development systems
developers

Build Release 1 Build Release 2 Build Release 3

Time
users

Use Release 1 Use Release 2 Use Release 3

Production systems

• Two systems functioning in parallel: production and development

• Incremental development
– System is partitioned into subsystems by functionality
– Releases are defined by starting with a subsystem, then adding functionality with each new
release
• Iterative development
– Deliver full system, then change functionality of subsystems with each new release
• In practice, a combination of incremental and iterative development may be used
Can you give some reasons?

Spring 2003 10
Wake Forest University Computer Science Department

Spiral Model (Boehm 1988)

Determine goals, Evaluate alternatives
alternatives, and risks
Risk analysis 4
constraints Constraints 4

Constraints 3 Risk analysis 3

Alternatives 4 Prototype 4
Constraints 2 Risk analysis
Alternatives 3 2
Prototype 3

Co
Alternatives 2 Al
Risk analysis 1 Prototype 2

ns
tern

tr a
ativ
Budget 2 Budget 1 es 1

int
Budget 4 Budget 3 Prototype 1

s1
Requirements, Concept of re Detailed
life cycle plan separation ft wa ents
Development So irem design
u Software
plan Validated req design
Integration requirements Code
and test plan Validated,
Verified design Unit test

System
Acceptance test
test
Plan Develop and Test

Spring 2003 11
Wake Forest University Computer Science Department

Spiral Model
• Model focused in managing, controlling, and minimizing risk
• It is like iterative development in some sense
– With each iteration, risk analysis weights alternatives in light of
requirements and constraints
– Prototyping verifies feasibility or desirability before a particular
alternative is chosen

Spring 2003 12
Wake Forest University Computer Science Department

Summary
• The waterfall model is the traditional document-driven approach
• Other models proposed that deal with change, uncertainty and risk in more explicit
ways
• Process modeling
– Describe software development processes as programs
• Consecutive activities, input and output
– Describe process in terms of states and transitions
• UML diagrams
– Describe process using Petri nets
• Places, markings, and transitions
• Allow nondeterminism and parallelism
• Software development models help coordinate collaboration as system is designed
and implemented
• The models allow focusing in particular aspects of development process, e.g.
organizational, functional, behavioral, and other aspects

Spring 2003 13
Wake Forest University Computer Science Department

References
• H. Van Vliet. Software Engineering Principles and Practice. Wiley, West Sussex,
UK, 2002
• S. L. Pfleeger. Software Engineering Theory and Practice. Second Edition. Prentice
Hall. Upper Saddle River, NJ, 2001
• W.W. Royce. Managing the development of large software systems: concepts and
techniques. In Proceedings IEEE WESCON, pp. 1-9. IEEE, 1970
• German Ministry of Defense. V-model: software lifecycle process model. General
Preprint No. 250, 1992
• P. Zave. The operational versus the conventional approach to software
development. Comm. of the ACM, 27 (2), pp. 104-118, 1984
• R. Balzer. Transformational implementation: an example. IEEE Trans. on Software
Engineering, SE 7 (1), pp. 3-14, 1981
• T. Gilb. Principles of Software Engineering Management. Addison-Wesley, 1988
• B. W. Boehm. A spiral model of software development and enhancement. IEEE
Computer, 21 (5), pp. 61-72, 1988

Spring 2003 14