Collegiate Sports Paging System
Software Development Plan
Version 1.0
Revision History
Date |
Version |
Description |
Author |
October 5, 1999 |
1.0 |
Initial release |
Context Integration |
Table of Contents
Purpose
The purpose of this Software Development Plan is to define the development
activities in terms of the phases and iterations required for implementing a
Collegiate Sports Paging Service for WebNewsOnLine.
Scope
This Software Development Plan describes the overall plan to be used by the
team for developing the system for . The details of the individual iterations
will be described in the Iteration Plans.
Definitions, Acronyms and Abbreviations
None.
References
- CSPS Requirements Management Plan
- CSPS Risk List
- CSPS Development Case
- CSPS Creative Design Brief
Project purpose, scope and objectives
This project will implement a customized for WebNewsOnline. This will deliver
notification of updated content to subscribers via pagers, cellular phones, or
electronic mail. The subscribers will then be able to view their customized
content via the World Wide Web.
Assumptions and constraints
The system must be available in time for "March Madness" in the
year 2000 (NCAA Championship Tournament).
Project deliverables
The following deliverables will be produced during the project:
- Business Use Cases
- Business Use Case Survey
- Glossary
- Supplementary Specifications
- Creative Design Briefs
- Navigation Map
- User Interface Prototype
- Use Case Survey
- Data Model
- Design Model
- Database Design
- Software Architecture Document
- Implementation Subsystem
- Test Package
- Change Requests
- Test Summary
Evolution of the Software Development Plan
This plan will be updated prior to be start of each subsequent phase or
iteration. The target dates for the end of each phase are shown below.
Organizational Structure
The project team for the Inception and Elaboration phases will be organized
as follows:
External Interfaces
The project team will work with the Editing staff, Advertising staff, and
Field Representative staff to gather requirements, review prototypes, and test
various functions within the system. The primary contact for WebNewsOnLine will
be Donna Cram, Director of Business Operations.
Roles and Responsibilities
The following table shows the roles represented in the project diagram above
and their primary responsibilities.
Role |
Responsibility |
Project Manager |
The Project Manager allocates resources, shapes
priorities, coordinates interactions with the customers and users, and
generally tries to keep the project team focused on the right goal. The
Project Manager also establishes a set of practices that ensure the
integrity and quality of project artifacts. |
Architect |
The Architect leads and coordinates technical
activities and artifacts throughout the project. The Architect establishes
the overall structure for each architectural view: the decomposition of the
view, the grouping of elements, and the interfaces between these major
groupings. Thus, in contrast with the other workers, the Architect's view is
one of breadth, as opposed to depth. |
Business Analyst |
The business analyst leads and coordinates
business use-case modeling, by outlining and delimiting the organization
being modeled. For example, establishing what business actors and business
use cases exist and how they interact. |
Designer |
The designer defines the responsibilities,
operations, attributes, and relationships of one or several classes and
determines how they should be adjusted to the implementation environment. In
addition, the designer may have responsibility for one or more design
packages or design subsystems, including any classes owned by the packages
or subsystems. |
Creative Designer |
The creative designer leads and coordinates the
prototyping and design of the Web interface, by capturing requirements on
the Web interface, including usability requirements, building Web page
prototypes, involving other stakeholders of the Web interface, such as
end-users, in usability reviews and use testing sessions, and reviewing and
providing the appropriate feedback on the final implementation of the Web
interface (as created by other developers, i.e. designers and implementers). |
Tester |
The Tester is responsible for executing
testing, including test set-up and execution, evaluation of test execution
and recovery from errors, and assessing the results of test and logging
identified defects |
Requirements Specialist |
The Requirements Specialist captures the
specification of a part of the system's functionality by describing the
Requirements aspect of one or several use cases and other supporting
software requirements. The Requirements Specialist is also responsible for a
use-case package, and maintaining the integrity of that package. |
Project Estimates
The Inception phase of this project will take 3 weeks. Initial estimates of
subsequent phases can be seen in section 2.4 above.
Project Plan
The Inception phase of the project can be viewed as follows:
Task |
Start |
End |
INCEPTION |
Fri 10/1/99 |
Mon 10/25/99 |
Begin Inception |
Fri 10/1/99 |
Fri 10/1/99 |
Inception Kick-off |
Mon 10/4/99 |
Wed 10/6/99 |
Add tasks to project plan for specific project
technology using ContextWISE cartridges |
Mon 10/4/99 |
Mon 10/4/99 |
Assemble Change Control Board |
Mon 10/4/99 |
Tue 10/5/99 |
Create and baseline Change Control Plan |
Tue 10/5/99 |
Tue 10/5/99 |
Obtain Sign-off |
Tue 10/5/99 |
Tue 10/5/99 |
Inception Kick-off Meeting |
Tue 10/5/99 |
Wed 10/6/99 |
Prepare for inception kick-off meeting |
Tue 10/5/99 |
Wed 10/6/99 |
Hold Inception Kick-off Meeting |
Wed 10/6/99 |
Wed 10/6/99 |
Inception Kick-off Completed |
Wed 10/6/99 |
Wed 10/6/99 |
Inception Deliverables |
Wed 10/6/99 |
Thu 10/14/99 |
Hold Requirements Workshop |
Wed 10/6/99 |
Thu 10/7/99 |
Project Vision created, reviewed, and signed
off |
Wed 10/6/99 |
Thu 10/7/99 |
Preliminary Use Case Model (10-20% complete)
created and placed under revision control |
Thu 10/7/99 |
Mon 10/11/99 |
Preliminary Use Case Survey created, reviewed,
and signed off |
Mon 10/11/99 |
Tue 10/12/99 |
Preliminary Supplementary Specifications
created, reviewed, and signed off |
Tue 10/12/99 |
Tue 10/12/99 |
Business Case created, reviewed, and signed off |
Tue 10/12/99 |
Tue 10/12/99 |
Preliminary Project Glossary created, reviewed,
and signed off |
Tue 10/12/99 |
Tue 10/12/99 |
Preliminary Creative Design Brief created,
reviewed, and signed off |
Wed 10/6/99 |
Thu 10/7/99 |
Preliminary Site Map & Use-Case Navigation
Mapping created, reviewed, and signed off |
Thu 10/7/99 |
Fri 10/8/99 |
Creative Design Comps created, reviewed, and
signed off |
Fri 10/8/99 |
Mon 10/11/99 |
Preliminary Content Plan created, reviewed, and
signed off (if applicable) |
Wed 10/6/99 |
Wed 10/6/99 |
User Interface Prototype (optional) created,
reviewed, and signed off |
Wed 10/6/99 |
Wed 10/6/99 |
Reports Prototype (optional) created, reviewed,
and signed off |
Tue 10/12/99 |
Thu 10/14/99 |
Develop Preliminary Technology Alternatives |
Wed 10/6/99 |
Thu 10/7/99 |
Establish contact with appropriate Context
Gurus |
Tue 10/12/99 |
Wed 10/13/99 |
Preliminary Knowledge Transfer Plan &
Schedule created, reviewed, and signed off |
Wed 10/13/99 |
Wed 10/13/99 |
Validate/Invalidate Assumption from Inception
proposal |
Wed 10/13/99 |
Thu 10/14/99 |
Obtain Sign-off |
Thu 10/14/99 |
Thu 10/14/99 |
Inception Deliverables Complete |
Thu 10/14/99 |
Thu 10/14/99 |
Inception Wrap-up |
Thu 10/14/99 |
Mon 10/25/99 |
Conduct Quality Check Meeting with Client |
Thu 10/14/99 |
Thu 10/14/99 |
Conduct Quality Assurance |
Thu 10/14/99 |
Fri 10/15/99 |
Hold Context Lessons Learned Meeting |
Thu 10/14/99 |
Thu 10/14/99 |
First project estimates created, reviewed, and
signed off (+75%, -60%) |
Thu 10/14/99 |
Mon 10/18/99 |
Full Project Iterative Delivery Plan created,
reviewed, and signed off |
Mon 10/18/99 |
Tue 10/19/99 |
Create proposal for Elaboration Phase |
Thu 10/14/99 |
Fri 10/15/99 |
Create Software Project Log |
Fri 10/15/99 |
Fri 10/15/99 |
Prepare for Inception Checkpoint |
Fri 10/15/99 |
Mon 10/18/99 |
Have team, including client project manager,
complete the work release sign-off form |
Mon 10/18/99 |
Tue 10/19/99 |
Deliver proposal for Elaboration Phase |
Tue 10/19/99 |
Thu 10/21/99 |
Inception Checkpoint Review and Go/No Go
Decision |
Thu 10/21/99 |
Fri 10/22/99 |
Move appropriate deliverables from Project
Homepage to IAN Artifacts |
Fri 10/22/99 |
Mon 10/25/99 |
Inception Complete |
Mon 10/25/99 |
Mon 10/25/99 |
Phase Plan
The development of the 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 4 |
Elaboration Phase |
1 |
Week 5 |
Week11 |
Construction Phase |
3 |
Week 12 |
Week 27 |
Transition Phase |
1 |
Week 28 |
Week 31 |
The milestones that mark the end of each phase can be seen in the table
below.
Description |
Milestone |
Inception Phase |
The Inception Phase will develop the product
requirements and establish the business case for the . The major use cases
will be developed as well as the high level Project Plan. At the end of the
Inception Phase 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 and 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, are installed and available for the users. |
Iteration Objectives
Phase |
Iteration |
Description |
Associated Milestones |
Risks Addressed |
Inception |
Preliminary Iteration |
Defines business model, product requirements,
project plan, and business case. |
Business Case Review |
Clarifies user requirements up front.
Develops realistic project plans and scope.
Determines feasibility of project from a business point of view |
Elaboration Phase |
Develop Architectural Prototype |
Completes analysis & design for all use
cases. Develops the architectural prototype. |
Architectural Prototype |
Architectural issues clarified.
Technical risks mitigated.
Early prototype for user review. |
Construction Phase |
C1 Iteration – Develop Beta |
Implement and test use cases to provide the
Beta Version. |
Beta |
All key features from a user and architectural
prospective implemented in the Beta.
User feedback prior to release of software. |
|
C2 Iteration – Develop initial Release |
Implement and test remaining use cases, fix
defects from Beta, and incorporate feedback from Beta.
Develops the initial system. |
Software |
Software fully reviewed by user community.
Product quality should be high.
Defects minimized.
Cost of quality reduced. |
|
C3 Iteration – Develop full Release |
Incorporate enhancements and defects from
initial release.
Develops the full system. |
Software |
Quick release addresses customer satisfaction.
All key functionality provided in System by full Release. |
Transition phase |
Software Release |
Package, distribute, and install Release. |
Software Released |
|
Releases
At this point in time, two releases are planned. The first must be complete
in time for March Madness, and its scope will be determined during the
Elaboration Phase. Any functionality remaining will be included in a subsequent
release (if required).
Project Schedule
The preliminary project schedule can be seen in section 2.4. Updated plans
will be made available on the dates specified in that section
Project Resourcing
- Staffing Plan
The individuals on this project are provided by Context Integration and and
are named in section 3.1.
- Resource Acquisition Plan
Not Applicable.
- Training Plan
The staff assigned to this project have appropriate skills at this point. A
Knowledge Transfer Plan will be developed during the Inception Phase to ensure
that staff acquire the skills needed to support the system following the
Transition Phase.
Budget
The budget for the Inception Phase is $150,000.00. A price for the
Elaboration Phase will be developed during the Inception Phase.
Iteration Plans
This document contains the Iteration Plan for Inception. Iteration plans for
subsequent phases will be delivered at the end of the preceding phase or
iteration.
Project Monitoring and control
- Requirements management plan
See reference [1].
- Schedule control plan
Project status reports will be issued weekly and will include Milestone
Tracking detail to ensure that the project stays on track. Changes in the
schedule will be escalated to the project sponsors, who will then decide
whether to alter scope in order to preserve target completion dates.
- Budget control plan
Project status reports will be issued weekly and will include Milestone
Tracking detail to ensure that the project stays on track. Changes in the
schedule will be escalated to the project sponsors, who will then decide
whether to alter scope in order to preserve target completion dates.
- Quality control plan
Formal reviews will be executed for each design and implementation
subsystem. This will ensure that the objects under review meet the specified
requirements.
- Reporting Plan
Weekly project status reports will be issued. Phase and Iteration summary
reports will also be issued at the appropriate times.
- Measurement Plan
Effort and time will be used to track progress of the project. Planned vs.
Actual reports will be used by the project manager to measure progress.
- Risk Management plan
See reference [2].
- Close-out plan
At the end of the project, a Lessons Learned meeting will be held to
capture new techniques, tools, or methods. Project deliverables will be
archived to the Knowledge Management repository for future reference.
Development Case
See reference [3].
Methods, tools and techniques
The standard guidelines in the RUP will be used.
Infrastructure plan
This project will be developed at a Context Solution Center which has
appropriate servers and software already installed.
Product acceptance plan
To be developed.
Configuration management plan
See reference [3].
Evaluation plan
To be developed.
Documentation plan
Documents to be developed are listed in reference [3].
Quality assurance plan
See reference [3].
Problem resolution plan
To be developed.
Subcontractor management plan
N/A - no subcontractors will be used.
Process improvement plan
At completion of each phase, a Lessons Learned session will be held to
capture improvements to the process.
Copyright
© 1987 - 2001 Rational Software Corporation
|
|