[The introduction of the Software Development Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Software Development Plan.]

1.1 Purpose

[Specify the purpose of this Software Development Plan. The text below is provided as an example. ]

The purpose of the Software Development Plan is to gather all information necessary to control the project. It describes the approach to the development of the software and is the top-level plan generated and used by managers to direct the development effort.

The following people use the Software Development Plan:

· The project manager uses it to plan the project schedule and resource needs, and to track progress against the schedule.

· Project team members use it to understand what they need to do, when they need to do it, and what other activities they are dependent upon.

1.2 Scope

[A brief description of the scope of this Software Development Plan; what Project(s) it is associated with and anything else that is affected or influenced by this document. The text below is provided as an example.]

This Software Development Plan describes the overall plan to be used by the <project name> project, including deployment of the product. The details of the individual iterations will be described in the Iteration Plans.
The plans as outlined in this document are based upon the product requirements as defined in the Vision Document.

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Software Development Plan. This information may be provided by reference to the project’s Glossary.]

See the Project Glossary.

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Software Development Plan. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.

For the Software Development Plan, the list of referenced artifacts includes:

· RUP for Small Projects Website

· Iteration Plans

· Development Case

· Vision

· Glossary

· Any other supporting plans or documentation.]

1.5 Overview

[This subsection describes what the rest of the Software Development Plan contains and explains how the document is organized. The text below is provided as an example.]

This Software Development Plan contains the following information:

Project Overview — provides a description of the project's purpose, scope, and objectives. It also defines the deliverables that the project is expected to deliver.

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

Management Process — explains the estimated cost and schedule, defines the major phases and milestones for the project, and describes how the project will be monitored.

Applicable Plans and Guidelines — provides an overview of the software development process, including methods, tools and techniques to be followed.

2. Project Overview

2.1 Project Purpose, Scope, and Objectives

[A brief description of the purpose and objectives of this project and a brief description of what deliverables the project is expected to deliver.]

2.2 Assumptions and Constraints

[A list of assumptions that this plan is based and any constraints, for example. budget, staff, equipment, schedule, that apply to the project.]

2.3 Project Deliverables

[A list of the artifacts to be created during the project, including target delivery dates. The text below is provided as an example.]

Deliverables for each project phase are identified in the Development Case. Deliverables are delivered towards the end of the iteration, as specified in section 4.2.4 Project Schedule.

2.4 Evolution of the Software Development Plan

[A table of proposed versions of the Software Development Plan, and the criteria for the unscheduled revision and reissue of this plan. The text below is provided as an example.]

The Software Development Plan will be revised prior to the start of each Iteration phase.

3. Project Organization

3.1 Organizational Structure

[Describe the organizational structure of the project team, including management and other review authorities.]

3.2 External Interfaces

[Describe how the project interfaces with external groups. For each external group, identify the internal and external contact names. This should include responsibilities related to deployment and acceptance of the product.]

3.3 Roles and Responsibilities

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

Person	Rational Unified Process Role
Sally Slalom, Senior Manager	Project Manager Deployment Manager Requirements Reviewer Architecture Reviewer Configuration Manager Change Control Manager
Matt Mogul, VP Operations	Project Reviewer Requirements Reviewer
Tom Telemark, Senior Software Engineer	System Analyst Requirements Specifier User Interface Designer Software Architect Design Reviewer Test Manager Test Analyst and to a lesser extent the following roles: Designer Implementer Code Reviewer Integrator Test Designer Tester Technical Writer
Susan Snow, Software Engineer Henry Halfpipe, Junior Software Engineer TBD1, Software Engineer TBD2, Junior Software Engineer	Designer Implementer Code Reviewer Integrator Test Designer Tester Technical Writer
Patrick Powder, Administrative Assistant	Responsible for maintaining the Project web site, assisting the Project Manager role in planning/scheduling activities, and assisting the Change Control Manager role in controlling changes to artifacts. May also provide assistance to other roles as necessary.

Anyone on the project can perform Any Role activities.

4. Management Process

4.1 Project Estimates

[Provide the estimated cost and schedule for the project, as well as the basis for those estimates, and the points and circumstances in the project when re-estimation will occur.]

4.2 Project Plan

[This section contains the schedule and resources for the project.]

4.2.1 Phase Plan

[Include the following:

· Work Breakdown Structure (WBS) — optional for small projects

· a timeline or Gantt chart showing the allocation of time to the project phases or iterations

· identify major milestones with their achievement criteria

Define any important release points and demos.]

4.2.2 Iteration Objectives

[List the objectives to be accomplished for each of the iterations.]

4.2.3 Releases

[A brief description of each software release and whether it’s demo, beta, and so on.]

4.2.4 Project Schedule

[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.]

4.2.5 Project Resourcing

