1. An Introduction to
IEEE/EIA 12207

2. An Introduction to IEEE/EIA 12207
J-016
9000
1679
498
3405.1
12207 R
5000.1
CMM
Created by Wells as 12207SPIWG1.ppt - 8/99
Updated to 12207SPIWG2.ppt - 10/6/99
Material possibly needed in presentation:
IEEE/EIA 12207
2167A and 498
IEEE Software Engineering Standards book (includes J-STD-016 )
CMM(s) ?
ISO 9000
by Software Engineering Process Office (SEPO - D12)
Software Process Improvement Working Group (SPIWG)
October 13, 1999

3. Are there TWO 12207’s?
ISO/IEC 12207: Information Technology - Software Life Cycle Processes
published in 1995 by
International Organization for Standardization
International Electrotechnical Commission
Provides common framework for developing and managing software
IEEE/EIA 12207: Software Life Cycle Processes
published in 1998 by
Institute of Electrical and Electronics Engineers
Electronic Industries Association
Includes ISO/IEC in its entirety
Adds clarifications, concepts, and guidelines to foster better understanding and application
Adopted for use by DoD on May 27,1998
Designated by SSC SD for life cycle processes
Animation - top half appears automatically
2. bottom half appears on mouse click with front of figure
3. ISO and arrow down & back part - second mouse click.
ISO is not an acronym - is Greek for “equal, similar, alike” (= standard)
as in isometric, isobar, isosceles triangle
Many in US did not think ISO had enough rigor - lacked specificity of old MIL STDs, especially 498. So US industry developed their own version (initially called US 12207) to add good qualities of 498.

4. The Purpose of 12207
Establish a common framework for software life-cycle processes, with well-defined terminology that can be referenced by the software industry.
To acquire, supply, develop, operate, and maintain software products
To define, control, and improve software life cycle processes
This from Para 1.1: Purpose
12207 provides industry a basis for software practices usable for both national and international business

5. IEEE/EIA Has Many Uses
To acquire, supply, develop, operate, and maintain software
To support the above functions in the form of quality assurance, configuration management, joint reviews, audits, verification, validation, problem resolution, and documentation
To manage and improve the organization’s processes and personnel
To establish software management and engineering environments based upon the life cycle processes as adapted and tailored to serve business needs
To foster improved understanding between customers and vendors and among the parties involved in the life cycle of a software product
To facilitate world trade in software
Forward

6. Why Use Standards?
Establish uniform requirements for development and documentation
Define a common framework for software life cycle processes
Clarify the roles and interfaces of participants
Clarify the types and contents of documentation
Identify the tasks, phases, baselines, reviews, and documents needed
Follow the lessons learned and best practices of the industry
Avoid the pitfalls and problems of the past
Standards are not intended to torment the participants in a development effort. They contain the lessons learned by trial and error on Government and commercial software efforts.
All standards now are guidelines - and can be tailored to the specific characteristics of the project.
The bottom line is standards and directives assist the project team and all parties involved to produce quality products faster and cheaper
IEEE Software Magazine Sept/Oct 1999:
“Software Quality’s Eight Great Myths” - Jeffrey Voas
Myth 5: By following published standards, you can toss common sense on software development out the window - following a recipe blindly.
Concerns -
Standards lack timeliness - published well after they are relevant
Impediment to competition instead of advocate for quality
Unknown relationship to established “best practice” or related standards
Voas not advocating that standards should not be used, but one size does not fit all; you should consider your situation’s specifics before opting for a standard.

7. Don’t Get Caught in the Standards Quagmire
The multitude of standards and maturity models sometimes appears as a quagmire... The software development industry is being overwhelmed with a proliferation of standards and maturity models. The Software Productivity Consortium has studied those frameworks that are relevant to companies building software-intensive systems. The results of this research are documented in the paper, "The Frameworks Quagmire, A Brief Look," and are presented here in this graphic.
In addition, a Compliance Frameworks Comparison Course that describes the relationships, similarities, and differences among maturity models, technical and quality standards, and contractor selection vehicles, is available to Consortium members.
The colors of the frameworks names indicate the category or source of the framework:
Color Meaning of color
Red A Capability Maturity Model
Green A U.S. Government or military document
Purple An international standard
Blue Developed by a professional organization (mostly U.S.)
Black Other

