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.