SOFTWARE ENGINEERING

30 August 2010

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

Software Engineering Objective

The right software

delivered defect free,

on time and

on cost,

every time.

Carnegie Mellon Software Engineering Institute

Software Engineering Process

Requirements Design Implementation Test Maintenance

Transparency

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

No Silver Bullet

For Every Paper You Read What did you learn? What surprised you?

When was it written? What has changed? What hasn’t?

Who is the author? What are his credentials?

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

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.

Fundamental Steps

Step Documentation

Requirements Design Implementation Test Deployment Maintenance

Functional Spec Design Document Code Test Plan User Documentation Design Document

Our first task Spec for the project Need to understand

ConceptUsersUse casesRequirements

Need to Start with a Concept How do you tell people about your project Why are you doing it What makes it unique or different

brochure elevator speech

Capture Essence of Project Refer back if losing your way

Remind yourself and others why

Prominent: first page of your web

Clients vs. Users The client is the person “paying the bill” The users are the ones that will

Use your systemMaintain your systemAdminister your system

Know theirSkill levelTime constraintsTolerancesExpectations

Requirements Analysis To build something, we first must understand what

it is we’re building Establish expectations Understandable by both the client and the

developer

Requirements

Why Written Requirements? Unambiguous

Defines goals

Cost of finding a requirements bug later can be 100 times more expensive

Mars Climate Orbiter (December 1998)

Intended to orbit Mars Supposed to provide

output in newton seconds

Instead crashed into it Instead provided

pound-force seconds

Minimum distance:80 km