Software Project Planning

a key process area for level 2: Repeatable


The purpose of Software Project Planning is to establish reasonable plans for performing the software engineering and for managing the software project.

Software Project Planning involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work.

The software planning begins with a statement of the work to be performed and other constraints and goals that define and bound the software project (those established by the practices of the Requirements Management key process area). The software planning process includes steps to estimate the size of the software work products and the resources needed, produce a schedule, identify and assess software risks, and negotiate commitments. Iterating through these steps may be necessary to establish the plan for the software project (i.e., the software development plan).

This plan provides the basis for performing and managing the software project's activities and addresses the commitments to the software project's customer according to the resources, constraints, and capabilities of the software project.

Goals

Goal 1

Software estimates are documented for use in planning and tracking the software project.

Goal 2

Software project activities and commitments are planned and documented.

Goal 3

Affected groups and individuals agree to their commitments related to the software project.

Commitment to perform

Commitment 1 -- A project software manager is designated to be responsible for negotiating commitments and developing the project's software development plan.

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

This policy typically specifies that:
  1. The system requirements allocated to software are used as the basis for planning the software project.
    Refer to Activity 2 of the Requirements Management key process area.


  2. The software project's commitments are negotiated between:
  3. Involvement of other engineering groups in the software activities is negotiated with these groups and is documented.
    Examples of other engineering groups include:
  4. Affected groups review the software project's:
    Examples of affected groups include:
  5. Senior management reviews all software project commitments made to individuals and groups external to the organization.
  6. The project's software development plan is managed and controlled.
    The term "software development plan" is used throughout these practices to refer to the overall plan for managing the software project. The use of "development" terminology is not intended to exclude software maintenance or support projects and should be appropriately interpreted in the context of the individual project.



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


Ability to perform

Ability 1 -- A documented and approved statement of work exists for the software project.

  1. The statement of work covers:
  2. The statement of work is reviewed by:
  3. The statement of work is managed and controlled.

Ability 2 -- Responsibilities for developing the software development plan are assigned.

  1. The project software manager, directly or by delegation, coordinates the project's software planning.
  2. Responsibilities for the software work products and activities are partitioned and assigned to software managers in a traceable, accountable manner.
    Examples of software work products include:

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

  1. Where feasible, experienced individuals, who have expertise in the application domain of the software project being planned, are available to develop the software development plan.
  2. Tools to support the software project planning activities are made available.
    Examples of support tools include:

Ability 4 -- The software managers, software engineers, and other individuals involved in the software project planning are trained in the software estimating and planning procedures applicable to their areas of responsibility.

Activities performed

Activity 1 -- The software engineering group participates on the project proposal team.

  1. The software engineering group is involved in:
  2. The software engineering group reviews the project's proposed commitments.
    Examples of project commitments include:

Activity 2 -- Software project planning is initiated in the early stages of, and in parallel with, the overall project planning.

Activity 3 -- The software engineering group participates with other affected groups in the overall project planning throughout the project's life.

  1. The software engineering group reviews the project-level plans.

Activity 4 -- Software project commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure.

Activity 5 -- A software life cycle with predefined stages of manageable size is identified or defined.


Examples of software life cycles include:

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

This procedure typically specifies that:
  1. The software development plan is based on and conforms to:
  2. Plans for software-related groups and other engineering groups involved in the activities of the software engineering group are negotiated with those groups, the support efforts are budgeted, and the agreements are documented.
    Examples of software-related groups include:


    Examples of other engineering groups include:
  3. Plans for involvement of the software engineering group in the activities of other software-related groups and other engineering groups are negotiated with those groups, the support efforts are budgeted, and the agreements are documented.
  4. The software development plan is reviewed by:
  5. The software development plan is managed and controlled.

Activity 7 -- The plan for the software project is documented.


In the key practices, this plan or collection of plans is referred to as the software development plan.



Refer to Activity 1 of the Software Project Tracking and Oversight key process area for practices concerning the project's use of the software development plan.


