The objectives of this document are:
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
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.
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.
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:
Non-deliverable software shall be developed using the same process unless a waiver has been granted and authorized by the acquirer.
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.
Where no issue is stated the latest issue shall take
The following lists documents which are functionally a part of the SDP but for reasons of maintainability have been partitioned into separate documents:
The documents referenced above shall be available from the project library.
In the event of conflict between the text of this document and the references cited above the text of this document shall take precedence.
A system/software development life cycle that includes
the following phases shall be implemented:
A description of the activities to be performed is provided in section 5.
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.
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:
Initially, the preliminary hazard analysis determines
the software level pertinent to the CSCIs of a specific system
or subsystem without regard to system design
Potential effects of user modification can be determined
by the preliminary hazard analysis. The following discusses options.
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:
Guidance for upgrading or re-engineering a development baseline includes:
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:
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.
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.
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:
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
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.
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'.
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.
The following documents shall be updated:
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.
Coding and testing of the individual software units in accordance with the coding and standards defined in the 'Software Engineering Manual'.
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.
The following documentation shall be prepared;
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:
Internal evaluation to be performed:
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.
The developer shall integrate the software units into components and test them in accordance with the instructions contained in the 'Software Engineering Manual'.
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.
Test teams shall perform the testing and provide
'Problem/change reports' in accordance with the 'Software Configuration Management Plan'.
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.
The developer shall prepare and record the test cases, test procedures, and test data for conducting CSCI/HWCI integration and testing.
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.
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.
(This section contains information of a general or explanatory nature that may be helpful, but is not mandatory).
List in alphabetical order definitions of words that have not been defined in a previously declared dictionary or project identified list.
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
The total number of visitors to this site since the 15th 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: firstname.lastname@example.org