1.1
Purpose
The purpose of this document is to describe the processes,
procedures, and guidelines that should be followed by a software project
manager in order to plan and execute a productive and successful project. It is
assumed that the reader is familiar with the SSC San Diego organizational
policy for Software Project Planning (SPP).
Software project planning is a Level 2 Capability Maturity
Model (CMM) Key Process Area (KPA). Satisfying this KPA is a major step toward
achieving Level 2 (Repeatable). This KPA
requires a written process for planning a software project. It also requires the development of a
project Software Development Plan (SDP),
which is the document which describes the plan for the software project. The planning phase is one of the most crucial
steps in any software development project.
The success of a software project is often determined in the planning
phase. Lack of adequate planning often
results in a project’s failure to meet either cost, schedule, or performance
objectives or all three. The quality of your project plan will probably reflect
the quality of your project. Be
thorough, concise and precise. It is never too early to plan.
This process applies to any software project at SSC San
Diego and also to any activity of the software development life cycle. Though this process is written from the
viewpoint of a project in the requirements activity, it can be easily modified
for use by projects in any activity of the software life cycle. Even software projects that are in life cycle
maintenance can implement this process for planning software builds or for
implementing Engineering Change Proposals (ECPs).
This document addresses
steps and guidelines for performing software development planning on a software
project. Section 1 provides background
and process overview information.
Section 2 provides detailed information on each step of the
process. Section 3 provides information
on software project planning aides. The
following provides the format and the format definitions used to describe each
of the process steps in Section 2 of the SPP Process.
PURPOSE: The objective of the
process activity. If a subprocess
activity exists, the details are described in that specific paragraph
description.
ROLE AND RESPONSIBILITY: The
responsibilities of individuals or groups for accomplishing a process activity.
ENTRY CRITERIA: The elements and
conditions necessary to be in place to begin a process activity. Reading lower level activities assumes that
the entry criteria for all higher level activities have been satisfied.
INPUT: Data or material with which
a process activity is performed.
PROCESS ACTIVITY: Actions to
transform an input, as influenced by controls, into a predetermined output.
OUTPUT: Data or material produced
by or resulting from a process activity.
It must include the input data in some form. The output title differs from the input title
in order to indicate that an activity has been performed.
EXIT CRITERIA: Elements and/or
conditions necessary to be in place to complete a process activity.
PROCESS METRICS: Data collected
which can be analyzed and used to improve the process.
The SSC San Diego Software Project Planning (SPP) process
begins with the planning initiation step. In this step a software project
manager is selected and resources and budget are allocated to the planning and
replanning activities. The Requirements Management (RM) Guidebook is an
interfacing process to the SPP process.
Requirements are the major driving force in SPP and therefore are a
major interface to this process. Without
requirements, you would not know what to plan or what to estimate. Initial software
estimates and software activities are also developed in this step. The SSC San Diego Software Size, Cost, and
Schedule Estimation process is an interfacing process.
The next step in the process is to develop the Software
Development Plan (SDP). The MIL-STD-498
Data Item Description (DID) for the SDP, DI-IPSC-81427, should be used as a format for the SDP. The SSC San Diego SDP template, which is
based on the MIL-STD-498 DID, can be used as a guide for developing the project
specific SDP. The SDP should include
items such as software estimates, schedules, milestones, Work Breakdown
Structure (WBS), software development environment, software development
methodology, software test methodology, and software risks. The SDP is used to establish commitments on
the project. Software estimates are
refined using the SSC San Diego Software Size, Cost, and Schedule Estimation
process.
After the SDP has
been developed it should undergo formal review and approval. The SSC San Diego Formal Inspection process
is one type of review methodology that can be used. Review of the SDP should include all groups
internal and external to the organization which will be affected by the work in
the SDP. Affected groups, both internal
and external to the organization, should also approve the SDP by signing the
signature page of the SDP indicating their commitment and acceptance of the
SDP.
After the SDP has been approved it should be placed under
configuration management. The SSC San
Diego Software Configuration Management (SCM) process can be used as a guide to
develop the project’s SCM process.
The project is now ready to implement the activities as
described in the SDP. In implementing
the SDP, follow the project’s tailored version of the SSC San Diego Software
Project Tracking and Oversight (SPTO) process to provide information about the
software project which can precipitate changes to the SDP. These changes should be implemented in
accordance with the project’s SCM
process. The project should also
implement the project’s tailored SQA process in order to monitor the project’s
software development activities. In
addition, the SQA group should be monitoring the activities of the SPP process.
Metrics are collected
on each process step and are then used to develop process improvements in the
SPP process. These measurements are
analyzed against both planned and historical data, if available.
Proposed changes to the SDP are analyzed and approved
changes are implemented. After changes
are made, the SDP should follow the project’s standard review and approval
process.
a) Requirements
Management Guidebook
b) SSC
San Diego Size, Cost, and Schedule Estimation Process
c) SSC
San Diego Software Configuration Management Process
d) SSC
San Diego Formal Inspection Process
e) SSC
San Diego Software Project Tracking and Oversight Process
f) SSC
San Diego Software Quality Assurance Process
g) SSC
San Diego SDP Template
h) SSC
San Diego Reuse Adaptation and Management (RAM) Process
i)
SSC San Diego Risk Management Process
j)
SSC San Diego Software Management for Executives
Guidebook
k) SSC
San Diego Contractor Acquisition and Performance Monitoring (CAPM) Process
l)
MIL-STD-498
Software Development and Documentation, 5 December 1994
m) Capability
Maturity Model for Software V1.1
n) NAWCAD
Procedure for Preparing a Software Development Plan
CAPM Contractor Acquisition and Performance Monitoring
CM Configuration
Management
CMM Capability
Maturity Model
DCR Document Change
Request
DID Data Item
Description
ECP Engineering
Change Proposal
KPA Key Process
Area
PR/CR Problem
Report/Change Request
RM Requirements
Management
SCM Software
Configuration Management
SDP Software
Development Plan
SEPO Software
Engineering Process Office
SOW Statement of
Work
SSC San Diego Space and Naval Warfare Systems Center, San
Diego
SPM Software
Project Manager
SPE Software
Product Engineering
SPP Software
Project Planning
SPTO Software
Project Tracking and Oversight
SQA Software
Quality Assurance
SQAP Software Quality
Assurance Plan
SSM Software
Subcontractor Management
WBS Work Breakdown
Structure
Project Manager - person responsible for planning and
execution of the project, both hardware and software.
Software Project Manager (SPM) - person responsible
for the planning and execution of the software portion of a project.
Sponsor/Customer - the acquirer of the system being
developed. The source of the funding for
the
project.