Level 3 - Organization Process Definition

Organization Process Definition

a key process area for level 3: Defined

The purpose of Organization Process Definition is to develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization.

Organization Process Definition involves developing and maintaining the organization's standard software process, along with related process assets, such as descriptions of software life cycles, process tailoring guidelines and criteria, the organization's software process database, and a library of software process-related documentation.

These assets may be collected in many ways, depending on the organization's implementation of Organization Process Definition. For example, the descriptions of the software life cycles may be an integral part of the organization's standard software process or parts of the library of software process-related documentation may be stored in the organization's software process database.

The organization's software process assets are available for use in developing, implementing, and maintaining the projects' defined software processes. (The practices related to the development and maintenance of the project's defined software process are described in the Integrated Software Management key process area.)

Goals

Goal 1

A standard software process for the organization is developed and maintained.

Goal 2

Information related to the use of the organization's standard software process by the software projects is collected, reviewed, and made available.

Commitment to perform

Commitment 1 -- The organization follows a written policy for developing and maintaining a standard software process and related process assets.

The organization's software process assets include:
  • the organization's standard software process,
  • guidelines and criteria for the projects' tailoring of the organization's standard software process,
  • descriptions of software life cycles approved for use,
  • the organization's software process database, and
  • a library of software process-related documentation previously developed and available for reuse.
This policy typically specifies that:
  1. A standard software process is defined for the organization.
    The primary purposes of a standard software process are to maximize the sharing of process assets and experiences across the projects and to provide the ability to define and aggregate a standard set of process measurements from the projects at the organization level.

    The organization's standard software process may contain multiple software processes. Multiple software processes may be needed to address the needs of different applications, life cycles, methodologies, and tools, which the software projects may compose in multiple ways.

  2. A project's defined software process is a tailored version of the organization's standard software process.
    Refer to Activity 1 of the Integrated Software Management key process area for practices covering tailoring of the organization's standard software process.

  3. The organization's software process assets are maintained.
  4. Information collected from the projects is organized and used to improve the organization's standard software process.
    Examples of collected information include:
    • process and product measurements,
    • lessons learned, and
    • other process-related documentation.

Ability to perform

Ability 1 -- Adequate resources and funding are provided for developing and maintaining the organization's standard software process and related process assets.

  1. The development and maintenance of the organization's standard software process and related process assets is performed or coordinated by the group responsible for the organization's software process activities (e.g., software engineering process group).
    Refer to the Organization Process Focus key process area for practices covering the group responsible for the organization's software process activities.

  2. Tools to support process development and maintenance are made available.
    Examples of support tools include:
    • desktop publishing tools,
    • database management systems, and
    • process modeling tools.

Ability 2 -- The individuals who develop and maintain the organization's standard software process and related process assets receive required training to perform these activities.

Examples of training include:
  • software engineering practices and methods,
  • process analysis and documentation methods, and
  • process modeling.

Refer to the Training Program key process area.

Activities performed

Activity 1 -- The organization's standard software process is developed and maintained according to a documented procedure.

This procedure typically specifies that:
  1. The organization's standard software process satisfies the software policies, process standards, and product standards imposed on the organization, as appropriate.
  2. The organization's standard software process satisfies the software process and product standards that are commonly imposed on the organization's projects by their customers, as appropriate.
  3. State-of-the-practice software engineering tools and methods are incorporated into the organization's standard software process, as appropriate.
  4. The internal process interfaces between the software disciplines are described.
    Examples of software engineering disciplines include:
    • software requirements analysis,
    • software design,
    • coding,
    • software testing,
    • software configuration management, and
    • software quality assurance.
  5. The external process interfaces between the software process and the processes of other affected groups are described.

    Examples of other affected groups include:
    • system engineering,
    • system test,
    • contract management, and
    • documentation support.
  6. Changes proposed for the organization's standard software process are documented, reviewed, and approved by the group responsible for the organization's software process activities (e.g., software engineering process group) before they are incorporated.
    Examples of sources for change include:
    • the findings and recommendations of software process assessments,
    • results of the project's tailoring of the organization's standard software process,
    • lessons learned from monitoring the organization's and projects' software process activities,
    • changes proposed by the organization's staff and managers, and
    • process and product measurement data that are analyzed and interpreted.
  7. Plans for introducing changes to the software process of ongoing projects are defined as appropriate.
  8. The description of the organization's standard software process undergoes peer review when initially developed and whenever significant changes or additions are made.
    Refer to the Peer Reviews key process area.

  9. The description of the organization's standard software process is placed under configuration management.
    Refer to the Software Configuration Management key process area.

Activity 2 -- The organization's standard software process is documented according to established organization standards.

These standards typically specify that:
  1. The process is decomposed into constituent process elements to the granularity needed to understand and describe the process.
    Each process element covers a well-defined, bounded, closely related set of activities.

    Examples of process elements include:

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

  2. Each process element is described and addresses:
    • the required procedures, practices, methods, and technologies;
    • the applicable process and product standards;
    • the responsibilities for implementing the process;
    • the required tools and resources;
    • inputs;
    • the software work products produced;
    • the software work products that should undergo peer review;
    • the readiness and completion criteria; and
    • the product and process data to be collected.
  3. The relationships of the process elements are described and address:
    • the ordering,
    • the interfaces, and
    • the interdependencies.
    This relationship of the process elements is sometimes referred to as a software process architecture.

Activity 3 -- Descriptions of software life cycles that are approved for use by the projects are documented and maintained.

Examples of software life cycles include:
  • waterfall,
  • overlapping waterfall,
  • spiral,
  • serial build, and
  • single prototype/overlapping waterfall.
  1. The software life cycles are compatible with the organization's standard software process.
  2. Changes proposed for the descriptions of software life cycles are documented, reviewed, and approved by the group responsible for the organization's software process activities (e.g., software engineering process group) before they are incorporated.
  3. The descriptions of the software life cycles undergo peer review when initially documented and whenever significant changes or additions are made.

    Refer to the Peer Reviews key process area.

  4. The descriptions of the software life cycles are managed and controlled.
    "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).

    If a greater degree of control than is implied by "managed and controlled" is desired, the work product can be placed under the full discipline of configuration management, as is described in the Software Configuration Management key process area.

Activity 4 -- Guidelines and criteria for the projects' tailoring of the organization's standard software process are developed and maintained.

  1. The tailoring guidelines and criteria cover:
    • selecting and tailoring the software life cycle for the project,
    • tailoring the organization's standard software process to accommodate the software life cycle and the project's characteristics, and
      Examples of tailoring include:
      • adapting the process for a new product line or host environment,
      • customizing the process for a specific project or class of projects, and
      • elaborating and adding detail to the process so that the resulting project's defined software process can be enacted.
    • standards for documenting the project's defined software process.
  2. Changes proposed for the tailoring guidelines and criteria are documented, reviewed, and approved by the group responsible for the organization's software process activities (e.g., software engineering process group) before they are incorporated.
  3. The tailoring guidelines and criteria are managed and controlled.

Activity 5 - The organization's software process database is established and maintained.

  1. The database is established to collect and make available data on the software processes and resulting software work products.
    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;
    • quality measurements;
    • peer review coverage and efficiency;
    • test coverage and efficiency;
    • software reliability measures;
    • number and severity of defects found in the software requirements; and
    • number and severity of defects found in the software code.
  2. The data entered into the database is reviewed to ensure the integrity of the database contents.

    In addition, the database also contains or references the actual measurement data and related information and data needed to understand and interpret the measurement data and assess it for reasonableness and applicability.

  3. The database is managed and controlled.
  4. User access to the database contents is controlled to ensure completeness, integrity, and accuracy of the data.
    Access is limited to those who have a need to enter, change, view, analyze, or extract data.

    Sensitive data are protected and access to these data is appropriately controlled.

Activity 6 -- A library of software process-related documentation is established and maintained.

Examples of software process-related documentation include:
  • the description of a project's defined software process,
  • a project's standards,
  • a project's procedures,
  • a project's software development plans,
  • a project's measurement plans, and
  • a project's process training materials.
  1. Candidate documentation items are reviewed and appropriate items that may be useful in the future are included in the library.
  2. The documentation items are catalogued for easy access.
  3. Revisions made to documentation items currently in the library are reviewed, and the library contents are updated as appropriate.
  4. The library contents are made available for use by the software projects and other software-related groups.
    Examples of software-related groups include:
    • software quality assurance
    • software configuration management,
    • software test, and
    • documentation support.
  5. The use of each documentation item is reviewed periodically, and the results are used to maintain the library contents.
  6. The library contents are managed and controlled.

Measurement and analysis

Measurement 1 -- Measurements are made and used to determine the status of the organization's process definition activities.

Examples of measurements include:
  • status of the schedule milestones for process development and maintenance, and
  • costs for the process definition activities.

Verifying implementation

Verification 1 -- The software quality assurance group reviews and/or audits the organization's activities and work products for developing and maintaining the organization's standard software process and related process assets and reports the results.

Refer to the Software Quality Assurance key process area.

At a minimum, these reviews and/or audits verify that:

  1. The appropriate standards are followed in developing, documenting, and maintaining the organization's standard software process and related process assets.
  2. The organization's standard software process and related process assets are controlled and used appropriately.

[^^]Table of contents [->]Back one chapter [->]Forward 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