Failed software projects

Implementing enterprise software can be one of the most complex activities undertaken by a business. It is broadly regarded as high risk and fraught with potential problems. The horror stories of failed software projects are legion and the financial consequences have been punishing. In some cases these failures brought down a company. In other cases, the system was implemented but software problems caused multibillion-dollar losses. Even companies with world-renowned IT capabilities such as Nike, Hewlett-Packard, and Cisco can point to substantial software project related losses. 

The term software engineering was invented in the late 1960s after many large software projects failed to meet their goals. Since then, the field has grown to include... 

Too many software projects fail. One important reason, though not the only one, is the absence of a good specification. Specifications should be complete, consistent, comprehensible, and correct. Correctness can only be demonstrated if the specification is fonnal (so that reasoning can be supported) but the associated use of a formal language seriously reduces user comprehension, so there is a conflict between these two properties. We contend that formal mediods should be used but tliat their use should be totally concealed and automated, so tliat users are unaware of the underlying formality. 

Unfortunately, it is this writer s opinion that, considering the voluminous publications on chemometrics applications, the number of actual effective process analytical chemometrics applications in the field is much less than expected. Part of this is due to the overselling of chemometrics during its boom period, when personal computers (PCs) made these tools available to anyone who could purchase the software, even those who did not understand the methods. This resulted in misuse, failed applications, and a bad taste with many project managers (who tend to have long memories...). Part of the problem might also be due to the lack of adequate software tools to develop and safely implement chemometric models in a process analytical environment. Finally, some of the shortfall might simply be due to lack of qualified resources to develop and maintain chemometrics-based analytical methods in the field. 

The cost of integrating systems from different manufacturers often proved to be very expensive, and, as a result, many automation projects failed to meet the required return on incremental investment. The main problem was that computer systems were not designed to be integrated in an open manner. Integration projects were typically dominated by the need to write bespoke software to link different systems together. The costs of validating a standard-proven solution increased by a factor of ten. 

The answers to aU of these questions can have a profound impact on the success of the tool in an organization. One needs to be especitilly cttfeful in considering the last question. The human implications of introducing software tools in an oigemization are frequently underestimated. This underestimation has caused organizations to be unsuccessful in the introduction and implementation of these tools, resulting in wasted effort and dollars and in the frustration of those project sttikeholders who were affected by the failed effort. 

Availability, in general, is defined as the ability of the plant/equipment to perform its required function over a stated period of time. Maintainability is the probability that a failed item can be restored to operation effectiveness within a given period of time when repair action is performed as per the specified procedure (Smith, 2011). Software is available for performing RAM studies. For smaller projects, spreadsheets can be used. Reliability and process safety are interlinked, and so combined RAM and safety (RAMS) studies can be performed with the RAMS software (Sikos and Klemes, 2010). It considers many factors affecting the plant performance such as equipment performance, redundancy, demand requirements and logistics. RAM analysis is based on statistical failure data such as mean time between failures (MTBF), mean time to repair (MTTR), mean time to failure (MTTF) and mean down time (MDT). Wherever possible, failure data available within the company should be used for RAM/RAMS study. If not, typical failure data available in the literature/software can be used. 

In this paper the word limitation has been used as a general term to describe any difference fi om the ideal state of the evidence. Counter-evidence is defined in Defence Standard 00-56 as evidence with the potential to undermine safety claims. As Defence Standard 00-56 requires a pro-active search for counterevidence, a limitation needs to be considered as possible counter-evidence unless or until it can be shown that the safety claims are not undermined by that limitation. Suppose for example that a test has failed, and as a result a fault has been found in the software, this limitation (in the correctness of the software) might be counter-evidence. On the other hand if the fault is in some functionality that is not safety related, then it is likely that, fi om a safety perspective, the existence of tire fault is acceptable, and so this limitation is not counter-evidence. Any member of the project who is competent in a particular process area coidd record limitations and assess their impact in relation to the scope of that process. However, counterevidence is wholly related to flie safety of the product and must be assessed by a competent safety professional. Hence it is important that limitations are accurately and transparently recorded in the evidence generated by all of flie project processes and identified in the summary process documents, so that they can be assessed by a safety engineer. 

Random failure (see Chapter VII) Random failures are project specific in the sense that they depend on the process and its use. From lEC 61508 it is found that a failure occurs at a random time, which results from one or more degradation mechanisms. Random failures are mainly caused by physical damage/changes such as wearout, thermal stress erosion/corrosion, etc. These are applicable for hardwires of E/E/PEs in automation systems. The rate of failure of random failures normally cannot be reduced instead for random failures focus should be on their detection and handling. Statistical data handling and treatments can be applied to random failures, hence risks associated with random failure can be calculated. This is not possible in the case of software with systematic faults. Common cause failure (see Chapter VII) This is a kind of fault that causes multiple devices/systems to fail simultaneously. Common cause failure may be random or systematic. This is discussed in Fig. 1/8.3-1 in Chapter I, Chapter Vll, and in Ref. [9]. 

The inevitable lateness and poor quality of the software coming from this team is primarily a result of management failing to pay attention to the factors (1), (2) and (3) above. This failure results in lack of motivation on the part of individuals and the team as a whole, which, in tinn, affects newcomers to the project. There is a gradual decline in the average ability of the team because the most able tend to be the ones who leave first. 

The survey also revealed that a total of 18 different software shells were used by the developers, with each developer again tending to stay with a specific shell once a project had started. Most systems were developed and distributed on personal computers (PCs), which is very different from the practice reported during the early days of ES development. Seven systems were available for purchase at the time of the MTI survey, but the survey failed to request information on the validation of the products themselves. 

---