噿楍档敡吠獡扨浔-AccidentAnalysisWhattodo….ppt

Accident Analysis What to do… What not to do… CS 851 Michael TashbookNathanael Paul November 11, 2002 Quote for the day “Experience is waiting until we have had an accident ourselves.” Lee Hung-Kwong Accidents presented… R101 Airship (leaking hydrogen) Comet crashes (fuselage) Munich crash (de-icing and slush) 1972 Trident crash at Heathrow (stall) … Goals Common factors in aviation accidents Apply findings to accident analysis and software Errors in Aviation Kletz’ model 3 layer classification Technical Avoidance Improve management Not very good but better than nothing Let’s take a look at Trident crash at Heathrow of ‘72 Kletz Model “Recommendations” Learn from experience Do not take unnecessary risks in high-risk areas. Follow up known weaknesses… Simon says… Many recurring “recommendations” Provide better training “You get what you pay for.” Learn lessons of the past… of incidents (not just accidents). Don’t rush. Error on side of safety. Don’t ignore warnings. Turning them off? Politics’ involvement A software accident… Federal Reserve’s funds transfer system “Bankwire” Upgrade to help protect against overdrafts Software not ready. Ok for production 2 days later? No, not “stress tested.” Whatever… Fine on first day. By end of 2nd day, main file in new software heavily fragmented, consuming system resources Response time slowed Transactions of “double posted” items Comments on Kletz’ applied model Hard to find proper recommendations How many recommendations are necessary? Are some of these accident issues unique to software? Some of the same problems in the Bankwire accident as in aviation accidents Appendix 1 – Questions to ask during accident investigation WHAT equipment failed? HOW can we prevent failure or make it less likely? HOW can we detect failure or approaching failure? Apply these questions in using model for accident analysis Not what is the cause, but how can this accident be prevented from happening again? Classification of errors Identif