IEEE Std 1058-1998
(Revision and redesignation of IEEE Std 1058.1-1987,
incorporating IEEE Std 1058-1998 and
IEEE Std 1058a-1998)
IEEE Standard for Software Project
Management Plans
Sponsor
Software Engineering Standards Committee
of the
IEEE Computer Society
Approved 8 December 1998
IEEE-SA Standards Board
Abstract: The format and contents of software project management plans, applicable to any type or size of
software project, are described. The elements that should appear in all software project management plans
are identified.
Keywords: management plans, software project management plans
The Institute of Electrical and Electronics Engineers, Inc.
345 East 47th Street, New York, NY 10017-2394, USA
Copyright © 1998 by the Institute of Electrical and lectronics Engineers, Inc.
All rights reserved. Published 22 December 1998. Printed in the United States of America.
Print:
PDF:
ISBN 0-7381-1447-2
ISBN 0-7381-1448-0
SH94690
SS94690
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written
permission of the publisher.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of
the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve voluntarily and
without compensation. They are not necessarily members of the Institute. The standards developed within IEEE
represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of
IEEE that have expressed an interest in participating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other
ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE
Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change
brought about through developments in the state of the art and comments received from users of the standard. Every
IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more
than five years old and has not been reaffirmed, it is reasonable to conclude that its contents, although still of some
value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the
latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation
with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to
specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate
action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is
important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason,
IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant
response to interpretation requests except in those cases where the matter has previously received formal
consideration.
Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
Note: Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for
which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of
those patents that are brought to its attention.
Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute
of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center.
To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood
Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for
educational classroom use can also be obtained through the Copyright Clearance Center.
Introduction
(This introduction is not part of IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans.)
Overview
This standard contains four clauses. Clause 1 defines the scope and purpose of the standard. Clause 2 provides
references to other IEEE standards that should be followed when applying this standard. Clause 3 provides definitions
of terms that are used throughout the standard. Clause 4 contains an overview and detailed specification of the
standard, including required components that shall be included, and optional components that may be included in
software project management plans (SPMPs) based on this standard. The sequence of the elements presented in
Clause 4 does not imply that SPMPs must be developed in the order of presentation. In most instances, SPMPs based
on this standard will be developed by repeated iteration and refinement of the various elements in the plan.
Purpose
This standard specifies the format and content of SPMPs. This standard does not specify the exact techniques to be
used in developing an SPMP, nor does it provide examples of SPMPs. Each organization using this standard should
develop a set of practices and procedures to provide detailed guidance for preparing and updating of SPMPs based on
this standard. These practices and procedures should take into account the environmental, organizational, and political
factors that influence application of the standard.
Not all software projects are concerned with development of source code for a new software product. Some software
projects consist of a feasibility study and definition of product requirements. Other software projects terminate upon
completion of product design, and some projects are concerned with major modifications to existing software
products. This standard is applicable to all types of software projects; applicability is not limited to projects that
develop source code for new products. Project size or type of software product does not limit application of this
standard. Small projects may require less formality in planning than large projects, but all components of the standard
should be addressed by every software project.
Software projects are sometimes component parts of larger projects. In these cases, the SPMP may be a separate
component of a larger plan or it may be merged into a system-level or business-level project management plan.
Audience
This standard is intended for use by software project managers and other personnel who prepare and update project
plans and monitor adherence to those plans.
Evolution of plans
Developing the initial version of the SPMP should be one of the first activities to be completed in a software project.
As the project evolves the nature of the work to be done will be better understood and plans will become more detailed.
Thus, each version of the plan should be placed under configuration management, and each version should contain a
schedule for subsequent updates to the plan.
Terminology
This standard follows the IEEE Standards Style Manual. In particular, the word shall is used to indicate mandatory
requirements to be strictly followed in order to conform to the standard and from which no deviation is permitted.
The word should is used to indicate that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or
that (in the negative form) a certain course of action is deprecated but not prohibited.
Copyright © 1998 IEEE. All rights reserved.
iii
The word may is used to indicate a course of action permissible within the limits of the standard.
The word can is used for statements of possibility and capability, whether material, physical, or causal.
History
The project authorization request for development of this standard was approved by the IEEE Standards Board on
13 December 1984. The first version of this standard (IEEE Std 1058.1-1987) was approved on 10 December 1987.
The standard was reaffirmed 2 December 1993. IEEE Std 1058a was approved by the IEEE-SA Standards Board on
17 September 1998; the revision of the full standard was approved on 8 December 1998. The changes in this version
of the standard are based on comments from users of the 1987 standard and the desire for conformance with IEEE/EIA
12207.0-1996.
Contributors
This standard was developed by the Software Project Management Plans Working Group of the Software Engineering
Standards Committee of the Computer Society of the IEEE. The following individuals contributed to the development
of this standard:
Richard E. Fairley
John M. Glabas
Richard H. Thayer
The following persons were on the balloting committee of IEEE Std 1058a:
Torben Aabo
T. J. Al-Hussaini
R. W. Allen
Leo Beltracchi
H. Ronald Berlack
Richard E. Biehl
Juris Borzovs
David W. Burnett
Edward R. Byrne
Michael Caldwell
Keith Chan
Antonio M. Cicu
Theo Clarke
François Coallier
Virgil Lee Cooper
W. W. Geoff Cozens
Paul R. Croll
Thomas Crowley
Geoffrey Darnton
Taz Daughtrey
Raymond Day
Bostjan K. Derganc
Sanjay Dewal
Perry R. DeWeese
Sherman Eagles
Christof Ebert
William Eventoff
Jonathan H. Fairclough
Richard E. Fairley
John W. Fendrich
Jay Forster
Kirby Fortenberry
Eva Freund
Karol Fruehauf
Barry L. Garner
Marilyn Ginsberg-Finner
John Garth Glynn
iv
Julio Gonzalez-Sanz
Lewis Gray
L. M. Gunther
David A. Gustafson
Jon D. Hagar
John Harauz
Rob Harker
Robert T. Harley
Herbert Hecht
William Hefley
Mark Heinrich
Debra Herrmann
Umesh P. Hiriyannaiah
Peter L. Hung
George Jackelen
David Johnson
Frank V. Jorgensen
Vladan V. Jovanovic
William S. Junk
George X. Kambic
Ron S. Kenett
Judith S. Kerner
Robert J. Kierzyk
Thomas M. Kurihara
John B. Lane
J. Dennis Lawrence
Mary Leatherman
Randal Leavitt
William M. Lively
James J. Longbucco
Stan Magee
David Maibor
Robert A. Martin
Mike McAndrew
Patrick D. McCray
James W. Moore
Pavol Navrat
Donald J. Ostrom
Mike Ottewill
Indradeb P. Pal
Mark Paulk
John G. Phippen
Alex Polack
Peter T. Poon
Lawrence S. Przybylski
Kenneth R. Ptack
Larry K. Reed
Donald J. Reifer
Annette D. Reilly
Dennis Rilling
R. Waldo Roth
Andrew P. Sage
Helmut Sandmayr
Stephen R. Schach
Norman Schneidewind
David J. Schultz
Lisa A. Selmon
Robert W. Shillato
David M. Siefert
Lynn J. Simms
Carl A. Singer
Melford E. Smyre
Alfred R. Sorkowitz
Julia. Stesney
Fred J. Strauss
Christine Brown Strysik
Toru Takeshita
Richard H. Thayer
Booker Thomas
Patricia Trellue
Mark-Rene Uchida
Theodore J. Urbanowicz
Glenn D. Venables
Delores Wallace
Copyright © 1998 IEEE. All rights reserved.
John W. Walz
Camille S. White-Partain
Scott A. Whitmire
P. A. Wolfgang
Paul R. Work
Natalie C. Yopconka
Janusz Zalewski
Geraldine Zimmerman
Peter F. Zoll
The following persons were on the balloting group of IEEE Std 1058.1 (renumbered as 1058):
Syed Ali
Theodore K. Atchinson
H. Ronald Berlack
Richard E. Biehl
Juris Borzovs
David W. Burnett
James E. Cardow
Leslie Chambers
Keith Chan
Antonio M. Cicu
Theo Clarke
Rosemary Coleman
Darrell Cooksey
Virgil Lee Cooper
W. W. Geoff Cozens
Paul R. Croll
Thomas Crowley
Taz Daughtrey
Hillary Davidson
Bostjan K. Derganc
Perry R. DeWeese
Audrey Dorofee
Carl Einar Dragstedt
Jonathan H. Fairclough
Richard E. Fairley
John W. Fendrich
Kirby Fortenberry
Eva Freund
Karol Fruehauf
Roger U. Fujii
Barry L. Garner
Marilyn Ginsberg-Finner
John Garth Glynn
Julio Gonzalez-Sanz
Donald Gotterbarn
L. M. Gunther
Robert T. Harley
William Hefley
Manfred Hein
Debra Herrmann
S. H. Stephen Huang
George Jackelen
Frank V. Jorgensen
Vladan V. Jovanovic
William S. Junk
George X. Kambic
Diana Kang
Ron S. Kenett
Judith S. Kerner
Robert J. Kierzyk
Shaye Koenig
Thomas M. Kurihara
John B. Lane
J. Dennis Lawrence
Randal Leavitt
Michael Lines
Dieter Look
John Lord
Stan Magee
Tomoo Matsubara
Patrick D. McCray
Russell McDowell
Sue McGrath
Jerome W. Mersky
Alan Miller
James W. Moore
Pavol Navrat
Mike Ottewill
David E. Peercy
John G. Phippen
Peter T. Poon
Kenneth R. Ptack
Annette D. Reilly
Andrew P. Sage
Helmut Sandmayr
Norman Schneidewind
David J. Schultz
Lisa A. Selmon
Robert W. Shillato
Lynn J. Simms
Carl A. Singer
James M. Sivak
Alfred R. Sorkowitz
Julia Stesney
Fred J. Strauss
Christine Brown Strysik
Toru Takeshita
Richard H. Thayer
Douglas H. Thiele
Booker Thomas
Patricia Trellue
Leonard L. Tripp
Mark-Rene Uchida
Theodore J. Urbanowicz
Andre Villas-Boas
Udo Voges
Ronald L. Wade
Scott A. Whitmire
P. A. Wolfgang
Paul R. Work
Natalie C. Yopconka
Geraldine Zimmerman
The IEEE-SA Standards Board approved IEEE Std 1058a on 16 September 1998. When it approved IEEE Std 1058 on
8 December 1998, it had the following membership:
Richard J. Holleman, Chair
Donald N. Heirman, Vice Chair
Satish K. Aggarwal
Clyde R. Camp
James T. Carlo
Gary R. Engmann
Harold E. Epstein
Jay Forster*
Thomas F. Garrity
Ruben D. Garzon
Judith Gorman, Secretary
James H. Gurney
Jim D. Isaak
Lowell G. Johnson
Robert Kennelly
E. G. “Al” Kiener
Joseph L. Koepfinger*
Stephen R. Lambert
Jim Logothetis
Donald C. Loughry
L. Bruce McClung
Louis-François Pau
Ronald C. Petersen
Gerald H. Peterson
John B. Posey
Gary S. Robinson
Hans E. Weinrich
Donald W. Zipse
*Member Emeritus
Kristin Dittmann
IEEE Standards Project Editor
Copyright © 1998 IEEE. All rights reserved.
v
Contents
1.
Overview .............................................................................................................................................................1
2.
References ...........................................................................................................................................................2
3.
Definitions...........................................................................................................................................................2
4.
Elements of the software project management plan ...........................................................................................3
4.1 Overview (Clause 1 of the SPMP) ............................................................................................................. 5
4.2 References (Clause 2 of the SPMP) ........................................................................................................... 6
4.3 Definitions (Clause 3 of the SPMP)........................................................................................................... 6
4.4 Project organization (Clause 4 of the SPMP) ............................................................................................ 6
4.5 Managerial process plans (Clause 5 of the SPMP) .................................................................................... 6
4.6 Technical process plans (Clause 6 of the SPMP)..................................................................................... 10
4.7 Supporting process plans (Clause 7 of the SPMP) .................................................................................. 10
4.8 Additional plans (Clause 8 of the SPMP) ................................................................................................ 12
4.9 Plan annexes............................................................................................................................................. 12
4.10 Plan index................................................................................................................................................. 12
Annex A (informative) Bibliography...........................................................................................................................13
Annex B (informative) Guidelines for compliance with IEEE/EIA 12207.1-1997.....................................................14
vi
Copyright © 1998 IEEE. All rights reserved.
IEEE Standard for Software Project
Management Plans
1. Overview
This standard prescribes the format and content of software project management plans (SPMPs). An SPMP is the
controlling document for managing a software project; it defines the technical and managerial processes necessary to
develop software work products that satisfy the product requirements.
The readers of this document are referred to Annex B for guidelines for using this document to meet the requirements
of IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information Technology—Software life cycle processes—Life cycle
data.
This standard may be applied to any type of software project. Use of this standard is not restricted by the size,
complexity, or criticality of the software product. This standard is applicable to all forms of product delivery media,
including traditional source code, firmware, embedded systems code, programmable logic arrays, and software-insilicon. This standard can be applied to any, or all, phases of a software product life cycle.
This standard identifies the elements that should appear in all SPMPs. There are two types of compliance to this
standard: format compliance, in which the exact format and contents of this standard are followed in a project plan;
and content compliance, in which the contents of this standard are rearranged in a project plan. In the case of content
compliance, a mapping should be provided to map the content-compliant project plan into the various clauses and
subclauses of this standard. Project plans that conform to the earlier version of this standard, IEEE Std 1058.1-1987,
may claim partial content-compliance with this standard; this is the only type of partial content-compliance allowed.
All compliant project plans must be titled “Software Project Management Plan.”
Project plans based on this standard may incorporate additional elements by appending additional clauses or
subclauses. The various clauses and subclauses of an SPMP conformant to this standard may be included in the plan
by direct incorporation or by reference to other plans. Access to plans incorporated by reference shall be provided for
all project stakeholders.
Some organizations may have generic project plans based on this standard, so that development of a particular project
plan will involve tailoring of the generic plan in areas such as the process model, supporting processes, and
infrastructure, and adding project-unique elements such as schedule, budget, work activities, and risk management
plan.
Copyright © 1998 IEEE. All rights reserved.
1
IEEE
Std 1058-1998
IEEE STANDARD FOR
2. References
This standard shall be used in conjunction with the following publication. When the following standard is superseded
by an approved revision, the revision shall apply.
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.1
3. Definitions
The definitions listed here establish meanings within the context of this standard. Definitions of other terms that may
be appropriate within the context of this standard can be found in IEEE Std 610.12-1990.
3.1 acquirer: The individual or organization that specifies requirements for and accepts delivery of a new or modified
software product and its documentation. The acquirer may be internal or external to the supplier organization.
Acquisition of a software product may involve, but does not necessarily require, a legal contract or a financial
transaction between acquirer and supplier.
3.2 baseline: A work product that has been formally reviewed and accepted by the involved parties. A baseline should
be changed only through formal configuration management procedures. Some baselines may be project deliverables
while others provide the basis for further work.
3.3 milestone: A scheduled event used to measure progress. Examples of major milestones for software projects may
include an acquirer or managerial sign-off, baselining of a specification, completion of system integration, and product
delivery. Minor milestones might include baselining of a software module or completion of a chapter of the user’s
manual.
3.4 project agreement: A document or set of documents baselined by the acquirer and the supplier that specifies the
conditions under which the project will be conducted. A project agreement may include items such as the scope,
objectives, assumptions, management interfaces, risks, staffing plan, resource requirements, price, schedule, resource
and budget allocations, project deliverables, and acceptance criteria for the project deliverables. Documents in a
project agreement may include some or all of the following: a contract, a statement of work, user requirements, system
engineering specifications, software requirements specifications, a software project management plan, supporting
process plans, a business plan, a project charter, or a memo of understanding.
3.5 project deliverable: A work product to be delivered to the acquirer. Quantities, delivery dates, and delivery
locations are specified in a project agreement. Project deliverables may include the following: operational
requirements, functional specifications, design documentation, source code, object code, test results, installation
instructions, training aids, user’s manuals, product development tools, and maintenance documentation. Project
deliverables may be self-contained or may be part of a larger system’s deliverables.
3.6 software project: The set of work activities, both technical and managerial, required to satisfy the terms and
conditions of a project agreement. A software project should have specific starting and ending dates, well-defined
objectives and constraints, established responsibilities, and a budget and schedule. A software project may be selfcontained or may be part of a larger project. In some cases, a software project may span only a portion of the software
development cycle. In other cases, a software project may span many years and consist of numerous subprojects, each
being a well-defined and self-contained software project.
3.7 supplier: An organization that develops some or all of the project deliverables for an acquirer. Suppliers may
include organizations that have primary responsibility for project deliverables and subcontractors that deliver some
part of the project deliverables to a primary supplier. In the latter case, the primary supplier is also an acquirer.
1IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-
1331, USA (http://standards.ieee.org/).
2
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE PROJECT MANAGEMENT PLANS
IEEE
Std 1058-1998
3.8 supporting process: A collection of work activities that span the entire duration of a software project. Examples
of supporting processes include software documentation, quality assurance, configuration management, software
reviews, audit processes, and problem resolution activities.
3.9 work activity: A collection of work tasks spanning a fixed duration within the schedule of a software project.
Work activities may contain other work activities, as in a work breakdown structure. The lowest-level work activities
in a hierarchy of activities are work tasks. Typical work activities include project planning, requirements specification,
software design, implementation, and testing.
3.10 work package: A specification of the work that must be accomplished to complete a work task. A work package
should have a unique name and identifier, preconditions for initiating the work, staffing requirements, other needed
resources, work products to be generated, estimated duration, risks factors, predecessor and successor work tasks, any
special considerations for the work, and the completion criteria for the work package—including quality criteria for
the work products to be generated.
3.11 work product: Any tangible item produced during the process of developing or modifying software. Examples
of work products include the project plan, supporting process requirements, design documentation, source code, test
plans, meeting minutes, schedules, budgets, and problem reports. Some subset of the work products will be baselined
and some will form the set of project deliverables.
3.12 work task: The smallest unit of work subject to management accountability. A work task must be small enough
to allow adequate planning and control of a software project, but large enough to avoid micro-management. The
specification of work to be accomplished in completing a work task should be documented in a work package. Related
work tasks should be grouped to form supporting processes and work activities.
4. Elements of the software project management plan
The individual or organization responsible for a software project shall also be responsible for the software project
management plan (hereafter referred to as the SPMP). This clause of the standard describes each of the elements of an
SPMP, as shown in Figure 1.
The ordering of elements presented in Figure 1 is not meant to imply that the clauses and subclauses must be
developed in that order. The order of elements is intended for ease of reading, presentation, and use, and not as a guide
to the order of preparation of the various elements of an SPMP. The various clauses and subclauses of an SPMP may
be included by direct incorporation or by reference to other plans and documents.
Detailed descriptions of each clause and subclause in an SPMP are presented in 4.1 through 4.7 of this standard.
Certain additional plans may be included in an SPMP. Additional plans are specified in 4.8.
Each version of an SPMP based on this standard shall contain a title page, a signature page, and a change history. The
title page shall contain the date of issue, a unique identifier (draft number, baseline version number), and identification
of the issuing organization. The signature page shall contain the signature(s) of the persons responsible for approving
the SPMP. The change history shall include the project name, version number of the plan, date of release, a list of
pages that have been changed in the current version of the plan, a brief statement describing the nature of changes
incorporated into this version of the plan, and a list of version numbers and dates of release of all previous versions of
the plan.
The preface of the SPMP shall describe the scope and context of the SPMP and identify the intended audience for the
SPMP. A table of contents, and lists of figures and tables that appear in the SPMP shall be included, as indicated in
Figure 1.
Copyright © 1998 IEEE. All rights reserved.
3
IEEE
Std 1058-1998
IEEE STANDARD FOR
Figure 1—Format of a software project management plan
4
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE PROJECT MANAGEMENT PLANS
IEEE
Std 1058-1998
4.1 Overview (Clause 1 of the SPMP)
This clause of the SPMP shall provide an overview of the purpose, scope, and objectives of the project, the project
assumptions and constraints, a list of project deliverables, a summary of the project schedule and budget, and the plan
for evolution of the SPMP.
4.1.1 Project summary (Subclause 1.1 of the SPMP)
4.1.1.1 Purpose, scope, and objectives (Subclause 1.1.1 of the SPMP)
This subclause of the SPMP shall define the purpose, scope, and objectives of the project and the products to be
delivered. This subclause should also describe any considerations of scope or objectives to be excluded from the
project or the resulting product. The statement of scope shall be consistent with similar statements in the project
agreement and other relevant system-level or business-level documents.
This subclause of the SPMP shall also provide a brief statement of the business or system needs to be satisfied by the
project, with a concise summary of the project objectives, the products to be delivered to satisfy those objectives, and
the methods by which satisfaction will be determined. The project statement of purpose shall describe the relationship
of this project to other projects, and, as appropriate, how this project will be integrated with other projects or ongoing
work processes.
A reference to the official statement of product requirements shall be provided in this subclause of the SPMP.
4.1.1.2 Assumptions and constraints (Subclause 1.1.2 of the SPMP)
This subclause of the SPMP shall describe the assumptions on which the project is based and imposed constraints on
project factors such as the schedule, budget, resources, software to be reused, acquirer software to be incorporated,
technology to be employed, and product interfaces to other products.
4.1.1.3 Project deliverables (Subclause 1.1.3 of the SPMP)
This subclause of the SPMP shall list the work products that will be delivered to the acquirer, the delivery dates,
delivery locations, and quantities required to satisfy the terms of the project agreement. In addition, this subclause
shall specify the delivery media and any special instructions for packaging and handling. The list of project
deliverables may be incorporated into the SPMP directly or by reference to an external document such as a contract
data requirements list (CDRL) or a product parts list (PPL).
4.1.1.4 Schedule and budget summary (Subclause 1.1.4 of the SPMP)
This subclause of the SPMP shall provide a summary of the schedule and budget for the software project. The level of
detail should be restricted to an itemization of the major work activities and supporting processes as, for example,
those depicted by the top level of the work breakdown structure.
4.1.2 Evolution of the SPMP (Subclause 1.2 of the SPMP)
This subclause of the SPMP shall specify the plans for producing both scheduled and unscheduled updates to the
SPMP. Methods of disseminating the updates shall be specified. This subclause shall also specify the mechanisms used
to place the initial version of the SPMP under configuration management and to control subsequent changes to the
SPMP.
Copyright © 1998 IEEE. All rights reserved.
5
IEEE
Std 1058-1998
IEEE STANDARD FOR
4.2 References (Clause 2 of the SPMP)
This clause of the SPMP shall provide a complete list of all documents and other sources of information referenced in
the SPMP. Each document should be identified by title, report number, date, author, path/name for electronic access,
and publishing organization. Other sources of information, such as electronic files, shall be identified using unique
identifiers such as date and version number. Any deviations from referenced standards or policies shall be identified
and justifications shall be provided.
4.3 Definitions (Clause 3 of the SPMP)
This clause of the SPMP shall define, or provide references to, documents containing the definition of all terms and
acronyms required to properly understand the SPMP.
4.4 Project organization (Clause 4 of the SPMP)
This clause of the SPMP shall identify interfaces to organizational entities external to the project; describe the project’s
internal organizational structure; and define roles and responsibilities for the project.
4.4.1 External interfaces (Subclause 4.1 of the SPMP)
This subclause of the SPMP shall describe the organizational boundaries between the project and external entities.
This should include, but is not limited to, the following: the parent organization, the acquiring organization,
subcontracted organizations, and other organizational entities that interact with the project. Representations such as
organizational charts and diagrams may be used to depict the project’s external interfaces.
4.4.2 Internal structure (Subclause 4.2 of the SPMP)
This subclause of the SPMP shall describe the internal structure of the project organization to include the interfaces
among the units of the software development team. In addition, the organizational interfaces between the project and
organizational entities that provide supporting processes, such as configuration management, quality assurance, and
verification and validation, shall be specified in this subclause. Graphical devices such as organizational charts or
diagrams should be used to depict the lines of authority, responsibility, and communication within the project.
4.4.3 Roles and responsibilities (Subclause 4.3 of the SPMP)
This subclause of the SPMP shall identify and state the nature of each major work activity and supporting process and
identify the organizational units that are responsible for those processes and activities. A matrix of work activities and
supporting processes vs. organizational units may be used to depict project roles and responsibilities.
4.5 Managerial process plans (Clause 5 of the SPMP)
This clause of the SPMP shall specify the project management processes for the project. This clause shall be consistent
with the statement of project scope and shall include the project start-up plan, risk management plan, project work
plan, project control plan, and project closeout plan.
4.5.1 Project start-up plan (Subclause 5.1 of the SPMP)
This subclause of the SPMP shall specify the estimation plan, staffing plan, resource acquisition plan, and training
plan. Depending on the size and scope of the project, these plans may be incorporated directly or by reference to other
plans.
6
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE PROJECT MANAGEMENT PLANS
IEEE
Std 1058-1998
4.5.1.1 Estimation plan (Subclause 5.1.1 of the SPMP)
This subclause of the SPMP shall specify the cost and schedule for conducting the project as well as methods, tools,
and techniques used to estimate project cost, schedule, resource requirements, and associated confidence levels. In
addition, the basis of estimation shall be specified to include techniques such as analogy, rule of thumb, or local history
and the sources of data. This subclause shall also specify the methods, tools, and techniques that will be used to
periodically re-estimate the cost, schedule, and resources needed to complete the project. Re-estimation may be done
on a monthly basis and aperiodically as necessary.
4.5.1.2 Staffing plan (Subclause 5.1.2 of the SPMP)
This subclause of the SPMP shall specify the number of staff required by skill level, the project phases in which the
numbers of personnel and types of skills are needed, and the duration of need. In addition, this subclause shall specify
the sources of staff personnel; for example by internal transfer, new hire, or contracted. Resource Gantt charts,
resource histograms, spreadsheets, and tables may be used to depict the staffing plan by skill level, by project phase,
and by aggregations of skill levels and project phases.
4.5.1.3 Resource acquisition plan (Subclause 5.1.3 of the SPMP)
This subclause of the SPMP shall specify the plan for acquiring the resources in addition to personnel needed to
successfully complete the project. The resource acquisition plan should include a description of the resource
acquisition process, including assignment of responsibility for all aspects of resource acquisition. The plan should
include, but not be limited to, acquisition plans for equipment, computer hardware and software, training, service
contracts, transportation, facilities, and administrative and janitorial services. The plan should specify the points in the
project schedule when the various acquisition activities will be required. Constraints on acquiring the necessary
resources shall be specified. This subclause may be expanded into additional subclauses of the form 5.1.3.x to
accommodate acquisition plans for various types of resources to be acquired.
4.5.1.4 Project staff training plan (Subclause 5.1.4 of the SPMP)
This subclause of the SPMP shall specify the training needed to ensure that necessary skill levels in sufficient numbers
are available to successfully conduct the software project. The training schedule shall include the types of training to
be provided, numbers of personnel to be trained, entry and exit criteria for training, and the training method; for
example, lectures, consultations, mentoring, or computer-assisted training. The training plan should include training as
needed in both technical and managerial skills.
4.5.2 Work plan (Subclause 5.2 of the SPMP)
This clause of the SPMP shall specify the work activities, schedule, resources, and budget details for the software
project.
4.5.2.1 Work activities (Subclause 5.2.1 of the SPMP)
This subclause of the SPMP shall specify the various work activities to be performed in the software project. A work
breakdown structure shall be used to depict the work activities and the relationships among work activities. Work
activities should be decomposed to a level that exposes all project risk factors and allows accurate estimate of resource
requirements and schedule duration for each work activity. Work packages should be used to specify, for each work
activity, factors such as the necessary resources, estimated duration, work products to be produced, acceptance criteria
for the work products, and predecessor and successor work activities. The level of decomposition for different work
activities in the work breakdown structure may be different depending on factors such as the quality of the
requirements, familiarity of the work, and novelty of the technology to be used.
Copyright © 1998 IEEE. All rights reserved.
7
IEEE
Std 1058-1998
IEEE STANDARD FOR
4.5.2.2 Schedule allocation (Subclause 5.2.2 of the SPMP)
This subclause of the SPMP shall provide scheduling relationships among work activities in a manner that depicts the
time-sequencing constraints and illustrates opportunities for concurrent work activities. Any constraints on scheduling
of particular work activities caused by factors external to the project shall be indicated in the work activity schedule.
The schedule should include frequent milestones that can be assessed for achievement using objective indicators to
assess the scope and quality of work products completed at those milestones. Techniques for depicting schedule
relationships may include milestone charts, activity lists, activity Gantt charts, activity networks, critical path
networks, and PERT.
4.5.2.3 Resource allocation (Subclause 5.2.3 of the SPMP)
This subclause of the SPMP shall provide a detailed itemization of the resources allocated to each major work activity
in the project work breakdown structure. Resources shall include the numbers and required skill levels of personnel for
each work activity. Resource allocation may include, as appropriate, personnel by skill level and factors such as
computing resources, software tools, special testing and simulation facilities, and administrative support. A separate
line item should be provided for each type of resource for each work activity. A summary of resource requirements for
the various work activities should be collected from the work packages of the work breakdown structure and presented
in tabular form.
4.5.2.4 Budget allocation (Subclause 5.2.4 of the SPMP)
This subclause of the SPMP shall provide a detailed breakdown of necessary resource budgets for each of the major
work activities in the work breakdown structure. The activity budget shall include the estimated cost for activity
personnel and may include, as appropriate, costs for factors such as travel, meetings, computing resources, software
tools, special testing and simulation facilities, and administrative support. A separate line item shall be provided for
each type of resource in each activity budget. The work activity budget may be developed using a spreadsheet and
presented in tabular form.
4.5.3 Control plan (Subclause 5.3 of the SPMP)
This subclause of the SPMP shall specify the metrics, reporting mechanisms, and control procedures necessary to
measure, report, and control the product requirements, the project schedule, budget, and resources, and the quality of
work processes and work products. All elements of the control plan should be consistent with the organization’s
standards, policies, and procedures for project control as well as with any contractual agreements for project control.
4.5.3.1 Requirements control plan (Subclause 5.3.1 of the SPMP)
This subclause of the SPMP shall specify the control mechanisms for measuring, reporting, and controlling changes to
the product requirements. This subclause shall also specify the mechanisms to be used in assessing the impact of
requirements changes on product scope and quality, and the impacts of requirements changes on project schedule,
budget, resources, and risk factors. Configuration management mechanisms shall include change control procedures
and a change control board. Techniques that may be used for requirements control include traceability, prototyping and
modeling, impact analysis, and reviews.
4.5.3.2 Schedule control plan (Subclause 5.3.2 of the SPMP)
This subclause of the SPMP shall specify the control mechanisms to be used to measure the progress of work
completed at the major and minor project milestones, to compare actual progress to planned progress, and to
implement corrective action when actual progress does not conform to planned progress. The schedule control plan
shall specify the methods and tools that will be used to measure and control schedule progress. Achievement of
schedule milestones should be assessed using objective criteria to measure the scope and quality of work products
completed at each milestone.
8
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE PROJECT MANAGEMENT PLANS
IEEE
Std 1058-1998
4.5.3.3 Budget control plan (Subclause 5.3.3 of the SPMP)
This subclause of the SPMP shall specify the control mechanisms to be used to measure the cost of work completed,
compare planned cost to budgeted cost, and implement corrective action when actual cost does not conform to
budgeted cost. The budget control plan shall specify the intervals at which cost reporting will be done and the methods
and tools that will be used to manage the budget. The budget plan should include frequent milestones that can be
assessed for achievement using objective indicators to assess the scope and quality of work products completed at
those milestones. A mechanism such as earned value tracking should be used to report the budget and schedule plan,
schedule progress, and the cost of work completed.
4.5.3.4 Quality control plan (Subclause 5.3.4 of the SPMP)
This subclause of the SPMP shall specify the mechanisms to be used to measure and control the quality of the work
processes and the resulting work products. Quality control mechanisms may include quality assurance of work
processes, verification and validation, joint reviews, audits, and process assessment.
4.5.3.5 Reporting plan (Subclause 5.3.5 of the SPMP)
This subclause of the SPMP shall specify the reporting mechanisms, report formats, and information flows to be used
in communicating the status of requirements, schedule, budget, quality, and other desired or required status metrics
within the project and to entities external to the project. The methods, tools, and techniques of communication shall be
specified in this subclause. The frequency and detail of communications related to project measurement and control
shall be consistent with the project scope, criticality, risk, and visibility.
4.5.3.6 Metrics collection plan (Subclause 5.3.6 of the SPMP)
This subclause of the SPMP shall specify the methods, tools, and techniques to be used in collecting and retaining
project metrics. The metrics collection plan shall specify the metrics to be collected, the frequency of collection, and
the methods to be used in validating, analyzing, and reporting the metrics.
4.5.4 Risk management plan (Subclause 5.4 of the SPMP)
This subclause of the SPMP shall specify the risk management plan for identifying, analyzing, and prioritizing project
risk factors. This subclause shall also describe the procedures for contingency planning, and the methods to be used in
tracking the various risk factors, evaluating changes in the levels of risk factors, and the responses to those changes.
The risk management plan shall also specify plans for assessing initial risk factors and the ongoing identification,
assessment, and mitigation of risk factors throughout the life cycle of the project. This plan should describe risk
management work activities, procedures and schedules for performing those activities, documentation and reporting
requirements, organizations and personnel responsible for performing specific activities, and procedures for
communicating risks and risk status among the various acquirer, supplier, and subcontractor organizations. Risk
factors that should be considered include risks in the acquirer-supplier relationship, contractual risks, technological
risks, risks caused by the size and complexity of the product, risks in the development and target environments, risks
in personnel acquisition, skill levels and retention, risks to schedule and budget, and risks in achieving acquirer
acceptance of the product.
4.5.5 Project closeout plan (Subclause 5.5 of the SPMP)
This subclause of the SPMP shall contain the plans necessary to ensure orderly closeout of the software project. Items
in the closeout plan should include a staff reassignment plan, a plan for archiving project materials, a plan for postmortem debriefings of project personnel, and preparation of a final report to include lessons learned and analysis of
project objectives achieved.
Copyright © 1998 IEEE. All rights reserved.
9
IEEE
Std 1058-1998
IEEE STANDARD FOR
4.6 Technical process plans (Clause 6 of the SPMP)
This clause of the SPMP shall specify the development process model, the technical methods, tools, and techniques to
be used to develop the various work products; plans for establishing and maintaining the project infrastructure; and the
product acceptance plan.
4.6.1 Process model (Subclause 6.1 of the SPMP)
This subclause of the SPMP shall define the relationships among major project work activities and supporting
processes by specifying the flow of information and work products among activities and functions, the timing of work
products to be generated, reviews to be conducted, major milestones to be achieved, baselines to be established, project
deliverables to be completed, and required approvals that span the duration of the project. The process model for the
project shall include project initiation and project termination activities. To describe the process model, a combination
of graphical and textual notations may be used. Any tailoring of an organization’s standard process model for a project
shall be indicated in this subclause.
4.6.2 Methods, tools, and techniques (Subclause 6.2 of the SPMP)
This subclause of the SPMP shall specify the development methodologies, programming languages and other
notations, and the tools and techniques to be used to specify, design, build, test, integrate, document, deliver, modify
and maintain the project deliverable and nondeliverable work products. In addition, the technical standards, policies,
and procedures governing development and/or modification of the work products shall be specified.
4.6.3 Infrastructure plan (Subclause 6.3 of the SPMP)
This subclause of the SPMP shall specify the plan for establishing and maintaining the development environment
(hardware, operating system, network, and software), and the policies, procedures, standards, and facilities required to
conduct the software project. These resources may include workstations, local area networks, software tools for
analysis, design, implementation, testing, and project management, desks, office space, and provisions for physical
security, administrative personnel, and janitorial services.
4.6.4 Product acceptance plan (Subclause 6.4 of the SPMP)
This subclause of the SPMP shall specify the plan for acquirer acceptance of the deliverable work products generated
by the software project. Objective criteria for determining acceptability of the deliverable work products shall be
specified in this plan and a formal agreement of the acceptance criteria shall be signed by representatives of the
development organization and the acquiring organization. Any technical processes, methods, or tools required for
product acceptance shall be specified in the product acceptance plan. Methods such as testing, demonstration, analysis
and inspection should be specified in this plan.
4.7 Supporting process plans (Clause 7 of the SPMP)
This clause of the SPMP shall contain plans for the supporting processes that span the duration of the software project.
These plans shall include, but are not limited to, configuration management, verification and validation, software
documentation, quality assurance, reviews and audits, problem resolution, and subcontractor management. Plans for
supporting processes shall be developed to a level of detail consistent with the other clauses and subclauses of the
SPMP. In particular, the roles, responsibilities, authorities, schedule, budgets, resource requirements, risk factors, and
work products for each supporting process shall be specified. The nature and types of supporting processes required
may vary from project to project; however, the absence of a configuration management plan, verification and
validation plan, quality assurance plan, joint acquirer-supplier review plan, problem resolution plan, or subcontractor
management plan shall be explicitly justified in any SPMP that does not include them. Plans for supporting processes
may be incorporated directly into the SPMP or incorporated by reference to other plans.
10
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE PROJECT MANAGEMENT PLANS
IEEE
Std 1058-1998
4.7.1 Configuration management plan (Subclause 7.1 of the SPMP)
This subclause of the SPMP shall contain the configuration management plan for the software project, to include the
methods that will be used to provide configuration identification, control, status accounting, evaluation, and release
management. In addition, this subclause shall specify the processes of configuration management to include
procedures for initial baselining of work products, logging and analysis of change requests, change control board
procedures, tracking of changes in progress, and procedures for notifying concerned parties when baselines are first
established or later changed. The configuration management process should be supported by one or more automated
configuration management tools.
4.7.2 Verification and validation plan (Subclause 7.2 of the SPMP)
This subclause of the SPMP shall contain the verification and validation plan for the software project to include scope,
tools, techniques, and responsibilities for the verification and validation work activities. The organizational
relationships and degrees of independence between development activities and verification and validation activities
shall be specified. Verification planning should result in specification of techniques such as traceability, milestone
reviews, progress reviews, peer reviews, prototyping, simulation, and modeling. Validation planning should result in
specification of techniques such as testing, demonstration, analysis, and inspection. Automated tools to be used in
verification and validation should be specified.
4.7.3 Documentation plan (Subclause 7.3 of the SPMP)
This subclause of the SPMP shall contain the documentation plan for the software project, to include plans for
generating nondeliverable and deliverable work products. Organizational entities responsible for providing input
information, generating, and reviewing the various documents shall be specified in the documentation plan. Nondeliverable work products may include items such as requirements specifications, design documentation, traceability
matrices, test plans, meeting minutes and review reports. Deliverable work products may include source code, object
code, a user’s manual, an on-line help system, a regression test suite, a configuration library and configuration
management tool, principles of operation, a maintenance guide, or other items specified in subclause 1.1.3 of the
SPMP. The documentation plan should include a list of documents to be prepared, the controlling template or standard
for each document, who will prepare it, who will review it, due dates for review copy and initial baseline version, and
a distribution list for review copies and baseline versions.
4.7.4 Quality assurance plan (Subclause 7.4 of the SPMP)
This subclause of the SPMP shall provide the plans for assuring that the software project fulfills its commitments to the
software process and the software product as specified in the requirements specification, the SPMP, supporting plans,
and any standards, procedures, or guidelines to which the process or the product must adhere. Quality assurance
procedures may include analysis, inspections, reviews, audits, and assessments. The quality assurance plan should
indicate the relationships among the quality assurance, verification and validation, review, audit, configuration
management, system engineering, and assessment processes.
4.7.5 Reviews and audits plan (Subclause 7.5 of the SPMP)
This subclause of the SPMP shall specify the schedule, resources, and methods and procedures to be used in
conducting project reviews and audits. The plan should specify plans for joint acquirer-supplier reviews, management
progress reviews, developer peer reviews, quality assurance audits, and acquirer-conducted reviews and audits. The
plan should list the external agencies that approve or regulate any product of the project.
4.7.6 Problem resolution plan (Subclause 7.6 of the SPMP)
This subclause of the SPMP shall specify the resources, methods, tools, techniques, and procedures to be used in
reporting, analyzing, prioritizing, and processing software problem reports generated during the project. The problem
resolution plan should indicate the roles of development, configuration management, the change control board, and
Copyright © 1998 IEEE. All rights reserved.
11
IEEE
Std 1058-1998
IEEE STANDARD FOR
verification and validation in problem resolution work activities. Effort devoted to problem reporting, analysis, and
resolution should be separately reported so that rework can be tracked and process improvement accomplished.
4.7.7 Subcontractor management plans (Subclause 7.7 of the SPMP)
This subclause of the SPMP shall contain plans for selecting and managing any subcontractors that may contribute
work products to the software project. The criteria for selecting subcontractors shall be specified and the management
plan for each subcontract shall be generated using a tailored version of this standard. Tailored plans should include the
items necessary to ensure successful completion of each subcontract. In particular, requirements management,
monitoring of technical progress, schedule and budget control, product acceptance criteria, and risk management
procedures shall be included in each subcontractor plan. Additional topics should be added as needed to ensure
successful completion of the subcontract. A reference to the official subcontract and prime contractor/subcontractor
points of contact shall be specified.
4.7.8 Process improvement plan (Subclause 7.8 of the SPMP)
This subclause of the SPMP shall include plans for periodically assessing the project, determining areas for
improvement, and implementing improvement plans. The process improvement plan should be closely related to the
problem resolution plan; for example, root cause analysis of recurring problems may lead to simple process
improvements that can significantly reduce rework during the remainder of the project. Implementation of
improvement plans should be examined to identify those processes that can be improved without serious disruptions
to an ongoing project and to identify those processes that can best be improved by process improvement initiatives at
the organizational level.
4.8 Additional plans (Clause 8 of the SPMP)
This clause of the SPMP shall contain additional plans required to satisfy product requirements and contractual terms.
Additional plans for a particular project may include plans for assuring that safety, privacy, and security requirements
for the product are met, special facilities or equipment, product installation plans, user training plans, integration plans,
data conversion plans, system transition plans, product maintenance plans, or product support plans.
4.9 Plan annexes
Annexes may be included, either directly or by reference to other documents, to provide supporting details that could
detract from the SPMP if included in the body of the SPMP.
4.10 Plan index
An index to the key terms and acronyms used throughout the SPMP is optional, but recommended to improve the
usability of the SPMP.
12
Copyright © 1998 IEEE. All rights reserved.
SOFTWARE PROJECT MANAGEMENT PLANS
IEEE
Std 1058-1998
Annex A
(informative)
Bibliography
The standards listed here should be consulted when applying this standard. The latest revisions should be consulted.
[B1] IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.
[B2] IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans.
[B3] IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation.
[B4] IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.
[B5] IEEE Std 1490-1998, IEEE Guide—Adoption of PMI Standard, A Guide to the Project Management Body of
Knowledge.
[B6] IEEE/EIA 12207.0-1996, IEEE/EIA Standard—Industry Implementation of ISO/IEC 12207: 1995, Standard for
Information Technology—Software life cycle processes.
[B7] IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information Technology—Software life cycle processes—Life
cycle data.
[B8] IEEE/EIA 12207.2-1997, IEEE/EIA Guide for Information Technology—Software life cycle processes—
Implementation considerations.
[B9] ISO/IEC 12119: 1994, Information technology—Software packages—Quality requirements and testing.
[B10] ISO/IEC 9126: 1991, Information technology—Software product evaluation—Quality characteristics and their
use.
Copyright © 1998 IEEE. All rights reserved.
13
IEEE
Std 1058-1998
IEEE STANDARD FOR
Annex B
(informative)
Guidelines for compliance with IEEE/EIA 12207.1-1997
B.1 Overview
The Software Engineering Standards Committee (SESC) of the IEEE Computer Society has endorsed the policy of
adopting international standards. In 1995, the international standard, ISO/IEC 12207, Information technology—
Software life cycle processes, was completed. The standard establishes a common framework for software life cycle
processes, with well-defined terminology, that can be referenced by the software industry.
In 1995 the SESC evaluated ISO/IEC 12207 and decided that the standard should be adopted and serve as the basis for
life cycle processes within the IEEE Software Engineering Collection. The IEEE adaptation of ISO/IEC 12207 is
IEEE/EIA 12207.0-1996. It contains ISO/IEC 12207 and the following additions: improved compliance approach, life
cycle process objectives, life cycle data objectives, and errata.
The implementation of ISO/IEC 12207 within the IEEE also includes the following:

IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information Technology—Software life cycle processes—
Life cycle data;

IEEE/EIA 12207.2-1997, IEEE/EIA Guide for Information Technology—Software life cycle processes—
Implementation considerations; and

Additions to 11 SESC standards (i.e., IEEE Stds 730, 828, 829, 830, 1012, 1016, 1058, 1062, 1219, 1233,
1362) to define the correlation between the data produced by existing SESC standards and the data produced
by the application of IEEE/EIA 12207.1-1997.
NOTE — Although IEEE/EIA 12207.1-1997 is a guide, it also contains provisions for application as a standard with specific
compliance requirements. This annex treats IEEE/EIA 12207.1-1997 as a standard.
In order to achieve compliance with both this standard and IEEE/EIA 12207.1-1997, it is essential that the user review
and satisfy the data requirements for both standards.
When this standard is directly referenced, the precedence for conformance is based upon this standard alone. When
this standard is referenced with the IEEE/EIA 12207.x standard series, the precedence for conformance is based upon
the directly referenced IEEE/EIA 12207.x standard, unless there is a statement that this standard has precedence.
B.1.1 Scope and purpose
Both this standard and IEEE/EIA 12207.1-1997 place requirements on an SPMP. The purpose of this annex is to
explain the relationship between the two sets of requirements so that users producing documents intended to comply
with both standards may do so.
B.2 Correlation
This clause explains the relationship between this standard and IEEE/EIA 12207.0-1996 in the following areas:
terminology, process, and life cycle data.
14
Copyright © 1998 IEEE. All rights reserved.
IEEE
Std 1058-1998
SOFTWARE PROJECT MANAGEMENT PLANS
B.2.1 Terminology correlation
The two standards use similar terms in similar ways. The concept of project management is present in IEEE/EIA
12207.0-1996 but it is embedded in two other processes: acquisition and supply. Hence, there is an acquisition project
and a supply project that, though related, may be done by different organizations.
B.2.2 Process correlation
This standard places no explicit requirements on process. However, the information required by its SPMP makes
implicit assumptions regarding process, similar to that of IEEE/EIA 12207, but limited to a software project.
Generally, fulfilling the implied process requirements of this standard would meet the requirements of IEEE/EIA
12207.0-1996 and would not violate its requirements.
B.2.3 Life cycle data correlation and SPMPs
The information required in an SPMP by this standard and the information required in an SPMP by IEEE/EIA
12207.1-1997 are similar. It is reasonable to expect that a single document could comply with both standards. The
main difference is that this standard specifies a particular format, while IEEE/EIA 12207.1-1997 does not. Details are
provided in Clause B.3 of this standard.
B.2.4 Life cycle data correlation between other data in IEEE/EIA 12207.1-1997 and
IEEE Std 1058-1998
Table B.1 correlates the life cycle data other than SPMP between this standard and IEEE/EIA 12207.1-1997. It
provides information to users of both standards.
Table B.1—Life cycle data correlation between other data in
IEEE/EIA 12207.1-1997 and IEEE Std 1058-1998
Information item(s)
IEEE/EIA 12207.01996 subclause
Kind of
documentation
IEEE/EIA 12207.11997 subclause
Corresponding
subclause of
IEEE Std 1058-1998
Management process
plans
7.1.2.1
Plan
—
4.5
Supplier selection
record—Proposal
evaluation criteria,
Requirements
compliance weighting
5.1.3.1
Record
—
4.7.7
B.3 Document compliance
This clause provides details substantiating a claim that an SPMP complying with this standard may achieve document
compliance with the SPMP prescribed in IEEE/EIA 12207.1-1997. The requirements for document compliance are
summarized in a single row of Table 1 of IEEE/EIA 12207.1-1997. That row is reproduced in Table B.2 of this standard.
Copyright © 1998 IEEE. All rights reserved.
15
IEEE
Std 1058-1998
IEEE STANDARD FOR
Table B.2—Summary of requirements for an SPMP
excerpted from Table 1 of IEEE/EIA 12207.1-1997
Information item(s)
Project management
plan
IEEE/EIA 12207.01996 subclause
5.2.4.3, 5.2.4.4,
5.2.4.5
Kind of
documentation
Plan
IEEE/EIA 12207.11997 subclause
6.11
References
IEEE Std 1012-1998;
IEEE Std 1058-1998;
IEEE Std 1074-1997;
EIA/IEEE J-STD 0161995, E.2.1;
ISO/IEC 9126: 1991;
ISO/IEC 12119: 1994;
SEI Continuous Risk
Management
Guidebook
The requirements for document compliance are discussed in the following subclauses:




B.3.1 discusses compliance with the information requirements noted in column 2 of Table B.2 as prescribed
by 6.2.1.1 of IEEE/EIA 12207.0-1996.
B.3.2 discusses compliance with the generic content guideline (the “kind” of document) noted in column 3 of
Table B.2 as a “plan.” The generic content guidelines for a “plan” appear in 5.2 of IEEE/EIA 12207.1-1997.
B.3.3 discusses compliance with the specific requirements for an SPMP noted in column 4 of Table B.2 as
prescribed by 6.11 of IEEE/EIA 12207.1-1997.
B.3.4 discusses compliance with the life cycle data objectives of Annex H of IEEE/EIA 12207.0-1996 as
described in 4.2 of IEEE/EIA 12207.1-1997.
B.3.1 Compliance with information requirements of IEEE/EIA 12207.0-1996
The information requirements for an SPMP are those prescribed by 5.2.4.3, 5.2.4.4, and 5.2.4.5 of IEEE/EIA 12207.01996. In this case, those requirements are substantively identical with those considered in B.3.3 of this standard.
B.3.2 Compliance with generic content guidelines of IEEE/EIA 12207.1-1997
The generic content guidelines for a “plan” in IEEE/EIA 12207.1-1997 are prescribed by 5.2 of IEEE/EIA 12207.11997. A complying plan shall achieve the purpose stated in 5.2.1 and include the information listed in 5.2.2 of IEEE/
EIA 12207.1-1997.
The purpose of a plan is as follows:
IEEE/EIA 12207.1-1997, subclause 5.2.1: Purpose: Define when, how, and by whom specific
activities are to be performed, including options and alternatives, as required.
Any plan complying with IEEE/EIA 12207.1-1997 shall satisfy the generic content requirements provided in 5.2.2 of
that standard. Table B.3 of this standard lists the generic content items and, where appropriate, references the
subclause of this standard that requires the same information.
16
Copyright © 1998 IEEE. All rights reserved.
IEEE
Std 1058-1998
SOFTWARE PROJECT MANAGEMENT PLANS
Table B.3—Coverage of generic plan requirements by IEEE Std 1058-1998
IEEE/EIA 12207.1-1997
generic content
Corresponding clause of
IEEE Std 1058-1998
Additions to requirements of
IEEE Std 1058-1998
a) Date of issue and status
Front pages of outline
—
b) Scope
4.1.1.1 Purpose, scope, and
objectives
—
c) Issuing organization
Front pages of outline
—
d) References
4.2 References
—
e) Approval authority
4.6.1 Process model
—
f) Planned activities and tasks
4.5.2 Work plan
—
g) Macro references (policies or laws
that give rise to the need for this
plan)
4.2 References
—
h) Micro references (other plans or
task descriptions that elaborate
details of this plan)
4.2 References
—
i) Schedules
4.5.2.2 Schedule allocation
4.5.5 Project closeout plan
—
j) Estimates
4.5.2.4 Budget allocation
—
k) Resources and their allocation
4.5.2.3 Resource allocation
—
l) Responsibilities and authority
4.4.3 Roles and responsibilities
—
m) Risks
4.5.4 Risk management plan
—
n) Quality control measures
NOTE — This includes quality
control of the SPMP
itself.
4.1.2 Evolution of the SPMP
4.5.3.1 Requirements control plan
4.5.3.4 Quality control plan
—
o) Cost
4.5.2.4 Budget allocation
4.5.3.3 Budget control plan
—
p) Interfaces among parties involved
4.4.1 External interfaces
4.4.2 Internal structure
—
q) Environment/infrastructure
(including safety needs)
4.5.1.3 Resource acquisition plan
4.5.2.3 Resource allocation
4.6.3 Infrastructure plan
4.8 Additional plans
—
r) Training
4.5.1.4 Project staff training plan
—
s) Glossary
4.3 Definitions
—
t) Change procedures and history
NOTE — This includes the change
procedures for the SPMP
itself.
Front pages of outline
Evolution of the plan
—
Copyright © 1998 IEEE. All rights reserved.
17
IEEE
Std 1058-1998
IEEE STANDARD FOR
B.3.3 Compliance with specific content requirements of IEEE/EIA 12207.1-1997
The specific content requirements for an SPMP in IEEE/EIA Std 12207.1-1997 are prescribed by 6.11 of IEEE/EIA
12207.1-1997. A compliant SPMP shall achieve the purpose stated in 6.11.1 and include the information listed in
6.11.3 of IEEE/EIA 12207.1-1997.
The purpose of the SPMP is as follows:
IEEE/EIA 12207.1-1997, subclause 6.11.1: Purpose: Define the technical and managerial processes
necessary to satisfy project requirements.
An SPMP complying with IEEE/EIA 12207.1-1997 shall satisfy the specific content requirements provided in 6.11.3
of that standard. The specific content requirements of 6.11.3 of IEEE/EIA 12207.1-1997 reiterate the generic content
requirements and specify the generic requirements that must be satisfied for several activities. The activities are listed
in Table B.4 of this standard along with the reference to the clause of this standard that specifically deals with the
activity.
Table B.4—Coverage of specific SPMP requirements by IEEE Std 1058-1998
IEEE/EIA 12207.1-1997
specific content
18
Corresponding clauses of
IEEE Std 1058-1998
Additions to requirements of
IEEE Std 1058-1998
a) Generic plan for managing the
project
See Table B.3
—
b) Project organizational structure
showing authority and responsibility
of each organizational unit,
including external organizations
4.4 Project organization
—
c) Engineering environment (for
development, operation or
maintenance, as applicable),
including test environment, library,
equipment, facilities, standards,
procedures, and tools
4.5.2.3 Resource allocation
4.6.3 Infrastructure plan
—
d) Work breakdown structure of the
life cycle processes and activities,
including the software products,
software services and nondeliverable
items to be performed, budgets,
staffing, physical resources,
software size, and schedules
associated with the tasks
4.5.2 Work plan
—
e) Management of the quality
characteristics of the software
products or services (Separate plans
for quality may be developed.)
4.5.3.4 Quality control plan
—
f) Management of safety, security,
privacy, and other critical
requirements of the software
products or services (Separate plans
for safety and security may be
developed.)
4.5.3.1 Requirements control plan
4.8 Additional plans
—
Copyright © 1998 IEEE. All rights reserved.
IEEE
Std 1058-1998
SOFTWARE PROJECT MANAGEMENT PLANS
Table B.4—Coverage of specific SPMP requirements by IEEE Std 1058-1998 (Continued)
IEEE/EIA 12207.1-1997
specific content
Corresponding clauses of
IEEE Std 1058-1998
Additions to requirements of
IEEE Std 1058-1998
g) Subcontractor management,
including subcontractor selection
and involvement between the
subcontractor and the acquirer, if
any
4.7.7 Subcontractor management
plan
—
h) Quality assurance
4.7.4 Quality assurance plan
—
i) Verification and validation,
including the approach for
interfacing with the verification and
validation agent, if specified
4.7.2 Verification and validation
plan
—
j) Acquirer involvement (i.e., joint
reviews, audits, informal meetings,
reporting, modification and change,
implementation, approval,
acceptance, access to facilities)
4.4.3 Roles and responsibilities
4.7.5 Reviews and audits
—
k) User involvement (i.e.,
requirements setting exercises,
prototype demonstrations and
evaluations)
4.4.3 Roles and responsibilities
4.6.4 Product Acceptance Plan
4.7.5 Reviews and Audits
—
l) Risk management (i.e., the
management of the areas of the
project that involve technical, cost,
and schedule risks)
4.5.4 Risk Management Plan
—
m) Security policy (i.e., the rules for
need-to-know and access-toinformation at each project
organizational level)
4.6.1 Process Model
4.6.2 Infrastructure Plan
4.8 Additional Plans
—
n) Approval required by such means
as regulations, required
certifications, proprietary, usage,
ownership, warranty and licensing
rights
4.6.1 Process model
4.7.5 Reviews and audits
—
o) Means for scheduling, tracking,
and reporting
4.5.3.2 Schedule control plan
4.5.3.5 Reporting plan
—
p) Training of personnel
4.5.1.4 Project staff training plan
—
q) Software life cycle model
4.6.1 Process model
—
r) Configuration management
4.7.1 Configuration management
plan
—
Copyright © 1998 IEEE. All rights reserved.
19
IEEE
Std 1058-1998
B.3.4 Compliance with life cycle data characteristics objectives
In addition to the content requirements, life cycle data shall be managed in accordance with the objectives provided in
Annex H of IEEE/EIA 12207.0-1996.
NOTE — The information items covered by this standard include plans and provisions for creating software life cycle data related
to the basic “management data” in H.4 of IEEE/EIA 12207.0-1996. It provides for the following: management data,
management plans, status reports, management indicators, criteria and key decision rationale, and contract and other
procurement information.
B.4 Conclusion
The analysis documented in this annex suggests that any SPMP complying with this standard will comply with the
requirements of an SPMP in IEEE/EIA 12207.1-1997. In addition, to comply with IEEE/EIA 12207.1-1997, an SPMP
shall support the life cycle data objectives of Annex H of IEEE/EIA 12207.0-1996.
20
Copyright © 1998 IEEE All rights reserved