Software Development Standards (SDS)

FOREWORD

The objectives of this document are:

• To establish a standardized and coherent process for the development of software for a specific project. It is intended that this document shall contain the eclectic requirements for the development as required by the contract requirements;
• To provide reference for common terminology and vocabulary for software development;
• To establish clear expectations between acquirer and developer. This standard shall establish common expectations about the process and documentation to be prepared.

The requirements of this standard shall be applicable to all phases of the software development life cycle. It shall be applicable for software to be developed, modified, reused, procured, prepared to other standards, or procured off-the-shelf.

The total documentation suite comprising the Software Development Standards may be referred to as the software: 'Project Standards', 'Quality Plan', 'Quality System', 'Management plan', or 'Standards' by various companies, national, and international organizations.

For more information see Software Development Plan

1. SCOPE

1.1 Identification.

This 'Software Development Standards' (SDS) document establishes the standard for the development, acquisition, and support of all software for the name of project project.
This standard will provide a concise and complete method for implementing a uniform software development process for all the software required by the project.

1.2 Purpose.

The purpose of this document is to define a uniform process by integrating the requirements if the various standardization documents prepared previously to develop software. It represents an eclectic interpretation of the requirements in these documents (DOD-STD-2167A), MIL-STD-498, RTCA/DO-178B, ISO 9001, JSP188, ISO 12207, etc., to fit the requirements for the acquisition, design, development, and maintenance process.

1.3 Overview of the document.

This standard has been prepared to meet the software development requirements for the project. It contains the eclectic requirements from several "standards" identified documents i.e., MIL-STD-498, ISO 9001, DEF STAN 05-91, RTCA/DO-178B, ISO 12207, JSP 188, etc. Its use is to specify "what-is" required to develop software whether it is being designed, procured, modified, reused, etc.
The 'Software Development Standards' shall be applicable for:

• System software (CDRL identified items)
• Software used to certify system, subsystem, HWCI, or CSCI, for example, inspection, test, evaluation, or other measuring equipment software;
• Simulations, models, emulation's used to establish product certification and performances;
• Communication and data transfer software;
• Data manipulation and analysis software;
• Machinery control software used during manufacture.

Non-deliverable software shall be developed using the same process unless a waiver has been granted and authorized by the acquirer.

1.4 Relationship to other plans and standard.

This standard will be compatible with the "Project Management System" standards and plans namely the 'Program Plan', 'Systems Engineering Management Plan', Configuration Management Plan, and 'Technical Documentation Standard'.

This standard requires the preparation of a common "project" set of plans and procedures to specify the "code of practice", "work instructions" and identification for the project.
See figure for an graphical illustration of the hierarchy.

In Netscape use the right mouse button to expand the figure.

2. REFERENCED DOCUMENTS

Where no issue is stated the latest issue shall take precedence.

• MIL-STD-498;
• DOD-STD-2167A;
• DO-178B;
• DEF STAN 05-91;
• ISO 9001;
• ISO 12207;
• DEF STAN 05-12;
• DEF STAN 05-31;
• DEF STAN 05-22;
• J-STD-016?
• etc.

2.2 Project documents.

The following lists documents which are functionally a part of the SDP but for reasons of maintainability have been partitioned into separate documents:

• Systems Engineering Management Plan;
• Configuration Management plan;
• Technical Documentation Standard;
• Software Engineering Manual
• Software Product Evaluation Plan
• Software Configuration Management Plan
• Other relevant specialist plans.

2.2 Source of documents.

The documents referenced above shall be available from the project library.

2.3 Order of precedence.

In the event of conflict between the text of this document and the references cited above the text of this document shall take precedence.

3. REQUIREMENTS

3.1 System/software development life cycle.

A system/software development life cycle that includes the following phases shall be implemented:

• System requirements analysis;
• System design
• Software requirements analysis;
• Software design (preliminary and detailed)
• Implementation and software unit testing;
• Integration and testing;
• CSCI testing;
• CSCI/HWCI integration testing;
• System integration and testing.

A description of the activities to be performed is provided in section 5.

3.2 Software safety considerations.

For systems that perform critical and essential functions it may not be possible to demonstrate an acceptable low level of software errors without the use of specific design techniques following preliminary hazard analysis. When such techniques are used, they shall be identified in the System/subsystem Specification and reflected in the Development Specifications.

3.2.1 Risk (level) classes.

Software level classes have been derived from 'DO-178B' which defines criticality categories and software levels. The risk classification of the software shall be based on a criticality analysis (preliminary hazard analysis), which shall be determined, at the beginning of the Software Requirements analysis phase by the responsible System Safety Technical Authority.
Software Level definitions shall be:

