CS8300 Software Reliability and Safety

Lessons Learned

1. Tools and operating systems used in safety-related applications should be well chosen and industry proven. Using Visual Basic to develop a safety-related application running on Windows 3.0 was not a good idea, especially since safety in this case depended on speed of execution. Running a Windows operating system where speed is a concern is not recommended due to its non-preemptive environment. On top of that, the development team chose an unproven, recently released development tool that was designed primarily for prototyping and developing small, non mission-critical systems.

2. Applications need to be thoroughly tested before introduction to a safety-related environment. The original plan called for the LASCAD system to be fully implemented on set date (one would assume after complete testing). Due to the delayed time frame and the target date being missed, it was decided mid-stream that a phased implementation would take place where whatever was finished would be put into operation. During phase-in the system consistently showed itself to be buggy and unstable. Yet the decision was made to continue with the final phase and implementation of the fully automatic LASCAD system.

3. Safety-related software operators need a complete, well-developed training program to equip them for the job. It is generally recognized that operators of complex safety-critical applications receive intense training. While training was planned and implemented in the LASCAD project, it was too little and much too early. The training was neither consistent nor comprehensive with substantial skills decay between training and the operations. The software and its user interface had been modified between the time of the training and the operational environment. This was evidenced by the LASCAD staff’s frustration, overall lack of system confidence, and unfamiliarity with the system’s procedures and protocols