26
CSCI-6961/ECSE-6780: Software Engineering II Class: Mondays and Thursdays 4-5:20 pm, Carnegie 201 Instructor: Ana Milanova Email: [email protected] Office: Lally Hall 314 Phone: 518-276-6887 Office hours: Wednesdays 12-2pm, or by appointment • Web: www.cs.rpi.edu/~milanova/csci6961/ • Syllabus: www.cs.rpi.edu/~milanova/csci6961/syllabus.html

CSCI-6961/ECSE-6780: Software Engineering II

  • Upload
    carney

  • View
    66

  • Download
    0

Embed Size (px)

DESCRIPTION

CSCI-6961/ECSE-6780: Software Engineering II. Class: Mondays and Thursdays 4-5:20 pm, Carnegie 201 Instructor: Ana Milanova Email: [email protected] Office: Lally Hall 314 Phone: 518-276-6887 Office hours: Wednesdays 12-2pm, or by appointment Web: www.cs.rpi.edu/~milanova/csci6961/ - PowerPoint PPT Presentation

Citation preview

Page 1: CSCI-6961/ECSE-6780: Software Engineering II

CSCI-6961/ECSE-6780:Software Engineering II

• Class: Mondays and Thursdays 4-5:20 pm, Carnegie 201• Instructor: Ana Milanova• Email: [email protected]• Office: Lally Hall 314• Phone: 518-276-6887• Office hours: Wednesdays 12-2pm, or by appointment

• Web: www.cs.rpi.edu/~milanova/csci6961/• Syllabus: www.cs.rpi.edu/~milanova/csci6961/syllabus.html

Page 2: CSCI-6961/ECSE-6780: Software Engineering II

What is Software Engineering II?

• Catalog: Current techniques in software engineering with topics selected from economics, reusability, reliable software, program analysis, reverse engineering, CASE tools, automatic code generation, and project management techniques.

• Our focus: Program analysis and its applications to software engineering, especially towards techniques and tools for improving software quality and reliability

Page 3: CSCI-6961/ECSE-6780: Software Engineering II

Program Analysis

• Program analysis is a technique that reasons about the run-time behavior of the program– Static program analysis – reasoning is done statically,

before program execution– Dynamic program analysis – reasoning is done

dynamically, during program execution

• We will focus on static program analysis– Traditional application – compiler optimization– New application – software engineering tools, especially

tools for improving software quality and reliability

Page 4: CSCI-6961/ECSE-6780: Software Engineering II

Software Quality and Reliability • Development

– Requirements Analysis– Domain Analysis– Design– Implementation

– Testing/Validation

• Maintenance– Enhancements– Bug fixes– Etc.

Only about 5 to 10% of cost!

90 to 95% of cost!

DEPLOYMENT/RELEASE

Page 5: CSCI-6961/ECSE-6780: Software Engineering II

Economic Impact

• National Institute of Standards and Technology study– On CNN.com – April 27th, 2003

– “Last year, a study commissioned by the National Institute of Standards and Technology found that software errors cost the U.S. economy $59.5 billion annually, or about 0.6 percent of the gross domestic product. More than half the costs are borne by software users, the rest by developers and vendors.”

Page 6: CSCI-6961/ECSE-6780: Software Engineering II

Beyond Dollar Costs• “Software Engineering: Report on a Conference

Sponsored by the NATO Science Committee, Brussels, NATO Scientific Affairs Division,” 1968, p. 121– An error in an aircraft design program contributed to

several serious air crashes

• “Software and its Impact: A Quantitative Assessment,” by B.W. Boehm, Datamation, 19(5), 48-59 (1973)– Errors in medical software have caused deaths

Page 7: CSCI-6961/ECSE-6780: Software Engineering II

Expectations

• Can’t we expect software to execute correctly?

• Carefully made programs– 5 faults/1000 LOC– 5000 faults/1M LOC

• Windows XP has about 45M LOC– 45 x 5000 = 225,000

Page 8: CSCI-6961/ECSE-6780: Software Engineering II

Goals of the Course

• Learn about techniques for testing and validation– Software testing --- systematic execution of the

software• Learn/review fundamentals of testing

– Static program analysis --- track flow of control and data without execution of the software

• Learn some theory of program analysis, learn about applications of program analysis towards testing and validation

• Traditional static program analysis (data-flow analysis)

– Dynamic program analysis --- track flow of control and data during execution of the software

Page 9: CSCI-6961/ECSE-6780: Software Engineering II

Syllabus• Course Material

– Static Program Analysis– Fundamentals of Software Testing– Dynamic Program Analysis

• Expected Work– Project (50%)– Midterm (20%)– Homework (15%)– Presentation of a research paper (15%)

• Textbooks

Page 10: CSCI-6961/ECSE-6780: Software Engineering II

Prerequisites• SD&D/Software Engineering I

• Java – Helpful to know, but other OO programming

will work too

• You will need a UNIX account on the CS system for the class project– Let me know if you don’t have one

Page 11: CSCI-6961/ECSE-6780: Software Engineering II

