Level 2 - Software Project Planning

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:
    • the project manager,
    • the project software manager, and
    • the other software managers.
  3. Involvement of other engineering groups in the software activities is negotiated with these groups and is documented.
    Examples of other engineering groups include:
    • system engineering,
    • hardware engineering, and
    • system test.

  4. Affected groups review the software project's:
    • software size estimates,
    • effort and cost estimates,
    • schedules, and
    • other commitments.

    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 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:
    • scope of the work,
    • technical goals and objectives,
    • identification of customers and end users,
      The end users referred to in these practices are the customer designated end users or representatives of the end users.


    • imposed standards,
    • assigned responsibilities,
    • cost and schedule constraints and goals,
    • dependencies between the software project and other organizations,
      Examples of other organizations include:
      • the customer,
      • subcontractors, and
      • joint venture partners.

    • resource constraints and goals, and
    • other constraints and goals for development and/or maintenance.
  2. The statement of work is reviewed by:
    • the project manager,
    • the project software manager,
    • the other software managers, and
    • other affected groups.
  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:
    • work products for delivery to the external customer or end users, as appropriate;
    • work products for use by other engineering groups; and
    • major work products for internal use by the software engineering group.

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:
    • spreadsheet programs,
    • estimating models, and
    • project planning and scheduling programs.

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:
    • proposal preparation and submission,
    • clarification discussions and submissions, and
    • negotiations of changes to commitments that affect the software project.
  2. The software engineering group reviews the project's proposed commitments.
    Examples of project commitments include:
    • the project's technical goals and objectives;
    • the system and software technical solution;
    • the software budget, schedule, and resources; and
    • the software standards and procedures.

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:
  • waterfall,
  • overlapping waterfall,
  • spiral,
  • serial build, and
  • single prototype/overlapping waterfall.

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:
    • the customer's standards, as appropriate;
    • the project's standards;
    • the approved statement of work; and
    • the allocated requirements.
  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:
    • software quality assurance,
    • software configuration management, and
    • documentation support.


    Examples of other engineering groups include:
    • system engineering,
    • hardware engineering, and
    • system test.

  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:
    • the project manager,
    • the project software manager,
    • the other software managers, and
    • other affected groups.
  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:
    • software development planning,
    • software configuration management,
    • software quality assurance,
    • software design,
    • problem tracking and resolution, and
    • software measurement.

  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:
    • function points,
    • feature points,
    • lines of code,
    • number of requirements, and
    • number of pages.


    Examples of types of work products and activities for which size estimates are made include:
    • operational software and support software,
    • deliverable and nondeliverable work products,
    • software and nonsoftware work products (e.g., documents), and
    • activities for developing, verifying, and validating work products.

  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:
    • the project manager,
    • the project software manager, and
    • the other software managers.

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.
    • The productivity and cost data are from the organization's projects when possible.
    • The productivity and cost data take into account the effort and significant costs that go into making the software work products.

    Examples of significant costs that go into making the software work products include:
    • direct labor expenses,
    • overhead expenses,
    • travel expenses, and
    • computer use costs.

  3. Effort, staffing, and cost estimates are based on past experience.
    • Similar projects should be used when possible.
    • Time phasing of activities is derived.
    • Distributions of the effort, staffing, and cost estimates over the software life cycle are prepared.
  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:
    • computer memory capacity,
    • computer processor use, and
    • communications channel capacity.

  2. Estimates for the critical computer resources are related to the estimates of:
    • the size of the software work products,
    • the operational processing load, and
    • the communications traffic.
  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:
    • the size estimate of the software work products (or the size of changes), and
    • the software effort and costs.
  2. The software schedule is based on past experience.
    • Similar projects are used when possible.
  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:
    • schedule buffers,
    • alternate staffing plans, and
    • alternate plans for additional computing equipment.

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:
    • host computers and peripherals for software development,
    • software test computers and peripherals,
    • target computer environment software, and
    • other support software.

  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:
  • completions of milestones for the software project planning activities compared to the plan; and
  • work completed, effort expended, and funds expended in the software project planning activities compared to the plan.

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

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