Software Development Plan
Version 1.0
Revision History
Date |
Version |
Description |
Author |
---|---|---|---|
15/Jan/99 |
1.0 |
Initial version |
Rick Bell |
|
|
|
|
|
|
|
|
|
|
|
|
1.3 Definitions, Acronyms and Abbreviations
2.1 Project Purpose, Scope and Objectives
2.2 Assumptions and Constraints
2.4 Evolution of the Software Development Plan
3.3 Roles and Responsibilities
4.2.5.2 Resource Acquisition Plan
4.4 Project Monitoring and Control
4.4.1 Requirements Management Plan
5.2 Methods, Tools and Techniques
Software Development Plan
The objective of this Software Development Plan is to define the development activities in terms of the phases and iterations required for implementing a computerized class registration system for Wylie College.
This Software Development Plan describes the overall plan
to be used by Wylie College Information Systems for developing the
C-Registration System for Wylie College. 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].
See Glossary [4].
Applicable references are:
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.
Technical Process Plans - provides an overview of the software development process, including methods, tools and techniques to be followed.
Supporting Process Plans - this includes the configuration management plan.
This Software Development Plan describes the overall plan to be used by Wylie College Information Systems for developing the C-Registration System for Wylie College. 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 [1].
The system is intended to be the primary means of student registration for the 1999 Fall term. Since course registration begins Aug 1 1999, the system must be fully available by this date.
The following artifacts will be produced during the project, and delivered to the maintenance organization.
Other artifacts will be produced, as described in the project development case, but are not intended to be delivered to the maintenance organization.
The Software Development Plan will be revised prior to the start of each Iteration phase.
The Project Manager will provide Status Assessment, as scheduled in this plan, to the IT Executive stakeholder (see Vision [1]).
The project team will also interact with other stakeholders to solicit inputs and review of relevant artifacts.
The following table identifies the organizational units that will be responsible for each of the disciplines, workflow details, and supporting processes.
Role |
Responsibility |
---|---|
Project Manager |
As described in the Rational Unified Process [6]. Responsible for managing the overall Project Management discipline. Leads the extended Project Management Team. |
Process Engineer | Responsible for the project environment, and providing process related support for the teams in the project as defined in the Environment discipline in Rational Unified Process. Participates in an extended Project Management Team. |
Configuration Manager / Change Control Manager | Responsible for Configuration Control on the project, and for exercising the Wylie College Change Request Process in the project. Participates in an extended Project Management Team. |
Systems Engineering Team Lead |
Leading the team primarily responsible for managing the Business Modeling and Requirements disciplines. Participates in an extended Project Management Team. |
Software Engineering Team Lead |
Primarily responsible for the Analysis & Design and the , Implementation disciplines. Participates in an extended Project Management Team. |
Test Team Lead |
Leading the team responsible for managing the Test discipline. Participates in an extended Project Management Team. |
Deployment Team Lead | Leading the team responsible for installation activities and infrastructure in the end-user environment. Participates in an extended Project Management Team. |
Project estimates are based on the C-Registration System Cost Model and Analysis Report [7].
The Course Registration System is similar in complexity and architecture to the Online Library System, built by Wylie College in 1997. The course registration system database is roughly 25% more complex, and the number and complexity of use cases suggests that the system will be roughly 20% more complex overall. The time-frame and effort estimates from this report are the basis of the project budget and schedule.
A Work Breakdown Structure is being prepared, and will be provided in the next version of this document.
The development of the C-Registration System will be conducted using a phased approach where multiple iterations occur within a phase. The phases and iterations in this plan do not overlap. A summary of the relative timeline is shown below in the table below:
Phase |
No. of Iterations |
End |
---|---|---|
Inception Phase |
1 |
Week 7 |
Elaboration Phase |
1 |
Week 14 |
Construction Phase |
1 |
Week 19 |
Transition Phase |
4 |
Week 32 |
Table 4.2.1 Relative Timeline Summary
Table 4.2.2 describes each phase and the major milestone that marks the completion of the phase.
Phase |
Description |
Milestone |
---|---|---|
Inception Phase |
The Inception Phase will develop the product requirements and establish the business case for the C-Registration System. The major use cases will be developed as well as the high level Software Development Plan. At the end of the Inception Phase Wylie College will decide whether to fund and proceed with the project based upon the business case. |
Business Case Review Milestone at the end of the phase marks the Go/No Go decision for the project. |
Elaboration Phase |
The Elaboration Phase will analyze the requirements and will develop the architectural prototype. At the completion of the Elaboration Phase all use cases selected for Release 1.0 will have completed analysis & design. In addition, the high risk use cases for Release 2.0 will have been analyzed and designed. The architectural prototype will test the feasibility and performance of the architecture that is required for Release 1.0. |
The Architectural Prototype Milestone marks the end of the Elaboration Phase. This prototype signifies verification of the major architectural components that comprise the R1.0 Release. |
Construction Phase |
During the Construction Phase, remaining use cases will be analyzed and designed. The Beta version for Release 1.0 will be developed and distributed for evaluation. The implementation and test activities to support the R1.0 and R2.0 releases will be completed. |
The Initial Operational Capability Milestone (completion of the beta) marks the end of the Construction Phase. |
Transition Phase |
The Beta version for Release 1.0 will be distributed and evaluated. The Transition Phase will prepare the R1.0 and R2.0 releases for distribution. It provides the required support to ensure a smooth installation including user training. |
The R2.0 Release Milestone marks the end of the Transition Phase. At this point all capabilities, as defined in the Vision Document [1], are installed and available for the users. |
Table 4.2.2 Project Phases and Major Milestones
Each phase is split into development iterations as described in Section 4.3.
Section 4.2.4 illustrates the high-level project schedule showing phases, iterations, and major milestones.
Each phase consists of development iterations in which a subset of the system is developed. In general, these iterations:
The following table describes the iterations along with associated milestones and addressed risks.
Phase |
Iteration |
Description |
Associated Milestones |
Risks Addressed |
---|---|---|---|---|
Inception Phase |
Preliminary Iteration |
Defines business model, product requirements, Software Development Plan, and business case. |
Business Case Review |
Clarifies user requirements up front. Develops realistic Software Development Plans and scope. Determines feasibility of project from a business point of view. |
Elaboration Phase |
E1 Iteration - Develop Architectural Prototype |
Completes analysis & design for all high risk requirements. Develops the architectural prototype.
|
Architectural Prototype |
Architectural issues clarified. Technical risks mitigated. Early prototype for user review. |
Construction Phase |
C1 Iteration - Develop R1 Beta |
Implement and test key R1 requirements to provide the R1 Beta Version.
Assess if the release is ready to go for beta testing. |
Initial Operational Capability (R1 Beta Code Complete) |
All key features from a user and architectural perspective implemented in the Beta.
|
Transition Phase |
T1 Iteration - Develop/Deploy R1 Release |
Deploy the R1 Beta. Fix defects from Beta, and incorporate feedback from Beta.
Implement and test remaining R1 requirements. Package, distribute, and install R1 Release. Remaining low-risk R2 use cases fully detailed. |
R1 Beta Test Complete
R1 Code Complete
R1 Product Release |
User feedback prior to release of R1.
Product quality should be high. Defects minimized. Cost of quality reduced. Two-stage release minimizes defects. Two-stage release provides easier transition for users. R1 fully reviewed by user community. |
|
T2 Iteration - Develop R2 Internal 1 |
Design, implement, and test R2 Internal 1 requirements. Incorporate enhancements and defects from R1. Deploy the R2 Internal 1. |
R2 Internal 1 Test Complete |
If needed, R2 Internal 1 could be released to address R1 defects, to help address customer satisfaction. |
|
T3 Iteration - Develop R2 Internal 2 |
Design, implement, and test R2 Internal 2 requirements Incorporate enhancements and defects from R2 Internal 2. Deploy the R2 Internal 2. |
R2 Internal 2 Test Complete |
R2 Internal 1 informally reviewed by user community.
If needed, R2 Internal 1 could be released to address R1 defects, to help address customer satisfaction. |
|
T4 Iteration - Develop/Deploy R2 Release |
Package, distribute, and install R2 Release. |
R2 Code Complete
R2 Product Release |
R2 Internal 2 informally reviewed by user community. Two-stage release provides easier transition for users. |
This Software Development Plan addresses the first 2 releases of the C-Registration System. Key features as defined in the Vision Document [1] are targeted for the first 2 releases. All features critical to student registration are planned for the first release (R1.0).
The planned content of the releases is expected to change as the project progresses. This may be due to a number of business and technical factors. To accommodate the changes, Rational RequisitePro will be used to manage the product requirements and to keep track of release content. In particular, benefit, effort, and risk attributes are used to determine priority of product requirements and thus the target release.
It is anticipated that the C-Registration System will be released for general use at Wylie College through 2-4 main releases.
Release 1 must contain as a minimum the basic functionality as listed below:
Release 2 should include:
The functionality for Release 3 has not yet been determined. It is anticipated that this release will contain enhancements to the existing functionality.
Future replacement of the legacy Billing System and Course Database System is targeted for Release 4 in Year 2005.
In addition, a Beta Release will precede the R1.0 Product Release, and will contain all the key R1 functionality. The Beta release will be deployed as if it were the real system, with the exception that it will interact with an isolated copy of the existing legacy systems, in order to avoid any disruption of existing systems. A select group of students and faculty will be asked to formally evaluate the beta.
In addition, there will be internal releases, to maintain a regular heartbeat to help keep the project on track, and to allow for the possibility of additional releases after the initial release, if needed. Internal releases can be informally reviewed by students and faculty. The following provides a brief description of the objectives for each of these internal releases:
The functionality for Release 3 has not yet been determined. It is anticipated that this release will contain enhancements to the existing functionality.
Future replacement of the legacy Billing System and Course Database System is targeted for Release 4 in Year 2005.
The high level schedule showing project phases, iterations, and milestones is contained in the C-Registration High Level Project Schedule [5] as shown below.
|
The IT employees identified in the Organizational Chart in Section 8.1 are allocated to the project. Additional resources will not staffed until the business case is reviewed at the end of the Inception Phase and a Go/No Go decision is made on the project.
The test organization will rely on support from the software engineering organization, as shown by the dotted line in the organization chart.
The Wylie College IT department has insufficient Developers and Designers to meet the project needs. The Wylie College Recruiting Office is prepared to recruit a Senior Developer with several years C++ experience, and experienced System Integrator, and 2 Implementor/Testers (Junior Grade), with at least 1 years C++ experience.
Training on the following skills will be conducted for the project team prior to the commencement of design activities:
The project's budget as based upon the initial estimates
See the Course Registration System E1 Iteration Plan [11].
The requirements for this system are captured in the Vision [1] and Stakeholder Requests [3] documents.
The project manager maintains a summary schedule showing the expected date of each milestone, and is part of the Status Assessment Report, as described in the reporting plan. The Status Assessment Report is provided to the IT Executive, who may use this to set new priorities or to recommend corrective action.
The summary schedule is derived from a detailed schedule maintained by the team managers. The line items in the detailed schedule are work packages assigned to individuals. Each individual who is assigned a work package provides %completion information to his/her team manager on a weekly basis.
Expenses are monitored by the project manager, and reported and assessed via the Status Assessment Report.
All deliverables are required to go through the appropriate review process. The review is required to ensure that each deliverable is of acceptable quality, using guidelines described in the Rational Unified Process [6] review guidelines and checklists.
In addition, defects will be recorded and tracked, and defect metrics gathered as described on the Wylie Software Process Website [10].
The Status Assessment report will be prepared by the Project Manager at least once per month. This includes:
- updated cost and schedule estimates
- summary of metrics
Standard project metrics, as described in The Wylie College Software Process Website [10], will be gathered and included in the Status Assessment Report.
See C-Registration System Risk List [8].
The schedule will show a gradual roll-off of staff onto other projects. At least one developer will be retained part time by the IT Department after delivery to provide maintenance of the system.
A Post Mortem Report will be submitted to the IT Executive summarizing lessons learned, including an assessment of actual cost and schedule vs. predicted.
See C-Registration System Development Case [9].
See Wylie College Software Process Website [10].
N/A
N/A
See Wylie Software Process Website [10].
N/A.
N/A.
N/A.