1 IEEE P1633\AIAA R013A Recommended Practice on Software Reliability Status Report Norm Schneidewind, Naval Postgraduate School (chair) Dennis Lawrence, Lawrence Livermore Labs David Franklin, Boeing Canoga Park Allen Nikora, Jet Propulsion Laboratory

2 1. Goals Of The Revision –1. Complete the revision in PAR approved until 31 December –2. Evolutionary rather than revolutionary revision in order to meet goal 1. –3. Priority 1: Upgrade of existing models and concepts. –4. Priority 2: Addition of new models and concepts. Justify models by providing the items in the template used in IEEE

3 IEEE Standard Dictionary of Measures of the Software Aspects of Dependability Template 1 Definition (normative) 2 Variables (normative) 3 Parameters (normative) 4 Application (normative) 5 Data Requirements (normative) 6 Units of Measurement (normative) 7 Experience (informative) 8 Tools (informative)

4 2. Goals of the Revision –Priority 3: Extend, if feasible, the coverage of IEEE P1633\AIAA R013A over the entire software life cycle. –Divide plan into minimum requirements to accomplish and optional items, which are desirable, if we have time. –Be sensitive to the clauses in the document that are normative (i.e., conformance required) and informative (i.e., for your information).

5 1. Approach for the Revision The revised document should address all phases of the life cycle, including fielded use. The current version seems to address only the testing phase. –The existing document states in the introduction that it is intended for use in all phases from integration testing through operations. However, it is not clear how thoroughly operations are actually addressed. Review the document to see how well it handles the operational phase.

6 2. Approach for the Revision –If we address the complete life cycle, we will have to tie IEEE P1633\AIAA R013A into existing IEEE standards, probably –In the future, we will probably have to relate IEEE P1633\AIAA R013A and –Should we only include testing and operational use, but not earlier life cycle phases? There has been enough work done for earlier life cycle phases since the document was first published that material on this subject could be usefully included.

7 3. Approach for the Revision Recommendations for using models should drive the revision. The heart of the revised document should be the models. –Make sure that the material on the models is still correct, and then add in new models that have come along that would be applicable.

8 1. Criteria for Model Inclusion Develop criteria for model inclusion: Quality of Assumptions Capability Experience in real development efforts – this is an important criterion for inclusion, but a more detailed definition of the criterion is required. For instance, we will need to know how determine how much experience is enough and what type of experience is appropriate.

9 2. Criteria for Model Inclusion Published in a peer-reviewed publication – this is an important criterion for inclusion, but a more detailed definition of the criterion is required. Desirable to include models that address network and wireless software reliability.

10 Workshop on Software Assessment (In Conjunction with ISSRE 2003) 17 November, 2003 – Denver, CO The working group will lead an open forum to solicit comments on work accomplished to date and plans for completion of the revision. For details, contact Norm Schneidewind, Allen Nikora,