Testing: Decades of Experience

Test Case

Software Under Test

Output

Good Coverage?

Test case Generation(can be automated)

Validation(can be automated)

Yes

No

Executes the software.

Page 12: CSCI-6961/ECSE-6780: Software Engineering II

Limitations of Testing• Not enough!

• Kinds of bugs difficult to reveal with testing– Resource leakage bugs

• Buffer overflows• Memory leaks

– Concurrency related bugs• Data races• Atomicity violations• Deadlocks

Page 13: CSCI-6961/ECSE-6780: Software Engineering II

Static Program Analysis: Recently

StaticAnalysis Tool

Warnings

Specification --- what bugs to look for?

(optional)

Examine warningsand fix bugs

Software Under Check

Examines the source code,without execution.

Page 14: CSCI-6961/ECSE-6780: Software Engineering II

A Growing Area…

• Microsoft – investment in static analysis tools for C/C++ with good results

• IBM – less, mostly in the J2EE area (some tools are available through the Eclipse project).

• NASA, US Navy

• Successful companies with hundreds, even thousands of clients

Page 15: CSCI-6961/ECSE-6780: Software Engineering II

Our class, once again: techniques for improving software quality and

reliability• Static program analysis (data-flow analysis)

– Theory, applications and tools

• Fundamentals of software testing– Review testing techniques, apply data-flow

analysis in testing

• Dynamic analysis– Applications and tools.

Page 16: CSCI-6961/ECSE-6780: Software Engineering II

Some Notable Software Bugs…

• A collection of notable software bugs– Thanks to Atif Memon, University of Maryland

Page 17: CSCI-6961/ECSE-6780: Software Engineering II

Mars Climate Orbiter

• Purpose: to relay signals from the Mars Polar Lander once it reached the surface

• Disaster: smashed into the planet instead of reaching a safe orbit

• Why: Software bug – failure to convert English measures to metric values

• $165M

Page 18: CSCI-6961/ECSE-6780: Software Engineering II

Shooting Down of Airbus 300

• 1988

• USS Vincennes shot down an Airbus 300

• Mistook the Airbus 300 for an F-14

• 290 people dead

• Why: Software bug --- cryptic and misleading output displayed by the tracking software

Page 19: CSCI-6961/ECSE-6780: Software Engineering II

THERAC-25 Radiation Therapy

• THERAC-25, a computer controlled radiation-therapy machine

• 1986: two cancer patients at the East Texas Cancer Center in Tyler received fatal radiation overdoses

• Why: Software bug --- a race condition (i.e., miscoordination between concurrent tasks)

Page 20: CSCI-6961/ECSE-6780: Software Engineering II

London Ambulance Service

• London Ambulance Service Computer Aided Dispatch (LASCAD)

• Purpose: automate many of the human-intensive processes of manual dispatch associated with ambulance service– Functions: Call tracking

• Failure of the London Ambulance Service on 26 and 27 November 1992

Page 21: CSCI-6961/ECSE-6780: Software Engineering II

“Nice of You to Turn Up”

• Load increased• Emergencies accumulated• System made incorrect allocations

– More than one ambulance being sent to the same incident

– The closest vehicle was not chosen for the emergency

• At 23:00 on November 28 the LAS eventually went to a back-up procedure after at least 20 patients die

Page 22: CSCI-6961/ECSE-6780: Software Engineering II

More…• “The development of software for ballistic-missile

defense,” by H. Lin, Scientific American, vol. 253, no. 6 (Dec. 1995), p. 48

– An Air New Zealand airliner crashed into an Antarctic mountain

– North American Aerospace Defense Command reported that the US was under missile attack; traced to faulty computer software that generated incorrect signals

– Manned space capsule Gemini V missed its landing point by 100 miles

Page 23: CSCI-6961/ECSE-6780: Software Engineering II

More• “Ghost in the Machine,” Time Magazine, Jan. 29,

1990. p. 58– Dallas/Fort Worth air-traffic system began spitting out

gibberish in the Fall of 1989 and controllers had to track planes on paper

• Software Reliability: Principles and Practice, p. 25, by G. J. Myers– Apollo 8 spacecraft erased part of the compute

r’s memory– Eighteen errors were detected during the 10-

day flight of Apollo 14

Page 24: CSCI-6961/ECSE-6780: Software Engineering II

More…

– An error in a single FORTRAN statement resulted in the loss of the first American probe to Venus

– An Airbus 320 crashes at an air show– A China Airlines Airbus A300 crashes on April

26, 1994 killing 264– Ariane 5 satellite launcher malfunction was

caused by a faulty software exception routine

Page 25: CSCI-6961/ECSE-6780: Software Engineering II

More…

• CNN.com– A poorly programmed ground-based warning

system was partly responsible for the 1997 Korean Air crash in Guam that killed 228 people

– Faulty software in anti-lock brakes forced the recall of 39,000 trucks and tractors and 6,000 school buses in 2000

• AND MANY MORE OF COURSE…

Page 26: CSCI-6961/ECSE-6780: Software Engineering II