Project Planning Process Definition

1.     Project planning process definition

This section describes each of the process steps as depicted in Figure 2-1.

Figure 2-1.  Project Planning Process

1.1     Planning Initiation

1.1.1     PURPOSE

The purpose of this process step is ensure that the necessary requirements have been met in order to properly carry out the planning activities.

1.1.2     ROLE AND RESPONSIBILITY

The project manager is responsible for carrying out this process step.

1.1.3     ENTRY CRITERIA

a.   A Software Project Manager is designated to be responsible for developing software size, cost, schedule, and resource estimates; preparing project planning documents; and negotiating commitments.

b.  Those responsible for preparing the project planning documents are skilled or have received training in software project planning and software estimating.

c.  The Statement of Work (SOW)  or tasking statement has been documented.  The SOW or task statement should include the scope of the work, technical goals and objectives, identification of customers and end users, imposed standards, assigned responsibilities, cost and schedule constraints and goals, dependencies between the software project and other organizations, resource constraints and goals, and other constraints and goals for development and/or maintenance.

                  d.   Initial allocated requirements have been documented.

e.   Adequate resources and budget for software project planning have been identified and allocated. Adequate budget generally means 1-2% of the software project budget.

f.   Customer/sponsor required documentation (e.g. Computer Resources Life Cycle Management Plan, Software Support Requirements Analysis, Transition Plan, Acquisition Plan, etc.) is available and complete.

g. SSC San Diego Software Project Planning Policy has been reviewed.

1.1.4     INPUT

Planning budget and trained personnel.

SSC San Diego Software Project Planning Policy.

Project’s documented software requirements.

Documented SOW or tasking statement.

1.1.5     PROCESS ACTIVITY

There are two major activities to initiating software project planning: develop estimates, and plan software activities.

a.  Develop Estimates

(1) Review the “SSC San Diego Software Project Tracking and Oversight Process” document  to determine the measurement data to be collected for project tracking and oversight.

(2) Review the statement of work and the initial allocated requirements to scope the effort.

(3) Make initial estimates of software size, cost and schedule using the " SSC San Diego Software Size, Cost, and Schedule Estimation Process” document.

(4) Estimate the project's critical computer resources.  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.

(5) Estimate the space requirements for the project's software engineering facilities and make a preliminary identification of  the hardware, support tools and associated costs (e.g., license fees, maintenance cost) required for the target environment, the host environment and the integration and test environment.

b.  Plan Software Activities

(1)  Perform an initial assessment of the following:

      (a)  Software objectives, allocated requirements and interface requirements.  The “Requirements Management Guidebook” available for downloading from the SEPO Home page will assist in this step.

      (b)  Customer delivery schedule requirements.

      (c)  Customer budget limitations.

      (d)  System technical constraints.

      (e)   Staffing constraints (in-house and contractors).

      (f)   Contracting needs.

      (g)   Resource constraints.

      (h)   Software development environment.

      (i)    Software processes to be used.

      (j)    Design, programming, software engineering and test requirements and  standards.

      (k)   Configuration management requirements.

      (l)    Quality assurance requirements.

      (m)  Non-deliverable software and hardware requirements.

      (n)   Risks and risk reduction strategies for the project.

      (o)   Documentation requirements.

1.1.6     OUTPUT 

 Initial planning data including a Project budget and/or WBS that includes a line item for the SPP task and the project organization chart identifies the project’s Software Project Manager (SPM).

1.1.7     EXIT CRITERIA

A Project Software Manager for the project has been identified.  Adequate resources, funding have been allocated to perform the planning task, and an initial understanding of the scope of the effort has been accomplished.

1.1.8     PROCESS METRICS

Effort expended in planning work efforts.

1.2     Develop SDP

1.2.1     PURPOSE

The purpose of this process step is to develop the Software Development Plan (SDP) for the project. The SDP  is the document that allows the customer  insight into all stages of the software development process and addresses the commitments  of the software developer to the allocated requirements.  It identifies resources, estimates of size and cost, schedules, constraints, capabilities of the software developer's organization and identifies the products to be delivered.  The plan identifies a basis for managing, for tracking the software activities, and a means for communicating status of the software development tasks.  The plan documents each group's responsibility for the development of the software.  The organization’s standard software processes are a major input to the SDP. 

