An Introduction to IEEE/EIA 12207

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

Outline Background of IEEE/EIA 12207 Structure of the standard
Its Life Cycle Processes 12207 vs. 2167A and 498 How it relates to the SW-CMM How to tailor it for your use How to use it on a project How to get a copy of it

ISO/IEC 12207: Information Technology - Software Life Cycle Processes
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.

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

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

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.

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 From the SPC’s

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 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)

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

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

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

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

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)

12207’s five Primary Life Cycle Processes
The primary processes define what the organization elements do during the software life cycle. Process Role 498 term Acquisition Acquirer - an organization that Acquirer procures a system or service Supply Supplier - an organization that enters into contract with acquirer under terms of the contract Development Developer - organization that Developer performs development during the life cycle process Maintenance Maintainer - an organization that (Support performs maintenance activities Agency) Operation Operator - an organization that operates the system User - An individual or organization (User) that uses the system for a specific function 12207 addresses 5 major roles for 5 major processes. Also 6th role - user. These roles may belong to different “parties” or one party may play several roles in a development. E.g.: Supplier (contractor) may also be developer or could subcontract out. Maintenance may be part of supplier’s job, or developer’s job, or Acquirer’s job. Operation may be acquirer’s job, or User’s job. (498 and J-016 addressed primarily the developer, and some of the interface with the acquirer.) (2167A addressed “contractor” and “government” roles.) (CMM addresses Organization and Project roles (developer) and “customer” and “end user”)

Examples of Life Cycle Roles
Role Teens’ Truck Navy System Acquirer (“Buyer”) Mom and Dad Systems Command, PD-xx Supplier (“Vendor”) Ed’s Car Lot Systems Center D555 Developer Ford Motor Cool Coders Corp. Maintainer Terry’s Tuneup Shop Systems Center D999 Operator Family’s Teenagers Pacific Fleet User A teenager Ship’s watch team Here is an analogy to the roles defined in Situation: Your family wants to buy pickup truck for the teenagers. Compare to Navy system procurement. Many variations possible.

12207’s Organizational and Supporting Processes
Organizational Life Cycle Processes - typically outside the realm of specific projects and contracts. Should be in place prior to performing primary processes. Management Infrastructure Improvement Training Supporting Processes - employed and executed by another process. Responsibility of the organization. Documentation Configuration Management Quality Assurance Verification Validation Joint Review Audit Problem Resolution These additional processes are the responsibility of the overall organization, not the individual software project. But in some instances, the “project” may be equal to the “organization.”

How The Life Cycle Processes Interact
MANAGEMENT SUPPLY OPERATION MAINTENANCE DEVELOPMENT ACQUISITION DOCUMENTATION JOINT REVIEW SUPPORTING PROCESSES CM QA PROB. RES. AUDIT VERIFICATION VALIDATION contract INFRASTRUCTURE TRAINING IMPROVEMENT ORGANIZATIONAL PROCESSES Animation - graphic dissolves in automatically 12207 has 17 Life Cycle Processes in three categories: - 5 Primary processes (shadowed boxes) - for software life cycle - 8 Support processes (as needed, responsibility of the organization) - 4 Organizational processes (apply to all processes) 17 total All are interconnected and interrelated depending on the role of the parties in the operation/maintenance/development. 498 addresses primarily the Development process box. Verification = building product right (satisfy standards, processes) Validation = building right product (complies with requirements)

