Interpreting the CMM

4 Interpreting the CMM

4.1 Interpreting the Key Practices

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 and 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.

4.2 Interpreting the Common Features

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.

4.2.1 Commitment to Perform

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.

4.2.2 Ability to Perform

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 related 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 Levels 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.

4.2.3 Activities Performed

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.

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 detail 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-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 agreed 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).

4.2.4 Measurement and Analysis

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.

4.2.5 Verifying Implementation

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 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 involvement 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.

4.3 Interpreting Software Process Definition

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.

4.3.1 Process Definition Concepts

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, "Software Process Development and Enactment: Concepts and Definitions" [Feiler 92].

Figure 4.1 Conceptual Software Process Framework Used in the CMM

4.3.2 Concepts Related to the Organization's Software Process Assets

Organization's software process assets

The organization establishes and maintains a set 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 may 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 established 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.

4.3.3 Concepts Related to the Project's Defined Software Process

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 completion 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 "activity" 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.

4.3.4 Relationship Between the Project's Defined Software Process and the Software Development Plan

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.

4.3.5 Life Cycles and the CMM

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.

4.3.6 Technology and the CMM

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.

4.3.7 Documentation and the CMM

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 relationship 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 example, 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.

4.3.8 Collection and Analysis of Process Data

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.

4.4 Organizational Structure and Roles

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.

4.4.1 Organizational Roles

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 senior 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 responsibility 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 organization or in different second-line organizations.

On a large project, many roles, especially those of management, would likely be filled by separate individuals.

4.4.2 Organizational Structure

The fundamental concepts of organization, project, and group must be understood to properly interpret the key practices of the Capability Maturity Model. The following paragraphs 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 organization. This group typically prepares and conducts most of the training courses and coordinates use of other training vehicles.

4.4.3 Independence and Organizational Structure

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

4.5 Applying Professional Judgment

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 organization 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 are 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.

[^^]Overview table of contents [->]Back one chapter

page d'accueil

contact

 

menu precedent
Acknowledgements
SEI CMM Key Practices - Overview
Introduction
CMM Overview
Using the Key Practice Pages
Interpreting the CMM
Level 2 - Requirements Management
Level 2 - Software Project Planning
Level 2 - Software Project Tracking and Oversight
Level 2 - Software Subcontract Management
Level 2 - Software Quality Assurance
Level 2 - Software Configuration Management
Level 3 - Organization Process Focus
Level 3 - Organization Process Definition
Level 3 - Training Program
Level 3 - Integrated Software Management
Level 3 - Software Product Engineering
Level 3 - Intergroup Coordination
Level 3 - Peer Reviews
Level 4 - Quantitative Process Management
Level 4 - Software Quality Management
Level 5 - Defect Prevention
Level 5 - Technology Change Management
Level 5 - Process Change Management
Appendix A: References
Appendix B: Glossary
Appendix C: Abridged Key Practices
Appendix D: Change History

 

 

contact

<-- precedent ] page d'accueil ] menu precedent ] suite --> ]

FREE, la liberté n'a pas de prix !  antoine@apple2.com 29-04-2000