introduction
play

Introduction Bugs CL1 23: Definition Examples Getting it - PDF document

Introduction Bugs CL1 23: Definition Examples Getting it right and Algorithms getting it wrnog Foundation of computer programs All applications are programs Monday 13/11/2006 Software design Minimising the


  1. Introduction • Bugs CL1 23: – Definition – Examples Getting it right and • Algorithms getting it wrnog – Foundation of computer programs – All applications are programs Monday 13/11/2006 • Software design – Minimising the impact of bugs – Minimising human error! Bugs: Ariane 5 flight 501 Ariane 501 • Cost – $500 million of satellites on board • The bug – “Type conversion error” (Jargon!) – A 64-bit number was converted to a 16-bit number A – The value of the horizontal position was lost – Ariane self-destructs correctly cautionary • The error – Code not meant for that flight? tale A happy F-16 Well, almost … In simulation, software inverted aircraft as it crossed the equator 1

  2. Less dramatic but.. Computer Bug • On August 28, 1993, 2 a.m. clocks in • Unwanted property of program code or some PCs in Israel suddenly lost an hour. hardware • On October 24, 1993, at 2 a.m. some PCs • Especially when it causes a malfunction in the UK did not lose an hour. • Bugs are common Unfortunately everyone else was turning – “In Windows 98 Microsoft supposedly fixed back their clocks that morning. 3000 bugs.” PC Computing, Sept. 1998 – Bugs can be unwanted security holes Remember..? First Bug? • Ariane: Programme was doing the right • Moth found in the Mark II computer by Admiral Grace Hopper in 1947 thing in the wrong rocket – error in requirement • Summertime: Programme was correctly doing the wrong thing – error in specification • F-16, Mariner: Programme(r) made a mistake – error in implementation Software design process Early bug: IEFBR14 • Requirements: statement of the problem • IEFBR14: one line of code for an IBM mainframe computer used in 70’s – Validation (fails: Ariane 501) • Instruction of code: • Specification: statement of what to do – “Do nothing” (i.e. wait for a short time) – Verification (fails: date error) • Contained a bug! • Implementation: doing it – Forgot to prepare the memory for the next – Design, Testing (fails:f16 (nearly)) instruction – Subsequent instructions went wrong • Note: the F-16 bug was the only one • Fixed code increased code size to 4 bytes! caught 2

  3. Bugs: Patriot missile A few other causes • Error calculating the time since the • Evolutionary bugs (requirement drift) computer booted – Ariane, Patriot missile – Binary representation of 0.1 seconds limited • Human Interactions to 24 bits – USS Yorktown (data entry error), HMS • Once activated, navigation system drifts Sheffield (operational errors) • In the Gulf War 1991 – Caused a patriot missile to fail to intercept a • Communication Scud missile – Mars Orbiter: mixed imperial and Metric units – 28 killed, 100 injured • Most major failures have multiple causes Computer programs Bugs in programs • Computers are excellent at following • Memory leak instructions – Forget to release memory after it has been used • Other easy/common mistakes – Identify how to solve the problem – Variable not set to the right initial value – Use a computer! – Divide by zero: answer is infinity! • Major difficulties are – Get a number wrong by 1 – Expressing problems that can be solved – Loops that never end using efficient algorithms • Spelling mistakes – Giving the computer the correct instructions – Usually prevented by the code not compiling – Making the program user-friendly – Not always! (Mariner 1) Fault tolerant systems Mariner 1: • Creating fault free systems • Failed “because the line – Difficult and time-consuming should have • Fault tolerant systems operate successfully – DO 10 I=1.100 despite faults read • Hardware: back-up systems – DO 10 I=1,100” • Software: – Keep multiple copies of (back-up) the data – Identify and monitor critical variables • There’s rather more to it than – Checkpointing: reset system to a stored set of values that.. 3

  4. Example: Aircraft failure rates Software design: Waterfall model • Fatal accident rate Analyse the problem 1 death in 1,000,000 flying hours → Design solution architecture • System causes 10% of accidents → Design solution details • 100 critical systems in an aircraft → Write program code • Rate of failure → Test code 1,000,000 hours × 100 systems / 10% → Maintain code = 1 fatal fault in 1,000,000,000 system flying • Problems: hours – Original analysis is difficult Good enough? – Problems identified at the end can be expensive to fix Defensive programming Iterative design model • At each stage • Anticipate possible circumstances – Design → Prototype → Evaluate → Redesign – All stages developed concurrently, with feedback • Trust nothing between all stages – Check what you are being told e.g. • Advantages • angles between 0 and 359º • day-of month is between 1 and 31 – User-defined from the start – Check what you are telling others – Performance can be measured much earlier – Sanity checks on actions taken • Problems • Fail in predictable manner if fault occurs – Time consuming – Requires good management • Layered protection including hardware ‘back- stops’ Beta testing In the news … • Refers to the 2nd phase of software testing • Cost of Child Support Agency’s new – Sample of the intended audience tests the product computer system: – It works for the programmer, does it work for the – £456 million user? – Provides a “preview” of software: it’s free! Buggy! (Scottish parliament building: £431 million) • Emerging software: look for “Beta” versions • Unable to cope with the work load – At Google http://labs.google.com/ – Backlog of 30,000 cases per month – At MSN now: http://beta.search.msn.com/ – Dedicated Web site www.betanews.com/ • How could this happen? • [Beta is the second letter in the Greek alphabet. “Alpha” testing refers to the • Source: http://news.bbc.co.uk/1/hi/uk_politics/4020399.stm first phase: checking it works for the programmer] 4

  5. IT systems development Reporting problems • Difficult initial problem analysis • Relevant details: – IT systems supplement existing practice – Username – Easy to be over-ambitious – Goals can change – Date, Time – Practical difficulty of establishing user’s goals – Location • Changing technology – Computing environment (Operating system…) – Technology is quickly obsolete – Limited experience with new technology • The fault: • Complexity: – Observations – Large programs use ~100,000 lines of code – And separately, any inferences – High staff turnover Key Points • Computers solve problems using algorithms • Bugs result from human-computer interactions • Techniques exist to try and control the effects of bugs 5

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend