Software Life Cycle

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) • One development stage should end before the other begins • Milestones and deliverables associated with each process • Validation and verification at every stage • Model focused on documents and artifacts

Requirements Analysis System Design Program Design

Coding Unit & Integration 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 System Design

Operation & Maintenance

Program Design

Acceptance Testing System Testing

• •

Coding Unit & Integration 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 & Maintenance

Requirements Analysis

Acceptance Testing

System Design

System Testing Program Design

Unit & Integration Testing Coding

•

Testing activities (right) are related to analysis and design (left) – –

•

Iteration is explicitly specified –

•

Verification: Unit & integration testing used for verification of program design Validation: Acceptance testing is conducted by customer for validation of requirements If problems arise during verification or validation (right), stages on left side can be reexecuted 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 Revisions

Revise Prototype

List of Revisions

User/Customer Review

Prototype Requirements

Prototype Design

System Requirements

• • •

List of Revisions

Prototype System

System Testing

Deliver 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

Operational Specification (problem-oriented)

Transformed Specification (implementationoriented)

System Requirements

• • •

Test

Deliver 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; update as needed

Formal Development Record Sequence of transformations plus rationale for them Transform n

Formal Specification

Transform 2

Test

Transform 1

System Requirements (informal)

• •

Deliver System

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 developers

Development systems Build Release 1

Build Release 2

Build Release 3

users

Time

Use Release 1

Use Release 2

Use Release 3

Production systems

• •

Two systems functioning in parallel: production and development Incremental development – –

•

Iterative development –

•

System is partitioned into subsystems by functionality Releases are defined by starting with a subsystem, then adding functionality with each new release 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, alternatives, constraints

Constraints 3

Risk analysis 3

Prototype 4

Constraints 2 Risk analysis 2 Alternatives 3 Prototype 3 Alternatives 2 Al tern Risk analysis 1 Prototype 2 ativ Budget 3 Budget 2 Budget 1 es 1 Prototype 1 int tr a ns Co

s 1

Budget 4

Risk analysis 4

Constraints 4

Alternatives 4

Evaluate alternatives and risks

Development plan Integration and test plan

Requirements, life cycle plan

Concept of separation Validated requirements

re wa ents t f So irem Software u req design

Code

Validated, Verified design Acceptance test

Plan

Detailed design

Unit test System test

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