498GBOT

8/7/2019 498GBOT

1/109

MIL-STD-498Overview and Tailoring

GUIDEBOOK

MIL-STD-498

Software Development and Documentation

OVERVIEWAND

TAILORINGAPPLICATION

ANDREFERENCE

8/7/2019 498GBOT

2/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page ii

This page is intentionally blank.

8/7/2019 498GBOT

3/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page iii

CONTENTS

Paragraph Page

FOREWORD .............................................................................................................................vii

EXECUTIVE OVERVIEW.........................................................................................................viii

PARTICIPANTS ......................................................................................................................... x

1. SCOPE.............................................................................................................................. 1

1.1 Purpose................................................................................................................... 11.2 Application of the guidebook................................................................................... 1

1.2.1 Intended audience.................................................................................... 11.2.2 Use on contracts ...................................................................................... 1

1.3 Organization of the guidebook ................................................................................ 1

2. DOCUMENTS MENTIONED IN THIS GUIDEBOOK......................................................... 22.1 Government documents.......................................................................................... 2

2.1.1 Specifications, standards, and handbooks ............................................... 22.1.2 Other government documents, drawings, and publications...................... 2

2.2 Non-government publications.................................................................................. 2

3. DEFINITIONS.................................................................................................................... 3

4. OBJECTIVES, OVERVIEW, KEY CONCEPTS, AND CONVERSION............................... 94.1 Objectives of MIL-STD-498..................................................................................... 9

4.1.1 Merge DOD-STD-2167A and DOD-STD-7935A....................................... 9

4.1.2 Resolve issues identified in applying DOD-STD-2167A .......................... 104.1.3 Ensure compatibility with current DoD instructions, standards, andhandbooks............................................................................................... 11

4.2 Overview of MIL-STD-498...................................................................................... 124.2.1 Organization of MIL-STD-498.................................................................. 124 2 2 Overview of MIL STD 498's general requirements 13

8/7/2019 498GBOT

4/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page iv

4.3.13 Distinguishing between software quality assurance and softwareproduct evaluation................................................................................... 33

4.3.14 Application of configuration management to in-process work products... 344.3.15 Relationship to other related standards................................................... 354.3.16 Ordering the software via the CDRL (DD Form 1423) ............................. 354.3.17 Tailoring................................................................................................... 364.3.18 The importance of plans.......................................................................... 36

4.4 Converting to MIL-STD-498 from DOD-STD-2167A and DOD-STD-7935A........... 37

5. TAILORING AND APPLICATION GUIDANCE ................................................................. 41

5.1 Approval of MIL-STD-498....................................................................................... 415.2 Ways of applying MIL-STD-498 ............................................................................. 415.3 Information about tailoring...................................................................................... 42

5.3.1 What is tailoring....................................................................................... 425.3.2 Why tailor ................................................................................................ 425.3.3 When is tailoring performed..................................................................... 435.3.4 Who performs tailoring ............................................................................ 45

5.4 Tailoring and applying MIL-STD-498...................................................................... 465.4.1 Step 1: Determining the context of the software development .............. 465.4.2 Step 2: Determining the program strategy for the system ..................... 465.4.3 Step 3: Selecting a strategy for acquiring the software ......................... 475.4.4 Step 4: Selecting the software support concept .................................... 495.4.5 Step 5: Identifying types of software on the project............................... 55

5.4.6 Step 6: Defining the software builds ...................................................... 565.4.7 Step 7: Tailoring MIL-STD-498 for each build ....................................... 595.4.8 Step 8: Tailoring the DIDs as activity checklists .................................... 615.4.9 Step 9: Recording tailoring decisions in the Statement of Work............ 625.4.10 Step 10: Clarifying "shell requirements".................................................. 635.4.11 Step 11: Selecting deliverables .............................................................. 65

5.4.12 Step 12: Tailoring the DIDs for deliverables ........................................... 665.4.13 Step 13: Selecting the format of deliverables ......................................... 675.4.14 Step 14: Scheduling deliverables ........................................................... 695.4.15 Step 15: Preparing the CDRL (DD Form 1423) ...................................... 705.4.16 Step 16: Including SDP preparation in Instructions to Bidders ............... 715 4 17 Step 17: Evaluating Software Development Plans 72

8/7/2019 498GBOT

5/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page v

FIGURESFigure Page

1 Objectives of MIL-STD-498................................................................................... 92 Issues identified in applying DOD-STD-2167A...................................................... 103 The MIL-STD-498 package.................................................................................... 124 Organization of MIL-STD-498 ................................................................................ 125 Overview of MIL-STD-498's general requirements................................................. 136 Overview of MIL-STD-498's detailed requirements................................................ 147 The MIL-STD-498 DIDs.......................................................................................... 18

8 Overview of MIL-STD-498 DIDs and the resulting software products .................... 199 Players and agreements assumed by MIL-STD-498.............................................. 22

10 One possible mapping of MIL-STD-498 activities to multiple builds....................... 2411 Excessive documentation ...................................................................................... 2512 Role of DIDs and software products in MIL-STD-498............................................. 2613 Two types of systems handled by MIL-STD-498.................................................... 2714 Illustration of the use of quantitative measures...................................................... 2715 MIL-STD-498 provisions supporting modification, reuse, and reengineering ......... 2816 MIL-STD-498 provisions that promote software supportability ............................... 2917 Contrasting definitions of requirements and design ............................................... 3018 Flexibility in handling design entities, code entities, and files................................. 3119 Methodology independence of MIL-STD-498......................................................... 3220 Relationship of the terms software, computer program, and

computer database ................................................................................................ 3221 MIL-STD-498's use of objective and subjective criteria.......................................... 3322 Avoiding overlap of SQA with other evaluation/testing activities ............................ 3423 Tiering of standards ............................................................................................... 3524 The MIL-STD-498 plans ......................................................................................... 3625 Mapping of key terms............................................................................................. 37

26 Mapping of DOD-STD-7935A DIDs to MIL-STD-498 DIDs..................................... 3827 Mapping of DOD-STD-2167A DIDs to MIL-STD-498 DIDs..................................... 3928 Mapping of MIL-STD-498 DIDs to DOD-STD-2167A and

DOD-STD-7935A DIDs .......................................................................................... 4029 Ways of applying MIL-STD-498 ............................................................................. 4130 Overview of the tailoring process 42

8/7/2019 498GBOT

6/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page vi

45 Using the worksheets to record tailoring decisions ................................................ 5946 Process for tailoring the standard........................................................................... 6047 Relationship of tailoring decisions for the standard and DIDS ............................... 6148 Sample language for specifying tailoring in the Statement of Work ....................... 6249 MIL-STD-498's "shell requirements"....................................................................... 6350 Distinguishing between preparation and delivery of software products.................. 6551 Alternative "homes" for selected information......................................................... 6652 Combining software products into a single deliverable ......................................... 6753 Sample CDRL wording for combining deliverables ................................................ 6854 Sequential versus incremental/overlapping delivery of software products ............. 69

55 Examples of information that can be included in Block 16 ..................................... 7056 Requiring an SDP in proposals as well as after contract award............................. 7157 Ways of achieving visibility into the evolving software............................................ 7258 Ingredients for successful joint reviews.................................................................. 7359 Mapping between DOD-ST--2168 and MIL-STD-498............................................. 7860 Sample build planning and tailoring worksheet for MIL-STD-498........................... 8261 Sample build planning and tailoring worksheet for a DID....................................... 96

8/7/2019 498GBOT

7/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page vii

FOREWORD

1. This guidebook is available for use by all departments and agencies of the Department of

Defense (DoD) or any other government agency.

2. MIL-STD-498, Software Development and Documentation, identifies a set of software

development activities and defines the software products to be generated by those activities.

In order to use the standard effectively, all parties involved in a software development effort

need to understand the principles that underlie the standard. This guidebook is intended to

help the acquirer understand and apply MIL-STD-498, but, it can be useful to developers and

other parties.

3. This guidebook is the first of two guidebooks prepared by DoD for use with MIL-STD-498.

