45
27 February A Broader Perspective

27 February A Broader Perspective. Triangle Technology Executive Panel Friday, 2 March 3:30 p.m. Sitterson 014 For more info, see pozefsky/TTECPanel.html

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

27 February

A Broader Perspective

Triangle Technology Executive PanelFriday, 2 March

3:30 p.m.Sitterson 014For more info, see

http://www.cs.unc.edu/~pozefsky/TTECPanel.html

Capital Analytics

Find out about local businessesAsk questions

about the industry

Learn what companies are looking for in employees

Network

Midterm Presentations:Purpose

You don’t understand something until you’ve taught it Clarification of your thought process and

understanding Sharpen your understanding of the

project Facilitate sharing

Learn from each other Practice presenting

Midterm Presentations:Logistics March 6 and 8

Requests accepted Assignments will be made at team meetings

15 minute presentations (excluding set up)

Copies of charts to be posted on website

Full attendance is expected

Presentations: The Basics

Speak loudly and clearly Stand up No chewing gum when speaking Speak, don’t read: you ARE the

experts Practice, practice, practice Set up and test demos and laptops

early

Presentations Hints

Cover all topics, but they don’t need equal time!

Focus on what’s special about your project

Don’t try to cover too much Keep it light Give the audience something to look

at

Presentations Grading

Content and style count Single grade for group Everyone does NOT need to

present

Presentation Content Motivation

Introduction to the area and project Key domain problems to be addressed

“Use Cases” Who are the users What do they need to do

Design System design and further detail as needed Key technical problems to be addressed Technologies being used (and why)

Demo: what you present to your customer this week Any interesting “why”s

Motivation

Tell the class about the problem

Information about the group Similar websites How things are done today What are the problems being faced Why is the project being done

Design

The first picture that you would draw for a new team member

Sharing with other teams Technologies Major problems (solved or open)

Examples of Architecture Pictures

Game Engine

Sound

File I/O

Controller I/O

VisualInterfac

e

Omega

CONTROL

Login

Monster

Combat

Breed

VerifyUser

Login

MODEL VIEW

Monster

Two links sent to me …

Humor: If Programmers Had to Build Planes http://www.flixxy.com/if-programmers-had-to-build-planes.

htm

Which would be funny except… F-22 Raptors http://it.slashdot.org/it/07/02/25/2038217.sh

tml

The Goal of Software Engineering

The right software, delivered defect free,

on time and on cost,

every time.

Software Craftmanship

Software craftsmanship (McBreen 2001) Craft of writing software Craft of using software

Distinguish from software engineering Scope Rigor

Relevant distinction?

Why Industry Practices?

Software engineering is the application of theory and practice of computer science project management engineering domains

Where better to look at application?

Software Engineering History

First key conference in 1968 Became important because of

perceived software crisis in productivity Cost and budget overruns (OS/360)

Morphed to issues of quality Financial implications (BoNY) Safety (Therac)

BoNY (1985)

BoNY (Bank of New York): Nation’s largest clearer of government securities

Software to track Federal securities transactions wrote new information on top of old.

Feds debited the bank for each transaction but bank did not know who owed it how much.

90 minutes => $32 Billion overdraft!

Cost of Bug Bank had to borrow $24 bill from federal

reserves. Interest paid ~$5 mill for 1 day. (Annual earnings of bank ~120 mill)

BoNY share prices dropped by 25c Federal funds rate dropped from 8.4%

to 5.5% System down for 28 hours. Fear of financial crisis caused increase

in price of platinum!

Cause of bug

Message buffer counter at BoNY system was 16-bit long.

Counters at Fed (and other banks) 32 bit.

More than 32,000 transactions that morning! =>Counter overflow

Securities database corrupted.

The Drama continues…

Trying to correct it – they copied corrupted data over the backup.

Lost a few hours because of this. Does code for error recovery get

tested at all?

Therac-25 (1985-1987) Medical linear accelerator

Used to zap tumors with high energy beams.

Electron beams for shallow tissue or x-ray photons for deeper tissue.

