Human error software engineering

A more careful comparison has also been made. JAXA (the Japanese Space Agency) and MIT engineers compared the use of STPA on a JAXA unmanned spacecraft (HTV) to transfer cargo to the International Space Station (ISS). Because human life is potentially involved (one hazard is collision with the International Space Station), rigorous NASA hazard analysis standards using fault trees and other analyses had been employed and reviewed by NASA. In an STPA analysis of the HTV used in an evaluation of the new technique for potential use at JAXA, all of the hazard causal factors identified by the fault tree analysis were identified also by STPA [88]. As with the BMDS comparison, additional causal factors were identified by STPA alone. These additional causal factors again involved those related to more sophisticated types of errors beyond simple component failures and those related to software and human errors. 

For Level-I PRA tools, the most commonly known used by the nuclear industry include CAFTA for FTA, ETA-II for ETA, and fhe HRA calculator for human error analysis. The Idaho National Engineering Laboratory developed for the NRC a software package called the Systems Analysis Programs for Hands-on Integrated Reliability Evaluations (SAPHIRE). The features of the SAPHIRE package include FTA, ETA, and imcertainty analysis. 

Three nonsafety tools are used in safety analysis failure modes, effects, and criticality analysis (FMECA) human factors analysis and software analysis. Because these techniques are extremely helpful in finding eqnipment failures, human errors, and software mistakes, safety engineers have coupled them to their safety analyses. It is definitely worthwhile to understand how these tools can benefit you. 

Smidts, C. A stochastic model of human errors in software development impact of repair times. In Proceedings of the 10th International Symposiiun on Software Reliability Engineering (ISSRE 1999), pp. 94-103 (1999)... 

The mental models of the system developers are also important. During software development, for example, the programmers models of required behavior may not match the engineers models (commonly referred to as a software requirements error), or the software may be executed on computer hardware or may control physical systems during operations that differ from what was assumed by the programmer and used during testing. The situation becomes more even complicated when there are multiple controllers (both human and automated) because each of their process models must also be kept consistent. 

---