The two guidebooks are:

1) MIL-STD-498 Overview and Tailoring Guidebook. The first guidebook provides thefollowing:

Objectives of MIL-STD-498

Overview of the standard

Key concepts of the standard

Conversion guide

Tailoring and application guidance

2) MIL-STD-498 Application and Reference Guidebook. The second guidebookprovides the following:

(PDF i ) MIL STD 498 O i d T il i G id b k P iii

8/7/2019 498GBOT

8/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page viii

EXECUTIVE OVERVIEW

MIL-STD-498 is a standard for the software development process. It is applicable throughout

the system life cycle. It establishes uniform requirements for acquiring, developing, modifying,and documenting software. It defines standard terminology and establishes activities, tasks,

and products for a software development or maintenance project. It can be applied to any type

of software, including application software, operating system software, the software portion of

firmware, reusable software, and software employed to develop deliverable software.

The activities in the standard form a comprehensive set, sufficient for a large, complex project,

but scalable and adaptable to suit the needs of small ones. The standard is meant to be

tailored as needed for each project by specifying in the contract which provisions of the

standard apply.

The standard is intended to be responsive to the rapidly evolving software discipline. It is

independent of any particular methodology, ensuring the acquirer's right to specify the product

and the developer's right to be technologically creative and innovative. In particular:

The activities and tasks in the standard tell what to do, not how to do it. For example,the standard requires the developer to perform architectural design, but does notrequire use of the object-oriented design method.

The standard does not specify or encourage any software life cycle model (Waterfall,Incremental, Evolutionary, Spiral, etc.). Instead, the standard provides the buildingblocks needed to carry out the life cycle model selected for a software project.

The standard does not specify or depend on any design or programming language. Itis meant to be applicable regardless of the language used.

The standard provides flexibility regarding documentation:

(PDF i ) MIL STD 498 O i d T il i G id b k P i

8/7/2019 498GBOT

9/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page ix

The standard provides a performance-based distinction between requirements for aproduct and design of a product. A requirement is a characteristic that a system orsoftware item is required to possess to be acceptable to the acquirer, while design isa characteristic that the acquirer is willing to leave up to the developer. Thisemphasis on required performance can allow a developer to provide quality productsat reduced costs when unique product solutions are not required.

MIL-STD-498 specifically removes key problems found in the use of predecessor standards.

MIL-STD-498:

a. Is usable with any development strategy. MIL-STD-498 has been structured to betteraccommodate development models other than the traditional "Waterfall" model; toavoid time-oriented dependencies and implications; to provide alternatives to formalreviews (that can force a Waterfall development model); and to explain how to applythe standard across multiple builds or iterations.

b. Is usable with any development methods. To improve compatibility withobject-oriented and other methods not using functional decomposition, MIL-STD-498allows the developer to define the design and implementation structures, and to usethat structure in the documentation.

c. Is compatible with CASE tools. MIL-STD-498 recognizes that much of the significantwork on a software development project does not involve writing documents. Thestandard: (1) separates planning and engineering activities from preparation ofdeliverables to make it easier to call for one without the other; (2) provides languagethat permits the recording of project information in forms other than traditionaldocuments, such as CASE tools; (3) acknowledges data in CASE tools as asubstitute for traditional documents; and (4) provides guidance to preventunnecessary deliverables.

d. Provides requirements for software reuse. MIL-STD-498 recognizes that manyprojects incorporate or are based on reusable software. To provide clearerrequirements when this is the case, the standard: (1) identifies criteria for usein evaluating reusable software, and (2) provides guidance on interpreting

(PDF version) MIL STD 498 Overview and Tailoring Guidebook Page 10

8/7/2019 498GBOT

10/109

(PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page 10

PARTICIPANTS

The MIL-STD-498 Overview and Tailoring Guidebook was sponsored by the Joint Logistics

Commanders (JLC) Joint Policy Coordinating Group on Computer Resource Management

(JPCG-CRM), and was developed by Logicon under the direction of the MIL-STD-498

Harmonization Working Group (HWG). At the time this guidebook was completed, the HWG

had the following membership:

Dr. Raghu Singh, SPAWAR, HWG Chairman

Norma Stopyra, SPAWAR, MIL-STD-498 Guidebook Product Manager

Paul Anderson, SPAWAR

Larry Baker, DSMC

Perry DeWeese, CODSIA

C. "Jay" Ferguson (NSA)

Robert Gagnon, OASD (ES)

Susan Gardner, FAA

Joseph Gianuzzi, SEI

Robert Hegland, USAISSC

Alan Huguley, DMA

Tim Janes, MoD, UK

Capt. Jonathan Liles, HQ AFMC

Donna McCloud, HQ DLA

LTC. Dixie McNeme, USA

Fred Moxley, DISA

Glenn Plonk, NSA

Linda Sheets, AFMC

Mary Synder, USN

Guidebook Developers:

Myrna Olson

Stuart Campbell

Dorothy Kuckuck (PDF version) MIL STD 498 Overview and Tailoring Guidebook Page 1

8/7/2019 498GBOT

11/109


1. SCOPE

1.1 Purpose. The purpose of this guidebook is to:

a. Describe the objectives of MIL-STD-498

b. Provide an overview of the standard and explain its key concepts

c. Provide a conversion guide from DOD-STD-2167A and DOD-STD-7935A

d. Provide guidance on applying MIL-STD-498

1.2 Application of the guidebook. This guidebook is intended to be applied as follows.

1.2.1 Intended audience. This guidebook is addressed to the acquirer, that is, to an

organization that procures software products for itself or for another organization. It can alsobe used by developers and other parties, but its focus is on helping the acquirer understand

and apply MIL-STD-498.

1.2.2 Use on contracts. This guidebook is not intended to be included in procurements or

contracts as a contractually binding document. It is meant to provide guidance only.

1.3 Organization of the guidebook. This guidebook is organized into five major sections.

a. Section 1 defines the purpose, application, and organization of the guidebook.

b. Section 2 provides information about documents mentioned in the guidebook.c. Section 3 defines key terms used in the guidebook.

d. Section 4 describes the objectives of MIL-STD-498, provides an overview of the

standard explains its key concepts and provides a conversion guide from (PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page 2

8/7/2019 498GBOT

12/109


2. DOCUMENTS MENTIONED IN THIS GUIDEBOOK

This section identifies documents mentioned in sections 3, 4 and 5 of this guidebook.

2.1 Government documents.

2.1.1 Specifications, standards, and handbooks. The following specifications, standards,

and handbooks are mentioned in this guidebook. Unless otherwise specified, the issues of

these documents are those listed in the Department of Defense Index of Specifications and

Standards (DoDISS) and supplements thereto.

SPECIFICATIONS: None

STANDARDS, MILITARY

MIL-STD-498 - Software Development and Documentation

DOD-STD-1703* - Software Product Standards

DOD-STD-2167A* - Defense System Software Development

DOD-STD-7935A* - DoD Automated Information Systems (AIS) Documentation

Standards

DOD-STD-2168** - Defense System Software Quality Program

* Superseded by MIL-STD-498

** Discussed in this guidebook to aid in the transition to MIL-STD-498

HANDBOOKS, MILITARY: None

Unless otherwise indicated copies of federal and military specifications standards and (PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page 3

8/7/2019 498GBOT

13/109


3. DEFINITIONS

The definitions below are the same as those in MIL-STD-498. They are provided here to aid in

using this guidebook. A list of acronyms used in this guidebook can be found inAppendix A.

3.1 Acceptance. An action by an authorized representative of the acquirer by which the

acquirer assumes ownership of software products as partial or complete performance of a

contract.

3.2 Acquirer. An organization that procures software products for itself or another

organization.

3.3 Approval. Written notification by an authorized representative of the acquirer that a

developer's plans, design, or other aspects of the project appear to be sound and can be used

as the basis for further work. Such approval does not shift responsibility from the developer to

meet contractual requirements.

3.4 Architecture. The organizational structure of a system or CSCI, identifying its

components, their interfaces, and a concept of execution among them.

3.5 Associate developer. An organization that is neither prime contractor nor

subcontractor to the developer, but who has a development role on the same or related system

or project.

3.6 Behavioral design. The design of how an overall system or CSCI will behave, from a

user's point of view, in meeting its requirements, ignoring the internal implementation of the

system or CSCI This design contrasts with architectural design which identifies the internal (PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page 4

8/7/2019 498GBOT

14/109


3.9 Computer hardware. Devices capable of accepting and storing computer data,

executing a systematic sequence of operations on computer data, or producing control

outputs. Such devices can perform substantial interpretation, computation, communication,

control, or other logical functions.

3.10 Computer program. A combination of computer instructions and data definitions that

enable computer hardware to perform computational or control functions.

3.11 Computer software. See software.

3.12 Computer Software Configuration Item (CSCI). An aggregation of software that

satisfies an end use function and is designated for separate configuration management by the

acquirer. CSCIs are selected based on tradeoffs among software function, size, host or target

computers, developer, support concept, plans for reuse, criticality, interface considerations,

need to be separately documented and controlled, and other factors.

3.13 Configuration Item. An aggregation of hardware, software, or both that satisfies an

end use function and is designated for separate configuration management by the acquirer.

3.14 Database. A collection of related data stored in one or more computerized files in a

manner that can be accessed by users or computer programs via a database management

system.

3.15 Database management system. An integrated set of computer programs that provide

the capabilities needed to establish, modify, make available, and maintain the integrity of a

database.


8/7/2019 498GBOT

15/109

( ) g g

3.18 Developer. An organization that develops software products ("develops" may include

new development, modification, reuse, reengineering, maintenance, or any other activity that

results in software products). The developer may be a contractor or a government agency.

3.19 Document/documentation. A collection of data, regardless of the medium on which it

is recorded, that generally has permanence and can be read by humans or machines.

3.20 Evaluation. The process of determining whether an item or activity meets specified

criteria.

3.21 Firmware. The combination of a hardware device and computer instructions and/or

computer data that reside as read-only software on the hardware device.

3.22 Hardware Configuration Item (HWCI). An aggregation of hardware that satisfies an

end use function and is designated for separate configuration management by the acquirer.

3.23 Independent verification and validation (IV&V). Systematic evaluation of software

products and activities by an agency that is not responsible for developing the product or

performing the activity being evaluated. IV&V is not within the scope of this standard.

3.24 Interface. In software development, a relationship among two or more entities (such

as CSCI-CSCI, CSCI-HWCI, CSCI-user, or software unit-software unit) in which the entities

share, provide, or exchange data. An interface is not a CSCI, software unit, or other system

component; it is a relationship among them.

3.25 Joint review. A process or meeting involving representatives of both the acquirer and

the developer during which project status software products and/or project issues are (PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page 6

8/7/2019 498GBOT

16/109

( ) g g

3.29 Reengineering. The process of examining and altering an existing system to

reconstitute it in a new form. May include reverse engineering (analyzing a system and

producing a representation at a higher level of abstraction, such as design from code),

restructuring (transforming a system from one representation to another at the same level ofabstraction), redocumentation (analyzing a system and producing user or support

documentation), forward engineering (using software products derived from an existing

system, together with new requirements, to produce a new system), retargeting (transforming a

system to install it on a different target system), and translation (transforming source code from

one language to another or from one version of a language to another).

3.30 Requirement. (1) A characteristic that a system or CSCI must possess in order to be

acceptable to the acquirer. (2) A mandatory statement in this standard or another portion of

the contract.

3.31 Reusable software product. A software product developed for one use but having

other uses, or one developed specifically to be usable on multiple projects or in multiple roles

on one project. Examples include, but are not limited to, commercial off-the-shelf software

products, acquirer-furnished software products, software products in reuse libraries, and

preexisting developer software products. Each use may include all or part of the software

product and may involve its modification. This term can be applied to any software product (for

example, requirements, architectures, etc.), not just to software itself.

3.32 Software. Computer programs and computer databases. Note: Although some

definitions of software include documentation, MIL-STD-498 limits the definition to computer

programs and computer databases in accordance with Defense Federal Acquisition Regulation

Supplement 227.401.


8/7/2019 498GBOT

17/109

3.35 Software development library (SDL). A controlled collection of software,

documentation, other intermediate and final software products, and associated tools and

procedures used to facilitate the orderly development and subsequent support of software.

3.36 Software development process. An organized set of activities performed to translate

user needs into software products.

3.37 Software engineering. In general usage, a synonym for software development. As

used in this standard, a subset of software development consisting of all activities except

qualification testing. The standard makes this distinction for the sole purpose of giving

separate names to the software engineering and software test environments.

3.38 Software engineering environment. The facilities, hardware, software, firmware,

procedures, and documentation needed to perform software engineering. Elements may

include but are not limited to computer-aided software engineering (CASE) tools, compilers,

assemblers, linkers, loaders, operating systems, debuggers, simulators, emulators,

documentation tools, and database management systems.

3.39 Software product. Software or associated information created, modified, or

incorporated to satisfy a contract. Examples include plans, requirements, design, code,

databases, test information, and manuals.

3.40 Software quality. The ability of software to satisfy its specified requirements.

3.41 Software support. The set of activities that takes place to ensure that software

installed for operational use continues to perform as intended and fulfill its intended role in

system operation Software support includes software maintenance aid to users and related (PDF version) MIL-STD-498 Overview and Tailoring Guidebook Page 8

8/7/2019 498GBOT

18/109

3.44 Software transition. The set of activities that enables responsibility for software

development to pass from one organization, usually the organization that performs initial

software development, to another, usually the organization that will perform software support.

3.45 Software unit. An element in the design of a CSCI; for example, a major subdivision

of a CSCI, a component of that subdivision, a class, object, module, function, routine, or

database. Software units may occur at different levels of a hierarchy and may consist of other

software units. Software units in the design may or may not have a one-to-one relationship

with the code and data entities (routines, procedures, databases, data files, etc.) that

implement them or with the computer files containing those entities.

3.46 Support (of software). See software support.

3.47 Transition (of software). See software transition.


8/7/2019 498GBOT

19/109

4. OBJECTIVES, OVERVIEW, KEY CONCEPTS, AND CONVERSION

This section describes the objectives of MIL-STD-498, provides an overview of the standard,

explains its key concepts, and provides a conversion guide from DOD-STD-2167A andDOD-STD-7935A.

4.1 Objectives of MIL-STD-498. MIL-STD-498 was developed with three primary

objectives. These objectives are illustrated inFigure 1 and discussed in the following

paragraphs.

Resolve DOD-STD-2167A issues raised in applying Merge DOD-STD-2167A

MIL-STD-498 Incorporate DOD-STD-7935A changes in DoD Directives, Instructions, etc.

FIGURE 1. Objectives of MIL-STD-498.

4.1.1 Merge DOD-STD-2167A and DOD-STD-7935A.

a. Former standards. Before the development of MIL-STD-498, there were two primary

software development and documentation standards in the DoD:

1) DOD-STD-2167A, Defense System Software Development. This standard was

used for mission critical systems. It defined a software development process and

had 16 Data Item Descriptions (DIDs) defining documentation.


8/7/2019 498GBOT

20/109

c. Relationship to DOD-STD-1703. One of the participants in the MIL-STD-498 project

was the National Security Agency (NSA). During the project, NSA decided to adopt

MIL-STD-498 in place of its software development standard DOD-STD-1703 (NS),

Software Product Standards. As a result, DOD-STD-1703, though not merged withDOD-STD-2167A and DOD-STD-7935A, was superseded along with them.

4.1.2 Resolve issues identified in applying DOD-STD-2167A.

a. Issues raised. During the time that DOD-STD-2167A was in use, a number of issueswere identified regarding its use. Figure 2 presents the primary issues.

ISSUES IDENTIFIED IN APPLYING DOD-STD-2167A

1) Improve compatibility with Incremental and Evolutionary development models

2) Decrease dependence on formal reviews and audits

3) Decrease emphasis on preparing documentation

4) Improve compatibility with computer-aided software engineering (CASE) tools

