Integrated Software Management

a key process area for level 3: Defined

Integrated Software Management involves developing the project's defined software process and managing the software project using this defined software process. The project's defined software process is tailored from the organization's standard software process to address the specific characteristics of the project.

The software development plan is based on the project's defined software process and describes how the activities of the project's defined software process will be implemented and managed. The management of the software project's size, effort, cost, schedule, staffing, and other resources is tied to the tasks of the project's defined software process.

Since the projects' defined software processes are all tailored from the organization's standard software process, the software projects can share process data and lessons learned.

The basic practices for estimating, planning, and tracking a software project are described in the Software Project Planning and Software Project Tracking and Oversight key process areas. They focus on recognizing problems when they occur and adjusting the plans and/or performance to address the problems. The practices of this key process area build on, and are in addition to, the practices of those two key process areas. The emphasis of Integrated Software Management shifts to anticipating problems and acting to prevent or minimize the effects of these problems.

Goals

Goal 1

Goal 2

Commitment to perform

Commitment 1 -- The project follows a written organizational policy requiring that the software project be planned and managed using the organization's standard software process and related process assets.

1. Each project documents the project's defined software process by tailoring the organization's standard software process.
2. The project's deviations from the organization's standard software process are documented and approved.
3. Each project performs its software activities in accordance with the project's defined software process.
4. Each project collects and stores appropriate project measurement data in the organization's software process database.

Ability to perform

Ability 1 -- Adequate resources and funding are provided for managing the software project using the project's defined software process.

Ability 2 -- The individuals responsible for developing the project's defined software process receive required training in how to tailor the organization's standard software process and use the related process assets.

• using the software process database,
• using the organization's standard software process, and
• using the guidelines and criteria for tailoring the organization's standard software process to meet the needs of the software project.

Ability 3 -- The software managers receive required training in managing the technical, administrative, and personnel aspects of the software project based on the project's defined software process.

• methods and procedures for software estimating, planning, and tracking based on the project's defined software process; and
• methods and procedures for identifying, managing, and communicating software risks.

Activities performed

Activity 1 -- The project's defined software process is developed by tailoring the organization's standard software process according to a documented procedure.

1. A software life cycle is:
   • selected from among those approved by the organization, to satisfy the project's contractual and operational constraints;

     ---

     Refer to Activity 3 of the Organization Process Definition key process area for practices covering approved software life cycles.

     ---

   • modified, if necessary, in ways permitted by the organization's tailoring guidelines and criteria; and
   • documented according to the organization's standards.

   ---

   Refer to Activity 4 of the Organization Process Definition key process area for practices covering the organization's tailoring guidelines and criteria.

   ---

2. The description of the project's defined software process is documented.

   ---

   Refer to Activity 2 of the Organization Process Definition key process area for practices covering the expected contents of a process definition.

   ---

   ---

   The tailoring uses the organization's process assets as appropriate.

   ---

3. Tailoring of the organization's standard software process for the project is reviewed by the group responsible for coordinating the organization's software process activities (e.g., software engineering process group) and approved by senior management.

   ---

   Refer to Activity 6 of the Organization Process Definition key process area for practices covering the library of software process-related documentation.

   ---

   • Waivers for deviations from the organization's standard software process are documented and are reviewed and approved by senior management.
4. Waivers for deviations from contractual software process requirements are documented and are reviewed and approved by senior management and the software project's customer, as appropriate.
5. The description of the project's defined software process 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 2 -- Each project's defined software process is revised according to a documented procedure.

1. Changes derived from the following are documented and systematically reviewed:
   • lessons learned from monitoring the software activities of the organization's projects,
   • changes proposed by the software project, and
   • process and work product measurement data.
2. Changes to the project's defined software process are reviewed and approved before they are incorporated.

   ---

   Examples of individuals who review the changes include:
   • members of the groups responsible for the organization's software process activities (e.g., software engineering process group),
   • the software managers, and
   • the project software manager.

   ---

   ---

   Examples of individuals who approve the changes include:
   • the project software manager, and
   • the project manager.

   ---

Activity 3 -- The project's software development plan, which describes the use of the project's defined software process, is developed and revised according to a documented procedure.

Activity 4 -- The software project is managed in accordance with the project's defined software process.

1. Provisions are made for gathering, analyzing, and reporting measurement data needed to manage the software project.
2. The activities for software estimating, planning, and tracking are tied to the key tasks and work products of the project's defined software process.
3. Readiness and completion criteria are established, documented, and used to authorize initiation and determine completion of key tasks.
4. Documented criteria are defined to indicate when to replan the software project.
5. Technical and management lessons learned are documented and stored in the organization's library of software process-related documentation.

   ---

   Refer to Activity 6 of the Organization Process Definition key process area for practices covering the organization's library of software process-related documentation.

   ---

