ISO/IEC TR 16326:1999
(Main)Software engineering — Guide for the application of ISO/IEC 12207 to project management
Software engineering — Guide for the application of ISO/IEC 12207 to project management
Ingénierie du logiciel — Guide pour l'application de l'ISO/CEI 12207 à la gestion de projet
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
16326
First edition
1999-12-01
Software engineering — Guide for the
application of ISO/IEC 12207 to project
management
Ingénierie du logiciel — Guide pour l'application de l'ISO/CEI 12207 à
la gestion de projet
Reference number
ISO/IEC TR 16326:1999(E)
©
ISO/IEC 1999
---------------------- Page: 1 ----------------------
ISO/IEC TR 16326:1999(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 1999 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 16326:1999(E)
Contents Page
1 Scope .1
1.1 Audience.1
1.2 Prerequisites .2
2 Conformance.2
3 Normative references .2
4 Terms and definitions .3
5 Symbols and abbreviated terms .3
6 Guidance.3
6.1 Introduction to software project management .3
6.2 Management process .4
6.2.1 Initiation and scope definition.5
6.2.2 Planning.6
6.2.3 Execution and control .9
6.2.4 Review and evaluation .10
6.2.5 Closure.12
Annex A (informative) Support of the ISO/IEC 12207 Management Process.14
Annex B (informative) SPM activities mapped to the Management Process activities .16
Annex C (informative) Project Management Processes mapped to the ISO/IEC 12207 Management
Process activities.17
Annex D (informative) Supporting information .18
Annex E (informative) Bibliography .29
© ISO/IEC 1999 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 16326:1999(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from that which is
normally published as an International Standard ("state of the art", for example), it may decide by a simple majority
vote of its participating members to publish a Technical Report. A Technical Report is entirely informative in nature
and does not have to be reviewed until the data it provides are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this Technical Report may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 16326 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software engineering.
Annexes A to E of this Technical Report are for information only.
iv © ISO/IEC 1999 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 16326:1999(E)
Introduction
Software is an integral part of information technology and conventional systems, e.g., transportation, military,
medical care and finance. There is a proliferation of standards, procedures, methods, tools and environments for
developing and managing software. This proliferation has created difficulties in software project management and
engineering, especially in integrating products and services. The software discipline needs to migrate from this
proliferation to a common framework for software practitioners to “speak the same language” to create and manage
software. ISO/IEC 12207, Information technology — Software life cycle processes, provides a common framework.
The ISO/IEC 12207 framework covers the software life cycle from conceptualization of ideas through
retirement/closure and consists of processes for acquiring and supplying software products and services. This
framework also provides for controlling and improving these processes.
ISO/IEC 12207 provides a comprehensive set of software life cycle processes. An organization, depending on its
purpose, can select an appropriate ISO/IEC 12207 subset to fulfil that purpose. ISO/IEC 12207 is designed to be
tailored for an individual organization, project or application. It is also designed to be used when software is a
standalone entity, or an embedded or integral part of a total system.
This Technical Report provides guidance for the Management Process as introduced by ISO/IEC 12207,
subclause 7.1. Most of the guidance is provided based on Project Management Institute’s (PMI’s) A Guide to the
Project Management Body of Knowledge (PMBOK™ Guide) [11], ISO 10006, Quality management — Guidelines
to quality in project management [5] and experience of people who have been successful software project
managers.
It is not the intent of this Technical Report to suggest any organizational role or responsibility.
It is recognized that identified processes, activities and tasks have an iterative “life” and they may occur in any
order or frequency. These processes, activities and tasks must be coordinated with other processes, activities and
tasks not emphasized in this Technical Report, e.g., ISO/IEC 12207’s Supporting and Organizational Life Cycle
Processes.
This Software Project Management Technical Report is organized as follows:
� Section 1 provides the document’s scope.
� Section 2 identifies the conformance requirements.
� Section 3 identifies the normative references.
� Section 4 provides the definitions used in this Technical Report.
� Section 5 provides the symbols and abbreviations used in this Technical Report.
� Section 6 has guidance on the ISO/IEC 12207 Management Process.
� Annex A maps ISO/IEC 12207 Management Process activities to the ISO/IEC 12207 Primary Processes.
� Annex B maps ISO/IEC 12207 Management Process activities to [11]’s project management knowledge areas.
� Annex C maps ISO/IEC 12207 Management Process activities to [5]’s project management processes.
� Annex D maps ISO/IEC 12207 to [5]’s process levels and to [11]’s project management knowledge area major
processes.
� Annex E provides a bibliography of some reference material. This list is not inclusive, nor an endorsement of
any reference.
© ISO/IEC 1999 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 16326:1999(E)
Software engineering — Guide for the application of ISO/IEC 12207
to project management
1 Scope
This Technical Report supplements International Standard ISO/IEC 12207, Information technology — Software life
cycle processes, in the area of Management Process (hereafter referred to as “software project management” or
SPM. Thus, in this Technical Report, SPM is not a person, but a process). This Technical Report was developed by
(see Figure 1):
� Applying the Management Process in ISO/IEC 12207 to SPM.
TM TM
� Using A Guide to the Project Management Body of Knowledge (PMBOK ) [11] to define and describe
management knowledge areas applicable to SPM.
� Using ISO 10006, Quality management – Guidelines to quality in project management [5].
This Technical Report provides guidance to people responsible for managing the performance of ISO/IEC 12207
software life cycle Primary Processes: Acquisition, Supply, Development, Operation and Maintenance. The
guidance addresses:
� General guidance for SPM regarding ISO/IEC 12207, subclause 7.1, management activities as they are
supported in each Primary Process.
� SPM applicability for each Primary Process.
� Key areas applicable across the spectrum of SPM.
� Expanded guidance for software Project Managers (PMs) regarding the management tasks from:
TM
� [11] — Identifies and describes generally that subset of the PMBOK which is generally accepted.
Generally accepted means that the knowledge and practices described are applicable to most projects
most of the time, and there is widespread consensus about their value and usefulness.
� [5] — Gives guidance on quality system elements, concepts and practices for which the implementation is
important to and has an impact on the practice of project management.
This Technical Report addresses aspects of project management that are either “software specific” or are known to
cause problems in software projects in any of the ISO/IEC 12207 Primary Processes. For example, it is well known
that software projects are often late and/or over budget, or are unable to meet an acquirer’s requirements or
expectations. While this is not peculiar to software, there are a number of software specific attributes causing this to
happen.
Figure 1 illustrates the relationship of ISO/IEC 12207, [11] and [5] in the development of this Technical Report.
1.1 Audience
This Technical Report is written for those who use or plan to use ISO/IEC 12207 on software projects regardless of
project scope, product, methodology, size or complexity. This Technical Report is written primarily to aid software
PMs in ensuring management processes conform to ISO/IEC 12207, specifically:
© ISO/IEC 1999 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC TR 16326:1999(E)
� Managers responsible for establishing and continuously improving ISO/IEC 12207 software life cycle
processes.
� Managers responsible for executing any ISO/IEC 12207 software life cycle process at a project level.
� Organizations or individuals subcontracting an SPM effort.
Consideration is given to people who have:
� Worked on software projects, but not as a software PM.
� Been non-software PMs, but are transitioning to be software PMs.
This Technical Report presents the primary ISO/IEC 12207 life cycle processes from the perspective of a software
PM and provides advice (based on experience, lessons learned, etc.) about best practices and recommendations
to be applied to management tasks by the practitioners. Lastly, this Technical Report enables engineering,
technical and other support staffs to see how their efforts integrate within a total, software life cycle.
1.2 Prerequisites
The prerequisites to use this Technical Report are:
� Availability of and familiarity with ISO/IEC 12207.
� Familiarity with the relevant organizational policies and procedures.
� Knowledge of stakeholder and contract requirements (needs and expectations).
TM
ISO/IEC 12207 – Software
ISO/IEC 10006 – Guidelines to PMBOK Guide – Project
life cycle processes
quality in project management management knowledge areas
ISO/IEC TR 16326 – Guide for the application of ISO/IEC 12207 to project management
Best practices, lessons learned, etc.
TM
Figure 1 — Use of ISO/IEC 12207, PMBOK Guide and ISO 10006 to create this Technical Report
2 Conformance
Since this is a Technical Report, there are no conformance requirements.
3 Normative references
Since this is a Technical Report, normative references are not required. See the Bibliography (Annex E) for some
informative references.
2 © ISO/IEC 1999 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 16326:1999(E)
4 Terms and definitions
For the purpose of this Technical Report, the definitions given in ISO/IEC 12207, [11] and [5] apply, in that
hierarchial order.
5 Symbols and abbreviated terms
The following symbols and abbreviations are used in this Technical Report:
CCB* Configuration/Change Control Board
ICWG* Interface Control Working Group
IEC International Electrotechnical Commission
ISO International Organization for Standardization
PM Project Manager
SEE Software Engineering Environment
SPM Software Project Management
WBS Work Breakdown Structure
* Depending on the size and complexity of a project, can be a group of people, a single person or a function.
6 Guidance
6.1 Introduction to software project management
A project is a temporary endeavour undertaken to create a unique product or service [11]. As such, a project
involves a group of people, resources and events with the following common characteristics:
� The main objectives are to create products, services and results.
� A project has a known beginning and end, i.e., a project is temporary.
� A project is not part of the normal, ongoing operation of most organizations, i.e., it usually has a unique
requirement. Some organizations (e.g., Research and Development) exist only to perform projects.
A software project is a project emphasizing software as its product, service or result. So, how does software differ
from other project products, services and results? As stated by Watts Humphrey [17]:
� Software is generally more complex.
� Software changes appear relatively easy to make.
� Many late-discovered hardware problems are addressed through software changes.
� Because of its low reproduction cost, software does not have the natural discipline of release to manufacturing.
� Software discipline is not grounded in natural science and it lacks ready techniques for feasibility testing and
design modelling.
© ISO/IEC 1999 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC TR 16326:1999(E)
� Software is often the element integrating an entire system, thus adding to its complexity and creating
exposures to late change.
� Software is generally most visible, thus most exposed to requirements changes and most subject to user
complaint.
Because software is different from non-software products, services and results, the management of software
projects is also different. This is not to say SPM is totally different from the management of non-software projects.
The key item is that there are unique areas of SPM and general project management that management must be
aware of to achieve project goals, as well as prevent problems.
[11] provides important information about managing projects. ISO/IEC 12207 provides important information about
software projects within ISO/IEC 12207, subclause 5.2 (Supply Process) and describes many activities and tasks to
be performed. [5] provides information on how to improve the quality of project management. The main purpose of
this Technical Report is to highlight how the differences described above impact a software PM, to show how these
three documents complement each other and to help PMs manage software projects to a successful conclusion.
Rapidly changing technology in the software discipline is outpacing management and process techniques. This is
compounded by the incompleteness of the range of project management tools and techniques available to software
engineers as compared to other engineering disciplines.
SPM methodology implementation is determined by many factors, e.g., personnel, organizational and contractual
requirements, and project complexity.
A software PM determines the methodology and technology for undertaking a project and should be required to:
� Anticipate and thus prevent or minimize the adverse impact of problems.
� Make timely and firm decisions.
� Resolve problems when they occur.
� Take responsibility for a project’s actions, processes, activities, resources, products and results.
As an iterative endeavour, a software PM must consider any systemic impact when undertaking an action, e.g., an
action, or failure to act, in an area can affect other areas.
6.2 Management process
This clause examines ISO/IEC 12207’s (subclause 7.1) Management Process. ISO/IEC 12207 defines a generic
management process (rather than SPM) that may be employed by any party managing its processes. This clause
discusses the ISO/IEC 12207 Management Process as it applies to the management of software projects (SPM).
It is recognized that identified processes, activities and tasks may require a reiterative action to accomplish the
requirements/goals of a project. For instance, based upon the software life cycle model being used, processes,
activities and tasks may be employed at the same time; they may be interdependent; or they may be coordinated in
an organized series of Work Breakdown Structure (WBS) dependencies throughout a software project life cycle.
ISO/IEC 12207
7.1 Management process. The Management Process contains the generic activities and tasks, which may
be employed by any party that has to manage its respective process(es). The manager is responsible for
product management, project management, and task management of the applicable process(es), such as
the acquisition, supply, development, operation, maintenance, or supporting process.
4 © ISO/IEC 1999 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 16326:1999(E)
ISO/IEC 12207 (subclause 7.1) states “of the applicable process(es)” since a project may not involve all of the
Primary Processes. For instance, a project may be only involved with the development or maintenance of a
product, rather than product operation.
SPM should define (and the software PM control) the activities needed to ensure products are delivered as
specified in a contract, i.e., ensure a software project includes all the work required, and only the work required, to
complete the project and product successfully.
6.2.1 Initiation and scope definition
ISO/IEC 12207
7.1.1 Initiation and scope definition. This activity consists of the following tasks:
7.1.1.1 The management process shall be initiated by establishing the requirements of the process to be
undertaken.
7.1.1.2 Once the requirements are established, the manager shall establish the feasibility of the process by
checking that the resources (personnel, materials, technology and environment) required to execute and
manage the process are available, adequate, and appropriate and that the time-scales to completion are
achievable.
7.1.1.3 As necessary, and by agreement of all parties concerned, the requirements of the process may be
modified at this point to achieve the completion criteria.
Initiation and scope definition is the determination of the feasibility of a process to ensure personnel, materials,
facilities, Software Engineering Environment (SEE) and technology required to execute and manage a project are
available, adequate and appropriate; and the predetermined times for completion are achievable, timely and
economical. This involves choosing a software development strategy (e.g., a project may consist of off-the-shelf
software, in-house software, out-sourced software or a combination of these).
Scope (e.g., description of a project product, product characteristics and how the characteristics are to be
measured or assessed) related items aim to:
� Document the reason for the project, its goals and its objectives.
� Translate stakeholder requirements into project deliverables and activities to be carried out to achieve and
organize a project.
� Ensure people work within the scope.
� Evaluate the results of activities to facilitate the results meeting scope requirements.
In the best case scenario, a new software project has many similarities to a project previously managed by an
organization. This provides a high level of assurance that an organization has the capability to perform a software
project successfully.
Initiation and scope definition may be difficult to perform when a new project is unprecedented (i.e., has not
previously been performed by an organization). For an unprecedented project, special care should be taken to
ensure it is properly scoped and monitored. This should be accomplished by having frequent reviews and
evaluations, reviewing best practices and lessons learned from somewhat related projects, and by seeking advice
from experts.
The key to initiation and scope definition is to establish and document the comprehensive scope and requirements
of a software project. This involves identifying and understanding stakeholder requirements, and evaluating and
negotiating comprehensive requirements. Special care should be taken to manage change to the scope and
requirements throughout a software project’s life cycle. All changes in scope and requirements should be carefully
© ISO/IEC 1999 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC TR 16326:1999(E)
evaluated for the impact on cost, schedule, risk and performance. All stakeholders should be involved in the
requirements definition of a software project.
Special care should be applied to defining and documenting quality characteristics [19]; for example, when software
is to be embedded in a higher-level system, or functions are to be distributed between software and hardware, or
between software and external interfacing software or systems.
Responsibility for obtaining stakeholder agreement on project requirements should be determined. Agreement is
the result of an iterative process to be employed throughout a software project life cycle. Risks, changes in
stakeholder requirements, environment, project budget and schedule, and an evolving design make it necessary to
continually reassess and reaffirm agreements and commitments, and make appropriate changes to the project
scope, as required.
Establishing completion criteria is very important. The intent, as supported by [11], is to determine if a project,
activity or task has been completed successfully.
A business requirement, often ignored by software PMs, is the handling of copyrights, patents, etc. For instance,
when does an acquirer own a developing product or what does an acquirer own when a supplier goes out of
business prior to final product delivery?
Software specific advice:
� Requirements for software replication, distribution, installation and testing should be carefully determined.
� Traceability between system and software requirements, between software requirements and design, and
between software requirements and tests should be established and maintained.
� Interfaces should be specified and controlled as an integral part of software specification and interface
description documents.
� Due to the complexity of software development, it is difficult to prove software products meet all user
requirements (needs and expections).
� Workload projection depends on the type of project: a new development, embedding in or integration to a
system, modification of off-the-shelf software product, porting to different operating systems, etc.
6.2.2 Planning
ISO/IEC 12207
7.1.2 Planning. This activity consists of the following task:
7.1.2.1 The manager shall prepare the plans for execution of the process. The plans associated with the execution
of the process shall contain descriptions of the associated activities and tasks and identification of the
software products that will be provided. These plans shall include, but are not limited to, the following:
a) Schedules for the timely completion of tasks;
b) Estimation of effort;
c) Adequate resources needed to execute the tasks;
d) Allocation of tasks;
e) Assignment of responsibilities;
f) Quantification of risks associated with the tasks or the process itself;
g) Quality control measures to be employed throughout the process;
h) Costs associated with the process execution;
i) Provision of environment and infrastructure.
6 © ISO/IEC 1999 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 16326:1999(E)
The responsibility for preparing and approving plans should be defined.
Plans should identify the software life cycle model, task, task assignments, commitments and resources. A
software project should have one master schedule and all subordinate schedules should be integrated and
consistent with the master schedule. A WBS can effectively measure software project progress and provides
visibility into processes and products. A WBS technique is strongly encouraged because it organizes and defines
the total scope of the project [11]. The WBS should be constructed to allow a software project to be managed at the
appropriate level of granularity consistent with the size, complexity, criticality and risk of the software project;
familiarity is needed on the technology to be used.
Project estimates used in planning should include:
� Costs associated with process execution.
� Infrastructure.
� Need for resources, including related management and control.
� Quality assurance and control.
� Risk management.
� SEE provisions.
� Work to be performed in each process and/or activity.
Software PMs should make every attempt to use existing organizational infrastructure whenever possible. If
existing infrastructure is insufficient to support a project, then adaptation or additions to existing infrastructure
should be handled judiciously. This may require the use of subcontracting to satisfy infrastructure deficiencies.
Consultants may help bringing agreement on various matters.
Planning is an iterative activity in which a software project is assessed, refined and revised (as necessary) as
project execution progresses. Software PMs should have processes in place to facilitate re-planning and
refinement of estimates throughout a software project life cycle. There are many interdependencies on every
software project and several iterations of planning are usually required to obtain even an initial SPM plan. For
information needed by an SPM plan, but provided in other plans, an SPM plan may reference the other plans.
Plans should be updated and at least contain:
� Roles and Responsibilities.
� Activities and tasks to be performed.
� All project deliverables identified in a WBS.
� Completion criteria.
� Completion reporting.
� Cost and schedule reporting.
� Means of initiation - by direction, product or time-based.
� Frequency and means of reporting progress.
� Problem or exception reporting.
� Resource requirements and status.
© ISO/IEC 1999 – All rights reserved 7
-------------
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.