5) Improve links to systems engineering

6) Include the use of software management indicators7) Improve coverage of modification, reuse, and reengineering

8) Increase emphasis on software supportability

9) Provide a clearer distinction between requirements and design

10) Improve compatibility with non-hierarchical design methods

11) Improve coverage of database development

12) Improve the criteria used for software product evaluations

13) Eliminate confusion between software quality assurance and software product evaluation

14) Extend configuration management concepts to in-process work products

15) Clarify relationships to other standards


8/7/2019 498GBOT

21/109

4.1.3 Ensure compatibility with current DoD instructions, standards, and handbooks.

a. Changing environment. Between the time that DOD-STD-2167A and

DOD-STD-7935A were issued and the time that MIL-STD-498 was begun, significantchanges were made in DoD directives, instructions, standards, and handbooks

affecting software development. Key documents developed or undergoing change at

that time were DoDI 5000.2 and DoDI 8120.2 as well as standards and handbooks on

systems engineering, configuration management, and software support.

b. Ensuring compatibility. This changing environment for software development

resulted in the third objective for MIL-STD-498: ensure that the merged standard would

be compatible with the changes being made to these documents.


8/7/2019 498GBOT

22/109

4.2 Overview of MIL-STD-498. The MIL-STD-498 package consists of the standard and

22 Data Item Descriptions (DIDs), as illustrated in Figure 3. The paragraphs that follow provide

an overview of the standard and its DIDs.

. . .

MIL-STD-498

22

Data Item

Descriptions

(DIDs)

FIGURE 3. The MIL-STD-498 package.

4.2.1 Organization of MIL-STD-498. Figure 4 shows the organization of MIL-STD-498. Its

requirements are presented in Sections 4 and 5 of the standard. The remainder of the

standard provides details for selected requirements and associated material such as definitions

and application guidance.

ORGANIZATION OF MIL-STD-498

Section 1: Scope (including purpose and applicability)

Section 2: Referenced Documents

Section 3: Definitions

Section 4: General Requirements

Section 5: Detailed Requirements

Appendixes

Appendix A: Acronyms

Appendix B: Interpreting MIL-STD-498 for Incorporation of Reusable Software Products

Appendix C: Category and Priority Classifications for Problem Reporting

http://498-std.pdf/http://498-std.pdf/http://498-std.pdf/http://498-std.pdf/

8/7/2019 498GBOT

23/109

4.2.2 Overview of MIL-STD-498's general requirements. Figure 5 provides an overview of

MIL-STD-498's general requirements, presented in Section 4 of the standard. These

requirements apply across all detailed requirements presented in Section 5 of the standard.

OVERVIEW OF MIL-STD-498 GENERAL REQUIREMENTS

4.1 Establish a software development process consistent with contract requirements

4.2 General requirements for software development

- Use systematic, documented methods

- Develop and apply standards for representing requirements, design, code, and test

information

- Reuse software products as appropriate:

- Evaluate reusable software products for use in fulfilling contract requirements; incorporate

those that meet the criteria in the Software Development Plan

- Identify opportunities for developing software products for reuse; notify the acquirer of

those that have cost benefits and are consistent with program objectives

- Establish and apply strategies for handling critical requirements, such as those with safety,

security, or privacy implications

- Analyze and fulfill the computer hardware resource utilization requirements (such as memory

reserves)

http://498-std.pdf/http://498-std.pdf/http://498-std.pdf/http://498-std.pdf/

8/7/2019 498GBOT

24/109

OVERVIEW OF MIL-STD-498 DETAILED REQUIREMENTS

5.1 Project planning and oversight- Plan the software development effort

- Plan for computer software configuration item (CSCI) qualification testing

- Participate in planning for system testing

- Plan for installing the software at user sites

- Plan for transitioning the software to the support agency

- Follow approved plans; conduct management reviews; get approval for updates

5.2 Establishing a software development environment

- Establish, control, and maintain:

- A software engineering environment

- A software test environment- A software development library

- Software development files

- Use non-deliverable software only if operation/support of the deliverable software do not

depend on it or if the acquirer has or can obtain the same software

5.3 System requirements analysis

- Analyze user input provided by the acquirer

- Participate in defining and recording the system operational concept

- Participate in defining and recording system requirements

5.4 System design- Participate in defining and recording the system-wide design decisions

- Participate in defining and recording the system architectural design


8/7/2019 498GBOT

25/109

OVERVIEW OF MIL-STD-498 DETAILED REQUIREMENTS - (continued)

5.7 Software implementation and unit testing- Develop and record software corresponding to each software unit

- Prepare test cases, procedures, and data for unit testing

- Perform unit testing

- Revise and retest as needed

- Analyze and record test results

5.8 Unit integration and testing

- Prepare test cases, procedures, and data for unit integration and testing

- Perform unit integration and testing



5.9 CSCI qualification testing

- Assign responsibility to persons who did not perform detailed design or implementation

- Include testing on the target computer system or an approved alternative

- Prepare test cases, procedures, and data for CSCI qualification testing

- Dry run the test cases if testing is to be witnessed by the acquirer

- Perform CSCI qualification testing



5.10 CSCI/HWCI integration and testing- Prepare test cases, procedures, and data for CSCI/HWCI integration and testing

- Perform CSCI/HWCI integration and testing



8/7/2019 498GBOT

26/109


5.12 Preparing for software use- Prepare the executable software for user sites

- Identify and record the exact version of software to be sent to each site

- Prepare information needed for:

- Hands-on use of the software

- Submitting (batch) inputs and interpreting outputs

- Operating the software in software centers or networked environments

- Operating the computers

- Install at user sites; provide training and other assistance as required

5.13 Preparing for software transition

- Prepare the executable software for the support site- Prepare the source files for the support site

- Identify and record the exact version of software to be sent to the support site

- Update the CSCI design descriptions and prepare other information needed for support

- Update the system design descriptions

- Prepare information needed to:

- Program the host and target computers

- Program/reprogram the firmware devices

- Install the software at the support site; demonstrate that it can be regenerated from source

files; provide training and other assistance as required

5.14 Software configuration management

- Identify all entities to be controlled during development: computer files, documents, other

software products, and elements of the software environments

- Establish and implement procedures for controlling each entity

Prepare/maintain records of the stat s of all entities nder project le el or higher control


8/7/2019 498GBOT

27/109


5.16 Software quality assurance- Perform on-going evaluations to assure that:

- Activities required by the contract or described in the software development plan (SDP) are

being performed in accordance with the contract and SDP

- Required software products exist and have undergone software product evaluation, testing,

and corrective action as required by the standard and contract

- Prepare records of the evaluations

- Assign responsibility to persons other than those who developed the software product,

performed the activity, or are responsible for the product or activity

5.17 Corrective action

- Prepare problem/change reports for problems found in:- Software products under project-level or higher control

- Activities required by the contract or described in the software development plan

- Implement a corrective action system for handling these problems

5.18 Joint technical and management reviews

- Plan and participate in joint (acquirer/developer) technical reviews

- Plan and participate in joint management reviews

5.19 Other activities

- Identify project risks; develop/implement strategies to manage them

- Identify and apply software management indicators- Comply with the security and privacy requirements in the contract

- Include in subcontracts all requirements necessary to ensure that software products are

developed in accordance with the prime contract


8/7/2019 498GBOT

28/109

4.2.4 Overview of the MIL-STD-498 DIDs. MIL-STD-498 provides 22 DIDs from which an

appropriate set can be selected for a project. Figure 7 identifies the DIDs. Figure 8 provides

an overview of each DID and the resulting software product. Section4.4 shows the

relationship of the MIL-STD-498 DIDs to those for DOD-STD-2167A and DOD-STD-7935A.Section 6.2 of MIL-STD-498 provides a cross-reference to associated paragraphs of the

standard.

