standard

This handbook provides uniform guidance requirements for establishing the extent of compatibility between an aircraft, specific stores, and suspension equipment and guidance to justify the airworthiness of stores for use on an aircraft. This handbook defines all the engineering data package requirements and provides standard test methodology, test instrumentation and data to be obtained from each test to establish the extent of aircraft/stores compatibility. By this standardization, responsible agencies may then be assured that a test run by any agency to this handbook will provide the same data they would require, thereby facilitating the transfer of data between agencies and eliminating the unnecessary duplication of tests. Figure 1 provides an outline for the certification process and figure 2 provides a generic timeline for the activities that are expected to take place during a certification project.

From IEEE Software Engineering Standards Collection:

IEEE Std 1298. This is Australian Standard AS 3563.1-1991. This standard establishes requirements for a software developer’s quality management system. It identifies each of the elements of a quality management system to be designed, developed, and maintained by the developer with the objective of ensuring that the software will meet the requirements of a contract, purchase order, or other agreement.

From IEEE Software Engineering Standards Collection:

Draft IEEE Std 1219. This standard defines the process for performing the maintenance of software. It prescribes requirements for process, control and management of the planning, execution and documentation of the software maintenance activities.

From IEEE Software Engineering Standards Collection:

This recommended practice provides individuals and organisations a process for the evaluation and selection of computer-aided software engineering (CASE) tools. The recommended practice addresses the evaluation and selection of tools supporting software engineering processes including project management processes, development processes and integral processes.

From IEEE Software Engineering Standards Collection:

IEEE Std 1074. This standard defines the set of activities that constitute the processes that are mandatory for the development and maintenance of software. The management and support processes that continue throughout the entire life cycle, as well as all aspects of the software life cycle from concept exploration through retirement, are covered. Associated input and output information is also provided. Utilisation of the processes and their component activities maximises the benefits to the user when the use of this standard is initiated early in the software life cycle. This standard requires definition of a user’s software life cycle and shows its mapping into typical software life cycles. It is not intended to define or imply a software life cycle of its own.

From IEEE Software Engineering Standards Collection:

IEEE Std 1063. This standard provides minimum requirements on the structure and information content of user documentation, It applies primarily to technical substance rather than to style. Users of this standard may develop their own style manual for use within their organisations to implement the requirements of this standard.

From IEEE Software Engineering Standards Collection:

Draft IEEE Std 1061. This standard provides a methodology for establishing quality requirements and identifying, implementing, analysing, and validating the process and product of software quality metrics. This standard does not prescribe specific metrics. It does include examples of metrics together with a complete example of the standard’s use.

From IEEE Software Engineering Standards Collection:

IEEE Std 1058.1. This standard specifies the format and contents of software project management plans. It does not specify the procedures or techniques to be used in the development of project management plans, or does it provide examples of project management plans, instead the standard sets a foundation for an organisation to build its own set of practices and procedures for developing project management plans.

From IEEE Software Engineering Standards Collection:

IEEE Std 1045. This standard defines a framework for measuring and reporting productivity of the software process. It focuses on definitions of how to measure software process productivity and what to report when giving productivity results. It is meant for those who want to measure the productivity of the software process for creating code and documentation products.

From IEEE Software Engineering Standards Collection:

IEEE Std 1042. The purpose of this guide is to provide guidance in planning Software Configuration Management (SCM) practices that are compatible with IEEE Std 828. The guide focuses on the process of SCM planning and provides a broad perspective for the understanding of software configuration management.

From IEEE Software Engineering Standards Collection:

IEEE Std 1028. Software reviews and audits are a basic part of the ongoing evaluation of software products as they pass along the software development life cycle. This standard provides direction to the reviewer or auditor on the conduct of evaluations. Included are processes applicable to both critical and non-critical software and the procedures required for the execution of reviews and audits.

From IEEE Software Engineering Standards Collection:

IEEE Std 1016. A software design description is a representation of a software system. It is used as a medium for communicating software design information. This recommended practice describes that documentation of software designs. It specifies the necessary information content and the recommended organisation for a software design description.

From IEEE Software Engineering Standards Collection:

IEEE Std 1012. This standard has a threefold purpose:

a. to provide, for both critical and non-critical software, uniform and minimum requirements for the format and content of Software Verification and Validation Plans (SVVPs);

b. to define, for critical software, specific minimum Verification and Validation (V&V) tasks and their required inputs and outputs that shall be included in SVVPs; and

c. to suggest optional V&V tasks to be used to tailor SVVPs as appropriate for the particular V&V effort.

From IEEE Software Engineering Standards Collection:

Software unit testing is a process that includes the performance of test planning, the development of a test set, and the measurement of a test unit against its requirement. measuring entails the use of sample data to exercise the unit and the comparison of the unit’s actual behaviour with its required behaviour as specified in the unit’s requirement documentation. This standard defines an integrated approach to systematic and documented unit testing. The approach uses unit design and unit implementation information, in addition to unit requirements, to determine the completeness of the testing. The standard describes a testing process composed of a hierarchy of phases, activities, and tasks. Further, it defines a minium set of tasks for each activity, although additional tasks may be added to any activity.

From IEEE Software Engineering Standards Collection:

This standard describes the form and content of a software engineering standards taxonomy. It explains the various types of software engineering standards, their functional and external relationships, and the role of various functions participating in the software life cycle. The taxonomy may be used as a method for planning the development or evaluation of standards for an organisation. It could also serve as a basis for classifying a set of standards or for organising a standards manual.

