Integrated Software Management
a key process area for level 3: Defined
The purpose of Integrated Software Management is to integrate the software
engineering and management activities into a coherent, defined software process
that is tailored from the organization's
fd1
standard software process and related
process assets, which are described in Organization Process Definition.
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
The project's defined software process is a tailored version of the
organization's standard software process.
Goal 2
The project is planned and managed according to the project's defined
software process.
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.
Refer to the Organization Process Definition key process area for practices
covering the organization's standard software process and related process
assets.
This policy typically specifies that:
- Each project documents the project's defined software process by tailoring
the organization's standard software process.
- The project's deviations from the organization's standard software process
are documented and approved.
- Each project performs its software activities in accordance with the
project's defined software process.
- Each project collects and stores appropriate project measurement data in
the organization's software process database.
Refer to Activity 5 of the Organization Process Definition key process area for
practices covering 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.
Refer to Ability 3 of the Software Project Planning key process area and
Ability 3 of the Software Project Tracking and Oversight key process area for
practices covering resources and funding for software project planning,
tracking, and oversight.
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.
Examples of training include:
- 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.
Refer to the Training Program key process areas.
Abil
192
ity 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.
Refer to Ability 4 of the Software Project Planning key process area and
Ability 4 of the Software Project Tracking and Oversight key process area for
practices covering training for soft
fe5
ware project planning, tracking, and
oversight.
Examples of training include:
- 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.
Refer to the Training Program key process area.
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.
Refer to Activity 2 of Organization Process Definition key process area for
practices covering the contents of the organization's standard software
process.
This procedure typically specifies that:
- 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.
- 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.
- 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.
- 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.
- 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.
This procedure typically specifies that:
- 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.
- 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 so
19c
ftware 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 docu
fde
mented procedure.
Refer to Activities 6 and 7 of the Software Project Planning key process area
and Activities 1 and 2 of the Software Project Tracking and Oversight key
process area for practices covering the software development plan.
Activity 4 -- The software project is managed in accordance with the
project's defined software process.
Refer to the Software Project Planning and the Software Project Tracking and
Oversight key process areas for basic practices covering managing a software
project.
The project's defined software process typically specifies that:
- Provisions are made for gathering, analyzing, and reporting measurement
data needed to manage the software project.
- The activities for software estimating, planning, and tracking are tied to
the key tasks and work products of the project's defined software process.
- Readiness and completion criteria are established, documented, and used to
authorize initiation and determine completion of key tasks.
- Documented criteria are defined to indicate when to replan the software
project.
- 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.
- 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.
- The staffing plan addresses the software project's needs for individuals
with special skills and application domain knowledge.
- 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.
- 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.
Refer to Activity 5 of the Organization Process Definition key process area for
practices covering the organization's software process database.
- 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.
- 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.
- 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,
- th
199
e 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.
fd7
Refer to Activity 9 of the Software Project Planning key process area and
Activity 5 of the Software Project Tracking and Oversight key process area for
basic practices covering planning and tracking size of software work
products.
This procedure typically specifies that:
- 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.
- 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.
- 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.
- Factors which could significantly affect the size of the software work
products are identified and monitored closely.
- 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.
Refer to Activity 10 of the Software Project Planning key process area and
Activity 6 of the Software Project Tracking and Oversight key process area for
basic practices covering planning and tracking software efforts and costs.
This procedure typically specifies that:
- Software effort, cost, and staffing profile models, if used, are adapted
to the project and use available historical data where appropriate.
- 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.
- The overall software effort and cost is allocated to individually managed
tasks or stages as needed to manage the effort and cost effectively.
- 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.
- 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
196
procedure.
Refer to Activity 11 of the Software Project Planning key process area and
Activity 7 of the Software Project Tracking and Oversight key process area for
basic practices covering planning and tracking critical computer resources.
This procedure typically specifies that:
- Estimates for the project's critical computer resources are derived based
on histo
fdd
rical 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.
- 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.
- The available computer resources are allocated to the software
components.
- The available capacity for the critical computer resources provides
for a specified reserve capacity when the initial estimates are made.
- 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.
Refer to Activity 12 of the Software Project Planning key process area,
Activity 8 of the Software Project Tracking and Oversight key process area, and
Activity 4 of the Intergroup Coordination key process area for practices
covering negotiating and tracking critical dependencies.
This procedure typically specifies that:
- 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.
- 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.
- Schedule critical paths are defined and reflected in the software schedule.
- The software project's critical dependencies and schedule critical paths
are tracked on a regular basis.
- 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.
Refer to Activity 13 of the Software Project Planning key process area and
Activity 10 of the Software Project Tracking and Oversight key process area for
basic practices covering identifying and tracking risk.
Examples of software risks that are to be managed include significant
possibilities that the software project could fail to meet its objectives in
areas such as:
- schedule,
- cost,
- functionality,
- throughput or real-time performance,
- reliability or availability, and
- use of critical computer resources.
Examples of activities to manage risks include:
- early identification of high-risk project objectives;
- identification of events that could introduce or increase risks;
- prototyping or early implementation of high-risk modules
199
; and
- close monitoring of key project risk indicators.
This procedure typically specifies that:
- 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., identific
fef
ation, 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.
- 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.
- Alternatives for each software risk are defined, where possible, along
with criteria for selecting among the alternatives.
- The initial release and major revisions to the software risk management
plan undergo peer review.
Refer to the Peer Reviews key process area.
- The software risk management plan is managed and controlled.
- 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.
- 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.
Examples of actions include:
- 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.
The end users referred to in these practices are the customer-designated end
users or representatives of the end users.
Measurement and analysis
Measurement 1 -- Measurements are made and used to determine the
effectiveness of the integrated software management activities.
Examples of measurements include:
- 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.
Refer to Verification 1 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of senior management
oversight reviews.
Verification 2 -- The activities for managing the software project are
reviewed with the project manager on both a periodic and event-driven basis.
Refer to Verification 2 o
195
f the Software Project Tracking and Oversight key
process area for practices covering the typical content of project management
oversight reviews.
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.
Refer to the Software Quality Assurance key process ar
fb3
ea.
At a minimum, the reviews and/or audits verify:
- The process for developing and revising the project's defined software
process.
- The process for preparing the project's software development plan and software
risk management plan.
- The processes for managing the project in accordance with the project's
defined software process.
- The processes for collecting and providing appropriate data to the organization's
software process database.
- The process for using the organization's software process database to support
the software project's planning, estimating, and tracking activities