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 Deliverables     

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  Go to the top of the page.

1.1               Purpose Go to the top of the page.

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 Go to the top of the page.

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 Go to the top of the page.

See Glossary [4].

1.4               References Go to the top of the page.

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, WylIT390, 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 Go to the top of the page.

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. 

2.                  Project Overview Go to the top of the page.

2.1               Project Purpose, Scope, and Objectives Go to the top of the page.

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 Go to the top of the page.

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 Deliverables Go to the top of the page.

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.

2.4               Evolution of the Software Development Plan Go to the top of the page.

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

3.                  Project Organization Go to the top of the page.

3.1               Organizational Structure Go to the top of the page.

Description in Header Above

3.2               External Interfaces Go to the top of the page.

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.

3.3               Roles and Responsibilities Go to the top of the page.

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. 

 

4.                  Management Process Go to the top of the page.

4.1               Project Estimates Go to the top of the page.

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 PlanGo to the top of the page.

4.2.1          Phase Plan Go to the top of the page.

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 Go to the top of the page.

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.

 

4.2.3          Releases Go to the top of the page.

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.

4.2.4          Project Schedule Go to the top of the page.

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 Go to the top of the page.

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:

4.2.6          Budget Go to the top of the page.

Description in Content Below

The project's budget as based upon the initial estimates

4.3               Iteration Plans Go to the top of the page.

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

4.4               Project Monitoring and control Go to the top of the page.

4.4.1          Requirements Management Plan Go to the top of the page.

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

4.4.2          Schedule Control Plan Go to the top of the page.

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 Go to the top of the page.

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

4.4.4          Quality Control Plan Go to the top of the page.

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

4.4.5          Reporting Plan Go to the top of the page.

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 Go to the top of the page.

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 Go to the top of the page.

See C-Registration System Risk List [8].

4.6               Close-out Plan Go to the top of the page.

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 Go to the top of the page.

5.1               Development Case Go to the top of the page.

See C-Registration System Development Case [9].

5.2               Methods, tools and techniques Go to the top of the page.

See Wylie College Software Process Website [10].

5.3               Infrastructure Plan Go to the top of the page.

N/A

5.4               Product Acceptance Plan Go to the top of the page.

N/A

6.                  Supporting Process Plans Go to the top of the page.

See Wylie Software Process Website [10].

7.                  Additional plans Go to the top of the page.

N/A.

8.                  Annexes Go to the top of the page.

N/A.

9.                  Index Go to the top of the page.

N/A.