Level 2 - Software Project Tracking and Oversight

Software Project Tracking and Oversight

a key process area for level 2: Repeatable


The purpose of Software Project Tracking and Oversight is to provide adequate visibility into actual progress so that management can take effective actions when the software project's performance deviates significantly from the software plans.

Software Project Tracking and Oversight involves tracking and reviewing the software accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on the actual accomplishments and results.

A documented plan for the software project (i.e., the software development plan, as described in the Software Project Planning key process area) is used as the basis for tracking the software activities, communicating status, and revising plans. Software activities are monitored by the management. Progress is primarily determined by comparing the actual software size, effort, cost, and schedule to the plan when selected software work products are completed and at selected milestones. When it is determined that the software project's plans are not being met, corrective actions are taken. These actions may include revising the software development plan to reflect the actual accomplishments and replanning the remaining work or taking actions to improve the performance.

Goals

Goal 1

Actual results and performances are tracked against the software plans.

Goal 2

Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.

Goal 3

Changes to software commitments are agreed to by the affected groups and individuals.

Commitment to perform

Commitment 1 -- A project software manager is designated to be responsible for the project's software activities and results.

Commitment 2 -- The project follows a written organizational policy for managing the software project.

This policy typically specifies that:
  1. A documented software development plan is used and maintained as the basis for tracking the software project.
  2. The project manager is kept informed of the software project's status and issues.
  3. Corrective actions are taken when the software plan is not being achieved, either by adjusting performance or by adjusting the plans.
  4. Changes to the software commitments are made with the involvement and agreement of the affected groups.
    Examples of affected groups include:
    • software engineering (including all subgroups, such as software design),
    • software estimating,
    • system engineering,
    • system test,
    • software quality assurance,
    • software configuration management,
    • contract management, and
    • documentation support.

  5. Senior management reviews all commitment changes and new software project commitments made to individuals and groups external to the organization.

Ability to perform

Ability 1 -- A software development plan for the software project is documented and approved.


Refer to Activities 6 and 7 of the Software Project Planning key process area for practices covering the software development plan.


Ability 2 -- The project software manager explicitly assigns responsibility for software work products and activities.

The assigned responsibilities cover:

  1. The software work products to be developed or services to be provided.
  2. The effort and cost for these software activities.
  3. The schedule for these software activities.
  4. The budget for these software activities.

Ability 3 -- Adequate resources and funding are provided for tracking the software project.

  1. The software managers and the software task leaders are assigned specific responsibilities for tracking the software project.
  2. Tools to support software tracking are made available.
    Examples of support tools include:
    • spreadsheet programs, and
    • project planning/scheduling programs.

Ability 4 -- The software managers are trained in managing the technical and personnel aspects of the software project.


Examples of training include:
  • managing technical projects;
  • tracking and oversight of software size, effort, cost, and schedule; and
  • managing people.

Ability 5 -- First-line software managers receive orientation in the technical aspects of the software project.


Examples of orientation include:
  • the project's software engineering standards and procedures, and
  • the project's application domain.

Activities performed

Activity 1 -- A documented software development plan is used for tracking the software activities and communicating status.


Refer to Activity 7 of the Software Project Planning key process area for practices covering the content of the software development plan.


This software development plan is:
  1. Updated as the work progresses to reflect accomplishments, particularly when milestones are completed.
  2. Readily available to:
    • the software engineering group (including all subgroups, such as software design),
    • the software managers,
    • the project manager,
    • senior management, and
    • other affected groups.

Activity 2 -- The project's software development plan is revised according to a documented procedure.


Refer to Activity 6 of the Software Project Planning key process area for practices covering the activities for producing the software development plan.


This procedure typically specifies that:
  1. The software development plan is revised, as appropriate, to incorporate plan refinements and incorporate plan changes, particularly when plans change significantly.
    Interdependencies between the system requirements allocated to software, design constraints, resources, costs, and schedule need to be reflected in all changes to the plan.


  2. The software development plan is updated to incorporate all new software project commitments and changes to commitments.
  3. The software development plan is reviewed at each revision.
  4. The software development plan is 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 3 -- Software project commitments and changes to commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure.

Activity 4 -- Approved changes to commitments that affect the software project are communicated to the members of the software engineering group and other software-related groups.


Examples of other software-related groups include:
  • software quality assurance,
  • software configuration management, and
  • documentation support.

Activity 5 -- The size of the software work products (or size of the changes to the software work products) are tracked, and corrective actions are taken as necessary.


Refer to Activity 9 of the Software Project Planning key process area for practices covering derivation of size estimates.


  1. Sizes for all major software work products (or the size of the changes) are tracked.
  2. Actual size of code (generated, fully tested, and delivered) is compared to the estimates documented in the software development plan.
  3. Actual units of delivered documentation are compared to the estimates documented in the software development plan.
  4. Overall projected size of the software work products (estimates combined with actuals) is refined, monitored, and adjusted on a regular basis.
  5. Changes in size estimates of the software work products that affect software commitments are negotiated with the affected groups and are documented.

Activity 6 -- The project's software effort and costs are tracked, and corrective actions are taken as necessary.