6. Technical and management lessons learned from monitoring the activities of other projects in the organization are systematically reviewed and used to estimate, plan, track, and replan the software project.
7. The staffing plan addresses the software project's needs for individuals with special skills and application domain knowledge.
8. Training needs are identified and documented to fit the specific needs of the software project.

   ---

   Refer to Activity 1 of the Training Program key process area for practices covering the identification of the project's training needs.

   ---

9. The software plans and processes followed in interacting with other groups are adjusted to account for disparities with these groups and for other potential problems.

   ---

   Examples of disparities and problems include:
   • differences in process maturity,
   • process incompatibility, and
   • various business factors.

   ---

Activity 5 -- The organization's software process database is used for software planning and estimating.

1. The database is used as a source of data to estimate, plan, track, and replan a software project; data for similar software projects are used when possible.

   ---

   Examples of data contained in the organization's software process database include:
   • size of the software work products,
   • software effort,
   • software cost,
   • schedule,
   • staffing, and
   • technical activities.

   ---

2. Parameter values used to derive estimates for software size, effort, cost, schedule, and use of critical computer resources are compared to those of other software projects to assess their validity.
   • Similarities and differences to the other projects in terms of application domain and design approach are assessed and recorded.
   • Rationales for similarities and differences between the parameter values are recorded.
   • The reasoning used to judge the credibility of the project's estimates is recorded.
3. The software project provides appropriate software planning data, replanning data, and actual measured data for storage in the organization's software process database.

   ---

   Examples of data recorded by the software project include:
   • the task description,
   • the assumptions,
   • the estimates,
   • the revised estimates,
   • the actual measured data, and
   • the associated information needed to reconstruct the estimates, assess their reasonableness, and derive estimates for new work.

   ---

Activity 6 -- The size of the software work products (or size of changes to the software work products) is managed according to a documented procedure.

1. A group that is independent of the software engineering group reviews the procedures for estimating the size of the software work products, and provides guidance in using historical data from the organization's software process database to establish credible estimates.

   ---

   An example of an independent group is a software estimating group.

   An example of a method to evaluate the credibility of software size estimates is a function-by-function comparison to a completed system.

   ---

   • The individuals who prepare the size estimates ensure that the procedures and data used in the estimates are appropriate.
   • When the validity of a size estimate is questioned, a team of peers and experts reviews the estimate.
2. A contingency factor is applied to the size estimate for each software element identified as a software risk.
   • The rationale for the contingency is documented.
   • The risks associated with reducing or eliminating the contingency are assessed and documented.
3. Off-the-shelf or reusable software components are identified.
   • Reuse measurements account for the reuse of requirements, design, code, test plan, and test procedures, etc.
   • The effort to modify and incorporate reusable components is factored into the size estimates.
4. Factors which could significantly affect the size of the software work products are identified and monitored closely.
5. A size threshold is established for each managed software element which, when projected to be exceeded, requires action.

Activity 7 -- The project's software effort and costs are managed according to a documented procedure.

1. Software effort, cost, and staffing profile models, if used, are adapted to the project and use available historical data where appropriate.
2. Referenced productivity and cost data are adjusted to incorporate project variables.

   ---

   Examples of project variables include:
   • the geographic locations of the project's groups and organizations (e.g., subcontractor),
   • the size and complexity of the system,
   • the stability of the requirements,
   • the host environment for development,
   • the target environment of the system,
   • the developers' familiarity and experience with the application,
   • the availability of resources, and
   • other special constraints.

   ---

3. The overall software effort and cost is allocated to individually managed tasks or stages as needed to manage the effort and cost effectively.
4. When the software effort and cost status is reviewed and the estimates are revised, actual expenditures over time and against work completed are compared to the software development plan and used to refine the effort and cost estimates for remaining work.
   • Parameter values of the models used in estimating software effort and costs are updated whenever major changes are made to the software requirements.
   • Actual data on project productivity and other new software costs are used where appropriate.
5. An effort and cost threshold is established for each individually managed software task or stage which, when projected to be exceeded, requires action.

Activity 8 -- The project's critical computer resources are managed according to a documented procedure.

1. Estimates for the project's critical computer resources are derived based on historical experience, simulations, prototyping, or analysis, as appropriate.
   • Sources and rationale for estimates are documented.
   • Similarities and differences between the project and the sources for historical data in terms of application domain and design approach are assessed and recorded.
   • The reasoning used to judge the credibility of the estimates is recorded.
2. The planned computer resources, the system requirements allocated to software, the software requirements, and/or the software design are adjusted to achieve the project's critical computer resource requirements.
3. The available computer resources are allocated to the software components.
4. The available capacity for the critical computer resources provides for a specified reserve capacity when the initial estimates are made.
5. A threshold is established for each critical computer resource which, when projected to be exceeded, requires action.

