Topics Bugs A Bugs Life Definition Examples Computer Literacy 1 Lecture 16 Algorithms Foundation of computer programs 27/10/2008 All applications are programs Software design Minimising the impact of bugs Minimising human error Computer bug Early bug: IEFBR14 Unwanted property of program code or IEFBR14: One line of code for an IBM hardware mainframe computer used in the 70’s Especially when it causes a malfunction Instruction of code: Bugs are common “Do nothing” (e.g. wait for a short time) In Windows 98 Microsoft supposedly fixed 3000 Contained a bug! bugs Forgot to prepare the memory for the next In 2000 a leaked memo from Microsoft revealed instruction that Windows 2000 was released with 20,000 Subsequent instructions go wrong bugs Bugs can be unwanted security holes 1
Bugs: Patriot missile Computer programs Error calculating time since the computer Computers are excellent at following booted instructions Binary representation of 0.1 seconds limited Follow your command literally to 24 bits Can solve problems quickly Once activated, navigation system drifts Major difficulties are Gulf War in 1991 Expressing problems that can be solved by Caused a patriot missile to fail to intercept a efficient algorithms Scud missile Giving the computer the correct instructions 28 people were killed and 100 injured Making the program user friendly Bugs in programs Bugs: Ariane 5 flight 501 Cost Memory leak $500 million of satellites on board Forget to release memory after it had been used (e.g. IEFBR14) The bug Other easy/common mistakes “Type conversion error” A 64-bit number was converted in a 16-bit number Variable not set to the right initial value The value of horizontal position was lost Loops that never ends Ariane self-destructs correctly Spelling mistakes The error Usually prevented by the code not compiling Code not meant for that flight? Not always (Mariner 1) 2
Ariane 5 Flight 501 Software bug halts F-22 Flight On February 11, 2007 twelve raptors flying from Hawaii to Japan were forced to turn http://www.youtube.com/watch?v=IONcgYzV back because of a software glitch Flg Their computers crashed when they crossed Year was 1996 the international date line! They had to turn around an follow their tankers by visual contact back to Hawaii Less dramatic but happened Mariner 1 On August 28, 1993, 2a.m. clocks in some Mariner 1 should have been an spacecraft on PCs in Israel are suddenly loosing an hour a Venus flyby mission On October 24, 1993, at 2a.m. some PCs in Instead a security officer called its destructive the UK don’t turn back their clocks like they abort 293 seconds after its launch were supposed to It’s claimed that the bug was a single sign in the code that was wrong: DO 17 I = 1.100 should have been DO 17 I = 1,100 3
Remember Software design process Ariane : Program was doing the right thing in Requirements : statement of the problem the wrong rocket - error in requirement Validation Change from summer to winter-time : Specification : statement of what to do Program was correctly doing the wrong thing Verification - error in specification Implementation : doing it F-22, Mariner : Programme(r) made a Design, Testing mistake - error in implementation When it all goes wrong Fault tolerant systems Fault - an error lurking in the program Creating fault free systems Difficult and time-consuming Fault tolerant systems operate successfully Error - fault is triggered despite faults Software: Failure - program takes inapproriate action Keep multiple copies of (back-up) the data as a result Identify and monitor critical variables Checkpointing: reset system to a stored set of values 4
Software design: Waterfall model Iterative design model At each stage Analyse the problem: Design Prototype Evaluate Redesign Design solution architecture All stages developed concurrently, with feedback between Design solution details all stages Advantages Write program code User-defined from start Test code Performance can be measured much earlier Maintain code Problems Time consuming Requires good management Beta testing IT systems development Difficult initial problem analysis Refers to 2nd phase of software testing IT systems supplement existing practice Sample of intended audience test the product Easy to be over-ambitious It works for the programmer, does it work for the Goals can change user? Practical difficulty of establishing user’s goals Changing technology Provides a “preview” of software Technology is quickly obsolete Dedicated website: www.betanews.com Limited experience with new technology Complexity Large programs use ~100,000 of code High staff turnover 5
During the implementation Post implementation Analysis of any problem Monitoring calls with business What was their problem? Schedule of events checking What was done to resolve them? Formal checkpoints Are any further fixes needed? Business checkout Monitoring of ongoing system performance Incident management. Formal control of any Are the transactions being processed correctly? problems How is the business getting on with the system? Has it been well received? Go / No Go decision Is everyone able to use it easily? Ensure all in place for staff to use Any further action needed? London Ambulance Fiasco 1992 LAS Fiasco The London Ambulance (LAS) Computer Aided A series of errors were made in the Dispatch failed dramatically on October 26 1992 procurement, design, implementation, and shortly after it was introduced introduction of the system. The system could not cope with the load placed on it by There appears to have been NO backup normal use procedure at all The response to emergency calls was several hours Design of user interface was inadequate Ambulance communications failed and ambulances were lost from the system No consideration was given to system overload 6
Key points Bugs result from human-computer interactions There are many causes Techniques exist to try and control the effects of bugs Changes need planning 7
Recommend
More recommend