MIL-STD-498 DID Resulting Software Product

Software Development Plan (SDP) A plan for performing the software development

Software Test Plan (STP) A plan for conducting qualification testing

Software Installation Plan (SIP) A plan for installing the software at user sites

Software Transition Plan (STrP) A plan for transitioning to the support agency

Operational Concept Description (OCD) The operational concept for the system

System/Subsystem Specification (SSS) The requirements to be met by the system

Software Requirements Specification (SRS) The requirements to be met by a CSCI

Interface Requirements Specification (IRS) The requirements for one or more interfaces

System/Subsystem Design Description (SSDD) The design of the systemSoftware Design Description (SDD) The design of a CSCI

Interface Design Description (IDD) The design of one or more interfaces

Database Design Description (DBDD) The design of a database

Software Test Description (STD) Test cases/procedures for qualification testing

Software Test Report (STR) Test results of qualification testing

Software Product Specification (SPS) The executable software, the source files, andinformation to be used for support
http://498-std.pdf/http://498-std.pdf/

8/7/2019 498GBOT

29/109

8/7/2019 498GBOT

30/109

8/7/2019 498GBOT

31/109


8/7/2019 498GBOT

32/109

4.3 Key concepts of MIL-STD-498. To apply MIL-STD-498 effectively, it is important to

understand the key concepts embodied in the standard. The paragraphs that follow present

these key concepts.

4.3.1 Players and agreements assumed by MIL-STD-498. Figure 9 illustrates the players and

agreements assumed by MIL-STD-498. The paragraphs that follow explain each term.

Statement

User

Acquirer

Support

of

Agency

Work

(Tasking)

Developer Contract

Contract Line Item

(Agreement)

Number (CLIN)

----- OR -----

Contract Data

Requirements List

(CDRL)

Subcontractors

(Deliverables)

FIGURE 9. Players and agreements assumed by MIL-STD-498.

a. Players. MIL-STD-498 is written in terms of the following players.

1) Acquirer: an organization that procures software products for itself or another

organization. The acquirer may be a government agency or a prime contractor.

2) Developer: an organization that develops software products ("develops" may includenew development, modification, reuse, reengineering, or any other activity that results

in software products). The developer may be a contractor or a government agency.


b. Agreements. MIL-STD-498 is written in terms of the following agreements:

8/7/2019 498GBOT

33/109

b. Agreements. MIL STD 498 is written in terms of the following agreements:

1) Contract: the agreement between the acquirer and developer. Between government

agencies, the contract may take the form of a Memorandum of Agreement or other

form of tasking.

2) Statement of Work (SOW): that portion of the contract that lays out the tasks to be

performed by the developer.

3) Contract Line Item Number (CLIN): that portion of the contract that identifies

deliverable products.

4) Contract Data Requirements List (CDRL): that portion of the contract that identifies

deliverable software products.

c. Project-specific interpretation. Depending upon circumstances, two or more of the

players identified above may be the same; the players or agreements may have different

names; or there may be other variations from the framework just described. It is important

to sort out how these terms apply to each individual situation so the standard can be

interpreted appropriately.

4.3.2 Accommodating Incremental and Evolutionary development.

a. Program strategies. Both DoDI 5000.2 and DoDI 8120.2 define multiple program

strategies for acquiring systems and software. Included are "Grand Design," "Incremental"

(also called "Preplanned Product Improvement"), and "Evolutionary" strategies. A key

concept of MIL-STD-498 is accommodating each of these strategies.


8/7/2019 498GBOT

34/109

ActivityBuilds

Build 1 Build 2 Build 3 Build 4

5.1 Project planning and oversight x x x x

5.2 Establishing a software development environment x x x x

5.3 System requirements analysis x x

5.4 System design x x x

5.5 Software requirements analysis x x x x

5.6 Software design x x x x

5.7 Software implementation and unit testing x x x x

5.8 Unit integration and testing x x x x

5.9 CSCI qualification testing x x x

5.10 CSCI/HWCI integration and testing x x x

5.11 System qualification testing x x

5.12 Preparing for software use x x x x

5.13 Preparing for software transition x

Integral processes:

5.14 Software configuration management x x x x

5.15 Software product evaluation x x x x

5.16 Software quality assurance x x x x

5.17 Corrective action x x x x

5.18 Joint technical and management reviews x x x x

5.19 Other activities x x x x

FIGURE 10 O ibl i f MIL STD 498 ti iti t lti l b ild


b. MIL-STD-498's joint reviews. Instead of formal reviews and audits, MIL-STD-498 calls

8/7/2019 498GBOT

35/109

j

for more frequent, low-key joint (acquirer/developer) technical and management reviews,

focusing on natural work products rather than view-graphs or other specially prepared

materials. These reviews include informal discussions of status, ideas, approaches, risks,

etc. The idea of these reviews is ongoing communication between the acquirer and

developer with minimum time wasted. Appendix F in MIL-STD-498 suggests candidate

reviews to hold.

c. Relationship to formal reviews and audits. MIL-STD-498's joint technical and manage-

ment reviews are designed to provide all of the coordination needed between the

developer and the acquirer. Formal reviews may be used to supplement the joint reviews

if so desired, but they should focus on major issues raised at the joint reviews rather than

repeating the details covered there.

4.3.4 Decreased emphasis on documentation and greater compatibility with CASE tools.

a. Document-driven software development. A frequent

complaint about software development under military

standards is that it is document driven. This concern is

illustrated in Figure 11. Rather than focusing on the realwork to be done, the developer must generate an endless

series of documents, some of which have little to do with

getting the job done. The developer may have to translate

real work products, such as data in computer-aided

software engineering (CASE) tools, into paper documentsor translate work products from the format in which work is

being done to an artificial format imposed by Data Item

Descriptions (DIDs).

FIGURE 11.Excessive documentation.


2) Focus on natural work projects versus deliverables. MIL-STD-498 distinguishes
http://498-std.pdf/http://498-std.pdf/

8/7/2019 498GBOT

36/109

between the planning and engineering work that are the "real work" of a project and

the activity of preparing a deliverable. This point may seem the same as item (1) just

above, but is not. Item (1) is about allowing the developer to record project

information in the most natural form, for example, in a CASE tool versus a paper

document. Item (2) is about not making work products, whatever their form,

deliverable without good reason. In the past, acquirers often thought that the way to

make the developer do the work was to require deliverables containing evidence of

the work (the "homework" approach to acquisition management). But preparing

information for delivery takes extra time and should not be required without good

reason. MIL-STD-498 requires the work to take place, regardless of whether the

results are made deliverable, and gives the acquirer access to the results in the

developer's facility. When deliverables are needed, they are called for in the CDRL or

in contract line item numbers (CLINs).

3) Use of the DIDs as checklists. Many of the activities in MIL-STD-498 rely on DIDs to

fully define them. For example, the activity of preparing a Software Development Plan

(SDP) consists of defining and recording all information called for by the Software

Development Plan DID. This requirement applies regardless of whether the SDP is in

the form of a document and regardless of whether the resulting plan is deliverable.

The DID is used as a checklist of information to be defined in carrying out the required

activity. This is a new role for DIDs.Figure 12 illustrates the role of DIDs and software

products in MIL-STD-498, emphasizing the distinction made between natural work

products, the form in which they reside, and their status as deliverables or

non-deliverables. If the DID is used only as a checklist and the resulting softwareproduct is not deliverable, the DID is not cited in the CDRL.


4.3.5 Improved links to systems engineering.

8/7/2019 498GBOT

37/109

a. Two types of systems. A key aspect of the merger of DOD-STD-2167A and

DOD-STD-7935A was that the resulting standard had to cover two types of systems,

illustrated in Figure 13: (1) hardware-software systems (such as radar systems) for which

the standard covers only the software portion, and (2) software systems (such as payroll

systems) for which the standard governs overall system development.

Hardware/Software Software

System

System

Hardware Software Hardware Software Software Software

FIGURE 13. Two types of systems handled by MIL-STD-498.

