military standard - product...
TRANSCRIPT
,..
DoDSTD-2167
4 JUNE 1%
SUPERSEDING
DOD-STD-1B7BA (NAVY
Z? OCTOBER 19S2
MILSD-1644B (TDl
2 MARCH 19S4
MILITARY STANDARD
DEFENSE SYSTEMSOFIVVARE DEVELOPMENT
(
~i
AMSC NO. N3SOB AREA MCCR
DISTRIBUTION STATEMENT A. Approvedforpublicreleaaa;distributionisunlimitd’.
DOD-STD-2167
DEPARTMENT OF DEFENSEWashington, DC 20301
Defense System Software Development
1. This Military Standard is approved $or use by all Departmentsand Agencies of the Department of Defense.
2. Beneficial comments (recommendations, additions, deletions)and any pertinent data which may be of use in improving thisdocument should be addressed to: COMMANDER , Space and NavalWarfare Systems Command, ATTN: SPAWAR 8111, Washingtonr D.C.20363-5100, by using the self-addressed Standardization DocumentImprovement Proposal (DD Form 1426) appearing at the end of thisdocument or by letter.
)
ii
DOD-STD-2167
Foreword
1. This standard contains requirements for the development ofMission-Critical COMpUter System SOftWare. It establishes auniform software development process which is’ applicablethroughout the system life cycle. The software developmentprocess defines development activities which result in: (1) thegeneration different types and levels of software anddocumentation~f (2) the application of development tools,approaches, and methods, and (3) project planning and control. Itincorporates practices which have been demonstrated to becost-effective from a life cycle perspective, based on informationgathered by the Department of Defense (DOD) and industry.
2. This standard is intended to be dynamic and responsive to therapidly evolving software technology field. As such, thisstandard should be selectively applied and tailored to fit theunique characteristics of each software acquisition program. Toensure that the requirements in this standard are appropriate andresponsive to software acquisition needs, users of this standardare encouraged to provide “feedback to the Preparing Activity.User experience in terms of benefits, pitfalls, and any other
“useful information encountered in applying this standard will bemost helpful.
3. Data Item Descriptions (DIDs~ applicable to this standard arelisted in Section 6. When used in conjunction with this standard,these DIDs provide a set of concise and complete documents forrecording and communicating information generated as a result ofadherence to the requirements specified herein.
iii/iv
DOD-STD-2167
CONTENTS
Paragraph E!%&
1. SCOPE .....................................,............. 11.1 Purpose .............................................. 11.2 Applia’ation.......................................... 1
1.2.1 Application to various types of SOftWar.3......... 11.2.2 Non-applicability of this standard ............... 11.”2.3 Software developed by Government agencies ........ 4
1.3 Tailoring of this standard ........................... 4
2. REFERENCED DOCUMENTS .................................... 52.1 Government documents ................................. 5
2.1.1 Specifications, standards, and handbooks ......... 52..1.2 Other Government ,documents, drawings, and
publications .................................... 52.2 Gther publications ................................... 52.3 Order of precedence .................................. 5
3. DEFINITIONS .............3.13.2
:::3.53.63.73.83.93.103.113.123.133.143.153.163.173.183.193.203.213.223.23
Alloca~ed Baseline. ..Authentication. ......Baseline .............Certification ........Computer data definitComputer software (or
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
............................... 7
............................... 7
............................... 7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .on................ ............. ;software) ............:......... 7
Computer Software Component (CSC).................... 7Computer Software Configuration Item ”(CSCI).......... 7Computer Software Documentation ...................... 7Computer software quality (or software quality) ...... 7Configuration Identification ......................... 8Configuration Item .................................. 8Developmental Configuration .......................... 8Firmware ............................................. 8Formal test.................1........................Functional Baseline .................................. :Hardware Configuration Item (HWCI)................. .. 8Informal test........................................ 8Modular .............................................. 8Product Baseline ..................................... 8Software development library (SOL)................... 8Top-down ............................................. 9Unit ................................................. 9
4. GENERAL REQUIREMENTS .................................... 114.1 Software development cycle ........................... 114.2 Computer software organization ....................... 114.3 Software quality. ..................................... 154.4 Use of commercially available, reusable, and
Government furnished software ....................... 15
v
DOD-STD-2167
CONTENTS - Continued
Paragraph“1
~
4.5 Subcontractor control .........4.6
.......................Non-deliverable software, firmware, and hardware. ..,.
4.7 Firmware .............................................4.8 Development methodologies4.9
.............................Security .............................................
4,10 Deliverable Data .....................................4.11 Deviations and waivers. ..............................
5. DETAILED REQUIREMENTS ...................................5.1 Software Requirements Analysis .......................
5.1.1 Activities - Software Requirements Analysis ......5.1.2 Products - Software Requirements Analysis ........5.1.3 Formal Reviews - Software Requirements Analysis. .5.1.4 Baselines - Software Requirements Analysis .......
5.2 Preliminary Design ...................................5.2.1 Activities - Preliminary Design5.2.2
..................Products - Preliminary Design ....................
5.2.3 Formal Reviews - Preliminary Design ..............5.2.4 Developmental Configuration - Preliminary
Design ..........................................5.3 Detailed Design ......................................
5.3.1 Activities-Detailed Design .....................5.3.2 Products -Detailed Design. ......................5.3.3 Formal Reviews - Detailed Design5.3.4
.................Developmental Configuration - Detailed Design ....
5.4 Codinciand Unit Testinq. .............................5.4.15.4.25.4.3
5.5 Csc5.5.15.5.25.5.35.5.4
A~tivities - Codin~ and Unit Testing .............Products - Coding and Unit Testing ...............Developmental Configuration - Coding andUnit Testing ....................................Integration and Testing. .........................Activities - CSC Integration and Testing .........Products - CSC Integration and Testing ...........Formal Reviews - CSC Integration and Testing .....Developmental Confiquration - CSC Integrationand Testing .......~.............................
5.6 CSCI Testing .........................................5.6.1 Activities -CSCI Testing. .......................5.6.2 Prod~~cts- CSCI Testing ..........................5.6.3 Audits -CSCI Testing. ...........................5.6.4 Baselines -CSCI Test in. ................. .......5.6.5 Software acceptance.. ............................5.6.6 Installation and checkout. .......................
5.7 Configuration Management (CM)........................5.7.1 Activities - Configuration Management ............
5.7.1.1 Configuration identification .................5.7.1.2 Configuration control. .......................5.7.1.3 Configuration status accounting ..............
16161616161617
272727303131313133
3334343536
3939394041
.)
)
vi
DOD-STD-2167
CONTENTS - Continued
Paragraph
5.7.2 Products - Configuration Management ..............5.7.3. Audits - Configuration Management ................
5.8 Software Quality Evaluation. .........................5.8.1 Activities - Software Quality Evaluation .........
5.8.1.1 Planning .....................................5.8.1.2 Internal reviews ..............................
5.8.1.2.1 Evaluation Criteria ......................5.8.1.2.2 Internal reviews - all phases ............5.8.1.2.3 Internal review - Software Requirements
Analysis ................................5.8.1.2.4 Internal review - Preliminary Design .....5.8.1.2.5 Internal review - Detailed Design ........5.8.1.2.6 Internal review - Coding and Unit Testing5.8.1.2.7 Internal review - CSC Integration and
Testing. ................................5.8.1.2.8 Internal review - CSCI Testing ...........
5.8.1.3 Formal reviews and audits. ...................5.8.1.4 Acceptance inspection ........................5.8,1.5 Installation and checkout ....................5.8.1.6 Evaluation of subcontractor products .........5.8.1.7 Commercially available, reusable, and
Government furnished software ...............5.8.1.8 Pi-eparation of quality records ...............5.8.1.9 Quality reporting ............................5.8.1.10 Corrective action system .....................’5.8.1.11 Quality cost data ............................
5.8.2 Products - Software Quality Evaluation ...........5.8.2.1 Quality records ..............................5.8.2.2 Quality reports ..............................5.8.2.3 Certification ................................
5.8.3 Independence .....................................5.9 Software project planning and control ................
5.9.1 Activities - Software project planning andcontrol .........................................
5.9.1.1 Sizing and timing assessments ................5.9.1.2 Status and cost reporting ....................5.9.1.3 Test documentation control ...................5.9.1.4 Software development library (SDL)...........5.9.1.5 Risk management ..............................
6. NOTES ...................................................Intended use .........................................Data requirements list and cross reference ...........Subject term (keyword) listing......................
4142424242424243
43434445
464647474848
4848484849494949494949
494950505050
51515156
vii
DOD-STD-2167
CONTENTS - Contintied
FIGURES
1
56
;9101112
System development cycle within” thesystem life cycle ............................ 2
Software development cycle ..................... 12CSCI sample static structure ................... 14System support cycle within the systemlife cycle .................................... 62
Sequence Construct ............................. 72IF-THEN-ELSE construct ......................... 72DO-WdILE construct. ............................ 73DO-UNTIL construct ............................. 73CASE construct .................................Relationship among management documents ........ ::Relationship among requirements documents ...... 85Relationship among design documents ............ 87
TABLES
Table
I Typical data item requirements .................. 82
APPENDIXES
Appendix
ABcD
List of acronyms and abbreviations ............. 59System life cycle .............................. 61Design and coding standards. ................... 71Guidelines for tailoring this standard ......... 77
viii
DOD-STD-2167
1. SCOPE
lol,Purpose. This standard establishes requirements to be appliedduring the development and acquisition of Mission-CriticalComputer ’Systen (MCCSI software, as defined in DOD Directive5000.29. This standard ma: also be applied to non-14CCSsoftwaredevelopment and acquisition.
1.2 A lication.proc~i~O;;wT;~~;;;;OZe?;e ~~fW~l~~v~~~m~;~r~~~l~occurs orieor more times during each of the system life cyclephases (Figure 1). Appendix B describes a typical system lifecycle, the activities that take place during each iteration ofsoftware development, and the documentation which typically existsat the beginning of an iteration in any given system life cyclephase. The requirements of this standard shall be applied to eachiteration, as described below. The requirements of this standardshall also be applied to the development of software for firmwaredevices as described in 4.7.
1.2.1 Application to various - ~ software. This standardapplies .to deliv=a~ software designated as Computer SoftwareConfiguration Items (CSCIS). This standard, or portions thereof,such configuration management,documen~~tion also applies to:
quality evaluation, and
a.
b.
c.
d.
Software developed and delivered as part of a system or aHardware Configuration Item (HWCI) but not explicitlyidentified as a CSCI.
Non-deliverable software used in the development and testingof deliverable software and hardware (such as design andtest tools).
Deliverable unmodsoftware.
Commercially avasoftware (~FS),delivered as part
fied commercially available and reusable
lable software, Government furnishedand reusable software that is modified andof the system.
The specific requirements of this standard which apply to theabove categories will be identified in the statement of work(sow).
1.2.2 Non-applicability of ~ standard. This standard, orportions thereof, may =t apply to small applications whichperform a fixed function that is not expected to change for thelife of the system. Guidelines for applying specific portions ofthis standard to particular categories of software may be found inAppendix D. The SOW will specify the applicable requirements .Ofthis standard.
1
DOD-STD-2167
was,..M,L,WON, 4 M,L, S,ONE ,,
?4,,0DETEFOA,NA,,IJN co,,,,, PROGRAM
SE,,.,,0. GO ,“,,0$11”]’CONCEPT DW40”S1RAT!ONEXmcm,,,rw AN. FULL SCALE DEVELOPMENT
“,,,.,,,..\
</.””’””””> “’L:WS’““o:’‘:’c’”oz“,KJ”,, EMENT,
S“STEINHA, CWA,, ‘NALYSISFIEO”,R, MEWS
. . ..”s.5
I
i i1---- – -DEv’Lw’N’ALcO’’F’GuR’’’ON-
,“.,,,O .,, .L,oc,,,..,s,,,., ,,s,,,.,
““
‘)
FIGURE 1. Systemdevelopmentcyclewithinthesystemlifecycle.
2
)
DOD-STD-2167
MILESTONE Ill
PRO~DTION
Of PtOYMENT 1
)
f
PRCOUCTlON
FuLL SCALE DEVELOPMENT ANDOEPLOVMENr
4
FIGURE 1.
I I
REVIEWS
ISRR - SYSTEM REQUIREMEWS RNIEWSDR . SYSTEM DESIGN REVIEW
SSR - sOFTWARE SPECIFICATION REVIEW
–+PDR . PRELIMINARY DESIGN REVIEW
——.CDm . CRITICAL DESIC?NREVIEW
t TRR . TEST REAOINESS REVIEW
FCA - FUNCTIONAL CONFIGURATION AUDITPRODUCTSASELINE
PCA - PHYSICAL CONFIQURATIDN AUDITFOR - FORMAL GUALIFICATION REVIEW
System developmentcyclewithinthesystemlifecycle.(continued)
3
UOD-STD-2167
1.2.3 Software developed b Government#-
agencies. Although thisstandard describes so tware developmentcontractor,
as performed by athe provisions of this standard also
Governmentapply to
agencies acting as software developers. In this case,the term “contractor” refers to the Government agency that isdeveloping the software. Any contractor of that Government agencyis classified as a subcontractor.
1.3 Tailorinq of this standard. Software shall be developed inaccordance wifi -s standard to the extent specified in thecontract clauses, SOW, and the Contract i3ata Requirements List.Guidelines for applying this standard are providsd in Appendix D.The contracting agency will tailor this standard to require onlywhat is needed for each individual acquisition.
)
4
DOD-STD-2167
2. REFERENCED ”DOCUMENTS
2.1 Government documents.
2.1.1 >ecificationsl standards, and handbooks. Unless otherwisespecified, the fellowing specifi?=ions, standards, and handbooksof the issue listed in that issue of the Department of DefenseIndex of Specifications and Standards (DODISS) specified in thesolicitation form a part of this standard to the extent specifiedherein.
STANDARDSMILITARY
DOD-STD-480 -
M?L_sT&481 -
MIL-STD-483 -
MIL-STD-490 -
MIL-STD-881 -
MIL-STLJ-1521 -
MIL-STD-1535 -
Configuration Control - Engineering Changes,Deviations, and Waivers
Configuration Control - Engineering Changes,Deviations, and Waivers (Short Form)
Configuration Management Practices forSystems, Equipment, Munitions, and ComputerSoftware
Specification Practices
Work Breakdown Structures for DefenseMateriel I-terns
Technical Reviews and Audits for Systems,Equipments, and Computer Software
Sucmlier Qualitv Assurance ProgramRe&ireme~ts -
2.1.2 Other Government documents, drawings, andNone
——
(CoDies of specifications, standards, handbooks,
publications.
drawings, andpublications- required by contractors in connection with specificacquisition functions should be obtained from the contractingag~ncy or as directed by the contracting officer. )
2.2 Other publications, None.——
2.3 Order of precedence. In the event of a conflict between the— .text of this standard and the references cited herein, the text ofthis standard shall take precedence.
5/6
DOD-STD-2167
3. DEFINITIONS
i,
3.1 Allocated Baseline. The initial approved allocatedconfi~identificat~on as specified in DOD-STD-480.
3.2 Authentication. The procedure (essentially approval) used bythe Government ‘ verifying that specification
Authe~~icat’ion doescontent is
acceptable. not imply acceptance orresponsibility by the Government for the specified item to performsuccessfully.
3.3 Baseline. A configuration identification document or a set ofsuch documents (regardless of media) formally designated and fixedat a specific time during a configuration item’s life cycle.Baselines, plus approved changes from those baselines, constitutethe current configuration identification.
3.4 Certification. A process, which may be incremental, by whichcontractor provides evidence to the contracting agency that a
~roduct meets contractual or otherwise specified requirements.
3.5 Computer ~ definition. A statement of the characteristicsof basic elements of Information operated upon by hardware inresponding to computer instructions. These characteristics mayinclude, but are not limited to, type, range, structure, andvalue.
3.6 Computer software @ software). A combination of associatedcomputer InstructIons and computer data definitions required toenable the computer hardware to perform computational or controlfunctions. ,
3.7 Computer Software Component (CSC). A functional or logicallydist;nct part of a computer software configuration item. Computersoftware components may be top-level or lower-level.
3.8 Computer Softwar”e ItemConfiguration _ (CSCI). SeeConfiguration Item.
3.9 Computer Software Documentation. Technical datainformation, includlng computer listings and printouts, whi~[documents the requirements, design, or details of computersoftware, explains the capabilities and limitations of thesoftware, or provides operating instructions for using orsupporting computer software during the software’s operationallife.
(
3.10 Computer software quality @ software quality). The degreeto which the attributes of the software enable It to perform itsspecified end item use.
7
DOD-STD-2167
3.11 Configuration Identification. The current approved orconditionally approved technical documentation for a configurationitem as set forth in specifications, drawings, and associatedlists, and documents referenced therein.
3.12 Configuration Item. Hardware or software, or anof both,
aggregationwhich i~signated by the contracting agency for
configuration management.
3.23 Developmental Configuration. The contractor’s software andassociated technical documentation that defines the evolvingconfiguration of a CSCI during development. It is under thedevelopment contractor’s configuration control and describes thesoftware configuration of the design, coding, and testing effort.Any item in the Developmental Configuration may be stored onelectronic media.
3.14 Firmware. The combination of a hardware device and computerinstructions or computer data that reside as read-only software onthe hardware device. The software cannot be readily modifiedunder program control. The definition also applies to read-onlydigital data that may be used by electronic devices other thandigital compaters.
3.15 Formal ~ A test conducted in accordance with test plansand procedures approved by the contracting agency and witnessed byan authorized contracting agency representative, to show that thesoftware satisfies a specified requirement.
3.16 Functional Baseline. The initial approved functionalconfiguration ldentlflcatlon as specified in DOD-STD-480.
3.17 Hardware Configuration ~ (HWCI). See Configuration Item.
3.18 Informal ~ Any test which does not meet all therequirements of a formal test.
3.19 Modular. Pertaining to software that is organized intolimited aggregates of data and contiguous code that performidentifiable functions.
3.20 Product Baseline. The initial approved product configurationidentlflcatlon as specified in DOD-STD-480.
3.21 Software development library (SDL). A controlled collectionof software, documentation, and associated tools and proceduresused to facilitate the orderly development and subsequent supportof software. A software development library provides storage ofand controlled access to software and documentation in bothhuman-readable and machine-readable form. The library may alsocontain management data pertinent to the software developmentproject.
8
f,,
3.22 Top-down.highest levellower levels.
DOD-STD-2167
Pertaining to an approach that starts with theof a hierarchy and proceeds through progressively
For example, top-down design, top-down coding,top-down testing.
3.23 Unit. The smallest logical entity specified in the detaileddesigfiich completely describes a single function in sufficientdetail to allow implementing code to be produced and testedindependently of other Units. Units are the actual physicalentities implemented in code.
9/lo
DOD-STD-2167
4. GENERAL
4.1 Software development cycle.software development cycle that
a. Software Requirementsb. Preliminary Designc. Detailed Design
REQUIREMENTS
The contractor shall implement aincludes the following six phases:
Analysis
d. Coding and Unit Testinge. Computer Software ComponentTestingf. CSCI Testing.
CSC) Integrat on and
4.i.l Each iteration of the software development cycle, regardlessof the system life cycle phase during which it occurs, isinitiated by allocation of system requirements to that software ora subsequent revision to those requirements.
4.1.2 The relationship of the software development cycle phaseswith the products, reviews and audits, and baselines andDevelopmental Configurations required by Section 5 of thisStandard are shown in Figure 2. Figure 2 reflects the sequentialphases of a software development cycle, as well as thedocumentation which typically exists prior to initiating aniteration. During software development, more than one iterationof the software development cycle may be in progress at the sametime. Each iteration represents a different version of thesoftware. This process may be described as an “evolutionaryacquisition” or “incremental build” approach. Within eachiteration, the software development phases also typically overlap,rather than form a discrete termination-initiation sequence. Forexample, performing Unit code and test concurrently with CSCintegration and test is useful in implementing incremental builds.The relationship of the software development cycle to the systemlife cycle, inciuding system allocation of requirements to ‘CSCIS,and system integration and testing of HWCIS and CSCIS, isdescribed in Appendix B.
4.2 Computer software organization. Computer software developedin accordance with this standard shall be organized as one or moreCSCIS or other types of software (see 1.2.1). Each CSCI is partof a system, segment, or prime item and shall consist of one ormore Top Level Computer Software Components (TLCSCS). Each TLCSCshall consist of Lower-Level Computer Software Components (LLCSCS)or Units. LLCSCS may consist of other LLCSCS or Units. TLCSCSand LLCSCS are logical groupings. Units are the smallest logicalentities, and the actual physical entities implemented in code.The static structure of CSCIS, TLCSCS, LLCSCS, and Units shallform a hierarchical structure as illustrated in Figure .3. Thehierarchical structure shall uniquely identify all CSCIS, TLCSCS,LLCSCS , and Units.
11
DOD-STD-2167
PM SOFT-WARE )PHASES som,.~ PREL,MINAR, 3fTAILED .:DD:N:,
OfVELOPMENT “E?N’::yw DESIGN DESIGN TE81,NG
o
●
,,,,,.SC.”,.,
Uccmc.rtm
!
%%
Pn,L!M,N.””0W”AT8.N ● ‘) g:;::,
CONCEPT .0..,”.0.”...7 .0.””,.,
●m,,,”, ”,,,
,mm”,.c, ,“,,”,..,
“,0”!” ,”..,, II Eo”,,,.,m,
Wcc,nc.,lm●.E.!F,C.,,.M
DSOfnv.mCo NF!Gu”Ar,ot+
“..,.,.,.,w..
DSC.=lw..,W.u,”
,“.,”,,,.3. .,,.
DSO fwl..,STM’MRO, ,..
PRocm”.,$w.”.,
&‘mm.REVEIWS,AUDITS ,,o”,”,”wr,
“E,,rw
o*“*m.0Es8en*CV,W Y
,0-.,..,,.,,,..,,0.
“,”,,.
“’EL’N’s”@DmLOmENTALCONR.3uRhn0N m
FIGURE 2.
12
-- L-.
Iy‘%#wy ‘\\ “’cm
\“..”., ,1
--- --
:7\,“ \*,!,L /’--
“;3:::f H.”vma,
w-r\
\ MANUAL I\-. _- /
-r
?
c“m,cuM*ON“,,,FN
~=OPMENTAL j
{ CONFIGURATION }
)Softwaredevelopmentcycle.
DOD-STD-2167
“’s’s~
PR6DUCTS
REVEIWS, AUDITS
G)L
4mm“pm”
$MAYBEINCLUDED04FOLLOWING
PRIMARYDOCUMENT
,---, SUPPORTDOCUMENT,1. _-_, MAYBEVENDOR
SUPPLIED
●ENTERED INTOBASELINE
ENTERED INTOo DEVELOPMENTAL
CONFIGURATION
CRISD = COMPUTERRESOURCESINTEGRATEDSUPPORTDOCUMENT
FIGURE2. Softwaredevelopmentcycle.(continued)
13
DOD-STO-2167
I SYSTEM J
1SEGMENTI [ SEGMENT 2
1
-h
1
TLCSC31
I
LL(XC LLCSC312 313
I I I
‘@ @
@@
621UNIT NIT
limaLLCSC 673LLW ‘Nil ‘Ni3301
UNIT UNl uN! (JNI UNl UNIT
LH!lwlbNIT UNIT Nl NIT NIT UNIT
FIGURE3. CSClsample etatic structure.
)
14
)
DOD-STD-2167
(
4.2.1 The partitioning of the CSCI into TLCSCS, LLCSCS, and Unitsmay be based on functional requirements, data flow requirements,or other design considerations. The hierarchical structureillustrated in Figure 3 demonstrates the static relationship ofthe TLCSCS, LLCSCS , and Units based theconsiderations
partitioningand does not represent eit~~r the control flow of
the software during execution or the implemented code. Guidelinesfor selecting CSCIS are contained in MIL-STD-483, Appendix XVII.These guidelines may also be applied to selecting TLCSCS,, LLCSCS ,and Units.
4.3 Software quality. The contractor shall plan and implement thesoftware development project with the objective of building inquality. To achieve this quality, the contractor shall:
a.
b.
c.
Establish and maintain a complete set of requirements forthe software. These requirements shall serve as thestandard against which software quality is evaluated. Toestablish the requirements, the contractor shall perform thetasks specified in 5.1. To maintain the requirements, thecontractor shall perform the tasks specified in 5.7.
Establish and implement a complete process, includingmethodologies and tools, for developing the software and itsdocumentation. The process shall be designed to buildquality into the software and its documentati;~::~d t.;maintain the’level of quality throughout the lifethe software. The development process shall include bothcontractor internal steps (specified in the SoftwareDevelopment Plan (SDP), Software Configuration Management”Plan (SCMP), and Software Standards and Procedures Manual(SSPM)), and the formal steps specified in 5.1 through 5.7,and 5.9 (see 6.2).
Establish and maintain a process to evaluate the software,associated documentation, and the software developmentprocess. The objective of this process shall be to improvethe quality of the software and its documentation, byproviding feedback and ensuring that necessary correctionsare made. The quality evaluation process shall include bothcontractor internal steps (specified in either the “SDP orthe Software Quality Evaluation Plan (SQEP)) and the formal.steps specified in 5.8 (see 6.2).
4.4 Use g commercially available, reusable, and Governmentfurni=d software. In order to facilitate =st-effectivedevelopment and SUDDOrt of MCCS software. the contractor is---encour~ged to i<c;rporate into the current software designcommercially available software, GFS , and reusable softwaredeveloped for other applications. However, the contractor shallperform the following activities prior to incorporateingcommercially available software, reusable software, GFS, or anycombination of these, into the design: (1) describe in the SDP
15
DOD-STD-2167
the data rights and documentation the contractor plans t~ providethe contracting agency regarding the commercially available andreusable software, (2) evaluate the commercially available,reusable, or Government furnished software to determine whether itperforms as documented, (3) describe in the SDP the contractor’splans for certifying the commercially available or reusablesoftware, and (4) obtain explicit contracting agency approval foruse of commercially available software (see 5.8.1.7 and 6.2).
4.5 Subcontractor control. The contractor shall ensure that allsubcontractors developing software and documentation comply withsubcontract requirements. The requirements of 4.4 shall apply toconunercially available and reusable software procured fromsubcontractors. Additional guidance may be found in MIL-STD-1535.
4.6 Non-deliverable software~ ‘irmware’ and ‘ardwa:e”
Thecontractor shall describe In t e SDP the con~ls to be Imposed onall non-deliverable software, firmware, and hardwaie used in thedevelopment and acquisition of deliverable software (see 6.2). Asa minimum, the contractor shall describe the provisions for:
Modifications (as applicable):: Documentation
Configuration Management:: Desiqn & Coding Standardse. Testingf. Quality Evaluation9. Certification.
4.7 Firmware. The application of- the requirements in thisstandard to firmware depends on whether the firmware is designatedas a CSCI or as part of an HWCI. If the software to beimplemented in firmware is designated as a CSCI, all therequirements in this standard apply, as tailored by the contract.If the software to be inpleruented in firmware is considered partof an HWCI, the contractor shall identify the applicablerequirements in the SDP and apply these requirements subject tocontracting agency approval (see 6.2).
4.8 Development methodologies. The contractor shalltop-down
use aapproach to design, code, integrate, and test all CSCIS,
unless specif~c alternate methodologies have been proposea ineither the SSPt4or SDP (see Appendix D) and received contractingagency approval (see 6.2).
4.9 Security. The contractor shall implement applicable securitymeasures during software design and development.
4.10 Deliverable ~ Deliverable data prepared in accordancewith ~e— requirements of sections 4 and 5 of this standard andidentified on the DD Form 1423, Contract Data Requirements List,shall be prepared in accordance with the instructions in theapplicable DIDs (see 6:2).
16
)
)
)
DOD-STD-2167
4.11 Deviations and waivers. The contractor and, if applicable,subcontractors =11 develop software in compliance with thisstandard, as required by the contract, unless a deviation orwaiver has been approved by the contracting agency in accordancewith DOD-STD-480 or MIL-STD-4tlI.
(’17/18
DOD-STD-2167
5.”DETAILED REQUIREMENTS
5.1 Software Requirements Analysis. The contractor shall defineand analyze a complete set of functional, performance, interface,and qualification requirements for each CSCI. These requirementsshall be derived from the system requirements ss defined in theSystem/Segment Specification (SSS), prime item specification,critical item specification, or other sources specified in thecontract. Additional requirements may be derived during theanalysis and allocation of system-derived requirements. Thecontractor shall also prepare or update, as applicable (seeAppendix B), an SDP, SSPM, SCMP, SQEP, and Operational ConceptDocument (oCD), and establish internal control overdocuments.
these
5.1.1 Activities - Software Requirements Analysis. The contractorshall perform the followlng actlvztles during Software ~Requirements .XnalySiS.
5.1.1.1 If.plans for developing the software have not previouslybeen prepared and approved by the contracting agency (see AppendixB), the contractor shall prepare them. The contractor’s plans forsoftware development shall include:
a. Resources and organization, describing: (1) thecontractor’s facilities, (2) Government furnished equipment,software, and services required, and (3) organizationalstructure, personnel, and resources for software” Ldevelopment, software configuration management, and softwarequality evaluation.
Ib. Development schedule and milestones, describing: (1) each I
individual activity of the project, (2) the activ~~~network, (3) risk management procedures, andidentifiable high risk areas.
c. Software standards and procedures, describing: (1) tools,techniques, and methodologies to be used inf:~m development,(2) if appl~~g~le, criteria for departing a top-downapproach 5.3.1.3, 5.3.1.4), (3) the softwaredevelopment library and associated access and controlprocedures, (4) the format and contents of softwaredevelopment files, associated procedures, and organizationalresponsibilities, (5) the for~gj and contents of allinformal test documentation, design andstandards, and (7) procedures and reports used to p%~~~~for formal reviews. ~
d. Software configurateion management, describing: (1)configuration identification procedures, (2) configurationcontrol including software problem and change reports, and
19
IDOD-STD-2167
e.
f.
9.
h.
i.
j.
k.
review boards, (3) configuration “status accounting, (4)configuration audits, (5) preparation for configurationauthentication procedures, and (6) configuration managementmajor milestones.
Software quality evaluation, describing: (1) evaluation ofdevelopment plans, standards, and procedures, (2) evaluationof the contractor’s compliance with those plans, standards,and procedures, (3) evaluation of the products of softwaredevelopment, (4) implementation of a quality evaluationreporting system, and (5) implementation of a correctiveaction system.
Commercially available, reusable, and Government furnishedsoftware, describing: (1) rationale for its use, (2) plansfor providing associated data rights and documentation forcommercially available and reusable software, (3) plans fordetermining that the commercially available, reusable, andGovernment furnished software performs as documented, and(4) plans for certifying commercially available and reusablesoftware.
Data rights and documentation for the software developmentlibrary (SDL), describing the plans for providing associateddata rights and documentation for the SDL.
Subcontractor control, describing: (1) the organizationresponsible for subcontractor control, and (2) theprocedures to ensure that all subcontractor-developedsoftware meets subcontract requirements.
Control provisions for non-deliverable software, firmware,and hardware, describing requirements for: (1)modifications (if applicable), (2) documentation, (3)configuration management, (4) design and coding standards,(5) testing, (6) quality evaluation, and (7) certification.
Control provisions for software that is part of a hardwareitem, describing procedures for: (1) requirements analysisand allocation, (2) design and coding, (3) hardware andsoftware integration and test, (4) coordination of hardwareand software design, (5) documen~::ion, (6) softwareconfiguration management, and softwareevaluation.
quality
Interface management with associate contractors. describingthe contractor’s plan for coordinating development and dat~management efforts to ensure interface compatibility.’
5.1.1.2 The contractor shall establish internal control over theSDP , SSPM, SCMP , and SQEP. The contractor shall monitor thedevelopment effort for consistency with the SDP, SSPt.f,SCMP , andSQEP (see 5.8.1.2.2). The contractor shall notify the contracting
20
I
)
agency of proposed changesrevisions. All proposedby the contracting agency.
DOD–STD-2167
to these documents and make necessarychanges shall be subject to disapproval
In addition, the contractor shallnotify the contracting agency at the next review, audit, or in thenext status report (whichever comes first) of any actions orprocedures occurring during Software Requirements Analysis thatdeviate from the SDP, SSPM, SCMP, or SQEP.
5.1.1.3 If provided by the Government, the contractor shallanalyze the preliminary OCD (see Appendix B) for adequacy,understandability, validity, and completeness.
5.1.1.4 The contractor shall identify and describe the mission ofthe system and its operational and support environments. Thecontractor shall also describe the functions and characteristicsof the computer system within the overall system (see 5.1.2.2).
5.1.1.5 The contractor shall analyze the SSS and, if ‘provided, thepreliminary Software Requirements Spe;~;~~~tions (SRSS) andInterface Requirements Specifications for adequacy,testability, understandability, validity, and completeness.Circumstances under which the specifications are provided by theGovernment are described in Appendix B.
5.1.1.6 The contractor shall define a complete set of functional,performance, interface, and qualification requirements for eachCSCI, incorporating the results of 5.1.1.5. Requirementsspecified by the contractor shall also include the followingareas:
a. Programming constraints and standards
b. Design constraints and standards
c. Adaptation
d. Quality factors
e. Preparation for delivery.
5.1.1.7 In the definition and analysis of software requirements,the contractor shall use structured requirements analysis tools,techniques, or a combination of both. The specific tools andtechniques to be used shall be identified in either the SSPM c.rSDP (see Appendix D) and shall be subject to contracting agencyapproval. The contractor shall map the requirements defined in5.1.1.6 to the applicable higher-level documents.
5.1.1.8 The contractor shall conduct internal in-processduring
reviewsthis phase (see 5.8.1.2.3) and shall make all necessary
changes based on the results of the internal reviews prior topresenting the requirements document(s) to the contracting agency.
21
IDOD-STD-2167
5.1.2 Products - Software Re uirements Anal sis.shall produce the foil “~+ ‘he contractorowing pro ucts during So tware RequirementsAnalysis (see 6.2).
5.1.2.1 The contractor shall prepare or produce updated versions;;d ~~chever is applicable, see Appendix B) the SDP, SSPM, SCMP,
5.1.2.2 The contractor shall produce an OCD for the system. Inthe event a preliminary OCD has been provided by the Government,the contractor shall update and complete the document.
5.1.2.3 The contractor shall produce records and summary reportsof the internal reviews conducted (see 5.8.2.1 and 5.8.2.2).
5.1.2.4 The contractor shall produce an SRS and, if applicable,IRS(S) for each CSCI (see Appendix D). In the event preliminarySRSS and IRSS have been provided by the Government, the contractorshal1 produce updated and completed versions of thesespecifications (see Appendix B). Additional guidance on preparingspecifications is provided in MIL-STD-490.
5.1.3 Formal Reviews - Software Re uirements Anal sis.~~ahor %contractor shalmnt the newly prepare
system and an SRS and IRS(s) for each CSCI at a SoftwareSpecification Review (SSR). The purpose of the SSR is todemonstrate to the contracting agency the adequacy of the OCD,SRS , and, if applicable, IRS(s). Specific details regarding theSSR process are contained in MIL-STD-1521.
5.1.4 Baselines - Software Re uirements Analysis.of the SSR, and when authe~the cont=ct!~n&%~~t;;~SRS and IRS(s) will establish the Allocated Baseline for eachCsc I. Specific details regarding the baseline process arecontained in MIL-STD-483 and MIL-STD-490.
5.2 Preliminary Desi n. The contractor shall develop adesi-h C&! Ia:hi;;~~pletelyr eflectst here&%~~~~~~specified in the SRS The contractorlower-level design for criticai
may developelements of the CSCI. The
criteria for determining critical elements shall be described ineither the SSPM or SDP (see Appendix D).
5.2.1 Activities - Preliminary - The contractor shallperform the folrowing actlvltles during Preliminary Design.
5.2.1.1 The contractor shall monitor the development effort forconsistency with the SDP, SSPM, SCMP, and SQEP (see 5.8.1.2.2).The contractor shall notify the contracting agency of proposedchanges to these documents, and make necessary revisions. Allproposed changes shall be subject to disapproval by thecontracting agency. In addition, the contractor shall notify thecontracting agency at the next review, audit, or in the next
22
‘)
)
,.,
DOD-STD-2167
status report (whichever comes first) of any actions or proceduresoccurring during Preliminary Design that deviate from the SDP,SSPM, SChfP,or SQEP.
5.2.1.2 The contractor shall establish the top-level design ofeach CSCI by allocating requirements from the SRS and, ifapplicable, IRS(s) to the TLCSCS of each CSCI. In defining eachTLCSC the contractor shall identify:
a.
b.
c.
d.
e.
f.
9.
h.
The TLCSC’S place in the CSCI’S static structure
Functions allocated to the TLCSC
Memory size and processing time allocated (including reservecapacities) to the TLCSC
Functional control and data” flow to and from the TLCSC
Known interrupt and special control featuresnon-standard subroutine returns) of the TLCSC
Global data shared with other TLCSCS
Applicable inputs, local data, interrupts, timsequencing, processing, and outputs of the TLCSC
Adaptation data needed by the TLCSC.
such as
n9 and
5.2.1.3 The contractor may establish the lower-level design ofcritical elements of each CSCI, including external interfaces anddata bases, by refining TLCSCS to LLCSCS and Units. The criteriafor determining critical elements shall be described in either theSSPM or SDP (see Appendix D).
5.2.1.4 ‘“In establishing and defining the top-level and, asapplicable, lower-level design of each CSCI, the contractor shalluse a program design language or some other “top-level designdescription tool or methodology. This tool or methodology shallbe identified in either the SSPM or SDP (see Appendix D) and shallbe subject to contracting agency approval.
5.2.1.5 In the development of the top-level’design, the contractorshall incorporate applicable human factors engineering principles,including:
a. Human information processing capabilities and limitations
b. Anthropometric characteristics of the target population
c. Foreseeable human errors under both normal and extremeconditions
d. Implications for the total system environment (to include
23
DOD-STD-2167
training, support, maintenance, and operationalenvironment ).
5.2.1.6 The contractor shall develop test plans for both informaland formal tests.
a. Informal tests shall test individual Units during Coding andUnit Testing and aggreetes of Units during CSC Integrationand Testing. For Unit testing, the contractor shallidentify the overall test requirements, testresponsibilities: and schedule information. For Cscintegration testing, the contractor shall identify:overall test
(1) therequirements, test responsibilities, and
schedule information, and (2) different classes of CSCintegration tests, Although informal test documentationdoes not require Government approval, it shall be madeavailable for Government review.
b. Formal tests shall test the fully implemented CSCI duringCSCI Testing, to show that the CSCI satisfies its specifiedrequirements. Formal tests may also occur at the Tl,csc,LLCSC , and Unit levels, when compliance with specifiedrequirements cannot be shown at the CSCI level. Some CSCISmay require integration with other computer systems, HWCIS,or CSCIS before all formal testing can be completed. Forformal testing, the contractor shall identify: (1) the testrequirements applicable to CSCI testing, (2) CSCI testorganization, responsibilities, and schedule information,(3) different classes of formal tests, (4) data recording,reduction, and analysis requirements, and (5) the purpose ofeach formal test planned. The contractor shall plan fordocumenting formal test results as well. All individualsresponsible for planning formal tests shall be sufficientlyindependent from the individuals responsible for developmentto permit objective testing.
c. The contractor shall identify all the resources (facilities,personnel, hardware, software) required for informal andformal testing.
5.2.1.7 The contractor shall define a preliminary version of theprocedures and information for the operation of the computersystem in which each CSCI executes (see 5.2.2.6). This definitionshall
::c.d.e.f.9.
include:
System preparation and set upOperating proceduresInput/OutputMonitoring proceduresOff-line routinesRecovery and special proceduresDiagnostic features.
24
‘)
:)
)
/“
DOD-STD-2167
5.2.1.8 The contractor shall define a preliminary version of theinstructions for user personnel to execute each CSCI requiringuser interaction (see 5.2.2.6). This definition shall include foreach function the CSCI performs:
&::e.f.9.h.i.
Name, number and purpose of the functionInitialization requirementsExecution optionsUser and system inputsTermination and restart proceduresExpected outputsInterrelationship with other functionsError messagesDiagnostic features.
5.2.1.9 Tne contractor shall define a preliminary version of theinformation necessary to identify a computer system malfunctionand instructions to run the diagnostics (see 5.2.2.6). Thisdefinition shall include:
a. Identification of all support hardware, software, andprocedures necessary to perform system diagnosis.
b. A description of each diagnostic tool available for thesystem.
c. A description of each diagnostic test available on thediagnostic tools, including: (1) the purpose of each test,(2) procedures for executing the test, (3) additionalhardware, software, or firmware necessary for executing the.test, and (4) all diagnostic messages.
5.2.1.10 The contractor shall define a preliminary version of theinformation required to perform life cycle support for thecontractually deliverable software (see 5.2.2.6). This definitionshall include identification of:
a. The support”environment, describing required: (1) supportsoftware, (2) equipment, (3) facilities, and (4) personnel.
b. Support operations, describing: (1) general usageinstructions (initiation, general operation, and monitoringoperations of the support environment), (2) administration,(3) software modification, (4) software integration andtesting, (5) system and software ,generation, (6) softw~:fquality evaluation, (7) corrective action system,configuration management, (9) simulation, (10) emulation,(11) reproduction, and (12) operational distributions.
c. Training plans and provisions.
d. Predicted level of change to the deliverable software in thesupport environment.
25
IDOD-STD-2167
5.2.1.11 The contractor shall conduct internal in-process reviewsduring this phase (See 5.8.1.2.4) and shall.make all necessary
“)
changes based on the results of the internal reviews, prior topresenting the top-level design, test plans, and operation andsupport documents to the contracting agency.
5.2.2 Products - Preliminary Desi n.the following pro~g-inary Design (see 6.2).
The contractor shall produce
5.2.2.1 The contractor shall produce updatedSSPM, SCMP, and SQEP as necessary.
5.2.2.2 The contractor shall produce records
versions of the SDP,
and reportsof the internal reviews conducted (see 5.8.2.1 ands&%~~2).
5.2.2.3 The contractor shall produce a Software Top-Level DesignDocument (STLDD) for each CSCI to describe the top-level design ofthe CSCI.
5.2.2.4 The contractor may produce preliminary versions of theSoftware Detailed Design Document (SDDD), Interface DesignDocument(s) (IDD(s)), and Data Base Design Document(s) (DBDD(s))for critical lower-level elements of the CSCI.
5.2.2.5 The contractor shall produce a Software Test Plan (STP )for each’ CSCI to describe the plans for both informal and formaltesting of the CSCI.
5.2.2.6 The contractor shall produce preliminary versions of the:
a. Computer
b. Software
c. Computer
d. Computer
System Operator’s Manual (CSOM)
User’s Manual (SUM) for one or more CSCIS
System Diagnostic Manual (CSDM)
Resources Integrated Support Document (CRISD).
5.2.3 Formal Reviews - Preliminary Desi n.presen~ STLDD an~*c~~~CCO~;~a~~~~i<;~~~versions of the CSOM, SUM(s), CSDM, and CRISD at a PreliminaryDesign Review (PDR). The purpose of the PDR is to review thetop-level design, test plans, and preliminary operation andsupport documents with the contracting agency and to demonstrateto the contracting agency that: (1) the top-level designsatisfies the software requirements allocated from thehigher-level documents, (2) the test plans establish adequate testcriteria for each CSCI and address all specified requirements, and(3) the preliminary versions of the CSOM, SUM(s), CSDM, and CRISDwill, in final form, adequately address the operation and supportof the computer system. In addition, the PDR may reviewpreliminary versions of the SDDD, IDD(s), and DBDD(s) for criticallower-level elements, including external interfaces and data
26
I
‘)
I
DOD-STD-2167
base(s), to demonstrate that the lower-level design for criticalelements will satisfy the specified requirements. Specificdetails regarding the PDR process are contained in MIL-STD-1521.
5.2.4 Developmental Configuration - Preliminarysuccessful completion of ~ ‘esi’n” “Penthe PDR, t e STLDD shall establish thecontractor’s Developmental Configuration for each CSC1.
contractor shall performDesign.
development effort forand SQEP (see 5.8.1.2.2).
5.3.1 Activities - Detailed ~esign. Thethe following activities during Detailed
5.3.1.1 The contractor shall monitor theconsistency with the SDP, SSPt4,SCMP,The contractor shall notify the contracting agency of proposedchanges to these documents and make necessary revisions. Allproposed changes shall be subject to disapproval by thecontracting agency. In addition, the contractor shall notify thecontracting agency at the next review, audit, or in the nextstatus report (whichever comes first) of any actions or proceduresoccurring during Detailed Design that deviate from the SDP,SCMP, or SQEP.
SSPM,
5.3.1.2 The contractor shall establish the complete: modular,( lower-level design for each CSCI, by refining TLCSCS lnto”LLCSCs
and Units. Each Unit shall _perform a single function. Inrefining TLCSCS, the contractor shall identify:
a. All required details for implementing external interfaces,including item summary and item format for each interface
(
b.
c.
d.
e.
Global data definitions within each TLCSC
Inputs, local data definitions, process controlrequirements, processing, utilization of other elements,limitations, and outputs of all LLCSCS
Inputs, local data definitions, process controlrequirements, processing; special control features,protection, error handling, utilization of other elements,limitations, and outputs for all Units
Detailed data base design including data base managementsystem overview, data base structure, data base file desiqn,a~d data base references.
..3 The contractor shall refine.all TLCSCS usina a5.3.1design approach, unless specific alternate methodolo~iesproposed in either the SSPt4or .SDP (see Appendix D)received contracting agency approval.
top-downhave been Iand have
27
IDOD-STD-2167
5.3.1.4 The contractor may depart from a top-down approach to:(1) address critical lower-level elements or (2) incorporateconunercially available, reusable, and Government fu]nishedsoftware. The contractor shall describe the criteria fordetermining critical lower-level elements in either the SSPM orSDP (see Appendix D). Examples of criteria for determiningcriticality are software performance, cost, and schedule.
5.3.1.5 In the development of the detailed design for each CSCI,the contractor shall employ a program design language. Thelanguage and other tools to be used shall be identified in eitherthe 55PM or SDP (see Appendix D) and shall be subject tocontracting agency approval.
5.3,1.6 The contractor shall ensure that the detailed designincorporates applicable human factors engineering principles (see5.2.1.5).
5.3.1.7 The contractor shall monitor size and time estimates forthe Csc 1 and adjust the estimates, if necessary. Allmodifications to controlled or baselined documentation shall bemade in accordance with the configuration management requirementscontained herein (see 5.7).
5.3,1.8 The contractor shall establish software development files(5DFs) for all Units. Each SDF may serve a single Unit orlogically related group of Units. Unit requirements, designconsiderations and constraints, schedule, status information, andtest documentation shall be incorporated into the correspondingSDF . All SDFS shall be in the format described in either the SSPMor SDP (see Appendix D). To reduce duplication, SDFS should notcontain information provided in other documents. SDFS may begenerated, maintained, and controlled by automated means.
5.3.1.9 The contractor shall document additional engineeringinformation generated in the design process for each CSCI. Theengineering information shall include rationale, results ofanalyses and trade-off studies, and any other information whichaids in understanding the detailed design.
5.3.1.10 The contractor shall identify the test requirements,responsibilities, and schedule’ for the informal testing to beconducted for each Unit, and shall record them in thecorresponding SDF.
5.3.1.11 The contractor shall describe test cases for eachinformal Unit test in terms of inputs, expected results, andevaluation criteria. The test cases for each Unit shall bedescribed in the corresponding SDF.
5.3.1.12 The contractor shallresponsibilities, and schedule for
28
identify the requirements,each CSC integration test.
)
I
I
5.3.1.13informalresults,
5.3.1.14
DOD-STD-2167
The contractor shall describe test cases for eachCsc integration test in terms of inputs, expectedand evaluation criteria.
The contractor shall describe test cases for each formalCSCI test identified in the STP. Test case descriptions shailinclude:
a. Initialization requirements
b, Input data
c. Expected intermediate test results
d. Expected output data
e. Criteria for evaluating results
f. Assumptions and constraints.
5.3.1.15 The contractor shall update with any additional kmdetails all information and instructions pertaining to compusystem operation, software operation by users, and computer sysdiagnostics (see 5.3.2.9).
5.3.1.16 The contractor shall complete the information thatrequired to perform life cycle support of the contractualdeliverable software (see 5.3.2.10).
5.3.1.17 The contractor shall prepare information to facilitateprogramming or reprogramming software for the target computer (see5.3.2.11). The information shall include:
a. Equipment configurationb. Operational characteristics, capabilities, and limitations
Compilation and assembly information:: Programming.featurese. Progrzm instructionsf. 1/0 control features9. Examples of programming techniquesh. Special featuresi. Error detection and diagnostic features.
5.3.1.18 The contractor shall describe the information necessaryto modify or replace the read-only memory (ROM), programmableread-only memory (PROM), and other such firmware components of thesYstem (see 5.3.2.11). This description shall include:
a. Description of firmware componentsb. Installation and repair procedures
Security implications:: Operational and environment limitationse. Hardware needed for programming firmware devices
29
DOD-STD-2167
f. Software needed for programming firmware devices9. Procedures for programming firmware devicesh. Vendor information.
5.3.1.19 The contractor shall conduct internal in-process reviewsduring this phase (ace 5.8.l.~~~) and shall make all necessarychanges based on the results of internal review, prior topresenting the detailed design, formal test case documentation,and operation and support documentation to the contracting agency.
5.3.2 Products - Detailed - The contractor shall producethe following products during Detailed Design (see 6.2).
5.3.2.1 The contractor shall produce updated versions of the SDP,SSPt4,SCMP, and SQEP as necessary.
5.3.2.2 The contractor shall produce records and summary reportsof the internal reviews conducted (see 5.8.2.1 and 5.8.2.2).
5.3.2.3 The contractor shall produce an SDDD for each CSCI, todescribe the detailed design. The contractor shall include in theSDDD, in Section 6 Notes,(rationale,
additional engineering informationresults of analyses and trade-off studies, etc.) which
aids in understanding the detailed design of the CSCI.
5.3.2.4 The contractor shall produce an IDD for each IRS todescribe the details of external interfaces. The contractor shallinclude in the IDD(s), in Section 6 Notes, additional(rationale,
informationresults of analyses and trade-off studies, etc.) which
aids in understanding the details of external interfaces.
5.3.2.5 The contractor shall produce one or more DBDDs. Each DBDDshall describe the contents and structure of one or more databases. (Data base interactions and control mechanisms aredescribed in the top-level and detailed design documents). Thecontractor shall include in the DBDD(s), in Section 6 Notes,additional information (rationale, results of analyses andtrade-off studies, etc.) which aids in understanding the detailsof the data base(s).
5.3.2.6 The contractor shall establish and maintain SDFS forUnits.
all
5.3.2.7 The contractor shall produce documents that identify eachinformal CSC integration test and describe the test cases, in thestandard format described in either the SSPt4or SDP (see AppendixD), for each informal test to be executed.
5.3.2.8 The contractor shall produce a Software Test Description(STD) for each CSCI, to define test cases for each formal test ofthe CSCI described in the STP.
5.3.2.9 The contractor shall produce updated versions of the CSOM,
30
.,, ..: .::
DOD-STD-2167
‘SUM(S), and CsDM.
5.3.2.10 The contractor shall produce a completed CRISD.
5.3.2.11 The contractor shall produce a Software Pr09ra~er’sManual (SPM) and a Firmware Support Manual (FSM).
5.3.3 Formal Reviews - Detailed Desi n.presen~ SDDD ,andthe STD~:*~h~t ~O~~~~~~~~~!;~~Review (CDR). The contractor also present the IDD(s),DBDD(s), SPM, FSM, and updated CSOM, SUM, CSDM, and CRISD at thisreview. The purpose of the CDR is to review the detailed design,test description, and operation and support documents with thecontracting agency, and to demonstrate to the contracting agencythat: (1) the detailed design sat;;g~;y,the requirements of theSRS and the IRS(s), (2) the SDDD, and DBDD(s) furtherrefine the design details of the CSCI in a manner consistent withthe STLDD, (3) the STD provides adequate test cases for the formaltests identified in the STP, (4) the updated versions of the CSOM,SUM(S), and CSDM will, in final form, adequately address theoperation and support of the computer system, and (5) the SPM,FSM, and CRISD adequately address software programming support,firmware support, and integrated computer resources support.Specific details regarding the CDR process are contained inMIL-STD-1521.
5.3.4 Developmental Confi uration - Detailed “of ~he CDR, thecontractti%%!%nter”%~successful completion
SDDD, IDD(s), and the DBDD(s) for each CSCI into the DevelopmentalConfiguration for the CSCI.
5.4 Cod~n~ and Unit Testin .each Un~t m~n~ hiled design.
The contractor shall code and test
5.4.1 Activities - Coding and Unit Testin4
The contractor shallperform the fofiowing acti=i=urlng Co lng and Unit Testing.
5.4.1.1 The contractor shall monitor the development effort, forconsistency with the SDP, SSPM, SCMP, and SQEP (see 5.8.1.2.2).The contractor shall”notify the contracting agency of proposedchanges to these documents, and make necessary revisions. Allproposed changes shall be subject to disapproval by the.contracting agency. In addition, the contractor .shall notify thecontracting agency at the next review, audit, or in the nextstatus report (whichever comes first) of any actions or proceduresoccurring during Coding and Unit Testing that deviate “from theSDP, SSPM, SCMP, or SQEP.
5,4,1.2 The contractor shall code and test Units in top-downsequence, unless alternate methodologies have been proposed ineither the SSPM or SDP (see Appendix D) and have receivedcontracting agency approval.
31
DOD-STD-2167
~i~.l~;d~he contractor may depart from a top-down approach to:and test critical Units or (2) incorporate commercially
available, reusable, or Government furnished software. Thecontractor shall describe the criteria for determining criticalUnits in either the SSPM or SDP (see Appendix D). Examples ofcriteria for determining criticality are software performance,cost, and schedule.
5.4.1.4 The contractor shall code all Units in accordance withcoding standards. If the contractor has not proposed use ofinternal coding standards in either the SSF’Mor SDP (see AppendixD) and received contracting agency approval for the internalcoding standards, then the coding standards of Appendix C shallapply.
5.4.1.5 The contractor shall produce deliverable code that can beregenerated and maintained using only Government-owned,contractually deliverable, or commercially available supportsoftware and hardware.
5.4.1.6 Prior to the testing of each Unit, the contractor shallprepare and record in the SDF test procedures for conducting eachlnf~rmal Unit test.
5.4.1.7 The contractor shall performto the test plans for informal Unitand according to the Unit test casescontained in the SDF.
5.4.1.8 The contractorall informal Unit test
5.4.1.9 The contractordesign documentationUnits that undergo des
nformal Unit tests accordingtestina contained in the STPand ~nit test procedures
shall record in the SDF the test results ofn9.
shall make necessary revisions to theand code ! and shall update the SDFS of allgn or coding changes based on Unit tests.
5.4.1.10 The contractor shall enter into the DevelopmentalConfiguration and release for integration each coded Unit that hasbeen successfullytested and reviewed (see 5.8.1.2.6).
5.4.1.11 The contractor shall develop detailed test procedures forconducting each informal CSC integration test.
5.4.1.12 The contractor shall prepare preliminary versions of testprocedures for conducting each formal CSCI test and for analyzingformal CSCI test results. Test procedures shall include:
a. Schedule
b. Pretest procedures, including equipment preparation andsoftware preparation
c. Each step of the procedures
32
DOD-STD-2167
d. Applicable data reducti~n and data
e. Assumptions made and constraintsprocedures.
analysis procedures
imposed on formal test
5.4.1.13 The contractor shall update with additional known detailsall information and instrs,ctions pertaining to computer systemoperation, software operation by users, computerdiagnostics,
systemprogramming or reprogramming software for the target
computer, and modifying or replacing firmware (see 5.4.2.7).
5.4.1.14 The contractor shall conduct internal in-process reviewsduring this phase (see 5.8.1.2.6) and shall make all necessarychanges based on the results of the internal reviews.
5.4.2 Products - Coding and Unit Testing. The contractor shall:r~~uce the following products during Coding. .
5.4.2.1 TheSSPM, SCMP,
5.4.2.2 The
contractor shall produceand SQEP, as necessary.
contractor shall Droduce
updated
recordsof the internal reviews condu&ted (see 5.8.2
and Unit Testing (see
versions of the SDP,
and summary reports.1 and 5.8.2.2).
5.4.2.3 The contractor shall produce the source and object codeand, as necessary, updated design documentation for each Unit ofeach CSCI.
5.4.2.4 The contractor shall produce updated SDFs’as necessary forall Units (e.g., modified Unit test procedures, retest results,etc.). All .SDFS shall be in the standard format described ineither the SSPM or SDP (see Appendix D).
5.4.2.5 The contractor shall produce detailed test procedures forconducting each informal CSC integration test. These proceduresshall be in the Sormat described in either the SSPM or SDP ‘(seeAppendix D).
5.4.2.6 The contractor shall produce a preliminary version of thesoftware Test Procedure (STPR) to describe the detailed proceduresfor conducting formal CSCI tests and for analyzing formal CSCI,test results.
5.4.2.7 The contractor shall produce updated versions of the CSOM,SUM(s), CSDM, 5PM, and FSM.
5.4.3 Developmental Configuration - Codincontractor shall enter any update~g=o%%n%%%sou%and object .code, and associated listings for each successfullytested and reviewed Unit into the Developmental Configuration forthe CSCI (see 5.8.1.2.6).
33
DDD-STD-2167
5.5 ~ Integration and Testing. The contractor shal1 integrateUnits of code entered In the Developmental Configuration andperform informal tests on aggregates of integrated Units. Inorder to test critical functions of each CSCI early, formal testsmay be conducted during this phase. Formal tests conducted duringthis phase require: (1) the contractor to complete the applicableformal test ~~~;~;ures, (2) contracting agency approval of theapplicable test procedures, and (3) the contractor toperform the tests in accordance with the approved test procedures.
5.5.1 Activities - ~ Integration and Testing. The contractorshall perform the followlng actlvifis during CSC Integration andTesting.
5.5.1.1 The contractor shall monitor the development effort forconsistency with the SDP, SSPM, SCMP, and SQEP (see 5.8.1.2.2).The contractor shall notify the contracting agency of proposedchanges to these documents and make necessary revisions. Allproposed changes shall be subject to disapproval by thecontracting agency. In addition, the contractor shall notify thecontracting agency at the next review, audit, or in the nextstatus report (whichever comes first) of any actions or proceduresoccurring during CSC Integration and Testing that deviate from theSDP, SSPM, SCMP, or SQEP.
5.5.1.2 The contractor shall integrate and test aggregates ofUnits in a top-down sequence, unless alternate methodologies havebeen proposed in either the SSPM or-SDP (see Appendix D) and havereceived contracting agency approval.
5.5.1.3 The contractor may depart from a top-down(1)
approach to:integrate or test critical Units or (2) incorporate
commercially available, reusable, and Government furnishedsoftware. The contractor shall describe the criteria fordetermining critical Units in either the SSPM or SDP (see AppendixD). Examples of criteria for determining criticality are softwareperformance, cost, and schedule.
5.5.1.4 As Units are successively integrated with one another, thecontractor shall compare memory and processing time values withallocations established during Preliminary and Detailed Design.The contractor shall also compare any system resources affected bythe integrated units with speclfled.req:lrements (e.g., secondarystorage, communication channel utlllzatlon, etc.). The contractorshall modify, as necessary, all controlled or baselineddocumentation based on the memory, processing time, and systemresources comparisons. All modifications to controlledbaselined documentation shall be made in accordance with t~~configuration management requirements contained herein (see 5.7).
5.5.1.5 The contractor shall informally test aggregates ofintegrated Units according to the test plans contained in the STPand the test cases and test procedures developed in previous
34
,., . ,, .-,.,, .>
DOD-STD-2167
phases.
5.5.1.6 The contractor shall document the results of allintegration testing in the standard format described in either theSSPt4or SDP (see Appendix D).
5.5.1.7 The contractor shall make necessary revisions to thedesign documentation and code, perform all necessary retesting,and update the SDFS of all Units that undergo design or codingchanges based on integration tests.
5.5.1.8 The contractor shall complete preparation of detailedprocedures for conducting each formal CSCI test and for analyzingformal test results (see 5.4.1.12).
5.5.1.9 The contractor shall update with additional known detailsall information and instructions pertaining to computer systemoperation, software operation by users, computerdiagnostics,
systemprogramming or reprogramming software for the target
computer, and modifying or replacing firmware (see 5.5.2.7).
5.5.1.10 The contractor shall conduct inter’nalin-process reviewsduring this phase (see 5.8.1.2.7) and shall make all necessarychanges based on the results of the internal reviews, prior topresenting the informal test results, completed formal CSGI testprocedures, and updated operation and support documentation to thecontracting agency.
5.5.2 Products - ~ Inte ration and Testin .shall produce the foll~inq prod~sdSC ~~~e$~~~~~c~~~Testing (see 6.2).
5.5.2.1 The contractor shall produce updated versions of the SDP,SSPM, SCMP, and SQEP, as necessary.
5.5.2.2 The contractor shall produce records and summary reportsof the internal reviews conducted (see 5.8.2.1 and 5.8.2.2).
5.5.2.3 The contractor shall produce the source and object codefor each complete CSCI by integrating its constituent parts.
5.5.2.4resultsSSPt4or
5.5.2.5SDFS to
5.5.2.6CscI.
5.5.2.7SUM(S),
The contractor shall produce the informal integration testdocumented in the standard format described in either theSDP (see Appendix D).
The contractor shall produce updated design documents andreflect changes based on integration testing.
The contractor
The contractorCSDM, SPM, and
shall produce
shall produceFSM .
35
the completed STPR
updated versions of
for each
the CSOM,
DOD-STD-2167
5.5.3 Formal Reviews - CSC Integration and Testing. Thecontractor shall present in=mal CSC integra=n test results andthe STPR for each CSCI at a Test Readiness Review (TRR). Thecontractor shall .31S0 present the updated CSOM, SUM(S), and CSDM.The purpose of the TRR is to review the informal test results,formal test procedures, and operation and support documents withthe contracting agency, and to demonstrate to the contractingagency that: (1) the STPR is complete, (2) the contractor 1.sready to begin formal testing, and (3) the updated versions of theCSOt4,SUM(s), and CSDt.fwill, in final form, adequately address theoperation and support of the computer system. Specific detailsregarding the TRR process are contained in MIL-STD-1521.
5.5.4 Developmental Configuration - CSC Integration and TestingThe contractor shall updated design d~mentation~ent~ —anysource code, object code, and associated listings into theDevelopmental Configuration for each CSCI.
5.6 CSCI Testing. The contractor shall conduct formal tests oneach CSCI to show that the Csc I satisfies its specifiedrequirements. The contractor shall also record and analyze formaltest results. Conducting and analyzing formal tests shall beperformed by individuals sufficiently independent from theindividuals responsible for development to permit objectivetesting.
5.6.1 Activities - CSCI Testin~ The contractor shall perform thefollowing activities during CSCI Testing.
5.6.1.1 The contractor shall monitor the development effort forconsistency with the SDP, SSPM, SCMP, and SQEP (see 5.8.1.2.2).The contractor shall notify the contracting agency of proposedchanges to these documents and make necessary revisions. Allproposed changes shall be subject to disapproval by thecontracting agency. In addition, the contractor shall notify thecontracting agency at the next review, audit, or in the nextstatus report (whichever comes first) of any actions or proceduresoccurring during CSCI Testing that deviate from the SDP, SSPM ,SCMP, or SQEP.
5.6.1.2 Individuals sufficiently independent from the individualsresponsible for development shall perform formal tests on eachCSCI in accordance with the: (1) formal test plans described inthe STP, (2) formal test cases described in the STD, and (3)formal test procedures contained in the STPR.
5.6.1.3 Individuals sufficiently independent from the individualsresponsible for development shall report the results of all formalCSCI tests. The test reports shali include:
a. Summary and detail of the test resultsb. Detailed test historyc. Evaluation of test results, and recotmnendetions
36
“1
,. , ,%:.
DOD-STD-2167
d. Test procedure deviations.
4.6.1.4 The contractor shall make necessarydesign
revisions to thedocumentation and code, perform all necessary retesting,
and update the SDFS of all Units that undergo design or codingchanges based on formal tests.
5.6.1.5 The contractor shall identify the exact version of eachdeliverable CSC I and the interim changes occurring betweenversions. This identification shall include:
a.b.c.d.e.f.9.h.i.j.
5.6.1.
Inventory of materials to be releasedInventory of CSCI contentsClass I changes installedClass II changes installed.ldantationdata. . .Interface compatibilityBibliography of reference documentsOperational descriptionInstallation instructionsPossible probiems and known errors.
6 The contractor shall complete all information andinstructions pertaining to computer system operation, softwareoperation by users, computer system diagnostics, programming orreprogramming software for the target computer, and mo~ifying orreplacing firmware (see 5.6.2.7).
5.6.1,7 The contractor shall conduct internal in-process. reviewsduring this phase (see 5.8.1.2.8) and shall make all necessarychanges based on the results of the internal reviews, prior topresenting the formal test results and completed operation andsupport documents to the contracting agency.
5.6.2 Products - CSCI ~estinq The contractor shall produce thefollowir,gpro~uct=rlng CSCI Testing (see 6.2).
5.6.2.1 The contractor shall produce updated versions of the .SDP,SSPM, SCMP. and SQEP, as necessary,
5.6.2.2 The contractor shall produce records and summary reportsof the internal reviews conducted (see 5.8.2.1 and 5.8.2.2).
5,6.2,3 The contractor shall produce Software Test Reports (STRS )which document the results of formal CSCI tests, test dataanalysis, and any deviations or discrepancies discovered in thetesting.
5.6.2.4 The contractor shall produce the updated source and objectcode for each CSCI and prepare them for delivery in accordancewith the requirements of the SRS.
5.6.2.5 The contractor shall produce a Software Product
37
DOD-STD-2167
Specification (SPS) for each CSCI, consisting of all the documentsand listings comprising the Developmental ConfigurationCSC I.
for theSome CSCIS may require integration with other computer
systems, HWCIS, or CSCIS before all formal testing can becompleted. In such cases the SPS cannot be completed until aftersuch integration and testing. Additional quidance on preparingspecifica~ions is provided in MIL-STD-490. -
5.6.2.6 The contractor shall produce a VersionDocument (VDD) for each CSCI.
5.6.2.7 The contractor shall produce completed versCSOM, SUM(s), CSDM, 5PM, and FSM.
Description
ons of the
5.6.3 Audits - CSCI Testing. The contractor shall present theSTR(S) for each CSCI and the CSOM , SUM(S), and CSDM at aFunctional Configuration Audit (FCA). The contractor shallpresent the SPS, VDD, and source and object code for each CSCI ata Physical Configuration Audit (PCA). The contractor shall alsopresent the Csot.i, SUM(s), CSDM , SPhf,and FSM at the PCA. Thepurpose of the FCA is to demonstrate to the contracting agencythat the CSCI was successfully tested and meets the requirementsof the-SRS and the IRS(s). The FCA also demonstrates to thecontracting agency that the CSOM, SUM(S), and CSDM adequatelyaddress the operation and support of the computer system. Thepurpose of the PCA is to demonstrate to the contracting agencythat theSPS is complete and F~~fl~~~s p~; ;J;to-date technicaldescription of the CSCI. the CSCI may bepostponed until the system level, if_formal testing of the CSCIrequires system level integration. Specific details regarding theFCA and PCA processes are contained in MIL-STD-1521.
5.6.4 Baselines - CSCI Testing. The configuration identificationdocuments for the HWCIS and CSCIS that comprise a system form asingle Product Baseline. Upon successful completion of the FCAand PCA for each CSCI and when authenticated by the contractingagency, the SPS for the CSCI will be entered into the ProductBaseline. Upon SPS entry into the Product Baseline, the CSCI’SDevelopmental Configuration shall cease to exist. Specificdetails regarding the baseline process are contained inMIL-STD-483.and MIL-STD-490.
5.6.5 Software acceptance. Acceptance of the software by thecontracting agency depends on the nature of the end items undercontract. If only software is contracted for, then softwareacceptance follows PCA for each CSCI. If an integrated hardwareand software system is contracted for, then software acceptance ispart of system acceptance and follows system level PCA. Softwareacceptance shall be predicated on the following:
a. Satisfaction of criteria specified in the SOW and contract
b. Satisfactory completion of FCA and PCA
38
,, .,,.. ,. .>:,,.,
DOD-STD-2167
c. Number and severity oferrors
d. Documented evidence ofand object code
unresolved software and documentation
correlation between the source code
e. Consistency between the code and its associated SPS and VDD
f. Contractor recommendations for acceptance to the contractingagency or its designated representative
9. Certification of compliance with contractual requirements.
Specific details regarding the software acceptance process arecontained in MIL-STD-1521.
5.6.6 Installation and checkout. If required by the SOW, thecontractor shall i~all and checkout the deliverable software atGovernment-designated facilities. The contractor shall specifythe installation and checkout procedures to be followed in theSDP .
5.7 Configuration Management.% The contractor shall implementthe procedures described In either the SCt.fP,SDP, or system CMplan (see Appendix D) which provide technical and administrativedirection and surveillance to: (1) identify and document thefunctional and physical characteristics of each CSCI, (2) controlchanges to those characteristics, and (3) record and report theprocessing of changes and the status of implementation. Thecontractor shall perform software configuration management withinthe framework of the system configuration management and shallensure that integrated procedures address the total systemrequirements, including such items as hardware, related CSCIS,support and training elements and facilities, and Government$urnished hardware o! software, as applicable. The contractorshall perform configuration management on all non-deliverablesoftware used in the development and Oli revisions tocommercially-available computer resources, as described in eitherthe SCMP, SDP, or system CM plan (see Appendix D). The contractor
encouraged to use automated tools in performing configuration&agement (see 5.9.1.4). Additional guidance on Configurationmanagement practices and baselines may be found in MIL-STD-483 andMIL-STD-490.
5.7.1 Activities - Configuration Management. The contractor shallperform the following configuration management activities.
5.7.1.1 Configuration identification. The contractor shallimplement the procedures specified in either the SCMP, SDP, orsystem CM plan (see Appendix D) and approved by the contractingagency. These procedures shall identify the various TLCSCS,LLCSCS, and Units that make up the CSCI, and shall indicate therelationship between the CSCI elements and the documentation for
39
.
DOD-STD-2167
the CSCI. Configuration identification by the contractor shallinclude the following activities,
5,7.1,1.1 The contractor shall identify the followingdocumentation which establishes and defines:
a. The Functional and Allocated Baselines, which shall consistof system and CSCI requirements documents provided orapproved by the contracting agency.
b. The Developmental Configuration, which consists ofdocumentation defining the design and code (includingrevisions) for each CSCI and its constituent TLCSCS, LLCSCS,and Units. The Developmental Configuration also containsthe complete and current software code (source and object)of all Units that have been successfully tested andreviewed. Documental ion and code comprising theDevelopmental Configuration shall be designated forconfiguration control by the contractor until thedocumentation is entered into the Product Baseline and thesource and object code are delivered. Documentation andcode shall be provided to the contracting agency forinformation or provisional review in accordance with thecontract data requirements.
c. The Product Baseline whichsuccessful completion of FCAwill include the approveddocumentation for each CSCIagency configuration control,the contract.
will be established uponand PCA. The Product BaselineDevelopmental Configuration
“and shall be under contractingunless otherwise stipulated in
5.7.1.1.2 The contractor shall identify all documentation andcomputer software media containing code, documentation, or both bytitling, labeling, numbering, and cataloging procedures. Theprocedures shall accomplish the following:
a.
b.
c.
5.7.1.
Uniquely identify all the TLCSCS, LLCSCS, and Units of eachCSCI , and the specific versions of each element to which adocument applies.
Uniquely identify the serial, edition, change status, andother identification details of each document.
Identify the specific contents of each medium, includingchange status.
,2 Configuration control. The contractor shall implement theprocedures speclfled In either the SCMP, SDP, or system m DlanIsee Appendix-D) and approved by the contracting- agency,” tocontrol all changes to the Developmental Configuration, formallybaselined documents, and code for each CSCI. Configurationcontrol by the contractor shall include the following activities.
40
,,
DOD-STD-2167
5,7.1.2.1 The contractor shall include uncler internalconfigurateion control all items entered into the contractor’sDevelopmental Configuration.
5.7.1.2.2 The contractor shall form a Software ConfigurationControl Board (SCCB ) that shal 1 have control over theDevelopmental Configuration. NO changes shall be made to theDevelopmental Configuration without SCCB approval.
5.7.1.2.3 The contractor shall implement a corrective actionsystem to report and track all problems and to implement necessarychanges (see 5.8.1.10).
5.7.1.2.4 Proposed changes which impact the approved documentationcomprising the Functional, Allocated, or Product Baselines shallbe classified and processed in accordance with DOD-STD-480 orMIL-STD-481, as contractually specified, and shall be subject tocontracting agency approval prior to implementation.
5.7.1.2.5 The contractor shall control the preparation anddissemination of changes to both the software and itsdocumentation to reflect approved and implemented changes.
5.7.1.3. Q?-!@$&u! ~ a:c?unti?9. The contractor shallimplement the procedures speclfled In either the SCMP, SDP, orsystem CM plan (see Appendix D) and approved by the contractingagency, to generate periodic status reports on all products in theDevelopmental Configuration and in the Allocated and ProductBaselines. Status reports shall: (1) provide traceability ofchanges to controlled products, (2) serve as a basis forcommunicating the status o: configuration identifications andassociated software, and (3) serve as a vehicle for ensuring thatdelivered documents describe and represent the associatedsoftware.
5.7.2 Products - Configuration Management. The contractor shallprepare the followlng products of configuration management (see6.2).
5.7.2.1. The contractor shall prepare a software problem orchange report to describe each problem discovered and theassociated proposed change. All such reports shall be in theformat specified in either the SCMP, SDP, or system CM plan (seeAppendix D).
5.7.2.2 The contractor shall prepare an Engineering ChangeProposal (ECP) in accordance with DOD-STD-480 or MIL-STD-481, ascontractually specified, to propose each change to the Governmentthat impacts the CSCI’S cost , schedule, interfaces, orGovernment-controlled baselines.
5.7.2.3 The contractor shall prepare a Specification Change Notice(SCN) in accordance with MIL-STD-491J to describe changes to
41
DOD-STD-2167
Government-controlled baselines. Preliminary SCNS shall accompanyECPS , applicable. Additional guidance may be found inMIL-STD-~~3 and MIL-STD-490.
5.7.2.4 The contractor shall prepare. a Version DescriptionDocument (VDD) to identify new and interim versions of each CSCIand associated software product specifications entered in theProduct Baseline.
5.7.2.5 The contractor shall provide the contracting agency withCSCI configuration information from the status accounting system,in the form of reports, electronic data transmittal, or othermedia, as contractually required.
5.7.3 Audits - Configuration Mariaementwill conduct,
~ The contracting agencyand the contractor s all support, an FCA and PCA of
each CSCI in accordance with MIL-STD-1521.
5.8 Software Qual~ty Evaluation. The contractor shall establishand implement Internal procedures to: (1) evaluate therequirements established for the software, (2) evaluate themethodologies established and implemented for developing thesoftware, (3) evaluate the products of the software developmentprocess, (4) provide feedback and recommendations based on theseevaluations that can be used to effect improvements in thesoftware quality, and (5) perform corrective action in terms ofdetecting, reporting, and tracking problems with controlledsoftware and documentation. The methods of evaluation (e.g.,sampling) shall be specified by the contractor in either the SQEPor the SDP.
5.8.1 Activities - Software Quality Evaluation. The contractorshall perform the followlng software quality evaluationactivities.
5.8.1.1 Planning. The contractor shall perform the planningnecessary to establish and implement the tasks specified inSection 5.8 herein.
5.8.1.2 Internal reviews. The contractor shall conduct internalreviews of the methodologies proposed in the contractor’s planningdocuments and of their implementation on the software developmentproject. These reviews shall evaluate the compliance of proposedmethodologies with this standard, their adequacy to producesoftware products that will meet established requirements, andcompliance of the software development process with establishedmethodologies. In addition, the contractor shall conduct internalin-process reviews of the software development products. Theinternal reviews in each software development phase shall be asfollows.
5.8.1.2.1 Evaluation criteria. In conducting reviews of softwareand documentation, the contractor shall use the following
42
I
DOD-STD-2167
evaluation criteria in addition to those specified in 5.8.1.2.2through 5.8.1.2.8:
Adherence to required format:: Compliance with contractual requirementsc. Internal consistencyd. Understandabilitye. Technical adequacyf. Degree of completeness appropriate to the phase.
5.8.1.2.2 Internal reviews - all phases. The contractor shallconduct the follow~ Inter= reviews during all phases of thesoftware development cycle:
a, Review the newly prepared or revised SDP, SSPM, SCMP , andSQEP for the criteria identified in 5.8.1.2.1, compliancewith this standard, and consistency with one another.
b. Rev iew the activities and the tools, procedures, andmethodologies employed during the phase for consistency withthe contractor’s software development plans. Included inthis review shall be evaluation of: (1) softwareconfiguration management, (2) software development library,(3) documentation control, (4) storage and handling ofproject media, (5) control of non-deliverables, (6) riskmanagement, (7) corrective action, and (8) conformance toall approved standards and procedures.
5.8.1.2.3 Internal review - Software Requirements Analysis. Thecontractor shall conduct internal reviews during SoftwareRequirements Analysis. In addition to the reviews specified in5.8.1.2.2, the contractor shall:
a. Review the OCD for: (1) the criteria in 5.8.1.2.1, (2)consistency with the SSS, and (3) ability to provide ahigh-level underst.anding of the system.
b. Review the evolving requirements and the SRS and IRS(s) for:(1) the criteria in 5.8.1.2.1, (2) traceability of thesoftware requirements to the system/segment, prime item, orcritical item specification requirements, (3) consistency ofthe interface requirements with specifications forinterfacing elements, (4) consistency of the SRS and IRS(S)with one another, and (5) testability of the softwarefunctional, performance, and interface requirements,
5.8.1.2.4 Internal review - Preliminaryy *rein::; D:;%;;act;;shall conduct Internal rev?ews duringaddition to the reviews specified in 5.8.1.2.2, the contractorshall:
a. Review the evolving top-level design and STLDD for: (1) thecriteria in 5.8.1.2.1, (2) traceability to software
43
DOD-STD-2167
b.
c,
do
requirements, (3) use of(4) appropriate level of
Review the STP for: (1)adequate test coverage
appropriate design techniques, anddetail.
the criteria in 5.8.1.2.1, (2)of all software requirements, (3)
consistency with the software de.ielopment plans, and” (4)adequacy of test planning.
Review the preliminary versions of the CS014t SUM(S),CSDM for:
and(1) the criteria in 5.8.1.2.1, (2) consistency
with software requirement specifications and designdocuments, (3) appropriateness of content for operators orusers, and (4) consistency with one another,
Review the preliminary CRISD for: (1) the criteria in5.8.1.2.1, (2) consistency with the Government’s supportconcepts, and (3) adequacy of support planning.
5.8.1.2.5 Internal review - Detailed Design. The contractorshall conduct Internal reviews during Detailed Design. Inaddition to the reviews specified in 5.8.1.2.2, the contractorshall:
a.
b.
c.
d ..
e.
Review the evoand DBDD(s),5.8.1.2.1, (2specificationsof appropriateone another.
ving detailed design and the SDDD, IDD(s),as applicable, for: (i) the criteria in
traceability to software requirements.snd top-level design documentation, (3) use
design techniques, and (4) consistency with
Review the STD for: (1) the criteria in 5.8.1.2.1, (2)traceability to the STP, (3) adequate test coverage of thesoftware requirements, and (4) consistency with designdocumentation.
Review a representative subset of the software developmentfiles for: (1) the criteria in 5.8.1.2.1, and (2) accuracyof schedule and status information. Review Unit test casesfor: (1) the criteria in 5.8.1.2.1, (2) traceability to theSTP, (3) adequate test coverage of Unit requirements, and(4) consistency with the design documentation.
Review the CSC integration test cases for:in 5.8.1.2.1, (2) traceability to the STP,coverage of the software requirements, andwith design documentation.
Review the updated CSOM, SUM(s)criteria in 5.8.1.2.1, (2)requirement and design documencontent for operators or users,another.
44
(1) the criteria3) adequate test(4) consistency
and CSDM for: (1) theconsistency with software
s, (3) appropriateness ofand (4) consistency with one
. .
130D-STT)-267
f. Review the completed CRISD for: (1) the criteria in5.8.1.2.1, (2) consistency with the Government’s supportconcepts, and (3) adequacy of support planning.
9. Review the SPt.fand FSM for:(2)
(1) the criteria in 5.8.1.2.1,consistency with design documentation, and (3)
appropriateness of content for suppor”tpersonnel.
5.8.1.2.6 Internal review - C- and Unit Testing. The— .contractor shall conduct Internal revi= d=g Coding and UnitTesting. In ad?ition to the reviews specified in 5.8.1.2.2, thecontractor shall:
a,
b,
c.
d.
e.
f.
9.
Review the evolving and completed source code of eachsoftware Unit for: (1) the criteria in 5.8.1.2.1, (2)compliance with coding standards, and (3) traceability todetailed design documentation.
Ref7iewa representative subset of the updated softwaredevelopment files for: (1) the criteria in 5.8.1.2.1, and(2) the accuracy of status and schedule information. Reviewthe Unit test procedures and Unit test results forto ;nl~l) thecriteria in 5.8.1.2.1, and (2) traceability testplans and Unit test cases. Based on Unit test results,evaluate whether each Unit is ready tc be entered into theDevelopmental Configuration.
Review the updated STLDD, SDDD , IDD(s), and DBDD(s), asapplicable, for: (1) ‘the criteria in 5.8.1.2.1, (2)traceability to software requirements specifications, ,(3)use of appropriate design techniques, and (4) consistencywith one snother.
Reviewr as applicable, updated source code for: (1) the’criteria in 5.8.1.2.1, (2) compliance with coding standards,and (3) consistency with the updated detailed designdocumentation.
Review the informal.CSC integration(1) the criteria in 5.8.1:2.1,
test procedures for:(2) traceability to CSC
intecjrationtest plans and test cases, (3) adequate testcoverage of software requirements, and (4) consistency withdesign documents.
Review the preliminary STPR for: (1) the criteria in5.8.1.2.1,’(2) traceability to the STP and STD, (3) adequatetest coverage of the software requirements, and (4)consistency with the design documentation.
Review the updated CSOt4,SUM(s), and CSDt.f’for: .(1) thecriteria in 5.8.1.2.1, (2) consistency with softwarerequirement and design documents, (3) appropriateness ofcontent for operators or users, and (4) consistency with one
45
DOD-STD-2167
another.
h. Review, as applicable, the updatedcriteria in 5.8.1.2.1, (2)
SEW and FSM for: (1) theconsistency with desian
documentation, and (3) appropriateness of- content f~rsupport personnel.
5.8.1.2.7 Internal review - CSCcontractor shall conduct in=na +%%%%&+ C&s~;~~~raZ~~and Testing. In addition to the reviews specified in 5.8.1.2.2,the contractor shall:
a.
b.
c.
d.
e.
f.
9.
Review the informal test results of CSC integrationfor: (1) the criteria in 5.8.1.2.1, and (2) traceabi~~;~l%the CSC test cases and test procedures. Based on theinformal integration test results, evaluate whether theintegrated CSCI performs correctly and is ready toformal testing.
undergo
Review the updated STLDD, SDDD, IDD(s), and DBDD(s), asapplicable, for: (1) the criteria in 5.8.1.2.1, (2)traceability to software requirements specifications, (3)use of appropriate design techniques, and (4) consistencywith one another.
Rev,iew updated source code for: (1) the criteria in5.8.1.2.1, (2) compliance with coding standards, and (3)consistency with the updated design documentation.
Review a representative subset of the updated softwaredevelopment files, as applicable, for: (1) the criteria in5.8.1.2.1, and (2) accuracy of status and scheduleinformation.
Review the completed STPR for: (1) the criteria ‘5.8.1.2.1, (2) traceability to the STP and STD, (3) adequa~~test coverage of the software requirements, and (4)consistency with the design documentation.
Review the updated CSOM, SUM(s), and CSDt4 for: (1) thecriteria in 5.8.1.2.1, (2) consistency with softwarerequirement and design documents, (3) appropriateness ofcontent for operators or users, and (4) consistency with oneanother.
Review, as applicable, the updated SPM and PSM for: (1) thecriteria in 5.8.1.2.1, (2) consistency with desiqndocumentation, and (3) appropriateness of- content f;rsupport personnel.
5.8.1.2.8 Internal review - CSCI Testing. The contractor shallconduct internal re~dur~CSCI Testing. In addition to thereviews specified in 5.8.1.2.2, the contractor shall:
46
DOD-STD-2167
a.
b.
c.
d.
e.
f.
9.
h.
i.
Monitor the CSCI testing to ensure that: (1) it isperformed using the current controlled version of the code,(2) it is conducted in accordance with approved test plans,descriptions, and procedures, and (3) it includes allnecessary retesting.
Review the STRS for: (1) the criteria in 5.8.1.2.1, and (2)traceability of the CSCI test results to the CSCI testplans, test cases, and test procedures. Based on the CSCItest results, evaluate whether the CSCI meets its specifiedrequirements.
Review the updated STLDD, SDDD , IDD(s), and DBDD(s), asapplicable, for: (1) the criteria in 5.8.1.2.1, (2)traceability to software requirements specifications, (3)use of appropriate design techniques, and (4) consistencywith one another.
Review updated source code, as applicable, for: (1) the.criteria in 5.8.1.2.1, (2) compliance with coding standards,and (3) consistency with the updated detailed designdocumentation.
Review a representative subset of updated softwaredevelopment files, as applicable, for: (1) the criteria in5.8.1.2.1, and (2) accuracy of status and scheduleinformation.
Review the SPS for: (1) the criteria in 5.8.1.2.1, and (2)incorporation of design documentation and software listingsconsistent with the “as-builtm software.
Review the VDD for: (1) the criteria in 5.8.1.2.1, and (2)accuracy in reflecting the exact version of each CSCI.
Review the completed CSOM, SUM(s), and CSDM for: (1) thecriteria in 5.8.1.2.1, (2) consistency with the ~gj, [~]appropriateness Of content for operators or users,consistency with one another.
Review, as applicable, the updated SPt4and FSt4for: (1) thecriteria “ 5.8.1.2.1,documentati~~,
(2) consistency with designand (3) appropriateness of content for
support personnel.
5.8.1.3 Formal reviews and audits. The contractor shall evaluatethe plan=n~r=on performed for each formal review andaudit in 5.1 through 5.6, to ensure that all required productswill be available and ready for Government review.
5.8.1.4 Acceptance inspection. The contractor shall supportacceptance inspection by ensuring that all required products areavailable. and ready for Government inspection, all required
47
DOD-STD-2167
procedures have been performed, and evidence of these proceduresis available for Government inspection.
5.8.1.5 installation and checkout. The contractor shall evaluateinstallation and checkout of the software, if required by thecontract, to ensure that this activity has been carried out incompliance with procedures specified in the software developmentplans.
5.8.1.6 Evaluation ~ subcontractorsoftware or documentation develo-s;;;~;~~;;~pt;;~contractor shall evaluate them for completeness, technicaladequacy, and compliance with subcontract requirements.
5.8.1.7 Commercially available, reusable, and Governmentfurnished software. The contractor shall eval=e the plannlngperforned for the use of commercially available, reusable, andGovernment furnished software to ensure that all relevant factorshave been considered. Upon acquisition, the contractor shallevaluate the software to determine whether it performs asdocumented, prior to incorporating it into the software beinqdeveloped. The contra~toravailable and reusable softwareis documented adequately.
5.8.1.8 Preparation ~ qualityprepare and maintain records ofThese records shall identifyevaluation participants, itemsof the evaluation, all detectedresulting from the evaluation.
shall certify that commerciall~performs as documented and that it
records. The contractor shalleach quality evaluation performed.the date of the evaluation,
or activities reviewed, objectivesproblems, and any recommendations
5.8.1.9 _ reporting~ The contractor shall prepare reportsthat provide to contractor management the results andrecommendations from the quality evaluations specified herein.The quality evaluation reports shall identify the activitiesperformed, all detected problems, necessary remedial action,identified trends in the problems reported, and recommendedchanges to improve software quality.
5.8.1.10 Corrective action system. ‘The contractor shallimplement a correct~ action system for all software anddocumentation that has been placed under contractor or Governmentcontrol (e.g., development plans, test documentation, designdocumentation, etc.). The corrective action system shall includeprovisions for: (1) reporting detected problems, (2) analyzingthese problems, (3) classifying problems by category and bypriority, (4) identifying necessary corrective action, (5)identifying trends in the problems reported, (6) analyzing thesetrends to recommend changes that will improve software quality,(7) authorizing the implementation of corrective steps, (8)documenting the corrective actions taken, (9) performingreevaluation after corrections have been made, (10) tracking and
48
I
.,. .:.,,., .
DOD-STD-2167
closing out the problems reported, and (11) providing Governmentvisibility into critical problems based on fhe categorization andpriority schemes and problem/change reports.
5.8.1.11 Quality cost data. The contractor shall collect,analyze, and document data relative to the cost of detecting andcorrecting errors in all software and documentation that have beenplaced under contractor or Government control. The specific datato be collected and the analyses to be performed shall be proposedby the contractor in either the S.~Yi’~L” SW (see Appendix D) andshall be subject to contracting age~..j dpproval.
5.8.2 Products - Software Quality Evaluation (see 6.2).
5.8.2.1 Quality records. The contractor shall prepare andmaintain records of each quality evaluation performed.
5.8.2.2 Quality reports. The contractor shall prepare andmaintain reports that summarize the results and recommendations ofthe quality evaluations performed. These reports shall beavailable for Government review.
5,8.2.3 Certification. The contractor shall collect and makeavailable for Government inspection evidence indicating thecomp~iance with the requirements of the contract of each contractline item delivered under the contract.
5..8.3 Independence. Each activity specified in 5.8 herein shallbe performed by Individuals who have sufficient responsibility,authority, resources, and independence to accomplish objectiveevaluation of the products and activities being reviewed. Thedegree of independence varies with such factors as projectcomplexity and criticality. The contractor shall specify thedegree of independence in either the SQEP or SDP (see Appendix D).
development- project.
5.9.1 Activities - Softwarecontractor shall performactivities.
5.9 Software project planning and control. The contractor shallimplement -procedures for pl=ing and controlling the software
project Q@!l@ @ con~~~~;oll~~;the followlng plannlng and
5.9.1.1 S~z~ng andderive slzlng
~% assessments. The contractor shallparameters appropriate for the C,SCI,
including minimum reserve capacities, and shall develop initialestimates during Software Requirements Analysis of theseparameters’ values and allowed margins. During the remainder ofthe development, the contractor shall monitor these parameters andreallocate as necessary to meet requirements specified in the SRS.As Units of code are completed, tested, and successivelyintegrated with one another, the contractor shall measure thesesizing and timing parameters, compare these measurements with
49
DOD-STD-2167
estimates, and update overall CSCI sizing and timing records toreflect the results of these measurements. All modifications tocontrolled or baselined documentation shall be made in accordancewith the configuration management requirements contained herein(see 5.7).
5.9.1.2 Status and cost re ortin—-
The contractor shall maintaincost and~u~forecasts, ana yses, and reports to at least theCSCI level. These reports shall indicate to the contractingagency predicted and planned progress versus actual progress.Cost reports shall include budgeted versus actual expenditures andshall conform to the Work Breakdown Structure (WBS) applicable tothe development effort. Additional guidance for cost and statusreporting may be found in MIL-STD-881.
5.9.1.3 Test documentation control. Once the contracting agencyapproves the STP, STD , and STPR the contractor shall establishInternal control over these documents. The contractor shallnotify, the contracting agency at the next review, audit, or in thenext status report (whichever comes first) of any proposed changesto these documents, and shall obtain contracting agency approvalbefore making any of the proposed changes.
5.9.1.4 Software development library (SDL). The contractor shallestablish and Implement a softwa~velopment library forcontrolling all software and associated documentation. Proceduresand methodologies for establishing and implementing the SDL *shallbe specified in the SDP.
5.9.1.5 Risk managment. The contractor shall establish andimplement=e risk management procedures specified in the SDP forcontrolling risk. The procedures shall include:
a.
b.
c.
d.
e.
f.
9.
Identifying the risk areas of the project and theconstituent risk factors in each area.
Assessing the risk factors identified, including theprobability of occurrence and the potential damage.
Assigning appropriate resources to reduce the risk factors.
Identifying and analyzing the alternatives available forreducing the risk factors.
Selecting the most promising alternative for each riskfactor.
Planning implementation of the selected alternative for eachrisk factor.
Obtaining feedback to determine the success of the riskreducing action for each risk factor.
50
I
6.1 Intended ~deve~ooment andDirective 5000.29.
,. ,..>
DOD-STD-2167
6. NOTES
This standard is intended foracquisition of MCCS software,
use duringas defined in
theDOD
This standard may also be used for non-t4CCSsoftware development and acquisition:
6.2 Data re uirements ~ and cross reference.stand~ i~
When thisIn an acqui~io~ch~tes a DD Form
1423, Contract Data Requirements List (CDRL ), the datarequirements identified below shall be developed as specified byan approved Data Item Description (DD Form 1664) and delivered inaccordance with the approved CDRL incorporated into the contract.When the provisions of the DOD FAR Supplement 27.410-6 are invokedand the DD Form 1423 is not used, the data specified below shallbe delivered by the contractor in accordance with the contract orpurchase order requirements. .Deliverable data required by thisstandard is cited in the following subparagraphs.
Paragraph.No. Data Requirements Title— Applicable DID No—J
5.1, 5.1.1.5, System/Segment DI-CMAN-800085.8.1.2.3, 20.4.1, Specification20.4.2, 20.4.5.2,30.3.1, 30.3.1.1,30.3.1.3, 40.6.2.2
4.3, 4.4, 4.6, 4.4.8, 5.1, 5.1.l.l5.1.1.2, 5.1.1.7,5.1.2.1, 5.2,5.2.1.1, 5.2.1.3,5.2.1.4, 5.2.2.1,5.3.1.1, 5.3.1.3,5.3.1.4, 5.3.1.5,5.3.1.8, 5.3.2.1,5.3.2.7, 5.4.1.1,5.4.1.2, 5.4.1.3,5.4.1.4, 5.4.2.1,5.4.2.4, 5.4.2.5,5.5.1.1, 5.5.1.2,5.5.1.3, 5.5.1.6,5.5.2.1, 5.5.2.4,5.6.1.1, 5.6.2.1,5.6.6, 5.7,5.7.1.1, 5.7.1.2,5.7.1.3, 5.7.2.1,5.8.1.2.2, 5.8.1.
7,,,
Software DevelopmentPlan
DI-MCCR-80030
I
11,
Paragraph No.
5.8.3, 5.9.1.4,5.9.1.5, 20.4.3,20.4.5.2, 30.1,30.2, 30.3.1.1,30.3.1.2, 40.5.1,40.6.2.1
4.3, 5.1, 5.1.1.1,5.1.1.2, 5.1.2.1,5.2.1.1, 5.2.2.1,5.3.1.1, 5.3.2.1,5.4.1.1, 5.4.2.1,5.5.1.1, 5.5.2.1,5.6.1.1, 5.6.2.1,5.7, 5.7.1.1,5.7.1.2, 5.7.1.3,5.7.2.1, 5.8.1.2.2,40.5.1, 40.6.2.1
4.3, 5.1, 5.1.1.1,5.1.1.2, 5.1.2.1,5.2.1.1, 5.2.1.4,5.2.2.1, 5.3.1.1,5.3.2.1, 5.4.1.1;5.4.2.1, 5.5.1.1,5.5.2.1, 5.6.1.1,5.6.2.1, 5.8.1.2.2,5.8.1.11, 5.8.3,40.5.1, 40.6.2.1
5.1.1.5, 5.1.1.6,5.1.1.7, 5.1.2.4,5.1.3, 5.1.4, 5.2,5.2.1.2, 5.3.3,5.6.3, 5.8.1.2.3,5.9.1.1, 20.4.2,20.4.3, 20.4.5.2,40.6.2.2
5.1.1.5, 5.1.1.6,5.1.2.4, 5.1.3,5.1.4, 5.2,5.2.1.2, 5.3.2.4,5.3.3, 5.6.3,5.8.1.2.3, 20.4.2,20.4.3, 20.4.5.2,40.6.2.2
SoftwareConfigurationManagement Plan
DI-MCCR-80ClC19
—
Software QualityEvaluation Plan
SoftwafeRequirementsSpecification
InterfaceRequirementsSpecification
DI-MCCR-8OO1O
DI-MCCR-80025
DI-MCCR-80026
DOD-STD-2167
Data Requirements Title Applicable DID NO.J~
52
DOD-STD-2167
Paragraph NO.J
4.3, 4.8, 5.1,5.1.1.1, 5.1.1.2,5.1.1.7, 5.1.2.1,5.2, 5.2.1.1,5.2.1.3, 5.2.1.4,5.2.2.1, 5.3.1.1,5.3.1.3, 5.3.1.4,5.3.1.5, 5.3.1.8,5,3.2.1, 5.3.2.7,5.4.1.1, 5.4.1.2,5.4.1.3, 5.4.1.4,5.4.2.1, 5.4.2.4,5.4.2.5; 5.5.1.1,5.5.1.2, 5.5.1.3,5.5.1.6, 5.5.2.1,5.5.2.4, 5.6.1.1,5.6.2.1, 5.8.1.2.2,20.4.3, 30.1,30.2, 30.3.1.1,40.5.1, 40.6.2.1
5.2.1.2, 5.2.2.3,5.2.3, 5.2.4,5.3.3, 5.8.1.2.4,5.8.1.2.6,5.8.1.2.7,5.8.1.2.8,20.4.3, 40.6.2.2
5.2.1.3, 5.2.2.4,5.2.3, 5.3.1.2,5.3.2.3, 5.3.3,5.3.4, 5.8.1.2.5,5.8.1.2.6,5.8.1.2.7,5.8.1.2.8,20.4.3, 40.6.2.2
5.2.1.3, 5.2.2.4,5.2.3, 5.3.1.2,5.3.2.4, 5.3.3,5.3.4, 5.8.1.2.5,5.8.1,2.6,5.8.1.2.7,5.8.1.2.8,20.4.3, 40.6.2.2
Data Requirements Title Applicable DID No.A
Software Standards and DI-MCCR-80011Procedures Manual
SoftwareTop Level DesignDocument
DI-MCCR-80012
Software Detailed DI-MCCR-80031Design Document
InterfaceDesign Document
DI-MCCR-80027
53
DOD-STD-2167
Paragraph NoJ
5.2.1.3, 5.2.2.4,5.2.3, 5.3.1.2,5.3.2.5, 5.3.3,5.3.4, 5.8.1.2.5,5.8.1.2.6,5.8.1.2.7,5.8.1.2.8,20.4.3, 40.6.2.2
5.6.2.5, 5.6.3,5.6.4, 5.6.5,5.8.1.2.8, 20.4.3,40.6.2.2
5.6.1.5, 5.6.2.6,5.6.3, 5.6.5,5.7.2.4, 5.8.l.2.8,40.6.2.2
5.2.1.6, 5.2.2.5,5.2.3, 5.3.1.14,5.3.2.8, 5.3.3,5.4.1.7, 5.5.1.5,5.6.1.2, 5.8.1.2.4,5.8.1.2.5,5.8.1.2.6,5.8.1.2.7, 5.9.1.3,20.4.3, 40.6.2.3
5.3.1.14, 5.3.2.8,5.3.3, 5.6.1.2,5.8.1.2.5,5.8.1.2.6,5.8.1.2.7, 5.9.1.3,20.4.3, 40.6.2.3
5.4.1.12, 5.4.2.6,5.5.1.8, 5.5.2.6,5.5.3, 5.6.1.2,5.8.1.2.6,5.8.1.2.7,5.9.1.3, 40.6.2.3
5.6.1.3, 5.6.2.3,5.6.3, 5.8.1.2.8,40.6.2.3
5.2.1.7, 5.2.2.6,5.2.3, 5.3.1.15,5.3.2.9, 5.3.3,
Data Requirements Title Applicable DID No..—
Data Base DI-MCCR-80028Design Document
Software ProductSpecification
VersionDescriptionDocument
Software TestPlan
Software TestDescription
Software TestProcedure
Software TestReport
Computer SystemOperator’s Manual
DI-MCCR-80029
DI-MCCR-80013
DI-MCCR-80014
DI-MCCR-80015
DI-MCCR-80016
DI-MCCR-80017
D1-MCCR-80018
54
Paragraph No. Data—
5.4.1.13, 5.4.2.7,5.5.1.9, 5.5.2.7,5.5.3, 5.6.1.6,5.6.2.7, 5.6.3,5.8.1.2.4,5,8.1.2.5;5.8.1.2.6,5.8.1.2.7,5.8.1.2.8, 20.4.3,40.6.2.4
DOD-STD-2167
Requirements Title Applicable DID No—J
5.2.1.8, 5.2.2.6, Software User’s5.2.3, 5.3.1.15, Manua 15.3.2.9, 5.3.3,5.4.1.13, 5.4.2.7,5.5.1.9, 5.5.2.7,5.5.3, 5.6.1.6,5.6.2.7, 5.6.3,5.8.1.2.4,5.8.1.2.5,5.8.1.2.6,5.8.1.2.7,5.8.1.2.8, 20.4.3,40.6.2.4
DI-MCCR-80019
5.2.1.9, 5.2.2.6, ComputerSystem DI-MCCR-800205.2.3, 5.3.1.15, Diagnostic Manual5.3.2.9, 5.3.3,5.4.1.13, 5.4.2.7,5.5.1.9, 5.5.2.7,5.5.3, 5.6.1.6,5.6.2.7, 5.6.3,5.8.1.2.4,5.8.1.2.5,5.8.1.2.6,5.8.1.2.7,5.8.1.2.8, 20.4.3,40.6.2.4
5.3.1.17, 5.3.2.11, Software Programmer’s DI-MCCR-800215.3.3, 5.4.1.13, Manua 15.4.2.7, 5.5.1.9,5.5.2.7, 5.6.1.6,5.6.2.7, 5.6.3,5.8.1.2.5, 20.4.3,40.6.2.4
55
DOD-STD-2167
Paragraph NO.
5.3.1.18, 5.3.2.11,5.3.3, 5.4.1.13,5.4.2.7. 5.5.1.9.5,5.2.7: 5.6.1.6;5,6.2.7, 5.6.3,5.8.1.2.5, 20.4.3,40.6.2.4
5.1, 5.1.1.3,5.1.1.4, 5.1.2.2,5.1.3, 5.8.1.2.3,20.4.2, 20.4.3,20.4.5.2, 40.6.2.4
5.2.1.10, 5.2.2.6,5.2.3, 5.3.1.16,5.3.2.10, 5.3.3,5.8.1.2.4,5.8.1.2.5,20.4.3, 40.6.2.4
Data Requirements Title Applicable DID No.II
Firmware Support DI-MCCR-80022Manual I
Operational ConceptDocument
Computer ResourcesIntegrated SupportDocument
DI-MCCR-80023
DI-MCCR-80024
5.7, 5.7.l.2, Configuration DI-E-31085.7.1.3, 5.7.2.1 Management Plan
5.7.2.2, 5.7.2.3, Engineering DI-E-312840.6.2.2 Change Proposal
5.7.2.3, 40.6.2.2 Specification DI-E-3134Change Notice
(Data item descriptions related to this standard, and identifiedsection 6 will be approved and listed as such in DOD
%00.19-L., vol. II, AMSDL. Copies of data item descriptionsrequired by the contractors in connection with specificacquisition functions should be obtained from the Nava 1Publications and Forms Center or as directed by the contractingofficer.)
6.3 Subject term (key - listing.
AcquisitionCodeCode and unit testingComputerComputer resourcesComputer softwareComputer software componentComputer software configuration itemConfiguration itemConfiguration managementCsc
56
DOD-STD-2167
CSC integration and testingCSC ICSCI testingData item descriptionsDetailed designFirmwareFormal testingInformal testingLLCSCLower level computer software componentMission-criticalMission-critical computer resourcesMission-critical computer systemPreliminary des’ignQualityQuality evaluationRequirements analysisRisk managementSoftwareSoftware acquisitionSoftware codeSoftware configuration itemSoftware configuration managementSoftware designSoftware detailed designSoftware developmentSoftware integrationSoftware preliminary designSoftware qualitySoftware quality evaluationSoftware requirementsSoftware requirements analysisSoftware standardsSoftware testTailoringTailoring of software requirementsTestingTLCSCTop-level computer software componentUnit
57/58
A
DOD-STD-2167APPENDIX A
LIST OF ACRONYMS AND ASBREVIATIONS
10. General.
10.1 Purpose. This appendix provides a list of all acronyms andabbreviations used in this standard, with the associated meaning.
10.2 Acronyms.
CDRCDRLCMCRISDCscCSC ICSDt4CSOMDBDDDIDDODDODISS
ECPFARFCAFSMGFEGFSHOLHWCIIDDIRSLLCSCMCCSNSCCAOCDPCAPDRPROMRFPROMSCCBSCMPSCNSDDDSDFSDLSDPsowSPMSPS
Critical Design ReviewContract Data Requirements ListConfiguration ManagementComputer Resources Integrated Support DocumentComputer Software ComponentComputer Software Configuration ItemComputer System Diagnostic ManualComputer..System Operator’s ManualData Base Design DocumentData Item DescriptionDepartment of DefenseDepartment of Defense Index of
Specifications and StandardsEngineering Change ProposalFederal Acquisition RegulationFunctional Configuration AuditFirmware Support ManualGovernment Furnished EquipmentGovernment Furnished SoftwareHigher order languageHardware Configuration ItemInterface Design DocumentInterface Requirements SpecificationLower-level computer SOftWare COMpOnentMission-Critical Computer SystemNuclear safety cross-check analysisOperational Concept DocumentPhysical Configuration AuditPreliminary Design ReviewProgrammable read-only memoryRequest for proposalRead-only memorySoftware Configuration .Control BoardSoftware Configuration Management PlanSpecification Change NoticeSoftware Detailed Design DocumentSoftware Development FileSoftware Development LibrarySoftware Development PlanStatement of WorkSoftware Programmer’s ManualSoftware Product Specification
59
SRSSSASSPMSSRSssSTDSTLDDSTPSTPRSTRSUMTLCSCTRRVDDWBS
DOD-STD-2167APPENDIX A
Software Quality Evaluation PlanSoftware Requirements SpecificationSoftware Support AgencySoftare Standards and Procedures ManualSoftware Specification ReviewSystem/Segment SpecificationSoftware Test DescriptionSoftware Top Level Design DocumentSoftware Test PlanSoftware Test ProcedureSoftware Test ReportSoftware User’s ManualTop-level computer software componentTest Readiness ReviewVersion Description DocumentWork Breakdown Structure
60
DOD-STD-2167APPENDIX B
SYSTEM LIFE CYCLE
20. General.
20.1 Purpose. This appendix provides information on the systemlife cycle and the framework in which software development isconducted under the provisions of this standard.
20.2 Scope. This appendix briefly describes a typical system lifecycle and its relationship to iterations of the softwaredevelopment cycle (see Figures 1 and 4). It also describes thedocuments that result from early system acquisition activities.The activities and phases described in this appendix includeactivities and phases for which the contractor is not responsible,as well as those for which the contractor is responsible.
20.3 Applicability. The information in thisgeneral, tutorial
appendix is of anature and is not a requirement of this
standard.
20.4 General information. The system life cycle consists of four~n~eptphases: Exploration, Demonstration and Validation, Full
Scale Development, and Production and Deployment. The softwaredevelopment cycle consists of six phases:: Software RequirementsAnalysis, Preliminary Design, Detailed Design, Cod ing and UnitTesting, CSC Integration ad Testing, and CSCI Testing. The totalsoftware development cycle or a subset may be performed withineach of the system life cycle phases. Successive iterations ofsoftware development usually build upon the products of previousiterations (see-Figure 2). -
20.4.1 Concept ~loration. Theinitial plannlng period wheneconomic bases are establishedexperimental development, andplanning may be directed towarddeveloping alternative conceptscapability.
Concept Exploration Phase is thethe technical, strategic, andthrough comprehend ive studies,
concept evaluation. This initialrefining proposed solutions orto satisfy a required operational
a. During this phase, proposed solutions are refinedalternative concepts are developed using feasibili~~assessments, estimates (cost and schedule, intelligence,logistics, etc.), trade-off studies, and analyses. The 55Aand user should be involved in these activities.
b. For computer resources, the software development cycleshould be tailored for use during this phase and may resultin demonstration of critical algorithms, breadboards, etc.
61
DOD-STD-2167APPENDIX B
MILESTONE Ill
PRODUCTION ANDDEPLOYMENT
A
5
FSD PRODUCTION AND DEPLOYMENT PHASE\
A,
I
..:”</ ““D:::‘;:‘;’’’’=‘=”f REowy,M,mTs
.wsIEMIHARDWARE.EO”,. EMENTS
ANA LVSIS
=$=.~ + ~ “+ 4 9WSTEM/SOFTWAREeEym;m:,;ls I
$OFTWA.Enmum:wTs
>“ ;:’ : ‘s;:O‘,x=’‘,,==. POSS,WE CHANGE RECIUIREMENTS
SYSTEM UPGRADE I IHARDWARE uPGRADESOFTWARE ENHANCEMENTERROR cORRECTION
i :
~__–_. o,v,L.JPMENTALCUNFIOURATION-
ADAPTATION CHP.NGES
,“NCTI ONA L A:UC4L:DBASEL!NE
FIGURE 4. System supporl cycle within the system life cycle.
62
DOD-STD-2167
APPENDIX 3
I SVSTEMRETIREMENT I
\ PRODUCTION AbD DEPLOYMENT PHASE
-rEE1---fEEHEzlI I
REVIEWS
SRR SYSTEM REOUIREMENTS REVIEWSDR - SYSTEM DESIGN REVIEWSSR - SOFTWARE SPECIFICATION REVIEWPDR - PRELIMINARY DESIGN REVIEWCDR - CRITICAL DESIGN REVIEWTRR - TEST READINESS REVIEWFCA - FUNCTIONAL CONFIGURATION AUDIT
I PCA - PHYSICAL CONFIGURATION AUDIT
1
FOR - FORMAL OUALIFICATION REVIEW— — — —
PRODUCTSASELINE
FIGURE 4. System support cycle within the system life cycle. (continued)
63
DOD-STD-2167APPENDIX B
c. The major document resulting from this-phase is the initialSSS, which documents total system requirements. The SSS maydifferentiate between the requirements to be met by computersoftware and those applicable to hardware design. Whenapplicable, definitions of interfaces between computerequipment functions, communication functions, and personnelfunctions are provided to enable the further definition andmanagement of the computer software and computer equipmentresources. Normally, this information is derived fromsystem engineering studies. Deliverable products at the endof the Concept Exploration phase typically includepreliminary Sss(s), preliminary Prime Item DevelopmentSpecifications, software listings, and software testresults, etc. The System Requirements Review is thetechnical review that should be accomplished.
20.4.2 Demonstration and Validation. The Demonstration andValidation Phase 1s t~perlod when major system characteristicsare refined through studies, system engineering, development ofpreliminary equipment and prototype computer software, and testand evaluation. The objectives are to validate the choice ofalternatives and to provide the basis for determining whether ornot to proceed into the next phase.
a. During this phase, system requirements, includingrequirements for computer resources, are further defined,and preferred development methodologies for computersoftware and data bases are selected. The results ofvalidation activities are used to define the systemcharacteristics (performance, cost, and schedule) and toprovide confidence that risks have been resolved orminimized.
b. For computer resources, the software development cycleshould be tailored for use during this phase, resulting inprototype software items.
c. The major documents resulting from this phase are theauthenticated SSS(s), authenticated Prime Item DevelopmentSpecifications, and preliminary IRS(s) and SRSS forCSCI .
eachThe authenticated SSS(s) establish the system or
segment Functional Baseline. Each authenticated Prime Item.Development Specification contains the system requirementsallocated to the equipment and software and establishes theAllocated Baseline for each prime item. Each preliminarySRS contains system or prime item requirements allocated toa CSCI. Each preliminary IRS defines the interfaces andqualification requirements for a CSCI within the system,segment, or prime item. The Allocated Baseline for eachCSCI is established following Software Requirements Analysiswithin the software development cycle. A preliminaryversion of the Operational Concept Document (OCD) should
64
DOD-STD-2167
also besystem,
APPENDIX B
prepared to identify and describe the mission of theoperational and support environments of the system,
and the functions and characteristics of the computer systemwithin the overall system. The System Design Review is thetechnical review that should be accomplished.
20.4.3 Full Scale Development. The Full Scale Development phaseis the period when the system, equipment, computer software,facilities, personnel subsystems, training, and the principalequipment and software items necessary for support are designed,fabricated, tested, and evaluated. It includes one or more majoriterations of the software development cycle. The intended”outpuis are a system which closely approximates the productionitem, the documentation necessary to enter the system’s Productionand Deployment phase, and the test results that demonstrate thatthe system to be produced will meet the stated requirements.During this phase the requirements for additional software itemsembedded in or associated with the equipment iterns may beidentified. These requirements may encompass firmware, testequipment, environment simulation, mission support, developmentsupport, and many other kinds of software.
a.
b.
Software requirements analysis is performed in conjunctionwith system engineering activities related to equipmentpreliminary design. SRSS and IRSS for each CSCI arecompleted and authenticated at the SSR, establishing theAllocated Baseline for each CSCI. Requirements for softwarethat is part of an HWCI may be authenticated during HWCIdesign reviews. The OCD is completed and reviewed at theSSR as well.
A preliminary design effort is accomplished and results in adesign approach. For computer software, preliminary designincludes the definition of TLCSCS in terms of functions,external and internal interfaces, storage and timingallocation, operating sequences, and data base design.Detailed desion of critical lower-level elements of the CSCImay be perfor~ed as well. A PDR is held to review thesoftware top-level design docum~~haaainst the respectiveauthenticated specifications forCSC1. The following documents arePDR :
STP - to define the plans fortesting of the CSCI.
“equipment it;m andalso presented at the
informal and formal
Preliminary Csohf - to define the procedures andinformation necessary to operate the computer system inwhich the CSCIS execute.
Preliminary SUM(s) - to define the instructions forusers to execute each CSCI.
65
DOD-STD-2167APPENDIX B
Preliminary CSDM - to define the information andprocedures necessary to identify a malfunction andinstructions to run the diagnostics.
Preliminary CRISD - to define the information that isrequired to perform life cycle support of thecontractually deliverable software.
c. Formal engineering change control procedures are implementedto prepare, propose, review, approve, implement, and recordengineering changes to each Allocated Baseline.
d. Informal engineering change control by the contractor startswith the establishment of each CSCI’S DevelopmentalConfiguration. The Developmental Configuration isestablished at PDR by the STLDD as the repository for theapproved design documents, software, and software listings.Following successful completion of FCA and PCA, thedocuments and listings of the Developmental Configurationare included in the SPS which establishes the ProductBaseline. This baseline is used to control the software asit is integrated with other CSCIS and HWCIS.
e. Following an acceptable PDR for an item, detailed design ofthat item begins. During this activity, engineeringdocumentation such as drawings, product specifications, testprocedures, and descriptions” are produced. For computersoftware, detailed design is accompanied by detailed designdocumentation of logical flows, functional sequences andrelations, formats, constraints, data bases, andincorporation of reused design. The CDR should assure thatthe recommended design satisfies the requirements of the SRSand, if applicable, IRS(s). At the CDR! the detailed designdocuments (i.e. SDDD and, if applicable, DBDD (S ) and
IDD(s)) are reviewed. Equipment/personnel/computer softwareinterfaces should be finalized at this time. A primaryproduct of the CDR for software is the Government andcontractor concurrence on the detailed design documents thatwill be released for coding aridUnit testing. Additionaldocuments prepared during detailed design and reviewed atCDR include:
STD - to describe the test cases for all formal testingof the CSCI.
CRISD - to define the information that is required toperform life cycle support cf the contractuallydelivered software.
SPM - to define the information which facilitatesprogramming or reprogramming software for the targetcomputer.
66
DCJD-STD-2167APPENDIX B
FSM - to define the information necessary to modify orreplace the firmware devices in the Mission-CriticalComputer system.
f. Following CDR , software cod ing and testing, softwareintegration and testing; software formal testing, system ‘“integration and testing, and initial operational test andevaluation are conducted. Software coding is performed inaccordance with standards and procedures contained in theapproved SDP (or 55PM, if applicable). Software testing isperformed according to test plans submitted for review atPDR, test descriptions submitted for review at CDR, and testprocedures submitted for review at TRR. These activitiesnormally proceed in such a way that testing of selectedfunctions begins early during development and proceeds byadding successive increments to the point where a completeCSCI is subjected to formal testing. Additional testequipment may be required to properly simulate anoperational ’environment to test a CSCI. The scope andrealism of software testing may be progressively expanded asadditional increments are made available for this purpose.Adequacy of the performance of the software is checked tothe maximum extent possible, sometimes through use ofsimulation, prior to software installation in a field siteor operational computer. Nuclear safety cross-checkanalysis (NSCCA) is also performed on specified computerresource items during this phase. Satisfactory performanceof the software for a large operational system may not becompletely demonstrated and assessed until completion ofsystem integration and operational test and evaluation ofthe equipment or of the system. Software that is relativelyinsensitive to the system’s operational environments may becompletely demonstrated earlier.
9. Functional and Physical Configuration Audits are performedon all items of hardware and software. FCA is condycted onthe software at the completion of software formal testing.Based on the natureof the software, PCA may be conducted atthe completion of software formal testing or after systemintegration and testing.
h. Functional and Physical Configuration Audits may beperformed at the system level to authenticate the hardwareproduct “specification(s) and the software productspecification(s) to establish the system Product Baseline.This baseline acts as an instrument for use in diagnosingtroubles, adapting the computer resources to environmentaland operational requirements of specific site locations, andproposing changes or enhancements.
i. Planning for transition of the computer resources to theuser and the Software Support Agency (SSA) begins early in
67
DOD-STD-2167APPENDIX B
j.
this phase. Necessary agreements should be preparec?,coordinated, and approved prior to the end of this phase.The SSA and the user should be involved in this planning.
Provisions are made for follow-on support of the equipmentand software configuration items anddocumentation.
associatedFailure to properly consider these
provisions may result in support complications, obsoletedocumentation, and costly “modernization” proqrams. This isparticularly true where the system is being developed in aphased manner, providing reduced capabilities for earlysystem integration, operation, and evaluation.
20.4.4 Production and Deployment. The Production and DeploymentPhase IS the combination of tWo overlapping periods. Theproduction period is from production approval until the lastsystem item is delivered and accepted. The objective is toefficiently produce and deliver effective and supported systems tothe user(s). The deployment period commences with delivery of thefirstitems
a.
b.
c.
operational system item and terminates when the last systemare removed from the operational inventory.
At system transition, the role of the contracting agencynormally terminates except for identified residual tasks andphase-out responsibilities. The supporting and usingagencies start providing the resources necessary to supportthe software throughout the Deployment phase.
Follow-on test and evaluation is performed on operationalsystem items as they are deployed, to assess theifoperational effectiveness and suitability in a deployedconfiguration and environment.
After a system is in operational use, there are a variety ofchanges that may take place on the hardware items, softwareitems, or both hardware and software items. Changes tosoftware items may be necessary to remove latent errors,enhance operations, further system evolution, adapt tochanges in mission requirements, or incorporate knowledgegained from operational use. Based upon complexity andother factors such as system interfaces, constraints, andpriorities, control of the changes may vary from on-sitemanagement to complex checks and balances with mandatorysecurity keys and access codes. The authority to change thesoftware must be carefully and specifically delineated,particularly when security, safety, or special nuclearrestrictions are involved. The same six phases of thesoftware development cycle are utilized for each changeduring the Production and Deployment phase (see Figure 4).
20.4.5 Software Development Cycle Application and Documentation.The software development cycle may span more t= one system llfe
68
I
DOD-STD-2167APPENDIX B
cycle phase, or may occur in any one phase. For example, missionsimulation software may undergo one iteration of the softwaredevelopment cycle during the Concept Exploration, while missionapplication software may undergo.many iterations of the softwaredevelopment cycle during the Demonstration and Validation, FullScale Development, and Production and Deployment phases (seeFigure 1).
20.4.5.1 The phases in the software development cycle may involveiterations back to previous phases. For example, design mayreveal problems which lead to the revision of requirements andreinstitution of certain analyses; checkout may reveal errors indesign, which in turn may lead to redesign or requirementsrevision; etc.
20.4.5.2 Prior to initiating software development during the FullScale Development and the Production anddocumented
Deployment phases,plans for software development (e.g. SDP) ;
authenticated system, segment, or prime item specifications; andthe OCD typically exist. In earlier life cycle phases, such plansmay not yet exist. The software development plans includedescriptions of all organizations and procedures to be used in thedevelopment effort. The system, segment, or prime itemspecification identifies the requirements of the systeml segment,or prime item. In addition, these specifications identify theHWCIS and CSCIS making up the system, segment, or prime item. TheOCD identifies and describes the mission of the system, the systemoperational and support en.vironments, and the functions andcharacteristics of the computer system within the overall system.The six phases of the software development cycle are discussedbelow:
a. Software Requirements Analysis. The purpose of SoftwareRequirements Analysis is to completely define and analyzethe requirements for the software. These requirementsinclude the functions the software is required.to accomplishas part 01 the system, segment, or prime item.Additionally, the functional interfaces and the necessarydesign constraints are defined. During Full ScaleDevelopment, and Production and Deployment, this phasetypically begins with the release of the SSS, Prime ItemSpecification(s) , Critical Item Specification(s), orPreliminary SRS(S) and IRS(S), and terminates with thesuccessful accomplishment of the SSR. During this phase,analyses and trade-off studies are performed, andrequirements are made definitive. The results of this phaseare documented and approved requirements for the software.At the initiation of Software Requirements Analysis, plansfor developing the software are prepared or reviewed (asapplicable) .
69
DOD-STD-2167APPENDIX B
b. Preliminary Design. The purpose of Preliminary Design is todevelop a design approach which includes mathematicalmodels, functional flows, and data flows. During this phasevarious design approaches are considered, analysis andtrade-off studies are performed, and design approachesselected. Preliminary Design allocates softwarerequirements to TLCSCS, describes the processing that takesplace within each TLCSC, and establishes the interfacerelationship between TLCSCS. Design of critical lower-levelelements of each CSCI may also be performed. The result ofthis phase is a documented and approved top-level design ofthe software. The top-level design is reviewed against therequirements prior to initiating the detailed design phase.
c. Detailed Designz The purpose of Detailed Design is torefine the design approach so that each TLCSC is decomposedinto a complete structure of LLCSCS and Units. The detaileddesign approach is provided in detailed design documents andreviewed against the requirements and top-level design priorto initiating the coding phase.
d. Codi:q an+ Unit Testinq. The purpose of Coding and UnitTesting IS to code and test each Unit of code described inthe detailed design documentation. Each Unit of code isreviewed for compliance with the corresponding detaileddesign description and applicable coding standards prior toestablishing internal control.of the.Unit and releasing itfor integration.
e. CSC Integration and Testin& The purpose of CSC Integration~ Testing lS=O integrate and test aggregates of codedUnits. Integration tests should be performed based ondocumented integration test plans, test descriptions, andtest procedures. CSC Integration test results, and CSCItest plans, descriptions, and procedures for testing thefully implemented software are reviewed prior to the nextphase of testing.
f. CSCI Testing. The purpose of CSCI testing is to test themy implemented CSCI . Testing during this phaseconcentrates on showing that the software satisfies itsspecified requirements. Test results should be reviewed todetermine whether the software satisfies its specifiedrequirements.
70
DOD-STD-2167APPENDIX C
DESIGN AND CODING STANDARDS
30. General.
30.1 Pur ose.*rstandar s
This appendix specifiesthe contractor. If the
default design and codingcontractor, has not proposed
internal “design and coding standards in either the SSPt4 or SDP(see Appendix-D) and received approval, then the design and codingstandards in this appendix shall be applied to all code written bythe contractor.
30.2 Applicability. This appendix contains design and codingstandards generally applicable to all programming languages.However, it does not provide complete design and coding standardsfor some higher order languages with advanced capabilities (e.g.Ada, PROLOG, etc.). In such cases, the contractor should proposeadditions to this appendix in either the SSPM or SDP (see AppendixD) and obtain contracting agency approval.
30.3 Detailed requirements.
30.3.1 H~er order language (HOL). All code shall be written inthe HOL spec~f~ed in the SSS.
‘30.3.1.1 If one or more compilers are specified in the SSS, thenall code shall be compiled- by the specified compiler(s).Otherwise, all code shall be compiled by the compilers describedin either the SDP or the SSPM (see Appendix D).
30.3.1.2 If the higher order language does not contain the controlconstructs of Section 30.3.2, the contractor shall use theprecompiled specified in the SDP.’ If a precompiled which isacceptable to the contracting agency does not exist, then thesecontrol constructs shall be simulated (i.e. code in the languageused shall follow the logic shown in figures 5 through 9 withoutexplicitly using the names of the constructs in the code). Iflanguage simulation is used, the same form of the simulatedconstructs shall be uniformly applied throughout the code.
30.3.1.3 A waiver from the contracting agency shall be required inorder for the contractor to write code in assembly language or insome HOL other than the HOL specified in the SSS.
30.3.2 Control constructs. Code shall be written using only thefive control constructs illustrated in Fiqures 5 throuqh 9:SEQUENCE, IF-THEN-ELSE, DO+4%ILE, DO-UNTIL, CA=E. These cofitrolconstructs refer to the control logic within a Unit while it isexecuting and do not preclude the calling or passing of ‘processorcontrol to other Units (e.g., subroutines, procedures, functions,exception handlers, interrupt service routines).
71
DOD-STD-2167APPENDIX C
CONTROL FLOWS FROM PROCESS A TO THE NEXT IN SEIIJENCE, PROCESS B
FIGURE 5. Sequence construct.
F%IFTRUE A FALSE
, FLOW OF CONTROL WILL RETURN TO
COMMON POINT AFTER EXECUTING PROCESS
B OR C. A PREDICATES THE CONDITIONAL EXECUTION.
IF OPTION IS
PENDING THE
TO SKIP A PROCESS
CONDITION OF A
“1
FIGURE 6. IF-THEN-ELSE construct.
72
EOD-STD-2167
APPENDIX C
I 1( ENTER EXIT
)
CONDITION A IS EVALUATED. IF FOUND TO BE TRUE, THEN CONTROL IS PASSED TO
PROCESS B AND CONDITION A IS (THEN) EVALUATED AGAIN. IF CONDITION A IS FALSE,
CONTROL IS PASSED OUT OF THE LOOP.
FIGURE7. DO-WHILE construct.
cENTER EXIT1
SIMILAR TO DO WHILE, EXCEPT THAT THE TEST OF CONDITION A IS PERFORMED AFTER’
PROCESS B HAS EXECUTED. IF CONDITION A IS TRUE, CONTROL IS PASSED OUT OF THE LOOP.
FIGURE81 DO-UNTIL construct.
73
DOD-STD-2167
APPENDIX C
I
CONTROL IS PASSED TO PROCESS BASED ON THE VALUE OF L
FIGURE9. CASE construct.
74
DOD-STD-2167APPENDIX C
30.3.3 Modularity. The source code for each Unit shall notexceed, on the “average, 100 executable, non-expandable statementsor, at most, 200 executable, non-expandable statements,Additionally, Units shall exhibit the following characteristics:
a.
b.
c.
6.
e.
f.
9.
Local variables within different Units shall not share thesame storage locations.
Each Unit shall
Modification ofprohibited.
Each Unit shall
All Units shall
perform a single function.
a Unit’s code during Unit execution shall be
be uniquely named.
follow a standard format consisting ofDrolooue. declarative statements. and executable state~ents.–.?or comments, in that order.
Except for error exits, each Unitpoint and a single exit point.
Coding style conventions shall
shall have a single entry
be consistent among aIlUnits.
30.3.4 Symbolic parameters. To the maximum extent practical,svmbolic Parameters shall be.-used. in lieu of sDecific n’umeric—.values, to”represent constants, relative location within a table,and size of data structure.
Naming conventions shall be uniform throughout the~~;~”’a%%%l employ meaningful names which clearly identify theconstant, variable, function performed, and any other objects usedin the CSCI, to a reader of the source code. Language keywordsshall not be used as identifiers.
30.3.6 Mixed mode operations. Mixed mode operations shall beavoided~.g. , arithmetic between real numbers and integernumbers) . However, if it is necessary to use them, they shall beclearly identified and described using prominent comments withinthe source code.
30.3.7 Paragraphing, bloc- and indenting. Paragraphing,blocking by blank 1i=e~ and in=ting shall be used to enhancethe readability of the code.
30.3.8 Complicated expressions. Compound negative Booleanexpressions shall be prohibited. Nesting beyond five levelsshould be avoided.
75
DOD-STD-2167APPENDIX C
30.3.9 Compound expres.sions. The orderexpressions shall be clarlfied throughspacing.
30.3.10 Single statement. Each line ofat most, one executable statement.
of eva uation for compoundthe use of parentheses and
source code shall contain,
30.3.11 Comments. Comments shall be set off from the executablesource code In a uniform manner. Before each Unit’s executablesection, a prologue section shall describe the following details:
a.
b.
c.
d.
e.
f.
9.
h.
i.
The Unit’s purpose and how it works.
Functions, performance requirements, and external interfacesof the CSCI that the Unit helps implement.
Other Units (subroutines, procedures, functions) called andthe calling sequence.
Inputs and outputs, including data files referenced duringUnit entry or execution. For each referenced file, the nameof the file. usaoe (inDut, output, or both) , and briefsummary of ~he p~rpose ~or”refer&ncing
Use of global and local variablesregisters and memory locations.
The identification of special tasksdefined, and the ‘size/structure ofexternal requirements.
The programming department or sectionUnit.
Date of creation of the Unit.
the file.
and, if applicable,
that are internallywhich are based on
responsible for the
Date of latest revision, revision number, problem reportnumber and title associated with revision.
~fiZiiZ2~l%;mgZF?ZgZLsa$i sN71#J~~:~~~]~a uniform manner and shall be self-explanatory.require the operator to perform table look-ups or furtherprocessing of any kind to interpret the message.
I
76
DOD-STD-2167APPENDIX D
GUIDELINES FOR TAILORING THIS STANDARD
I
40. General.
%~~-e%%.e ~~~;or~~p~~d~~e ~~~~~~nt~~~d~~~~ st~~~ard~~~the development and acquisition of Mission-Critical ComputerSysten software. This appendix serves as guidance for the agencyresponsible for the preparation of contract requirements and doesnot form a part of the contract. This appendix provides guidancefor the tailoring of software requirements allocated from aSystem/Segment Specification (SSS). In cases where the softwarerequirements are allocated from a~~;::;ication (PIDS) or
Prime Item DevelopmentCritical Item Development Specification
the guidance provided in the Tailoring Handbook* should beconsidered.
40.2 Purpose. The guidelines contained herein aid inimplementing the Department of Defense Directive 4120.21,Specification and Standards Application, which requires all DODcomponents to apply selectively and to tailor militaryspecifications and standards prior to their contractualimposition. .This appendix provides guidelines for tailoringdevelopment requirements for Mission-Critical Computer Systemsoftware. These guidelines help accommodate variations in:
a. The software development processes used during the systemlife cycle.
b. Software characteristics and intended end use.
c. Acquisition strategies and project management styles forsoftware development.
40.3 Ob”ective.~“
The guidelines in this appendix address thefollowlng tal orlng objectives:
a. Eliminating inapplicable and unnecessary requirements.
b. Eliminating redundancy and inconsistency with other contractspecifications and standards.
c. Promote the use of commercial and reusable software.
40.4 Tailorin A roach.achievfio~pstep-tail%~n~~~e~~’lOrlng ‘b’ect’ves are
. . . .
I
I
* Planned for future release.
77
a. Step 1 - Class:
DOD-STD-2167APPENDIX D
fy the required software by categor es.
b. Step 2 - Select applicable contract data items.
c. Step 3 - Tailoi the activities, products, and reviewsrequired during each software development phase.
d. Step 4 - Tailor the requirements for the selected dataitems.
40.5 Tailoring Considerations.
40.5.1 Relationship to the Statement of Work (SOW) @ theContract Data Requi=me= List (CDRL~ ~pi=ontract=defined by documents that Include the following, or Iequivalent:
a. A statement of work icientifying tasks to be accompl(sow)
b. A schedule of contract line items, articles, servicessome combination to be delivered (schedule)
c. A list of data items, including format, content,delivery requirements (CDRL)
d. A specification of the characteristics for’the contractitems, articles, and services (Specification).
heir
shed
or
and
line
This software development standard is invoked as a work task by acitation in the SOW. Tailoring of this standard for each of thesoftware categories is accomplished by including appropriate sowstatements which enumerate the changes. Selection of deliverablesoftware documentation for each software category is invoked bycitations in the CDRL. These citations cite the appropriate DIDto invoke the format and content of the documentation. Tailoringof the DIDs for each software category is accomplished byincluding appropriate statements in the CDRL enumeratingchanges.
theSuch changes could include incorporating the
requirements of several DIDs into a single document and therebyeliminate the need for separate DIDs (e.g. incorporate the SCMP,SQEP, and SSPM into the SDP).
40.5.2 Offeror participation in tailoring. Cost-effective— .tailorinq reaulres that this ~andard and Its related DIDs be
I
tailored- to- the project requirements andcha~acteristics of
the uniquethe software. The contracting agency is
ultimately responsible for this effort. However, the offerorshould be given an opportunity to recommend changes and toidentify requirements considered appropriate. The contractingagency should request, in the instructions for proposal
78
DCID-STD-2167APPENDIX D
~reoaration, that the offeror recommend the tailoring details in\he” proposal. The tailoring process should be finalized prior tocontract award.
40.6 Tailoring Process
40.6.1 ~~The
.-+. required soft::~utzs;:::z:i::~software deve.oped for Mission-Cr~tical
the software used in that development, can be divided into thefive categories identified below.
40.6.1.1 Category 1. Deliverable software E & developed anddesignated as a =CI. Designating software as a CSCI typfca~Imposes all = tlie=opment, documentation, test, review, andcontrol requirements on the software. Some of the factorsinfluencing the decision to designate software as a CSCI are:
a.
b.
c.
d.
e.
f.
9.
h.
i.
j.
k.
1.
m.
Functional complexity
Size
Criticality
Interface complexity
Database complexity
Integration complexity
Complexity of security requirements
Certification requirements
Probability of change
Intended end-use
Support concept
Development location(s)
Schedule.
40.6.1.2 Category 2. Deliverable software Q ~ developed anddesignated as Q@lz + =.C E w D=19n?tln9 soft;%as part= a= HWCI typically Imposes fewer requirementsCategory 1. Such software may be embedded in firmware devices andmay not be expected to undergo significant change. Within theframework of this standard, the contractor may propose thetailoring details applicable to such software, subject tocontracting agency approval. Some of the factors influencing thedecision to designate software as part of an HWCI are:
79
DOD-STD-2167APPENDIX D
a. Size
b. Complexity
c. Probability of change
d. Intended end-use.
40.6.1.3 Category 3. Non-deliverable software. The controlsimposed on non-delfierable software vary widely: depending on theuse of the software. Within the framework of this standard, thecontractor may propose control provisions for non-deliverablesoftware, subject to contracting agencyfactors to consider in establishing a%~~~~~”pr%~io% ~~~non-deliverable software are:
a. Used in formal testing of deliverable products
b. Used in informal testing
c. Used to support manufacture of a deliverable item
d. Used for scientific simulation
e. Used as an analysis tool in hardware or software design
f. Probability of change
9. Duration of use within the software development cycle
h. Developed software Vs . commercially available software.
40.6.1.4 Category 4. Unmodified commercially available qn@reusable software u=d in a deliverable CSCI or ~ Within the—— .~ramework of
—.this standard, approval to use unmodified
commercially available and reusable software in a deliverable CSCIor HWCI depends on the associated data rights, documentation, andcertification evidence which the contractor proposes to providethe contracting agency. Some of the factors to consider inaccepting the proposed data rights, documentation, andcertification evidence are:
a.
b.
c.
d.
e.
Support plans
Budget constraints
Proprietary information
Duration of project
Product evolution strategy.
80
DOD-STD-2167APPENDIX D
I%&:jk%??%c?:“:lO%:s‘e~~~~%d ‘~ii:ar%’”n=%~~~commerclall yavailable~of_ The’requirements~mposed onmodifications to previously developed software vary widely. Someof the factors to consider in establishing the requirements are:
a. Existing documentation
b. Available support tools
c. Modification v’ . enhancement
d. GFS. VS. commercial software Vs . developed software
e. Duration of project
f. Product evolution strategy.
40.6.1.6 Cate orsoft.are*sp ~tyhiS-fa ~!e~~d~~t~~~~~~~d~ ~f~~~~ ~%category requires a different approach to achieve cost effectivemanagement of its software through tailoring the application ofthis standard and its related DIDs. For this step, it is firstnecessary to identify each type of software associated with thedevelopment program (e.g., operational, diagnostic, and supportsoftware) . Then, identify how each of these types might consistof software from one or more categories (e.g., operationalsoftware includes newly-developed, unmodified reusable,..and somemodified GFS components). Then ! s’imunarizefor each category thedifferent types of software with components within the category.The nature of the software types within any given category willinfluence the tailoring process for that category.
40.6.2 ~ 2 - Select Contract Data Items. The contract dataitems associated with this stan~ fall Into four categories:Management, Engineering, Test, and Operational and Support. Eachof the data items is typically associated with either a.syst”em, an ~individual .CSCI! or group of CSCIS. Some of the data items aretypically required, while others’may be required depending uponproject-unique characteristics (see Table I).
40.6.2.1 Management data items. The following data items are inthe management catego~ —
Software Development Plan (SDP)Software Configuration Management Plan (SCMP)Software Standards and Procedures Manual (SSPM)Software Quality Evaluation Plan (SQEP).
81
DOD-STD-2167
APPENDIX D
TABLE 1. Typical datSitem @wtionmnge.
DIDTITLE
SDPSCMPSSPMSQEP
SssSRS
SPSVDDEcPSCN
STPSTDSTPRSTR
OCDCSOMSLIMCSDMSPM
%D
TYPICALLYREOUIRED
x
xx
xx
xxxx
xxxx
x
x
MAY BE COVERED INANOTHER OATA ITEM
xxx
x
xx
MAY aEvENDOR-SUPPLIED
xxxxx
82
DOD-STD-2167APPENDIX D
The SDP, SCMP, SSPM, and SQEP typically define the contractor’sapproach to developing all the software in the systemsoftware for a group of CSCIS. All the development plansdescribed in a single SDP, or broken out into twodocuments (see Figure 10). Some of the factors to consselecting the appropriate management documentation are:
or themay beor moreder in
a.
b.
c.
d.
e.
f.
9.
h.
Budget constraints
Multiple contractors or subcontractors
Proprietary information
Project size
Organizational complexity
Complexity of development
Complexity of development
process
environment
Applicable software categories.
40.6.2.2 Engineering data items. The following data items are inthe engineering catego~ —
System/Segment Specification (SSS)Software Requirements Specification (SRS)Interface Requirements Specification (IRS)Software Top Level Design Document (STLDD)Software Detailed Design Document (SDDD)Interface Design Document (IDD)Data Base Design Document (DBDD)Software Product Specification (SPS)Version Description Document (VDD)Engineering Change Proposal (ECP)Specification Change Notice (SCN).
The SSS defines the requirements for the entire Svstem, or Seqmentof the system.
The SRS specifies the requirements for an individual CSCI.interfaces for each CSCI may be specified in one or more IRSSFigure 11). Some of the factors to consider in selectingappropriate requirements documentation are:
The(seethe
83
DOD-STD-2167APPENDIX D
SDP—
=
3. RESOURCES ANO ORGANIZATION
4. DEVELOPMENT SCHEDULE AND MILESTONES
5. SOFTWARE DEVELOPMENT PROCEDURES
5.1 SOFiWARE STANDARDS AND PROCEDURES
5.2 SOFIWARE CONFIGURATION MANAGEMENT
5.3 SOFTWARE QUALITY EVALUATION
=—
●
I SSPM II I
NOTES:
● SOFTWARE STANDARDS AND PROCEDURES MAYBE PROVIDEO IN A SEPARATE SSPM
● * SOFIWARE CONFIGURATION MANAGEMENT PROCEDURES MAYBE PROVIDEO INA SEPARATE SCMP OR SYSTEM CONFIGURATION MANAGEMENT PLAN
● ** SOFTWARE QUALITY EVALUATION PROCEDURES MAY BE PROVIDED IN ASEPARATE SOEP
FIGURE1O. Relationship Bmong management documents.
84
DOD-STD-2167APPENDIX D
SRS—
———
3. REQUIREMENTS
3.1 PROGRAMMING REQUIREMENTS
———
3.2 DESIGN REC3UIREMENTS
—— -.—
I[l:s~
3.3 INTERFACE REQUIREMENTS●
#iy~.— I——
p3sJ-~—
——— .—
NOTES
● interface Requirements MAY BE SPECIFIED lNONEOR MORE SEPARATEIRSS.
FIGURE 11. RELATIONSHIP AMONG REQUIREMENTS DOCUMENTS.—— ..
85
DOD-STD-2167APPENDIX D
a. Number of interfacesI
b. Number of development groups
c. Complexity of interfaces
d. Number of contractors or subcontractors
e. Applicable software categories.
The STLDD defines the top-level design and the SDDD defines thedetailed design for an individual CSCI. The detailed design ofthe CSCI’S data base(s) and external interfaces may be defined inthe SDDD or one or more DBDDs and IDDs respectively (see Figure12). Some of the factors to consider in selecting the appropriatedesign documentation are:
a. Interface requirements in separate IRS(s) (separate IDD foreach IRS)
b. Number of data bases
c. Complexity of data base(s)
d. Probability of change to data base(s).
The SPS specifies the “as-built” ‘description of an individualCSCI . The VDD identifies the exact version of an individual CSCI.ECPS and SCNS identify changes to formal baselines.
40.6.2.3 Test data items The following data items are in the—— +test category:
Software Test Plan (STP)Software Test Description (STD)Software Test Procedure (STPR)Software Test Report (STR).
I
The test documents identify test information for an individualCSCI . The STP describes the contractor’s plans for formal andinformal testing. The STD identifies test cases for all formaltests of the CSCI. The STPR describes the step-by-step proceduresfor executing each formal test. STRS record the results of one ormore formal tests.
86
DOD-STD-2167APPENDIX D
S. REoUIREMENTB
——
%1 INTERFACE DESIGN———
3.3 GLOBAL DATA———
3.3 OETAILED DESIGN———
————
NOTE%
● DETAILED DESIGN OF EXTERNAL INTERFACES MAY BE PROVIDED IN ONE ORMORE SEPARATE I DDs
● , DETAI LED DEsl GN oF DATA SASE(S) MAY SE PROVIDED IN ONE OR MORE
IsEPARATE OBDOS
FIGURE 12. Reletionshlp emong design documents.
87
DOD-STD-2167APPENDIX D
40.6.2.4 Operational ~ Support data items. The following dataitems are In the operational and support category:
The
Operational Concept Document (OCD)Computer System Operator’s Manual (CSOM)Software User’s Manual (SUM)Computer System Diagnostic Manual (CSDM)Software Programmer’s Manual (SPM)Firmware Support Manual (FSM)Computer Resources Integrated SupPort Document (CRISD).
operational documents define the information required tooperaie the computer system(s) and associated software. The OCDidentifies and describes the mission of the system and itsoperational and support environments. It also describes thefunctions and characteristics of the computer system within theoverall system. The CSOM defines procedures for operating acomputer system. The SUM defines procedures to execute one ormore CSCIS. The entire SUM , or portions thereof, may bevendor-supplied, if commercially available software is used.
The support documents define the information required tothe computer
supportsystem and associated software. The CSDM defines
procedures to identify and isolate faults in a computer system.The SPM defines the programming aspects of a computer system. TheFSM defines procedures to modify or replace firmware devices of asystem. The CRISD defines the info-rmation required to support allthe contractually deliverable software, or a portion thereof.
The CSDM, FSM, SPM, SUM, and CSOM, or portions thereof, may bevendor-supplied and may not be required from the developmentcontractor.
40.6.2.5 Additional Guidance. Additional guidance on theselection of appropriate contract data items may be found in theTailoring Handbook* related to this standard.
40.6.3 ~ 3 - Tailor the activities, products, and reviews.This standar~
—identlfi=appllcable requirements for actlvltles,
products, reviews, and baselines/Developmental Configurations foreach of the six software development phases identified in 4.1.The products of each phase consist of the contract deliverabledata items as well as internal, non-deliverable items. Tailoringthe requirements of each phase for each software category isaccomplished by deletion of the affected paragraphs in thisstandard. Detailed tailoring guidance for each softwaredevelopment phase may be found in the Tailoring Handbook* relatedto this standard.
* Planned for future release.
88
I
DOD-STD-2167APPENDIX D
40.6.4 ~~ ~ Tailor the requirements of selected ~ items.All of the requlr= =the data items=elected for the projectmay not be appropriate. Tailoring the data items is accomplishedby deletion of the affected paragrapha in each selected data itemfor each software category. Detailed guidance for tailoring eachdata item may be found in the Tailoring Handbook* related to thisstandard.
* Planned for future release.
89
DOD-STD-2167
Custodians:
Navy - ECArmy - AMAir Force - 10,26
Preparing Activity:
Navy -E
(Project MCCR-0005)
Review Activities:
Army - AD,AR,AY,CR,ER,MD,MINavy - EC,SH,AS,OMAir Force - 10,26
I
90
!
INSTRUCTIONS: In ● continuing .ffoti ti make our ~tmd~,zatio. doc.me.ti better. the OoDprovidesthisform forusein..btittinrammwnti .nd .ug#efitionaf.1impro.ementi.AU u*-1Aof militarystandardizationdm.menu we inritedto provide
suggestions.Tbiiform nmY b. detached.fold.d*1.ngih:brie.i.di.~ted,tapedalongthek.=. ●dge (DONOTSTAPLE),tndmdkd. 1. block5,& u .pecificM ~ible aboutPtiic.lerproblemuew .uchu wordingwhichrequiredi?kerpr.tation,-m
toorigid,restrictive,loose,.mbiruou. or wu in.omlmtiv,e,and giv.prom-d wordi.8changesWlch would dle,iake theproblem. Entit in block 6 my mm=h not mlat.d to a SpecificP_ph of the document. Ifblock1 u filledout,m
..knowledgementwillbe mailedto YOU rnthi.30 daysto letYOU know thatyour commenb werereceivedand .retitng
considered.
NOTE: ‘Thiuform mmy not be ted 10 requestcopiesof doc.menb, nor 10requestwaivers,deviation,.or clarificationof
sJHcificatiOnreq.irem.nuon currentcontmcfs (%mmenu a.bmitt.dcm thisform do noteorutit.teor imply..thoriz.tionku waiveany !xxkio.of lhereferenceddocument(s)or to amend co”tt.ct.ti ,equimmrnti.
(Fold do”, thil 11..,
(Fold do”, ,kl,$,..,
DEPARTMENT OF THE NAVY
SP4C.Z AM. ..”.’ WARPARCSYSTEMS.0)4?4...
111111 F\
WAS”, MG,ON. ....2.3ss.5,00UN4TE0 STATES
Of fICIAL Busmfss
●ENALTY FOR ● RbVATE USE $30Q BUSINESS REPLY MAILFIWTCL,iss,~.h4!TNO.!2503 WASHINGTON D C
POmAGEWILLOE PAIDOV THE OEPARTMENTOF THE MAVV
COMMANDERSPACE AND NAVAL WARFARE SYSTEMS COMNAND
ATTN : SPAWAR 8111WASHINGTON , DC 20363-5100
SIANDARDl~TION OOCUMENT IMPROVEMENT PROPOSAL,,.-,..,”..,+.%”– ,?...,Sac)e),_= ,,”.,..----- ......—. —..
,c””ENT NUMBER 2. WC”MENT TITLE
AWEOF SUSMITT,NGO*GANIZATION. . ,Y,tlc)f ORGANIZATlONWti
•1 vENOOn
•1 USE R
;oRE6S(WMI, cdh,81=I-ZJpc~J
•1 ‘“””’’’’”””
•1OTHER(Sfmdti):
30BLEM AREAS
?.rm.are N.!”-, -d WO,*l”S:
,. ma.am”.mdldw.rd.g:
. . R..um/R.t--l. +.r R.co”!”u . . ..Io”
REMARKS
L NAMEOFSUOM,TTE. (Z”,, FI”t, Ml, - 0,,1 Om.1b. WORK TELEPI+OWNU$I-EP
Co&) – 0.11...1
MAILING AODRESS (SU. t, CltY. 9tilc, ZIPC*J – 0.$10 ..1a.C.Am OF SUBMISSION(YYM
I
PnEVl OUS EO, T,ON IS O#SOLETE