Prepared by the Software Project Management Plans Working Group of the

Software Engineering Standards Committee

Copyright © 1998 by the Institute of Electrical and Electronics Engineers, Inc.

345 East 47th Street

New York, NY 10017, USA

All Rights Reserved.

This is an unapproved draft of a proposed IEEE Standard, subject to change. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities. If this document is to be sub mitted to ISO or IEC, notification shall be given to the IEEE Copyright Administrator. Permission is also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position. Other en tities seeking permission to reproduce portions of this document for these or other uses must contact the IEEE Standards Department for the appropriate license. Use of information contained in the unapproved draft is at your own risk.

IEEE Standards Department
Copyright and Permissions
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331, USA

Introduction

(This Introduction is not part of P1058 Standard for Software Project Management Plans).

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 us ed 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 based on this st andard. The sequence of the elements presented in Clause 4 does not imply that software project management plans must be developed in the order of presentation. In most instances, software project management plans based on this standard will be develope d by repeated iteration and refinement of the various elements in the plan.

This standard specifies the format and content of software project management plans. This standard does not specify the exact techniques to be used in developing a software project management plan, nor does it provide examples of software project manag ement plans. Each organization using this standard should develop a set of practices and procedures to provide detailed guidance for preparing and updating of software project management plans based on this standard. These practices and procedures shoul d 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 pro duct 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. Proje ct 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 software project management plan may be a separate component of a larger plan or it may be merged into a system-level or business-level project management plan.

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.

Developing the initial version of the software project management plan 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 becom e 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.

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 t he negative form) a certain course of action is deprecated but not prohibited.

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.

Richard E. Fairley

Richard H. Thayer

John M. Glabas

CLAUSE PAGE

Annexes

This standard prescribes the format and content of software project management plans. A software project management plan is the controlling document for managing a software project; it defines the technical and managerial processes necessary to develo p software work products that satisfy the product requirements.

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 traditi onal source code, firmware, embedded systems code, programmable logic arrays, and software-in-silicon. This standard can be applied to any, or all, phases of a software product lifecycle.

This standard identifies the elements that should appear in all software project management plans and recommends elements that should appear in all software project management plans. There are two types of compliance to this standard: format compli ance, 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 IEEE Std 1058.1-1987 may claim partial content-compliance with this standard; this is the only type of partial c ontent-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 a software project management plan 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 addin g project-unique elements such as schedule, budget, work activities, and risk management plan.

The standards listed here should be consulted when applying this standard. The latest revisions shall apply.

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 ANSI/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. Acquis ition 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 whil e 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 produc t delivery. Minor milestones might include baselining of a software module or completion of a chapter of the users� 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 agre ement may include some or all of the following; a contract, a statement of work, user requirements, system engineering specifications, software requirements specifications, the 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 req uirements, functional specifications, design documentation, source code, object code, test results, installation instructions, training aids, users� manuals, product development tools, and maintenance documentation. Project deliverables may be self-conta ined 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 self-contained 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 othe r cases, a software project may span many years and consist of numerous subprojects, each being a well-defined and self-contained software project.

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.8 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 r equirements, 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 minu tes, 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 t o 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.

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 a SPMP.

Signature Page

Change History

Preface

Table of Contents

List of Figures

List of Tables

1. Overview

1.1 Project Summary

1.1.1 Purpose, Scope, and Objectives

1.1.2 Assumptions and Constraints

1.1.3 Project Deliverables

1.1.4 Schedule and Budget Summary

1.2 Evolution of the Plan

2. References
3. Definitions
4. Project Organization

4.1 External Interfaces

4.2 Internal Structure

4.3 Roles and Responsibilities

5. Managerial Process Plans

5.1 Start-Up Plan

5.1.1 Estimation Plan

5.1.2 Staffing Plan

5.1.3 Resource Acquisition Plan

5.1.4 Project-Staff Training Plan

5.2 Work Plan

5.2.1 Work Activities

5.2.2 Schedule Allocation

5.2.3 Resource Allocation

5.2.4 Budget Allocation

 

 

Table 1 (continued)

 

5.3 Control Plan

5.3.1 Requirements Control Plan

5.3.2 Schedule Control Plan

5.3.3 Budget Control Plan

5.3.4 Quality Control Plan

5.3.5 Reporting Plan

5.3.6 Metrics Plan

5.4 Risk Management Plan

5.5 Closeout Plan

6. Technical Process Plans

6.1 Process Model

6.2 Methods, Tools, and Techniques

6.3 Infrastructure Plan

6.4 Product Acceptance Plan

7. Supporting Process Plans

7.1 Configuration Management Plan

7.2 Verification and Validation Plan

7.3 Documentation Plan

7.4 Quality Assurance Plan

7.5 Reviews and Audits

7.6 Problem Resolution Plan

7.7 Subcontractor Management Plan

7.8 Process Improvement Plan

8. Additional Plans

Annexes

Index

The ordering of elements presented in Table 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 prepa ration of the various elements of a SPMP. The various clauses and subclauses of a SPMP may be included by direct incorporation or by reference to other plans and documents.

Detailed descriptions of the clauses and subclauses in a SPMP are presented in clauses 4.1 through 4.7 of this standard. Certain additional plans may be included in a SPMP. Additional plans are specified in clause 4.8.

Each version of a 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 is suing 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 chang ed 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 Table 1.

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 evolutio n 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 result ing 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.

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 b e employed, and product interfaces to other products.

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 specif y the delivery media and any special instructions for packaging and handling. The list of project deliverables may be incorporated into the software project management plan directly or by reference to an external document such as a Contract Data Requirem ents List (CDRL) or a Product Parts List (PPL).

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 depicte d by the top level of the work breakdown structure.

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 ve rsion of the SPMP under configuration management and to control subsequent changes to 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 prov ided.

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.

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 organiza tions, 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.

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, the project work plan, the project control pla n, the risk management plan, and the project closeout plan.

4.5.2 Estimation Plans (Subclause 5.2 of the SPMP)

This subclause of the SPMP shall specify the estimation and estimation techniques to determine cost, schedule, staffing requirements, and staff-training requirements for the complete project.

4.5.2.1 Estimation Plan (Subclause 5.2.1 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 sour ces 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.

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 the resource acquisition process, includ ing 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 adminis trative 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 int o additional subclauses of the form 5.1.3.x to accommodate acquisition plans for various types of resources to be acquired.

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 pr ovided, 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 technic al and managerial skills.

This subclause of the SPMP shall specify the work activities, schedule, resources, and budget details for the software project.

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 b e 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 necessa ry 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 diffe rent depending on factors such as when the work package is scheduled to be accomplished, the quality of the requirements, familiarity of the work, and novelty of the technology to be used]

4.5.3.2 Schedule Allocation (Subclause 5.3.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 (CPN), and PERT.

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.

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 inclu de, 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.

This subclause of the SPMP shall specify the metrics, reporting mechanisms, and control procedures necessary to measure, report, and control the status of product requirements, the project schedule, the budget, and the quality of work processes and wor k products. All elements of the control plan should be consistent with the organization�s standards, policies, and procedures for controlling software projects and with any contractual agreements for project control.

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 o n 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.

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 actu al 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.

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 con trol 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 indicator s 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.

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 v alidation, joint reviews, audits, process assessment, and product evaluations.

4.5.4.5 Reporting Plan (Subclause 5.4.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.4.6 Metrics Plan (Subclause 5.4.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 also specify the metrics to be collected, the frequency of collection, and the method s to be used in validating, analyzing, and reporting the metrics. In addition, the metrics plan shall provide the rationale for the particular metrics chosen for the project.

4.5.5 Risk Management Plan (Subclause 5.5 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 on-going identification, assessment, and mitigation of risk factors throughout the lifecycle 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 responsibl e 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 achi eving acquirer acceptance of the product.

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 post-mortem debrie fings of project personnel, and preparation of a final report to include lessons learned and analysis of project objectives achieved.

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 ac ceptance plan.

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 generat ed, 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 initiat ion 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.

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 projec t deliverable and non-deliverable work products. In addition, the technical standards, policies, and procedures governing development and/or modification of the work products shall be specified.

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 soft ware 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 ja nitorial services.

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 th is 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.

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 documentati on, 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, r esponsibilities, 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 a bsence of a configuration management plan, verification and validation plan, documentation plan, quality assurance plan, joint acquirer-supplier review plan, problem resolution plan, or subcontractor management plan shall be explicitly justified in any so ftware project management plan that does not include them. Plans for supporting processes may be incorporated directly into the software project management plan or incorporated by reference to other plans.

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. I n 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, an d 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.

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 r eviews, 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.

This subclause of the SPMP shall contain the documentation plan for the software project, to include plans for generating non-deliverable and deliverable work products. Organizational entities responsible for providing input information, generatin g, and reviewing the various documents shall be specified in the documentation plan. Non-deliverable 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, users� manual, on-line help system, regression test suite, configuration library, principles of operation, a maintenance guide, or other items specified in subclause 1.1.3 of the so ftware project management plan. 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 vers ion, and a distribution list for review copies and baseline versions.

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 software project management plan , 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.

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, devel oper peer reviews, quality assurance audits, and acquirer -conducted reviews and audits.

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 verification and validation in problem resolution work activities. Effort devoted to problem reporting, analysis, and resolution should be separately report ed so that rework can be tracked and process improvement accomplished.

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 subco ntract 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, schedul e 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 s ubcontract and prime contractor/subcontractor points of contact shall be specified.

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; fo r 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 on-going project and to identify those processes that can best be improved by process improvement initiatives at the organizational level.

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 pro duct 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.

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.

An index to the key terms and acronyms used throughout the SPMP is optional, but recommended to improve the usability of the SPMP.

Informative Annex

The standards listed here should be consulted when applying this standard. The latest revisions should be consulted.