b. MIL-STD-498's "participate" concept. MIL-STD-498 covers this duality by including

system-level activities, requiring the developer to "participate" in them, and stating that:

1) If the software to be developed is part of a hardware-software system for which the

standard covers only the software portion, the term "participate" is to be interpreted as

"take part in, as described in the Software Development Plan," and 2) If the software

(possibly with its computers) is considered to constitute a system, the term "participate" is

to be interpreted as "be responsible for." This use of "participate" covers both cases.

4.3.6 Use of software management indicators.

a. DoD emphasis on quantitative measures. There is increasing emphasis in DoD on

quantitative measurement of software progress, size, quality, and other attributes.

Figure 14 illustrates this type of measurement The idea behind these initiatives is that


b. MIL-STD-498's software management indicators. MIL-STD-498 takes a cautious step

8/7/2019 498GBOT

38/109

into this area by requiring the developer to define and apply software management

indicators and by providing a set of candidate management indicators to serve as a

starting point. It is left to the developer to propose in the Software Development Plan the

indicators to be used, the data to be collected, the approach to interpreting the data, and

the reporting approach. The acquirer can provide feedback on the proposed approach

when reviewing the Software Development Plan.

4.3.7 Improved coverage of modification, reuse, and reengineering.

a. DoD initiatives. There is increasing emphasis in DoD on meeting user needs by

modifying, reusing, and reengineering existing software products rather than developing

everything "from scratch." These initiatives apply not just to the software itself, but to

associated software products such as architectures and design.

b. MIL-STD-498's support for these initiatives. Figure 15 summarizes the provisions

incorporated into MIL-STD-498 to accommodate these approaches.

PROVISIONS SUPPORTING SOFTWARE MODIFICATION, REUSE, AND REENGINEERING

MIL-STD-498:

1) States that each activity in the standard may be performed by modifying, reusing, or

reengineering existing items, as well as by developing something new.

2) Requires the developer to identify and evaluate reusable software products for use infulfilling contract requirements, and to incorporate those that meet the criteria

established for the project.


4.3.8 Increased emphasis on software supportability.

8/7/2019 498GBOT

39/109

a. Importance of supportability. Study after study has shown that over 75% of software's

life cycle cost occurs after initial delivery. These figures emphasize the importance of

making software supportable.

b. Effect of the DoD support model. In many DoD organizations, the approach to software

support is to transition the software from the initial developer to a completely different

organization for software support. This approach, potentially involving a complete change

of players, makes supportability of the software even more critical.

c. MIL-STD-498's approach to supportability. Supportability is the driving force behind

many of MIL-STD-498's requirements. Figure 16 summarizes key provisions.

PROVISIONS THAT PROMOTE SOFTWARE SUPPORTABILITY

MIL-STD-498 requires the developer to:

1) Identify all resources used or generated during the development that will be needed by

the support agency.

2) Prepare a Software Transition Plan that identifies these resources and tells how

deliverable items will be transitioned to the support agency.

3) Demonstrate that the delivered software can be supported given these resources.

4) Define and record the behavioral design as well the architectural and detailed designs,

detailing the behavior selected to meet system and CSCI requirements.

8/7/2019 498GBOT

40/109


3) Keeping design decisions the developer's prerogative. Design decisions made during

th j t if t d t j i t i i l d d i d li bl d i

8/7/2019 498GBOT

41/109

the project, even if presented at joint reviews or included in deliverable design

descriptions, remain at the discretion of the developer. They need to be covered in

developer-internal testing, but they are subject to change and need not be

demonstrated in qualification testing. If the acquirer decides that a design decision

should be a requirement, it is necessary to take appropriate action, possibly involving

contractual measures and additional cost to revise specifications, revise planning for

qualification tests, and perform additional qualification tests.

4.3.10 Compatibility with non-hierarchical methods.

a. Top-down functional decomposition. Although not intended to do so, DOD-STD-2167A

has been perceived to favor top-down functional decomposition over other development

methods. Most frequently cited are DOD-STD-2167A's requirements regarding software

architecture, in which CSCIs are decomposed into computer software components(CSCs), which are decomposed into other CSCs, which are finally decomposed into

computer software units (CSUs), which are associated with physical code entities. While

some users of DOD-STD-2167A have had no problem with this framework, others have

found it inhibiting to their preferred methods.

b. MIL-STD-498's software architecture. MIL-STD-498 redefines software architecture by

requiring simply that CSCIs be decomposed into software units, which may or may not be

related to each other in a hierarchical manner. A software unit is any element in the

design of a CSCI, for example, a major subdivision of a CSCI, a component of that

subdivision, a class, object, module, function, routine, or database. Software units may

occur at different levels of a hierarchy and may consist of other software units.

MIL-STD-498 further acknowledges that software units in the design may or may not have

a one-to-one relationship with the code and data entities that implement them or with the

fil i i h i i Thi li i f f i d


c. Methodology independence. It is MIL-STD-498's goal to neither encourage nor preclude

ti l ft d l m t m th d l A h i Fi 19 th t d d

8/7/2019 498GBOT

42/109

any particular software development methodology. As shown inFigure 19, the standard

lays out a set of activities that must be accomplished and defines a set of software

products that must be produced, but leaves it to the developer to propose in the Software

Development Plan how those activities will be performed and how the products will be

produced. The acquirer has an opportunity to react to the proposed methods when

reviewing the Software Development Plan.

MIL-STD-498 SW Development Plan

-------- -------- --------

-------- -------- -------

------- -------

--------

-------

--------

-------

--------

--------

Requirement stating Developer's plan stating

WHAT must be done HOW it will be done

FIGURE 19. Methodology independence of MIL-STD-498.

4.3.11 Improved coverage of database development.

a. Role of databases. Databases are crucial to automated information systems. They may

not be used at all in weapon systems. A significant issue that arose in merging

DOD-STD-2167A and DOD-STD-7935A was making sure that database development was

handled adequately.

b. MIL-STD-498's approach to databases. MIL-STD-498 takes an approach consistent

with the Defense Federal Acquisition Regulation Supplement, by defining software as

computer programs and computer databases. Figure 20 illustrates this relationship.

Following this approach, MIL-STD-498 takes databases into account throughout the

software development process. Requirements definition includes defining database


4.3.12 Improved criteria for software product evaluations.

8/7/2019 498GBOT

43/109

a. Objective versus subjective criteria. A significant problem in specifying criteria for

software product evaluations is that some of the most important criteria are subjective. For

example, most people would agree that a requirement specification should be

understandable and feasible, but there are no objective definitions for these criteria.

Concern about objectivity led to the deletion of all subjective criteria from

DOD-STD-2167A. The result was a set of objective but incomplete criteria that was less

than satisfactory.

b. MIL-STD-498's criteria. MIL-STD-498 handles this problem by including subjective

criteria such as understandability and feasibility, defining them as clearly as possible,

acknowledging that they are subjective, and stating that, because of their subjectivity, the

requirement is not to prove that a software product meets the criteria but to perform an

evaluation using the criteria and to identify possible problems for discussion andresolution. This explicit handling of subjective criteria, illustrated inFigure 21, was

accepted by reviewers and provides more meaningful software product evaluations.

Objective Software Product

criteria

--------

--------

Possible

--------

--------

problems for

-------- discussion and

Subjective

-------- -------- resolution

criteria

--------

--------

FIGURE 21. MIL-STD-498's use of objective and subjective criteria.

4.3.13 Distinguishing between software quality assurance and software product

evaluation.

a. Issues addressed. MIL-STD-498 addresses two related issues:


b. MIL-STD-498's approach to software quality assurance. In response to these

concerns MIL-STD-498 incorporates software quality assurance and carefully words the

8/7/2019 498GBOT

44/109

concerns, MIL STD 498 incorporates software quality assurance and carefully words the

requirements for software quality assurance to avoid any overlap with software product

evaluation. Figure 22 summarizes these requirements.

Aspect of the project Responsibility of quality assurance

Activities required by the contract or described in

the Software Development Plan