8. The Evolution of Standards Affecting DoD Software Development
MIL-STD-1679A Software Development 1983
DOD-STD-2167A Defense System Software Development 1988
DOD-STD-7935A AIS Documentation Standards 1988
MIL-STD-498 Software Development and Documentation (SecDef Perry Memo - June 1994)
ISO (series - on Quality Management, etc.) 1991-
J-STD Software Development Acquirer-Supplier Agreement
ISO/IEC Information Technology - Software Life Cycle Processes 1996
IEEE/EIA Software Life Cycle Processes 1998
Animation - text rolls down automatically
In contrast to the many documents on last viewgraph - these are the ones we will cover in this session.
Even if superseded - some standards live forever (story of US rail lines at 4’ 8.5” apart, based on British rail, British trams, British carriages, all European roads built by Romans, Roman chariot wheel width based on width of two horses rear ends)

9. The Family Tree of Standards
ISO/IEC “Software Life Cycle Processes” Aug 95
DOD-STD-2167A “Defense System Software Development” Feb 88
2167A
7935A
498
ISO 12207
IEEE Stds
IEEE/EIA 12207
016
MIL-STD-498
“Software Development and Documentation” Dec 94
J-STD
(Trial Use)
“Software Life Cycle Processes, Software Development” Sep 95
IEEE/EIA
IEEE/EIA
IEEE/EIA
“Software Life Cycle Processes”
Mar/Apr 98
Animation - figures and text fly in from left automatically
This shows that 2167A and 7935A were combined and replaced by 498; 498 became the basis for J-STD-016 (along with portions of ISO 12207)
IEEE includes all of ISO and good parts of 016 (=498)
DOD-STD-7935A “DoD Automated Information Systems (AIS) Documentation Standards” Oct 88

10. Outline of IEEE/EIA 12207.0: “Software Life Cycle Processes”
Forward
1. Scope
2. Normative references
3. Definitions
4. Application of this Standard
5. Primary processes
6. Supporting processes
7. Organizational processes
Annexes A - D
Annexes E - J
ISO/IEC 12207
Animation - all appears automatically
12207 has three volumes: .0, .1, .2
Divided into CLAUSES and ANNEXES vice sections and appendices
Normative = incorporated by reference, required.
Webster: “prescribing a norm or standard”
some annexes “normative”, some “informative”
total: 85 pages

11. Outline of IEEE/EIA 12207.1: “Software Life Cycle Processes - Life cycle data”
Forward
1. Scope
2. Normative references
3. Definitions
4. Life cycle data
5. Generic info item content guidelines
6. Specific info item content guidelines
Annex A - References
Animation - all appears automatically
total: 36 pages

12. Outline of IEEE/EIA 12207.2: “Software Life Cycle Processes - Implementation considerations”
Forward and introduction
1. Scope
2. Normative references
3. Definitions
4. Application
5. Primary processes
6. Supporting processes
7. Organizational processes
Annexes A - M
Animation - all appears automatically
Annexes A-E are repeat of annexes A, F, G, H, J with guidance
Repeats clauses with additional guidance
total: 109 pages

13. Terminology used in 12207 (both of ‘em)
17 Life Cycle Processes
5 Primary Processes § 5
8 Supporting Processes § 6
4 Organizational Processes § 7
Each Process is broken down into Activities
Each Activity is broken down into Tasks
Tasks reference Information Items (software products/documents)
84 items in matrix § 4.3
Generic guidelines for 7 categories § 5
Specific guidelines for § 6
Aed repf dbmezrt
Ased of dbe zmrt
Asedfbme
12207 assumes life cycle begins with an idea or need that can be satisfied wholly or partly by software and ends with the retirement of the software. Architecture is build with a set of processes and interrelationships. Based on two principles: modularity and responsibility. (.0 Annex E)
A task is expressed in the form of self-declaration, requirement, recommendation, or permissible action. Doc uses auxiliary verbs (will, shall, should, may) to differentiate.
Will = self-declaration of purpose or intent by one party.
Shall = binding provision between two parties.
Should = recommendation among other possibilities.
May = permissible within limits.
(Note: § = Clause/Section)

14. Thanks…