1.2.2     ROLE AND RESPONSIBILITY

The Software Project Manager (SPM), or whomever the SPM designates to develop the SDP,  is responsible to lead  the development effort for the SDP.

1.2.3     ENTRY CRITERIA

a.  The Software Project Manager has been designated and is responsible for the creation of the SDP.

b.  The initial software size, cost, schedule and resource estimates have been developed.

c.  Adequate resources and budget for project planning have been identified and allocated.

d.  The software quality assurance and configuration management task leaders have been identified and assigned to the project planning group.

e.  The project planning group has reviewed the initial planning data.

1.2.4     INPUT

 Initial planning data.

The organization’s standard software processes (e.g. SCM process, SQA Process, etc.)

1.2.5     PROCESS ACTIVITY

a.  The planning group has downloaded the SDP Template from the SEPO Home page and familiarized themselves with the guidance information and samples contained in the template.  Tailoring the SDP template will require that the planning group address the following items:

(1) Scope/Objective/Goals - Define the project's purpose, the customer, the scope of the project to bound the project, the project's goals and objectives, the product delivery date and criteria for determining the project's success.

(2) Requirements - Identify the data base of requirements allocated to software, the functional requirements which the allocated requirements support and a high level summary of the entire project.

(3) Project Organization - Identify the project's organizational structure and define the relationship among the organizational elements.  Identify for each organizational element its authority and responsibility for each major task area.

(4) Task Definition - Refine the major tasks to develop the software (e.g., software design, software test, independent verification and validation).  This can be accomplished using a work breakdown structure format.

(5) Schedule - Refine the project's overall schedule and schedules associated with each task including significant events (reviews, audits, key meetings) related to the task and interdependencies with other tasks.

(6) Cost - Refine the cost for the software product, contracting efforts, quality assurance efforts, configuration management efforts, training expense, software development environment, software test environment, software licenses and travel expenses.  The cost should be expressed as a total cost throughout the life of the project and as yearly cost for multi-year projects.  Refer to the " SSC San Diego Software Size, Cost and Schedule Estimation Process" document for procedures to develop the cost.

(7) Resource Requirements – Refine any human resources, software resources and hardware resources and any limiting factors associated with each resource (e.g., dates available, skill type, sequences of events and dependencies).

(a) Human Resources - Identify the human resources by skill type (management,  software engineering, testing, configuration management, quality assurance) assigned to each task in the project's schedule.  Indicate the chronological time and duration when the resources are required.

(b) Software Resources - Identify the software resources that are necessary for the project, the provider of the software (e.g., government furnished, commercial off the shelf, non-developmental item, new development), and the need dates.

(c) Hardware Resources - Identify the equipment that is necessary for the project, the provider of the equipment (e.g., government furnished, contractor furnished, commercial), procurement agreement (purchase, rental, existing) and the need dates.

(d) Critical Computer Resources - Identify any critical computer resource (i.e., memory, throughput, I/O) that will impact any task within the project. 

(8) Software Process - Identify the techniques, methodologies and tools for the development and control of the software through all its development phases (e.g., preliminary design, detailed design, implementation, integration, testing, internal/external reviews, inspections, corrective action process, problem/change reports, software product evaluation).

(9) Software Standards - Identify the standards and procedures that will be used for design and implementation of the software product(s) including language specific standards, the contents and maintenance of the software development files.

(10) Software Development Environment/Software Test Environment - Identify the software development environment and software test environment.  Address their performance requirements.  Identify any custom tailoring of the environments that are needed for the project and the schedule for the environments including dates of installation, date of availability, need date and duration.  Include any maintenance requirements for the environments.

(11) Software Licenses - Identify all software license agreements associated with the software development environment, software test environment, target environment, maintenance environment and the delivery of the product and associated software package to the customer.  Determine the approach the project will use for each licensed item and maintenance agreement for each licensed item.

(12) Documentation - Identify the documentation standard or the format to be used to develop the project documentation.  Identify specific tailoring of documents, delivery medium, delivery schedule, document review cycle, project management reports and maintenance of documentation.

(13) Risk Analysis and Risk Reduction - Identify the risks in the software project by utilizing a risk analysis method which provides risk identification, risk factors, risk assessment, risk prioritization, risk management strategies, risk resolution, risk monitoring techniques and document the contingency procedures for each area of risk on the project.  Refer to the " SSC San Diego Risk Management Process" document.

(14) Training - Identify the required training needs and associated efforts (e.g., on the job training assignments) necessary for the staff in such areas as software methodology, tools, languages, and software packages. Also, identify the training requirements for the customer to effectively use the delivered software.

 (15) Project Constraints - Identify the constraints that will impact meeting the customer's goals ( i.e., start date, completion date, specific tools, software development environment, software test environment, availability of tools or environments, resources, and dependencies on external activities relating to project commitments).

(16) Quality Assurance - Identify the organization's structure and personnel resources for performing the quality assurance activities on the software products produced for the customer and the QA activities for evaluating the software engineering or development processes.  Define the approach for evaluating the software and associated documentation, the software engineering processes, and identify the tools utilized by the SQA group.  Refer to “SSC San Diego Software Quality Assurance Process” document and associated SQA Plan template.

(17) Configuration Management - Identify the organization's structure and personnel resources for performing software configuration management for the software developed or used throughout the project.  Define the configuration control flow used for changes to software and documentation and deliveries of products.  Refer to the " SSC San Diego Software Configuration Management Process" document and associated templates for further details.

(18) Contracting Needs - Identify any technical agreement or contract that is needed by the project to meet its goal.  Define for each technical agreement or contract the end product to be procured or produced, type of agreement/contract, type of funding, funding expiration date, lead time for contract preparation, award date and cost.  Refer to the " SSC San Diego CAPM” process.

(19) Security - Identify the security levels of any facility used on the project.  Identify any classified processing or security issues associated with software items (e.g., tool), firmware and hardware.

c.  The SDP template is tailored, incorporating the findings of the planning group into a project specific draft Software Development Plan.

Note: At the early stages of a software project many sections of the SDP may include items that are “TBD” (To Be Determined).  This is quite normal and does not present a problem as long as those items are planned before their implementation.

1.2.6     OUTPUT

Draft Software Development Plan.

1.2.7     EXIT CRITERIA

 Software Development Plan has been developed using the SSC San Diego SDP template.

1.2.8     PROCESS METRICS

Effort expended planning and developing the SDP.

1.3     Review and approve the SDP

1.3.1     PURPOSE

The purpose of this process step is to identify and correct any defects or missing information  in the SDP.   The approval of the document will signify the signees commitment to the SDP.

1.3.2     ROLE AND RESPONSIBILITY

 Project manager, senior management, software project manager, program sponsor, project personnel, systems engineering, hardware engineering, system test, SCM, SQA, and other affected groups are responsible for reviewing and approving the SDP.

1.3.3     ENTRY CRITERIA

Draft SDP has been developed.

1.3.4     INPUT

Draft SDP.

1.3.5     PROCESS ACTIVITY

a.  Perform a rigorous technical review of the SDP.   One example of such a review is the SSC San Diego Formal Inspection process.   The purpose of the review is to uncover any defects or missing information in the SDP. 

b. Change requests and/or new process definitions developed during SDP production should be submitted to SEPO.

c.  Integrate and validate corrections to the SDP.

d.  Gain commitment to the SDP by following the appropriate document approval process for the organization.  This process should include the Project Manager, the Software Project Manager, the Project Sponsor, and other groups, internal and external to the organization,  who are affected by the SDP.  All software project commitments made to individuals and groups external to the organization should be reviewed by senior management.

e. The SDP is put under control using the same CM  procedures  as would be used with any other of the project’s software documents.

1.3.6     OUTPUT

a.  Reviewed and approved SDP filed in project document library.

b.   Document inspection report filed in project document library.

c.  Management and software engineering team commitment to the SDP.

d.  Baselined SDP under CM control.

1.3.7     EXIT CRITERIA

SDP has been reviewed.  Defects in the SDP have been corrected and appropriate individuals have committed to the approved the SDP.

1.3.8     PROCESS METRICS

Effort expended reviewing, making corrections to, and approving the SDP.

Number and severity of defects found.

