The engineering activity shall develop the technical elements of the CWBS/SOW.
A preliminary contract Work Breakdown Structure (CWBS) shall be prepared and structured by selection of appropriate elements from the approved project summary WBS. The contract line replaceable items (RUs), configuration items (HWCIs and CSCIs), contract work statement tasks (SOW), the contract system/subsystem specification (s), and contractor responses shall be expressed in terms of a preliminary CWBS.
A CWBS is defined as the complete WBS for a contract, developed, and used by a contractor in accordance with the contract work statement (SOW).
A specification tree which relates to the CWBS/SOW shall be prepared.
The System Specification tree shall be a top-down diagrammatic representation of the breakdown of specifications from the top specification (System Specification) to the lower level (subsystem, etc.) specifications defined at any phase and shall form a convenient medium for the cataloguing of applicable specifications.
The breakdown shall also show the inter-dependency of specifications throughout the whole of the system, and allow progressive follow-through of the requirements from specification to specification.
Specifications and associated documentation during Engineering, and Manufacturing development phase shall be identified using the 'Technical Numbering Standard' as identified in the 'Configuration Management Plan'.
For hardware and software at production release, deliverable specifications shall be allocated an identifier in accordance with the National Stock Number (NSN) scheme.
The specifications shall as a minimum comprise:
See figure 8 for an illustration of the Specification Tree.
Specification form - specifications shall be prepared in accordance with MIL-S-83490 and conform to the specification requirements specified in MIL-STD-490A, MIL-STD-970, MIL-STD-961D and DEF STAN 05-28/1 (Documentation Standard) unless otherwise specified by the acquirer.
On completion of the Concept Exploration and Definition phase, the Initial Baseline Build Standard (BBS) for the system shall be established.
The primary documents which form the initial BBS are the SOW, System Specification and its applicable documents, associated documentation and the Physical Baseline definition which reflects the specification and drawing tree. Together they form the Functional and Physical definition of the System (WS).
On completion of the Demonstration and Validation Phase the Design/Programme Requirements Baseline (DRB) and Development Component Baseline (DCB) shall be established. The DRB shall comprise of the System Specification(s) together with the applicable documents and relevant CDRL items. The DCB shall comprise of the SOWs, ICDs and a list of all specifications forming the various Development parts (HWCIs and CSCIs) which comprise the System and/or segments. See figure 9 for an example of a typical system breakdown.
As a result of Systems Engineering from the established Functional Baseline the System Requirements shall materialize in the form of diagrams, drawings, software/interface requirements specifications and hardware development specifications for the identified CSCIs and HWCIs.
Allocated Baselines shall comprise of the above for each HWCI and CSCI identified. For Computer Software the software/interface requirements specifications shall form the Allocated baseline for the specific CSCI to be developed and shall be established after successful completion of the Software Specification Review. For Hardware, the HWCI Development Specification for the specific HWCI shall form the Hardware Allocated baseline and shall be established before the Critical Design Review is scheduled to be performed.
As a result of the Software Engineering effort from the established CSCI allocated baselines the software design shall materialize in the form of Software Design Descriptions and Source Code listings documentation. These documents shall be entered into each of the CSCIs internal developmental configuration and change controlled using the process contained in the SCMP.
The Source Code shall be written in accordance with MIL-STD-1815A Ada Programming Language unless an authorized deviation has been identified.
On completion of the PCA of a CSCI the Software Design Description and Source Code listings shall have been demonstrated to have been incorporated into the Software Product Specification and establish with the CSCI executable object code the CSCI Software Product baseline. This baseline shall be change controlled using the processes defined in the CMP. The first formal release of the software (formal production release) shall be identified as Version 1.
The HWCI and CSCI Product Baselines shall comprise of all the "build-to" or "as-coded" and built, form, fit, and function requirements and the product acceptance tests and hardware Product specifications for the HWCIs together with the Software Product Specifications for the CSCIs.
The Production Baseline shall be established from these Product baselines after a successful System/segment PCA(s) (for example., LRU), and/or PRR, and shall form a component part of the Physical Baseline Build Standard for the System.
The Physical Baseline Build Standard (PBBS) shall be established in an incremental manner. Functional aspects (Specifications, etc.) shall be updated through the Configuration Management Change Control Processes.
The point in time when the PBBS must be established to achieve Contractual Status (Under Ministry Control)) must be carefully chosen.
Important aspects to be considered are:
They are clearly not entirely independent, and all aspects must be borne in mind. In general, it is required to wait until the System is design stable.
The system baselines formally define the total system
or comprising subsystems to which they are applicable. These baselines
will be establish a specific system life cycle milestone, from
which future changes are referenced.
These are identified as the "functional" baselines.
Allocated baselines are derived from the functional baselines and must be established to be used as milestones for the development of the system.
Product baselines are the design and implementation of their allocated baselines.
Although the internal developmental configuration*
is not a Systems Engineering Management function but a Configuration
Management function it has been identified here for visibility
and clarification purposes.
An internal developmental configuration* (Engineering and Manufacturing Development phase only) for each CSCI and HWCI shall be established at the first engineering release of; (1) the Software Design Description (SDD) produced against the CSCI specific Allocated Baseline (2) the Drawings (G.A, etc.,) produced against the HWCI Allocated baseline. The developmental configuration shall terminate at the establishment of the Product Baseline for each CSCI and HWCI.
The products entered into the internal developmental configuration for each CSCI and HWCI shall be maintained by the CMP identified Problem/Change Reports (PCRs) until their incorporation. The Problem/Change Report shall describe the corrective action needed and the actions taken to resolve the problem. Additional documents may be added to this list if approved but should not be automatic upon selection as a item or document. Note: for software only, the Software Design Description documents and Source Code listings shall be initially identified for configuration control.
Developmental configuration Change introduced by:
When the Product Baseline is established for each CSCI the above software design descriptions and Source Code Listings shall have been (after successful completion of the PCA) incorporated into the specific CSCI Software Product Specification.
Specific details of the software development process shall be defined in the 'Software Development Standards' and identified in the CSCI specific Software Development Plans. Details of the hardware development process shall be defined in the 'Hardware Development Standards' and activities identified in the pertinent 'Hardware Development Plan(s)'.
Note: Identifying to many items as configuration items can be more unproductive as too few as it can create emphasis on bureaucracy detracting away from the main objective of configuration control support role.
Operation and users documentation
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification of errors using the following form to: email@example.com
See figure 3 for the identification of the developmental configuration during the System life cycle. See figure 3 for an illustration of the developmental configuration.