Activity 9 -- The critical dependencies and critical paths of the project's software schedule are managed according to a documented procedure.

1. Milestones, tasks, commitments, critical dependencies, staffing, costs, and reviews are allocated in the schedule consistent with the project's defined software process.
   • The software schedule identifies specific tasks and milestones whose completion can be objectively determined (i.e., a binary or yes/no determination).

   ---

   Different levels of schedule detail, appropriately tied to each other, are developed to accommodate the needs of different groups and individuals.

   ---

2. Critical dependencies are defined, negotiated, and reflected in the software schedule.

   ---

   Critical dependencies include both those within the software engineering group (i.e., between subgroups) and between the software engineering group and other affected groups.

   ---

3. Schedule critical paths are defined and reflected in the software schedule.
4. The software project's critical dependencies and schedule critical paths are tracked on a regular basis.
5. Specific documented threshold criteria are established for each critical path which, when projected to be exceeded, require action.

   ---

   Examples of actions include:
   • conducting analyses and simulations to tradeoff function, quality, cost, schedule, staffing, and other resources;
   • allocating contingencies and schedule slack, if available;
   • evaluating the effects of contemplated actions on all critical paths; and
   • making decisions visible to the affected groups.

   ---

Activity 10 -- The project's software risks are identified, assessed, documented, and managed according to a documented procedure.

• schedule,
• cost,
• functionality,
• throughput or real-time performance,
• reliability or availability, and
• use of critical computer resources.

• early identification of high-risk project objectives;
• identification of events that could introduce or increase risks;
• prototyping or early implementation of high-risk modules; and
• close monitoring of key project risk indicators.

1. A software risk management plan is documented and used to identify and manage the software risks.

   ---

   Examples of items in a software risk management plan include:
   • resources required (including staff and tools);
   • risk management methods (e.g., identification, analysis, prioritization, planning, monitoring, and resolution);
   • list of identified risks (including assessment, prioritization, status, and plans);
   • risk management schedule;
   • responsibilities and authorities;
   • method and frequency of communicating risk status and activities; and
   • measurements.

   ---

2. Contingency planning is based on the project's defined software process and is performed throughout the project's software life cycle.

   ---

   Examples of areas covered by contingency planning activities include:
   • identification of options,
   • impact assessment of options,
   • technical feasibility of options,
   • allocation of management reserves, and
   • decision criteria on when to pursue an option.

   ---

3. Alternatives for each software risk are defined, where possible, along with criteria for selecting among the alternatives.
4. The initial release and major revisions to the software risk management plan undergo peer review.

   ---

   Refer to the Peer Reviews key process area.

   ---

5. The software risk management plan is managed and controlled.
6. Software risks are tracked, reassessed, and replanned at selected project milestones, at designated risk checkpoints, and during the planning of significant changes that affect the software project.
   • Risk priorities and software risk management plans are reviewed and revised at these reassessment points.
   • Information obtained from monitoring the risks is used to refine the risk assessments and software risk management plans.
7. The software engineering group and other affected groups and individuals are included in the communications on the software risks, the software risk management plans, and the results of risk mitigation.

   ---

   Examples of affected groups and individuals include:
   • customer,
   • subcontractors,
   • end users,
   • software estimating,
   • system engineering,
   • system test,
   • software quality assurance,
   • software configuration management,
   • contract management, and
   • documentation support.

   ---

Activity 11 -- Reviews of the software project are periodically performed to determine the actions needed to bring the software project's performance and results in line with the current and projected needs of the business, customer, and end users, as appropriate.

• accelerating the schedule,
• changing the system requirements in response to a change in market opportunities or customer and end user needs, and
• terminating the project.

Measurement and analysis

Measurement 1 -- Measurements are made and used to determine the effectiveness of the integrated software management activities.

• effort expended over time to manage the software project, compared to the plan;
• frequency, causes, and magnitude of replanning effort;
• for each identified software risk, the realized adverse impact compared to the estimated loss; and
• the number and magnitude of unanticipated major adverse impacts to the software project, tracked over time.

Verifying implementation

Verification 1 -- The activities for managing the software project are reviewed with senior management on a periodic basis.

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

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

1. The process for developing and revising the project's defined software process.
2. The process for preparing the project's software development plan and software risk management plan.
3. The processes for managing the project in accordance with the project's defined software process.
4. The processes for collecting and providing appropriate data to the organization's software process database.
5. The process for using the organization's software process database to support the software project's planning, estimating, and tracking activities

Table of contents Back one chapter Forward one chapter

  antoine@apple2.com 29-04-2000