The software development plan covers:
  1. The software project's purpose, scope, goals, and objectives.
  2. Selection of a software life cycle.
  3. Identification of the selected procedures, methods, and standards for developing and/or maintaining the software.
    Examples of software standards and procedures include:
  4. Identification of software work products to be developed.
  5. Size estimates of the software work products and any changes to the software work products.
  6. Estimates of the software project's effort and costs.
  7. Estimated use of critical computer resources.
  8. The software project's schedules, including identification of milestones and reviews.
  9. Identification and assessment of the project's software risks.
  10. Plans for the project's software engineering facilities and support tools.

Activity 8 -- Software work products that are needed to establish and maintain control of the software project are identified.


Refer to Activity 4 of the Software Configuration Management key process area.


Activity 9 -- Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure.

This procedure typically specifies that:
  1. Size estimates are made for all major software work products and activities.
    Examples of software size measurements include:


    Examples of types of work products and activities for which size estimates are made include:
  2. Software work products are decomposed to the granularity needed to meet the estimating objectives.
  3. Historical data are used where available.
  4. Size estimating assumptions are documented.
  5. Size estimates are documented, reviewed, and agreed to.
    Examples of groups and individuals who review and agree to size estimates include:

Activity 10 -- Estimates for the software project's effort and costs are derived according to a documented procedure.

This procedure typically specifies that:
  1. Estimates for the software project's effort and costs are related to the size estimates of the software work products (or the size of the changes).
  2. Productivity data (historical and/or current) are used for the estimates when available; sources and rationale for these data are documented.
    Examples of significant costs that go into making the software work products include:
  3. Effort, staffing, and cost estimates are based on past experience.
  4. Estimates and the assumptions made in deriving the estimates are documented, reviewed, and agreed to.

Activity 11 -- Estimates for the project's critical computer resources are derived according to a documented procedure.


Critical computer resources may be in the host environment, in the integration and testing environment, in the target environment, or in any combination of these.


This procedure typically specifies that:
  1. Critical computer resources for the project are identified.
    Examples of critical computer resources include:
  2. Estimates for the critical computer resources are related to the estimates of:
  3. Estimates of the critical computer resources are documented, reviewed, and agreed to.

Activity 12 -- The project's software schedule is derived according to a documented procedure.

This procedure typically specifies that:
  1. The software schedule is related to:
  2. The software schedule is based on past experience.
  3. The software schedule accommodates the imposed milestone dates, critical dependency dates, and other constraints.
  4. The software schedule activities are of appropriate duration and the milestones are of appropriate time separation to support accuracy in progress measurement.
  5. Assumptions made in deriving the schedule are documented.
  6. The software schedule is documented, reviewed, and agreed to.

Activity 13 -- The software risks associated with the cost, resource, schedule, and technical aspects of the project are identified, assessed, and documented.

  1. The risks are analyzed and prioritized based on their potential impact to the project.
  2. Contingencies for the risks are identified.
    Examples of contingencies include:

Activity 14 -- Plans for the project's software engineering facilities and support tools are prepared.

  1. Estimates of capacity requirements for these facilities and support tools are based on the size estimates of the software work products and other characteristics.
    Examples of software development facilities and support tools include:
  2. Responsibilities are assigned and commitments are negotiated to procure or develop these facilities and support tools.
  3. The plans are reviewed by all affected groups.

Activity 15 -- Software planning data are recorded.

  1. Information recorded includes the estimates and the associated information needed to reconstruct the estimates and assess their reasonableness.
  2. The software planning data are managed and controlled.

Measurement and analysis

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


Examples of measurements include:

Verifying implementation

Verification 1 -- The activities for software project planning 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 is 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 report from each meeting is prepared and distributed to the affected groups and individuals.

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

  1. Affected groups are represented.
  2. Status and current results of the software project planning activities are reviewed against the software project's statement of work and allocated requirements.
  3. Dependencies between groups are addressed.
  4. Conflicts and issues not resolvable at lower levels are addressed.
  5. Software project risks are reviewed.
  6. Action items are assigned, reviewed, and tracked to closure.
  7. A summary report from each meeting is prepared and distributed to the affected groups and individuals.

Verification 3 -- The software quality assurance group reviews and/or audits the activities and work products for software project planning 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 software estimating and planning.
  2. The activities for reviewing and making project commitments.
  3. The activities for preparing the software development plan.
  4. The standards used for preparing the software development plan.
  5. The content of the software development plan.

[^^]Table of contents [->]Back one chapter [->]Forward one chapter