00 software lifecycle

8/8/2019 00 Software Lifecycle

1/20

1

TCSS 360, Spring 2005Lecture Notes

Software Engineering and the

Software Lifecycle


2/20

2

Software engineering

Software engineering: the profession, practiced bydevelopers, concerned with creating and maintainingsoftware applications by applying technologies andpractices from computer science, project

management, and other fields.

Software engineering has accepted as its charter, "How to program ifyou cannot." -- E. Dijkstra

The first step toward the management of disease was replacement of

demon theories and humours theories by the germ theory. That verystep, the beginning of hope, in itself dashed all hopes of magicalsolutions. It told workers that progress would be made stepwise, atgreat effort, and that a persistent, unremitting care would have to bepaid to a discipline of cleanliness. So it is with software engineeringtoday. -- F. Brooks


3/20

3

Roles of people in software

people involved in software production

customer / client: wants software built

often doesn't know what he/she wants

managers / designers: plan software difficult to foresee all problems and issues in advance

developers: write code to implement software

it is hard to write complex code for large systems

testers: perform quality assurance (QA)

it is impossible to test every combination of actions

users: purchase and use software product

users can be fickle and can misunderstand the product


4/20


5/20

5

Ad-hoc software development

ad-hocdevelopment: creating softwarewithout any formal guidelines or process

what are some disadvantages of ad-hocdevelopment?

some important actions (testing, design) may go

ignorednot clear when to start or stop doing each task

does not scale well to multiple people

not easy to review or evaluate one's work


6/20

6

The software lifecycle

software lifecycle: series of steps / phases, throughwhich software is produced can take months or years to complete

goals of each phase: mark out a clear set of steps to perform

produce a tangible document or item

allow for review of work

specify actions to perform in the next phase

common observation: The later a problem is found insoftware, the more costly it is to fix


7/20

7

Lifecycle phases

standard phases

1. RequirementsAnalysis & Specification

2. Design

3. Implementation, Integration

4. Testing, Profiling, Quality Assurance

5. Operation and Maintenance

other possible phases risk assessment: examining what actions are critical and

performing them first (part of Spiral model)

prototyping: making a quick version of the product and

using it to guide design decisions


8/20

8

One view of SW cycle phases

Subsystems

Structured By

class...

class...class...

SourceCode

Implemented

By

SolutionDomainObjects

Realized By

System

Design

Object

Design

Implemen-

tationTesting

ApplicationDomainObjects

Expressed in

Terms Of

TestCases

?

Verified

By

class.... ?

Requirements

Elicitation

Use CaseModel

Analysis


9/20

9

Some software models

Several models for developing software(besides ad-hoc) have been attempted: code-and-fix: write some code, debug it, repeat

until finished

evolutionary: build initial requirement spec, writeit, then "evolve" the spec and code as needed

waterfall: perform the standard phases(requirements, design, code, test) in sequence

rapid prototyping: write an initial "throwaway"version of the product, then design, code, test

spiral: assess risks at each step, and do the most

critical action immediately


10/20

10

code-and-fix model

Code FirstVersion

Retirement

Operations Mode

Modify untilClient is satisfied


11/20

11

Problems with code-and-fix

What are some reasons not to use the code-and-fix model?

code becomes expensive to fix (bugs are notfound until late in the process)

code didn't match user's needs (norequirements phase!)

code was not planned for modification, notflexible


12/20

12

Evolutionary model

For each build:Perform detaileddesign, implement.Test. Deliver.

Requirements

Verify

Retirement

Operations

Verify

Arch. Design


13/20

13

Problems with evolutionary

The evolutionary model is similar to code-and-fix, butit assumes the repetitions are "evolutions" of thecode, not necessarily bug fixes. Problems with this?

difficult to distinguish from code-and-fix

assumes user's initial spec will be flexible; fails for:

separate pieces that must then be integrated

"information sclerosis": temporary fixes become permanentconstraits

bridging; new software trying to gradually replace old

wrong order: makes lots of hard-to-change code


14/20

14

Waterfall model (Royce, 1970)

Requirements

Verify

Retirement

Operations

Test

ImplementationVerify

Design

Req. Change


15/20

15

Rapid prototyping model

Rapid Prototype

Verify

Retirement

Operations

Test

Re-implementationVerify

Redesign

Req. Change


16/20

16

Waterfall /Prototyping issues

The waterfall models (with or withoutprototyping) are perhaps the most commonmodel for software development

we will use waterfall in this course! What are some positives and negatives about

this method?

+ formal, standard, has specific phases with clear goals

+ good feedback loops between adjacent phases

-rigid, too linear; not very adaptable to change in the product

-requires a lot of planning up front (not always easy / possible)

-assumes that requirements will be clear and well-understood


17/20

17

Spiral model (Boehm)

Concept of

Operation

Requirements

Plan

Requirements

OAC

Risk

Assessment

Risk

Item

Set

RiskMa

nagem

entPlan

Requirements

Risk

Control

Requirements

Validation

Abstract Specification

Plan

Abstract

Specifcation

OAC

Risk

Assessment

Risk

Control

Abstract

Specification

Abstract Specification

Validation

Concrete Specification

Plan

Concrete

Specification

OAC

Concrete

Specification

Concrete

Specification Validation

and Verification

Software

Development Plan

Risk

Assessment

Risk

Control

Progressthroughsteps

Cumulativecost

Evaluate alternatives,identify, resolve risks

Develop, verifynext-level product

Plan next phases

CommitReview

partition

Determineobjectives,alternatives,constraints(OAC)


18/20

18

Another view of spiral model

Requirements

Verify

Retirement

Operations

Test

ImplementationVerify

Design

Req. Change

Adds a Risk Analysisstep to each phase

(phases may not becompleted in this order

any more!)

Risk Assessment

Risk Assessment

Risk Assessment


19/20

19

Spiral model problems

What are some positives and negatives aboutthis method?

+ focuses attention on reuse

+ accommodates changes, growth

+ eliminates errors and unattractive choices early

+ limits to how much is enough (not too much design, reqs, etc)

+ treats development, maintenance same way-matching to contract software (doesn't work well when you'rebound to a fixed inflexible contract)

-relying on developers to have risk-assessment expertise

-need for further elaboration of project steps (clearer milestones)


20/20

20

Tools for software engineers

CASE (Computer-Aided Software Engineering)

requirements / spec generation software

design diagram (UML) software

integrated development environments (IDEs) test suites (JUnit) and benchmarking / profiling

software

00 software lifecycle

Documents