Refer to Activity 10 of the Software Project Planning key process area for practices covering the derivation of cost estimates.


  1. Actual expenditures of effort and costs over time and against work completed are compared to the estimates documented in the software development plan to identify potential overruns and underruns.
  2. Software costs are tracked and compared to the estimates documented in the software development plan.
  3. Effort and staffing are compared to the estimates documented in the software development plan.
  4. Changes in staffing and other software costs that affect software commitments are negotiated with the affected groups and are documented.

Activity 7 -- The project's critical computer resources are tracked, and corrective actions are taken as necessary.


Refer to Activity 11 of the Software Project Planning key process area for practices covering the derivation of computer resource estimates.


  1. The actual and projected use of the project's critical computer resources are tracked and compared to the estimates for each major software component as documented in the software development plan.
  2. Changes in estimates of critical computer resources that affect software commitments are negotiated with the affected groups and are documented.

Activity 8 -- The project's software schedule is tracked, and corrective actions are taken as necessary.


Refer to Activity 12 of the Software Project Planning key process area for practices covering derivation of the schedule.


  1. Actual completion of software activities, milestones, and other commitments is compared against the software development plan.
  2. Effects of late and early completion of software activities, milestones, and other commitments are evaluated for impacts on future activities and milestones.
  3. Software schedule revisions that affect software commitments are negotiated with the affected groups and are documented.

Activity 9 -- Software engineering technical activities are tracked, and corrective actions are taken as necessary.

  1. Members of the software engineering group report their technical status to their first-line manager on a regular basis.
  2. Software release contents for successive builds are compared to the plans documented in the software development plan.
  3. Problems identified in any of the software work products are reported and documented.
  4. Problem reports are tracked to closure.

Activity 10 -- The software risks associated with cost, resource, schedule, and technical aspects of the projectare tracked.


Refer to Activity 13 of the Software Project Planning key process area for practices covering identification of risks.


  1. The priorities of the risks and the contingencies for the risks are adjusted as additional information becomes available.
  2. High-risk areas are reviewed with the project manager on a regular basis.

Activity 11 -- Actual measurement data and replanning data for the software project are recorded.


Refer to Activity 15 of the Software Project Planning key process area for practices covering recording of project data.


  1. Information recorded includes the estimates and associated information needed to reconstruct the estimates and verify their reasonableness.
  2. The software replanning data are managed and controlled.
  3. The software planning data, replanning data, and the actual measurement data are archived for use by ongoing and future projects.

Activity 12 -- The software engineering group conducts periodic internal reviews to track technical progress, plans, performance, and issues against the software development plan.

These reviews are conducted between:
  1. The first-line software managers and their software task leaders.
  2. The project software manager, first-line software managers, and other software managers, as appropriate.

Activity 13 -- Formal reviews to address the accomplishments and results of the software project are conducted at selected project milestones according to a documented procedure.

These reviews:
  1. Are planned to occur at meaningful points in the software project's schedule, such as the beginning or completion of selected stages.
  2. Are conducted with the customer, end user, and affected groups within the organization, as appropriate.
    The end users referred to in these practices are the customer designated end users or representatives of the end users.


  3. Use materials that are reviewed and approved by the responsible software managers.
  4. Address the commitments, plans, and status of the software activities.
  5. Result in the identification and documentation of significant issues, action items, and decisions.
  6. Address the software project risks.
  7. Result in the refinement of the software development plan, as necessary.

Measurement and analysis

Measurement 1 -- Measurements are made and used to determine the status of the software tracking and oversight activities.


Examples of measurements include:

  • effort and other resources expended in performing the tracking and oversight activities; and

  • change activity for the software development plan, which includes changes to size estimates of the software work products, software cost estimates, critical computer resource estimates, and schedule.


Verifying implementation

Verification 1 -- The activities for software project tracking and oversight are reviewed with senior management 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.


  1. The technical, cost, staffing, and schedule performance are reviewed.
  2. Conflicts and issues not resolvable at lower levels are addressed.
  3. Software project risks are addressed.
  4. Action items are assigned, reviewed, and tracked to closure.
  5. A summary status report from each meeting is prepared and distributed to the affected groups.

Verification 2 -- The activities for software project tracking and oversight are reviewed with the project manager on both a periodic and event-driven basis.

  1. Affected groups are represented.
  2. The technical, cost, staffing, and schedule performance is reviewed against the software development plan.
  3. Use of critical computer resources is reviewed; current estimates and actual use of these critical computer resources are reported against the original estimates.
  4. Dependencies between groups are addressed.
  5. Conflicts and issues not resolvable at lower levels are addressed.
  6. Software project risks are addressed.
  7. Action items are assigned, reviewed, and tracked to closure.
  8. A summary report from each meeting is prepared and distributed to the affected groups.

Verification 3 -- The software quality assurance group reviews and/or audits the activities and work products for software project tracking and oversight and reports the results.


Refer to the Software Quality Assurance key process area.


At a minimum, the reviews and/or audits verify:
  1. The activities for reviewing and revising commitments.
  2. The activities for revising the software development plan.
  3. The content of the revised software development plan.
  4. The activities for tracking the software project's cost, schedule, risks, technical and design constraints, and functionality and performance.
  5. The activities for conducting the planned technical and management reviews.

[^^]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