[Identify the numbers and type of staff required here, including any special skills or experience, scheduled by project phase or iteration.

Describe how you will approach finding and acquiring the staff needed for the project.

List any special training project team members will require, with target dates for when this training should be completed.

Allocation of costs against the WBS and the Phase Plan.]

4.3 Project Monitoring and Control

[The following is a checklist of items to consider:

· Requirements Management : Specify the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements.

· Schedule and Budget Control:Describe the approach to be taken to monitor spending against the project budget and progress against the planned schedule. Describe how to take corrective action when required.

· Quality Control:Describe the timing and methods to be used to control the quality of the project deliverables and how to take corrective action when required. Include techniques, metrics, criteria, and procedures used for evaluation— this will include walkthroughs, inspections, and reviews. Note that this is in addition to the Test Plan, which is not enclosed in the Software Development Plan.

· Reporting and Measurement: Describe internal and external reports to be generated, and the frequency and distribution of publication. Specify which metrics should be collected and why.

· Risk Management: Describe the approach that will be used to identify, analyze, prioritize, monitor and mitigate risks. Include a list of risks and their current status.

· Project Close-out: Describe the activities for the orderly completion of the project, including staff reassignment, archiving of project materials, post-mortem debriefings and reports, and so forth.

· Configuration Management: Describe the process by which problems and changes are submitted, reviewed, and dispositioned. Describe how project or product artifacts are to be named, marked, and numbered, including hardware, system software, Commercial-Off-The-Shelf (COTS), plans, models, components, test software, results and data, executables, and so on. Describe retention policies, and the back-up, disaster, and recovery plans. Also describe how the media is to be retained—online, offline, media type, and format.

· Problem Resolution: Describe the approach to be taken to resolve disagreements with the customer, including how to handle schedule slips, scope, and contractual disagreements.

· Subcontractor Management: Describe how subcontractors will be managed.

· Process Improvement Plan: Describe how the effectiveness of the process will be assessed and improved.

The text that follows is provided as an example.]

Requirements Management

The requirements for this system are captured in the Vision document. Requested changes to requirements are captured in Change Requests, and are approved as part of the Configuration Management process.

Schedule and Budget Control

Expenses are monitored by the project manager, and reported and assessed monthly. (See Reporting and Measurement below).

The project manager maintains a schedule showing the expected date of each milestone. The line items in the schedule include work packages assigned to individuals. Each individual who is assigned a work package provides %completion information to the project manager on a weekly basis. Changes in the schedule will be escalated to the project sponsors, who will then decide whether to alter scope in order to preserve target completion dates.

Quality Control

Defects will be recorded and tracked as Change Requests, and defect metrics will be gathered (see Reporting and Measurement below).

All deliverables are required to go through the appropriate review process, as described in the Development Case. The review is required to ensure that each deliverable is of acceptable quality, using guidelines described in the RUP for Small Projects review guidelines and checklists.

Any defects found during review which are not corrected prior to releasing for integration must be captured as Change Requests so that they are not forgotten.

Reporting and Measurement

Updated cost and schedule estimates, and metrics summary reports, will be generated at the end of each iteration.

The Minimal Set of Metrics, as described in the RUP Guidelines: Metrics, will be gathered on a weekly basis. These include:

Earned value for completed tasks. This is used to re-estimate the schedule and budget for the remainder of the project, and/or to identify need for scope changes.

Total defects open and closed – shown as a trend graph. This is used to help estimate the effort remaining to correct defects.

Acceptance test cases passing – shown as a trend graph. This is used to demonstrate progress to stakeholders.

In addition, overall costs will be monitored against the project budget.

Risk Management

Risks will be identified in Inception Phase using the steps identified in the RUP for Small Projects activity “Identify and Assess Risks”. Project risk is evaluated at least once per iteration and documented in this table. The risks of the greatest magnitude are listed first in the table.

Risk Ranking (High, Medium, Low)	Risk Description and Impact	Mitigation Strategy and/or Contingency Plan

Configuration Management

Appropriate tools will be selected which provide a database of Change Requests and a controlled versioned repository of project artifacts.

All source code, test scripts, and data files are included in baselines. Documentation related to the source code is also included in the baseline, such as design documentation. All customer deliverable artifacts are included in the final baseline of the iteration, including executables.

The Change Requests are reviewed and approved by one member of the project, the Change Control Manager role.

Full backups are performed monthly and incrementals are performed nightly.

5. Annexes

[Additional material of use to the reader of the Software Development Plan. Reference or include any project technical standards and plans which apply to this project. This typically includes the Development Case, plans for infrastructure, and product acceptance. It also typically includes Programming Guidelines, Design Guidelines, and other process guidelines. The text that follows is provided as an example.]

The project will follow the RUP for Small Projects process, as tailored by the project Development Case.

Other applicable process plans are listed in the references section, including Programming Guidelines.