The Three Software Life-Cycle Development Strategies
Define All Requirements First? Multiple Development Cycles Distribute Interim Software? Program Strategy Once-Through (Waterfall) Yes No Incremental (Preplanned Product Improvement) Yes Maybe Evolutionary No Yes From IEEE/EIA Annex I These are recommended by SSC SD as the basis for project planning and implementation. Animation - three strategies appear with three mouse clicks Managers must choose their life-cycle strategy, so you must understand it. This table drawn from IEEE Annex I shows three strategies for acquisition - however the world is not limited to three. Annex I provides guidance (risk analysis) in helping you understand the factors to consider in selecting one of its recommended strategies. Please note key difference in the areas of requirements and in interim distribution - critical aspects in selecting a strategy. Model of Software Life Cycle goes from concept and Requirement thru retirement. (CMM, IEEE) IEEE says “this does not prescribe a specific life cycle model or software development method.” CMM SPP Activity 5: A software life cycle with predefined stages of manageable size is identified or defined. Examples of software life cycles include waterfall, overlapping waterfall, spiral, serial build, single prototype/overlapping waterfall. Strategies recommended in SSC “Description of the SSC Software Process Assets”

A Sample 12207 Development Process
One example of applying to the Waterfall development strategy Process Implementation Activity SRS SARAD SRD, UDD SAD, SIDD, DBDD, T/VP EOCR, SCR,T/VPr, T/VRR SIP,T/VPr T/VPr T/VRR SCR SCR, T/VRR DPP, SDSD SCMP, SCMR, SCIR, SQAP, SQAR, SVRR, PR/PRR Software Item 1: Sys Arch Design System Reqts Analysis Software Qual Test Software Integra- tion Software Code & Test Software Detailed Design Software Arch. Design Software Reqts. Analysis Software Item 2: Software Qual Test Software Integra- tion Software Code & Test Software Detailed Design Software Arch. Design Software Reqts. Analysis System Qual Test System Integra-tion Software Installation Software Acceptance Support Hardware items A flow chart of Activities of the Development process looks similar to the 498 flow chart. Animation: takes 6 mouse clicks: 1. “Process Implementation activity” - start to finish of life cycle 2. The other 12 activities of Development Process 3. Software item 2 - in parallel, but not exactly 4. Other items - e.g., Hardware items 5. Other Supporting and Organizational Processes (colored boxes) 6. Associated information items (documents) The Development process has 13 activities, shown above in the white boxes. Supporting and Operational Processes at the bottom in colored boxes. Document acronyms are part of the 84, not the 30 with specific info. Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution Organizational Processes: Management, Infrastructure, Improvement, Training

The 30 12207.1 “Information Items”
Descriptions Concept of operations description Database design description Software architecture description Software design description Software devel. standards descr. Software interface design descr. Software requirements description Sys. arch.& reqts. alloc. descr. User documentation description Plans Acquisition plan Development process plan Maintenance process plan Operation process plan Project management plan Software CM plan Software integration plan Software QA plan Test or validation plan Procedures Test or validation procedures Record Evaluation records Executable object code record Software configuration index record Software CM records Software QA records Source code record Report Problem report & prob. resolution report Software verification results report Test or validation results report Request Change request or modification request Specification System requirements specification has “Life Cycle Data “ guidance for documents, which are called “Information items.” It identifies 84 information item names called for in It then gives general information item content guidelines for 7 general types of documents 5.1 Description 5.2 Plan 5.3 Procedure 5.4 Record 5.5 Report 5.6 Request 5.7 Specification Then gives specific info item content guidelines for the 30 documents above in Clause 6 of Not as specific as DIDs.

12207’s Guidance for the “Information Items”
This example for Development process 5.3 Process Implementation Activity 5.3.1 Task #4

12207’s Management Process An Organizational Life Cycle Process - 12207.0 § 7.1
Defines the basic activities of the management, including project management, related to the execution of a life cycle process. Activity Tasks 1 Initiation and .1 Establish the requirements for management scope definition .2 Check resources: personnel, materials, etc. .3 Modify requirements to achieve criteria 2 Planning .1 Plan efforts, schedules, tasks, duties, costs (in Management process plan) 3 Execution and .1 Implement plan to meet objectives control .2 Monitor process .3 Investigate and resolve problems .4 Report progress 4 Review and .1 Ensure products and plans are evaluated evaluation .2 Assess evaluation results 5 Closure .1 Determine when process is complete .2 Check results for completeness Management process can apply to any primary process: acquisition, supply, development, operation, maintenance

