military standard - product lifecycle management · military standard configuration ... functional...
TRANSCRIPT
MILSTD-483A (USAf3
\-
4 JUNE 1=
SUPERSEDING
MIL-STD483
31 DECEMBER 1970
MILITARY STANDARD
CONFIGURATION MANAGEMENT ~PRACTICES FOR SYSTEMS, EQUIPMENT,
MUNITIONS, AND COMPUTER PROGRAMS
AMSt3 NO. F3B29 AREA CMAN
DISTRIBUTION STATEMENT A, Approvedforpublicrelease;distributionisunlim~d
MIL-STD-483A
DEPARTMENT OF THE AIR FORCE
Washington, DC 20330
Configuration Management Practices for Systems, Equipment,Munitions, and Computer Software
1. This Military Standard is approved for use by all departmentsand agencies of the Department of Defense.
-
2. Recommended corrections, additions, or deletions should beaddressed to: Air Force Systems Command, HQ AFSC/SDXP, AndrewsAir Force Base, Washington, MD 20334.
ii
MIL-STD-483A
FOREWORD-----
1. This military standard sets forth configurateion managementpractices which are to be tailored to specific programs andimplemented by the contract work statement. The standard alsoestablishes configuration management requirements which are notcovered in DOD-STD-480, MIL-STD-481, MIL-STD-482, and MIL-STD-490.
2. This military standard is arranged in two parts. Part 1 statesthe general requirements for configuration management and theapplication of each appendix of the standard to specific detailrequirements. Part 2 consists of appendixes which supplement oradd configurateion management requirements not contained inDOD-STD-480, MIL-STD-481, MIL-STD-482, and MIL-STD-490.
L-
iii/iv
——— . . . .
—.
MIL-STD-4U3A
CONTENTS
Part 1 - General Requirements
Paragraph
1.1.11.21.31.4
2.2.12.2
3.3.13.1.13.23.33.3.13.3.23.43.4.13.4.2
\- 3.4.33.4.43.4,53.4.63.4.7
3.4.83.4.93.53.63.7
3.83.93.9.13.9.23.9.33.9.43.9.53.103.10.13.11
3.12
SCOPE .........● 0***.**Q.****.*** ● ******** ● ********Scope (Requirements) ● ..0..● ● .● ...● .● ● *● ..● ● .● ● ●
Purpose .......................**. ● ..● ● ..● ● ● ● ..●
Application ...............oD*+*--ooo”oo”o ““”””=Definit ions....................................
REFERENCED MCUMENTS. .............................Specifications and Standards ...................Other Publications. ............................
REQUIREMENTS .● ● ● ● ● ● .● ● ● ● ● ● ● ● *● ● *● .*● ● ● ● ● ● ● .● ● ● ● ● =●
Introduction. ........*O.0.0.0. ● *.**.* ● *.*..** ● *Configuration management plan ..................Baseline management.. ..........................System engineering and interface control .......System engineering .............................Interface control ..... ..........**... ...0.......Configuration
. .identlflcatlon ...................
Functional Configuration Identification (FCI)..Allocated Configuration Ident+flcation (ACI)...Product Configuration Identlflcatlon (PCI).....Precedence ...............O:OOO.:O~COO:”OOO ““=””Addendum to configuration ldentlficatlon .......Inventory iternidentification. .................Computer software configuration. .
identlflcatlon. ..............................Specification form .............................Specification authent ication ...................Specification maintenance ......................Configuration item
. .identlflcatlon. .............
Engineering release requirements andcorrelation of manufactured products .......t.
System allocation docuent .....................Configuration audits ...........................Functional Configuration Audit (FCA) ...........Physical Configuration Audit (PA).............Audits performed on privately developed items..Formal Qualification Review (FAR)..............Relationship of audits to other reviews ........Engineering changes (equipment/munitions) ......Engineering changes (computer software) ........Reporting the accomplishment of
updating/retrofit changes ....................Configuration management records/reports .......
Page
11111
334
55556677788999
910101212
12121212131414141415
1515
v
MIL-STD-483A
CONTENTS - continued
Paragraph
3.13 Advance Change Study Notice (ACSN) .............3.14 Contract Change Proposal/Task Change Proposal
(CCPITCP) ..............+..* ● ..00.0o*ocoo*=*Do=o3.15 Quality Assurance Provisions/Qualification.
Requirements .................................
4. DATA .....................● ..● ....● ........● ......●
4.1 Data requirements. .............................
5. DEFINITIONS ● **.....*...*. .0.00.. ● ...*.............5.1 Terms ..........................................
6. NOTES ...........................o.o...*00=o= ● =-...6.1 Intended use .....................-=...... .=....6.2 Data requirements list and cross reference .....
Part 2 - APPENDIXES
Appendix
10.
20.
30.
40.
50.
70.
80.
Appendix IHardware Configuration Management Plan .........
Appendix IIInterface Control ......0.......................
Appendix IIISystem Specification/System Segment
Specificat ion................................
Appendix IVAddendum to Configuration Item Specification. ..
Appendix VInventory Item Specification ...................
Appendix VIComputer Software Configuration Item
Specification ................................
Appendix VIISpecification Maintenance,
Equipment/Munitions .....................oc..o
Appendix VIIISpecification and Support DocumentationMaintenance, Computer software ................
Page
16
16
17
2121
2323
272727
Page
31
37
45
47
51
53
55
63
vi
MIL-STD-483A
CONTENTS - continued
Appendix
90.
100.
110.
120.
130.
140.
150.
-.
160.
170.
Appendix IXDocument and Item Identification Numberingand Marking ● O...*. ● *..*.* ● . . . . . . . . . . . . . . . ...*. .
Appendix XEngineering Release Records and Correlation ofManufactured Products ..........................
Appendix XISystem Allocation Document .....................
Appendix XIIConfiguration Audits.. .........................
Appendix XIIIEngineering Changes (Equipment/Munitions). .....
Appendix XIVEngineering Changes (Computer Software) ........
Appendix XVReporting the Accomplishment ofUpdating/Retrofit Changes ......................
Appendix XVINon Complex Computer Program SpecificationDELETED .● ● ● ....● .● ● .....● ● ● ..● ● c.....● ● ● ..● *● ..
Appendix XVIICriteria for Selecting ConfigurationItems ...........*.... ...*.... .....0............
Part 3 - FIGURES
Figure
123
456789
10
Specification Cover Page .......................Advance Change Study Notice Form (Sample) ......Contract Change Proposal/Task Change
Proposal (CCP/TCP) Form ...0.... .....*.. .....*Verification Cross Reference Matrix (Sample) ...Matrix of Interface Control Responsibil ities. ..Flow Chart of ICWG Procedures ..................Example of ICWG Control Sheet ..................Cover page - Addendum Specif ication ............Example of Entries onSCN. .....................Configuration Item Development Record - Part 1.
Page
77
81
85
91
93
101
107
111
113
Page
1118
1920414243495659
vii
MIL-STD-483A
Figure
11
1213
14
151617181920
CONTENTS - continued
Page
Configuration Item Development Record - Part 2. 62Computer Software Configuration Index.......... 69Configuration Item Development Record -
Section A (CSCI) ● .● ● ● .*● ● .● ● ● ..........● .● ● ● ●70
Configuration Index: Sample Section 1 -CSCI Requirements Specification .............. 72
Change Status Report, Computer Software ........ ~~Sample A, System Allocation Document ...........Sample B, System Allocation Document ........... 89Sample C, System Allocation Document ........... 90Engineering Change Classification Checklist .... 99(Sample Form) Installation CompletionNotificat ion................................. 109
viii
MIL-STD-483A
MILITARY STANDARDCONFIGURATION MANAGEMENT PRACTICES FOR SYSTEMS,
EQUIPMENT, MUNITIONS, AND COMPUTER SOFTWARE
Part 1 - General Requirements
1. SCOPE
1.1 Scope (Requirements). This standard establishes requirementsfor configuration management in the following areas:
a. Configuration management planb. Configuration identificationc. Configuration controld. Configuration auditse. Interface controlf. Engineering release control9* Configuration management reports/records
1.2 Purpose. The purpose of this standard is to establishuniform configuration management practices that can be tailored toall systems and configuration items including those systems andconfiguration items procured by the Air Force for other agencies.
1.3 App lication. Configuration management requirementsestablished by this standard apply during the applicable systemlife cycle phases of configuration items whether part of a
--system
or an independent configuration item. Contracts invoking thisstandard will specifically identify the appropriate applicableparagraphs and appendixes or portions thereof as defined in thecontract work statement depending upon the scope of the program,other contractual provisions, and the complexity of theconfiguration item being procured. The contractor shall ensurethat all software, hardware, firmware and documentation procuredfrom subcontractors is generated according to the requirements ofthis standard.
1.4 Definitions. For definitions of terms used in this standardand not defined in Sect ion 5 herein, refer to DOD-STD-480,Appendix E.
---1/2
MIL-STD-483A
2. REFERENCED DOCUMENTS.-
2.1 Specifications and Standards. The following documents, ofthe Issue In effect= date of Invitation for bids or request forproposal, form a part of this standard to the extent ~pecifiedherein:
SPECIFICATIONS
Militarv
DOD-D-1000MIL-Q-9858MIL-L-9931
MIL-P-15024
MIL-I-45208MIL-S-83490
STANDARDS
Military
DOD-STD-1OOMIL-STD-129MIL-STD-130DOD-STD-480
MIL-STD-481
MIL-STD-482
MIL-STD-490MIL-STI)-499MIL-STD-1167MIL-STD-1168MIL-STD-1521
Drawing, Engineering and Associated ListQuality Program RequirementsLot Numbering, Dating and Preparing Data Cardsfor Guided Missile Explosive Assemblies,Sub-Assemblies and PartsPlate, Identification - Information andMarking for Identification of Electrical,Electronic and Mechanical EquipmentInspection System RequirementsSpecification, Types and Forms
Engineering Drawing PracticesMarking for Shipment and StorageIdentification Marking of US Military PropertyConfiguration Control - Engineering Changes,Deviations and WaiversConfiguration Control - Engineering Changes,Deviations and Waivers (Short Form)Configuration Status Accounting Data Elementsand Related FeaturesSpecification PracticesEngineering ManagementAmmunition Data CardLot Numbering of AmmunitionTechnical Reviews and Audits for Systems,Equipments, and Computer Software
PUBLICATIONS
Air Force-Navy Aeronautical Bulletin
152 Number, Serial, Aircraft Engine(Instructions for Assignment)
Air Force Procurement Instruction
L
57-303 Assignment of Serial Numbers toAircraft and Missiles
3
MIL-STD-483A
Air Force Logistics Command Exhibit——
MCMS 67-2 Mobile Training Unit (MTU) IdentificationNumbering System
Air Force Manuals——
AFM 66-1 Maintenance Management
Regulations
AFR 57-4 Retrofit Configuration ChangesAFR 67-35 Assignment of Serial Numbers to
Air Force Equipment
(Copies of specifications, standards, drawings, and publicationsrequired by suppliers in connection with specific procurementfunctions should be obtained from the contracting agency or asdirected by the contracting officer. )
2.2 Other Publications. The following documents form a part ofthis standard to the extent specified herein. Unless otherwiseindicated, the issue in effect on-date of invitation for bids orrequest for proposal shall apply.
Defense Standardization Manual
4120.3-M Standardization Policies, Proceduresand Instructions
Cataloging Handbook
H 4-1 Federal Supply Code for Manufacturers(United States and Canada) - Name to Code
-
(Application for copies should be addressed to the Superintendentof Documents, US Government Printing Office, Washington DC 20402.)
MIL-STD-483A
3. REQUIREMENTS--
3.1 Introduction. Configuration management is a disciplineapplying technical and administrative direction and surveillanceto (a) identify and document the functional and physicalcharacteristics of a configuration item, (b) control changes tothose characteristics, and (c) record and report change processingand implemental ion status. It includes configurationidentification, control, status accounting and audits.Configuration management is thus the means through which theintegrity and continuity of the design, engineering and costtrade-off decisions made between technical performance,producibility, operability, and supportability are recorded,communicated, and controlled by program and functional managers.
3.1.1 Configuration management m The contractor shallestablis;l wlthln hls organlzatlon, responsibility for implementingthe requirements of configuration management invoked by thecontracting agency. The responsibilities and procedures shall bedocumented in a configurateion management plan which shall besubject to review or approval by the contracting agency. ForHardware Configuration Items (HWCIS), the plan shall be inaccordance with the criteria set forth in Appendix I. For ComputerSoftware Configuration Iterns (CSCIS) the plan shall beincorporated in one of the following: the Software DevelopmentPlan (SDP), the Software Configuration Management Plan (SCMP), orthe System Configuration Management Plan (see 6.2). Where no newor additional configuration management requirements have beeninvoked and the contractor’s configuration management system hasbeen previously validated by the contracting agency, submittal ofthe configuration management plan may not be required.
3.2 Baseline management. One of the more important aspects ofconfiguration management is the concept of baselinemanagement. Baseline management is formally required at thebeginning of an acquisition program.
a. Baselines may be established at any point in a program whereit is necessary to define a formal departure point forcontrol of future changes in performance and design. Systemprogram management normally employs three baselines for thevalidation and acquisition of systems: the functional,allocated, and product baselines. Equipment and munitionsmanagement may employ all three baselines or employ only thefunctional and product baselines depending upon complexityor peculiar requirements. The baselines are documented byapproved configuration identifications which are the basisfor control of changes in system/configuration itemrequirements. Software management normally employs aDevelopmental Configuration to describe the software designprior to establishing the Product baseline and after theestablishment of the Allocated and Functional baselines.
5
MIL-STD-483A
b. Baselines are the basic requirements from which contractcosts are determined. Once defined, changes in theserequirements are formally approved and documented to provide
--
an equitable way to adjust contract costs. (See DOD-STD-480and MIL-STD-481. ) Essentially, configuration management isoriented toward change management. The use of these separatebaselines provides necessary latitudes for defining changesso that, initially, most changes may be made within thescope of the functional baseline for the totalsystem/segment requirements, and ultimately, changes shallbe defined as they affect individual configuration items.
c. All descriptions of baselines (functional, allocated, andproduct) of a system, or other configuration items, used tostate product performance and design requirements (and to beused as a common reference by industry and the Government)must be contained in specifications. However, descriptionsof the contractor’s internally controlled developmentalconfiguration of a Csc I, used to describe the evolvingconfiguration of the software design during softwaredevelopment are contained in design documents (notspecifications) and software listings. MIL-STD-490establishes criteria for a uniform specification program forall contractor-prepared documents and is also compatiblewith the criteria for those specifications which maysubsequently be prepared and issued under the militaryseries of documents (DOD 4120.3-M) All specificationsincident to configuration management are organized incontent, format, and use to recognize the environmentimposed by configuration management principles. Theyrecognize the specific periods of design evolution reflectedin the baseline concept. Further, they are organized forprogressive definition of technical requirements and changecontrol. They are the means of relating performancerequirements to the design definition expressed in drawings.
3.3 System engineering and interface control. There are tWoclosely related tasks which must be accomplished in the design anddevelopment of configuration items and in the development of thespecification requirements for the configuration items. These twotasks are system engineering and interface control.
3.3.1 System engineering. System engineering for the totalsystem or a functional area (system element or segment) isnormally vested in a single contractor or contractingagency. System engineering, as it relates to configurateionmanagement, is the application of scientific and engineeringefforts to transform an operational need into a description ofsystem performance parameters; a system configuration must beultimately called out in the configuration item specifications. Inthis way, the system engineering agency or contractor generatesrequirements for configurations which will satisfy the operationalneed, constrained technically only by the content of the system
6
MIL-STD-483A
specification. The system engineering agency or contractor is-— responsible for assessing the impact of changes to configuration
item specifications or to the system specification. This includesmodifications to operational systems. (See MIL-STD-499 for systemengineering criteria. )
3.3.2 Interface control. Interface control is the coordinated~ed toactivity assure that the functional and physical
characteristics of systems and equipments are compatible. Theinterface control contractor is a coordinator with responsibilityto assure that configuration item identification conforms to thefunctional interfaces established by system engineering and thatthe configuration items, including computer software as finallydesigned, are physically and logically compatible, will assembletogether, and can be operated and supported as intended. Theinterface control contractor or agency is responsible for controlof space allocation where necessary to assure that equipment canbe installed in a facility or existing system, and is responsiblefor management control of interface control drawings. Theinterface control contractor may be made responsible for thepreparation of all interface control, including installationcontrol drawings. The interface control contractor shall normallyassess the impact of changes which affect interfaces. Appendix IIestablishes the requirements for interface control of the systemwith other systems, and between configuration items within thesystem, including computer software (see 6.2) .
3.4 Configuration identification. Selection of configurationitems shall be in accordance with the guidance contained inAppendix XVII. For every configuration item, configurationidentification shall be established in the form of technicaldocumentation. Initially, functional configuration identification
used to establish performance-oriented requirements for the~~sign and development of the higher level configuration item.These requirements may be translated into allocated configurationidentification for selected configuration items that are part of ahigher level configuration item. A Developmental Configurationidentification contains each CSCI’S design documentation andsoftware listings as the CscI is undergoing development. (Thedesign documentation and listings become the product configurationidentification for software. ) Finally, for developedconfiguration items (Government or private), product configurationidentification shall be used to prescribe “build-to” or form, fit,and function requirements, and acceptance tests appropriate tothese requirements.
3.4.1 Functional Configuration Identification (FCI). FCI isrequired for all systems and all configuration items specified inthe contract which are allocated from a system requirement, exceptprivately developed items. Whenever possible, the initial FCI(i.e., the functional baseline or changed functional baseline of asystem required to be modified) will be established concurrentlywith approval to initiate engineering or operational systems
----
7
MIL-STD-483A
development. The establishment of the functional baseline willoccur no later than System Design Review (SDR). The FCI shall be -documented by a Type A specification prepared in accordance withMIL-STD-490.
3.4.2 Allocated Configuration Identification (ACI). ACI shall beused to govern the development of selected configuration itemsthat are allocated from system requirements or are part of ahigher level configuration item, including those that will becomea part through modification of a higher level configuration item.The allocated baseline will be formally established with the awardof engineering or operational systems development contract(s)whenever possible. For HWCIS, the timing of the establishment ofthe allocated baseline will be as agreed between the contractorand the contracting agency, but not later than Critical DesignReview (CDR). For CSCIS, the allocated baseline shall beestablished upon completion of Software Specification Review(SSR). The ACI shall be documented by Type B specifications,Software and Interface Requirements Specifications, and otherdocuments prepared in accordance with MIL-STD-490.
3.4.3 Product Configuration Identification (PCI). PCI shall beused to prescribe necessary “build-to” or form, fit, and functionrequirements and the acceptance tests for those HWC Irequirements. The kind and level of detail to be contained in thePCI shall be determined in consideration of requirements for theanticipated method of reprocurement and for logistic support ofpotentially reparable components which are part of a configurationitem. The contractor shall establish a Developmental —Configuration for each CSCI to maintain internal configurationmanagement during software development. Computer software designdocumentation and software shall be developed, reviewed, andentered into the contractor’s Developmental Configuration. Afterthe software and documentation for the CSCI are approved at thefunctional and physical configuration audits the documentation ofthe contractor’s Developmental Configuration shall become part ofthe contracting agency’s product baseline. In addition to othercontractual requirements such as DOD-STD-1OO and MIL-STD-490,documentation for the PCI shall be prepared in accordance with thefollowing:
3.4.3.1 Reparable HWCIS. On reparable HWCIS developed atGovernment expense, ~ntified and required by the contractingagency, design disclosure documentation to the level ofnonreparability shall be developed. On those reparable iternstested by automatic or semi-automatic test equipment, themaintenance of the configuration of the item will be at the lowestlevel tested automatically or semiautomatically. The maintenancedocumentation shall consist of product specifications, drawings,and associated lists, including the detail design of allinterfaces.
8
MIL-STD-483A
3.4.3.2 Nonreparable HWCIS. On nonreparable HWCIS developed at\. Government expense, form, fit, and function documentation shall be
used. This documentation describes the physical and functionalcharacteristics of the HWCI as an entity, but does not describecharacteristics of the elements that make up the HWCI. For thosenonreparable HWC IS that are also expendable, the PCI may consistof a detail design specification (as in the case of clothing andsubsistence), or of a detail design specification incorporatingperformance requirements and certain drawings, whereinterchangeability or other functional considerations prevail (asin the case of ammunition).
3.4.3.3 Privately developed configuration items. On privatelydeveloped configuration Items (reparable an~eparable), form,fit, and function documentation (equivalent to function typespecification per MIL-STD-490) shall be used, except when theGovernment intends to repair the configuration item and purchasesother design data for this purpose. On all configuration itemsplanned for test on automatic or semiautomatic test equipment, thecriteria for configuration identification shall be form, fit,function, and testability.
3.4.4 Precedence. Functional, allocated, and productconfiguration Identification shall be mutually consistent andcompatible. Should conflicts arise between such identification,the order of precedence shall be (a) functional, (b) allocated,and (c) product, unless otherwise specified by the contracting
-- agency.
3.4,5 Addendum to configuration identification, When an existingconfiguration i~m can by changed for a new application and it isrequired that the original configuration identification documentbe retained, the change can be described by means of an addendumto the configuration item specification. Appendix IV describes theuse and format for preparation of an addendum to a configurationitem specification (see 6.2).
3.4.6 Inventory item identification. Configuration itemspreviously procured and entered into the Government inventory andwhich are suitable for use as a part of the configuration baselineof the system or configuration item shall be identified in aninventory item specification in accordance with Appendix XII ofMIL-STD-490. Appendix V provides supplementary information to befollowed in the preparation of the(see 6.2).
inventory item specification
3.4.7 Computer Software Configuration Identification. CSCIspecifications, design documents, and listings shall definesoftware requirements and design details for a single CSCI . Thesubparagraphs below identify the specifications and designdocuments of the CSCI.
MIL-STD-483A
3.4.7.1 Re uirements s edifications.~Sh% d
The Software RequirementsSpecification eflne system requirements allocated to -a specific CSCI. The Interface Requirements Specification (IRS)shall describe in detail the requirements for one or more CSCIinterfaces. Interface requirements shall include the interfacebetween a CSCI and other configuration items. The SRS and IRSshall be authenticated at the Software Specification Review andestablish the allocated baseline for the CSCI (see 6.2).
3.4.7.2 Design documents and listin s.Design Document (STLDD~ =1 + ‘he ‘“ftware ‘0’ ‘eve’eflne the top-level design of theCSCI . Upon the successful review of the STLDD at PreliminaryDesign Review, the contractor shall establish the DevelopmentalConfiguration for the CSCI. The contractor shall prepare theSoftware Detailed Design Document (SDDD), the Interface DesignDocument(s) (113D(s)), and Data Base Design Document(s) (DBDD(s)),
to define the detailed design of the CSCI. Upon successful reviewof the SDDD, IDD(s), and DBDD(s), at Critical Design Review thecontractor shall enter these documents into the DevelopmentalConfiguration. The contractor shall then code and test softwareUnits, and enter the source and object code, and associatedlistings of each successfully tested Unit into the DevelopmentalConfiguration (see 6.2).
3.4.7.3 Software product specification. At the completion offormal t~of the CSCI, the contractor shall combine theupdated design documents and software listings contained in theDevelopmental Configuration to comprise a Software Product -Specification (SPS) for the CSCI. The integrity of the SPS isestablished by the Physical Configuration Audi t (PCA) anddependent upon the accuracy with which the SPS describes thedetailed configuration of the qualified (or to be qualified)CSCI ● Upon authentication of the SPS following the PCA the SPSwill establish the product baseline (see 6.2).
3.4.8 Specification form. Specifications prepared for new designconfiguration Iterns which are to be produced for the operationalinventory shall be prepared as Form la or lb in accordance withMIL-S-83490 unless otherwise specified by the contracting agency.
3.4.9 Specification authentication. The cover page of thespecification (or of each part of a configuration itemspecification) for a system/configuration item shall provide forapproval signature by a responsible person of the contractingagency. Authentication by the contracting agency normally will beaccomplished on that issue of the specification which is to be thecontractual requirement for the baseline which the particularspecification defines. Figure 1 is an example of a cover page forspecifications (see 6.2). Changes to the specification subsequentto authentication by the contracting agency and its contractualincorporation shall be accomplished in accordance with formalchange procedures e.g., as set forth in DOD-STD-480, MIL-STD-490and this standard.
10
—
MIL-STD-483
SPECIFICATION NUMBER 12WB
CODE IDENT XXXXX
*PART 10F TWO PARTS
(Date)
*SYSTEM SPECIFICATION
*PRIME ITEM DEVELOPMENT SPECIFICATION
*PRIME ITEM PRODUCT FABRICATION SPECIFICATION
*ADDENDUM SPECIFICATION
FOR
(APPROVED TITLE)
(TYPE DESIGNATOR, CONFIGURATION ITEM NUMBER, ETC.)
\ -
“AS APPLICABLE
AUTHENTICATED BY APPROVED BY
{CONTRACTING AGENCY) (CONTRACTOR)
DATE DATE
FIGURE 1, Specification Covar Paga
.
11
MIL-STD-483A
3*5 Specification maintenance. After initial release of aspecification defining any of the three baselines as applicable to -a specific contract, subsequent changes to each specificationshall be formally approved and shall be documented and made a partof the specification. Appendix VII sets forth procedures formaintenance of equipment/munitions specifications and relateddata. Appendix VIII sets forth procedures which are applicable tomaintenance of specifications and related data for computersoftware.
3.6 Configuration ~ Identification. Identification numberingand marking requirements for configuration items and theassociated configuration identification documentation shall be ascontained in Appendix IX.
3.7 Engineering release requirements and correlation ofmanufactured
- ‘hecontractor sh= malntaln a curre=
engineering re ease record of all specifications and drawings forconfiguration items accepted, or to be accepted by the contractingagency. The engineering release records shall interrelate with thecontractor’s internal. system of controls to assure tfiatallapproved Class I engineering changes have been incorporated inproduction items, as specified. Appendix X establishes the minimumcriteria and capabilities to be provided by the contractor’sengineering release system and his control system for verifyingthat manufactured products correlate with the released engineeringdata.
-3.8 System allocation document. A system allocation documentshall be prepared as defined on the Contract Data RequirementsList (CDRL) to ‘identify the aggregation of configuration iternswhich are the basis for system design and integration. The systemallocation document is normally used for those systems which arein a fixed installation, e.g., a ground electronic system or aballistic missile silo; however, it can be used on other types ofsystems when specified by the contracting agency. The systemallocation document shall be maintained until completion of allsystem testing required to complete the design and developmentprogram. The system allocation document shall be in accordancewith Appendix XI (see 6.2).
3.9 Configuration audits. Configuration audits shall consist ofa Functional Conflg~ Audit (FCA) and PCA.
3.9.1 Functional Configuration Audit. The FunctionalConfiguration Audit is a means of validating that development of aconfiguration item has been completed satisfactorily. FCAS shallbe conducted on configuration items to assure that:
a. Test/analysis data for a configuration item verify that theconfiguration item has achieved the performance specified inits functional or allocated configuration identification.
12
MIL-STD-483A
b. The contractor maintains internal technical documentation.- that describes the physical configuration of each unit ofthe configuration item for which test/analysis data areverified.
3.9.2 Physical Configuration Audit. The Physical ConfigurationAudit is a means of establishing the product configurationidentification used initially for the production and acceptance ofconfiguration items (see 6.2). The PCA will assure that theas-built configuration of a configuration item, selected jointlyby the Government and contractor, matches the same configurationitem’s product configuration identification or that differencesare reconciled. The PCA will also assure that the acceptancetesting requirements prescribed by the documentation are adequatefor acceptance of production units of a configuration item by thequality assurance activities.
a. When the developing contractor is also the contractor forproducing production articles, the following shall apply:
..-
(1)
(2)
(3)
(4)
The first production article or the first articledelivered for operational use of a configuration itemshall be selected for the audit.
Achievement of the key functional characteristics ofthe configuration item shall have been demonstrated inthose cases where production/release is authorizedprior to completion of the FCA.
The contractor shall identify any differences betweenthe physical configuration of the selectedconfiguration item and the development configurationitem used for the FCA, and shall certify or demonstrateto the Government that these differences do not degradethe functional characteristics of the selectedconfiguration item.
If the FCA has not been completed prior toaccomplishment of the PCA , the Government mayconditionally approve hardware production units untilthe FCA is completed, provided that other acceptancerequirements for the hardware units have been met.
b. Where the developing contractor is not preselected to be theproduction contractor, the following shall apply for thedeveloping contractor:
(1) The most complete development hardware unit of the HWCIwill be selected for the PCA.
(2) The FCA must have been accomplished prior to completionof the PCA.
13
MIL-STD-483A
(3) :;: contractor shall identify any d~~fer~;ges betweenphysical configuration selected _
configuration item and other development configurationitem used for the FCA, and shall certify or demonstrateto the Government that these differences do not degradethe functional characteristics of the selectedconfiguration item.
3.9.3 Auditsitems. WhenGovernment asconfigurateionto:
a. Validate
,-developed configuration
.&el_ms are acquired by theconfiguration items for the Defense inventory,audits shall be performed to the extent necessary
that the functional characteristics of thedeveloped configuration item are satisfactory for theintended use, with the audit limited to an examination ofthe test data applicable to the requirements of theGovernment for that configuration item.
b. Establish the Product Configuration Identification (PCI) tobe used for production and acceptance purposes. Normally,the contractor-offered form, fit, function, and testabilitytechnical documentation will be established as thePCI. However, for those configuration iterns where theGovernment negotiates an agreement with the contractor goingbeyond form, fit, and function documentation, the moredetailed documentation will be established as the PCI. -
3.9.4 Formal Qualification Review (FQR). A formal qualificationreview ~means of establlshlna by certification/authent icationthat a new group of configuration”it&ms comprising a system hassatisfactorily qualified to the specification requirements. (TheFQR does not pertain to the Qualified Products List (QpL) coveredin FAR Section I, Part II and DOD 4120.3-M). The procedures,tasks, and responsibilities for accomplishment of the FQR when thecontracting agency requires contractor participation, arecontained in MIL-STD-1521.
3“”’ ~ap$o~%;~~ %nf%%ti~ev~~~~~s ~~~~ev~~practlca leaccomplished “ conjunction with other audits andreviews. MIL-ST&521 establishes procedures, tasks, andresponsibilities for conducting configuration audits.
3.10 Engineerindocumentation &iS73(equipmen’’munit i0ns) ● changes ‘0 ‘hede lne the functional or allocated baselines(system or HWCIS) shall be formally controlled by thecontractor. After the documentation which defines these baselinesis made a contractual requirement, subsequent changes to thatcontractual documentation require formal approval by thecontracting agency. After the product baseline is establishedcontractually, subsequent changes to the hardware and its
14
MIL-STD-483A
associated documentation require formal approval by the---- contracting agency. Appendix XIII provides criteria supplementary
to DOD-STD-480 and MIL-STD-481 on engineering changes (see 6.2).
3.10.1 Enqineerin ~- (computer software). Appendix XIVprovides procedures for implementing changes to computer softwareand its documentation (see 6.2).
3.11 Reporting the accomplishment of updating/retrofit changes.The accompllshm~ of updating/ret=flt changes 1s required to bereported in order to maintain status on all configuration items inthe custody of a contractor, unless otherwise directed by thecontract. Appendix XV delineates the detailed procedures forreporting accomplishment of updating/retrofit changes by thecontractor during test, and installation and checkout phases ofthe program. These procedures are intended for use only bycontractor’s test and field organizations to report TimeCompliance Technical Order (TCTO) and Engineering Change Proposal(ECP) accomplishments to his home plant and other activities asdirected by the contracting agency (see 6.2).
3.12 Configuration management records\reports. Configurationmanagement records/reports shall insure that:
a. There will be a configuration record documenting allapproved changes to all configuration items.
-. b. Configuration status accounting reporting of a configurationitem mission, design, series or type, model, and series willbe implemented at the time the product configurationidentification is approved/accepted. Thesystem/equipment/software program manager shall ensure thatconfiguration status accounting is maintained normally untilthe last unit of the configuration type, model , series isdelivered. The documentation shall be as established by thesystem/equipment/software program manager and as a minimumwill include identification of:
(1)
(2)
(3)
(4)
(5)
-.
Technical documentation comprising the configurationidentification.
Essential configuration item data elements.
Contractual information required to be included in therecords/reports for each configuration item, includingcontractor identification code.
Proposed Class I changes to configuration and thestatus of such changes.
Approved changes to configuration, including thespecific number and kind of configuration items towhich these changes apply, the implementation status of
15
MIL-STD-483A
such changes, and the activity responsible forimplementation. .-
C* The configuration status accounting records contractuallyrequired will utilize the data elements and their relateddata items, codes, use identifiers, and data chainsestablished in MIL-STD-482. Data elements not reflected inMIL-STD-482 may be utilized as pertinent to any specificprogram. However, a complete description of the new dataelement shall be submitted to the preparing activity ofMIL-STD-482 for consideration and possible inclusion in thestandard.
d. The contract will specify the specific data base suppliedconfiguration management reports required for theprogram. Format, content and timing will be as agreedbetween the contractor and the contracting agency.
3.13-f w “ ‘“tics ‘ACSN)” ‘ri”r ‘0 ‘hepreparation ormal routine Englneerlng Change Proposal (ECP)
or Contract Change Proposal (CCP) or Task Change Proposal (TCP),the contractor shall notify the contracting agency. An ACSN may beused to notify the contracting agency of its intent to submit achange proposal (see 6.2). Figure 2 is an example ACSN Form. Anysimilar format with essentially the same information may beused. Emergency, urgent, compatibility and record type ECPS do notrequire an ACSN prior to submittal. Use of ACSN will be subject toagreement between the contractor and the contracting agency. The _contracting agency upon receipt of an ACSN will then authorize thecontractor to take one of the following courses of action:
a. The contracting agency is not interested in the change andno further effort is authorized.
b. The contractor shall evaluate alternate course(s) of actionrecommended by the contracting agency.
c. Contractor shall submit additional information about change,prior to formalization of a decision by the contractingagency.
d. Authorize the contractor to perform engineering effortnecessary to prepare a formal ECP.
NOTE : The use of ACSNS should be documented in the CM Plan whenone is used.
3.14 Contract Change Proposal/Task Change Proposal (CCP/TCP). ACCP or TCP shall be used to propose changes to contractualrequirements other than those contained in specifications andengineering drawings, e.g., SOW tasks, test plan, or othercontractual document such configuration managementplan. CCPs/TCPs will not b~s ap~lied unless procedures for
16
MIL-STD-483A
processing them are established by both the contractor and the---program office. Figure 3 is an example form. Any similar formatwith essentially the same information may be used. CCPs/TCPs willnot be used in lieu of ECPS (see 6.2).
3.15 Qua~ity Assurance Provisions/Qualificat ion Requirements. Averification matrix shall be Included In any of the hardwarespecifications prepared per the appendixes of this standard. Thismatrix provides for the correlation of Section 3 performancerequirements with Section 4 verification requirements. Figure 4 isa sample verification cross-reference matrix. Softwarespecifications shall be prepared in accordance with the applicableData Item Descriptions.
.-
---
17
MIL-S’J’D-483
AcsN NLMSSR
ADVANCE CHANGWSTUDY NOTICE (ACSN)ORtGINATOR
7mE OATS
ITEM AFFECTED (l&nSty wntmcb, syB&nu@&y8tuna. * dron ~, C& or~ ~by-etailgs.l
WED FOR THE CHANGE (EaPMI {1) how - whwt nod ws fu@fM9d; toreulnpk,tw0tn4usB,m~~-
~:(2) -l@m-m-*; ~-m.* *~.~-m~-~ ~-fwhow chnsB uiU Impfum Dyobwn: for ●xmwh. hcmmnd iWoUStY. ndumd w8igM, aamwne cOBt,~ y~~m.)
DESCRIPTION OF CNAN(WYSTUDY (OBUdb@ cfwq?s or study mmawmdd M conutapubtwmorto~onm~fl
OWOdidtY. M_lshub IllDy h ,tihd 90 nomlvry [email protected]@~
** --.)
ar~wb~b
ALTERNATIVES TO SUGGESTED CHANGWSTUOY (Btiofy doBcdb ~t$w eoklbn$ lalhcpmbhnl oswsmnmoom mcOm-
Wwndwd. hckdm 8dv9amg0s, mv8nb#w Wld cd.)
COST ESTIMATES(EnWrough cdwIImoi88bROT6 Emdpmhdbn. Up?dnwd, ~ot88SaNtimDyboS 81SUamIuOotssh@s
OmndO.)
SPo CONTRACT AOMINISTRAmON OFFICE CONTRACTOR
❑awnmc Mul Trru f~ ~) -Tun6 AnD n’lLf (~ Au8w+) UOMATUM MO mu! f~ Aur-wl
AFSC - ANOREWS AFB MO 1~
--
FIGURE 2. Advance Change Study Notice Form (Sample)
18
MIL-STD-483
*Numbw
>-
CONTRACT CHANGE PROPOSA~ASK CHANGE PROPOSALDatcx
m of p-
,TfTLE:
Item(s) affected(Identify contmctual requhwnent(s) affected):
NEED (Explatnbenefit($)of making the change and Impactof not making change):
DESCRIPTION OF PROPOSED CHANGE (Enter a detaf~ description of the pmpoaed teak,kwtuding man-hours andany specialequipment required):
----,
ALTERNATIVES TO PROPOSED CHANGE (Explain reasoneforhgainst each alternative,and Itacoat):
COST ESTIMATE (cOntMCt Cod adjuatmant I SCHEDULE (Enter schedule for compled-required for * taak): Ing wwk and, when ●ppflcabta, ** tor
autldtal of resutts}URGENCY CONSIDERATIONS (When appik-able, deacrlbe any condition beating on theurgency of obtdnlng approval tor change)
(NOTE: Any bfock maybe continued on aapamtasheet(s) se required)
FIGURE 3. Contract Change PropoaaUTaak Change Proposel (CCP/TCP) Form @arnpfe)
--19
MIL”STD-483
VERIFICATION CROSS REFERENCE MATRIX
METHOD LEGltNIk l- bpu8i0n 1- Revkw d hslytksl Dda3-~km 4-T-
N.A. - NOI AFPSMbk
TEST CATEGORY LEGEND. A - ~ led& Ev~hwkm
B.~~
C-F-1~
D - RekbMIy T-& AndydI
~-~c-c~-~F- SysemTe#
SECITON 3.0 VERIFICATIONTEST CA TECORY
SkXTTOh 4.0
REQUIREMENT METt40D(S) VERIFICATION REQUIIWMENT
REFERENCE 12 3 4 NA A B c D E F
3.0 x
3.1
3.1.1
3.1.1.1
3.2
3.2.1
3.2.1.1
3.2.1.1
32.3.2
33
3A
*.
&
FIGURE 4. Verification Cross Reference Metrix (Semple)
20
MIL-STD-483A
4. DATA
4.1 Data requirements. The selected requirements in support ofthis standard WI1l be reflected in the Contract Data RequirementsList (CDRL) (DD Form 1423), attached to the request for proposal,invitation for bids, or the contract, as appropriate.
L
.-21/22
—. —.
MIL-STD-483A
5. DEFINITIONS
5.1 Terms. Terms used in this standard not included in, orappl ied differently than, DOD-STD-480 Appendix E entitledDefinitions, are abridgements of definitions from noted sourcedocuments or from the appendixes of this standard and are asfollows:
a.
b.
c.
d.
e.
f.
9“
Advance *f qor:g:ic:out:~sN~:p O:rior to thepreparation a CCP/TCP, thecontractor notifies via an ACSN the contracting agency ofhis intent to submit a proposal. The ACSN containsinformation establishing the need for a change and enableseffective initial evaluation of a suggested change prior topreparation of a formal proposal. The ACSN states theproblem, provides a solution, any known alternativesolutions and a cost estimate. It may also be prepared bythe contracting agency to request the contractor to preparea proposal based on its content. Emergency, urgent,compatibility and record type ECPS do not require an ACSNprior to submittal. Use of ACSNS are subject to agreementbetween the contractor and the contracting agency. (Seeparagraph 3.13 above and 6.2.)
Allocated Baseline. The approved allocated configurationldentlflcatlon as defined in DOD-STD-480.
Baseline Mana ement.techn~
Baseline management is the applicationof and administrative direction to designate thedocuments which formally identify and establish the initialconfiguration identification at specific times during itslife cycle, i.e., functional, allocated, and productbaselines.
Computer Software. A combination of associated computerinstructions and computer data definitions required toenable the computer hardware to perform computational orcontrol functions.
Computer Softwarelogically + ““)” A ‘unction”’ ‘rdlstlnct part o a Computer Software ConfigurationItem (CSCI). Computer Software Components may be top-level,or lower-level.
Configuration item. Hardware or software, or an aggregationof both, which 1s designated by the contracting agency forconfiguration management.
Configuration Item Development Record. The configurationItem development record provides status information on thedevelopment progress of a configuration item as reflected byconfiguration audits and design reviews.
23
h.
i.
j“
k.
1.
m.
t-l.
o.
MIL-STD-483A
Computer Software ConfigurationItem.
Item. See Configuration
Configuration Item Identification (CII) Number. A CIInumber is a permanent number assigned by the design activityto identify a configuration item. The number is a commonidentification for all units in a configuration item type,model, series, and serves as a permanent address for allactions and documentation applicable to the type, model, andseries. The CII number is seven-digits with alpha-numericcharacters.
Configuration Item Specification Addendum. A configurationItem spec~flcatlon a&i endure 1s accomplished by writing a newspecification (addendum) by direct reference to an existingspecification and recording in the new specificationreference to each paragraph in the existing specification. Aspecification created in this manner is a new and completespecification with a new specification number.
Confiquration Mana ement Plan. The configuration managementplan def lnes +e=tion (including policies andmethods) of configuration management on a particularprogram/project. It may or may not impose contractorrequirements depending on whether it is incorporated on thecontract.
Developmental Configuration. The contractor’s software and _assoc~ated technical documentation that defines the evolvingconfiguration of a CSCI during development. It is under thedevelopment contractor’s configuration control and describesthe software configuration at any stage of the design,coding and testing effort. Any item in the DevelopmentalConfiguration may be stored on electronic media.
Engineering Release Record. The engineering release recordcomprises the offlclal data file which records andinterrelates engineering data, and changes thereto, whichtechnically describe and are to be or have been used tobuild/operate\maintain configuration items.
Firmware. The combination of a hardware device and computerInstructIons or computer data that resides as read–onlysoftware on the hardware device. The software cannot bereadily modified under program control. The definition alsoapplies to read-only digital data that may be used byelectronic devices other than digital computers.
Formal Qualification Review (FQR). A formal review,normally accomplished ~ementally at the contractingfacility, of test reports and test data generated during theformal qualification of a new group of configuration itemscomprising a system to ensure that all tests required by
24
MIL-STD-483A
Section 4 of the development specification(s) have beenaccomplished and that the system performs as required bySect ion 3. Usually held in conjunction with the FCA, it maybe delayed until after the FCA/PCA if total system testingis required (see MIL-STD-1521).
P* Functional baseline. The approved functional configurationidentification as defined in DOD-STD-480.
cl” Hardware Configuration Item (HWCI). See configuration item.
r. Interface Control. Interface control comprises thedelineation of the procedures and documentation, bothadministrative and technical, contractually necessary foridentification of functional and physical characteristicsbetween two or more configuration items which are providedby different contractors/Government agencies, and theresolution of the problems thereto.
s. Interface control w*g=(I:w’)* ‘?r programs ‘hichencompass a system configuration item design cycle, an ICWGnormally is established to control interface activitybetween contractors or agencies, including resolution ofinterface problems and documentation of interfaceagreements.
t. Product baseline. The approved product configurationidentification as defined in DOD-STD-480.
u. System Allocation Document. A system allocation document isa document which identifies the aggregation of configurationitems by serial number and the system configuration at eachlocation.
‘“ -Z;anZ~~~igZ~~T~~ngcZ~~~ZestJ~~~z~~uL~2~~vZ;;systems, equipment and munitions, including relatedContractor Furnished Equipment (CFE), and delivered sparesfor which the change requirement is identified prior to theestablished AFSC/AFLC program management transfer,regardless of the method of generation. This includeschange requirements identified during production, testingand operation. (See AFR 57-4)
w. Contract Chan e Pro osal (CCP). A+ to ‘as
formal priced documentalso referre “~hange Proposal (TCP)” used topropose changes to the scope of work of the contract. It isdifferentiated from an ECP by the fact it does not affectspecification or drawing requirements. It may be used topropose changes to contractual plans, the SOW, CDRL ,etc. (See the Task Change Proposal Data Item Description andparagraph 3.14 above.)
.-25
MIL-STD-483A
‘“ -ris%~~ O;’’’”’’’O”s” A “a’ement “f ‘heelements of information operated upon byhardware in responding to computer instructions. ‘These -
characteristics may include, but are not limited to, type,range, structure, and value.
26
MIL-STD-483A
6. NOTES
6.1 Intendedconfigurationsystems andconfigurateion
use. This standard is used to establish uniformmanagement practices that can be tailored to allconfiguration items including those systems anditems procured by the Air Force for other agencies.
6.2 Data requirements list and cross reference. When thisstandard is used In an acqui ion which-tes a DD Form1423, 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 clause on data requirements(currently DOD FAR Supplement 52.227-7031) are invoked and the DDForm 1423 is not used, the data specified below shall be deliveredby the contractor in accordance with the contract or nurchaseo;der requirements. Deliverable data required by this stahdard iscited in the following paragraphs.
Paragraph No.
3.14, 5.lW
3.14, 5.lW
10.3.2.1, 70.10,130.4.2
3.4.9
3.4.5, APP. IV
3.4.6, APP. V
3.11, APP. XV
3.1.1, APP. I
3.8, APP. XI
80.4.2.3, 80.5,80.5.5, 80.5.5.1,80.5.5.4.1
80.5, 80.5.6
Data Requirements Title
Task Change Proposal
Contract Change Proposal/Task Change Proposal
Configuration ItemDevelopment Specification
Configuration Item ProductFabrication Specification
Addendum Specification
Inventory Item Specification
Installation CompletionNotification
Configuration ManagementPlan
System Allocation Document
Configuration Index(Computer Program)
Change Status Report(Computer Program)
27
Applicable DID No.——
DI-A-300
DI-A-3020
DI-E-3102
DI-E-3103
DI-E-3104
DI-E-3105
DI-E-3107
DI-E-3108
DI-E-3116
DI-E-3122
DI-E-3123
.—- -—- .- #..MIL-STD-463A
Paragraph No.
3.13, 5.1
3.11, 3.13, 3.14,5.1, 10.3.1,20.6.1, 70.2, 70.6,70.6.2, 70.6.5,70.6.6, 70.10.2,APP. VIII, 90.1.1,100.4, APP. XIII,APP . XIV, 150.1,170.6
40.4.1, 40.5,70.1-70.9, 70.10.2,APP. VIII, 90.1.1,130.4.2, 130.6,140.6.3, 140.8.8
3.11, 70.2,80.5.1, 130.2,140.4
3.11, 70.2,80.5.1, 130.2,140.4
3.9.2
3.3.2
3.3.2
3.3.2
20.5.4.3
3.1.1, 10.1,80.4.2, 80.5.2
3.1.1, 10.1,80.4.2, 80.5.2
Data Requirements Title
Advance Change Study Notice
Engineering Change Proposal
Specification Change Notice
Engineering Changes,Deviations, and Waivers(Short Form)
Engineering Changes,Deviationsr and Waivers
Physical ConfigurationAudit Plan
Interface ControlManagement Data
Interface Master GageControl Document
Interface Control DrawingDocumental ion
Interface ManagementReporting
Software Development Plan
Software ConfigurationManagement Plan
Applicable DID No.——-
DI-E-3127
DI-E-3128
DI-E-3134
DI-E-5034
DI-E-5035
DI-E-5603
DI-E-30123
DI-E-30124
DI-E-30125
DI-M-30418
DI-MCCR-80030
DI-MCCR-80009
-
.28
MIL-STD-483A
Paragraph No.
80.4.1.3,80.4.2.3,80.5, 80.5.4,80.5.5.1,80.5.5.4.1,90.1.2
3.4.2, 3.4.7.1,20.4.6, 80.4.1.1,80.4.1.2, 80.5.3,80.5.5.1, 80.5.5.2
3.4.2, 3.4.7.1,20.4.6, 80.4.1.1,80.4.1.2, 80.5.3,80.5.5.1, 80.5.5.2
3.4.7.3, 80.4.1.2,80.4.2.1, 80.5.3,80.5.5.1, 110.3.3
3.4.7.2
3.4.7.2
3.4.7.2
3.4.7.2
Data Requirements Title Applicable DID No.——
Version Description DI-MCCR-80013Document
Software RequirementsSpecification
Interface RequirementsSpecification
DI-MCCR-80025
DI-MCCR-80026
Software Product DI-MCCR-80029Specification (includes)
Software Top Level DI-MCCR-80012Design Document
Software Detailed DI-McCR-80031Design Document
Interface Design DI-MCCR-80027Document
Data Base Design DI-MCCR-80028Document
(Data item descriptions related to this standard, and identifiedsect ion 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 NavalPublications and Forms Center or as directed by the contractingofficer. )
6.3 Chanqes from previous issue. Asterisks or vertical lines arenot used In this revlslon ~ntify changes with respect to theprevious issue due to the extensiveness of the changes.
29/30
10. HARDWARE-—
MIIJ-STD-483AAPPENDIX I
CONFIGURATION MANAGEMENT PLAN
10.1 Purpose. This appendix provides criteria to be followed inthe development of a configuration management plan for theimplementation of configuration management requirements invoked bythe contracting agency. This appendix is applicable toconfiguration management requirements for the system/segment andHWCIS (including HWCIS containing software). For CSCIS, thecriteria in the Software Development Plan and SoftwareConfiguration Management Plan Data Item Descriptions may befollowed in the development of a software configuration managementplan.
10.2 Scope. Depending on the terms and conditions of the requestfor proposal or the contract, the requirements that prescribe whatis to be done to implement configurateion management shall beplanned and documented in a configuration management plan preparedby the contractor, unless otherwise specified by the contractingagency. The plan may be limited to defining the contractor’simplementation of configuration management as it relates to theconfiguration identification, configuration control, andconfiguration status accounting. When required to be furnished tothe contracting agency, the plan is intended primarily as anexchange of information between the contracting agency and thecontractor on the configuration management policy and methods ofthe contractor, as he intends implementation on a given contracteffort , and this increases the probability of clear understanding
L of the intent of both parties. For the most part, the documentshould be written in simple positive statements that implement theprecise configuration management requirements to be met by thecontractor.
10.3 organization and content.
10.3.1 Section 1, Organization. Describe the relationship of thecontractor’ s ~ogram/project management to configurationmanagement.
An organizational chart for the program (or company, or divisionof company) which illustrates the structure for program/projectmanagement should be used. The chart, either through the use ofnarrative description or flow diagrams, should illustrate theauthority/responsibi lity of the key organizational elements in thecompany impacted by contractual requirements for configurationmanagement.
Identify the organizational level of engineering control group(s)as well as their authority and responsibility influencing theprogram. A discussion of the contractor’s policy and proceduredetermining the formal establishment of configuration, and controlof changes to established configuration, as these relate tospecification preparation, drawing preparation, engineering
31
MIL-STD-483AAPPENDIX I
release, ECP preparation, configuration management audits, -configuration indexing and accounting, and quality controlprocedures (only to the extent they assure delivery of approvedconfiguration) shall be included herein, to the level of detailnecessary to determine the integrity of configuration managementpractices.
10.3.2 Section ~ Configuration identification.
10.3.2.1 Specifications. The plan shall identify thespecifications (e.g., Type A, Bl, B2, Cl, C2a, C2b, etc.) that thecontractor shall prepare, existing specifications for inventoryitems, and the use of these specifications to establish andcontrol, as appropriate to this program (contract), the FCIS,ACIS, and PCIS developed within the contractor’s organization. Thealignment of authority and responsibility of the contractor andthe contracting agency with respect to establishment of theconfiguration identifications, and changes to the specificationsestablishing the configuration identifications, including cleardelineation of responsibility for cost and schedule impacts whichmay result shall be included herein. The plan shall identify knownspecifications below prime configuration item level that will beprepared; i.e., critical items. The plan shall also identify anylimitations on contracting agency approval of content and theintended point in the program when the above specifications willbe presented for delivery (or otherwise made available) to thecontracting agency. The applicability of appropriate policy andappendixes of MIL-STD-490 and appendixes of this standard to thisprogram (contract) shall be stated. Any need for deviation of thecontent of those appendixes deemed applicable to this programshall be stated. Any limitation on delivery to, or use by, thecontracting agency of contractor-prepared specifications shall bestated (see 6.2).
10.3.2.2 Drawinqs. This sect ion shall define the drawingpractices for application to this program, and the application ofDOD-D-1OOO, DOD-STD-1OO and standards referenced therein. Also,appendixes of this standard shall be applicable as statedherein. Any need for deviation ,of the content of those standardsand appendixes deemed applicable to this program shall bestated. Any limitations on delivery to, or use by, the contractingagency, of contractor-prepared drawings shall be stated.
10.3.3 Section 3, Configuration control. The contractor shalldefine the pol~ies and procedures used within his organizationfor control to established configuration identifications, and forprocessing changes to established configuration identifications.Configuration control at interfaces between the contracting agencyand the contractor shall be stated. To the extent this subject isclear in Section 1, it need not be redundantly includedherein. This section shall be specific as it treats the subject ofcontrol of technical interfaces, both between the contractor and
32
MIL-STD-483AAPPENDIX I
the contracting agency and, when appropriate, the contractor andother contractors involved in the program. Plans for specificapplication of DOD-STD-480, MIL-STD-481 , and appendixes of thisstandard to this program (contract) shall be stated, and anyrequirement for deviation of content of those appendixes selectedfor application shall be stated.
10.3.4 Sect ion ~ Configuration statuscontractor shall state hls plans Y ‘hefor application of con lguratlonindex and status accounting records for this program(contract). He shall state his understanding relative to hisresponsibility to (a) submit data to an integrating agency, whowill collate, prepare, and distribute reports;prepare, and distribute
(b) collate,specific reports himself; (c) accept
inputs from other contractors (agencies), collate such data withhis own inputs, and prepare and distribute reports. He shallspecifically state his intentions for the implementation ofMIL-STD-482. ‘It should be noted there is latitude with respect tostatus accounting reporting, particularly if EDP methods areimplemented, therefore contract cost and schedule implicationswhich limit the flexibility of the contracting agency to requestchanges or additions to initially established formats shall bestated.
10.3.5 Section ~ Subcontractor/vendor control. The contractorshall ~nd~cate his proposed methods for control oversubcontractors and vendors, insofar as it impacts on hisconfiguration management commitments to the contractingagency. The methods used to determine their capability and monitortheir ability to support the requirements of configurationmanagement shall be explained.
10.3.6 Section 6, Program phasing. The contractor shallestablish the majo~milestones for implementation of configurationmanagement . These shall include, but not be limited to:
a.
b.
c.
d.
e.
Establishment of the configuration control board
Phasing for specification program implementation, includingspecification maintenance
Establishment of each of the configuration identifications
Establishment of interface control agreements with associatecontractors
Establishment of configuration index and status accountingprocedures.
10.3.7 Section ~ Management integration of configurationmanagement. The contractor shall describe fie integration ofconfiguration management activities with other project and
33
MIL-STD-483AAPPENDIX I
program/management activities. He shall be specific in defining -the relationship between configuration management at theconfigurateion item level, and its relationship to the workbreakdown structure for control of work authorization and costcontrol in his facility(ies). He shall be specific in defining therelationship between events critical to configuration managementand schedule control of the program project, e.g., sequencing ofdesign reviews, release of engineering, production, test, logisticsupport events, audits, etc.
10.3.8 Section & Configuration audits. The contractor shalldescribe his plans for condu~upport ing the followingconfiguration audits including a description of the audits:
a. Functional configuration audit (FCA)
b. Physical configuration audit (PCA).
10.3.9 Section ~ Software specific configuration manaqement.
10.3.9.1 Developmental Configuration. This paragraph shal 1identify the contractor’s Internal Developmental Configuration(s)to be used in the development of the CSCI(S). For eachDevelopmental Configuration identified, the method of establishingit shall be described and the contents shall be listed. Forexample, the engineering release of the first draft of theSoftware Top Level Design Document (STLDD), prior to submitting itat the Preliminary Design Review, shall establish the internalDevelopmental Configuration.
10.3.9.2paragraph w’=s oftware ‘TOblems = Chanqes” ‘hiss a 1 ldentlfy and describe the format used to documentsoftware problems and changes detected during softwaredevelopment. This report shall include:
a.
b.
c.
d.
e.
System or Project Name - The name of the system ordevelopment project to which this report applies.
Originator - The name, telephone number, and designation ofthe organization submitting the report.
Problem Number - The assigned problem number (once a problemnumber has been assigned in accordance with establishedproject configuration control procedures).
Problem Name - A brief phrase descriptive of the problem anddescriptive of similar problems, if applicable.
Software Element of Document Affected - The specificsoftware element(s) , document(s) paragraph(s), or both towhich the report applies, including appropriateconfiguration identification and version number, if
34
MIL-STD-483AAPPENDIX I
h.
i.
j“k.
1.
m.---
n.
o.
P“
q“
r.
s.
applicable. Include all established baselines orDevelopmental Configurations affected.
Origination Date - The date the report is first submitted.
Need Date or Priority - The date the fix is needed in orderto maintain established schedules or priority in accordancewith established standards.
Description of Problem - A description of the problem andthe conditions, inputs, and equipment configuration underwhich the problem arises. A description of the activitiesleading up to the problem occurrence. Sufficient probleminformation to permit duplication and analysis. Includerelationship to other reported problems and modifications.
Analyst - The name, telephone number, and organization ofthe individual assigned to analyze the problem.
Date Assigned - The date the analyst was assigned.
Date Complete - The date the analysis was completed.
Analysis Time - The time required to analyze the problemreport.
Recommended Solution - After analysis of the problem, therecommended solution and alternative solutions, ifavailable. The nature of the recommended solution by a
short descriptive phrase. When applicable, supportingrationale and test results.
Impacts - The cost, schedule, and interface impacts if thesolution is approved. Also, performance impacts if thesolution is not approved. As applicable, include the impacton the other systems, configuration items, othercontractors, system employment, integrated logisticssupport, system resources trainingl etc.
Problem Status - The problem status designated by theconfiguration control procedures.
Approval of Solution - To be designated by the cognizantconfiguration control authority.
Follow-up Action - Act ions following resolution of theproblem.
Corrector - The name, telephone number, and organization ofthe individual correcting the problem.
Correction Date - The date the problem was corrected.
. . 35
MIL-STD-483AAPPENDIX I
t. Version Number - The version in which the problem will be .-corrected.
u. Correction Time - The time required to correct the problem.
v. Implementation Solution - A brief description of theimplemented solution to the problem.
10.3.9.3 Review Procedures. This paragraph shall describethe purpo~ and the procedures to be employed by anyreview boards (e.g., Software Configuration Control Board )associated with the flow of configuration control. Thisparagraph shall also describe how the procedures used by anyRev iew Boards, in conjunction with the configurationidentification scheme, provide historical traceability.
10.3.9.4 Stora e, Handlin~hall d~~~~~R~~~as~e%o~ rO~~ctfZ~~~Y~This paragrap
control the storage, handling, and release of software anddocumentation (including master copies) during thedevelopment process.
36
MIL-STD-483AAPPENDIX II
20. INTERFACE CONTROL
20.1 Pur ose. This appendix sets forth criteria and guidance forthe eatient of interface control including installationrequirements.
::;&en= This appendix provides guidance for theand control of all physical and functional
interfaces of systems, equipment, munitions, computer software,facilities, and installation requirements.
20.3 Applicability. When specified in the contract, the criteriaand guidance of this appendix is applicable to all contractors tothe Government whose configuration items have an interface withother configuration items which are the responsibility of anothercontractor or Government agency.
20.4 Definitions.
20.4.1 Interface. The term interface is defined as thefunctional and physical characteristics required to exist at acommon boundary between two or more equipments/computer softwareproducts, which are provided by different contractors/Governmentagencies.
20.4.2 Installation control requirements. The term installation.... control requirements denotes the space or location allocated for
each configuration item or equipment, taking into accountinstallation, assembly, test, operation, maintenance, environment,power requirements allocated for each item.
20.4.3 Interface Control Drawindrawing depicts physical + “CD)” ‘?ntJ~;~~~a~~g~~~~~~~functionalrequirements of a configuration item which affect the design oroperation of co-functioning configuration items. These drawingsare used as design control documents, delineating interfaceengineering data coordinated for the purpose of (a) establishingand maintaining compatibility between co-functioning configurationitems, (b) controlling interface designs thereby minimizingchanges to configuration item requirements which would adverselyaffect compatibility with co-functioning subsystems, (c)communicating design decisions and changes to participatingactivities, (d) establishing envelope and access compatibility toverify that all interfacing contractor/Government agency suppliedconfiguration iterns can function without interference throughassembly, test, and all expected operating conditions, and (e)containing master gage dimensional control. For interface controldrawing delineation requirements as well as envelope interfacesand installation envelopes, refer to DOD-STD-1OO.
20.4.4 Programming and timing interfaces. Describes the criticalsystem function interfaces and signal timing constraints inherent
37
MIL-STD-483AAPPENDIX 11
in the system hardware and computer software. -
g~~&~izeYF’-released = ‘-system ‘e’eased ‘CD ‘s anrawlng which has been signed by the contractor who hasprime responsibility, by the participants, and the systemengineering/interface control contractor.
20.4.6 Interface Requirements Specification (IRS). The IRSspecifies in detail the requirements for on~ more CSCIinterfaces in the system, segment, or prime item. Under variousconditions the interface requirements may be included in theassociated Software Requirements Specification (see MIL-STD-490) .The IRS is part of the allocated configuration identification inaccordance with MIL-STD-490.
20.5 General quidance.
20.5.1 The contracting agency will determine the requirements forthe control of interfaces and installation requirements during thevalidation or equivalent phase. The responsibility for developingconfiguration identification covering system interfacerequirements may be contractually delegated in whole or in part tothe system engineering/interface control contractor.
20.5.2 Interfaces detailed during the demonstration andvalidation phase shall be treated as system criteria and shall notbe established as part of the interface control activity. Thisexclusion allows contractors/Government agencies the flexibility
.-
to negotiate interface agreements among themselves within thelimits of the established system criteria.
20.5.3 Programs entering the acquisition phase can be broken intotwo categories as follows:
a. Those programs requiring a total hardware/computer softwaredevelopment cycle (encompassing a system/equipment/computersoftware design phase).
b. Those programs not requiring a total development(where
cycleprogram progresses directly from validation to
production).
20.5.4 When required for those programs encompassing asystem/equipment/computer software design cycle, the use of anInterface Control Working Group (ICWG) will be specified by therequest for proposal as the interface control activity. Theestablishment of an ICWG requires determination of the following:
20.5.4.1 The chairmanship of the ICWG must be designated by theresponsible interface control contractor through coordination withthe contracting agency.
38
MIL-STD-483AAPPENDIX 11
20.5.4.2 The extent to which contractors and Government agencieswill support the interface control activity must be determined(e.g., what agency will be responsible for interface drawingrelease system).
20.5.4.3 The which will be responsible for statusaccounting and r~~~~~?ng must be designated (see 6.2).
20.5.5 For those programs where the use of an ICWG is notapplicable, the contracting agency will contractually specifyother procedures for an interface control activity.
20,5.6 Relationships, responsibilities, and requirements will beas specified in the contractual statement of work.
20.6 Ir.terface Control Workin q- (I~G)”—.
20.6.1 The ICWG serves as the official communicantions linkbetween program participants to resolve interface problems,document interface agreements, and coordinate ECPS. The ICWG shallconsist of at least one member from each of the contractors andGovernment agencies participating in the system development. Aroster of all affected contractors and agencies represented on theICWG will be maintained by the contracting agency and thisinformation provided to all participants.
------ 20.6.2 The establishment of system interface control by the ICWGrequires the identification and definition of interfaces,scheduling, preparation, approval, release, and control of formalinterface drawings.
20.6.3 Interface control drawings shall be used to record thedesign agreements by the contracting agency, and shall, inconjunction with production drawings, diagrams, facilityconstruct ion drawings, and specifications provide a means toevaluate and control all mutually interdependent/interact ingdesign parameters at interfaces between participants’ ; equipment,computer software or facilities.
20.6.4 Interface control drawings may be used to control certaininterfaces where a single participant controls the design of bothconfiguration items when deemed necessary by the contractingagency.
20.6.5 Interface control drawings and revisions thereto will bescheduled for completion at the earliest need of the program tosupport any participating contractor or agency. Thedrawings/revisions will be scheduled and approved by theoriginator to support participating contractor’s PreliminaryDesign Reviews at the earliest need of the program. They shall bescheduled for completion, released by the originating contractor,signed by the interfacing participants, and approved by the ICWG
. .
39
MIL-STD-483AAPPENDIX 11
chairman prior to the time of the applicable Critical DesignRev iew. All drawings/revisions shall be complete, approved, and —system released prior to the time of the Physical ConfigurationAudit.
20.6.6 Individual interface control drawings developed under theprocedures of this appendix shall be maintained by the originatingcontractors to reflect all approved changes. However, theinterface control contractor shall maintain an up-to-datereproducible file of all approved ICDS.
20.6.7 Interface control drawings shall reflect the effects ofany waivers or deviations on the interface depicted, but shall notbe used as the primary means of documenting such waivers and shallnot be used in the fabrication of hardware. Interface controldrawings may be used to establish requirements for interfacemaster gages.
20.6.8 Interface control drawings shall be prepared in accordancewith DOD-STD-1OO. However, if it is deemed necessary, additionaldetails and drawing preparation instructions may be contractuallyspecified by the contracting agency.
20.6.9 Interface control responsibility delegation.
20.6.9.1 Participating contractors/Government agencies shall bedesignated prime and collateral responsibilities for the ICWG. Inthe matrix (figure 5), the interface control contractor has theprime responsibility in each of the actions shown. Theparticipating contractors and contracting agency have collateralresponsibilities where so indicated.
20.6.9.2 Exclusion. The ICWG shall not have the authority toapprove fixes to facilities, computer software, or equipmentrequired because of non-conformant interface conditions discoveredin the field or at equipment/computer softwareacceptance. However, the ICWG shall assist the contractingagencies responsible for approval action upon request, and shallreview and recommend fixes for resolution of interfaceincompatibilities.
20.6.10 ICWG procedures. The Interface Control Working Group(ICWG) pr=ures are shown on the flow chart in Figure 6.
20.6.11 ICWG control sheet. The ICWG actions in connection withinterface control dra-shall be recorded on a form similar toFigure 7. Any other form may be used as long as it provides thenecessary information.
40
MIL-STD-483
APPENDIX II
----
Ntx=
ICWG RFStONSIBILJTIFS OF THE INTSRFACE CONTROL CONTRACTOR,
PARTICIPATING CONTRACTORS, AND THE CONTRACTING AfXNCV
‘f-k inlerke C991tId C0nlIu3wtithcpriw mpOdbfSty h *g *I ●ll of the AOw ~ we mccompbhed. He b
tlwoOkmpadblllty fOrthOw ita19wherc thcterm %lterfacrc0nll0l conhuior” appcm. An ‘X”&I tfw ●bove columns
hdiata Ibt the ~* colmactcm or he ~ SSWICY.or both, hwe cofhnral recpauibihty for Ihe utiom
&own.
FIGURE 5. Matrix of Interface Control Responsibilities
-.
41
MIL-STD-483APPENDIX II
lNTERFACECONTROL DRAWINGS(ICD)
ANY
PARTICIPATING ALL CONTRACTING
CONTRACTOR PARTIES Icwci AGENCV# f ●
REVIEWS
0RIOINATE6 ANoAPPROVES REVIEWS
ICD ESTASLISNESOR on
POWTIONDISAPPROVES RESOLVES
# ● h
1. Any participatingcontractororiginatesJCD.
2. All affectedpartiesreviewlCD●nd submit recommendationsto lCWG Chsirmsn.
3. lCWG Chairman evaluatesproposedICD.
4. ICWG ●pproves/ciisapprovesICD.
a. IflCW G decisionis unsrdmous,the ICD is forwardedto thecontractingagencyfor review.
b. If disagreementexistswithinlC WG, thenlCWG Chsirmsn forwards ICD to contractingagencyfor resolutiontogetherwith his recommendations.
5. When the ICD is incomplete●nd reksse must be madeat that time, the ICD shsll be●ppropriatelyidentifiedsrrdfollowup actionsssignedby 1CW G Chairmsrrfor compktion of ICD.
ENGINEERING CHANGE PROPOSALS (ECPS)
ORIGINATING ALL PARTICIPATING ICWG CONTRACTING
CONTRACTO~ CONTRACTORS cNAtRMAN AGENCV-CCS●
mvttws 1I!CP AND RE~S APPRPVES
INMATED ESTASUSNESACTIONS OR
PosmoN TO CCS DISAPPROVES
. 4 . +
1.
2.
3.
4.
ECP preparedby initiator.
All partiapsting contractorsreview ECP for interfsceimplirntkms on thar system/segmentsndsubmit recommendationsto ICWG.
ICWG conductsevshtstionof ECP snd pmicipsthtg contractorsrecommendst.hms.
ICWG Chsirnmn recommendsto CCB through contractingagency●pprovd/disapproval of ECPfrom an interfacepoint of view.
5. ContractingagencyCCB evaluatessnd approves/dkapproves ECP.
-
-
FIGURE 6. Flow Chart of ICWG proatdures
42
MIL-STD-483APPENDIX II
m mLE
lCWGCON1’ROL SHEET
PAfllwoPAmDATE-nmn.
IcwG
rrEu X0.
—
IcoAw.DATE
FIGURE 7. Example of ICWG Control Sheet
43/44
.
--
------
MIL-STD-483AAPPENDIX III
30. SYSTEM SPECIFICATION/SYSTEM SEGMENT SPECIFICATION
This Appendix has been replaced by DI-cMAN-80008 System/SegmentSpecification.
45/46
MIL-STD-483AAPPENDIX IV
-—40. ADDENDUM TO CONFIGURATION ITEM SPECIFICATION
40.1 Purpose. An addendum to an existing configuration itemspecification is used to describe requirements for a newconfiguration item which is similar to the existing configurationitem.
40.2 sCOPe. The addendum specification creates a newconfiguration item specification; i.e., identification differentfrom the orginal specification. The specification so(basic
createdspecification plus addendum) then becomes controlled and
maintained as a separate and distinct specification, to beup-dated and revised as necessary, independent of changes to thebasic specification from which it was created.
40.3 Applicability. An addendum to an existing specification isused when there is a requirement to retain the existingconfiguration item for some applications and the new (modified)configuration item can be created by minimum redesign of theexisting configuration item. The preparation of an addendum to anexisting specification shall be used when the following conditionsare satisfied:
a.
b.
c.
d.
40.4
There is sufficient reason to establish direct relationshipbetween the new configuration item and an existingconfiguration item as a basis for design and development;e.g., progressing from one type, mode 1, series of aconfiguration item to another; minor changes must beaccomplished to a very limited number of units of aconfiguration item for a specific mission.
The basic specification, to which the addendum is prepared,complies with the requirements of MIL-STD-490 and thisstandard, with respect to format and content.
An addendum shall be created only when the configurationitem identification is different from that of theconfiguration item specified in the basic specification.
When more than 40 percent of the paragraph requirements inthe basic specification must be changed to identify the newconfiguration, a completely new specification shall begenerated.
Preparation instructions. The specification addendum isprepared in a manner which permits ready comparison to the exactrelationship between tWo configuration items. This isaccomplished by writing the new specification (addendum) by directreference to the existing specification on aparagraph-by-paragraph basis, recording in the new specificationspecific reference to each paragraph in the existing specificationand noting each addition, deletion, or change. Where no change is
47
MIL-STD-483AAPPENDIX IV
necessary specify the paragraph number followed by the wording “no -change”. When no sub-paragraphs are changed only the relatedmajor paragraphs need be listed. The paragraph numbering betweenthe two documents shall be identical, with the exception ofparagraphs added to the new document which do not have an exactcounterpart in the existing specification. For convenience ofpreparation, as an option, all paragraphs having “no change” canbe collectively identified in a single paragraph. A specificationcreated in this manner is a new and complete specification inevery sense with a new specification number assigned perMIL-STD-490. the basic specification shall be the first entry insection 2; applicable documents, of the addendum specification.
40.4.1 Addendum specification cover a When a newspecification 1s created by the preparation of an addendum to anexisting specification, an addendum cover page shall be preparedwhich conforms to the format and includes the content required bysample format A as shown on figure 8. All of the data on theaddendum cover page refer to the specification used as the basicdocument against which the addendum is prepared. Each article ofdata to be entered on the cover page shall be transcribed from thetitle page and the specification change notices(s) (SCN) of thebasic specification.
40.5 Change ~ addendum specification. Both the specificationcreated by the addendum and the basic specification to which theaddendum is prepared shall have independent change cycles. A _specification change notice (SCN) to either is not automatically achange to both. Each change to either document shall be reviewed,and if it is desirable to change both the basic specification andthe specification prepared as an addendum, then two separatespecification change notices shall be prepared.
—48
IMIL-STD-483APPENDIX IV
.
.
SAMPLE FORMAT “A”
Specification Number 12345
Code Merit XXXXX
(Date)
ADDENDUM SPECIFICATION
This specification has been prepared as an Addendum to: *Prime Item (Development/Product
Fabrication) Specification
Specification No—
configuration item No.—
FOR(Approved Title)
(Type designator, configuration item number, etc.)
The exact content of specification (insert same number as abo~.) used as the basic document for thts
addendum is the revision referenced above plus the following specification change notices to specification(insert same number as above).
*Note: Lise Development if Type B Addendum and Product Fabrication if Addendum toType C.
FIGURE 8. CoverPege- Addendum Specification
49/50
MIL-STD-483AAPPENDIX V
50. INVENTORY ITEM SPECIFICATION
50.1 Purpose. This appendix provides supplementary informationfor use in preparation of an inventory item specification inaccordance with appendix XII of MILSTD-490, titled Type C4,Inventory Item Specification. (Paragraph numbers cited belowrefer to paragraphs of the inventory item specification format ofMIL-STD-490, appendix XII.)
50.2 Section ~ Requirements. Each paragraph of the inventoryitem specification which Identified an inventory item from theGovernment inventory shall include the following information:
Inventory Item Federal StockSpecification Number Nomenclature Class Code Part Number.—
50.3 Section 10, 20, etc. , Appendixes. The functionspecification refired= here shall be the existing specification(Government- or contractor-prepared) which identifies theinventory item to be used. A new specification shall be preparedonly when the inventory item is to be modified. Each appendixshall follow the following format:
Appendix
1. SCOPE This appendix establishes the requirement for one\- item of equipment from the Government inventory identified as
(insert nomenclature, specification number and date, and otheridentifying data) for the (insert system/configurationnomenclature) .
2. APPLICABLE DOCUMENTS
3. REQUIREMENTS (only when requirements are not contained orare over and above those in the specification for the inventoryitem).
4. QUALITY ASSURANCE
4.1 Qualification (only when tests are required which are overand above those in the inventory item specification).
4.2 Receiving tests
5. PREPARATION FOR DELIVERY
51/52
-
-
-—
MIL-STD-483AAPPENDIX VI
60. COMPUTER SOF’TWARE CONFIGURATION ITEM SPECIFICATION
This Appendix has been replaced by DI-MCCR-80025, SoftwareRequirements Specification, and DI-MCCR-80026, InterfaceRequirements Specification.
53/54
MIL-STD-483AAPPENDIX VII
70. SPECIFICATION MAINTENANCE, EQUIPMENT/MUNITIONS-.
70.1 Purpose. This appendix provides amplified instructions forthe preparation of a proposed specification change notice, anapproved specification change notice, specification change pages,and specification revisions as set forth in MIL-STD-490 as well asindexes (logs) required. For computer software specificat ionmaintenance, see Appendix VIII.
70.2 Sco e.+
The proposed Specification Change Notice (SCN)identl les a proposed change to a contractually applicablespecification. After the proposed SCN is contractually accepted,an approved SCN provides a record of the change and the associatedECP. The proposed specification change notice identifies exactlythe proposed changes to the specification contents. Thespecification revision is a complete revision of the specificationand shall incorporate all previously contractually approvedchanges.
70.3 App liability. Each contractor to the Government shall beresponsible for compliance by his subcontractors, vendors, andsuppliers to the extent specified in paragraph 1.3 of thisstandard.
70.4 Distribution of SCN. Proposed specification change noticesshall not be dlstr~uted to other activities on the specificationdistribution list until the SCN has been approved by the
-- contracting agency. Approved SCNS shall not be furnished to theDefense Technical Information Center. After the approvedspecification is furnished to the Defense Technical InformationCenter, only complete revisions of the specification shall befurnished thereafter.
70.5 Approved SCN. The approved SCN shall be inserted into thespecification =diately in front of Section 1 following thetitle page. The previously approved SCN (DD Form 1696) shall beremoved when the latest approved SCN is inserted in thespecification.
70.6 Preparation of the SCN. By definition, all Class 1engineering changes‘re@re an SCN (see 6.2). Errata of a minornature (such as typographical errors, punctuation, etc.) normallyshall not be corrected, except as an incidental part of the nexttechnically required ECP and accompanying proposed SCN. For thoseECPS that do not affect the specification contents and affect thehardware only, the approved SCN shall indicate only that the SCNhas been added to the ECP for change traceability. The followinginstructions apply in addition to those contained inMIL-STD-490. Figure 9 is an example of entries on the SCN.
55
MIL-STD-483APPENDIX VI
2SPECIFICATION CEIAN ENOTICE{SEE MIL-STD490 FOR INSTRL’CTIONS)
l)\ It Plt},Pr4Ri,D
1. ORIGlh/4TOR NAME AND ADORt.%h 1 3. ( 001 11)}~1 4. SP}.( \o
(SCN Preparing Activity) jXJ ,sIopowm(Des@r Actvty)
,$ f OLMIot.w
D APPRO\W
b. %( \ %0.
{SCN Prep Actvty) 3
? s~ W~4i DW41C%ATION t RLI.AIED U’P W ?. [ (JhlRA( T W)
I
19. ( O\ T$tA( TI 41 i( rltll}
(Type. Model. .Series etC) 4-R! (Note 2) Authority
II. (’ON}I{; l R4TIoN ITEM \oWE\Cl ATI 14t. 12 }}}}(”ll) 11}
(Serkl Numbers of all Configuration Items Affected by this SCN)
THIS NOTTCE INFORMS RECIPIENTS THAT THE SPECIFICATION IDENTIFIED BY THE NUMBER (AND REVISION LETTER)
SHOWN IN BLOCK 4 HAS BEEN CHANCED. THE PAGES CHANGED BY THIS SCN BEtNGTHOSE FURNISHED HEREWITH AND
CARRYING THE SAME DATE AS THIS SCN. THE PACES OF THE PACE NUMBERS ANt’) DATES LtSTED BELOW IN THE
SUMMARY OF CHANCED PAGES. COMBINED WITH NON-IJSTEO PAGES OF THE ORIGINAL ISSUE OF THE REVISION
SHOWN IN BLOCK 4. CONSTITUTETHE CURRENT vERSION OF THIS SPECIFICATION.
u. 14. ● ● I~.w% ho. P4{iEs {’HA% [, ED II%oN *T}: Dt.1.ETIO\SI s % [)*It
PAGES CHANGED AND TRANSMiTTED HEREWiTH
3 6 x
7 x
7a x
12 deleted
SCN ECPNo. No. SUMMARY OF PREVIOUSLY CHANGED PACES
1 2-R I 1,2 2/9/67 x
2 3-R23/12/67
11 4/24/67 x 5/8/67
4 6 Disapproved 4/ 10/675 7-cl 9.15.21 4/12/6~ x
6 8 4,8, 12 4/15/67 x
Not? 1. Bkxks2.4.6.8.9,11,13.●id 16are self-explmttory
Note 2. Typ of contractual action required forimpkrnentation of this SCN, e.g.. ContractChange Order. Suppl-enta~ Ag~t. tic
1s. TE(VUW Al. {“ONCI RRENCE r)41L
(Cosmdssg Agatcy) ( Approvnl Dste)
* .L-,_a.. .._ .... .. . . . __.,...--_. - . .... . .. . .. -4-—-
FIGURE 9. Example of entries ofSCN.56
MIL-STD-483AAPPENDIX VII
-..70.6.1 Block completion. An SCN shall initially be submittedcomplete, except for block 10. If all data cannot be includedwithin the space allocated on the forms, use attachments asnecessary, with appropriate references in the blocks. Thecontractor shall enter the contract change order, or equivalentcontract approving authority number, in block 10 when thisauthority is officially received and prior to inclusion of the SCNin the specificat ion to which it applies. The contractor shallassure that approved SCNS , including changed pages, are incomplete accord with the contractual authority which approved theSCN prior to inclusion in the specification. The contractor shallthen distribute those SCNS in accordance with the specificationdistribution list as described on the DD Form 1423.
70.6.2 Supersession. When a contractor is requested to resubmita proposed SCN , the resubmitted SCN shall retain the same SCNnumber with a new date. An SCN shall only be revised andresubmitted in conjunction with a revision to an ECP. When an SCNis revised and resubmitted, the resubmitted SCN shall show thatthe previous dated SCN has been superseded.
70.6.3 Proposed/app roved SCNS. Proposed/approved SCNS shall beidentified by appropriate marking in block 2. Approved SCNS shallbe marked by completion of blocks 2 and 10, citing the contractualauthority; e.g., contract change order (CCO).
--- 70.6.4 Date prepared (upper right-handThis is date of contractor preparation
corner DD form 1696) .and shalrbe the date on
the specification change pages:
70.6.5 Effectivity (block 12). Block 12 shall be completed toshow ~all t e HWCI s~n=rs affected by the SCN/ECP. Systemspecification SCNS shall state (not applicable).
70.6.6 Summary of chanciechange pages, =ter the% (b’ock W ‘n addition ‘0 ‘here ated ECP number of each SCN and thedate appearing on the change pages of that SCN.
70.6.7 Date (block 15). This date shall be the approval date ofthe SCN._ ~N_ not been approved, leave the date blank.
70.6.8 Technical concurrence (block 16). The chairman of theconfigur~trol board will slgn~ SCN.
70.7 Specification change paqe. The specification change page(s)shall be attached to the SCN and shall constitute an integral partof the SCN. Updated and reissued pages shall be complete reprintsof pages suitable for incorporation by removal of old pages andinsertion of new pages. All portions affected by the change shallbe indicated by a symbol in the right-hand margin. Proposedchange pages shall be printed on colored paper.
57
MIL-STD-483AAPPENDIX VII
70”7”1 Prpsed specification - ~ When a proposedspecification change page is used, the page shall reflect only thechanges of that particular page; i.e., the paragraphs not beingchanged need not be incorporated on the page.
70.8 Specification revisions. A revision is defined as thereissue of a speclflcatlon,~ith all the SCNS incorporated in thebody of the specification. A specification shall not be revisedwithout specific approval of the contracting agency. Thecontracting agency will establish a convenient cutoff point,oriented to a production article number or change in baseline.The specification revision shall incorporate the informationidentified on the latest approved specification change notice.
70.9 Superseded specification. The issue of the specificationsuperseded by the revised specification shall be retained intactwith all specification change pages and SCNS by the custodian toprovide complete continuity of all previous changes.
70.10 Configuration item development record. The configurationitem ~evelopment record provides status information on thedevelopment progress of the HWCI as reflected by specificationaudits and reviews. The configuration item development record foreach HWCI of the system which is of new design shall be assembledand maintained in a log. The log serves as an index of all HWCISof the system which are of new design and records significantprogram actions. The log may be prepared by the integrating or ._systems engineering contractor designated by the contractingagency. Distribution of a contractor-prepared log will be asspecified by the contracting agency on the appropriate CDRL. Theinitial issue of the 1Og shall include a record for allspecifications for HWCIS of new design which are part of thefunctional or allocated baseline. As requirements for additionalnew design HWCIS are established, a record shall be added for eachspecification. Each configuration item development recordcontains information which may be included in configuration statusaccounting records.
70.10.1 Preparation of the configuration item development
%%% Lss*akyTh= pa~of the record shall be prepared in aas shown on fiqure 10. The following
information shall be provided:
a.
b.
c.
Nomenclature - Enter the title of the specification (thetitle of the specification shall be the same as thenomenclature of the HWCI).
Development specification number and date - Enter the dateon which the contracting agency authenticated thespecification.
Configuration item identification.
58-
MIL-STD-483APPENDIX VII
.-
--
CONFIGURATION ITEM DEVELOPMENT RECORD-PART I I
IDevelopment SpecifiutionNumber and Date 12345A 21 Sept67Authentication Date 27 Ott 67
Configuration ItemJdentificmtion
\Configuration ItemPart Number
Prelimirury Design ReviewScheduled Date IO Jan 68
llJan68c
Functional ContigurstionAudit - !kbCdUk!d D8tc
11 July 6812 Juty 68 C
Physical Configuration Audit - Scheduled Date
Critical Design Review
Schedukd Date: llApr6814 Apr68 c
Production SpecificationScheduled Subrnittml Date:
1 Aug 68lAug68c
13 sept 6815 Sept 68 c I
Configuration Item Qualification Scheduled Dste: 10 Ott 6810 Ott 68 c
I
Product SpecMc8tion 170ct68scheduled Authentication Date 170ct68c
Configuration Item Formal Qualification Certification Date: 25 Ott68I
Qudithmtion Test Repori
Contractor I Contract No. I1 J
FIGURE 10. Configuration Item DevelopmentRecord - Part 1
59
d.
e.
f.
9*
h.
i.
]0
k.
1.
m.
n.
o.
P*
MIL-STD-483AAPPENDIX VII
Configuration item part number. Not applicable to CSCIS.
Enter thePreliminaryfollowed by
Enter the
-
date scheduled by the contractor for theDesign Review (PDR) for the HWCI. Enter the dataa “c” to indicate when the PDR was completed.
date scheduled by the contractor for theFunctional Configuration Audit- (FCA) for the HWCI. Enter thedate followed by a “C” to indicate when the FCA has beencompleted.
Enter the date scheduled by the contractor for the CriticalDesign Review (CDR) for the HWCI. Enter the data followed bya “c” to indicate when the CDR was completed.
13nter the date scheduled for submittal of the specificationfor the HWCI. Enter the date followed by a “C” to indicateaction completed.
Enter the date scheduled for the PCA. Enter a “C” after thedate to indicate that the PCA has been completed.
Enter the date scheduled for completion of formalqualification of the HWCI to specific requirements. Enterthe date followed by a “c” to indicate action completed.
Enter the date scheduled for authentication of productspecification. Enter the data followed by a “Cn to indicateaction completed.
Enter the date of acceptance by the contracting agency ofthe certified qualification of the HWCI.
Enter the identity of the test report/documental ion whichsets forth results of the qualification tests of the HWCI.
Enter the name of the contractor responsible for thedesign/manufacture of the HWCI.
Enter the contract number under which the development andqualification of the HWCI is accomplished.
Whenever a date for any event is rescheduled, cross out theoriginal date and enter the rescheduled date.
70.10.2 Preparation of the configurationrecord - Part 2. T=s ~rt of “em -the record-en app lca~be prepared=n a format essentially as shown on fi9ure11. The following information shall be provided:
60 -
MIL-STD-483AAPPENDIX VII
a. Nomenclature - Enter the title of the specification. (The-— title of specification shall be the same as the nomenclature
of the HWCI.)
b. Development specification number and date.
c. Impact of changes on related configuration items. Whenever achange to the HWCI has an impact on related configurationitems, the specification or document title andidentification number of the affected configuration item,the SCN and ECP covering the changes to the affectedconfiguration item, and the contractor’s name who isresponsible for the related configuration item shall belisted.
-
61
MIL-STD-483APPENDIX VII
CONFIGURATION lTEMDEVELOPMENT RECORD-PART 2
Nomenclature of Configuration Item
Configuration Item SpeciliutionNumber md Date:
Configuration item Impct of Ch8nges on
Specification Related Comf~Aon Items
SCN ECPSpeafrcntion/ Document
Title and N umkSCN ECP CONTR
I
Contractor Contmct No.
-
FIGURE 11. Configuration Ittm Demloptnent Rewrd – Part 2
62
MIL-STD-483AAPPENDIX VIII
80. SPECIFICATION AND SUPPORT DOCUMENTATION MAINTENANCE,COMPUTER SOFTWARE
80.1 Purpose. This appendix provides amplified instructions forthe preparation of configuration control forms and documents thatare used for reporting proposed and approved changes as well ascurrent status and version(s) of CSCIS and their associateddocumentation. Also, requirements are included that pertain to thepreparation timing of the various configuration control forms asthey relate to Class I and Class 11 changes. Adherence to therequirements contained in this appendix will ensure that accuraterecords are developed, maintained, and disseminated for all CSCISand for the status of all approved changes and change proposalsthroughout the acquisition phase. Change maintenance proceduresare initiated for each specification, support document, or CSCI atthe time of formal approval or acceptance of the specification ordocument by the contracting agency.
80.2 ~ This appendix “ divided into threesections. Paragraph 80.4 and asso~~ated subparagraphs containgeneral configuration control processing requirements pertainingto Class I and Class II CSCI changes. Subparagraphs of 80.5contain instructions (or references to other sources that containinstructions) for the preparation of required configurationcontrol documents. Finally, paragraph 80.6 contains informationpertinent to specification and document revisions.
80.3 Applacability. This appendix is applicable for use duringthe accyulsltlon and operational phases of CSCI design,developm~nt, test and support. Each- contractor shall -beresponsible for compliance by subcontractors in accordance withparagraph 1.3 of this standard.
80.4 Configuration controlv’
recess. All changes toestablished functional, allocate , or product baselines are ClassI changes. Slight changes to documentation or other changes of aminor nature are Class 11 changes. Requirements for defining acomputer software change as Class I or Class II are presented inAppendix XIV. The following paragraphs define configurationcontrol procedures for Class I and Class 11 changes.
80.4.1 Class I wprocessing shali +on~n~ti;io ~i~~~. 10Jh%~be performechange processing is the simultaneous submission of the formal ECPand SCN with change pages for the appropriate specification(s) bythe contractor to the contracting agency Configuration ControlBoard (CCB). Two step change processing consists of the followingsteps:
a. Submission of a preliminary ECP by the contractor to thecontracting agency CCB without SCN or change pages.
63
MIL-STD-483AAPPENDIX VIII
b. Submission of the formal ECP, completed SCN and change pages eto the appropriate specification(s) to the CCB.
80.4.1.1 Use of one step change Processing. One step changeprocessing— sFIT apply to changes In the System/SegmentSpecification when an approved change to the Software RequirementsSpecification or Interface Requirements Specification impacts theSystem/Segment Specification. One step change processing shallalso be used for changes to the Software RequirementsSpecification or Interface Requirements Specification when thechanges are of a minor nature to accomplish expansions orrefinements, such as the elimination of “TBDs”.
80.4.1.2 +h~ltw~estepprocessing used%% pmjo~~h~~~~ ~~a~~~Software Requirements Specification and Interface RequirementsSpecification, such as the addition or deletion of significantcapabilities, which may entail extensive system engineeringanalysis and result in changes to many pages of thespecification. Two step change processing shall always apply tothe Software Product Specification. Modification of the CSCI isaccomplished between steps one and two of the process byfurnishing computer-generated change pages for the SCN package tothe Software Product Specification.
change processing the co~tractor shall complete the change processfor the current modification by preparing the following items fordistribution:
a. Specification change notice package, consisting of thespecification change notice and specification change pages,for each affected specification.
b. Revised CSCI.
d. Version Description Document related to the revised CSCI.
80.4.2 Class II change processing. Class II changes usually donot — ~proval byrequire the contracting agency CCB prior toimplementation by the contractor. Class II changes shall bedocumented using only page 1 of the standard ECP form, or usingthe Software Problem/Change Report (SPCR) as described andprepared according to the Software Development Plan, SoftwareConfiguration Management Plan, or the System ConfigurationManagement Plan.
&ii-2iIiy %’?e$i %%% + app’icab:’ity”A“ass11‘Cp‘ra So tware Requirements and an InterfaceRequirements Specification, or a Software Product Specification,but never the requirements and product specifications
-64
simultaneously. A Class II---- delivered document.
MIL-STD-483AAPPENDIX VIII
ECP or SPCR may be used to maintain any
80.4.2.2 Reporting Class II changes. Class II changes shall bereported to the contract=g agency by including an SPCR or ClassII ECP as part of the next Class I ECP package for the sameCSCI. Class II changes shall be included in SCNS issued toincorporate Class I changes. The SCN shall indicate theclassification of each change specified therein.
80.4.2.3 Other Class ~ change processing requirements. AllClass 11 chanaes~nstalled In a CSCI shall be ldentlfled in the_————next issue of the Version Description Document by ECP or SPCRnumber, title, and issue date. Class II ECPS and SPCRS shall alsobe reported in the computer software configuration index.
80.5 Configuration control documents and forms. Instructions (orreferences to sources that contfi Instructions) for thepreparation of the configuration control documents are containedin the following subparagraphs:
80.5.1 Engineering Change Proposal (ECP)80.5.2 Software Problem/Change Report (SPCR)80.5.3 Specification Change Notice (SCN)80.5.4 Version Description Document (VDD)80.5.5 Computer Software Configuration Index80.5.6 Change Status Report
-.The forms and documents listed above shall be used to maintainspecifications and support documentation, as applicable to anyspecific proposed or approved change(s). Requirements for applyingthe appropriate documents and forms for a specific change aredelineated in the following subparagraphs.
80.5.1 Engineerin w proposal (~cp)” The contractor shallprovide a preliminary ECP to the contracting agency CCB for allproposed Class I changes to a CSC I. Upon approval andimplementation of the change, using the two-step process, thecontractor shall submit the formal ECP to the contracting agencyCCB. A single ECP can accommodate more than one change includingchanges to two or more CSCI(S) developed by several contractorsand subcontractors. Page I of an ECP form may be used to reportClass 11 changes. Instructions for completing an ECP are providedin Appendix XIV.
80.5.2 Software Problem/Chanqe Report (SPCR). If the contractordoes not use page 1 of an ECP to report Class 11 changes, thecontractor shall use a Software Problem/Change Report. TheSoftware Problem/Change Report format is described in the SoftwareDevelopment Plan, Software Configuration Management Plan, or theSystem Configuration Management Plan.
65
MIL-STD-483AAPPENDIX VIII
80.5.3 Specification Change Notice (SCN). The SCN shall be usedto document all Class I ~lass II changes to Software ~Requirements, Interface Requirements, and Software ProductSpecifications and Class I changes to the System/SegmentSpecification.
80.5.3.1 Distribution of SCN . A proposed SCN shall bedistributed to other actfiit=s-on the specification distributionlist only after the SCN has been approved by the contractingagency.
80.5.3.2 Supersession. When a contractor is requested toresubmit a proposed SCN, the resubmitted SCN shall retain the sameSCN number with a new date. An SCN shall be revised andresubmitted only in conjunction with a revision to an ECP. When anSCN is revised and resubmitted, the resubmitted SCN shall showthat the previous dated SCN has been superseded.
80.5.3.3 Approved SCN. The approved SCN shall be inserted intothe specification =diately in front of Section I following thetitle page.
80.5.3.4 Specification chanqe paqe. The specification changepage(s) shall be attached to the approved SCN and shall constitutean integral part of the SCN. Updated and reissued pages shall becomplete reprints of pages suitable for incorporation by removalof old pages and insertion of new pages. All portions affected bythe change shall be indicated by a symbol in the right or lefthand margin.
.-
80.5.3.5 Proposed specification%%
~ Proposedspecification~e pages may be attac e to a proposed SCN. Aproposed specification change page shall reflect only the changesof that particular page (i.e., the paragraphs not being changedneed not be incorporated on the page.)
80.5.3.6 Preparation of the SCN. A sample SCN is—— — presented inFigure 9. If required by the contracting agency, the SpecificationChange Notice shall be prepared by the contractor in accordancewith the Specification Change Notice Data Item Description (see6.2).
80.5.4 Version Description Document. The Version DescriptionDocument shall be prepared to accompany the release of eachversion of a CSCI and to accompany each release of an interimchange (i.e., changes that occur between CSCI versions). Thisdocument shall record the items delivered and additional pertinentdata relating to status and usage of the CSCI change. Thecontractor shall prepare the Version Description Document inaccordance with the format and content of the Version DescriptionDocument Data Item Description (see 6.2).
66 w
MIL-STD-483AAPPENDIX VIII
provides the c~rrent status of specifications and additionalcontractual deliverable documents which depend for their contenton the CSCI configuration. Document status is maintained by datesof issue, document number and title, ECPS, SCNS, and revisionidentifiers associated with each issue or document changeresulting from accomplished changes. Additionally, the indexcontains a section which provides a summary record of milestonesfor CSCI development, audit, and qualification. One index ismaintained for each CSCI; however, status data pertaining to agroup of interrelated CSCIS may be combined in a single index whenso approved by the contracting agency (see 6.2).
80.5.5.1 Organization and content. The index contains numeroussections that may be% book form. The format is not mandatory,but the elements of information are. The index shall be preparedbased on the guidelines in this appendix and will be generally inthe format as described herein. The body of the index shall haveone historical record section and an additional section for eachtype of document or document series associated with the CSCI. Thefollowing is an example of a typical outline of a computersoftware configuration index for a CSCI:
Section A - Development RecordSection I - Software Requirements/Interface Requirements
-. SpecificationSection II - Software Product SpecificationSection III - Test DocumentationSection IV - ManualsSection V - Version Description Document.
80.5.5.2 Preparation and maintenance. The initial issue of theindex shall be prepar=and dellvered by the contractor after theestablishment of the functional baseline or allocated baseline,whichever occurs later, as required by the contracting agency.Subsequent issues shall be published and distributed thereafter atregular intervals (e.g., monthly) as established by thecontracting agency. The initial issue shall contain only Sect ionA, which identifies significant schedule and completed milestonedata pertaining to the CSCI, and Section I, which lists the basicissue of the Software Requirements Specification and, ifapplicable, Interface Requirements Specification(s). In thoseinstances of complex CSC IS for which a volume structure of thespecification has been approved by the contracting agency, thislisting shall identify each volume as a separate issue. Anadditional section (i.e. of the Sections II through VI asidentified in 80.5.5.1) is added as the basic issue of anysubsequent document if delivered by the contractor for approval oracceptance by the contracting agency. Each succeeding issue of theindex is expanded and revised to reflect milestone data in SectionA and to include the listings specified in 80.5.5.4 below. A
67
section mayor document
MIL”STD-483AAPPENDIX VIII
be deleted from the index once a particular document ‘-series has outlived its usefulness. The first paqe(s)
of the index shall be prepared to conform to figure 12 an~ inaccordance with the following instructions:
a.
b.
c.
d.
e.
f.
9“
h.
i.
j.
Issuing agency - Enter the name of the contractorresponsible for the design/development of the CSCI.
Contract No. - Enter the number of the Government contractunder which the CSCI development is accomplished.
CDRL Item No. - Enter the item number from the ContractData Requirements List (CDRL) for the CSCI.
Document No. - Enter the contractor’s document number forthe configuration index.
Date - Enter the publication date of the given index issue.
CSCI nomenclature - Enter the approvedCSC I.
System - Enter the title and number ofthe CSCI is a part, as assigned by the
nomenclature of the
the system of whichcontracting agency.
CSCI No. - Enter the software inventory number based on theagreed to software inventory numbering system. .-
Issue No. - Enter the issue number of the index. The number“1” is assigned to the first issue; subsequent issues arenumbered consecutively.
Table of contents - Provide a table of contents at the frontof the index, following the data contained in the blocksdescribed above. The table of contents shall identify thepage number on which the initial entry appears for eachsection, for each separate document or volume under asection where applicable, and for each of the two parts of asection.
80.5.5.3 Pre aration of development record,o~ –
Section A. Thissection t e In ex shall be prepared in a format equi=lent tothat illustrated on figure 13, to include the informationspecified below.
a. CSCI No. and nomenclature - Enter the number and approvedname of the CscI as it appears on the front cover of theCSCI specifications (e.g., TM1112A, Message InterfaceComputer Software for SPACE, System 4XXL).
68
MIL-STD-483APPENDIX VIII
Ile8ulng Agency
CONFIGURATION INDEX(Computer Software)
IDocument No.
m
Contrwt No. ICDRL item No. ! Date I
1 ICSCI Nomenclature
System
TABLE OF CONTENTS
Section At
Section 1,
Page
Development Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Rqdrements Specification/lntdace Rqdmmnb S~atio~s). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FIGURE 12. Computer SdtvuareConfiguration Index
69
MIL-STD-483APPENDIX VIII
C’ONFIG(IRATION ITEM DEVELOPMENT RECORD - SECTION A
CSCI No. and Nomenckture
SPECIFICATIONS AND DOCUMENTS REVIEWS AND A[)DITS
.Software Rquiremenk Specification software Specitiation Review
issued:
Authenticated:
Interface Requirements Specification(s)
Issued:
Authenticated:
Software Top Level Design Document” Preliminary Design Review
Issued:
Software Test Phm
Issued:
Approved:
Software Detailed Design Document” Critial Design Review
Issued:
Software Test Description
issued:
Approved:
Interface Design Document*
l!wwed:
Data Base Design Document”
Issued:
Software Test Procedure Test Readinm Review
Issued:
Approved:
Software Test Reporl Functional C’onfigumtinrr Audit
Issued:
Authenticated:
Software Product Speafication Physical Configumtion Audit
Approved:
Contractor I Contract No.
* The authenticated versions of these documents are equivalent to the
authenticated Software Product Specification.
FIGURE 13. Configuration lt8m Development
70
Record – SectionA (CSCI)
MIL-STD-483AAPPENDIX VIII
b. Specifications and documents - For each specification or-. document listed in the left hand column of figure 13, enter
the date of basic issue and, for those items not indicatedby an asterisk, enter the date of authentication orapproval.
c. Reviews and audits - For each milestone event indicated inthe right hand column of figure 13, enter the (starting and)ending date(s) of the (incremental) activity.
80.5.5.4 Organization of content, Sections I through VI. Eachsection of the Index de=ted to a speclflcat~on or docum= seriesshall be further subdivided into two parts, Part 1 contains alisting of the basic issues(s) and all subsequent updatings of thespecification or document, together with identification of ECPSincorporated and associated SCNS. Part 2 lists ECPS which havebeen apptioved and will affect the specification or document butwhich have not yet been reflected in a published specification ordocument revision or set of specification or document changepages,
80.5.5.4.1 Part 1 - Identification. Part 1 of each section shallcontain inf~t~on concerning the basic documentation equivalentto that illustrated in figure 14. The figure illustrates data onlyfor Sect ion I of the index, and for a requirements specificationwhich is issued as a series of separate volumes andappendixes. Data shall be provided in Part 1 of each section asappropriate to single volume documents and the given section, as\follows:
a. Issue. The first entry in this column is always “BASICn for~ocuments or volumes in Section I through V. The firstentry in Section VI is “VDD-1”. Each succeeding entry willbe:
(1) for Sections I and II, an SCN number; or
(2) for Section VI, a VDD number.
Except for VDDS in Section VI: “BASIC” is replaced by asuitable indicator when a complete revision is issued, e.g.,“REV A“. The listing of all previous updates to the basicissue or to any previous revision is deleted from the indexwhen a new revision appears.
71
MIL-STD-483APPENDIX VIII
COMPUTERSOFTW’ARE CONFIGURATION INDEX
SECTION I- SOFTWARE REQUIREMENT!5SPECIFICAT1ON,ESD499~5(9VOLUMES+ 4APPENDIXES)
PART 1. BASIC DOCUMENTATION
ISSUE CHANGE TITLE ISSUED
BASIC VOLUME 1 GENERAL 01-31-76
SCN l-l ECP 1 F/TELL OVER MULTIPOINT LINE 02-%76SPCR 1 CLARIFY FUNCTION DESCRIPTION
SCN 4-1 ECP 7 DELETE B1RDW6 0S-07-76.
.
BASIC VOLUME 2 SURVEILLANCE 01-31-76
SCN 1-2 ECP 1 F/TELL OVER MULTIPOINT LINE 02-30-76
SCN 3-2 ECP 4 ADD TRACKING-ON-STATION ARPS 0&06-76SPCR 3 DELETE REPS INTABLE 2-1SPCR 5 CLARIFY ALR1 SMOOTHING CONSTANTS
SCN 9-2 ECP 11 SYSTEM LIMITS FOR MANUAL REPORTS 12-05-76
APPENDIX JV (continued)
SCN 38-1 V ECP 57 MODIFY SUPPRESS TAPE SRN MESSAGE 03-18-77SPCR SO CLARIFY SIM TAGS
SCN 47-IV ECP 63 CHANGE EVAI.[JATIONREQUEST FORMAT 06-12-78SPCR 60 MISCELLANEOUS CORRECTIONS TO SIM
PART 2. APPROVED CHANGES
ECP NO, TITLE VOL/APP APPROVED
90 EXPAND LEGAL RANGE OF TAPE SRN 1,5,7,1,111 12-19-7794-1 MONITOR EXCHANGE TELL LINE 3,4 02-06-789s COMPENSATE GRID VS.TRUE NORTH 1,2,3,11 06-24-78101 DISPLAY FtJNCTIONCHANGES 3,8,9,I 06-24-78105 DELETE AIJTOMATIC MODE CHANGE 2 07-4)2-78
-
FIGURE 14. ConfigurationIndex: SampleSectionI – CSCI RequirementsSpecification
72
MIL-STD-483AAPPENDIX VIII
b.—.
c.
d.
Change. For the first entry, this column shall be used toldentlfy the number of the given document or volume. Foreach succeeding entry in the “ISSUE” column (i.e., SCNnumber, or VDD number), this column shall contain a listingof the numbers of all ECPS and SPCRS which are incorporatedin the given updating.
Title. The title of the given document or volume is entered-te the “BASIC” entry. The title of the change islisted opposite each Class I or Class 11 ECP numberappearing in the preceding column.
Date of Issue. The date listed is the date of issue——corresponding to each basic issue, SCN , change issueidentifier, or VDD number appearing in the first column.
80.5.5.4.2 Part 2 - Approved changes. This part shall contain alisting of ~ ‘approved ECPS which affect the specification ordocument listed within the given section but which have not yetbeen incorporated into published changes. Upon approval of aformal ECP, the next issue of the index shall contain anuncler
entryPart 2 of each section in which the document, or any volume
of the document, was identified in the ECP as being affected bythe proposed change. When a change package is submitted, thecontracting agency will verify that the impact of the CSCI change
adequately reflected in the revised document(s) and that~~cument changes are accurately reported in the formal revised ECP
. which accompanies the issue of changes. Upon approval of therevised ECP and submitted changes to each affected document orvolume, the listing of the ECP under Part 2 which references thatdocument/volume shall be deleted in the next issue of theindex. The listing for each ECP shall comply with the followinginstructions, as illustrated in figure 14, Part 2:
Column 1.
Column 2.
Column 3.
ECP No. - Enter the number of the ECP.
Title/volume(s)/appendixes affected - enter (a)the title of the proposed change, and (b) if thedocument affected is issued in more than onevolume or issued with separate appendixes,identify each volume or appendix affected by thechange.
Date approved - Enter the approval date of theECP .
73
MIL-STD-483AAPPENDIX VIII
80.5.6 Change status report. The change status report detai 1sthe status of all proposed changes to a CSCI for which thecontractor is responsible, and for which existing documentation islisted in the configuration index. The purpose of the report is toprovide the contracting agency and contractor, on a periodicbasis, with the current status of all officially proposed ECPS tothe CSCI. The change status report supplements the configurationindex. It shall be published concurrently with the index and shallbe used with the index to obtain current status information on theCSCI and related changes thereto (see 6.2).
80.5.6.1 Preparation of the computer softwarebe Ormd ::::U:report. The change IZat= report shallmlnlmum of two sections as described herein.
80.5.6.1.1 Status listing. Section I shall contain a listing bynumber of ~successive ECP prepared against the CSCI, with abrief indicator or comment which characterizes the status of theECP. An example of this listing is illustrated in figure 15. Whenan ECP is impacted by or impacts another ECP, an appropriate noteindicating the impacted or impacting ECP shall be included in thecomments column.
80.5.6.1.2 Status summary. Section 11 of the report shallcontain a detailed summary of the status information for each ECPlisted in Section I which is currently active. The summary shallappear in the first issue of the change status report following _assignment of a number to an ECP in preparation, and shallcontinue to appear in each subsequent issue of the report for atleast one issue following either (a) disapproval of the ECP or (b)completion of implementation of the change. The contractor may usehis own form for the status summary, provided it contains thefollowing minimum items of information:
a. The ECP number and date of preparation.
b. The short title of the proposed ECP.
c. A brief summary of the problem which the proposed change isto resolve.
d. A brief description of the proposed solution.
e. Reference documents - letters, reports of design studies ortests, problem reports, etc.
f. Preparation status - Whether the ECP is in process ofcoordination, is undergoing initial preparation, has beensubmitted, etc.
74
.>. -
MIL-S’J’D-483APPENDIX VIII
CHANGE STATUSREPORT
Section 1. Status LMting
System Date
R3CI NoniencIature Spec No. CSCI No.
ECP No. Title status Comments
2 Disptay Expansion Levets A2-RI Disptay Expansion Levek A SCN approved3 DiItn Link Buffer Output A3-MI Data LhA Buffer Output A New information3-R2 Data Link Buffer Output A SCN approved4 Detection of Button Pop-up A*R1 Detection of Button Popup s6 processSimulated A-Link Data D7 Detection of Input Data A7-cl Detection of Input Data A Editorial change7-RI Detection of Input Data P8 Data Monitor Feedback x Pending interface
requirements
---
Status indicators: P - ECP is being preparedS - ECP is submitted and under consideration
by the CCBA - ltCP has been approved by the CCBD - ECP has been disapproved hy the CCB
X - ECP has been deferred by the CCB1- ECP has been implemented
Section 2. Status Summary
(Contractor Format)
I
FIGURE 15, Change Status Report,Compmer Software
75
MIL-STD-483AAPPENDIX VIII
9“
h.
80.6
Action status - Whether the ECP is awaiting CCB action, has -been returned or withdrawn for revision/corrections, hasbeen approved, requires further study, etc.
Implementation status - The dates of distribution of theapproved change in the CSCI specification and shipment ofthe new CSCI version.
Specification/document revisions. A revision is defined asthe reissue of a sDeclflcatlon or contractual deliverable documentwith all the SCNS &ince the last reissue (or original issue)incorporated in the revised specification or document. Aspecification or contractual deliverable document shall not berevised without approval of the contracting agency. Thespecification or document revision shall not incorporate theinformation from any proposed SCNS that have not been approved.
80.6.1 Superseded specificat ion/document. The supersededspecification or document shall be retained intact with all changepages and SCNS to provide complete continuity of all previouschanges.
76
-.
MIL-STD-483AAPPENDIX IX
90. DOCUMENT AND ITEM IDENTIFICATION
NUMBERING AND MARKING
90.1 Scope. This appendix establishes the numbers to be used foridentifying documents and physical items in order to achieveconfiguration traceability for equipment, components, computersoftware, facility sites, and spares.
90.1.1 Identification numbers to be used for configurationmanagement are as follows:
a.
b.
c.
d.
e.
f.
9*
h,
i.
Specification or standard number
Configuration Item Identification Number for hardware, orthe software inventory number, for the CSCI, based on theagreed to software inventory numbering system.
Serial number (or lot number)
Drawing and part number
Change identification numbers:
(1) Specification Change Notice (SCN)
(2) Notice of Revision (NOR)
(3) Engineering Change Proposal (ECP)
(4) Request for deviation/waiver
Code identification (federal supply code for Mfr.)
Registration number (when specified in lieu of serialnumber )
Program management code (when identified)
Type, series, model designator.
90.1.2 Examples of identification numbers which are not normallyused in configuration management; are as follows:
a. Aerno number (except when authorized by the contractingagency )
b. Production line number
c. Synthetic part number
d. Material codes
77
MIL-STD-483AAPPENDIX IX
e. Federal Stock Number (FSN) (when specified)
f. Version Description Document number.
90.1.3 Applicability. This appendix applies to the configurationidentification and marking of each configuration item and each ofits components requiring configuration control which are acceptedby the contracting agency for systems/configuration item programsor for follow-on spares procurement. Each contractor to thecontracting agency shall be responsible for compliance by hissubcontractors, vendors, and suppliers to the extent hissubcontractors, vendors, and suppliers assign and control standardconfiguration identification numbers. Incorporation of thisappendix in a contract shall not be construed as directing orpermitting the contractor to change an existing identification fora system, Hwc I (or part thereof), material, process, computersoftware or data base, or document specifying any of the foregoingif a past association with any Government agency has caused theexisting identification to be entered into Government technicaldata or supply records.
90.2 General requirements.
90.2.1 Contractor responsibility. The contractor shall assignand control configuration identification numbers in accordancewith this appendix without further approval of the contractingagency.
90.2.2 Numbers assiqned ~ other design activities. Where theconfiguration item Incorporates the design of a subcontractor,vendor, or supplier, the contractor shall use the configurationidentification numbers assigned by these design activities withoutchange except as specifically authorized by DOD-STD-1OO (e.g.,source control drawings).
90.3 Detail requirements.
90.3.1 Specification numbers. Specification identificationnumbers, speclflcatlon change notices, and specification revisionsshall be assigned as prescribed in MIL-STD-490 and MIL-STD-482.
90.3.2 Configuration item identification numbers.
90.3.2.1 The design activity and the manufacturer of theconfiguration item shall be identified by manufacturing codeidentification numbers taken from Handbook H4-1.
90.3.2.2 All discrete parts, assemblies, and units shall beidentified by part numbers in accordance with DOD-STD-1OO.
--
90.3.2.3 A family of like units of a configuration item thatindividually satisfies prescribed functional requirements shall be
-78
MIL-STD-483AAPPENDIX IX
identified by an unchanging base number such as a configurationitem identification number, or a type-model-seriesdesignator. This number:
a. Shall establish a base for serializing individual units of aconfiguration item
b. Shall not change when the unit is modified, even though theinterchangeability of units within the family is affected
c. Shall remain the same even though the configuration item mayhave more than one application or may be reprocured throughdifferent contractors
d. Shall be composed of seven digits ofcharacters. (Note:
alpha-numericOn privately developed configuration
items where the number exceeds seven digits, the last sevendigits of the number will be utilized for
90.3.2.4 Serial or lot numbers. A single unitof like units = yconfiguration item shalluniquely identified by a ‘serial or lotconfiguration item’s unchanging base as follows
a.
b.
c.
d.
e.
f.
9“
Air vehicles - Serial numbers will be assin accordance with AFPI 57-303
EDP application. )
or lot in a familybe permanently andnumber and the
gned by Air Force
Engines for air vehicles - Serial numbers shall beconstructed by the engine manufacturer in accordance withBulletin 152
Mobile training sets (MTS) and resident training equipment(RTE) - Serial numbers shall be constructed by contractor inaccordance with MCMS Exhibit 67-2
Aircrew trainers and mission flight simulation - Serialnumbers shall reflect the program element code assigned bythe prime class AMA and progressive numerical effectivity ofthe configuration item
For solid propellants, the requirements of MIL-L-9931 shallbe followed for the assignment of lot numbers. Formunitions, MIL-STD-1167 and MIL-STD-1168 shall be used forassignment of lot numbers
Ground communication-electronic-meterological (CEM )equipment - Delivered end configuration items and sets shallbe identified with Air Force serial numbers assigned by theresponsible Air Force configuration item manager inaccordance with AFR 67-35
Air Force serial numbers for deliverable components not
79
MIL-STD-483AAPPENDIX IX
included in (a) through (f) above, and havingrecoverability/repairabil ity designator code “D” or “F.
shall be identified, where appropriate, by Air Force serialnumbers assigned by the Air Force configuration item managerin accordance with AFR 67-35
h. Manufacturers serial numbers or lot numbers forconfiguration iterns other than 90.3.2.4 a through g -Serial/lot numbers shall be:
-
(1)
(2)
(3)
(4)
(5)
(6)
Maximum length of 15 digits of alpha-numeric characters
Numeric in last four digits
Assigned to units/lots of configuration iternsidentified by the unchanging serial number base(paragraph 90.3.2.3)
Unique and nonduplicating within the group identifiedby the non-changing serial/lot number base
Assigned in numeric sequence within the configurationitem group
Permanent for the life of the unit.
90.3.3 Change identification numbers. Notice of revisions (NOR),requests for deviations/waivers, and engineering change proposals -identification numbers are prescribed in DOD-STD-480.
90.3.4 Identification of physical configuration items.Configuration Item ~den~ficatlon numbers for configurationmanagement shall be affixed or marked on physical configurationitems in accordance with MIL-STD-130 and other contractuallyinvoked specifications and standards, (e.g., MIL-P-15024).
90.3.5 Reuse g;:iquration item serial numbers. Configurationitem ser~al assigned to the orlglnal configuration itemapply to all follow-on configuration items (within this contractor under separate contract) even though a change affectinginterchangeability may require a part number change of theconfiguration item. Configuration item serial numbers, onceassigned, shall not be reissued on follow-on procurements for thesame configuration item.
90.3.6 Drawinq numbers. Drawing numbers and drawing changeidentification shall be assigned in accordance with DOD-STD-1OO.
80
MIL-STD-483AAPPENDIX X
100. ENGINEERING RELEASE RECORDS AND CORRELATION OFMANUFACTURED PRODUCTS
100.1 Purpose. This appendix establishes therequirements for achieving proper relationshipengineering/tnanufacturing data and manufactured HWCIS.
100.2 s- The c~iteria of this appendix appliescontractor s engineering release system pertaining to:
a. Elements of data required
b. Production release functional capabilities
c. Release of engineering changes
d. Field release functional capabilities.
minimumbetween
to the
100.2.1 After the initial release of data, criteria are set forthfor the control of incorporating Class I engineering changes inHWCIS. The internal control system of the contractor shall becapable of:
a. Reconciling engineering work authorizations to contractrequirements
—. b. Verifying that released engineering and purchase orders arein accordance with contract requirements
c. Assuring that engineering changes are manufactured andincorporated into HWCIS as required by the releasedengineering changes.
100,3 Applicability. The criteria of this appendix applies toall contracts requiring the preparation of engineering drawingsand specifications for HWCIS. The contractor to the contractingagency shall be responsible for compliance by his subcontractors,vendors, suppliers to the extent specified in paragraph 1.3 ofthis standard. No specific provisions for engineering releaserecord requirements for CSCIS are included in this appendix. Anengineering release system complying with the intent of thisappendix shall be implemented by the contractor for CSCIS toassure that the objectives of this appendix are met.
100.4 Engineering release requirements. The contractor shallprepare and malnt~ engineering release records in accordancewith his formats and procedures, and the minimum requirementsherein. The contractor’s formats and procedures may includeinformation in addition to these minimum requirements providingthat the port ion thereof which constitutes engineering releaserecords:
a.
b.
c*
d.
MIL-STD-483AAPPENDIX X
Is limited to an expression of configuration requirements _defined by engineering data.
Does not reflect a hardware or other product configurateionthat varies from the engineering requirements contained inthese data.
Does not reflect manufactureing status. Only one releaserecord (which may be multi-sheet) shall be maintained foreach drawing number. Drawings released by a subcontractor,vendor, supplier, or another contractor shall not bere-released by the contractor.
Shall meet the requirements established in DOD-STD-480 orMIL-STD-481 for waivers and limited effectivity ECPS.
100.4.1 Elements of data required. The contractor’s engineeringrelease records —Sm contain the standard configurationidentification numbers (refer to Appendix IX and other elements ofinformation listed in this subparagraph).
100.4.1.1 HWCI elements:
a. HWCI number
b. HWCI serial numbers
c. Top assembly drawing number
d. KWCI specification identification number.
100.4.1.2 Drawing elements:
a. Drawing number (including specification control and sourcecontrol drawing numbers)
b. Drawing title
c. Code identification number
d. Number of sheets
e. Date of release
f. Change letters
!3” Date of change letter release
h. Ancillary document numbers (ECNS, EOS, variations, etc.).
100.4.1.3 Part number elements:
-82
MIL-STD-483AAPPENDIX X
a. Controlling drawing number-
b. Part numbers released.
100.4.2 Production release functional capabilities. To theextent that the contractor has detail design responsibility, thecontractor’s release function and documentation, includingdrawings and associated lists, shall be capable of determining thefollowing released engineering requirements:
a.
b.
c.
d.
e.
f.
9“
h.
i.
Except for standard parts, the composition of any partnumber at any level in terms of subordinate part numbers
All next higher (next assembly) part numbers of any part,except parts assembling into standard parts
The composition of any HWCI in terms of part numbers andsubordinate HWCI numbers
The HWCI number and HWCI serial numbers (effectivity) onwhich any subordinate provisioned or to be provisioned partis used. This does not apply to subcontractors, vendors,and suppliers who are not producing HWCIS.
Identification numbers of class I changes which have beenpartially or completely released for any configuration itemnumber and HWCI serial number and class II changes aspertains to configuration item number
The configuration item numbers and HWCI serial numbers whichconstitute effectivity of each engineering change
The military specification numbers or military standard partnumbers used within any nonstandard part number
The subcontractor, vendor, or supplier part numbers whichhave been assigned
The contractor specification document, specification controldrawing numbers, or source control drawing numbersassociated with any subcontractor, vendor, or supplier partnumber.
100.4.3 Release of engineering changes. The contractor’s releasefunction and d~umentation shall be capable of identifyingengineering changes and retaining the record of supersededconfiguration requirements, affecting HWCIS which have beenformally accepted by the contracting agency.
100.4.3.1 All class I and II engineering changes released forproduction incorporation shall be identified by identificationnumbers and shall be completely released prior to formal
83
MIL-STD-483AAPPENDIX X
acceptance of the HWCI where first installed.
100.4.3.1.1 The configuration released for each HWCI at the timeof its formal acceptance shall be retained in release records forthe time required by retention of records requirements in thecontract, or as otherwise provided in 100.4.4 through 100.4.4.3.
100.4,4 Field release functional capabilities. Engineering datadefining =mally accepted equipment which is under thejurisdiction of the contractor, or government through category IItesting and which is progressing through testing or throughactivation programs, shall be maintained current with all fieldactivity requirements and released as follows:
100.4.4.1 Superseded requirements may be replaced by supersedingrequirements in the release records for units of a HWCI mission,design, series or type, model, series which are logisticallysupported by the contractor and which were accepted prior to theestablished product baseline (physical configuration audit).
100.4.4.2 Superseded requirements of the product baseline shallbe retained as a reference release and superseding requirementsadded as a requirements release for all units of the HWC I whichhave been formally accepted or are under the jurisdiction of thecontractor.
100.4.4.2.1 Superseded requirements shall be retained in allrelease records until status accounting records indicate thatsuperseded configurations no longer exist.
100.4,4.3 Engineering changes to HWCIS which have been formallyaccepted by the contracting agency, and which are not under thejurisdiction of the contractor, shall be released for serviceaction. For service action, the multiple release procedure shallnot be used.
100.5 Correlation of engineering changes with manufacturedproducts. It is me ob~ectlve that each class I eng~neerlngchange approved by the contracting agency be incorporated in allunits within one mission, design, series or type, model, series ofthe HWCI affected. Complete verification of the productionincorporation of engineering changes is therefore required toassure that engineering changes directed were accomplished onspecific HWCIS. The requirements for accomplishing this functionare based on production and quality control capabilities which thecontractor “ required to comply with in accordance withMIL-I-45208 O:s MIL-Q-9858 whichever is a requirement of thecontract, Where the contractor has satisfactorily demonstratedhis ability to control the design, manufacture, and incorporationof engineering changes, complete verification will be consideredaccomplished by a documented audit of the first incorporation ofthe engineering change, and routine surveillance thereafter.
84 -
MIL-STD-483AAPPENDIX XI
110. SYSTEM ALLOCATION DOCUMENT
110.1 Purpose, This appendix provides criteria to be followed inthe development of a System Allocation Document (SAD).
110.2 Scope. The SAD is used to identify the aggregation ofconfiguration items (computer software, hardware, and facilities)which form the basis for system design and integration. It shallbe the document that identifies the location of all configurationitems by configuration item serial number for each location of thesystem/configuration item program. The contractor shall preparethe SAD and shall update and maintain the document as specified inthe contract.
110.3 Or anization and content.contain~l~ormats A ‘hesAD shall include ‘he ‘?~aB, and C shown on figures 16,18, however, the format is no: a mandatory requirement. Th&document shall consist of lists, prepared as book form drawingsand assigned drawing numbers, which identify the systemconfiguration of each location. It shall also consist of the topassembly drawings of the configuration items at those locations.
110.3.1 This document shall be identified by a title page showingthe system\configuration item program designation number assignedby the contracting agency followed by the title “System AllocationDocument” as indicated in figure 16, sample A.
110.3.2 Part I of the SAD shall contain the information shown in--figure 17, sample B. This information shall be referenced/releasedby the Government agency or integrating contractor as a book-formdrawing. The drawing may be in the form of a data processingmachine printout.
a.
b.
c*
d.
The location block shall contain the official designation ofthe Government agency or other organizational level wherethe listed configuration items will be integrated as asystem for its mission.
The system employment and configuration block shall containa brief narrative describing the mission at the location anddescribing the configuration required for that mission.
The specification reference block shall contain theparagraph numbers in the System/Segment Specificationrsection 3.1 system definition which are applicable to thenarrated employment and configuration description, Forconfiguration item programs, the pertinent paragraphs ofSection 3.1 configuration item definition of the developmentspecification shall be used.
Mission equipment is the identified configuration items tobe formally accepted by the contracting agency at the
85
MIL-STD-483AAPPENDIX XI
contractor’s plant for accountability thereafter by thelocation. Some of these configuration items will be shipped _to the location with other configuration items installed inthem.
Note: The contracting agency regularly accepts configurationitems from one source and supplies them for installation inequipment to be furnished as a configuration item by anothersource. An example is an engine supplied for installation in anaerospace vehicle. In these cases, the installing contractor shallalways identify the supplied configuration items in the list ofmaterial of his drawing as Government-furnished.
e. The configuration item number for the HWCI, and the softwareinventory number for the CSCI, based on the agreed tosoftware inventory numbering system.
f. The short title entry shall contain the noun phrase which ispart of the title of the configuration item top drawing.
9“ The part number shall contain the part number of allquantities of the HWCI allocated by engineering design tothe location.
Note: Initially, the contractor shall assign just one part numberfor all allocations of a configuration item within one Mission,Design, Series (MDS). Practice to the contrary may indicate that apart number is being used as a configuration item number,indicating noninterchangeabil ity and adversely affecting updating —and maintenance.
h.
i.
j.
k.
The serial number entry shall contain all serial numbers forthe total quantities of each “configuration item number”allocated by engineering design to the location.
Installed equipment shall contain the configuration iternsthat are installed in the mission equipment at thecontractor’s plant, or as removed and replaced subsequent toacceptance and recorded in historical records accompanyingthe configuration item.
The configuration item number entry shall list allconfiguration iterns installed in each mission equipmentconfiguration item number.
The short title, part number, and serial number shall be asdefined in paragraphs f, g, and h, respectively, as appliedto each installed equipment/configurat ion item number.
110.3.3 Part II of the SAD shall contain the top assembly drawingand quantity of all configuration items shown in Part I. Figure18, sample C, is provided as a guide; all entries are
86 w
MIL-STD-483AAPPENDIX XI
+- self-explanatory. The equivalent to a hardware top assemblydrawing for computer software is a CSCI architecture diagram foundin the Software Product Specification.
110.3.4 Additional parts may be added, as approved by thecontracting agency, to contain different machine sorts of part Idata.
110.3.5 Configuration items that must be moved to differentlocations at intervals shall be listed and identified as such sothat the entry need not be revised each time these configurationitems are rotated or moved from site to site. For each suchconfiguration item, the list shall identify, where practicable,the office maintaining records of the configuration item’smovements.
-
87
MIL-STD-483APPENDIX XI
SYSTEM ALLOCATION DOCUMENTTECH CONTROL EQUIPMENT
FOROVERSEAS AUTOVON
(490L PROGRAMS)
LOCATION DRAWING NUMBER
NAPLES, ITALY 900S2151COLTANO, ITALY 90052J52HILLINGDON, ENGLAND 90052153
LANGERKOPH, GERMANY 90052155COROZAL, CANAL ZONE 900S2156
FELDBERG, GERMANY 90052154
DONNERSBERG, GERMANY 9oos215a
MARTLESHAM HEATH, ENGLAND 90052160FLOBECQ, BELGUIM 90052161
HUMOSA, SPAIN 90052162SCHOENFELD, GERMANY 90052163FUCHU, JAPAN 90052164
ATHENS, GREECE 90052166ANKARA, TURKEY 90052167FINEGOYAN BAY,GUAM 90052160FUTEMA, OKINAWA 90052169
DAU, PHILIPPINE ISLANDS 90052170GROSS MOUNTAIN, TAIWAN 90052171
FIGURE 16. Sampk A, System Allocation Document
-
88
MIL-STD-483APPENDIX XI
..—
8WTEM EMPLOYMENT AND cotOpiomnoN 8pEcwmnoNnmuwNcE LOCATION
MlsslmEoutPuENT lNSIALLEDEOU~NT
CONFKLIIEM
PART SERIALCONFIG.
-T TITLE rnw SNORT TITLEPART EERIAL
NUMBERNUMBER NUMBER
NUM8ERNUMBER NUMBER
4XXL SYSTEMS ALLOCATION DOCUMENT PART IORAWING TITLE AND NUMBER
NUMBERI WEET OF I
IBSUE
FIGURE 17. Sampk B, System Allocation Document
89
MIL-STD-483APPENDIX XI
I j LOCATION I
I= I ‘=’”0 IEOU~ NOMENCLATURE I‘F l== I
1 (
4)(XL SY~ ALLOCATION ~ PART II
h ,
NUMSERI
SNEET OFI
tSSUE
FIGURE 18. Ssmple C, System Allocation Document
90
MIL-STD-483AAPPENDIX XII
120. CONFIGURATION AUDITS.—
This Appendix has been replaced by MIL-STD-1521, Appendixes G, H,and I.
L
91/92
---- 1300 ENGINEERING
MIL-STD-483AAPPENDIX XIII
cHANGEs (EQUIPMENT/MUNITIONS)
130.1 Purpose. This appendix provides supplementary informationfor configuration control of engineering changes in accordancewith DOD-STD-480 and MIL-STD-481, These instructions pertain toall engineering changes (including VECPS) to hardware. Engineeringchanges to computer software are covered in Appendix XIV of thisstandard.
130.2 S$ope. This appendix establishes unique provisions forengineering changes to the functional baseline as reflected in thesystem/segment or HWCI specification, the allocated baseline asreflected in the hardware development specifications, and theproduct baseline as reflected in the hardware productspecifications. The baseline established in the contract ischanged only by Class I ECPS approved by the contracting agencyand incorporated in the contract by contract change documentation.
130.3 DELETED
130.4 Changes to the System/Segment Specification. The ECPformat (DOD-STD-~O)=all be used, except as follows:
a.
b.
c.
The words “system specification ECP “ shall be boldlyidentified directly above block 1, over the words“originator name and address,” of DD Form 1692.
Figure 5 of DOD-STD-480 is changed to require a DD Form1692-4, cost summary, during engineering and operationaldevelopment to the extent that cost data are available.
The mission capability of a system shall be identified bythe mission,- desi~n, se;ies or type, model, seriekdesignation of the system. Mission capability is defined asthe system characteristics and operability requirements inthe approved system specification. Proposals to change theserequirements will only be made by the contracting agency andmay result in a new mission, design, series or type, model,series designation of the system as determined by thecontracting agency. DOD-STD-480 paragraph 20.9, “Block31. Development requirements and status. ”
130.4.1 Changinq the System/Segment Specification =atgvalidation & =ncludlnq the source selectlonperiod.
130.4,1.1 During the validation phase, any of the competingcontractors may require a change to the functional baseline astechnically defined in the System/Segment Specification. In thiscircumstance, the contractor shall initiate a System/SegmentSpecification ECP for his segment (see Appendix III) per paragraph4.6.1.1 of DOD-STD-480 and submit it with his formal proposal.
93
MIL-STD-483AAPPENDIX XIII
130.4.1.2 The System/Segment Specification shall be revised and -expanded at the completion of the validation phase by an ECP. TheHWCI development specifications which define the allocatedbaseline shall establish a more refined basis for the program andthe succeeding contract. Any update of the System/SegmentSpecification at the end of the validation phase or at any othertime as finally negotiated shall be accomplished by an ECP.
130.4.2 Chan in S stem/Segment~= ‘he ~has;.
Specification durinq thedevelopment acqulsi=n The contractors shall accompl=the followlng during the eve opment period of the acquisitionphase for all ECPS affecting the System/Segment Specifications:
a.
b.
c.
d.
e.
When changes to the System/Segment Specification affects theinterface of HWCIS, and other contractor/agencies areinvolved, Appendix II shall be invoked, in which case theICWG chairman, if any, or the interface control contractoror agency, will establish the responsibilities for actionson the ECP.
The contractor initiating the change shall be responsiblefor determining other contractors, system segments, and thefunctional interfaces affected.
The contractor shall be responsible for coordination of apreliminary ECP with the other affected contractors beforesubmitting it to the systems engineering and integratingcontractor or agency whichever is custodian of theSystem/Segment Specification. The custodian shall assign theECP number and the SCN number and prepare the SCN.
Documentation of the ECP per paragraph titled Class IChanges During Engineering or Operational System Developmentof DOD-STD-480 shall include the estimated total impact ofthe change together with a description of the extent ofcoordination and understanding established with the othercontractors. This shall include reference to all ECPS, toconfiguration items affected and known.
Systems enqineerinq and integrating contractors or agenciessfiall be “responsible for ;eview-and recommendation-on allinterface ECPS as well as for preparation of ECPS forchanges to systems requirements which they initiate or areresponsible to have prepared.
130.4.2.2 The contractors shall prepare ECPS using the followingsupplemental guidance:
a. Interface (code B) shall be used for all ECPS which affectmore than one system segment and which require coordinationbetween two or more contractors.
94
MIL-STD-483AAPPENDIX XIII
b. Changes to integrated system test requirements shall beprepared as an interface ECP when such changes are requiredto correct the system\segment specification to make itcompatible with the test plans. Such changes shall beproposed by the contractor designated by the contractingagency to plan and implement Category II (or equivalent)test program.
130.5 Engineering changes to development specifications.—
130.5.1 Changes to development specifications w thevalidation
wG preparation of proposals. These changes ~
limited to the ollfiing cases: —
a. When hardware development specifications are provided by thecontracting agency as part of the validation contract orwork statement.
b. That portion of the system/segment specification which mayindicate use of an existing segment with already establishedHWC I Development Specifications (e.g., a Thor-Agenalaunching a new communications satellite system).
130.5.1.1 The validation contractors shall prepare ECPS to changethese configuration item specifications using DOD-STD-480procedures. Unless the contracting agency indicates to thecontrary, these ECPS shall be held and submitted as part of theproposal package. The contractor shall coordinate the change withthe established segment contractor as an interfacing change usingAppendix 11 of this standard as a guide. The estimated cost ofthese ECPS shall be included in the contractor’s proposed cost forthe development/acquisition phase.
130.5.1.2 Contractors for the system segments, which incorporateconfiguration iterns having an established baseline, that areconducting a sole source validation under a separate contractshall submit ECPS during the validation period if they requirechanges to the configuration item specifications being used. SuchECPS must be processed as the design proceeds so that thevalidation contractors can be kept abreast of changes.
130.5.2 Engineering changes to development specifications !!L!Q<he evaluation period durfiq the development phase.
130.5.2.1 During the source selection evaluation, any ECPSsubmitted with the proposal (see 130.5.1 above) shall beformalized by the contractor when so directed by the contractingagency. These ECPS generally shall be no cost ECPS since they areto be included in the price quoted during the validation phase. Inthe event of changes required by the contracting agency duringnegotiation, the contractor shall be requested to prepare andsubmit ECPS , and the cost of these ECPS shall be included in the
.- 95
MIL-STD-483AAPPENDIX XIII
negotiated price.
130.5.2.2 Configuration control of the allocated baseline foreach HWCI shall be implemented beginning with incorporation of thehardware development specification into the contract. Bydefinition, allocated requirements are in the hardware developmentspecification and ECPS which only change these requirements mustbe substantiated in terms of performance, cost , or scheduleeffectiveness.
a. In addition to the requirements of the paragraph ofDOD-STD-480 entitled “Class I Changes During Engineering orOperational System Development,” a DD Form 1692-3 and DDForm 1692-4 shall be prepared to assess cost impact to theextent that such cost data are available. The figure ofDOD-STD-480 entitled “ECP Form DD 1692 Page Utilization” ischanged per the above.
b. The contractor shall provide the following additionalinformation in block 17 entry of the DD Form 1692 inDOD-STD-480. The need for the proposed change shall containa specific definition of the problem which the ECP proposesto solve, or of the new capability which the change proposesto provide. When the ECP is directed toward providing a newcapability, the improvements shall be described in specificnumerical terms and referred to applicable subparagraphs inthe HWCI development specification.
c. Class II changes do not apply to development specifications.
130.6 Engineerin‘+=–F
than es to thebaseline). DOD-STD-4 ‘Pacific:;::: +%%%supp emented as fopreparation of ECPS to be submitted for approval after the productbaseline has been established in the contract:
a. All ECPS shall be addressed and prepared at the contractlevel even though the change is at a level of reparableindenture.
b. The SCN will, if the ECP is approved, be the means by whichthe HWCI specification is changed and the basis for a changeto the contract. The SCN number will be shown in block 8 ofthe DD Form 1692. The SCN for other configuration itemspecifications shall be listed in blocks 27 and 30. If thesystem/segment specification is also to be changed, blocks28 and 30 will show the system/segment specification andsystem/segment specification SCN numbers.
c. Contractor’s own engineering order forms shall be used asspecified in paragraph 4.6.2 entitled “Class II engineeringchanges,” of DOD-STD-480 for all Class II changes. Thecontractor shall use a checklist as an aid in making proper
96
MIL-STD-483AAPPENDIX XIII
classification of the ECP. A completed checklist shallaccompany each Class II change when it is submitted to thelocal Government representative. An example of a checklistis shown is figure 19. The local Government representativesignature shall be obtained on the engineering order form inall cases.
He will accomplish this review within three working daysindicating his approval or disapproval of theclassification. If the contractor disagrees with thedetermination of the Government representative, he shall notrelease the change. He shall treat the change as Class I andsubmit the change to the contracting agency for finalresolution of the classification.
d. Once the product baseline is established, the hardwareDevelopment and the Product Specifications shall be treatedas one specification. A single ECP shall be used to changethe specifications. Separate SCN pages and specificationchange pages for the hardware Development and ProductSpecifications shall be submitted with the ECP.
e. Waivers will not be used when all units of a HWC I areaffected.
130.7 Addition of Aerospace Ground Equipment (AGE) HWCIS to the- functional/ alloc=ed baselines. When HWCIS -E requir= a=part of the total system configuration or to support an individualHWC I or system modification program are identified after award ofthe contract, the following procedures shall apply. An ECP shallbe processed to incorporate the additional HWCI(S) of AGE into thefunctional/allocated baseline. For purposes of establishing arequirement for AGE, DD Form 1692, blocks 16 and 17, shall be usedto describe the requirement/problem against which the followingappropriate action will be accomplished:
a. When the HWCI of AGE is a new design (Developmental) , theECP data package shall include a preliminary draft of adevelopment type HWCI specification in accordance with theapplicable appendix of MIL-STD-490. The type of developmentspecification shall be determined from the complexity andcharacteristics of the HWCI.
b. When the HWCI of AGE is an existing design which has beenpreviously procured for the Government inventory (standard),the ECP data package shall include a proposed additionalappendix to the inventory item specification (Appendix XIIof MIL-STD-490, titled Type C4, Inventory ItemSpecification) .
,.
97
c.
d.
MIL-STD-483AAPPENDIX XIII
When the HWCI of AGE is a modification to an existing designof a HWCI, the ECP data package shall include a descriptionof the proposed changes and be in the format of an addendumspecification to the existing HWCI specification (SeeAppendix IV of this standard).
When the HWCI of AGE is an existing design of a privatelydeveloped HWCI including commercially available productsjthe ECP data package shall include a copy of themanufacturer’s documentation identifying the form, fit, andfunction parameters of the HWCI. If the privately developedHWC I requires modification to make it suitable for theproposed application, a description of the requiredmodifications shall be included.
130.8 Multi le HWCI ECPS..han*r— ‘
When more than one HWCI is affected bya the cognizance of a single contracting agency, asingle ECP with separate dash numbers for each HWCI may be used inlieu of separate ECPS for each HWCI.
98
MIL-STD-483APPENDIX XIII
CONFIGURATIONITEM CONTRACT/CONTROL NUMBER
PART NUMBER
ENGINEERINGCHANGE CLASSIFICAT1ONCHECKLIST
CRITERIA(NOT LIMITED TO THE FOLLOWING) I
1. Are you recommendingretrofit(attritionor kit)?
2. Does thiscorrecta deficiency(speaficationvaluesor requirements)?7
3. Would it changeTechnicalManuals?1
a. Operational or Flight Manual
b. MaintenanceManualI
c. Illustratedor NonillustratedParts Manual
4. Would operational,testor maintenancecomputersoftwarebeaffected?
5. Are existingsparesaffected(obsoleted or rquire modification or will new spares be
required)?I
6. 1sinterchangeability,substitutabilityy or repiaceability afkcted?
7. Is safetyaffected?
8. 1sinterface,electromagneticcharacteristicsor compatability affected(withGFE, AGE, or
other)?
9. Is weight,balance,or momentof inertiaaffected?
10. 1sAGE affected?
11. Are trainingdevices/equipmentaffected?m
A “YES” answer to any of the above considered in relation to the criteria in DoD-STD-480 and the terms of
the contract identifies the change as a chm 1 ECP.
FIGURE 19. Engineering Change Chtssifiwtiort Checklist
-----
99/100
MIL-STD-483AAPPENDIX XIV
140. ENGINEERING CHA.NGES (COMPUTER SOFTWARE)
140.1 Purpose. This appendix supplements the requirements ofDOD-STD-480 to provide uniform procedures for preparing,formatting, and processing changes to Computer SoftwareConfiguration Items.
140.2 Scope. This appendix establishes the requirements forconfiguration control that are unique to computer software. It:
a. Supplements DOD-STD-480.
b. Replaces DOD-STD-480 paragraph 4.2.1 titled “Class Iengineering change”, (paragraph 4.2.1.1 titled “Class Iengineering change to a privately developed item”, isey.eluded) and paragraph 4.2.2 titled “Class II engineeringchange”.
c* Provides guidance in preparing the DD 1692 series of formsfor engineering changes to CSCIS. Hardware orientedrequirements of DOD-STD-480 pertaining to engineeringdrawings, production/manufacturing, and logistics support donot apply to CSCIS. Other requirements of DOD-STD-480 whichhave not been supplemented by this appendix shall remain ascontractually invoked.
-— 140.3 Applicability. The requirements of this appendix areapplicab le to all contracts involving CSCIS during the acquisitionand operational phases of CSCI design, development, test, andsupport. Each contractor to the Government shall be responsiblefor his compliance with this appendix as well as the compliance ofhis subcontractors, vendors and suppliers to the extent that theyare involved in preparing, formatting, and processing engineeringchange proposals to CSCIS for which the prime contractor isresponsible.
140.4 Multiple Configuration Item ECPS . When more than oneconfiguration Item 1s affected by a change under the cognizance ofa single contracting agency, a single ECP with separate dashnumbers for each configuration item may be used in lieu ofseparate ECPS for each configuration item.
140.5 Classification. The originator of an engineering change toa CSCI shall classify the change as Class I or Class 11. Assumingthat its purpose and necessity have been established, each ECPshall be assigned the appropriate classification by the originatorin accordance with the definitions in this appendix (paragraph140.6). Disagreements as to classification of computer softwarechanges shall be processed in accordanceforth in DOD-STD-480.
140.6 Definition of classification.—
10.1
with the procedure set
DOD-STD-480 paragraphs
MIL-STD-483AAPPENDIX XIV
4.2.1, (excluding paragraph 4.2.1.1) and 4.2.2 are replaced by the _following with respect to Class I and Class 11 computer softwarechanges.
140.6.1 Class ~ change. A computer software change shall beclassifie~ass I when one or more of the factors listed(subparagraphs a, b, c, or d) below is affected:
a. The Functional Configuration Identification (FCI) orAllocated Configuration Identification (ACI).
b. The approved Product Configuration Identification (PCI)including referenced documents that pertain to:
(1) Performance, including reliability, maintainability,correctness, efficiency, integrity, usability,testability, flexibility, portability, reusability, orinteroperability, outside stated tolerance.
(2) Interface characteristics (external
c. Non-technical contractual provisions:
(1) Fee
(2) Incentives
(3) Cost to the Government
(4) Schedules
(5) Guarantees or deliveries.
d. Other factors:
(1)
(2)
(3)
(4)
(5)
(6)
Government Furnished Equipment
Safety
Other computer software
GFE
to the CSCI).
Compatibility with support resources, trainers, ortraining devices/equipment
Delivered operation and support manuals for whichadequate change/revision funding is not on existingcontracts
Pre-set adjustments or schedules affecting operatinglimits or performance to such extent as to requireassignment of a new software inventory number
102
MIL-STD-483AAPPENDIX XIV
(7) Skills, manning, training, biomedical factors or humanengineering design.
140.6.2 Class II chanqe. A ccmputer software change shall beclassified Clas=II when it does not fall within the definition ofa Class I change in paragraph 140.6.1 above. Examples of a ClassII change are (a) a change in documentation only (e.g., correctionof documentation errors; corrections to code which do not affectsoftware logic, design, or mathematical formulation; or additionof clarifying notes), or (b) other changes of a minor naturewithin categories specifically defined by the contracting agencyin a given procurement (e.g., adaptation data or recompilingwithin specified limits).
140.6.3 Class I, ECP types. The type of Class I ECP applicableto csf:~s sh=l be used in accordance with the followingguidelines. A preliminary ECP shall be prepared in accordancewith DOD-STD-480 . A formal ECP shall contain an assigned SCNnumber and sufficient definition of a proposed change and itsimpact, including schedule and cost data, to support formalapproval and contractual authorization. Definition of theproposed change provided with a formal ECP need not normallyinclude exact changes in CSCI specification data to the degreethat such data represents products of the total computer softwarechange implementation process.
140.7 Instructions for the preparation of ECP forms.—. —— —
a.
b.
c*
140.8
The contractor shall use the ECP form and format illustratedDOD-STD-480 for the preparation of all Class I ECPS to
;;CIS.
Instructions for ECP preparation contained in Sections 10through 60 of Appendix A to DOD-STD-480 shall apply exceptas noted herein.
ECPS shall be submitted in the uniform format specifiedherein for all proposed changes:
(1) TO the functional configuration identification andallocated configuration identification both before andafter establishment of a product baseline for the CSCI,and,
(2) TO the product configuration identification after theproduct baseline has been established.
Engineeringq- proposal Q!!QZ!!! 16921 -L
140.8.1 Block ~ ClassECP Class as defln~
-..
of ECP. Enter I or 11 for the.— applicable140.6.1 and 140.6.2 above.
103
MIL-STD-483AAPPENDIX XIV
140.8.2 Block ~ ECP desi nation.paragraph 10.6 of=OD~tl~~n~~~~~’&~nsE&O~~~~~~Sti~~ -apply, except for modified subparagraphs (a) and (b) as notedbelow:
a. Model/type - enter the CSCI identification.
b. Enter either a “P” for preliminary or “F” for formal, inaccordance with 140.6.3 herein.
140.8.3 Block ~ Specification and other data affected. The dataiterns to=xarnined by the con~c~or identification in thisblock shall include, at the minimum, all items listed on theContract Data Requirements List (CDRL) for the CSCI developmentcontract, as well as previously-delivered support and user manualsassociated with the CSCI. This entry shall identify each dataitem affected by the proposed change, the nature of the effect,and any relevant impact on schedule or delivery of the data item.
140.8.4 Block > Drawings affected. List all drawings affectedby the change.
140.8.!5 Block ~ In production. This block is not applicable to—CSCIS.
140.8.6 Block & Name ofEnter
~p part or lowestthe names of Leve l— Computer m :;:;::%s
(TLCSCS), Lower Level Computer Software Components (LLCSCS), and -Units affected.
140”8”7 EQs!.! A2LdE2Q ,&!p?H ~at~identification revlslon dj- e%e~LC;::LLCSC, and Unit identified in block 14.
140.8.8 Block 18, Effectivity. Identify, by CSCI version number,the —Tversion the CSCI into which the change will beincorporated. Enter the date(s) of the SCN(S). In the ECPsubmittal, the contractor shall indicate the new version number inblock 18. If’the impact of the ECP merits the issuance of a newversion of the CSCI, block 18 of the ECP submittal shall alsoinclude a recommendation to this effect. Serial numbers may beused in lieu of version numbers upon agreement of the contractingagency.
140.8.9 Block 19 Effect on productionIdentify em otiel-scfidule.
140.8.10 Block ~ Retrofit. This block mayCSCIS. However. If the Csc I chan~e is
delivery schedule.
or may not apply toPart of a larqer
hardware/equiprnent change and incorpora~ion of the CSCI change ‘isper a hardware retrofit schedule, that information will beincluded here either directly or by reference.
104
MIL-STD-483AAPPENDIX XIV
-- 140.8.11 Block ~ Estimated costs/savinqs under contract. Entera dollar estimate of costs (contract fundlng~ther Increased ordecreased, which will result if the change is approved by thecontracting agency. If the contractor at the time of submissionof the formal ECP has available the firm cost proposal, thisproposal shall be submitted and shall be accompanied by theappropriate cost breakdown.
140.9 Engineerin q QIZl$& pr?pos+~ Form +6?2-1: u L Effectson functional /allocated conflquratlon =tlflcatlon.—
140.9.1 Block 29, Effects on em 10— ‘Theeffectiveness. con~a~~rai~~~~’ %;-
lnformatlon as applicable to the phase of CSCIdevelopment/operation at the time of ECP submission:
a.
b.
c.
-.d.
e.
f.
Describe effects of the proposed change on personnel andtraining requirements, including any changes or the effectson the operability or support of the system.
Identify any effect on contract engineering technicalservices that increases the scope or dollar limitationestablished in the contract.
Identify any required changes to the data base parameters orvalues, or to data base management procedures.
Identify and explain any estimated effects of the proposedchange on acceptable computer operating time and cycle timeutilization.
Provide an estimate of the net effect on computer softwarestorage.
Identify and explain any other relevant impact of theproposed change on utilization of the system. -
140.9.2 Block 31 Develo mental re uirementscontractor sha~ ~denti!y in this ~lock the scf%%ul~t~%&nceT~;computer software design/development/test activities whic~ will berequired to implement the proposed change. In the case of ECPSwhich are initiated following the completion of significantpreliminary design of the CSCI, or of a new CSCI version, specificinformation shall be entered in this block to identify significantrequirements for computer software redesign, re-assembly,re-compilingr recoding, retest, special installation, adaptation,checkout, or live environment testing, as applicable, and toidentify the specific impact of these factors on existingschedules for completion.
-----105
MIL”STD-483AAPPENDIX XIV
140.10 Engineerin‘-
Proposal DD Form 1692-2,Effects on product con lguratlon lden~fi~on. SpecifWer& -of lnform=ion to be reDorted on DD Form 1692-2, as specified inthe instructions under kection 30 of Appendix A’to DOD2STD-480 areeither already provided on the forms 1692 and 1692-1 or do notreadily apply to computer software. In general, factors associatedwith the use and operation of CSCIS depend more directly oncharacteristics defined at the level of the requirementsspecification (Software Requirements Specification, and, ifapplicable Interface Requirements Specification(s)) than on thosedefined at the product configuration level; and factors ofcomputer programming support are rarely, if ever, affected bymodifications in the CSCI product configuration. However, thecontractor shall review these factors and comply with the intentof blocks 37, 38, 42, 43, 44, and 46.
;ZZ;;;te%%%Y%% c%?%ipaE;Vpo%’Fo% 1=3 %%%ot%&us%with ECPS ~C~ -total cost estimates shall be based on allimpact factors identified in the relevant blocks of DD Forms 1692and 1692-1 and shall be reported as specified in 140.8.11 herein.
140.12 EngineeringFor21%Y/- Y% =
savinqssummary. DD not app y In the case where allrelated ECPS being summarized refer to computer software changesonly. When the related ECPS include changes to HWCIS, the formshall be used in accordance with instructions contained in Section50 of Appendix A to DOD-STD-480.
CSCIS. The ~ficant scheduling information associated withcomputer software changes is normally that information relating tomilestones in the change analysis/design/development/test process(e.g., as required in block 31 of DD Form 1692-1; see 140.9.2herein) . Schedule information for CSCI changes shall be provided,listing significant developmental milestones associated with thechange, and representing events by the use of standard milestonechart symbols.
140.14 Instructions for preparation of Notice of Revision (NOR)DD Form 1695.
— ———
140.14.1 Blocks ~ - 9. A NOR is applicable to a CSCI when it wasnot speci~y de=loped for a given system (commerciallyavailable) but is utilized with the system. For example,maintenance/diagnost ic and utility programs that are provided witha given general purpose computer and must be modified/changed tooperate within the allocated systems environment. The NOR wouldprovide a record of change to the commercially available softwarefor present and future use.
106
MIL-STD-483AAPPENDIX XV
150. REPORTING THE ACCOMPLISHMENT OF
UPDATING/RETROFIT CHANGES
tiiiiar/Weq2~iZnP’ fZiEiZcGFi’iFZ.$i. GYzte?h.z?ziii~~engineering and affecting TCTO/ECP accomplishments of approvedClass I changes (DOD-STD-480). These data will be used by thecontractor to update the configuration status accounting reportsthat he is producing for the contracting agency. This appendixdoes not supersede the requirements for reporting TCTOaccomplishments via the AFTO Form 349 when AFM 66-1 and the 00-20series technical orders are applicable.
150.2 Applicability. Each contractor to the contracting agencyshall be responsible for compliance by his subcontractors,vendors, and suppliers to the extent specified in 1.3 of thisstandard.
;Z~&pli%%% Zon;;;;;or; ~%~:s f~%%.~%) ~ZYr~ySd~~computer software, equipment, and spares. Figure 20 is asuggested format for use in recording such information. Thisformat shall not be used to report in-product ion changes. Afterpreparation, the contractor shall forward the original and all
-— copies with retrofit kit or modification instructions to thecontracting agency or contractor agency having custody of theconfiguration item affected. Integrating contractors shall preparean original and tWo copies of the report. In instances where achange to a configuration item must be accomplished concurrentlywith a change approved for associate contractor configurationitem, an original and three copies shall be prepared.
150.3.1 Contracting agency or contractors having custody of theconfiguration items affected shall complete copies of the reportupon accomplishment of the approved change. The completed originalwill be retained for filing with the equipment records. One copyshall be forwarded to the contracting agency configurationmanagement organization, if required another copy shall beforwarded to the associate contractor’s configuration managementorganization, and the third copy shall be forwarded to thecontractor preparing configuration status accounting reports forthe contracting agency. Processing of these completed reportsshall be accomplished as they occur.
150.4 Preparation instructions. All entries on the report, withthe exception of the signature blocks , shall be typewrittenwhenever possible. If a typewriter is not available, the entriesshall be inserted with permanent black, blue, or blue-black ink.Signatures shall be made with permanent black or blue-black ink.
\ --
107
MIL-STD-483AAPPENDIX XV
150.4.1 Format and entries
a.
b.
c.
d.
e.
f*
9“
h.
i.
]0
Block 1 - location - Enter the location where the changeshall be accomplished. Example: “Electronic SystemsDivision, ” “Air Force Western Test Range,” “576 Squadron.”
Block 2 - identification of change - Enter ECP number aswell as Time Compliance Technical Order (TCTO) and Data CodeNumber, when applicable.
Block 3 - configuration item affected - Enter all applicablenumbers
Block 4 - date- Enter date of installation
Block 5 - check appropriate square and explain whennecessary (see figure 20)
Block 6 - problems encountered during installation - Makeentry when appropriate
Block 7 - proposed solution - Make appropriate entry
Enter “X:n in applicable “Distribution To” blocks
Sign and record “Name of Contractor Installation Agency”under ‘Installation Accomplished By”
Sign and record “Name of Government Inspection Organization”under “Installation Inspected By.”
108
----
MIL-STD-483APPENDIX XV
UPDATING/RETROFITCHANGES
lNSTALLATIONCOMPLETION NOTIFICATION
-—
(1) Location
(2) Mentification of Change
ECP No
TCTO No
Data Code No
(3) Config. item Affected
Config. Item No
Serial No
Part No
VeraionNo
(5) InstallationFully Completed 0
(4) Date
Partially Completed o
If Partially Completed,Explain
(6) ProblemsEncounteredDuring Installation
(7) Proposed Solution
Distribution to: InstallationAccomplishedBy:
Contract CMO = signature Required
ContractingAgency CM() n Name of Contractor InstallationAgency
Contractor/Government InstallationInspectedBy:
Record CenterO~lce SignatureRequired
Name of Government InspectionOrganization
FIGURE 20. (Smple Form) Installation Completion Notice
109/110
MIL-STD-483AAPPENDIX XVI
160. NON COMPLEX COMPUTER PROGIUW SPECIFICATION
This Appendix has been deleted.
L
111/112
MIL-STD-483AAPPENDIX XVII
170. CRITERIA FOR SELECTING CONFIGURATION ITEMS
170.1 Purpose. This appendix provides criteria for selectingconfiguration Items.
170.2 Scope. The criteria of this appendix shall be used in theconfiguration item selection process whenever it occurs during thelife cycle.
170.3 Applicability. Each contractor shall be responsible forhis compliance with this appendix as well as the compliance of hissubcontractors, vendors, and suppliers in accordance withparagraph 1.3 of this standard.
170.4 General Considerations.
170.4.1 Need for Configuration Item Identification. Selection ofconfigura= Items 1s based on the definition contained inDOD-STD-480A: “an aggregation of hardware/software, or any of itsdiscrete portions, which satisfies an end use function. ..configuration items are those specification items whose functionsand performance parameters must be defined and controlled toachieve the overall end use function and performance.”
170.4.2 Level of Government Control. The configuration item mustbe a manageabl~level of assemb ly. The selection of configurationitems is normally a function of anticipated design and should beindependent of the concept for future reprocurement. The selectionprocess separates the elements of a system into individuallyidentified subsets for the purpose of managing their development.The selection is normally limited to the designation ofconfiguration items to major subsystem levels of the WorkBreakdown Structure, or to a critical item of a lower level, whenso identified. Configuration item selection reflects an optimummanagement level during acquisition. This level is one at whichthe contracting agency specifies, contracts for, and acceptsindividual elements of a system.
170.4.3 Lo istics and Life Cycle Considerations.+“—
The selectionof hardware so tware to be manaqed as conflquration items shouldbe determined by the need to iontrol a Configuration item’sinherent characteristics or to control that configuration item’sinterface with other configuration items. The selection is amanagement decision normally accomplished through the systemengineering process in conjunction with configuration managementand with the participation of logistics. Selecting configurationitems should be with a full view of the life cycle cost andmanagement impacts associated with such a designation. Choosingtoo many configuration items increases the cost of control;choosing too few or the wrong elements as configuration items runsthe risk of too little control through lack of managementvisibility. It must be determined what control is needed to be
113
MIL-STD-483AAPPENDIX XVII
exercised in light of cost/benefit trade-offs. The configurationitem selections are made accordingly.
170.4.4 Common Subsystem Considerations. On development programsfor subsystems or support equipment that will be common to morethan one system, the basic configuration item should be thatassembly that is common to all applications. An assembly part thatis required to meet interface or other requirements peculiar toone of the systems should be identified as a separateconfiguration item in that system.
170.4.5 Schedule Considerations. The major elements comprisingthe system should be ldentlfled as configuration items during theDemonstration and Validation Phase. Early selection ofconfiguration items is important since management emphasis becomesgreater as development progresses. As development continues andlogistic or technical considerations surface, additionalhardware/software can be designated configuration items. Usually,the configuration item selection process should be essentiallycomplete by PDR for HWCIS and SSR for CSCIS.
170.5 Specific Considerations. The following paragraphs discusssome of the considerations upon which the configuration itemselection decision shall be based.
170.5.1 DELETED—
170.5.2 Engineering Release System> The configuration item mustallow the contractor to release enqlneerinq changes at an assemblylevel which is reportable and which enable= verification of changeincorporateion, i.e., does not preclude change incorporationverification in a lower level assembly.
170.5.3 Criticality. A configuration item should be identifiedas a separate configuration item if failure of the configurationitem would adversely affect security, human safety, theaccomplishment of a mission, or nuclear safety, or would have asignificant financial impact.
170.5.4 Existing or Modified Existinarticles ‘ %,0+%%.0::%%that are%ot conflquratlon itemsexpense should not generally-be candidates for reidentification asnew configuration items on new programs. Existing/modified designand commercially available equipment/computer software should notnecessarily be excluded from configuration item selection. Theconsiderations identified in the remaining subparagraphs ofparagraph 170.5 should be addressed prior to making a decision.
170.5.5 New or Modified Design. Careful consideration shall begiven — — modified design items,new or wherein more than a modestdegree of complexity, utilization of new materials, processes ortechnology is involved; and, where the contracting agency wants
—
114
MIL-STD-483AAPPENDIX XVII
direct control over the performance requirements for that design%.item, at a specific time, i.e., when the contracting agency isdirectly concerned with detailed development.
170.5.6 Interfaces. Interfaces among HWCIS and CSCIS should besimple. Functions which are highly data or control interdependentshould be allocated to the same HWCIS or CSCIS. Functions whichexhibit a high disparity between input and output data ratesshould be allocated to separate HWCIS or CSCIS.
170.5.7 DELETED
170.5.8 Maintenance. When different agencies have responsibilityfor maintaining parts of an element, consider breaking the elementinto separate configuration items. An item which is clearlydesignated as “Repairable” is much more a configuration itemcandidate than one which “ not repairable. Eventuallylogisticians must deal with tk: Line Replaceable Units (LRUS)which comprise the principal components of the subsystem. However,designating configuration items at the LRU level at the onset offull-scale development (FSD) would add significant cost to thedevelopment effort, especially in the area of changemanagement. The LRU level is usually too low a level for effectiveconfiguration control during development.
170.5.9 ~w
Considerations. Without properplanning, minor items o support equipment could swell the list ofconfiguration items. Minor in this context refers to items such asindividual hand tools, as compared to hydraulic torque wrenches,engine build-up tools, etc. There will usually be little or nochange activity on many of these minor items. It may besufficient to list these items as ‘support equipment” in paragraph3.2.4 of the configuration item Type B specification perMIL-STD-490 paragraph 20.3.2.4.c.
170.5.10 Subassembly Characteristics.~should have
Subassemblies (within aconfigurateion a common mission relationship;should have common installation and deployment requirements(ground and airborne segments would be separate configurationitems); should have a cycle of changes dependent on theconfiguration item; and should not be the subject of separate testor formal acceptance by the contracting agency (should beaccomplished as part of a configuration item). If these conditionsare not met, the subassembly should be either part of anotherconfiguration item or a separate configuration item.
-—
170.5.11 DELETED
170.5.11.1 DELETED
170.5.11.2 DELETED
115
MIL-STD-483AAPPENDIX XVII
170.5.11.3 DELETED
170.5.12 Types. If there are different configurations due todifferent adaptation data for each operating location, thedifferent configurations should be identified by(MIL-STD-490
typesparagraph 4.1.2 and 4.3b) within a single
configuration item.
170.5.13 Function. A given configuration item should avoidmixing t~ mission (including initialization, normaloperation, and back-up or degraded operation) , test andmaintenance, and support functions.
170.5.14 Supp lier. Elements provided by different suppliersshould be assigned to separate configuration items.
170.5.15 Use. Elements which are general purpose in nature,require the capability to be operationally reprogrammed, or areintended to be reused in another system or are likely to bechanged after initial deployment should be considered as separateconfiguration items.
170.5.16 Location. The functions allocated to a configurationitem should not be partitioned among separate geographicareas. Functions allocated to physically distinct processors in adistributed environment should be considered as separateconfiguration items.
170.5.17 Size. Configuration item selections whichmade on the basis of other criteria should be madeconfiguration item to manageable proportions.
cannot beto keep the
170.5.18 Schedule/Phasing. Elements scheduled for development,testing, and delivery at different times should be assigned toseparate configuration items.
170.6 Effects of Configuration Item Selection. Configurationitem selectlon—affects cost , S=U 1e and performance for thecontracting agency, prime contractors, subcontractors andsuppliers. The effects of configuration item selection should notbe permitted to occur automatically upon selection of an item as a‘configuration item. The effects which are unnecessary or prematurecan be tailored out for each configuration item by means of anappropriate contractually recognized vehicle, e.g., Program Plan,Statement of Work, CM Plan, Exceptions and Deviations. Selectionof an item as a configuration item for manageability may be basedon its administrative complexity, technical (engineering)criticality or maintenance (logistics) criticality. The followingis a listing of the usual effects of configuration itemdesignation:
116
MIL-STD-483AAPPENDIX XVII
a.
b.
c.
d.
f.
9“
h.
—.i.
]0
k.
1.
170.7many
Formal preparation of discrete configuration identification- most often in the form of a specification(s).
A discrete development or requirements specification and acompanion product specification.
Government approval of changes over the configurationidentification governing the configuration itern.
Continuing an accurate recording of the exact configurationstatus of the configuration item, including providing fieldactivities precise data dealing with impending or completedmodification actions.
Providing traceability of detailed design for follow-onactivity, including historical data and individual statusinformation for accident investigations, failure analysis,etc.
Individual design review activity (pDR, cDR, FQR, etc.)during development.
Individual qualification testing and reporting.
Individual physical and functional audits (PCA and FCA) atthe conclusion of development.
Discrete and separate “related” ECP development preparation,review, approval and negotiation (for changes toconfiguration items).
Separate identification indices and qualification records.
Separate nameplates and discrete configuration itemidentifiers (i.e., configuration item number, type, model,series, etc.).
Preparation of separate operator’s and user’s manuals.
Effects of selectinq =ma%es:o:fi?uration items” Tooconflgur~ion 1terns In effect~mDerina
visibility and management rather ~han improving it. These ‘ “effectsinclude:
a. Increased administrative burden in preparing, processing,and status reporting of engineering changes which tends tobe multiplied by the number of configuration items.
b. Increased development time and cost as well as possiblycreating an inefficient design.
117
MIL-STD-483AAPPENDIX XVII
c. Possible increase in management effort, difficulties inmaintaining coordination and unnecessary generation of paperwork.
170.8 Effects of selecting too few configuration items. Too fewconfigu~i=rns may resu~i=ostly loglstlcs~aintenancedifficulties. The following may result:
a.
b.
c.
Loss of identity through separation of affected portions ofa configuration item during field or depot maintenance ormodification installation activity, e.g., an autocollimatorand its mount.
Inability to control like individual rexnovelreplace iternswhen configuration item identification and control is at the“set” level, e.g., a storage battery set.
Loss of o~erational use of one function because required.maintenance on another function requires action against theconfiguration item level, e.g. , a configuration item havingseparate VHF/UHF functions loses both when maintenance mustbe done on either function.
170.9 Configuration Item Selection Checklist. The followingquestions should be used In selectlng configuration items tailoredto individual program/project requirements. If most of thequestions can be answered NO, the item probably should not be a _configuration item. If most ofihe questions can be answered =the item probably should be a configuration item. If the questionscan be answered with approximately equal numbers of YESS andadditional judgement is needed to determine if the item shoul%%a configuration item. The selection of configuration items is amanagement decision based on experience and good judgment. Itshould be kept in mind that some of the factors such asserialization and nameplates will be required, regardless ofconfiguration item selection, e.g., part of a higher levelassembly.
a.
b.
c.
d.
e.
Is it a critical high risk, and/or a safety item?
Is it readily identifiable with respect to size, shape andweight (hardware)?
IS it newly developed?
Does it incorporate new technologies?
Does it have an interface with hardware or softwaredeveloped under another contract?
118—
MIL-STD-483AAPPENDIX XVII
. f. With respect to form, fit or function, does it interfacewith other configuration items whose configuration iscontrolled by other entities?
9* Is there a requirement to know the exact configuration andstatus of changes to it during its life cycle?
119
MIL-STD-483A
custodian:Air Force - 10
Review Activities:Air Force - 11,13,15,17,19,26
Preparing activity:Air Force - 10
(Project CMAN-O-007)
120
tN@TR~~S: In s continuing●ffort to make our standsrdhtion documerrti better, the DoDprovidee this form for z in
mhtd$ting cotsuwnb ●td suggestions for improvamenta. AU users of military standmdiration documents are invited to ~vide
-~. Thu form msY be detached, folded along the iines indicated, taped along the loose edge (DO NOT STAPLE), andamUad. In block6, be asspecificaspoaaibieabout particular problem areas ●rch as wording which required interpretatknr, ~
too rigid, metrictbe, baa, ambiguous, or was incompatible, and gise proposed wording changes which would alleviak the
SWObhra. &ter in block 6 my remarks not related to a specific paregraph of the document. If block 7 is filled out, an
acknowledgement will be mailed to you within 30 days to let you know that your comments were received snd are being
ecmsidared.
NOZZ: This form may not be used to request copies of documents, nor to request waivers, deviations, or clarification of
qmcification requiresrranta on current contracta. Comments submitted on thie form do not constitute or imply authorization
to wake any portion of the referenced document(s) or to amend contractual requirements.
* u-s. GC— ●*I mlmtm,rxllc.. 1*I’.--sam*7*mee4
(Fold olon# thSs lineJ
(Fold eh?e W the)
111111~1IN THE
i uNITED STATES I
OPFUXAL •USINE~PENALTY FOR PRIVATE USE S300 BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO. 71XSS WA8M DC
POSTAGE WILL SE PAID BY MQ U.S. AIR FORCE
HQ AFSC/SDXPANDREWS AFB, MD 20334-5000
4
STANDARDIZATION DOCUMENT IMPROVEMENT PROPOSAL(SeeInstructIons - Reverse Sidcj
. DOCUMENT NUMBER 2. OOCUMENT TITLE
u. NAME OF SUBMITTING 0F4GAfIJl ZAT10N 4. TVPE OF ORGANIZATION (M-k one)
•1VENOOR
❑ us,.
. ADOFIESS (Stmel, CiIY, State, ZIP Cock)
•1Manufacture
n oT”ER ,SXCVY)
, PROBLEM A“ LAS
a. PwWraph Number ●nd Wording:
b. FIacomrn.nded Word#no:
c. 130as0n/RatlOnd* *or R.comrnendation:
i. F?EMARKS
‘a. NAME OF SUBMITTER (Laf, Fret, MI) — Opt,orI,l b. WORK TELEPHONE NUMBER (lnctud# Armcode J – Optlorwl
MAILING AOORESS (St?vet, City, Stete, ZIP Code) - Optional S DATE OF SUBMISSION (Y YMMDD)
,.--—––. ---
PREVIOUS EDITION IS OBSOLETE
—