|
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 p feb erformed, 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:
- 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.
- The software project's commitments are negotiated between:
- the project manager,
- the project software manager, and
- the other software managers.
- 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.
- 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.
- Senior management reviews all software project commitments made to
individuals and groups external to the organization.
- 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.
- 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 pro e66 ject 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.
- The statement of work is reviewed by:
- the project manager,
- the project software manager,
- the other software managers, and
- other affected groups.
- The statement of work is managed and controlled.
Ability 2 -- Responsibilities for developing the software development
plan are assigned.
- The project software manager, directly or by delegation, coordinates
the project's software planning.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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/o 19b verlapping waterfall.
Activity 6 -- The project's software development plan is developed according
to a documented procedure.
This procedure typically specifies that:
- 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 all ffa ocated requirements.
- 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.
- 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.
- The software development plan is reviewed by:
- the project manager,
- the project software manager,
- the other software managers, and
- other affected groups.
- 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:
- The software project's purpose, scope, goals, and objectives.
- Selection of a software life cycle.
- 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.
- Identification of software work products to be developed.
- Size estimates of the software work products and any changes to the
software work products.
- Estimates of the software project's effort and costs.
- Estimated use of critical computer resources.
- The software project's schedules, including identification of milestones
and reviews.
- Identification and assessment of the project's software risks.
- 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:
- 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.
- Software work products are decomposed to the granularity needed to
meet the estimating objectives.
- Historical data are used where available.
- Size estimating assumptions are documented.
- Size estimates are documented, reviewed, and agreed to.
Examples of groups and individuals who review and agree to s 19b ize
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:
- Estimates for the software project's effort and costs are related
to ff6 the size estimates of the software work products (or the size
of the changes).
- 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.
- 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.
- 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:
- Critical computer resources for the project are identified.
Examples of critical computer resources include:
- computer memory capacity,
- computer processor use, and
- communications channel capacity.
- 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.
- 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:
- 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.
- The software schedule is based on past experience.
- Similar projects are used when possible.
- The software schedule accommodates the imposed milestone dates, critical
dependency dates, and other constraints.
- The software schedule activities are of appropriate duration and
the milestones are of appropriate time separation to support accuracy
in progress measurement.
- Assumptions made in deriving the schedule are documented.
- 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.
- The risks are analyzed and prioritized based on their potential impact
to the project.
- 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.
- 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.
- Responsibilitie 197 s are assigned and commitments are negotiated
to procure or develop these facilities and support tools.
- The plans are reviewed by all affected groups.
Activity 15 -- Software planning data are recorded.
- Information recorded includes the estimates and the associated information
needed to reconstruct the estimates and assess their reasonableness.
- The software fe9 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.
- The technical, cost, staffing, and schedule performance is reviewed.
- Conflicts and issues not resolvable at lower levels are addressed.
- Software project risks are addressed.
- Action items are assigned, reviewed, and tracked to closure.
- 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.
- Affected groups are represented.
- Status and current results of the software project planning activities
are reviewed against the software project's statement of work and allocated
requirements.
- Dependencies between groups are addressed.
- Conflicts and issues not resolvable at lower levels are addressed.
- Software project risks are reviewed.
- Action items are assigned, reviewed, and tracked to closure.
- 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:
- The activities for software estimating and planning.
- The activities for reviewing and making project commitments.
- The activities for preparing the software development plan.
- The standards used for preparing the software development plan.
- The content of the software development plan.
|
|