12207’s Maintenance Process A Primary Life Cycle Process - 12207.0 § 5.5
Defines the basic activities of the maintainer: managing modifications to the software product to keep it current and in operational fitness. Activity Tasks 1 Process Implementation Document maintenance activities (in Maintenance process plan). Document problem tracking procedures. Manage modifications to the system. 2 Problem and modification Analyze problem reports. Replicate or verify analysis problems. Develop modifications. Document problems, analysis, fixes (with Modification request). Get modifications approved per contract. 3 Modification implementation Document where changes are needed. Implement modifications (use Development Process). 4 Maintenance review/ Review integrity of modified system. Get approval for acceptance modifications per contract. 5 Migration Ensure products meet with this standard. Develop and use Migration Plan. Notify users of migration. Conduct parallel operations if needed. Notify all concerned, archive all records. Perform post-op review of changes. Keep data from old environment. 6 Software retirement Document plans for retirement. Notify all users of plans and activities. Conduct parallel operations. Notify all concerned, archive all records. Keep data from retired product per contract.

What about the Software Development Plan?
Management Process calls for ”plans for execution of the process.” § lists 9 topics for inclusion § 4.3 Table 1 includes “Management process plan,” refers to IEEE : “Standard for Software Project Management Plans” § 5.2 gives 20 items of Generic content of a “Plan” Supply Process calls for project management plan(s) § lists 15 topics to be considered § 4.3 Table 1 includes “Project management plan,” references include J-STD-016 § E.2.1: “contents of Software Development Plan” (like 498) IEEE 1074 Standard for Developing Software Life Cycle Processes IEEE Guide for Developing Software Life Cycle Processes § 6.11 gives 18 items for “Project management plan” Development Process calls for “plans for conducting the activities of the development process” § lists 7 topics for inclusion § 4.3 Table 1 includes “Development process plan,” references include ASTM E622 Guide for Developing Computerized Systems ASTM E1340 Guide for Rapid Prototyping of Computerized Systems § 6.5 gives 13 items for “Development process plan - may be part of Project management plan” If you like the 498 SDP - you can find a path to its use and format If you don’t like the 498 SDP - you can find many substitutes, but a plan is always required. ASTM is American Society for Testing and Materials, in Pennsylvania ( Annex A) E1340 is 11 pages ($35) at E622 is 31 pages ($40)

Can you Tailor 12207?

SEPO’s guidance on tailoring:
12207 should be tailored for a project - no two projects are the same Tailoring considerations: Life cycle activity: prototyping, maintenance Software characteristics: COTS, reuse, embedded firmware Your org’s policies, languages, hardware reserve, culture Acquisition strategy: contract type, contractor involvement Life cycle strategy: waterfall, evolutionary, spiral, etc. The Tailoring Process ( Annex A) 1. Identify project environment - strategy, activity, requirements 2. Solicit inputs - from users, support team, potential bidders 3. Select processes, activities, documentation, responsibilities 4. Document tailoring decisions and rationale Tailoring always a dangerous, nebulous area ========================================= See Section 4. TAILORING GUIDELINES of A DESCRIPTION OF THE SSC-SD Software Process ASSETS - Version 1.0, September 15, 1999 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. SEPO’s guidance on tailoring: What CAN’T be tailored: the intent or objectives What CAN be tailored: number of phases/activities, roles, responsibilities, document formats, formality/frequency of reports or reviews (see Tailoring Guidelines in “Description of SSC SD Software Process Assets”, at under OPD)

