SOFTWARE ENGINEERING

PROCESSES

Software Engineering

Engineering Turning ideas into reality

Creating something usefulfrom other things

using science and math

Software Engineering vs.

Other Engineering Disciplines

MaturityRoman aqueducts 2000 years agoSoftware engineering 50 years ago

Startup costsBarriers to entry

Rate of change

Software Engineering Objective

The right software

delivered defect free,

on time and

on cost,

every time.

Carnegie Mellon Software Engineering Institute

Common Mistakes Over committing (“big eyes”) Unrealistic schedules

TrainingAccess to people or materialsHours in the day

Level of detailVague descriptionsOver specification

Not knowing your user Assuming that you’ll get it right the first time

Different Types of Projects Consider 4 different types of systems

COMP 523 projectsProductivity suitesCommercial web sitesAirplane systemsPacemakers

How do they differ in criticality? What does that mean for the development

process?

All software projects are different

but …Requirements will change.

Surprises will happen.

Schedules will slip.

Life will happen.

Transparency

Track what you do AND document it …not as an afterthought Living, heavily-used documentation

Programming History

1960’s

60’s “Cowboys” wrote software anyway that they couldDifference between best programmers and worst as high as 28:1

(many sources)Start of the “software crisis”

1968Edsger Dijkstra, “GOTO Statement Considered Harmful” (CACM)Recognition that rules can improve the average programmer

Structuring Software Development

Few rules helped immensely Good rules and practices developed over the 70’s

and 80’s If a few rules are good, more are better… Late 80’s, major focus on process as a key to

quality ISO 9000 (first published 1987)Malcolm Baldrige National Quality Award (just celebrated

25th anniversary)

Why not apply to software development?

Companies started codifying their practices Large documents and people to manage them

Rise of the project manager “Honored in the breach” More large projects and more late or failed projects

1995 Standish Group StudyJerry Saltzer SOSP 1999

1995 Standish Group Study

50% software projects challenged2x budget2x completion time2/3 planned function

30% impairedScrapped

20% success

Jerry Saltzer Presentation

Who is Jerry Saltzer?Early time sharing (CTSS)Multics Operating System (“inspired” Unix)Project Athena

○ Thin client computing○ Kerberos○ LDAP○ Instant messaging

Processes

Software Engineering Processes

Differ by how often you do the steps Points on the spectrum Differences in overhead

Three fundamental models Waterfall Spiral Iterative

Widely used models Integrated Product Development Unified Software Development Process Extreme Programming

All models address the 4 P’s of Software Engineering

People: those doing it Product: what is produced Process: manner in which it is done Project: the doing of it

Fundamental Steps

Requirements Design Implementation Test Deployment Maintenance

Processes

Differ by how often you do the stepsFocus and emphasis

Points on the spectrum Differences in overhead Three fundamental processes

WaterfallSpiralIterative

Waterfall Do it once Traditional model Used for large next version releases, especially when well understood product tightly coupled changes

Waterfall

1970s Built on 1950’s stage-

wise process Recognized the need

for feedback LimitedHeavy process

Waterfall Pros

Simple documentation managementClean design phase

ConsLeast flexibilityNo early feedback

Iterative (a.k.a. Agile) Many iterations Each iteration is on a fixed cycle

Typically biweekly

Used for projects with

lots of small independent, but well understood, changes

small development team

strong client involvement

Iterative

Reaction to waterfall Derived from “evolutionary” process

Requirements and specs evolve over time Two well-known models

Extreme programmingSCRUM

Iterative (a.k.a. Agile) Pros

Fast feedback on problems Very adaptable to any changes Lots of versions to work with Heavy user involvement

Cons Document maintenance Code maintenance Requires good automation

Spiral Few iterations Each iteration adds new requirements Used often for projects with less well

defined requirements

Spiral

Risk based Barry Boehm 1988 “A Spiral Model of

Software Development and Enhancement”

Spiral Pros

Adaptation to changes based on risksGood customer interactionEarly versionLimited iterations provide phase structure

ConsDocument maintenance

Unified (Software Development) Process spiral variant Iterations within phases 4 phases and core workflows for each Identifies that iterations differ

Requirements

Analysis

Design

Implementation

Test

ElaborationInception Construction Transition

Also known as Rational Unified Process (Rational products)

Historical Recap

Waterfall: 1970, built on 1950’s stage- wise processes

Recognized need for feedback Iterative (agile): late 70s,modeled on

evolutionary model

Didn’t work well for large products Spiral: 1988, risk-based