1 CS 501 Spring 2008

CS 501: Software Engineering

Lecture 2

Software Processes

2 CS 501 Spring 2008

Letter "l"

Administration

Project teams

Any short notices to class?

Course team email address

When you have formed your team and reached

agreement with your client, please send a

message to cs501-l@lists.cs.cornell.edu with

the names of the team, the client's name, and

the topic of the project.

3 CS 501 Spring 2008

Project Concept: Legal Information

Institute

• Spaeth database of

Supreme Court statistics

• Federal rulemaking

documents

Tom Bruce, Director

Legal Information

Institute

4 CS 501 Spring 2008

Project Concept:

Student Disability Services (SDS)

Booking system for CULift service

Michele D. Fish, Student Disability Services

Center for Learning & Teaching

5 CS 501 Spring 2008

Project Suggestion:

Cheaper and Better Textbooks

Cheaper and Better Textbooks

Paul Francis, Computer Science Department

6 CS 501 Spring 2008

Project Suggestion: eCommons

• Harvesting from Web sites

• Drag and drop user interface

John Saylor, Cornell University Library

7 CS 501 Spring 2008

Project Concept:

Collaborative Text Editor

Collaborative Text Editor

Adam Engst

8 CS 501 Spring 2008

Project Concept:

Weill Cornell Medical Library

Weill Cornell Medical Library eResources

Paul Albert, Digital Services Librarian

9 CS 501 Spring 2008

Project Concept: Predict Systems

Additunes: music recommendation system

Blazej Kot, Predict Systems & Cornell Information Science

10 CS 501 Spring 2008

Project Concept: Cornell Cooperative

Extension

• Systems for online content management and

dissemination

Raj Smith, Department of Natural Resources

and Cooperative Extension

11 CS 501 Spring 2008

A Classic Book

Frederick P. Brooks, Jr. The Mythical Man Month.

Addison-Wesley, 1972.

12 CS 501 Spring 2008

Software Process

Fundamental Assumption:

Good processes lead to good software

Good processes reduce risk

Good processes enhance visibility

13 CS 501 Spring 2008

Variety of Software Processes

Software products are very varied...

Therefore, there is no standard process for all software

engineering projects

BUT successful software development projects all need to

address similar issues.

This creates a number of process steps that must be part of all

software projects

14 CS 501 Spring 2008

Basic Process Steps in all Software

Development

• Feasibility and planning

• Requirements

• System and program design

• Implementation and testing

• Acceptance testing and release

• Operation and maintenance

It is essential to distinguish among these process steps and

to be clear which you are are doing at any given moment.

Do not confuse requirements and design

15 CS 501 Spring 2008

Process Step: Feasibility and Planning

A feasibility study precedes the decision to begin a project.

• What is the scope of the proposed project?

• Is the project technically feasible?

• What are the projected benefits?

• What are the costs, timetable?

A feasibility study leads to a decision: go or no-go.

16 CS 501 Spring 2008

Process Step: Requirements

Requirements define the function of the system from the

client's viewpoint.

The requirements establish the system's functionality,

constraints and goals by consultation with the client and users.

They are then defined in a manner that is understandable by

both the client and the development staff.

This phase is sometimes divided into:

• Requirements analysis

• Requirements definition

• Requirements specification

17 CS 501 Spring 2008

Process Step: System and Program

Design

Design describes the system from the software

developers' viewpoint

System design: Match the requirements to hardware or

software systems. Establishes an overall system

architecture

Program design: Represent the software system

functions in a form that can be transformed into one or

more executable programs

• Unified Modeling Language (UML)

18 CS 501 Spring 2008

Process Step: Implementation and

Testing

Implementation (coding)

The software design is realized as a set of programs or

program units. (The software components may be

written specifically, acquired from elsewhere, or

modified.)

Testing

Individual components are tested against specifications.

The individual program units are integrated and tested

against the design by the development staff as a

complete system.

19 CS 501 Spring 2008

Process Step: Acceptance Testing and

Release

Acceptance testing

The complete system is tested against the requirements

by the client.

Delivery and release

The complete system is delivered to the client and

released into production.

20 CS 501 Spring 2008

Process Step: Operation and

Maintenance

Operation: The system is put into practical use.

Maintenance: Errors and problems are identified and

fixed.

Evolution: The system evolves over time as requirements

