A Practical Approach to Software Reliability for Army Systems

The objective of this paper on Software Reliability (SWR) is to provide a practical approach to implementing a SWR program for Army software intensive system acquisition planning and subsequent software development activities. The goal of this paper will be to leave the reader with the understanding that there is no magic to implement a robust SWR strategy and also to show that there is an abundance of information available from a myriad of industry sources on the subject. I don't intend to list those sources here; the reader can just do an internet search. The point I am making is that like any good "Bootlegger", my intent is to "distill" various ingredients, in this case, industry knowledge on software reliability and adopt a strategy that bests suits my particular organization. This strategy can be adopted in its entirety or tweaked to suit specific organizational needs. Regardless of any strategy that is adopted, it is critical that appropriate statement of work or contract language needs to be specified when acquiring software from a supplier or developing it from an in-house source. Finally, like any idea this one needs a home. There were Software Reliability requirements in the Software Development Plan of a large, now cancelled, software intensive Army program but the requirements were nebulous and some of the reference documents were out of date. Unfortunately, a good number of software problems ultimately labeled "Software Reliability defects" caused both formal laboratory and field testing delays. A robust SWR program may have avoided those costly rework efforts and delays. Unlike System Safety (incl Software) (MIL-STD-882E) or Information Assurance Certification (DIACAP), there is no official mandate or specific policy for Software Reliability Process compliance for Army Programs. However, I did manage to defend getting SWR contract language into the Ground Combat Systems contract. It called for collaboration between software and reliability subject matter experts to take appropriate steps to include software into the reliability case for the system. I also managed to obtain one fulltime equivalent work year of SWR engineering support to the Program. It was like planting a seed and the fruits of this labor are yet to be realized but progress has been made.