Aims of the module
Failed example 1: Ariane 5
European Space Rocket exploded during launch on 4 June 1996
Small programs: can be written in an ad-hoc way
Large programs: need to be systematic
Reasons:
Module will describe how to get it right
• overflow occurred in the inertial ref system (SRI) computer
converting a 64-bit floating to 16-bit signed integer
Two important points:
• no error handler ⇒ SRI shut down
• standby SRI unit shut itself down for same reason (running same
software)
• How to specify the desired behaviour of the program
• How to break a large program into smaller pieces
ter
• flight path computations wrong, rocket disintegrated
2
4
Eike Ritter
Fundamentals of Computer Science, i.2:
Programming Methodology
Examples of Program Sizes
• find the average of a list of numbers:
1 hour
• produces an alphabetically-ordered frequency count of all
identifiers in Java:
several weeks
Eike Ritter
University of Birmingham
2-hour Lecture Course in Semester 1 2004/2005
Tuesday, 4pm
Wednesday, 11.00am
• compiles a source program in a small high-level language:
0.5–1 year
• runs an on-line reservation system for an airline company:
5 years
Examination: 100% written examination in May (a third of the
marks for Fundamentals in Computer Science)
There will be an exercise sheet every two weeks
ter
• operating system for a mainframe computer:
100 years
⇒ have very large and complex systems which require teamwork
1
Eike Ritter
3
Failed Example 2:
London Ambulance Service
Underlying Reasons for Problems
Hardware is getting more and more powerful:
processor power doubles every 18 months (Moore’s Law)
memory capacity doubles every two years
but structure unchanged (still van Neumann-architecture of 1945)
components more tightly packed
Aim: Automation of despatch of Ambulances
System collapsed immediately after becoming operational:
• Location of vehicles could not be tracked
• Database incorrect
leads to demands for more and more complex software:
• Units were despatched non-optimally
• Several units assigned to same call
• large databases
System generated too many messages and collapsed under its own
weight.
Eventually manual despatch resumed.
• distributed systems (eg WWW)
• safety-critical systems
Structure very different: large system inherently more complex than
small system (very different interaction between components)
6
ter
8
Eike Ritter
London Ambulance Service, cont.
Ariane (continued)
Reason: Bad Software Management:
• Software incomplete and untested
• inappropriate and unjustified assumptions made during
specification
Faulty code working and necessary in Ariane 4
Changed requirements produced wrong results for Ariane 5
• Contract awarded to small software house, with no previous
experience
• no full-time professional project management
Was not detected during testing procedures
Error control mechanism geared towards hardware failures (random),
not software failures (systemic)
ter
• lack of consultation with users
• poor fit with organisational structure of ambulance service
• Attempt of changing working practices through computer system
backfired badly
• Pressure to complete project within unrealistic timetable
5
Eike Ritter
7
Peculiarities, contd.
In standard engineering, can avoid this to large extent:
Steering wheel at car
Have continuous phenomena
⇒ cannot apply standard techniques from Elec Eng, Civil Eng for
dealing with continuous phenomena
⇒ Require new methods and new techniques
ter
10
Peculiarities of Software
Definition of Software Engineering
Big Problem: Small errors in software can have big effects :
Software Engineering is the establishment and use of sound
engineering principles to obtain software which is
• Ariane 5
• if (AccountBalance > RequiredMoney) then pay else
refuse
• reliable;
• working efficiently on real machines;
Underlying phenomenon:
Software is discrete
ter
• cost-effective to produce.
9
Eike Ritter
11