Software Lifecycles

Overview

To frame our discussion, consider:

What are strategies used in industry to model the software development process?

What are the similarities and differences between these universal models?

What processes or tasks span phases of the lifecycles?

What factors guide the choice of one process model over another?

OUTLINE

Development Process

Software development projects are often very large projects. A number of people work on such a project for a very long time and therefore the whole process needs to be controlled: progress needs to be monitored, people and resources need to be allocated at the right point in time, etc.
Vliet, p. 31

Requirements Analysis What is the problem?

Functions to be developed
Possible future extensions
Amount and kind of documentation
Performance characteristics for functions

Feasibility Study

Technical
Social
Economic
Political
Design What is the solution?

A system model which solves the problem for the user.

Implementation How is the solution constructed?

A transformation of the design into an executable form.

Testing Is the problem solved?

Determining if the solution as constructed meets the requirements.

Delivery Can the customer use the solution?
Maintenance Are enhancements/changes needed?

Corrective - repair errors
Adaptive - modify software to adapt to changes in environment
Perfective - providing new functionality for new requirements
Preventive - improving the system's maintainability

Phased Lifecycles

Identify phases that have a clear beginning and end at which milestones can be established. The phased lifecycle is document driven - at the end of a phase a document is the product of that phase.

Linear Sequential Model

Phased Lifecycle Model


Relative Cost by Phase
Design
Errors		 Coding
Errors
TOTAL 64% 36%
FOUND AFTER
IMPLEMENTATION 45% 9%
AVERAGE
DIAGNOSTIC TIME 3.1 HRS 2.2 HRS
AVERAGE
CORRECTION TIME 4.0 HRS .8 HRS

[SOURCE: Boehm,?? ]

Cost to Repair Errors


Waterfall Model

Waterfall Lifecycle

Elaborated Waterfall

V&V

Validation - are we building the right product?

Verification - are we building the product right?

Problems with Phased Lifecycles

1. Real projects rarely follow the sequential flow that the model proposes.

2. It is often difficult for the customer to state all requirements explicitly.

3. The customer must have patience. A working version of the program will not be available until late in the project timespan.

4. Developers are often delayed unnecessarily.

(Pressman, p. 32)

5. Phased model does not adequately reveal all the tasks associated with the activity.

Alternate Waterfall Model

Waterfall with Additional Activities

Tasks - Fine Granularity

Prototyping Model

Rapid prototyping assumes that 'real' requirements exist and by iterating through the tasks they can be determined.

Evolutionary prototyping assumes that the project requirements will be subject to continuous change. Evolutionary prototyping a series of fully functioning complete systems with each successive system the new requirements are incorporated.

Findings on Prototyping

Prototyping seems appropriate for
1. Data-oriented applications
2. Applications with emphasis on the user interface
3. Applications which are highly interactive

Boehm (1984), as reported in Vliet (p. 37), had seven groups develop a system. Three groups took the traditional approach (waterfall) in which the requirements were written prior to subsequent activity. Four groups used an evolutionary prototyping strategy. The findings were:
1. Prototyping took 40% less time and resulted in 45% less code
2. The traditional approach resulted in a more robust product which was expected to be easier to maintain.

Alavi (1984), as reported in Vliet (p. 38), reports that users were more positive about the systems developed using the prototyping approach. The positive attitude concerns both the process and the product. Users felt more involved and had fewer conflicts with the designers. Designers had some difficulty with changing requirements and controlling the development process.

RAD Model

The RAD (Rapid Application Development) model is a high speed version of the waterfall model. The emphasis is on short development cycle. Short development cycle is achieved by using component-based construction. Typical use for RAD development is for information systems.

Evolutionary Models

Incremental Model

Incremental Model

Spiral Model

The spiral model attempts to encompass the best features of both the prototyping and phased lifecycle models. The spiral model adds a new element, risk analysis.

  1. Planning - determination of objectives, alternatives, and constraints.

  2. Risk Analysis - analysis of alternatives and identification/resolution of risks

  3. Engineering - Development of the "next-level" product

  4. Customer Evaluation - assessment of the results of engineering

Risk Identification

Project Risks
difficulties associated with budget, schedule, personnel (staffing and organization), resources, customer

Technical Risks
These are those problems that arise because the problem is harder than we thought.
technical uncertainty, technical obsolescence
difficulties in interfacing, maintenance, design and implementation

Business Risks
  1. market risk (the product no one wants)
  2. product line skew (product does not match product line)
  3. can't sell it because sales doesn't understand it
  4. management risk (change in physical management or focus)
  5. budget risk (resource commitment)

References

S. Pfleeger (1991) Software Engineering. New York: Macmillan.

Pressman (1997) Software Engineering: A Practitioners Approach. New York:McGraw-Hill.

van Vliet, Hans (1993) Software Engineering: Principles and Practice. Chichester: John Wiley & Sons.