<CompanyName>

Project Name
Software Development Plan (Project
Small
Version <1.0>

Note: The following template is provided for use with the Rational Unified Process (RUP). The text in
blue displayed in brackets and in italics (style=InfoBlue) was included to guide the author and should be
deleted before the publication of the document. A paragraph typed after this style will be automatically
defined as normal (style=Body Text).
To customize automatic fields in Microsoft Word (which display a gray background when
selected), choose File>Properties and replace the fields Title, Subject, and Company with the information
appropriate for this document. After closing the dialog box, to update the fields
automatically in the entire document, select Edit > Select All (or Ctrl-A) and press F9 or simply
click on the field and press F9. This should be done separately for Headers and Footers. Alt-F9
alternates between displaying field names and the contents of the fields. Refer to Word help for
get more information on how to work with fields.
Project Name Version: <1.0>
Software Development Plan (Small Project) Data: <dd/mmm/yy>
document_identifier

Revision History
Data Version Description Author
<dd/month/yyyy> <x.x> <details> <name>

Confidential <CompanyName>, 2013 Page 2 of 9

<Project Name> Version: 1.0
Software Development Plan (Small Project) <dd/mmm/yy>
<document identifier>

Analytical Index
1. Introduction 4

1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms and Abbreviations 4
1.4 References 4
1.5 Overview 4

2. Vision General of Project 4

2.1 Purpose, Scope and Objectives of Project 4

2.2 Assumptions and Restrictions 5

2.3 Products Released from Project 5

2.4 Evolution of the Software Development Plan 5

3. Organization of Project 5
3.1 Organizational Structure 5
3.2 External Interfaces 5
3.3 Roles and Responsibilities 5

4. Process of Management 6
4.1 Estimates of Project 6
4.2 Project Plan 6
4.2.1 Phase 6 Plan
4.2.2 Objectives of Iterations 6
4.2.3 Releases 6
4.2.4 Project 6 Schedule
4.2.5 Project Resources 6
4.3 Project Monitoring and Control 7

5. Annexes 9

Confidential <CompanyName>, 2013 Page 3 of 9

Project Name Version: 1.0
Software Development Plan (Small Project) <dd/mmm/yy>
<document identifier>

Software Development Plan (Project

Small

1. Introduction
The introduction of the Software Development Plan provides an overview of the entire document.
It includes the purpose, the scope, the definitions, the acronyms, the abbreviations, the references, and an overview
general of this Software Development Plan.
1.1 Purpose
The purpose of the Software Development Plan is to gather all the necessary information to
control the project. It describes the approach taken to software development and is the high-level plan.
highest generated and used by managers to coordinate the development effort.
The Software Development Plan is used by these people:
The project manager uses it to plan the project schedule and needs.
resources and to monitor the project's progress in relation to the schedule.
Team members use the project tool to understand what they need to do and when they need to do it.
to do it and what are the other activities they depend on.
1.2 Scope
This Software Development Plan describes the general plan to be used by the project <project name>
project>, including the implementation of the product. The details of individual iterations will be described in the
Iteration Plans.
The plans, as specified in this document, are based on the product requirements defined in
Vision Document.
1.3 Definitions, Acronyms, and Abbreviations
Consult the Project Glossary.
1.4 References
Vision

1.5 Overview
This Software Development Plan contains the following information:
Project Overview—presents a description of the purpose, scope, and objectives of the
project. It also defines the products that are expected to be released by the project.

Project Organization - describes the organizational structure of the project team.

Management Process - explains the estimated cost and schedule, defines the main milestones and
phases of the project and describes how the project will be monitored.

Plans and Applicable Guidelines - provide an overview of the software development process,
covering methods, tools, and techniques to be followed.
2. Project Overview
2.1 Purpose, Scope and Objectives of the Project
A brief description of the purpose and objectives of this project and a brief description of the products that
it is expected that the project will be released.

Confidential <CompanyName>, 2013 Page 4 of 9

<Project Name> Version: 1.0
Software Development Plan (Small Project) <dd/mmm/yy>
<document identifier>

2.2 Assumptions and Restrictions

A list of the assumptions on which this plan is based and any constraints such as, for example, of
budget, team, equipment and scheduling, which apply to the project.
2.3 Products Released from the Project
A list of the artifacts to be created during the project, including target release dates.
below is provided as an example.
The products released from each phase of the project are identified in the Development Case.
Released products are delivered at the end of the iteration, as specified in section 4.2.4 Scheduling
of the Project.

2.4 Evolution of the Software Development Plan

A table of proposed versions of the Software Development Plan and the criteria for review
non-programmed and re-edition of this plan. The text below is provided as an example.
The Software Development Plan will be reviewed before the start of each Iteration phase.
3. Project Organization
3.1 Organizational Structure
Describe the organizational structure of the project team, including management authorities and
other review authorities.]---- ORGANIZATIONAL CHART OF PI
3.2 External Interfaces
Describe how the project relates to external groups. For each external group, identify the
internal and external contact names. This should include responsibilities related to implementation and
to the acceptance of the product.

3.3 Papers and Responsibilities

Identify the organizational units of the project that will be responsible for each of the disciplines,
details of the workflow and support processes. The text below is provided as an example.

Person Role in the Rational Unified Process

Project Manager
Deployment Manager
Requirements Reviewer
Sally Slalom, Senior Manager
Architecture Reviewer
Configuration Manager
Change Control Manager
Project Reviewer
Matt Mogul, Vice President of Operations
Requirements Reviewer
System Analyst
Requirements Specifier
User Interface Designer
Software Architect
Design Reviewer
Test Manager
Tom Telemark, Senior Software Engineer Test Analyst
and, to a lesser extent, the following roles:
Designer
Implementer
Code Reviewer
Integrator

Confidential <CompanyName>, 2013 Page 5 of 9

<Project Name> Version: 1.0
Software Development Plan (Small Project) <dd/mmm/yy>
<document identifier>

Test Designer
Tester
Technical Writer

Designer
Susan Snow, Software Engineer Implementer
Henry Halfpipe, Junior Software Engineer Code Reviewer
Integrator
TBD1, Software Engineer Test Designer
TBD2, Junior Software Engineer Tester
Technical Writer
Responsible for maintaining the project website on the Web,
to assist the person who serves as Manager
of the Project in the planning/programming of
Patrick Powder, Administrative Assistant activities and help the person who plays the role
from Change Control Manager to control
changes in the artifacts. It can also assist
other roles, if necessary.

Any member of the project team can perform [Link] Role.

4. Management Process
4.1 Project Estimates
Provide the schedule and estimated cost of the project, as well as the basis for these estimates, and the points
and the circumstances of the project in which new estimates will be made.
4.2 Project Plan
This section contains the project schedule and resources.
4.2.1 Phase Plan
[Include the following:

Work Breakdown Structure (WBS) - optional for small projects

a timeline or a Gantt chart showing the time allocated for the phases or iterations of
project
identification of the main milestones with the respective success criteria
Define all important demonstrations and release points.
Objectives of the Iterations
List the objectives to be achieved for each of the iterations.
4.2.3 Releases
A brief description of each software release and whether it is a beta version, demo, etc.
4.2.4 Project Programming
[Diagrams or tables showing the target dates for the completion of iterations and phases, of the points of]
release, the demonstrations and other milestones.
4.2.5 Project Resources
Identify here the numbers and types of human resources needed, including all experiences or
special skills, programmed by phase or iteration of the project.

Confidential <CompanyName>, 2013 Page 6 of 9

<Project Name> Version: 1.0
Software Development Plan (Small Project) dd/mmm/yy
<document identifier>

Describe how you intend to locate and acquire the people to join the necessary team.
project.
List any special trainings required for the project team members, along with the dates.
target identifying when the training should be completed.
Carry out the cost allocation in relation to the WBS and the Phase Plan.

4.3 Project Monitoring and Control

Below we present a checklist of items to be considered:
Requirements Management: specify the information and control mechanisms that will be
collected and used to measure, report and control changes in product requirements.
Schedule and Budget Control: Describe the approach to be taken to monitor the
expenses, considering the project budget and progress according to the schedule
planned. Describe how to execute corrective actions when necessary.
Quality Control: Describe the progress and methods to be used for control.
quality of the products released from the project and how to implement corrective actions when necessary.
Include techniques, metrics, criteria, and procedures used for evaluation—this will encompass
technical inspections, inspections and reviews. Note that these procedures are a complement
of the Test Plan, which is not included in the Software Development Plan.
Reports and Metrics: describe the internal and external reports to be generated, and the frequency
and publication distribution. Specify the metrics that should be collected and why.
Risk Management: describe the method that will be used to identify, analyze, prioritize,
monitor and reduce risks. Include a list of risks and their current status.
Project Completion: describe the activities necessary for the project to be completed.
organized form, including the new team designation, the archiving of materials from
project, inquiries and post-mortem reports etc.
Configuration Management: describe the process through which problems and changes
are sent, reviewed and organized. Describe how the artifacts of the product or project
shall be named, marked, and numbered, including hardware, system software,
Third Party Products (COTS), plans, models, components, test software, results and
data, executables, etc. Describe retention policies and the backup, disaster recovery, and
recovery. Also describe how the media should be maintained—online, offline, type of media
the format.
Problem Resolution: describe the method that will be used to resolve misunderstandings with
the client, including how to handle misunderstandings related to contracts, to the scope of
project and delays in scheduling.
Management of Subcontractors: describe how subcontractors will be managed.
Process Improvement Plan: describe how the project's efficiency will be evaluated and
improved.
The text below is provided as an example.]
Requirements Management
The requirements of this system are captured in the Vision Document. The changes requested in the requirements
are captured in the Change Requests and are approved as part of the Management process
Configuration.
Schedule and Budget Control

Confidential <CompanyName>, 2013 Page 7 of 9

Project Name Version: 1.0
Software Development Plan (Small Project) <dd/mmm/yy>
<document identifier>

Expenses are monitored by the project manager and reported and assessed monthly.
Reports and Metrics below.)
The project manager keeps a schedule showing the expected date for each milestone. The line items
In the programming, there are work packages assigned to people. Each person to whom it is assigned a
The work package provides the project manager with information about the percentage of completion of tasks.
weekly. Changes to the schedule will be the responsibility of the project's sponsors, who will decide
if the scope will be altered in order to preserve the target completion dates.
Quality Control
The defects will be recorded and monitored as Change Requests, and the defect metrics will be
collected.
It will be necessary for all released products to undergo the appropriate review process,
as described in the Development Case. The review is necessary to ensure that each
product released meets acceptable quality, using the guidelines described in the checkpoints and
in the RUP review guidelines for Small Projects.
All defects found during the review that are not corrected before release for
Integration should be captured as Change Requests so that they are not forgotten.
Reports and Metrics
Updated cost and schedule estimates and summary reports of metrics will be generated at the end of
each iteration.
The Minimum Set of Metrics, as described in the RUPGuidelines: Metrics, will be collected
weekly. This includes:
The value attributed to completed tasks. It is used to redo the estimate of the schedule and budget.
for the remainder of the project and/or to identify the need for changes in the scope.
All open and closed defects - shown as a trend graph. They are used to help
estimate the remaining effort needed to fix defects.
Approval of acceptance test cases - shown as a trend graph. It is used for
demonstrate the progress to those involved.
In addition, the overall costs will be monitored in view of the project budget.
Risk Management
The risks will be identified in the Initiation Phase using the steps identified in the activity 'Identify and
Evaluate Risks of RUP for Small Projects. Project risks will be assessed at least once.
in each iteration and documented in this table. The most important risks are listed first in the
table.

