Mission Ready Software

Table of Contents

Module 1 -Software reliability fundamentals – Day 1 – Half day

In the first half-day of training, the class will learn the basics of software reliability. This module is a prerequisite for all other modules.

1. Why reliable software is important for defense applications
2. Software reliability defined
3. Standards available
4. Differences between hardware and software reliability
5. Myths and facts about software reliability

Module 2 – Assessing software reliability for a DoD software-intensive system – One day

The methods for assessing software reliability are different than for hardware because the software fails as a function of usage time and not calendar time.  The defects are predicted first.  Then the operational profile.   

A). Overview of methods for predicting software reliability

1. The RAM assessment – This method was developed for people in DoD acquisition who have limited exposure to software engineering. Our company invented it and it is available only via our training class.
2. Other methods recommended by the IEEE 1633 such as the Shortcut model, Full-scale model, Neufelder model. Our company invented these methods and these are available only via our training class.
3. Models that are outdated and should not be used.

B). Working session. The class will apply the RAM toolkit to an example DoD system.

This module can be taken in any order once the Getting Started module is complete. 

Module 3 – Determining a system reliability objective – Half day

System reliability objectives have historically been determined based on the hardware failure rates with some small buffer for software.  This doesn’t work with software-intensive systems.  This module will cover the methods for assessing the contribution of software to the total system before the software is even designed.  This provides for an early system reliability objective that addresses the failures from both software and hardware.

A). Methods for DoD personnel to determine the percentage of system failures due to software

1. 1. The proportion of system (customer) requirements that apply to the software
   2. The proportion of total R&D cost for software
   3. Historical percentages from prior systems if they exist
   4. Historical percentages as per Mission Ready Software database
   5. Achievable failure rates 

B). Identify a quantitative system reliability objective once the portion of failure due to software is known methods for incorporating the software into the overall system reliability objective

1. 1. Airborne systems
   2. Ground-based systems
   3. Ground-based vehicles

C). Methods for allocating the software reliability on the reliability block diagrams

1. 1. Establishing the software line replaceable units (LRUs) that should be modeled on the RBD.
   2. Software is rarely “redundant”. Understanding N version programming.
   3. How to model software that is in series with hardware
   4. How to model software that is in series with redundant hardware

This module can be taken in any order once the Getting Started module is complete. 

Module 4 – Tracking software reliability growth – Half day

Once the software is in a testable state the reliability can be directly measured and its growth can be tracked.  There are a variety of overly complex methods for software reliability growth.  In this class, we will present simple but effective methods.  

1. How to collect the software trouble report data
2. How to derive the time to failure occurrence
3. How to plot the data to see if the fault rate is increasing or decreasing
4. Two simple models for estimating the percentage of software defects that have already been found
5. Guidance for assessing the stability of the software based on: 

a). Its trend

b). How many estimated defects have already been found

c). How much testing has already been done

This module can be taken in any order once the Getting Started module is complete. 

Module 5 – Software Failure Modes Effects Analysis 1.5 Days

Software failure modes effects analysis are often conducted ineffectively, conducted too late in the development to be effective, conducted by the wrong personnel, conducted with the wrong failure modes, and at the wrong level of architecture.  This module will cover how to evaluate a software FMEA developed by a contractor as well as how to specify the software FMEA so that it is effective.

1. Understanding how software fails and how it’s effected the DoD
2. Understand the 17 mistakes people make when conducting software FMEAS
3. The process for conducting a software FMEA
4. The best time to conduct a software FMEA
5. The people who are needed to conduct the FMEA
6. How to tailor the FMEA to be cost effective
7. The approaches for conducting a software FMEA and when they are most appropriate – Top level, Capability level, Specification level, Interface level
8. How to assess likelihood of software failures

Module 7 – Statement of Work Language for software reliability – Half day

The students will receive SOW templates for software reliability.  These templates have been vetted by contract experts. Ideally this module is taken last.

     A). How to specify software reliability so that the DoD personnel get the data that they need when they need it

1. 1. Software failure data
   2. Software testing time data
   3. Software failure modes
   4. Software development plans, schedules, requirements, design, and test procedures are needed to assess the reliability

B). How to specify the software reliability tasks that you want the contractor to complete

1. 1. Software reliability program plan
   2. Software reliability predictions and growth modeling
   3. Software allocations
   4. Software reliability on the RBD
   5. Software FMEA

C). How to specify the reliability objective so that it’s clear that software will be considered in the acceptance of the system