Course Registration System

Software Development Plan

Version 1.0

Revision History

Table of Contents

1.          Introduction         

1.1      Purpose     

1.2      Scope     

1.3      Definitions, Acronyms and Abbreviations     

1.4      References     

1.5      Overview     

2.          Project Overview      

2.1      Project Purpose, Scope and Objectives     

2.2      Assumptions and Constraints     

2.3      Project Work Products     

2.4      Evolution of the Software Development Plan     

3.          Project Organization  

3.1      Organizational Structure     

3.2      External Interfaces     

3.3      Roles and Responsibilities     

4.          Management Process

4.1      Project Estimates     

4.2      Project Plan     

4.2.1       Phase Plan      

4.2.2       Iteration Objectives

4.2.3       Releases      

4.2.4       Project Schedule 

4.2.5       Project Resourcing      

              4.2.5.1       Staffing Plan      

              4.2.5.2       Resource Acquisition Plan      

              4.2.5.3       Training Plan      

4.2.6       Budget      

4.3      Iteration Plans     

4.4      Project Monitoring and Control     

4.4.1       Requirements Management Plan      

4.4.2       Schedule Control Plan      

4.4.3       Budget Control Plan      

4.4.4       Quality Control Plan      

4.4.5       Reporting Plan      

4.4.6       Measurement Plan      

4.5      Risk Management plan     

4.6      Close-out Plan     

5.          Technical process plans 

5.1      Development Case     

5.2      Methods, Tools and Techniques     

5.3      Infrastructure Plan     

5.4      Product Acceptance Plan     

6.          Supporting Process Plans 

7.          Additional Plans 

8.          Annexes 

9.          Index     

Software Development Plan

1.                  Introduction 

1.1               Purpose

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.

1.2               Scope

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].

1.3               Definitions, Acronyms and Abbreviations

See Glossary [4].

1.4               References

Applicable references are:

1. Course Registration System Vision, WyIT387, V1.0, Wylie College IT.
2. Course Registration System Business Case, WyIT388, DRAFT, 1998, Wylie College IT.
3. Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.
4. Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.
5. Course Registration System High Level Project Schedule, V1.0, 1999, Wylie College IT.
6. Rational Unified Process, 1999, Rational Software Corp.
7. Course Registration System Cost Model and Analysis Report, WylT390, V1.0 Wylie College IT.
8. Course Registration System Risk List, WyIT389, V1.0, Wylie College IT.
9. Course Registration System Development Case, WyIT390, V1.0, Wylie College IT.
10. Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT391, V1.0, Wylie College IT

1.5               Overview

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 work products 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. 

2.                  Project Overview

2.1               Project Purpose, Scope, and Objectives

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].

2.2               Assumptions and Constraints

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.

2.3               Project Work Products

The following work products will be produced during the project, and delivered to the maintenance organization.

• the Product, including:
  • executable released Deployment Units
  • Installation Work Products
• End-Use Support Material (including Release Notes)
• Source Code (Implementation Elements)
• Test Suites
• Software Architecture Document
• Project-Specific Design and Implementation Guidelines
• Use Cases
• Supplementary Specification
• Glossary
• Vision

Other work products will be produced, as described in the project development case, but are not intended to be delivered to the maintenance organization.

2.4               Evolution of the Software Development Plan

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

3.                  Project Organization

3.1               Organizational Structure

3.2               External Interfaces

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 work products.

3.3               Roles and Responsibilities

The following table identifies the organizational units that will be responsible for each of the disciplines, activities, and supporting processes.

4.                  Management Process

4.1               Project Estimates

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.

4.2               Project Plan

4.2.1          Phase Plan

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:

Table 4.2.2 describes each phase and the major milestone that marks the completion of the phase.

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.

4.2.2          Iteration Objectives

Each phase consists of development iterations in which a subset of the system is developed. In general, these iterations:

• Reduce technical risk;
• Provide early versions of a working system;
• Allow maximum flexibility in planning features for each release; and
• Enable scope changes to be handled effectively within an iteration cycle.

The following table describes the iterations along with associated milestones and addressed risks.

4.2.3          Releases

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:

• Logon
• Register for courses
• Interface to Course Catalog Database
• Maintain Student Information
• Maintain Professor Information

Release 2 should include:

• Submit Student Grades
• View Grades
• Select courses to teach

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:

• R2 Internal 1 - addressing R1 bugs and enhancements. Implement main flow of "Select Courses to Teach", and design the UI for remaining R2 functionality.
• R2 Internal 2 - Implement main flows for remaining R2 functionality.

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.

4.2.4          Project Schedule

The high level schedule showing project phases, iterations, and milestones is contained in the C-Registration High Level Project Schedule [5] as shown below.

4.2.5          Project Resourcing

4.2.5.1     Staffing Plan

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.

4.2.5.2     Resource Acquisition Plan

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.

4.2.5.3     Training Plan

Training on the following skills will be conducted for the project team prior to the commencement of design activities:

• Object Oriented Analysis & Design
• Introduction to the Rational Unified Process
• Advanced C++ Features

4.2.6          Budget

The project's budget as based upon the initial estimates

4.3               Iteration Plans

See the Course Registration System E1 Iteration Plan [11].

4.4               Project Monitoring and control

4.4.1          Requirements Management Plan

The requirements for this system are captured in the Vision [1] and Stakeholder Requests [3] documents.

4.4.2          Schedule Control Plan

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.

4.4.3          Budget Control Plan

Expenses are monitored by the project manager, and reported and assessed via the Status Assessment Report.

4.4.4          Quality Control Plan

All work products are required to go through the appropriate review process.  The review is required to ensure that each work product 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].

4.4.5          Reporting Plan

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

4.4.6          Measurement Plan

Standard project metrics, as described in The Wylie College Software Process Website [10], will be gathered and included in the Status Assessment Report.

4.5               Risk Management plan

See C-Registration System Risk List [8].

4.6               Close-out Plan

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.

5.                  Technical Process Plans

5.1               Development Case

See C-Registration System Development Case [9].

5.2               Methods, tools and techniques

See Wylie College Software Process Website [10].

5.3               Infrastructure Plan

N/A

5.4               Product Acceptance Plan

N/A

6.                  Supporting Process Plans

See Wylie Software Process Website [10].

7.                  Additional plans

N/A.

8.                  Annexes

N/A.

9.                  Index

N/A.