How does 12207 Compare to Previous Standards?
DOD-STD-2167A: Defense System Software Development Published: 29 February 1988 Superseded by MIL-STD-498 on 5 December May still remain valid on many contracts MIL-STD-498: Software Development and Documentation Published: 5 December 1994 Cancelled: 27 May superseded by IEEE/EIA May still remain valid on many contracts. SecDef Memo “Specifications and Standards - A New Way of Doing Business” Issued 29 June 1994: “Use performance and commercial specifications and standards in lieu of military specifications and standards, unless no practical alternative exists...” J-STD : Software Development - Acquirer-Supplier Agreement Published: 30 September 1995 as Trial Use Standard by IEEE/EIA Objective: replace MIL-STD with a non-government equivalent “Almost identical” to MIL-STD-498 with changes in traceability, terminology DOD-STD-2167A was specified for many Navy systems, and may still remain in contracts. We still refer to many lifecycle phases, reviews, documents, and terminology of 2167A. Just before 498 was released, SecDef Perry issued a memo encouraging use of commercial standards. 498 was approved for an interim period (2 yrs, extended to July 98), in Dec 94 because no industry standards were available and so much work had gone into developing 498 and it was significantly better than 2167A. If MIL STDS were to be discontinued, developers needed equivalent commercial standards. J-STD-016 was an attempt by commercial organizations to develop a replacement for a “non-govt” equivalent to 498 016 Is issued as “Trial Use Standard” - intended to be replaced by ( = Deemed to be of technical value to industry, without rigorous public review of normal IEEE standards.)

DOD-STD-2167A Deliverables, Reviews, Baselines
SYS SYSTEM SOFTWARE PRELIM DETAILED CODING CSC INTEG. CSC SYSTEM REQTS DESIGN REQTS DESIGN DESIGN AND CSU AND TEST TESTING INTEG. ANALYSIS ANALYSIS TESTING AND TEST PHASE PRELIM SYSTEM PRELIM DETAILED SOURCE SYS SPEC SDD SDD CODE SPEC LISTINGS DELIVERABLE PRODUCTS SYS/SEG SOFTWARE SOURCE UPDATED DESIGN TEST CODE SOURCE DOC PLAN CODE PRELIM SOFTWARE SW TEST SW TEST SW TEST SW REQTS REQTS DESCR. DESCR. REPORTS SPEC SPEC (CASES) (PROC) PRELIM I’FACE PRELIM I’FACE OPERATION I’FACE REQTS I’FACE DESIGN & SUP’RT REQTS SPEC DES DOC DOC DOCS SOFTWARE VERSION DEVEL DESCR. PLAN DOC This is a simplification of the 2167A chart. Note: 9 phases, 8 formal reviews baselines multiple documents. Little on planning, delivery, support, QA,. CM, organizational responsibilities SOFTWARE DEVELOPMENTAL CONFIGURATION PRODUCT SPEC REVIEWS AND AUDITS SRR SDR SSR PDR CDR TRR F/PCA FUNCTIONAL BASELINE PRODUCT BASELINE ALLOCATED BASELINE BASELINES

Sample MIL-STD-498 Life Cycle
Project planning and oversight SDP STP SIP/STrP Software Item Qual Test Unit Integ/ Test Software Impl. & Unit Test Soft- ware Design Software Reqts. Analysis SRS/IRS SDD/IDD/DBDD STD STR Software Item 1: Prepare for Soft- ware Use Executable SW SVDs User/op manual Sys Qual Test SW/HW Item Integ/Test Software Item Qual Test Unit Integ/ Test Software Impl. & Unit Test Soft- ware Design Software Reqts. Analysis SRS/IRS SDD/IDD/DBDD STD STR Software Item 2: SSDD/IDD STR System Design System Reqts. Analysis STD Prepare for SW Transition This diagram shows example application of 498 to the Grand Design program strategy. This is a simplified version of 498 Figure 9 - also reproduced in Development Chart tab in SPM notebook. Flow and activities may vary for different software items (CSCIs) - or for different builds in Incremental Strategy. Can also be applied to reengineering project, using Reverse Engineering at start; then redocumentation, translation, restructuring, retargeting for different CSCI paths Other activities that run from start to finish like PPO does above: SW devel environment SCM SW product evaluation SQA Corrective Action joint reviews risk management software management indicators security/privacy interface with IV&V coordination with asso. developers improvement of project processes OCD SSS/IRS Hardware item(s) (not covered by this standard) Executable SW Source files SVDs SPSs Updated SSDDs Maint. manuals Other ongoing activities: SQA, SCM, Reviews, Risk Management, Process Improvement, etc.

