Course Registration System

Software Development Plan

Version 1.0

Revision History

Date | Version | Description | Author
--- | --- | --- | ---
15/Jan/99 | 1.0 | Initial version | Rick Bell

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.

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.

# 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:

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.

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

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.

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

Project Schedule | Date
--- | ---
Inception Phase |
Preliminary Iteration (start) | Tue 12/1/98
Business Case Review Milestone (end Inception Phase) | Tue 1/19/99
Elaboration Phase |
Iteration E1 - Develop Architectural Prototype |
Architectural Prototype Milestone (end Elaboration Phase) | Tue 3/9/99
Construction Phase |
Iteration C1 - Develop Release 1 Beta |
Initial Operational Capability Milestone (R1 Beta Code Complete) | Fri 4/9/99
Transition Phase |
Iteration T1 - Develop/Deploy Release 1 |
R1 Beta Test Complete | Fri 4/16/99
R1 Code Complete | Fri 4/30/99
R1 Product Release (end T1) | Fri 5/7/99
Iteration T2 - Develop Release 2 Beta 1 |
R2 Internal 1 Test Complete (end T2) | Fri 5/28/99
Iteration T3 - Develop Release 2 Beta 2 |
R2 Internal 2 Test Complete (end T3) | Fri 6/18/99
Iteration T4 - Develop/Deploy Release 2 |
R2 Code Complete | Fri 7/2/99
R2 Product Release (project close-out) | Fri 7/9/99

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