Introduction

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.

Post a Comment

Previous Post Next Post