Standards: DODSTD2167A, MILSTD498 and IEEEEIA JSTD016 EEE493 2000

1
StandardsDOD-STD-2167A, MIL-STD-498 and
IEEE/EIA J-STD-016 EEE493 2000
Royal Military College of Canada Electrical and
Computer Engineering

• Major Greg Phillips
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

Dr. Scott Knight knight-s_at_rmc.ca 1-613-541-6000
ext. 6190
2
What are Standards?

• product standards, which prescribe the technical
  characteristics of some artifact
• process standards, which prescribe a method for
  accomplishing a task
• includes formalised life cycle models, quality
  models
• guidelines, which describe a preferred method for
  accomplishing a task
• procedures, which define the implementation of
  process standards or guidelines
• process improvement models
• contractor selection vehicles

3
Process Standards in Contracts

• US DoD faced problem in 1970s and early 1980s
• many software projects were failing
• because of inadequate software process practices
  on the part of the vendors
• and DoD was finding out too late to take action
• because of inadequate visibility into vendors
  process from customer perspective
• software process standards were a response
• contracts could now say roughly in building
  this product the vendor shall use a process and
  produce work products in compliance with some
  standard
• this is usually made explicit in the request for
  proposal (bidding) phase of the contract award

4
Process Standards History

• DOD-STD-2167A was released on 29 February 1988
  and superseded by MIL-STD-498 on 5 December 1994.
• MIL-STD-498 was released on 5 December 1994 and
  cancelled as of June 1998.
• IEEE/EIA J-STD-016 was released on 30 September
  1995 as an interim standard and has not since
  been updated.
• So, why bother studying them?

5
A Standards Family Tree
MIL-STD -7935
basis of
DoD Software Life Cycle (SWLC) Standards
MIL-STD -498
influenced
DOD-STD -2167A
IEEE 1074
Rev IEEE 1074
IEEE standards for developing LC processes
Rev ISO/IEC 12207
ISO/IEC 12207
ISO standards for LC Processes
J-STD -016
IEEE/EIA commercialisation of DoD SWLC standards
IEEE/EIA 12207
US standards for LC Processes
6
DOD-STD-2167A
7
Hard Copy Deliverable Data

• DOD-STD-2167A identifies 16 separate deliverable
  data items, with associated (inflexible) Data
  Item Descriptions (DIDs)
• intended to provide customer visibility into the
  process, not necessarily to improve the process
  itself.
• what is the probable effect of this?
• Many projects required the developer to prepare
  and deliver most or all of the documents in hard
  copy format 30 to 60 days prior to the milestone
  reviews
• what is the probable effect of this?

8
2167A Process Model

• The software development process shall include
  the following major activities, which may overlap
  and may applied iteratively or recursively
• System Requirements Analysis/Design
• Software Requirements Analysis
• Preliminary Design
• Detailed Design
• Coding and CSU Testing
• CSC Integration and Testing
• CSCI Testing
• System Integration and Testing

9
Reviews

• During the software development process, the
  contractor shall conduct or support formal
  reviews and audits as required by the contract.
  Guidance on formal reviews and audits is provided
  in MIL-STD-1521.
• But
• The contractor shall conduct one or more
  Software Specification Review(s) (SSR) in
  accordance with MIL-STD-1521.
• (ditto for PDR, CDR, TRR, etc.)

10
MIL-STD-1521
HWCI testing
fabrication
detailed design
preliminary design
FCA
PCA
CDR
hardware requirements analysis
PDR
system requirements analysis
system design
system integration and testing
SRR
SDR
SSR
FQR
software requirements analysis
PDR
preliminary design
FCA
PCA
CDR
detailed design
functional baseline
coding and CSU testing
Abbreviations
allocated baseline
TRR
system requirements review system design
review software specification review preliminary
design review critical design review test
readiness review functional configuration
audit physical configuration audit formal
qualification review
SRR SDR SSR PDR CDR TRR FCA PCA FQR
CSC integration and testing
product baseline
CSCI testing
development configuration
11
MIL-STD-498 andIEEE/EIA J-STD-016

• J-STD-016 is a civilianised version of
  MIL-STD-498. The two standards are virtually
  identical except for some wording changes.

12
Claimed Benefits of MIL-STD-498

• Is usable with any development strategy
• Is usable with any development methods
• Is compatible with CASE tools
• Provides requirements for software reuse
• Supports the use of software measurement
• Emphasizes software supportability
• Provides a role for software in the system

13
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
• Appendix D Software Product Evaluations
• Appendix E Candidate Joint Management Reviews
• Appendix F Candidate Management Indicators
• Appendix G Guidance on Program Strategies,
  Tailoring, and Build Planning
• Appendix H Guidance on Ordering Deliverables
• Appendix I Conversion Guide from DOD-STD-2167A
  and DOD-STD-7935A
• Index to the standard and DIDs

14
MIL-STD-498 Requirements (I)

• 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

15
MIL-STD-498 Requirements (II)

• 4.2 General requirements for software development
  (cont.)
• 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)
• Record rationale for key decisions for use by the
  support agency
• Provide the acquirer access to developer and
  subcontractor facilities

16
Decreased documentation
MIL-STD-498
DID specifying content
A software product, such as plan, requirements,
design, code, database, manual
plus
tasking paragraph
may be either
may be either
Traditional document
Deliverable
other form (e.g. CASE tool)
Non- deliverable
But there are still 23 DIDs in MIL-STD-498.
17
Support for reuse

• 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 in
  fulfilling contract requirements, and to
  incorporate those that meet the criteria
  established for the project.
• 3) Provides criteria for evaluating software
  products for reuse and tells how to interpret the
  standard when applied to reused items.
• 4) Requires the developer to identify and analyze
  opportunities for developing software products
  for reuse, and to notify the acquirer of those
  that provide cost benefits and are compatible
  with program objectives.
• 5) Provides a definition of reengineering and its
  constituent activities, and provides a diagram
  showing how MIL-STD-498 can be applied to a
  reengineering project.

18
Requirements versus Design
Traditional View
MIL-STD-498 View
WHAT the system is to do
characteristics deemed conditions for acceptance
Requirements
HOW the system is to do it
characteristics selected to meet the requirements
Design
19
Builds
20
Applying Process Standards

• acquisition agency must understand the invoked
  standard
• explicit requirements
• implicit assumptions
• contractor must understand the invoked standard
• level of compliance sometimes difficult to assess
  or enforce
• tailoring essential for most projects

21
Next ClassISO/IEC 12207 and IEEE/EIA 12207