Software Project Management Plan
Automated
Railway Reservation System
Huitang Li
Vahid Keshmiri
Yasin Esmail
Zaida M. Morales
September
17, 2000
|
Version |
Changes Made |
Date |
|
1.0 |
First Pass for Review |
9/17/00 |
|
|
|
|
Table
of Contents
1. Introduction.
1.1 Project Overview.
1.2 Project Deliverables.
1.4 Reference Materials.
1.5 Definitions and Acronyms.
2. Project Organization.
2.1 Process Model.
2.2 Organizational Structure.
2.3 Organizational Interfaces.
2.4 Project Responsibilities.
3. Managerial Process.
3.1 Management Objectives and Priorities.
3.2 Assumptions, Dependencies, and Constraints.
3.3 Risk Management.
3.4 Monitoring and Controlling Mechanisms.
3.5 Staffing Approach.
4. Technical Process.
4.1 Methods, Tools, and Techniques.
4.2 Software Documentation.
4.2.1. Software Requirements Specification (SRS).
4.2.2. Software Design Description (SDD).
4.2.3. Software Test Plan.
4.2.4. User Documentation.
4.3 Project Support Functions.
5. Work Packages, Schedule, and Budget.
5.1 Work Packages.
5.2 Dependencies.
5.3 Resource Requirements.
5.4 Budget and Resource Allocation.
5.5 Schedule.
6. Additional Components.
6.1 Index.
6.2 Appendices.
1.
Introduction.
The Chinese Railway Ministry (CRM) requests a proposal to build a prototype of an Automated Railroad Reservation System (ARRS) for their current railroad system, and a new railroad building in China. The Project Plan (PP) of the prototype will be examined on the basis of feasible development plan and process description. The overall development of the final ARRS will be maneged by our team, and the PP shall be updated as the project progresses.
The project objective involves the implementation of an ARRS prototype within one month. The project overview is based on a scenario that includes transportation of passengers to three major cities using ten trains operating on various schedules. Several of these trains depart and arrive from two cites after making a stop over at the third station. Furthermore, the ARRS project resources include 26 professional software developers of Chinese nationality, and the necessary hardware and software for implementing the project. In addition, the major milestone involves building the prototype in one month, which will be a tough challenge. Finally, this prototype relates to the attempt by CRM to develop a full-blown reservation system, which unfortunately failed. The budget for this project is unknown at this point
1.2 Project
Deliverables.
A scaled down version of the ARRS will be delivered to the CRM. The deliverables information is as follows:
§ Delivery date: 17th October 2000
§ Location: 6 East Chang’an Street Beijing China
§ Quantity: User Documents, SRS, SPMP and the prototype.
Parts of the project will be divided among the four group members, who will submit their work in a group Yahoo web account. The individual parts of the project will be checked and put together by the project manager. The changes will be reflected on the table at the beginning of this document and each version and change date will be noted. A team member will regularly review all documents. Weekly updates shall be communicated to the project manager who will immediately address these changes.
More information about the project can be found in the following documents:
§ General People’s Railroad Information
§ Railroad Building in China
§ China 2000-Railroad Building
§ The China Railways Home Page
§ The China Railways News Page
ARRS – Automated Railroad Reservation System
CITS – China International Travel Agency
CRM – Chinese Railroad Ministry
PP - Project Plan
SDD - Software Design Description
SRS - Software Requirement Specification
SPMP - Software Project Management Plan
2.
Project Organization.
This section specifies the process model for the project
and its organizational structure.
The ARRS project requires frequent user
interaction. For
that reason, our first choice included the Prototype
model. However, the Spiral model achieves the
same benefits as the Prototype model while further evaluating the major risks
involved. This
risk-based approach is significant to the development of this
prototype. Furthermore, the Spiral model also incorporates all or
most software qualities in the final product. Therefore, we concluded that the best model was to use the Spiral model for the ARRS
prototype.
Currently, the project revolves around two established stages:
Requirement Analysis and Prototype Development.
Determination of initiation and termination of each phase results in emphasis
on the entry and exit criteria. The results are as follows:
Requirment Analysis:
- Entry Criteria: CRM requests proposal for the
building of a prototype for their railway reservation system.
- Exit Criteria: 90% of all information related to ARRS
is acquired, understood, and rigorously
reviewed.
Prototype Development:
- Entry Criteria: 90% of all information is specified in the Requirements.
- Exit Criteria: the specified requirements during the entry criteria have been
met.
The internal management of the project, as well as how
the project relates to the rest of the organization
is included in Figure 2.
Figure 2:
Organization Chart
2.3 Organizational Interfaces.
The
administrative and managerial interfaces between the project and primary
entities with which it interacts are presented
in Table 1.
Table 1. Project
Interfaces
|
Organization |
Liaison |
Contact Information |
|
Customer: CRM |
Don Shafer |
86-1-5128931 |
|
Subcontractor: None |
Don Shafer |
|
|
Software Quality Assurance: CRM |
Don Shafer |
86-1-5128931 |
|
Software Configuration Management: Team 2 |
Don Shafer |
|
|
Change Control: Team 2 |
Don Shafer |
The project responsibilities are presented in Table 2.
Table
2 Project Responsibilities.
|
Role |
Description |
Person |
|
Project Manager |
leads project team; responsible for project deliverables |
Yasin Esmail |
|
Analysts/Architects |
discuss and review project requirements; frequent customer communication and authority to allocate people and resources to various stages |
Huitang Li Vahid Keshmiri Zaida M. Morales |
3.
Managerial Process.
This section specifies the management process for this
project.
3.1 Management Objectives and
Priorities.
The project objective is the satisfaction of the requirements with a feasible development process, and an on time delivery of a reliable and good quality product.
The flexibility matrix in Table 3 communicates the characteristics of the different project dimensions.
Table 3.
Flexibility Matrix.
|
Project Dimension |
Fixed |
Constrained |
Flexible |
|
Cost |
|
X |
|
|
Schedule |
X |
|
|
|
Scope (functionality) |
|
|
X |
3.2 Assumptions, Dependencies, and Constraints.
The ARRS project will be tested among three major
cities before being implemented on a larger scale. Therefore, the foundation of
the prototype must be based on several assumptions and restrictions.
Consideration for the assumptions is as follows:
· Ten trains transport the passengers between
three cities known as A, B and C. A and B are the origins and destinations of these trains. However,
other locomotives
make a stop over at B before arriving to their destination.
· Five trains leave from A and B each day. Two
of the five trains originating from A will make a stop-over at B before arriving
at C, and similarly, one of the five trains departing from C will arrive at A
via station C.
· There are five classes of tickets as listed
below
·
Sleeping (soft) - compartment style
coaches - 4 passenger per compartment
·
Sleeping (hard) - compartment style
coaches - 6 passenger per compartment
·
Sitting (soft) - typical first class
coach
·
Sitting (hard) - tourist class couch
·
Standing (hard and soft sitting coaches
only)
· Reservation can be made up to one month
before a particular trip, and seat are assigned during reservation.
· Phone reservation involves tickets being
purchased within 24 hours after making the reservation. Otherwise, the
reservation will be cancelled. In
addition, no reservations can be made 48 hours prior to the trip. Rather,
it will be done on a first come first serve basis from that point on.
· Passenger lists will be provided for
conductors at each stop.
· The trains will be assumed to be of a constant size
. They will consist of:
·
2 soft-sleeping coaches (12 compartments
each)
·
2 hard-sleeping coaches (12 compartments)
·
2 soft-seating coaches (60 seats)
·
9 hard-sitting coaches (80 seats each)
· The CRM expects several management reports.
Some reports are stated below:
·
number of reservations made for each
departure date/train
·
number of customers turned away because
of full trains for each departure/train
·
number of no-shows for each departure
·
Number and names of people who show up
without reservation for each departure
·
list of high buyers of train tickets.
· The expected
reservations during test period may amount to approximately 25,000 per day.
However, the volume varies by hour, day,and season.
Apart
from the assumptions,
several restrictions must be accounted for the development process.
Restrictions contribute to a significant portion of the ARRS prototype.
Therefore, the following constraints were evaluated:
· Communication with the Chinese team members may prove to be
difficult despite the presence of a translator. Absence of the translator may severely.
· Team members are restricted from bringing their own equipment, and
insufficient equipment supply may hinder project development.
· 26 developers will be provided. However, more may be required
for the completion of the project.
This section gives a detailed
description of the process used to identify, analyze, and manage the risk
factors associated with the project.
The results to the analysis are included.
First, identify the project risks as follows:
Deadline: The prototype must be completed within a one month period and
ready for presentation to the CRM.
Prototype not accepted: The Chinese may not be satisfied with the ARRS
prototype we present.
Skills and Hardware: One of these two or both may not be sufficient for the completion of the project.
Second, present solutions to each risk as follows:
Deadline: Frequent reviews of the requirement analysis must be done
before proceeding to build the prototype. Therefore, all team members will review the requirement analysis twice a week and the
requirements will be continuously updated. Once the exit criteria is reached for the requirement analysis (hopefully within
two weeks), we will proceed to implement the prototype.
Prototype not accepted: If the prototype
is not accepted by the CRM, then it will be applicable to Thai, Vietnamese, Kampuchean and Burmese Railroads.
Skills and Hardware: Requests for additional skills and hardware will be
made, if necessary. Otherwise, all team members will have to adjust the workload
equally among them.
The process used to identify, analyze, and resolve risks is known as the current top
10 risk chart and Software Risk Management Plan, which can be found in the appendices of this document.
3.4 Monitoring and
Controlling Mechanisms.
At the moment, the risks involved are not more than two. The first risk is of higher priority than the latter one, since it involves the completion of the prototype on time. The other risk involves the prototype being rejected by the CRM. It can also be the case that the CRM withdraws or terminates funding for this prototype. This puts a lot strain on our time and money.
Table 4 shows the reporting and communication plan for the project. This may change as the project progresses.
Table 4.
Communication and Reporting Plan.
|
Information Communicated |
From |
To |
Time Period |
|
Status report |
Project Team |
Project Manager |
Weekly |
|
Project Review |
Project Team |
Don Shafer |
Weekly |
|
Document Review |
Analysts/Architects |
Project Manager |
Weekly |
We intend to use the people recommended by the CRM for various tasks. At the moment we have categorized the list of required skills as follows:
§ software programming skills
§ software testing skills: knowledge in use of tools and knowledge about trains and reservations
§ program use training
§ design skills
§
development skills
4.
Technical Process.
This section specifies the technical methods, tools, and techniques to be used on the project. It also includes identification of the work products and reviews to be held and the plans for the support group activities in user documentation, training, software quality assurance, and configuration management.
4.1 Methods, Tools, and
Techniques.
The method to be applied to the project development leans more towards the objected oriented approach. Therefore, the programming language will be object oriented as well. Furthermore, defects on the modification and maintenance will be tracked by use of the Function Points method.
Specify the work products to be built for this project and the types of peer reviews to be held for those products. It may be useful to include a table that is adapted from the organization’s standard collection of work products and reviews. Identify any relevant style guide, naming conventions and documentation formats. In either this documentation plan or the project schedule provide a summary of the schedule and resource requirements for the documentation effort.
To ensure that the implementation of the software satisfies the requirements, the following documentation is required as a minimum:
4.2.1
Software Requirements Specification (SRS).
Refer to the SRS document.
4.2.2
Software Design Description (SDD).
Not Applicable
The Software Test Plan describes the methods to be used for testing at all levels of development and integration: requirements as expressed in the SRS, designs as expressed in the SDD, code as expressed in the implemented product. The test plan also describes the test procedures, test cases, and test results that are created during testing activities.
User documents will be uploaded online and the CRM will receive a hardcopy after the project completes
4.3 Project Support Functions.
Provide either directly or by reference, plans for the supporting functions for the software project. These functions may include, but are not limited to, configuration management, software quality assurance, and verification and validation. Plans for project support functions are developed to a level of detail consistent with the other sections of the SPMP. In particular, the responsibilities, resource requirements, schedules and budgets for each supporting function must be specified. The nature and type of support functions required will vary from project to project, however, the absence of a software quality assurance, configuration management, or, verification and validation plan must be explicitly justified in project plans that do not include them.
5.
Work Packages, Schedule, and Budget.
Specify the work packages, dependency relationships, resource requirements, allocation of budget and resources to work packages, and a project schedule. Much of the content may be in appendices that are living documents, updated as the work proceeds.
Specify the work packages for the activities and tasks that must be completed in order to satisfy the project agreement. Each work package is uniquely identified. A diagram depicting the breakdown of project activities and tasks (a work breakdown structure) may be used to depict hierarchical relationships among work packages.
Specify the ordering relations among work packages to account for interdependencies among them and dependencies on external events. Techniques such as dependency lists, activity networks, and the critical path method may be used to depict dependencies among work packages.
Provide, as a function of time, estimates of the total resources required to complete the project. Numbers and types of personnel, computer time, support software, computer hardware, office and laboratory facilities, travel, and maintenance requirements for the project resources are typical resources that should be specified.
5.4 Budget and Resource
Allocation.
Specify the allocation of budget and resources to the various project functions, activities, and tasks.
Provide the schedule for the various project functions, activities, and tasks, taking into account the precedence relations and the required milestone dates. Schedules may be expressed in absolute calendar time or in increments relative to a key project milestone.
6.
Additional Components.
Certain additional components may be required and may be appended as additional sections or subsections to the SPMP. Additional items of importance on any particular project may include subcontractor management plans, security plans, independent verification and validation plans, training plans, hardware procurement plans, facilities plans, installation plans, data conversion plans, system transition plans, or the product maintenance plan.
An index to the key terms and acronyms used throughout the SPMP is optional, but recommended to improve usability of the SPMP.
6.2 Appendices.
A. Current Top 10 Risk Chart
|
Risk Items |
Risk Management
Techniques |
|
Personnel Shortfalls |
Staffing with top talent,
job matching; team building; morale building; cross training; pre-scheduling
key people |
|
Unrealistic schedules and
budgets |
Detailed, multisource cost
and schedule estimation; design to cost; incremental development; software
reuse; requirement scrubbing |
|
Developing the wrong
software functions |
Organizational analysis;
mission analysis; ops-concept formulation; user surveys; prototyping; early
users' manuals |
|
Developing the wrong user
interface |
Task analysis; prototyping;
scenarios; user characterization(functionality, style, workload) |
|
Gold Plating |
Requirement scrubbing;
prototyping; cost-benefit analysis; design to cost |
|
Continuing stream of
requirement changes |
High change threshold;
information hiding; incremental development(defer changes to later
increments) |
|
Shortfalls in externally
furnished components |
Benchmarking; inspections;
reference checking; compatibility analysis |
|
Shortfalls in externally
performed tasks |
Reference checking;
pre-award audits; award-fee contracts; competitive design or prototyping team building |
|
Real-time performance
shortfalls |
Simulation; benchmarking;
modeling; prototyping; instrumentation; tuning |
|
Straining computer-science
capabilities |
Technical analysis;
cost-benefit analysis; prototyping; reference checking |
B. Current Project Work Breakdown
Structure
C. Current Detailed Project Schedule
D. Software Risk Management Plan
|
1. |
Identify the project's top
10 risk items. |
|
2. |
Present a plan for
resolving each risk item |
|
3. |
Update list of top risk
items, plan, and results monthly |
|
4. |
Highlight risk-item status
in monthly
project reviews. Compare with previous month's ranking status |
|
5. |
Initiate appropriate
corrective actions. |