MIL-STD-498 DIDs are still in effect!
MIL-STD-498 Data Item Descriptions and J-STD Software Product Descriptions Planning Software Development Plan (SDP) Software Test Plan (STP) Software Installation Plan (SIP) Software Transition Plan STrP) Concept and Requirements Operational Concept Descr. (OCD) System/Subsystem Spec. (SSS) Interface Requirements Spec. (IRS) Software Requirements Spec. (SRS) Design System/Subsys. Design Descr. (SSDD) Interface Design Description (IDD) Database Design Description (DBDD) Software Design Description (SDD) Qualification Testing Software Test Description (STD) Software Test Report (STR) Maintenance Software Product Specification (SPS) Software Version Description (SVD) Computer Programming Manual (CPM) Firmware Support Manual (FSM) User/Operator Software User Manual (SUM) Software Input/Output Manual (SIOM) Software Center Operator Manual (SCOM) Computer Operation Manual (COM) J-STD-016 addresses the same 22 documents as MIL STD 498. Content requirements are in Annexes E-J of 016; Format and structure are in Annex K. 498 DIDs are pages each, strict format, rigid structure to 3rd level outline MIL-STD-498 DIDs are still in effect!

How do the Standards Compare?
Animation - all appears from left, automatically. At the risk of oversimplification, here is a comparison of major characteristics of the 3 major standards applying to software.

How have the Development Activities Changed?
Names of activities in red have changed from previous standard

Have the Management Reviews changed?
DOD-STD-2167A MIL-STD IEEE/EIA 12207 Formal Reviews (10) Joint Mgmt. Reviews (11) Project mgmt. reviews (11) Software plan review Software plan review Operational concept review Operational concept review System Reqts. Rev.(SRR) System/subsys. reqts rev. System/subsys. reqts rev. System Design Rev.(SDR) System/subsys. design rev. System/subsys design rev. Software Spec. Rev. (SSR) Software reqts review Software reqts. review Prelim Design Rev. (PDR) Critical Design Rev. (CDR) Software design review Software design review Test Readiness Rev. (TRR) Test readiness review Test readiness review Test results review Test results review Production Readiness Rev(PRR) Software usability review Software maintenance rev. Software supportability rev. Software supportability rev. Critical reqts. review Critical reqts. review Functional Config Audit (FCA) (FCA in MIL-STD-973) (FCA in IEEE Std 1042) Physical Config Audit (PCA) (PCA in MIL-STD-973) (PCA in IEEE Std 1042) Formal Qual. Review (FQR) (dropped by MIL-STD-073) (see MIL-STD-1521B) (see 498 Appendix E) (see Annex G) (see also IEEE Std 1028) Names of activities in red have changed from previous standard 2167A para calls for formal reviews and audits as required. Cites MIL-STD-1521 for guidance parts for FCA, PCA, FQR superseded by MIL-STD-972 (CM) 498 covers reviews in 5.18 and Appx E. “Joint” means acquirer and developer Appendix E describes CANDIDATE reviews - not a mandatory part of the standard - guidance only. These not required or preclude alternatives or combinations. Para 6.6 covers Joint review process. Two parties are reviewing party and reviewed party Annex G has Candidate JMR’s. cites IEEE std 1028 for more info. 12207 Para 6.7 covers Audit process for auditing party and audited party. Tech Reviews: not addressed in 2167A called “Joint Technical Reviews” in 498 called “Technical reviews” in 12207 498 Para says JTRs objectives are to review evolving software products, using as criteria the software product evaluation criteria in App. D...

Wordsmithing the Review and Document Names
Most reviews and documents remain, sometimes with new names. E.g., PDR and CDR of 2167A combined into Software Design Review, even though SAD (= prelim SDD) and SDD (= detailed SDD) split. - Software Management for Executives Guidebook