1.4         Implement SDP and Apply Software Project Tracking and Oversight (SPTO) Processes

1.4.1     PURPOSE

The purpose of this process step is to carry-out the tasks as detailed in the SDP.

 

1.4.2     ROLE AND RESPONSIBILITY

 Any project personnel who have a defined task in the SDP is responsible for carrying-out their role.

1.4.3     ENTRY CRITERIA

SDP has been reviewed, approved, and placed under SCM control.

1.4.4     INPUT

Baselined SDP

1.4.5     PROCESS ACTIVITY

a.  The project personnel execute the tasks as described in the SDP, invoking the disciplines of the CMM SPE KPA to ensure quality product engineering. 

b.  In addition, as part of management’s planning and monitoring process, the Software Project Tracking and Oversight (SPTO) processes are applied.

c.  The disciplines of the CMM KPA for SQA are applied via the Software Quality Assurance Plan (SQAP) or the processes documented in the SDP.  SQA should be performed on both the software development activities and the SPP process itself.  Review SQA reports.

d.  The disciplines of the CMM KPA for Software Subcontractor Management (SSM) are applied for sub-contractor work.

1.4.6     OUTPUT

 Products resulting from the executed SDP. Periodic interactive technical reviews schedule.

1.4.7     EXIT CRITERIA

 SDP is being executed and the work effort monitored and managed.

1.4.8     PROCESS METRICS

As defined in the SDP and as required by organizational management policy and processes.

1.5     Process Measurement and Improvement

1.5.1     PURPOSE

 The purpose of this process step is to collect metrics on each step of the process and use that data to improve the process.

1.5.2     ROLE AND RESPONSIBILITY

 Software project manager or the person designated by the SPM to monitor and improve the SPP process.

1.5.3     ENTRY CRITERIA

 Metrics data collected from the software engineering and management process activities.

1.5.4     INPUT

 Metrics data base, change proposals (including feedback from process users), and problem reports affecting project, organization, and the SPP process.

1.5.5     PROCESS ACTIVITY

a.  Analyze process metrics, change requests, and problem reports to determine process changes.  Compare metrics data to planned and historical data.  Investigate variances that exceed the project-specified thresholds.  Investigate cause of the variance.  If the tasks in the process itself are found to be the cause of the variance, then formulate proposed process changes. 

b.  Draft process improvements for organizational standards, those specific to the project (i.e., tailored organizational standards or project unique), and to the SPP process.

e.  Gain commitment from the software engineering team (i.e., Inter-group Coordination) on the proposed process changes.

1.5.6     OUTPUT

 Team approved process improvement proposals for the organizational standards, the project process contained in the SDP, and the SPP process.  Process data and replanning data.

 

1.5.7     EXIT CRITERIA

 Process metrics have been analyzed and proposed process improvements have been drafted.

1.5.8     PROCESS METRICS

 Effort expended analyzing metrics and planning process improvements.

1.6     REVISE SDP

1.6.1     PURPOSE

The purpose of the process step is to ensure that the SDP remains current.

1.6.2     ROLE AND RESPONSIBILITY

 The Project Software Manager, or the person designated by the SPM, is responsible for updating the SDP.

1.6.3     ENTRY CRITERIA

 SDP, SCM, SQA, and SPTO process are being executed, results analyzed, and process improvement proposals drafted.

1.6.4     INPUT

 Metrics from the SPTO process; proposed process changes; and, changes in project plans as directed by the program sponsor.

1.6.5     PROCESS ACTIVITY

a.  Analyze impact of directed project changes, such as changes in project schedules, resources, etc., as negotiated with the program sponsor. 

b.  Incorporate approved changes into draft of next revision to the  SDP.

c.  Proceed to step 2.3 above.  The SCM process for updating the SDP should be the same as for any of the other project documentation.

1.6.6     OUTPUT

a.  Next revision to the SDP.

b.  Change proposals or problem reports against organizational standard processes forwarded to the appropriate group responsible for the configuration control of organizational standard processes (i.e., Software Engineering Process Group).

1.6.7     EXIT CRITERIA

 SDP has been revised based on  data from the process analysis and programmatic changes affecting the project plans.

1.6.8     PROCESS METRICS

 Effort expended updating the SDP.