Assure they are being performed in accordance

with the contract and with the plan

Software products required by the contract

(whether deliverable or not)

Assure they exist and have undergone software

product evaluation, testing, and corrective actionas required by the contract

FIGURE 22. Avoiding overlap of SQA with other evaluation/testing activities.

c. Relationship to DOD-STD-2168. MIL-STD-498's quality assurance requirements can be

used on their own. If more detail is desired, they can be replaced or supplemented byDOD-STD-2168 or another software quality assurance standard. Appendix B of this

guidebook shows how MIL-STD-498 covers the requirements in DOD-STD-2168.

4.3.14 Application of configuration management to in-process work products.

a. Software configuration management in DOD-STD-2167A. DOD-STD-2167A's

configuration management requirements focused on controlling deliverable code and

documentation. Feedback on the standard indicated that DOD-STD-2167A's concept of a

"developmental configuration" was confusing and unhelpful; that all work products, not just

deliverable ones, need to be controlled during development; and that the standard ignores

items that are actually controlled (such as computer files).

b. MIL-STD-498's approach to configuration management. MIL-STD-498 eliminates the


4.3.15 Relationship to other related standards.

8/7/2019 498GBOT

45/109

a. Tiering of standards. Tiering of standards, that is, having one standard invoke other

standards, is discouraged by the DoD Acquisition Streamlining initiative as leading to

excessive, sometimes unintended requirements. The problem is illustrated inFigure 23.

CONTRACT MIL-x MIL-y MIL-z

--------

--------

--------

--------

--------

-------- -------- Follow

-------- Follow . . .

Follow Follow MIL-z Mil-w

MIL-x

--------

MIL-y

--------

--------

-------- -------- ------- -------- -------

FIGURE 23. Tiering of standards.

b. MIL-STD-498's approach. MIL-STD-498 invokes no other standards. It takes the

approach of covering all relevant topics at least in summary form, and provides, for

information only, a table of related standards that the acquirer may wish to consider as

alternatives or supplements to the requirements in MIL-STD-498. Included in the table are

both DoD and commercial standards. Because the listed standards are from various

sources and are not coordinated, a set selected from the table may be inconsistent. The

acquirer is responsible for reconciling any inconsistencies in the selected standards.

4.3.16 Ordering the software via the CDRL (DD Form 1423).

a. Differing methods. Different DoD services and government agencies disagree on how to

order delivery of the software itself. Some order delivery of the software via the CDRL

(DD Form 1423), using a DID; others order delivery of the software as a contract line item

number (CLIN). As a result of the controversy, DOD-STD-2167A was issued without aDID for ordering software. This decision forced DoD services and government agencies

who wished to order software via the CDRL to find or prepare a DID for this purpose.


4.3.17 Tailoring.
http://498-std.pdf/http://498gbar5.pdf/http://498gbar5.pdf/http://498-std.pdf/

8/7/2019 498GBOT

46/109

a. Importance of tailoring. MIL-STD-498 and its DIDs are designed to be tailored for each

project and for each type of software being developed on a project. Each project is to

review the standard and DIDs and select only those requirements that will be

cost-effective for the project.

b. Relationship to "builds." Tailoring goes hand in hand with multiple builds because

different requirements of the standard apply to different builds. For example, the

requirements for qualification testing may not apply to early prototypes, but do apply to the

finished product. Section 5 provides guidance on how to plan the builds for a project and

tailor MIL-STD-498 accordingly.

4.3.18 The importance of plans.

a. MIL-STD-498's plans. MIL-STD-498 requires 4 types of plans, described inFigure 24.

Title Purpose

SoftwareDevelopment Plan(SDP)

Describes the developer's approach to carrying out the softwaredevelopment project. Includes planning for software qualityassurance and software configuration management, which can bepublished separately

Software Test Plan(STP)

Describes the developer's approach to software qualificationtesting

Software InstallationPlan (SIP) Describes the developer's approach to installing the software atuser sites

Software TransitionPlan (STrP)

Describes the developer's approach to transitioning the software tothe support agency


4.4 Converting to MIL-STD-498 from DOD-STD-2167A and DOD-STD-7935A. This section

is designed to ease the transition from DOD-STD-2167A and DOD-STD-7935A to MIL-STD-498.

8/7/2019 498GBOT

47/109

g

It identifies key terminology changes and maps the DIDs of the preceding standards to and from

the MIL-STD-498 DIDs.

a. Mapping of key terms. Figure 25 identifies selected terms in MIL-STD-498 and gives

their counterparts in DOD-STD-2167A and DOD-STD-7935A.

b. Mapping of DIDs. Figure 26 identifies the DOD-STD-7935A DIDs and tells which

MIL-STD-498 DIDs contain their contents. Figure 27 provides a similar mapping from the

DOD-STD-2167A DIDs to the MIL-STD-498 DIDs. Figure 28 provides the reverse

mapping, identifying the MIL-STD-498 DIDs and telling which DOD-STD-2167A and/or

DOD-STD-7935A DIDs formed the basis for each.

MIL-STD-498 Term DOD-STD-2167A Counterpart DOD-STD-7935A Counterpart

Acquirer Contracting agency User Group (no distinction made

between acquirer and user roles)

Developer Contractor (covers government

agency or contractor)

Development Group (covers

government agency or contractor)

Implementation Coding Development, production, coding,

database generation

Installation (at user sites) Deployment Deployment, implementation,

installation

Software unit Computer software component andcomputer software unit

Software unit

Computer Software Configuration

Item (CSCI)

Computer Software Configuration

Item (CSCI)

Program, computer program


DOD-STD-7935A DID Incorporated into These MIL-STD-498 DIDs

8/7/2019 498GBOT

48/109

DOD STD 7935A DID Incorporated into These MIL STD 498 DIDs

Functional Description (FD) System concepts into Operational Concept Description (OCD)

System requirements into System/Subsystem Specification (SSS)Development planning into Software Development Plan (SDP)

System/Subsystem Specification

(SS)

System requirements into System/Subsystem Specification (SSS)

System design into System/Subsystem Design Description (SSDD)

Software Unit Specification (US) Requirement information into Software Requirements Specification

(SRS) and Interface Requirements Specification (IRS)Design information into Software Design Description (SDD) and

Interface Design Description (IDD)

Database Specification (DS) Database Design Description (DBDD)

Test Plan (PT) High-level planning into Software Test Plan (STP)

Detailed planning into Software Test Description (STD)

Test Analysis Report (RT) Software Test Report (STR)

Users Manual (UM) Software Input/Output Manual (SIOM)

End User Manual (EM) Software User Manual (SUM)

Computer Operation Manual (OM) Software Center Operator Manual (SCOM)

Maintenance Manual (MM) Planning information into Software Transition Plan (STrP)

Software description into Software Design Description (SDD)

Maintenance procedures into Software Product

Specification (SPS)

Implementation Procedures (IP) Software Installation Plan (SIP)

FIGURE 26. Mapping of DOD-STD-7935A DIDs to MIL-STD-498 DIDs.


DOD-STD-2167A DID Incorporated into These MIL-STD-498 DIDs

8/7/2019 498GBOT

49/109

DOD STD 2167A DID Incorporated into These MIL STD 498 DIDs

Software Development Plan (SDP) Software Development Plan (SDP)

System/Segment Specification (SSS) System/Subsystem Specification (SSS)

System/Segment Design Document (SSDD) Operational concept into Operational Concept Description

(OCD)

System design into System/Subsystem Design Description

(SSDD)

Software Requirements Specification (SRS) Software Requirements Specification (SRS)

Interface Requirements Specification (IRS) Interface Requirements Specification (IRS)

Software Design Document (SDD) Software Design Description (SDD)

Interface Design Document (IDD) Interface Design Description (IDD)

Software Test Plan (STP) Software Test Plan (STP)

Software Test Description (STD) Software Test Description (STD)

Software Test Report (STR) Software Test Report (STR)

Computer System Operator's Manual (CSOM) Computer Operation Manual (COM)

