]> Software Development Plan (Small Project) &firstname; &surname; ©rightyear; &firstname; &surname;

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.

This Software Development Plan describes the overall plan to be used by the &projectname; 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.

See the Project Glossary.

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.

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

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

Person Rational Unified Process Role

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.

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.

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.

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 Show as a trend graph. This is used to help estimate the effort remaining to correct defects. Acceptance test cases passing Show as a trend graph. This is used to demonstrate progress to stakeholders. In addition, overall costs will be monitored against the project budget.

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

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.

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.