1. Level A; Software whose behaviour, as shown by the preliminary hazard analysis, would cause or contribute to a failure of system function resulting in a catastropic failure condition.
2. Level B; Software whose behaviour, as shown by the preliminary hazard analysis, would cause or contribute to a failure of system function resulting in a hazardous/severe-major failure condition of the aircraft.
3. Level C; Software whose behaviour, as shown by the preliminary hazard analysis, would cause or contribute to a failure of system function resulting in a major failure condition.
4. Level D; Software whose behaviour, as shown by the preliminary hazard analysis, would cause or contribute to a failure of system function resulting in a minor failure condition.
5. Level E; Software whose behaviour, as shown by the preliminary hazard analysis, would cause or contribute to a failure of system function with no effect.

3.2.2 Software level determination.

Initially, the preliminary hazard analysis determines the software level pertinent to the CSCIs of a specific system or subsystem without regard to system design

3.3 Considerations for procured software.

Potential effects of user modification can be determined by the preliminary hazard analysis. The following discusses options.

3.3.1 Upgrading a software product baseline.

The following provides guide-lines for CSCIs where documentation from a previous application are determined to be inadequate or do not satisfy the objectives of this document. These guide lines are applicable for:

• Commercial off-the-shelf (COTS) software
• Software developed to other standards or guide-lines;
• Software developed prior to the existence of this standard;
• Software previously developed to this (standard) document at a lower software level or risk classification.

Guidance for upgrading or re-engineering a development baseline includes:

• The objectives of this document shall be satisfied while taking advantage of documentation of the previous development that satisfy the objectives for the new application;
• Software aspects of certification shall be bases on the failure conditions and software level(s) as determined by the preliminary hazard analysis. Comparison to failure conditions of the previous application shall determine areas which may be needed to be upgraded;
• Documentation from a previous development shall be evaluated to ensure that the software verification process objectives of the software level are satisfying the objectives of this standard;
• Reverse engineering may be used to regenerate documentation

3.3.2 Modifications to previously developed software.

Software previously developed using these standards at the same software level the following guide-lines applies. Modifications may be a result from requirement changes, the deletion of errors and/or enhancements.
Analysis activities for the proposed modifications shall include:

• The revised outputs from the preliminary hazard analysis shall be reviewed considering the proposed modifications;
• If the software level is revised the considerations of 3.3.1 (Upgrading a software baseline) shall be considered;

3.3.3 Change of installation.

Systems or equipment containing software which has been previously certified at a certain software level and under a specific certification basis may be used in a new installation. The following provides guide-lines to be used foe a new installation.

3.3.4 Software product service history.

3.4 Considerations for security/privacy sensitive software.

CSCIs or portions of software whose failure may create a breach of system security/privacy shall be identified and a program plan established to assure that the requirements, design, implementation, and operating procedures will be minimized or eliminated for potential breaches.
The developer shall either record or identify the plan in the relevant 'Software Development plan' implement the strategy and prepare evidence, that the security assurance strategy has been carried out.

4. DETAILED REQUIREMENTS

4.1 System/software development life cycle.

This section defines the process(es) for the development, verification and validation of all software for the project.
The system/software development life cycle shall comprise of the following phases:

• System requirements analysis (software aspects only);
• System design
• Software requirements analysis;
• Software design (Preliminary design and Detailed design);
• Implementation and Unit testing;
• Integration and testing;
• CSCI testing;
• CSCI/HWCI integration testing;
• System integration and testing (software aspects only).

Note: the system requirements analysis and the System Integration and testing phases are not specifically software development phases, however, there will be activities relating to software aspects during these phases.

Figure 1 illustrate the basic elements of the system/software development life cycle. It must be noted that the system/software development life cycle is an iterative or recursive process; feedback loops are not shown in the figure because their inclusion would make the diagram to complex. The system/software development life cycle may overlap rather than form a discrete termination/initiation sequence.
The order of the requirements in this section is not intended to specify the order in which they must be carried out. Many activities may be ongoing at any one time; different software products may proceed at different paces.

4.2 System requirements analysis.

Although this phase is not a software specific development phase it has been included to identify the software activities that need to be performed.
During this phase the system requirements will be analyzed and documented in a System/subsystem specification(s).
After successful completion of the formal Systems Requirements Review (SRR and SDR) the System/subsystem specifications will establish the 'Functional Baseline' for each pre-determined system or subsystem.
As it is not usually possible to define the software requirements of complex systems at the first attempt, it may be necessary to adopt an iterative approach to design. Software prototyping is recommended prior to the commencement of the Engineering and Manufacturing development phase. All documentation prepared during the prototyping however shall be entered into the software library for future reference.
A 'Software Development Plan' for each CSCI should be prepared in accordance with the 'Documentation Standard'.
A system safety analysis shall be performed during this phase. This will assess the effect functional failures have on the systems or subsystems. Functions identified as having a high hazard severity will be subjected to a more detailed analysis. See 'Software Safety Analysis'.

4.3 System design.