Comparing 12207 to the CMM for Software
CMM Key Process Area IEEE/EIA L2: Requirements Mgmt. Development process, activity 2 and 4 Software Project Planing Management process Development process, activity 1 Proj. Track & Oversight Management process Software QA Quality assurance process Software CM Configuration management process Software Subctr. Mgmt. Acquisition process L3: Org. Process Focus Improvement process Org Process Def’n. Improvement process Integ. Software Mgmt. Mgmt process, tailoring guidance Training Program Training process Software Prod. Engr. Development process Intergroup Coord. Joint review process Peer Reviews Joint review process 12207 not directly relatable to KPAs, but most are covered.

How do I Get Copies of 12207? Hard copies of IEEE/EIA available from IEEE Print: 236 pages $ IEEE Mbr: $146.00 PDF: $ IEEE Mbr: $218.00 see With IEEE username & password, download from Review the Defense Automated Printing Service (DAPS) ASSIST Online webpage at IEEE/EIA can be downloaded to government users with DoD Single Stock Point accounts from Choose “Assist Quick Search” then Document Number = 12207 Hard copies of can be ordered from DAPS, see Review SSC Technical Library documents and suppliers at This info changing frequently.

How do I Get Copies of Other Standards?
MIL-STD-498 and DIDs on SEPO’s webpage at DoD and other standards can be downloaded from the Defense Automated Printing Service (DAPS) ASSIST Online webpage at Users have to register for many documents, but the Assist QuickSearch (lower right icon) can be used for the following: MIL-STD-498, all DIDs, and the cancellation notice available at - choose “Assist Quick Seach” and enter document number Hard copies of cancelled DOD specifications and standards can be obtained from the DoD Single Stock Point (DoDSSP) at Review SSC Technical Library documents and suppliers at

(also online at http://sepo.spawar.navy.mil/sepo/Standards.html )
The Cliff Notes: “Overview of IEEE/EIA12207” (attached to this handout) 13-page summary of all three volumes and annexes Tabular lists of processes, activities, tasks, and related info items Cross references: Info Item to activity - and vice versa Comparison of 498 activities to 12207 Comparison of program reviews among 2167A/1521B, 498, 12207 Comparison of documents among 2167A, 498, J-016, 12207 (also online at )

SEPO Recommends: Use IEEE/EIA 12207: It is the standard of DoD and SSC-SD It models all major roles and interfaces It achieves breadth of ISO/IEC and depth of MIL-STD-498 Relate 12207, the CMMs, ISO 9000, and other standards of interest to the activities within your project Tailor all “standards” for your organization/project/contract Reconcile conflicts of language and guidance within different “standards” related to the same activity These are our views: If you have control or influence over the standards applied to your project (often old ones specified or none specified - often tailoring is possible) IEEE is the latest, most comprehensive standard. It incorporates all of ISO and the best parts of 498 (DIDs) and IEEE standards.

References - Capability Maturity Model For Software, Version 1.1, SEI-93-TR-24, Feb On web at - IEEE Standards Collection: Software Engineering Edition, Institute of Electrical and Electronics Engineers, Inc. New York, NY. See : Quality Management, International Organization for Standardization, See - The ISO 9000 Implementation Manual, Omneo- Oliver Wight Publications, In SEPO library. - U.S. Software Lifecycle Process Standards, Crosstalk, July See - Defense Acquisition Policy - A More Flexible Management Approach. Program Manager magazine, July-August See - Software Engineering Standards - A User's Road Map. IEEE Computer Society, Nov See

An Introduction to IEEE/EIA 12207

Similar presentations

Presentation on theme: "An Introduction to IEEE/EIA 12207"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

An Introduction to IEEE/EIA 12207

Similar presentations

Presentation on theme: "An Introduction to IEEE/EIA 12207"— Presentation transcript:

Similar presentations

About project

Feedback