Impact Classification and Risk Description Reduction Strategy and/or Contingency Plan
Risk (High,
Medium, Low

Configuration Management
Appropriate tools will be selected that provide a database of Change Requests.
and a version-controlled repository of the project's artifacts.

Confidential <CompanyName>, 2013 Page 8 of 9

Project Name Version: 1.0
Software Development Plan (Small Project) dd/mmm/yy
<document identifier>

All the source code, test scripts, and data files will be included in the baselines. A
documentation related to the source code will also be included in the baseline, such as, for example, the
design documentation. All released product artifacts from the client are included in the final baseline
from the iteration, including the executables.

Change Requests are reviewed and approved by the project member responsible for the role.
Change Control Manager.
Full backups are performed monthly and incremental ones at night.
5. Annexes
Additional material for the reader of the Software Development Plan. List or include plans
and technical standards of any project that apply to this project. Normally, the Case of
Development, the plans for infrastructure and the acceptance of the product are included in these plans.
standards. In addition, Programming Guides, Design Guides, and are also usually included
other process guides. The text below is provided as an example.
The project will follow the RUP process for Small Projects, according to the adaptation contained in the Case of
Project development.
Other applicable process plans are listed in the references section, including the Guide of
Programming.

Confidential <CompanyName>, 2013 Page 9 of 9