CSCI6964ECSE6780: Software Engineering II

1
CSCI-6964/ECSE-6780Software Engineering II

• Class Mondays and Thursdays 4-520 pm, SAGE 2112
• Instructor Ana Milanova
• Email milanova_at_cs.rpi.edu
• Office Lally Hall 314
• Phone [phone]
• Office hours Thursdays 1-3pm, or by appointment
• Web www.cs.rpi.edu/milanova/csci6964/
• Syllabus www.cs.rpi.edu/milanova/csci6964/syllab
  us.html

2
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
  building techniques and tools for finding
  software errors early

3
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
• Emerging application software engineering
  tools, especially tools for finding errors early

4
Finding Errors (Bugs) Early?

• Development
• Requirements Analysis
• Domain Analysis
• Design
• Implementation
• Testing/Validation
• Maintenance
• Enhancements
• Bug fixes
• Etc.

Only about 5 to 10 of cost!
DEPLOYMENT/RELEASE
90 to 95 of cost!
5
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.

6
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

7
Expectations

• Cant 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

8
Goals of the Course

• Learn about state-of-the art techniques in
  testing and validation
• Software testing --- systematic execution of the
  software
• Learn/review fundamentals of testing
• Static program analysis --- track flow of control
  and flow of 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)
• Formal static program analysis (model checking)

9
Syllabus

• Course Material
• Traditional Static Program Analysis --- less
  powerful, but can be applied on large systems
  (millions LOC)
• Fundamentals of Software Testing
• Formal Static Program Analysis --- more powerful,
  but can be applied only on relatively small codes
  (1-2K LOC)
• Expected Work
• Project (50)
• Midterm (20)
• Homework (15)
• Presentation of a research paper (15)
• Textbooks

10
Prerequisites

• Good to have an SDD/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 dont have one

11
Testing Decades of Experience
Test Case
Executes the software.
Test case Generation(can be automated)
Software Under Test
Output
Good Coverage?
No
Validation(can be automated)
Yes
12
Limitations of testing

• Not enough!
• Kinds of bugs difficult to reveal with testing
• Memory/type-safety bugs (C/C)
• Buffer overflows
• Memory leaks
• Null pointer dereferences
• Concurrency related bugs
• Data races
• Deadlocks
• And many more

13
Static Program Analysis Recent Experience
StaticAnalysis Tool
Software Under Check
Specification --- what bugs to look
for?(optional)
Examines the source code,without execution.
Warnings
Examine warningsand fix bugs
14
A Growing Area

• Microsoft substantial 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 and the US Navy
• Numerous successful companies with hundreds, even
  thousands of clients

15
Our class, once again Techniques and tools for
finding bugs early

• Traditional static analysis (data-flow analysis)
• Learn theory, applications and tools.
• Fundamentals of software testing
• Learn/review
• Formal static analysis (model checking)
• Learn theory, applications and tools.

16
Some Notable Software Bugs

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

17
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

18
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

19
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)

20
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

21
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 2300 on November 28 the LAS eventually went
  to a back-up procedure after at least 20 patients
  die

22
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

23
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 computers
  memory
• Eighteen errors were detected during the 10-day
  flight of Apollo 14

24
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

25
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

26
(No Transcript)