Software User's Manual (SUM) Software User Manual (SUM)

Computer Resources Integrated Support

Document (CRISD)

Planning information into Software Transition Plan (STrP)

Modification procedures into Software Product Specification

(SPS)

Software Product Specification (SPS) Software Product Specification (SPS)

Software Programmer's Manual (SPM) Computer Programming Manual (CPM)

Firmware Support Manual (FSM) Firmware Support Manual (FSM)


MIL-STD-498 DID DOD-STD-2167A and DOD-STD-7935A Source DIDs

8/7/2019 498GBOT

50/109

Software Development Plan (SDP) 2167A Software Development Plan (SDP)7935A Functional Description (FD), section 7

Software Installation Plan (SIP) 7935A Implementation Procedures (IP)

Software Transition Plan (STrP) 2167A Comp Res Integ Sup Doc (CRISD) - planning info

7935A Maintenance Manual (MM) - planning info

Operational Concept Description (OCD) 2167A System/Segment Design Doc (SSDD), section 3

7935A Functional Description (FD), section 2

System/Subsystem Specification (SSS) 2167A System/Segment Specification (SSS)7935A Functional Description (FD) - system req't info

7935A System/Subsystem Spec (SS) - system req't info

System/Subsystem Design Description (SSDD) 2167A System/Segment Design Document (SSDD)

7935A System/Subsystem Spec - system design info

Software Requirements Specification (SRS) 2167A Software Requirements Specification (SRS)

7935A Software Unit Specification (US) - req't info

Interface Requirements Specification (IRS) 2167A Interface Requirements Specification (IRS)7935A SW Unit Specification (US) - interface req't info

Software Design Description (SDD) 2167A Software Design Document (SDD)7935A Software Unit Specification (US) - design info

7935A Maintenance Manual (MM) - "as built" design info

Interface Design Description (IDD) 2167A Interface Design Document (IDD)7935A SW Unit Specification (US) - interface design info

Database Design Description (DBDD) 7935A Database Specification (DS)

Software Test Plan (STP) 2167A Software Test Plan (STP)

7935A Test Plan (PT) - high-level information

Software Test Description (STD) 2167A Software Test Description (STD)7935A Test Plan (PT) - detailed information

Software Test Report (STR) 2167A Software Test Report (STR)

7935A Test Analysis Report (RT)


5. TAILORING AND APPLICATION GUIDANCE

Thi i id id i il i d l i MIL STD 498 Thi

8/7/2019 498GBOT

51/109

This section provides guidance to an acquirer on tailoring and applying MIL-STD-498. This

section assumes a basic knowledge of system and software acquisition and does not attempt

to describe these processes.

5.1 Approval of MIL-STD-498. MIL-STD-498 was issued 5 December 1994. Its approval

extends for a two-year period, at the end of which time a commercial standard is expected to

be ready to use in its place. Readers are advised to check with the Departmental

Standardization Office (DepSO) Standards Improvement Executive (SIE) of their DoD serviceor government agency or the DoD Standards Office for current policy and guidance regarding

the standard.

5.2 Ways of applying MIL-STD-498. As shown inFigure 29 and described below,

MIL-STD-498 can be used in four basic ways. The applicability of each method depends uponDoD service or government agency policy and practice. The acquirer is advised to check with

the Software Acquisition Executive for the DoD service or government agency for which the

project is being developed to determine the current status of pertinent policy.

Four basic ways of applying MIL-STD-498

Cite as a requirement inthe RFP and the contract

Cite as a requirement inthe RFP; require an SDP;put the resulting SDP oncontract

Cite as guidance in theRFP; require an SDP; putthe resulting SDP oncontract

Cite as a requirement inthe contract as a result ofthe winning bidder havingproposed it

FIGURE 29. Ways of applying MIL-STD-498.

a. Requirement in RFP and contract. One way of using MIL-STD-498 is to cite it as a

required standard, appropriately tailored, in the Request for Proposal (RFP) and in the

contract. This is the traditional use of military standards.


5.3 Information about tailoring. Regardless of the manner in which MIL-STD-498 is

used, it is intended to be tailored for each type of software to which it is applied. This section

8/7/2019 498GBOT

52/109

provides guidance on tailoring.

5.3.1 What is tailoring? The tailoring process is illustrated inFigure 30. It consists of:

a. Evaluating each requirement in a standard or DID to determine whether it is necessary

and cost effective for a given project, for a given phase or build within a project, and for

particular software on the project

b. For standards, deleting, modifying, or adding to the requirements, as appropriate

c. For DIDs, deleting unneeded requirements or modifying requirements in a manner that

does not increase required workload (This more restrictive tailoring for DIDs is based

on U.S. law, specifically the Paperwork Reduction Act)

D o D s e r v i c e / g o v t .

a g e n c y p o l i c i e s . . .

C h a r a c t e r i s t i c s o f M I L - S T D - 4 9 8

a g i v e n p r o j e c t U s e t o - - - - - - - - - - - - - - - -

> - - - - - - - -

e v a l u a t e D I D s

O b j e c t i v e s o f a - - - - - - - - - - - - - - - - - - -

p r o j e c t p h a s e / b u i l d - - - - - - - - - - - - - - - -

- - - - - - - - - - -

- - - - - - - - - - -

C h a r a c t e r i s t i c s o f d e s i g n a t e s d e l e t e d

p a r t i c u l a r s o f t w a r e o r m o d i f i e d - - - - - - - - - - -

r e q u i r e m e n t s

FIGURE 30. Overview of the tailoring process.

5.3.2 Why tailor?


d. Balance between near-term and long-term benefits. In making tailoring decisions, it

is important to perform a risk analysis to balance near-term savings of cost and

8/7/2019 498GBOT

53/109

schedule against long-term risks. Sample trade-offs include the following:

1) Products needed for software support. Tailoring out software products needed for

software support can save time and money in the initial development, but may

have severe negative effects on the long-term cost of supporting the software.

2) Tests and evaluations. Tailoring out software product evaluations, software

testing, and related activities can save time and money in the short term, but canresult in reduced quality and expensive and time-consuming rework if software

products are delivered before they are ready.

5.3.3 When is tailoring performed? Tailoring of MIL-STD-498 and its DIDs should be

viewed as an incremental process, as illustrated in Figure 31 and described below.

a. During preparation of the draft RFP. Initial tailoring is often performed during

preparation of a draft Request for Proposal (RFP). The acquirer assesses the project

and its objectives and determines what requirements of MIL-STD-498 and its DIDs

apply to each type of software. The draft RFP requests feedback on the tailoring as

well as on other aspects of the procurement.

b. In response to the draft RFP. Prospective bidders often include proposed revisions to

the tailoring in their comments on the draft RFP. This tailoring provides each

prospective bidder's view as to the most cost-effective manner to perform the project

given project requirements and the particular methods and tools used by that bidder.

c. During preparation of the final RFP. The tailoring in the final RFP is often revised

from the draft based on input from the prospective bidders. This tailoring reflects the


8/7/2019 498GBOT

54/109

ACQUIRER'S TAILORING DEVELOPERS' TAILORING

Program strategy

Developer's software development process

Current acquisition phase Developer's software development tools

DoD service/government agency policy Developer's capability maturity

Software support concept

Other considerations

Tailoring Draft Prospective

for

bidders'

draft RFP RFP tailoring

Tailoring

Comments on

for

RFP Draft RFP

RFP

Bidders'

tailoring

for proposal

Tailoring Proposals

for Best &

Final Offer

Request for Best and Bidders'

tailoring for

Final Offer Best and Final

Offer

Tailoring for Best and Final Offers

contract

negotiations

Tailoring Tailoring for

during contract contract

negotiations

negotiations

Contract

Proposed Revised tailoring Proposed

revisions to the

during contract

revisions to the

tailoring

performance

tailoring


f. During contract negotiations. Additional tailoring may occur as part of contract

negotiations with the winning bidder.

8/7/2019 498GBOT

55/109

498GBOT

Documents

Transcript of 498GBOT