change, to add new functions or adapt the technical

environment.

Phase out: The system is withdrawn from service.

This is sometimes called the Software Life Cycle

21 CS 501 Spring 2008

Sequence of Processes

Every software project will include these basic processes, in some

shape or form, but:

• They may be formal or informal

• They may be carried out in various sequences

Major alternatives

• Sequential: As far as possible, complete each process step

before beginning the next (but see the next few slides).

Waterfall model.

• Iterative: Go quickly through all process steps to create a

rough system, then repeat them to improve the system. Iterative

refinement.

22 CS 501 Spring 2008

Sequential Development:

The Waterfall Model

Requirements

System design

Testing

Operation & maintenance

Program design

Implementation (coding)

Acceptance & release

Requirements

Design

Implementation

Feasibility study

23 CS 501 Spring 2008

Discussion of the Waterfall Model

Advantages:

• Process visibility

• Separation of tasks

• Quality control at each step

• Cost monitoring at each step

Disadvantages:

Each stage in the process reveals new

understanding of the previous stages, that often

requires the earlier stages to be revised.

The Waterfall Model is not enough!

24 CS 501 Spring 2008

Sequence of Processes

A pure sequential model is impossible

Examples:

• A feasibility study cannot create a proposed budget and

schedule without a preliminary study of the requirements and a

tentative design.

• Detailed design or implementation usually reveals gaps in the

requirements specification.

The plan must allow for some form of iteration.

25 CS 501 Spring 2008

Modified Waterfall Model

Requirements

System design

Testing

Operation & maintenance

Program design

Implementation (coding)

Acceptance & release

Waterfall model

with feedback

This is better

Feasibility study

26 CS 501 Spring 2008

Iterative Development: Iterative

Refinement (Evolutionary Development)

Concept: Initial implementation for client and user

comment, followed by refinement until system is complete.

• Vaporware: user interface mock-up

• Throw-away software components

• Dummy modules

• Rapid prototyping

• Successive refinement

Get something working as quickly as possible!

27 CS 501 Spring 2008

Iterative Refinement

Requirements

Design Implementation

Evaluation

28 CS 501 Spring 2008

Iterative Refinement

Outline

Description

Concurrent

Activities

Requirements

Design

Implementation

Initial

Version

Intermediate

Versions

Final

Version

Evaluation

may be

continuous

29 CS 501 Spring 2008

Mixed Processes: Phased Development

Combine sequential and iterative elements

A simple system with basic functionality is brought quickly

into production (Phase 1).

Subsequent phases are based on experience gained from

users of each previous phase.

Advantages

• Pay-back on investment begins soon.

• Requirement are more clearly understood in developing

subsequent phases

30 CS 501 Spring 2008

Phased Development Online

When software is released online it is possible to divide it

into very small phases that are developed and released in

quick succession.

Example: Amazon.com divides most software development

into phases of about four weeks elapsed time.

This approach is excellent for continual enhancement of a

system within a well established architecture.

It is not possible for shrink wrapped software, embedded

systems, or similar environments.

31 CS 501 Spring 2008

Example:

Iterative Refinement + Waterfall Model:

Problem: Add graphics package to a programming environment

Phase 1: Iterative refinement

Extend current environment with a preprocessor and run-time support

package. Test with users. Make several new versions until users are

pleased with function.

Phase 2: Modified waterfall

Use the results of Phase 1 as the basis for a detailed set of

requirements. Write new compiler and run-time system incorporating

graphics elements. Make minor adjustments to requirements as

needed.

32 CS 501 Spring 2008

Observations about Software Processes

Completed projects should have the basic process steps

but ... the development process is always partly evolutionary.

Risk is lowered by:

• Prototyping key components

• Dividing into phases

• Following a visible software process

• Making use of reusable components

Conclusion

It is not possible to complete each step and throw it over the wall.

33 CS 501 Spring 2008

CS 501 Project Presentations:

Sequential Option

Requirements

System design

Testing

Operation & maintenance

Program design

Implementation (coding)

Acceptance & release

1. Requirements

2. Design

3. Implementation

Feasibility study

If you follow a

sequential process the

three presentations

should be as shown.

34 CS 501 Spring 2008

CS 501 Project Presentations:

Iterative Option

Requirements

Design Implementation

Evaluation

first presentation

second presentation

third presentation