Software Development Plan (Small Project)
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
Table of Contents
Software Development Plan (Small Project)
[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.]
[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:
[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.
[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.
[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:
[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.
[A brief description of the purpose and objectives of this project and a brief description of what deliverables the project is expected to deliver.]
[A list of assumptions that this plan is based and any constraints, for example. budget, staff, equipment, schedule, that apply to the project.]
[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.
[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.
[Describe the organizational structure of the project team, including management and other review authorities.]
[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.]
[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
Change Control Manager
|Matt Mogul, VP Operations||Project Reviewer
|Tom Telemark, Senior Software Engineer||System Analyst
User Interface Designer
and to a lesser extent the following roles:
|Susan Snow, Software Engineer
Henry Halfpipe, Junior Software Engineer
TBD1, Software Engineer
TBD2, Junior Software Engineer
|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.
[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.]
[This section contains the schedule and resources for the project.]
[Include the following:
Define any important release points and demos.]
[List the objectives to be accomplished for each of the iterations.]
[A brief description of each software release and whether it’s demo, beta, and so on.]
[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.]
[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.]
The text that follows is provided as an example.]
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.
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.
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.
[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.
Such a cheap price for your free time and healthy sleep
All online transactions are done using all major Credit Cards or Electronic Check through PayPal. These are safe, secure, and efficient online payment methods.