Related information

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 

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. Vision for the C-Registration System, WyIT387, V1.0, Wylie College IT.
    2. System Business Case for the C-Registration System, WyIT388, DRAFT, 1998, Wylie College IT.
    3. Stakeholder Requests Document for the C-Registration System, WyIT389, V1.0, 1998, Wylie College IT.
    4. Glossary for the C-Registration System, WyIT406, V1.0, 1998, Wylie College IT.
    5. C-Registration High Level Project Schedule, V1.0, 1999, Wylie College IT.
    6. Rational Unified Process, 1999, Rational Software Corp.
    7. C-Registration System Cost Model and Analysis Report, WylIT390, V1.0 Wylie College IT.
    8. C-Registration System Risk List, WyIT389, V1.0, Wylie College IT.
    9. C-Registration System Development Case, WyIT390, V1.0, Wylie College IT.
    10. Wylie College Software Process Website
    11. Course Registration System E1 Iteration Plan, 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 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

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 Deliverables

The following deliverables will be produced during the project:

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

3.3               Roles and Responsibilities

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

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 the relative timeline is shown in the table below:

Phase

No. of Iterations

Start

End

Inception Phase

1

Week 1

Week 8

Elaboration Phase

1

Week 8

Week 15

Construction Phase

3

Week 15

Week 31

Transition Phase

2

Week 25

Week 32

Table 4.2.1 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 R2.0 Operational Capability Milestone marks the end of the Construction Phase. Release 2.0 software is ready for packaging.

Transition Phase

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.1 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. The project duration is expected to be 7-8 months.

4.2.2          Iteration Objectives

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 R1 use cases. Develops the architectural prototype for R1.

Complete analysis & design for all high risk R2 use cases.

Architectural Prototype

Architectural issues clarified.

Technical risks mitigated.

Early prototype for user review.

Construction Phase

C1 Iteration – Develop R1 Beta

Implement and test R1 use cases to provide the R1 Beta Version.

R1 Beta

All key features from a user and architectural prospective implemented in the Beta.

User feedback prior to release of R1.

 

C2 Iteration – Develop R1 Release

Implement and test remaining R1 use cases, fix defects from Beta, and incorporate feedback from Beta.

Develops the R1 system.

R1 Software

R1 fully reviewed by user community.

Product quality should be high.

Defects minimized.

Cost of quality reduced.

 

C3 Iteration – Develop R2 Release

design, implement, and test R2 use cases.

Incorporate enhancements and defects from R1.

Develops the R2 system.

R2 Software

Quick release of R2 addresses customer satisfaction.

All key functionality provided in System by R2 Release.

Transition phase

T1 Iteration – R1 Release

Package, distribute, and install R1 Release.

R1 Released

Two-stage release minimizes defects.

Two-stage release provides easier transition for users.

 

T2 Iteration – R2 Release

Package, distribute, and install R2 Release.

R2 Released

Two-stage release minimizes defects.

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:

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.

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.

Task Name

Start

Finish

Milestones

Tue 12/1/98

Thu 6/24/99

Start

Tue 12/1/98

Tue 12/1/98

Business Case Review Milestone (end Inception Phase)

Tue 1/19/99

Tue 1/19/99

Architectural Prototype Milestone (end Elaboration Phase)

Tue 3/2/99

Tue 3/2/99

Beta Milestone (Beta Version Ready)

Fri 4/2/99

Fri 4/2/99

Initial Operational Capability Milestone (Release 1.0)

Mon 5/10/99

Mon 5/10/99

Product Release R1.0 Milestone

Wed 5/19/99

Wed 5/19/99

Second Operational Capability Milestone (Release 2.0)

Tue 6/15/99

Tue 6/15/99

Product Release R2.0 Milestone

Thu 6/24/99

Thu 6/24/99

 
 
 

Inception Phase

Tue 12/1/98

Tue 1/19/99

Preliminary Iteration

Tue 12/1/98

Tue 1/19/99

Business Modeling

Tue 12/1/98

Mon 12/21/98

Requirements

Tue 12/1/98

Tue 1/19/99

Configuration Management

Tue 12/1/98

Mon 1/11/99

Management

Tue 12/1/98

Tue 1/19/99

 
 
 

Elaboration Phase

Wed 1/20/99

Tue 3/2/99

Iteration E1 - Develop Architectural Prototype

Wed 1/20/99

Tue 3/2/99

Business Modeling

Wed 1/20/99

Fri 1/22/99

Requirements

Mon 1/25/99

Fri 1/29/99

Analysis & Design (Architecture & Major Risks)

Mon 2/1/99

Fri 2/12/99

Implementation (Architecture & Major Risks)

Mon 2/15/99

Fri 2/19/99

Test (Architecture & Major Risks)

Mon 2/22/99

Tue 3/2/99

Management

Wed 1/20/99

Tue 3/2/99

 
 
 

Construction Phase

Wed 3/3/99

Tue 6/15/99

Iteration C1 - Develop Release 1 Beta

Wed 3/3/99

Fri 4/2/99

Implementation (Beta)

Wed 3/3/99

Wed 3/24/99

Test (Interfaces & Integrated Function)

Thu 3/25/99

Fri 4/2/99

Management

Wed 3/3/99

Fri 4/2/99

Iteration C2 - Develop Release 1

Mon 4/5/99

Mon 5/10/99

Analysis & Design (Refine)

Mon 4/5/99

Mon 4/12/99

Implementation (Effective Production)

Tue 4/13/99

Mon 4/26/99

Test (Interfaces & Integrated Function)

Tue 4/27/99

Mon 5/10/99

Management

Mon 4/5/99

Mon 5/10/99

Iteration C3 - Develop Release 2.0

Tue 5/11/99

Tue 6/15/99

Analysis & Design (Refine)

Tue 5/11/99

Tue 5/18/99

Implementation (Effective Production)

Wed 5/19/99

Wed 6/2/99

Test (Interfaces & Integrated Function)

Thu 6/3/99

Tue 6/15/99

Management

Tue 5/11/99

Tue 6/15/99

 
 
 

Transition Phase

Tue 5/11/99

Thu 6/24/99

Iteration T1 - Release 1

Tue 5/11/99

Wed 5/19/99

Deployment

Tue 5/11/99

Wed 5/19/99

Iteration T2 - Release 2

Wed 6/16/99

Thu 6/24/99

Deployment

Wed 6/16/99

Thu 6/24/99

 
 
 

Environment

Tue 12/1/98

Fri 6/25/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:

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

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.