Software Engineering 3156

Fall 2001 Section 1

10-Sep-01

Class #2: Overview

Phil Gross

2

Administrivia

HW0 = questionnaire Fabulous new web site Policy about people who don’t meet the

requirements

3

Case Study: Ariane 501

Next-generation launch vehicle Successor to the Ariane 4 Prestige project for ESA Maiden flight: June 4th 1996

4

The System

Inertial Reference System– What’s my position, velocity, and acceleration?

Critical, obviously– Dual redundant

Calibrated on launch pad Largely carried over from Ariane 4

– recalibration routine allowed to continue running for 40 sec after launch

5

The Problems

Recal routine never used after launch, but still active

One step in recal converted floating point value of horizontal velocity to integer

Ada automatically throws an exception if data conversion is out of bounds

If exception not handled, IRS returned diagnostic data instead of position/velocity info

6

The Situation

Perfect launch Starts flying much faster than Ariane 4 Horizontal component goes out of bounds for

integer conversion Both IRSs switch to diagnostic mode Control system interprets diagnostic data as

very weird orientation And attempts to correct it…

7

Ariane 501 Go Boom

8

Postmortem

Recal routine had no business being active after launch

Horizontal velocity parameter conversion was deliberately allowed to be unchecked

Software had never been tested with actual flight parameters– Problem easily reproduced in test environment after

the fact

9

At Least It Was Pretty

10

Extra Case Study

Bug Report This is an actual e-mail I received over the

weekend (name removed to protect the guilty)

Hello, I filled out the questionnaire, but I could not submit it.  Just wanted to let you know. 

- (John Doe)

11

Overview

The Waterfall model More on maintenance Terminology Team models More on the project

12

Waterfall Model

Requirements Specification Design Implementation Integration Maintentance

13

Requirements

What are we doing and why? Interviews

– Getting a problem specification out of busy, threatened, very-much-not-programmer types

– Difficult to simulate in a course, so we’re skipping

Prototypes and negotiation Metric: requirements volatility

14

Specification

Creating the contract What it will do, not how Detailed, so duration and cost can be

estimated Classical: DFD, FSM, Petri Nets OO: Use cases, class modeling, state

diagrams

15

Design

Fill in the “How” Interaction diagrams

– Sequence– Collaboration

Interactions determine actions Determine object clients Create detailed design

16

Implementation

Pick a language: C, C++, Java, Ada, COBOL, LISP, FORTRAN, Standard ML, Forth, PL/SQL, Assembly, etc.

Programming standards: comments, meaningful variable names, named constants, etc.

Black-box and Glass-box testing

17

Integration

Top-down finds design faults early Bottom-up finds operational faults early and

isolates them So, “Sandwich Integration” does both at once Product and acceptance testing

18

Maintentance

Corrective (fix problems) Perfective (improvements) Adaptive (environment changes) Difficult, important, programmers hate it Carefully designed processes are critical

19

Better Definition of Maintenance

Changing something that’s already been written or specified

Regardless of whether it’s before or after delivery

Delivery date is artificial boundary Note that Schach is a Maintenance specialist

20

Maintenance Costs Money

Lots and lots of money Far and away most expensive component When doing cost-benefit analysis, anything that

cheapens maintenance generally wins

21

Maintenance Is A Good Thing

It’s what happens to a used, living program Dead programs, like dead languages, need no

maintenance

22

Maintenance Is Hard

Every problem is a puzzle This is what happened

– Find out why– Fix it

Often end up knowing code better than original authors

Horrible job– fixing stupidities all day, every day

23

Terminology

Faults and errors (also bug, defect, anomaly, failure, exception)– Fault is in the program– Error is observed effect

Products, programs, and systems

24

OO Terminology

Attribute = field, state variable, instance variable, property

Method = member function (not quite the same as plain old function, though)

Static vs. dynamic

25

Teams - Brooks’s Law

Adding personnel to a late software project makes it later

Training time Number of communication pairs grows as

O(N2) while work accomplished grows at O(N) If project naturally breaks into four pieces, what

is a fifth person supposed to do?

26

Democratic Teams

Egoless programming Social engineering “Please find bugs in my code” Problem: “I order you all to be egoless”

27

Chief Programmer Teams

Brooks’s approach Chief Programmer Back-up Programmer Secretary Just Plain Programmers

28

Chief Programmer Problems

Chief supposed to be manager and programmer

Back-up Programmer just waiting for Chief Programmer to be hit by a truck– Cf. Vice President of the USA

Secretary does paperwork all day Doesn’t scale to 100 programmers

29

Typical Modern Team

Programmers have a Technical Leader and a separate Team Manager

Manager is administrative only Tech Lead is Technical only Can increase the hierarchy

30

Microsoft Model

Synchronize and stabilize Programmers can do whatever they want, but

have to check in their code on time every day for integration

Lets hackers run (relatively) free Good model for firms that can attract the very

best programmers

31

Extreme Teams

Code in pairs No specialization A writes test cases, then B writes code while A

watches Designed to be turnover-resistant Not for those who don’t like to be watched

32

More On Project

Three main parts– Client– Server– AI

Each group will work on one of the three

33

Client

Graphical tile-based UI Network communication with server Running animations Sending commands from user to server Displaying what the server tells it to Editor modeUntrusted

34

Server

Network communication with client Modeling of entire game world

– Combat– movement

Management of game clock Storage to LDAP server

35

AI

Determine NPC/Monster actions Determine shortest path between points Scripting Conversation

36

XML

Structured form of communication How components will communicate Freeform HTML Grammar and validation DOM and SAX