Eleven Therac-25s were installed: Six in Canada Five in the United States

Therac-25

Changes from Therac-20 Uses new “double pass” technique to

accelerate electrons…more deadly Machine itself takes up less space Software now coupled to the rest of the

system and responsible for safety checks.

Hardware safety interlocks removed. “Easier to use”

Therac-25 Turntable

Counterweight

Field Light Mirror

Beam Flattener (X-ray Mode)

Scan Magnet (Electron Mode)

Turntable

What Happened?

Six patients were delivered severe overdoses of radiation between 1985 and 1987. Four of these patients died.

Why? The turntable was in the wrong position. Patients were receiving x-rays without

beam-scattering.

What would cause that to happen? Race conditions.

Several different race condition bugs. Overflow error.

The turntable position was not checked every 256th time the “Class3” variable is incremented.

No hardware safety interlocks. Wrong information on the console. Non-descriptive error messages.

“Malfunction 54” “H-tilt”

User-override-able error modes.

Source of the Bug

Incompetent engineering. Design Troubleshooting

Virtually no testing of the software. The safety analysis excluded the

software! No usability testing.

Back to History

1960’s 60’s

“Cowboys” wrote software anyway that they could

Difference between best programmers and worst as high as 28:1 (many sources)

1968 Edsger Dijkstra, “GOTO Statement Considered

Harmful” (CACM) Recognition that rules can improves the average

programmer The start of software engineering?

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 Malcolm Baldridge National Quality Award

Why not apply to software development?

ISO 9000 What is ISO?

International body 150 national standards organization

US: ANSI Primarily technical standards Recent years has broadened its scope

Generic management system standards First published in 1987 Revision in 2000

Compendium of best practices Not the process but the management of the process

http://www.iso.org/iso/en/ISOOnline.frontpage

Which brings us back to

What is part of software engineering?

The 4 P’s of Software Engineering

Product: what is produced Process: the manner in which it

is done Project: the doing of it People: those doing it

Product Sales brochure Use cases and requirements Design document: from architecture to

detailed design Fully documented code Test plan and tools Manuals

Users Administrators

Process

Software Engineering Steps Software Engineering Processes Reviews and Inspections

Software Engineering Elaborated Steps

Concept Requirements Architecture Design Implementation Unit test Integration System test Maintenance

Software Engineering Processes

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

Three fundamental models Waterfall Spiral Iterative

Two widely used models Rational Unified Process (a.k.a. Unified

Software Development Process) Extreme Programming

Integrated Product Development:The IBM Approach

Originated at GE Key principles

Cross-functional teams at all phases Phased approval

Example checkpoints Concept Plan Ship Sunset

Rational Unified Process

Iterations within phases 4 phases

Inception (interaction with stakeholders) Elaboration (architecture and functions) Construction (initial operational) Transition (completed product)

Core workflows for each iteration Requirements Analysis (part of Requirements) Design Implementation (includes Integration) Test

Unified Process Matrix

ElaborationInception Construction Transition

Requirements

Analysis

Design

Implemen-tation

Test

Extreme Programming

Complete development process First code drop is 2-3 weeks after start Customer a part of the development

team Iterative development to the max Derive requirements with customer

through hands-on experimentation Agile methodology

Why XP?

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 Study

50% software projects challenged 2x budget 2x completion time 2/3 planned function

30% impaired Scrapped

20% success http://web.mit.edu/Saltzer/www/publications/

Saltzerthumbnails.pdf

Agile Methodologies

Keep only those rules and processes that help Antidote to bureaucracy License to hack

Key characteristics Adaptive People-oriented

Extreme Programming: History

Kent Beck considered the inventor Ideas developed in the early 90’s First project at Daimler Chrysler in

1996

XP Bills of Rights Developer has a right to

Clear requirements and priorities Determine how long a requirement will take to implement Revise estimates Always produce quality code

Customer has a right to An overall plan See progress in a running system Change requirements and priorities Be informed of changes to schedule and have input as to

how to adapt Cancel in the middle and still have something to show for

the investment