4.4 Software requirements analysis.

4.4.1 Purpose.

To define and analyze a complete set of functional, operational, performance, interface, quality factors, design, criticality and test requirements for each CSCI or software contained within a HWCI.

4.4.2 Activities.

• Analysis of CSCI allocated requirement;
• Preparation of documents;
• Evaluation of analysis and documents prepared;
• Formal Review (SSR). if applicable

4.4.3 Documents.

• Software requirements specification;
• Interface requirements specification
• Operational concept description.

The following documents shall be updated:

• Software Development Plan;
• System/subsystem specification;

4.4.4 Verification.

4.5 Software design.

4.5.1 Purpose.

The purpose of the 'Software Design' phase is to define the software structure of a CSCI. Formal and informal test planning will be prepared. The results of this phase shall define the top-level components of the CSCI from the 'Software Requirements Specification' and 'Interface Requirements Specification(s).

The purpose of the detailed design is to detail the modular structure, the algorithms, low-level requirements, and the control and data structure completely.

4.5.2 Activities.

4.5.3 Documents.

4.6 Implementation and software unit testing.

4.6.1 Purpose.

Coding and testing of the individual software units in accordance with the coding and standards defined in the 'Software Engineering Manual'.

4.6.2 Activities.

Development
The coding and testing activities of this phase are usually performed on a host computer although some target testing may be necessary to prove critical functions.
Prior to the testing of each software unit the developer shall update, if necessary, the test procedure for conducting each informal Unit test and record the results in the updated 'Unit Test Description' document. Further test cases where the particular implementation reveals the need for tests not defined in the Detailed Design phase.

4.6.3 Documents.

The following documentation shall be prepared;

• Unit Test Report;
• Source code listing;
• Code Walkthrough Report;
• Software Test Procedure (preliminary)

The developer shall implement the software design into source code in accordance with the coding standards specified in the 'Software Engineering Manual'.
The developer shall test the code using the principles and methods identified in the Software Engineering Manual. Test shall be performed according to the requirements contained in the 'Unit Test Description' and according to the 'Software Test Plan'.
A record of the unit testing shall be recorded in the Unit Test Report.

Documents to be prepared:

1. Source Code listings
2. Unit Test Report
3. Software Test Procedure
4. Code Walkthrough Report

Internal evaluation to be performed:

4.7 Integration and testing.

4.7.1 Purpose.

During the Integration and testing phase, Software units of the software code shall be integrated and informal tests on aggregates of integrated Units shall be performed.

4.7.2 Activities.

The developer shall integrate the software units into components and test them in accordance with the instructions contained in the 'Software Engineering Manual'.

4.7.3 Documents.

4.8 CSCI testing.

4.8.1 Purpose.

The purpose of the CSCI testing phase is to merge the CSCI into hardware (HWCI) and verify that it complies with the requirements in this environment. Since some elements of a complete software release for a CSCI can only be tested on the Target Machine this integration phase represents the first opportunity to run the software as a complete release.

4.8.2 Activities.

4.8.3 Documents.

Test teams shall perform the testing and provide 'Problem/change reports' in accordance with the 'Software Configuration Management Plan'.

4.9 CSCI/HWCI integration and testing.

4.9.1 Purpose.

The activities described in this paragraph apply to the integration of the CSCI into its target HWCI.
The primary purpose of the phase is the Qualification (Verification and Validation) of CSCIs with interfacing HWCIs and CSCIs testing the resulting groupings to determine whether they work together as intended, and continuing this process until all CSCIs and HWCIs in the system are integrated and tested.

4.9.2 Activities.

The developer shall prepare and record the test cases, test procedures, and test data for conducting CSCI/HWCI integration and testing.

4.9.3 Documents.

4.10 System integration and testing.

4.10.1 Purpose.

The activities described in this paragraph apply mainly to the integration of software when being installed at a system level and is applicable only for the support of the software.
The primary purpose of the phase is the Qualification (Verification and Validation) of a complete system and/or its comprising subsystems. The aim of this activity is to show conformance with the functional and/or system/subsystem performance requirements in a functional environment.

4.10.2 Activities.

System and subsystem integration will develop and prove all software of the sub-system or segment on a step-by-step basis. Each individual system shall be built up gradually by the integration of each functional section following its validation.

4.10.3 Documents.

5. NOTES

(This section contains information of a general or explanatory nature that may be helpful, but is not mandatory).

5.1 Definitions used in this document.

List in alphabetical order definitions of words that have not been defined in a previously declared dictionary or project identified list.

5.2 Abbreviations used in this document.

List the abbreviations alphabetically that have been used in this document that have not been defined globally, for example, within an identified dictionary or project listing

5.3 Changes from the previous issue.

5.4 .

This page is under construction

The total number of visitors to this site since the 15^th of March 1998

Back to Home page MANAGING STANDARDS Home page

Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk