4 Interpreting the CMM
The intention in setting down the key practices is not to require or espouse
a specific model of the software life cycle, a specific organizational structure,
a specific separation of responsibilities, or a specific management a fc3
nd technical approach to development. The intention, rather, is to provide
a description of the essential elements of an effective software process.
The key practices are intended to communicate principles that apply
to a wide variety of projects and organizations, that are valid across
a range of typical software applications, and that will remain valid over
time. Therefore, the approach is to describe the principles and leave
their implementation up to each organization, according to its culture
and the experiences of its managers and technical staff.
Although the key practices are meant to be independent of any particular
implementation, specific terms and examples are consistently used in stating
the key practices to improve clarity. This section describes the conventions
used in the CMM for roles, responsibilities, relationships, products,
and activities. Organizations using the key practices should be aware
of these conventions and map them appropriately to their own organization,
project, and business environment.
The glossary in Appendix B contains definitions of terms, including
those described in this section and others.
Within each common feature of the key practices, certain phrases and conventions
were used to provide continuity and consistency between the key process
areas. The major structural conventions are described below, arranged by
common feature.
Policy Statements
Where policy statements are used, they generally refer to the project
following a written, organizational policy for the practices of that key
process area. This is to emphasize the connection between organizational
commitment and the projects that are actually performing the work.
The subpractices for the policy statement generally summarize activities
that are covered later in the key process area and are particularly suitable
to institutionalization via a written policy.
In some key process areas (e.g., Organization Process Focus), the focus
of the activities for the key process area is the organization, not the
project. In those cases, the policy statement is reworded and refers to
the organization following a written policy.
Leadership
In some key process areas, Commitment to Perform contains a statement
that addresses the assignment of a leadership role (e.g., project software
manager) or that describes particular sponsorship activities, which are
necessary for the key process area to be successfully institutionalized.
Resources and funding
Most key process areas contain a key practice that reflects the need
for adequate resources and funding for the activities covered by the key
process area. These resources and funding, described by the subpractices,
generally fall into three categories: access to special skills, adequate
funding, and access to tools. Tools that may be of use in performing the
activities of the key process area are listed as examples.
The word "funding" is used, rather than "budget," to emphasize that
what is delivered and used is more pertinent to the actual process than
what was promised.
Training
The CMM's context for the term training is somewhat broader than might
normally be considered when using the term. Training is provided to make
an individual proficient with specialized instruction and practice. This
training may include informal as well as formal vehicles for transferring
skills and knowledge to the individuals in the organization. Although
classroom training is a common mechanism that many organizations use to
build the skills of their employees, the CMM also accommodates other vehicles,
such as facilitated video, computer aided instruction, or formal mentoring
and apprenticeship programs. The Training Program key process area describes
the specific practices rela 191 ted to these training vehicles.
Two templates to describe training are generally found throughout the
CMM. At Level 2, the phrase "receive training" is used. At Levels 3 and
above, the phrase "receive required training" is used. The intention in
using these different templates is to recognize that training at Level
2 is not likely to have been institutionalized across the organization.
At L fbf evels 3 and above, the key practices of the Training Program
key process area are expected to govern the organization's training activities.
In all the key process areas, potential training topics are expressed
as example boxes, to recognize that different organizational situations
are likely to drive different specific training needs.
Orientation
In some key process areas, key practices that describe orientation are
found. The term orientation is used broadly to indicate less depth of
skill or knowledge being transferred than would be expected via training.
Orientation is an overview or introduction to a topic for those overseeing
or interfacing with the individuals responsible for performing in the
topic area.
Prerequisite Items
Some key process areas contain key practices that express a need for
prerequisite items; for example, a software development plan is a prerequisite
for Software Project Tracking and Oversight. In some cases, these are
prerequisites that would be expected as outputs from the activities of
another key process area. In other cases, they are items expected to be
obtained from outside the realm of the software project (e.g., the system
requirements allocated to software are a prerequisite for Requirements
Management).
In keeping with the CMM philosophy of highlighting "key" practices,
not all prerequisite items are listed for each key process area. Only
those that have been found to be particularly critical for implementing
the key process area are cited in the CMM.
Of all the common features, Activities Performed shows the greatest amount
of structural variability, because the implementation activities for the
key process areas vary in level of detail, organizational focus (e.g., project
or organization), and need for planning and documentation. Some generalizations
are highlighted below.
Types of plans
Two major types of plans are described in the key practices: formal
plans (e.g., software development plan, software quality assurance plan,
and software configuration management plan) and informal plans (e.g.,
peer review plan, risk management plan, and technology management plan).
The informal plans will typically be documented as part of a formal
plan (e.g., the peer review plan may be documented as part of the software
development plan) or as an adjunct to a formal plan (e.g., peer review
schedules may be a section in the software development plan). Formal plans
require a high degree of management commitment, both from the standpoint
of creating them and ensuring that they are followed. In contractual environments,
these plans are usually deliverable to the customer who contracted the
effort.
Formal plans
In cases where formal plans are called out, there are usually two key
practices that specifically address the planning activities: a key practice
that requires that the plan be developed or revised according to a documented
procedure, and one that requires that the activities of the key process
area be based on the plan.
The subpractices referring to a documented procedure generally cover
what the inputs to the plan need to be, as well as the expected steps
for obtaining commitment and support required for the plan. These subpractices
identify the typical reviewers of the plan. They also highlight what levels
of approval would be expected.
The subpractices that refer to the plan being the basis for activities
describe the expected contents of the plan under discussion. Depending
on the type of plan and need for organizational flexibility in covering
the general topics of the plan, varying levels of detail are provided
to describe the plan's contents.
Informal plans
Informal plans are usually described by a single key practice. The subpractices
include information about the contents of the plan as well as the procedure
for developing or revising the plan.
194 According to a documented procedure
A documented procedure is usually needed so that the individuals responsible
for a task or activity are able to perform it in a repeatable way and
so that others with general knowledge of the area will be able to learn
and perform the task or activity in the same way. This is one aspect of
institutionalizing a process.
The formality and level of de fb2 tail of a documented procedure can
vary significantly, from a hand-written individual desk procedure to a
formal organizational standard operating procedure. The formality and
level of detail depends on who will perform the task or activity (e.g.,
individual or team), how often it is performed, the importance and intended
use of the results, and the intended recipients of the results.
System requirements allocated to software
The system requirements allocated to software, usually referred to as
the "allocated requirements" in the CMM, are the subset of the system
requirements that are to be implemented in the software components of
the system. The allocated requirements are a primary input to the software
development plan. Software requirements analysis elaborates and refines
the allocated requirements and results in software requirements which
are documented.
Customer requirements involve a complete system, not just software.
In the CMM, discussion of customer requirements centers on those customer
requirements to be implemented in software. The allocation of system requirements
to hardware, software, etc., is typically done by a system engineering
group as part of the overall system design. The system requirements allocated
to the software project are usually referred to as the "allocated requirements"
in the CMM and include both technical requirements (functionality, performance,
etc.) and nontechnical requirements (delivery dates, cost, etc.).
Customer-supplier relationship
The customer may be internal or external to the organization. An example
of an internal customer is a marketing group; an example of an external
customer is the DoD. The user may also differ from the customer, as is
typically the case in the DoD contracting environment. The CMM is expressed
in terms of an external customer who is procuring a system with a critical
software component.
Where necessary, the boundaries between groups, as stated in the CMM,
must be appropriately interpreted. For example, in software-only procurements,
there may be no system engineering group between the customer and the
software engineering group. In such a case, customer requirements, system
requirements, and allocated requirements may be synonymous, and the responsibilities
of the system engineering group will be divided between the customer and
the software engineering group.
Tracking and taking corrective action versus managing
In Software Project Tracking and Oversight at Level 2, many of the key
practices use the phrase, "... is tracked... corrective actions are taken
as appropriate." In Integrated Software Management at Level 3, many of
the similar key practices use the phrase, "is managed." This difference
in wording reflects the project's lack of a completely defined software
process at Level 2. Management actions are likely to be reactions to actual
problems. At Level 3, the project has a complete defined software process,
and the relationships between the various software work products, tasks,
and activities are well defined. Management is better able to anticipate
problems and proactively prevent them from occurring. When interventions
are required, the effect on the entire software process is understood,
and these interventions can be more effectively defined and applied.
Reviewed versus undergoes peer reviews
At a review, a software work product, or set of work products, is presented
to managers, the customer, end users, or other interested individuals
for their comment or approval. Reviews typically occur at the end of a
task. At a peer review, a software work product, or set of work products,
is presented to the producer's colleagues to identify defects. Managers,
the customer, and end users are typically not present in a peer review.
Peer reviews are an integral, in-process part of a task. They are performed
so that defects can be removed early, leading to higher productivity and
high- 194 quality products. Some software work products will be reviewed;
some will undergo peer review; and some will undergo both peer reviews
and reviews.
Placed under configuration management versus managed and controlled
Some software work products, e.g., the software design and the code,
should have baselines established at predetermined points. These baselines
are formally reviewed and a fb6 greed on and serve as the basis for further
development. A rigorous change control process is applied to baselined
items. These baselines provide control and stability when interacting
with the customer. This is sometimes referred to as baseline configuration
management. The phrase "placed under configuration management" is used
for such software work products.
When control of the configuration is exercised by the developers, it
is usually referred to as developmental configuration management. Some
items under developmental configuration management may be placed under
baseline configuration management at predetermined points in their development.
The phrase "placed under configuration management" can be interpreted
as extending to developmental configuration management, but a valid minimal
interpretation is that only baseline configuration management is required.
Some software work products, such as estimates or the software development
plan, which may not have to be under configuration management, still need
to be "managed and controlled." This phrase is used to characterize the
process of identifying and defining software work products that are not
part of a baseline and, therefore, are not placed under configuration
management but that must be controlled for the project to proceed in a
disciplined manner. "Managed and controlled" implies that the version
of the work product in use at a given time (past or present) is known
(i.e., version control), and changes are incorporated in a controlled
manner (i.e., change control).
The key practices in the Measurement and Analysis common feature describe
basic measurement practices that are necessary to determine status related
to the Activities Performed common feature of the key practices. Measurements
that are inherently part of the activities of the key process area are contained
under the Activities Performed common feature.
Examples of suggested measurements are expressed as supplementary information,
because the variability in project environments may lead to different
measurement needs and approaches.
The Verifying Implementation common feature generally contains key practices
that relate to oversight by senior management and project management, as
well as specific verification activities that the software quality assurance
group or others are expected to perform to verify that the key practices
are being performed properly.
Senior management oversight on a periodic basis
The primary purpose of periodic reviews by senior management is to provide
awareness of, and insight into, software process activities at an appropriate
level of abstraction and in a timely manner. The time between reviews
should meet the needs of the organization and may be lengthy, as long
as adequate mechanisms for exception reporting are available.
The scope and content of senior management reviews will greatly depend
on which senior manager is involved in the review. Reviews by the senior
manager responsible for all software activities of an organization are
expected to occur on a different schedule, and address different topics,
from a review by the senior executive of the entire organization. Senior
management reviews would also be expected to cover different topics, or
similar topics at a higher level of abstraction, than project management
oversight reviews.
Project management oversight on both a periodic and event-driven
basis
The template "both on a periodic and event-driven basis" is used in
these key practices to emphasize that projects have needs for different
types of review at different stages and depending on the project characteristics.
Project management should maintain an ongoing awareness of the status
of the software effort and be informed when significant events on the
software project occur. Examples include project 191 management participation
in formal reviews, such as critical design reviews, as well as reviews
which encompass process issues such as status of process improvement planning
and resolution of process non-compliance issues.
At the project level, project management oversight is expected to be
at a more detailed level than that of senior management, reflecting project
management's more active in fbf volvement in the operational aspects of
a project.
Software quality assurance activities
The particular activities that are considered appropriate for review
and/or audit by the software quality assurance (SQA) group are described
as a key practice. There are particular cases where SQA verification activities
are not described, such as for the Training Program and Intergroup Coordination
key process areas. These are key process areas that are at the boundary
between the software project and the organization, where the SQA group
would not be expected to have authority.
Software process definition is fundamental for achieving higher levels of
maturity. This section discusses aspects of software process definition
which are helpful in using the key practices related to process definition,
beginning with Organization Process Definition at Level 3.
A fundamental concept of process definition in the CMM is the organization's
standard software process. An organization's standard software process
is the operational definition of the basic process that guides the establishment
of a common software process across the software projects in the organization.
It describes the fundamental software process elements that each software
project is expected to incorporate into its defined software process.
It also describes the relationships (e.g., ordering and interfaces) between
these software process elements. It establishes a consistent way of performing
the software activities across the organization and is essential for long-term
stability and improvement.
At the organizational level, the organization's standard software process
needs to be described, managed, controlled, and improved in a formal manner.
At the project level, the emphasis is on the useability of the project's
defined software process and the value it adds to the project. A project's
defined software process is the operational definition of the software
process used by the project. The project's defined software process is
a well-characterized and understood software process, described in terms
of software standards, procedures, tools, and methods. It is developed
by tailoring the organization's standard software process to fit the specific
characteristics of the project.
The key practices in Organization Process Definition are presented using
terms that reflect an approach to process definition that supports both
stability and flexibility. This approach is depicted in Figure 4.1, and
its key elements are described in the following paragraphs.
A fundamental concept that supports the approach taken by the SEI in its
process definition work is that processes can be developed and maintained
in a way similar to the way products are developed and maintained. There
must be:
- requirements that define what process is to be described,
- an architecture and design that provide information on how the process
will be defined,
- implementation of the process design in a project or organizational
situation,
- validation of the process description via measurement, and
- deployment of the process into widespread operation within the organization
or project for which the process is intended.
Using the analogy of product development, a framework for software process
development and maintenance has evolved that translates these concepts into
ones which are more specific to the process development discipline (similar
to the specificity of terminology used for developing real-time embedded
systems versus management information systems). The key elements of this
framework are illustrated in Figure 4.1 and described briefly below.
For further reading on the concepts of process definition that are being
developed within the process engineering community, refer to the paper,
"Softwar 19e e Process Development and Enactment: Concepts and Definitions"
[Feiler 92].
Figure 4.1 Conceptual Software Process Framework Used in the CMM
Organization's software process assets
The organization establishes and maintains a s fc1 et of software process
assets as shown in Figure 4.1. These software process assets include:
- the organization's standard software process (including the software
process architecture and software process elements),
- the descriptions of software life cycles approved for use,
- the guidelines and criteria for tailoring the organization's standard
software process,
- the organization's software process database, and
- the library of software process-related documentation.
The software process assets are available for use by the projects in developing,
maintaining, and implementing their defined software process.
An organization may bundle the software process assets in many ways,
depending on its approach to establishing its standard software process.
For example, the description of the software life cycle may be an integral
part of the organization's standard software process Another example is
that parts of the library of software process-related documentation may
be stored in the organization's software process database.
Organization's standard software process
An organization's standard software process is the operational definition
of the basic process that guides the establishment of a common software
process across the software projects in the organization. It describes
the fundamental software process elements that each software project is
expected to incorporate into its defined software process. It also describes
the relationships (e.g., ordering and interfaces) between these software
process elements. It guides the establishment of a common software process
across the software development and maintenance projects in the organization.
The relationship between software process elements is sometimes referred
to as a "software process architecture."
The organization's standard software process forms the basis for the
projects' defined software processes. It provides continuity in the organization's
process activities and is the reference for the measurements and long-term
improvement of the software processes used in the organization.
Software process architecture
The software process architecture is a high-level (i.e., summary) description
of the organization's standard software process. It describes the ordering,
interfaces, interdependencies, and other relationships between the software
process elements of the organization's standard software process. It also
describes the interfaces, dependencies, and other relationships to other
external processes (e.g., system engineering, hardware engineering, and
contract management).
Software process element
A software process element is a constituent element of a software process
description. Each process element covers a well-defined, bounded, closely
related set of tasks (e.g., software estimating element, software design
element, coding element, and peer review element). The descriptions of
the process elements may be templates to be filled in, fragments to be
completed, abstractions to be refined, or complete descriptions to be
modified or used unmodified.
Description of software life cycles approved for use
A software life cycle is the period of time that begins when a software
product is conceived and ends when the software is no longer available
for use. The software life cycle typically includes a concept stage, requirements
stage, design stage, implementation stage, test stage, installation and
checkout stage, operation and maintenance stage, and sometimes, retirement
stage [IEEE-STD-610].
Because an organization may be producing software for a variety of contractual
and/or commercial customers and users, one software life cycle may not
be appropriate for all situations. Therefore, the organization may identify
more than one software life cycle for use by the projects. These software
life cycles are typically obtained from software engineering literature
and m 194 ay be modified for the organization. These software life cycles
are available to be used, in combination with the organization's standard
software process, in developing a project's defined software process.
Guidelines and criteria for tailoring
The organization's standard software process is described at a general
level that may not be directly usable by a project. Guidelines are es
fbc tablished to guide the software projects in (1) selecting a software
life cycle from those approved for use and (2) tailoring and elaborating
the organization's standard software process and the selected software
life cycle to fit the specific characteristics of the project.
These guidelines and criteria help ensure that there is a common basis
across all software projects for planning, implementing, measuring, analyzing,
and improving the projects' defined software processes.
Organization's software process database
The organization's software process database is a database established
to collect and make available data on the software processes and resulting
software work products, particularly as they relate to the organization's
standard software process. The database contains or references both the
actual measurement data and the related information needed to understand
the measurement data and assess it for reasonableness and applicability.
Examples of process and work product data include estimates of software
size, effort, and cost; actual data on software size, effort, and cost;
productivity data; peer review coverage and efficiency; and number and
severity of defects found in the software code.
Library of software process-related documentation
A library of software process-related documentation is established to
(1) store process documents that are potentially useful to other current
and future projects, particularly as they relate to the organization's
standard software process, and (2) make them available for sharing across
the organization. This library contains example documents and document
fragments, which are expected to be of use to future projects when they
are tailoring the organization's standard software process. The examples
may cover subjects such as a project's defined software process, standards,
procedures, software development plans, measurement plans, and process
training materials. This library is an important resource that can help
to reduce the amount of effort required to start a new project, by providing
examples of successful projects as a starting point.
Description of project's defined software process
The description of the project's defined software process is the operational
definition of the software process used by the project. The project's
defined software process is a well-characterized and understood software
process, described in terms of software standards, procedures, tools,
and methods. It is developed by tailoring the organization's standard
software process to fit the specific characteristics of the project.
This tailoring includes selecting a software life cycle from those approved
by the organization and modifying the organization's standard software
process to fit the specific characteristics of the project.
The project's defined software process provides the basis for planning,
performing, and improving the activities of the managers and technical
staff performing the project's tasks and activities. It is possible for
a project to have more than one defined software process (e.g., for the
operational software and for the test support software) or to have one
defined software process for two or more similar projects.
Stages
A stage is a partition of the software effort that is of a manageable
size and that represents a meaningful and measurable set of related tasks
which are performed by the project. A stage is usually considered a subdivision
of a software life cycle and is often ended with a formal review prior
to the onset of the following stage.
Tasks
The work to be performed is broken down into tasks. A task is a well-defined
unit of work in the software process that provides management with a visible
checkpoint into the status of the project. Tasks have readiness criteria
(preconditions) and co 191 mpletion criteria (postconditions).
Within the context of process definition, a task is a well-defined component
of a defined process. All tasks can be considered activities, but not
all activities are well enough defined to be considered tasks (although
an activity may include a task). Because of this, use of "task" in the
Level 2 key practices is avoided and the less rigorous term "activit fc4
y" is used.
Activities
An activity is any step taken or function performed, both mental and
physical, toward achieving some objective. Activities include all the
work the managers and technical staff do to perform the tasks of the project
and organization.
Software work products (project results)
The results of activities and tasks primarily consist of software work
products. A software work product is any artifact created as part of defining,
maintaining, or using a software process, including process descriptions,
plans, procedures, computer programs, and associated documentation, which
may or may not be intended for delivery to a customer or end user. Work
products become an input to the next step in the process or provide archival
information on the software project for use in future projects.
Examples of software work products include plans, estimates, data on
actual effort, corrective action documentation, and requirements documents.
The subset of software work products that are deliverable to the customer
or end user are referred to as software products.
Software products
The software products are the complete set, or any of the individual
items of the set, of computer programs, procedures, and associated documentation
and data designated for delivery to a customer or end user. [IEEE-STD-610]
All software products are also software work products. A software work
product that will not be delivered to a customer or end use is not, however,
a software product.
The description of the project's defined software process will usually not
be specific enough to be performed directly. Although the description typically
identifies such things as roles (i.e., who performs a task) and types of
software work products needed to perform a task, it does not specify the
individual who will assume the roles, the specific software work products
that will be created, nor the schedule for performing the tasks and activities.
The project's software development plan, either as a single document
or a collection of plans collectively referred to as a software development
plan, provides the bridge between the project's defined software process
(what will be done and how it will be done) and the specifics of how the
project will be performed (e.g., which individuals will produce which
software work products according to what schedule). The combination of
the project's defined software process and its software development plan
makes it possible to actually perform the process.
The key practices are not meant to limit the choice of a software life cycle.
People who have extensively used one particular software life cycle may
perceive elements of that life cycle in the organization and structure of
the key practices. However, there is no intent either to encourage or preclude
the use of any particular software life cycle.
The term "stage" is used to refer to a defined partition of the software
project's effort, but the term should not be tied to any specific software
life cycle. As it is used in the key practices, "stage" can mean rigidly
sequential stages or overlapping and iterative stages.
The key practices neither require nor preclude specific software technologies,
such as prototyping, object oriented design, or reusing software requirements,
design, code, or other elements.
The key practices describe a number of process-related documents, each one
covering specific areas of content. The key practices do not require a one-to-one
relationship between the documents named in the key practices and the actual
work products of an organization or project. Nor is there an intended one-to-one
r 191 elationship to documents specified by the DoD or to standards such
as DOD-STD-2167A or IEEE software standards. The key practices require only
that the applicable contents of these documents be part of the organization's
or project's written work products.
In terms of document structure, the contents of a document referred
to in the key practices could be part of a larger document. For exampl
fbd e, an organization might have a software development plan that includes
the essentials of the software risk management plan.
Alternatively, the contents of a document referred to in the key practices
could be distributed over a set of documents that differ from the set
named in the key practices. For example, a project might develop three
documents, a software development plan, a software management plan, and
a project work breakdown structure, to satisfy the key practices for a
software project's software risk management, software quality assurance,
and software development plans.
The key practices for the collection and analysis of process data evolve
across the maturity levels.
At Level 2, the data are primarily related to the size of the project's
work products, effort, and schedule, and are defined, collected, and stored
separately by each project. The data are shared between projects via informal
mechanisms.
At Level 3, each project has a defined software process tailored from
the organization's standard software process. Data related to each project's
defined software process are collected and stored in the organization's
software process database. The data collected and stored may be different
for each project, but the data are well defined within the organization's
software process database.
At Level 4, the organization defines a standard set of measurements
based on the organization's standard software process. All projects collect
this standard set of measurement data, as well as other project-specific
data, and store them in the organization's software process database.
The data are used by the projects to quantitatively understand and stabilize
the process performance of the projects' defined software processes. They
are also used by the organization to establish a process capability baseline
for the organization's standard software process.
At Level 5, data are used to select areas for technology and process
improvements, plan these improvements, and evaluate the effects of these
improvements on the organization's process capability.
Although the CMM attempts to remain independent of specific organizational
structures and models, it is necessary to express the practices in the CMM
consistently using terminology related to organizational structure and roles,
which may differ from that followed by any specific organization. The following
sections describe the various concepts related to organizations, projects,
and roles that are necessary for interpreting the key practices of the CMM.
A role is a unit of defined responsibilities that may be assumed by one
or more individuals. The following descriptions of roles are frequently
used in the key practices:
Manager
A manager fulfills a role that encompasses providing technical and administrative
direction and control to individuals performing tasks or activities within
the manager's area of responsibility. The traditional functions of a manager
include planning, resourcing, organizing, directing, and controlling work
within an area of responsibility.
Senior manager
A senior manager fulfills a management role at a high enough level in
an organization that the primary focus is the long-term vitality of the
organization, rather than short-term project and contractual concerns
and pressures. In general, a senior manager for engineering would have
responsibility for multiple projects. A senior manager also provides and
protects resources for long-term improvement of the software process (e.g.,
a software engineering process group).
Senior management, as used in the CMM, can denote any manager who satisfies
the above description, up to and including the head of the whole organization.
As used in the key practices, the term senio 194 r management should be
interpreted in the context of the key process area and the projects and
organization under consideration. The intent is to include specifically
those senior managers who are needed to fulfill the leadership and oversight
roles essential to achieving the goals of the key process area.
Project manager
A project manager fulfills the role with total business responsi fba
bility for an entire project; the project manager is the individual who
directs, controls, administers, and regulates a project building a software
or hardware/software system. The project manager is the individual ultimately
responsible to the customer.
In a project-oriented organizational structure, most of the people working
on a project would report to the project manager, although some disciplines
might have a matrixed reporting relationship. In a matrixed organizational
structure, it may be only the business staff who reports to the project
manager. The engineering groups would then have a matrixed reporting relationship.
Project software manager
A project software manager fulfills the role with total responsibility
for all the software activities for a project. The project software manager
is the individual the project manager deals with in terms of software
commitments and who controls all the software resources for a project.
The software engineering groups on a project would report to the project
software manager, although some activities such as tools development might
have a matrixed reporting relationship.
In a large project, the project software manager is likely to be a second-,
third-, or fourth-line manager. In a small project or department with
a single project, the project software manager might be the first-line
software manager or might be at a higher level.
First-line software manager
A first-line software manager fulfills the role with direct management
responsibility (including providing technical direction and administering
the personnel and salary functions) for the staffing and activities of
a single organizational unit (e.g., a department or project team) of software
engineers and other related staff.
Software task leader
A software task leader fulfills the role of leader of a technical team
for a specific task, who has technical responsibility and provides technical
direction to the staff working on the task.
The software task leader usually reports to the same first-line software
manager as the other people who are working on the task.
Staff, software engineering staff, individuals
Several terms are used in the CMM to denote the individuals who perform
the various technical roles described in various key practices of the
CMM. The staff are the individuals, including task leaders, who are responsible
for accomplishing an assigned function, such as software development or
software configuration management, but who are not managers.
The software engineering staff are the software technical people (e.g.,
analysts, programmers, and engineers), including software task leaders,
who perform the software development and maintenance activities for the
project, but who are not managers.
The term "individuals" as used in the key practices is qualified and
bounded by the context in which the term appears (e.g., "the individual
involved in managing the software subcontract").
A similar breakout of roles can be identified for other engineering
groups such as system engineering or system test.
In a particular project or organization, there does not need to be a
one-to-one correspondence between these roles and individuals. One person
could perform in multiple roles, or each role could be performed by separate
individuals.
For example, on a small, software-only project, one person might have
as many as six roles: the system engineering first-line manager, the project
system engineering manager, the software first-line manager, the project
software manager, the project manager, and the software configuration
management manager.
On a slightly larger project, one person might be the system engineering
first-line manager, the project system engineering manager, and the project
manager while another person might be both the first-line software manager
and the project software manager. These two managers might be in the same
second-line or 196 ganization or in different second-line organizations.
On a large project, many roles, especially those of management, would
likely be filled by separate individuals.
The fundamental concepts of organization, project, and group must be understood
to properly interpret the key practices of the Capability Maturity Model.
The following pa fd1 ragraphs define the use of these concepts in the CMM:
Organization
An organization is a unit within a company or other entity (e.g., government
agency or branch of service) within which many projects are managed as
a whole. All projects within an organization share a common top-level
manager and common policies.
Project
A project is an undertaking requiring concerted effort, which is focused
on developing and/or maintaining a specific product. The product may include
hardware, software, and other components. Typically a project has its
own funding, cost accounting, and delivery schedule.
Group
A group is the collection of departments, managers, and individuals
who have responsibility for a set of tasks or activities. A group could
vary from a single individual assigned part time, to several part-time
individuals assigned from different departments, to several individuals
dedicated full time.
Groups commonly referred to in the CMM are described below:
Software engineering group
The software engineering group is the collection of individuals (both
managers and technical staff) who have responsibility for software development
and maintenance activities (i.e., requirements analysis, design, code,
and test) for a project.
Groups performing software-related work, such as the software quality
assurance group, the software configuration management group, and the
software engineering process group, are not included in the software engineering
group. These groups are considered to be one of the "other software-related
groups."
Software-related groups
A software-related group is the collection of individuals (both managers
and technical staff) representing a software engineering discipline that
supports, but is not directly responsible for, software development and/or
maintenance.
Examples of software engineering disciplines include software quality
assurance and software configuration management.
Software engineering process group
The software engineering process group is the group of specialists who
facilitate the definition, maintenance, and improvement of the software
process used by the organization. In the key practices, this group is
generically referred to as "the group responsible for the organization's
software process activities."
System engineering group
The system engineering group is the collection of individuals (both
managers and technical staff) who have responsibility for specifying the
system requirements; allocating the system requirements to the hardware,
software, and other components; specifying the interfaces between the
hardware, software, and other components; and monitoring the design and
development of these components to ensure conformance with their specifications.
System test group
The system test group is the collection of individuals (both managers
and technical staff) who have responsibility for planning and performing
the independent system testing of the software to determine whether the
software product satisfies its requirements.
Software quality assurance group
The software quality assurance group is the collection of individuals
(both managers and technical staff) who plan and implement the project's
quality assurance activities to ensure the software process steps and
standards are followed. Organizational issues concerning software quality
assurance are discussed in Section 4.4.3.
Software configuration management group
The software configuration management group is the collection of individuals
(both managers and technical staff) who have responsibility for planning,
coordinating, and implementing the formal configuration management activities
for the software project.
Training group
The training group is the collection of individuals (both managers and
staff) who are responsible for coordinating and arranging the training
activities for an organizat 195 ion. This group typically prepares and
conducts most of the training courses and coordinates use of other training
vehicles.
The organization must take care that the key practices that call for independence
are appropriately interpreted and followed. This is particularly true for
small projects and small organizations. fba The key practices call for independence
when technical or organizational biases may affect the quality or risks
associated with the project. For example, two practices dealing with independence
are:
- The SQA group has a reporting channel to senior management that is
independent of the project manager, the project's software engineering
group, and the other software-related groups (Commitment 1.2 in Software
Quality Assurance). (kp QA.CO.1.2)
- The (system and acceptance) test cases and test procedures are planned
and prepared by a test group that is independent of the software developers
(Activity 7.3 in Software Product Engineering). (kp PE.AC.7.3)
The need for independence of the system and acceptance testing is based
on technical considerations. This independence ensures that the testers
are not inappropriately influenced by the design and implementation decisions
made by the software developers or maintainers.
The independence of the SQA group is necessary so its members can perform
their jobs without being influenced by project schedule and cost pressures.
Ensuring effective operational independence without the organizational
independence is difficult. For example, an employee reporting to the project
manager may be reluctant to stop a test activity even though serious noncompliance
issues exist.
Organizations must determine the organizational structure that will
support activities that require independence, such as SQA, in the context
of their strategic business goals and business environment.
Independence should:
- provide the individuals performing the SQA role with the organizational
freedom to be the "eyes and ears" of senior management on the project,
- protect the individuals performing the SQA role from performance appraisal
by the management of the project about which they are reporting, and
- provide senior management with confidence that objective information
on the process and products of the project is being reported.
Since the key practices allow interpretation of the independence criteria,
professional judgment must be exercised by the organization in determining
whether the goals of the key process area are achieved.
To provide a complete set of valid principles that apply to a wide range
of situations, some of the key practices are intentionally stated to allow
for flexibility. Throughout the key practices, nonspecific phrases like
"affected groups," "as appropriate," and "as necessary" are used. The use
of such nonspecific terms is generally minimized in the key practices, with
examples provided in many cases, at least for the first use of the term.
These phrases may have different meanings for two different organizations,
for two projects in a single organization, or for one project at different
points in its life cycle. Each project or organization must clarify these
phrases for its specific situation.
Clarifying these phrases requires the organization to consider the overall
context in which they are used. The pertinent question is whether the
specific interpretation of one of these phrases meets the goals of the
key process area. Professional judgment must be used to determine whether
the goals have been achieved. The glossary in Appendix B may provide guidance
in interpreting these and other phrases in the key practices.
Professional judgment must also be used when interpreting the key practices
and how they contribute to the goals of a key process area. In general,
the key process areas describe a fundamental set of behaviors that all
software organizations should exhibit, regardless of their size or their
products. The key practices in the CMM, however, must be interpreted in
light of a project's or organization's business environment and specific
circumstances. This interpretation should be based on an informed knowledge
of both the CMM and the organizat 190 ion and its projects. The goals
of the key process areas provide a means for structuring this interpretation.
If an organization's implementation of a key process area satisfies the
goals, but differs significantly from the key practices, the rationale
for the interpretation should be documented. A documented rationale will
help assessment and evaluation teams understand why certain practices
a fbe re implemented the way they are.
Applying professional judgment leads to the issue of the "goodness"
of the software process. The CMM does not place "goodness" requirements
on the software process, although it does establish minimal criteria for
a "reasonable" process in many software environments. The objective of
process management is to establish processes that are used and can act
as a foundation for systematic improvement based on the organization's
business needs.
What are the criteria for a "reasonable" software process? A reasonable
software process is one that is effective in building the organizational
capability and satisfies most of the requirements of a defined process.
Specifically, it is practiced, documented, enforced, trained, measured,
and able to improve.
If an organization established a software process for estimating that
consisted of rolling the dice, would that constitute a reasonable process?
It could certainly be documented and consistently followed. Some might
even argue that it would be as realistic as many estimating techniques.
"Rolling the dice" would, however, not be judged a reasonable estimating
process by most software professionals. Since it responds only to the
laws of probability, it cannot be improved.
How far is it from "rolling the dice" to documenting a process to "go
ask George?" This could be a very good method for estimating. As long
as George is around, it could even be consistent and repeatable. It would
not, however, satisfy our criteria since it cannot be trained to other
individuals. It is a person-centered process that cannot be repeated without
George. It does not build an ongoing organizational capability.
Using some variant of a Delphi method (a method where experts in a subject
review the issues under consideration and come to consensus on the recommendations
related to the issue) for estimating would usually be judged a reasonable
software process. A size estimating approach based on a Delphi method
satisfies the criteria for a reasonable and effective process, even though
the Delphi method is a person-centered process. An organizational capability
can be based on a structured technique such as a Delphi method.
In a fundamental sense, professional judgment is necessary to make such
distinctions. The difficulty lies in discriminating between compliance
and goodness. The goals summarize the key practices, which, in turn, describe
a reasonable software process. Complying with a reasonable process, however,
does not mean that the process is efficient in achieving its purpose.
There may be many factors influencing both organization and project success.
For example, a successful project that builds a product that no one buys
is a failure in the commercial world.
"Goodness" attributes can only be interpreted in the context of the
business environment and specific circumstances of the project and the
organization. Such "goodness" judgments can be made only by the organization
as part of its continuous process improvement cycle. Perfection is never
achieved, and continuous process improvement never ends.
|