From IEEE Software Engineering Standards Collection:

IEEE Std 990. This recommended practice provides recommendations reflecting state-of-the-art and alternate approaches to good practice for characteristics of Program Design Languages (PDLs) based on the syntax and semantics of the Ada Programming Language. In this document, these are referred to as Ada PDLs.

From IEEE Software Engineering Standards Collection:

IEEE Std 982.2 is a companion to IEEE Std 982.1 and provides guidance in the use of the measures in IEEE Std 982.1. It provides information needed by industry to make the best use of IEEE Std 982.1.

From IEEE Software Engineering Standards Collection:

IEEE Std 982.1. This standard provides definitions of selected measures. The measures are intended for use throughout the software development life cycle in order to produce reliable software. The standard does not specify or require the use of any of the measures. Its intent is to describe the individual measures and their use.

From IEEE Software Engineering Standards Collection:

IEEE Std 830. This guide describes alternate approaches to good practice in the specification of software requirements. To enable the reader to make knowledgeable choices, extensive tutorial material is provided. This guide covers the attributes of a good software requirements specification, as well as specification methodologies and associated formats.

From IEEE Software Engineering Standards Collection:

IEEE Std 829. This standard defines the content and format of eight documents that cover the entire testing process. The test plan prescribes the scope, approach, resources, and schedule of the testing activities. It identifies the items to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan. Test specification is covered by three document types, while test reporting is covered by four document types. The standard shows the relationships of these documents to one another as they are developed, and to the test process they document.

From IEEE Software Engineering Standards Collection:

IEEE Std 828. This standard is similar in format to IEEE Std 730, but deals with the more limited subject of software configuration management. The standard identifies requirements for configuration identification, configuration control, configuration status accounting and reporting, and configuration audits and reviews. The implementation of those requirements provides a means by which the evolution of the software product items are recorded, communicated and controlled. This provides assurance of the integrity and continuity of the software product items as they evolve through the software development and maintenance life cycle.

From IEEE Software Engineering Standards Collection:

IEEE Std 730. This standard has legal liability as its basic rationale. It is directed toward the development and maintenance of critical software, that is, where failure could impact safety or cause large financial or social losses. The orientation is toward delineating all of the planned and systematic actions on a particular project that would provide adequate confidence that the software product conforms to established technical requirement. The standard establishes a required format and a set of minimum contents for software quality assurance plans.

From IEEE Software Engineering Standards Collection:

IEEE Std 610.12 is a revision and redesignation of IEEE Std 729. This standard contains definitions for more than 1000 terms, establishing the basic vocabulary of software engineering. Building on a foundation of American National Standards Institute (ANSI) and International Organization for Standardization (ISO) terms, it promotes clarity and consistency in the vocabulary of software engineering and associated fields.

MIL-STD-961D
22 MARCH 1995
SUPERSEDING
MIL-STD-961C
20 MAY 1988

METRIC
MIL–STD–462D
11 JANUARY 1993
_____________
SUPERSEDING
MIL–STD–462
31 JULY 1967

From Def Stan 00-40: "Reliability and Maintainability (R&M)" Part No: 1: Management Responsibilities and Requirements for Programmes and Plans: Issue 6:

The complete Def Stan 00-40 comprises:
Reliability and Maintainability
Part 1: Management Responsibilities and Requirements for Programmes and Plans

From Def Stan 00-40: "Reliability and Maintainability (R&M)" Part No: 1: Management Responsibilities and Requirements for Programmes and Plans: Issue 4:

Arrangement of Defence Standard 00-40

Part 1 - Management Responsibilities and Requirements for Programmes and Plans
Part 2 - General Application Guidance on the Use of NATO ARMP-1
Part 3 - Application of National R&M Documents
Part 4 - Guidance for Writing NATO R&M Requirements Documents
Part 5 - Guidance on R&M Training
Part 6 - In-Service R&M
Part 7 - NATO R&M Terminology Applicable to ARMPs (to be issued later)
Part 8 - Procurement of Off-the-Shelf Equipment

From Def Stan 00-35: "Environmental Handbook for Defence Materiel": Part No: 1: Control and Management: Issue 3:

Revision

Part 4 of the standard has been amended to include the supplementary '02' chapters aligned to Part 6.
Part 6 issued.
The content of this part of the standard has been revised to include previously published material.

Defence Standard 00-35 was previously published as a complete document as Issue 2 and is now
issued in separate parts to facilitate easier reference, amendment and distribution.

Defence Standard 00-35 comprises six Parts with each Part being divided into Sections and Chapters.
The six Parts are:

Part 1 Control and Management

Part 2 Environmental Engineering Rationales

Part 3 Environmental Test Methods

Part 4 Natural Environments

Part 5 Induced Mechanical Environments

Part 6 Induced Climatic, Chemical and Biological Environments

From Def Stan 00-35: "Environmental Handbook for Defence Materiel": Part No: 1: Control and Management: Issue 4

REVISION NOTE
This standard is raised to Issue 4 to update its content.

MIL-STD-882C
19 January 1993
_______________
SUPERSEDING
MIL-STD-882B
30 March 1984
W\ NOTICE 1
1 July 1987
MIL-STD-1574A
15 August. 1979

MIL-STD-882D
10 February 2000
_____________
SUPERSEDING
MIL-STD-882C
19 January 1993

MIL-STD-882B
30 March 1984
____________
SUPERSEDING
MIL-STD-882A
28 June 1977