a bugs life
play

A Bugs Life Definition Examples Computer Literacy 1 Lecture 16 - PDF document

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


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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