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 |
9/17/00 |
|
1.1 |
9/24/2000 |
|
1.2 |
Third Group Review |
10/01/2000 |
|
|
|
|
|
|
|
|
|
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 railroad system currently consists of 65,000 km of rails and plans are
being developed to increase it to 70,000 km by the year 2002. It is estimated that approximately 3.7
million Chinese and foreign visitors use the country’s railway system. Railroad use is bound to increase as the
population grows and new railways are added.
At present, train tickets can usually be purchased at the China International
Travel Service (CITS) desk in major tourist hotels, or through advance booking
offices and foreign desks at the train stations. In order to keep up with the increasing use of the railroad
system in China, the current reservation systems needs to improve. The Chinese Railway Ministry (CRM) is
requesting proposals to build a prototype of an Automated Railroad Reservation
System (ARRS) for their current system.
This new ARRS needs to be scalable enough so that it can accommodate the
increase in reservations caused by new railroad building in China. The
essential and most important part of this proposal will be the Project Plan
(PP). The PP and the prototype to be
presented will be evaluated on the feasibility of the development plan and
process description. The management
approach and appropriateness to the project at hand will play an important part
in the decision. If the prototype
proves to be a feasible alternative to the needed ARRS, our team will be given
the opportunity to manage the overall development of the actual ARRS that will
be implemented throughout reservation offices in China. In the case that our plan is approved by the
CRM, the PP will be updated as the project progresses.
ARRS begins the new
journey in the development of a scalable and improved reservation system for
Chinese Railroads. The first prototype of the project is based on the
transportation of passengers between
three major cities using ten trains operating on various schedules. Several of these trains depart and arrive
from two cities after making a stop over at the third station. The objectives of
this development effort are:
·
Provide existing clerks with a new environment in which to make
reservations for railroad travel.
·
Provide an avenue for customers to get their tickets in a more effective
way.
·
Regain control of the railway ticket sales to avoid scalping and
overselling of tickets.
·
Implement a prototype of a scaled down version of the final system to
test the solution and further develop requirements.
Project resources
for the ARRS include 26 professional software developers of Chinese
nationality, which will be provided by the CRM. The CRM will also provide the necessary hardware and software for
implementing the project. Major work activities will be divided between the
members of our team and the developers provided by the CRM. The ARRS system to be developed will include
a central database to keep all reservation information and a web server to
process all reservation transactions.
Traveler will be able to get their tickets online through a web
browser or by calling a reservation desk.
There are no budget constraints for the project at this time.
The major milestone
involves building a prototype within one month of getting to China, which will
be a tough challenge. This prototype
relates to the attempt by CRM to develop a full-blown reservation system, which
unfortunately failed. The actual look and feel of the reservation system
prototype will be similar to the current online reservation system implemented
by AMTRAK at www.amtrak.com.
1.2 Project
Deliverables.
The deliverables
for this project include:
· Software
Project Management Plan (SPMP)
· Software
Requirements Specification (SRS)
· Prototype
for a scaled down version of the system that includes only 3 cities and 10
trains.
· User
Documentation.
The delivery date for the full project plan has been setup
as 7th December 2000 at 6 East Chang’an Street, Beijing,
China. The prototype and its documentation will be presented within one
month of that first meeting. The
delivery dates for the final product will be included in this document if the
CRM approves our plan and we are to manage the development of the final ARRS.
The different parts of the project will be divided among the team 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. All 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. After comments and issues are resolved, the document will be approved and a new version will be made available.
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
This section specifies the process model for the project and its organizational structure.
The ARRS project requires frequent customer and user
interaction. For that reason, our first
choice included the Prototype model. However, we had doubts about the prototype model, and therefore we concluded
to use the Spiral Model. The risk-based approach of the
Spiral Model is significant to the development of this prototype, and it would also help select an established
lifecycle model or determine a different model constructed from various phases of other lifecycle models. After regular
reviews using the risk analysis table stated in the appendix, we decided that the best approach was to use a hybrid model
that would implement the risk management of the spiral model along with the
incremental model, which is a mixture of the prototype model and the linear
sequential model. Currently, the
project revolves around two established stages: Requirement Analysis and
Prototype Development. Figure 1 shows
the life cycle for the development process as well as entry and exit criteria
for the different phases of the project.
Figure 1: Life Cycle Model
The internal management of the project, as
well as how the project relates to the rest of the organization is included in
Figure 2.
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 |
Development Manager |
Manages CRM project team |
CRM development manager |
Team Leaders |
|
|
Developers |
|
|
Testers |
|
|
3.
Managerial Process.
This section specifies the management process for this project.
3.1 Management Objectives and Priorities.
The goal of the project is to satisfy the requirements
with a feasible development process that will improve the reservation process
for the China Railway System. On time
delivery of a reliable and good quality product is the central idea of the
development process.
The flexibility matrix in Table 3
communicates the characteristics of the different project dimensions
Project Dimension |
Fixed |
Constrained |
Flexible |
Cost |
|
|
X |
Schedule |
|
X |
|
Scope (functionality) |
|
|
X |
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.
This project management plan is based on the
following assumptions:
·
Ten trains transport the passengers between three cities known as A, B
and C. These trains originate only in cities A and B, and they make a stop 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 at B before arriving at C, and similarly,
one of the five trains departing from C will arrive at A via station B. No trains originate in station B.
·
There are five classes of tickets as listed below
o Sleeping
(soft) - compartment style coaches - 4 passenger per compartment
o Sleeping
(hard) - compartment style coaches - 6 passenger per compartment
o Sitting
(soft) - typical first class coach
o Sitting
(hard) - tourist class couch
o Standing
(hard and soft sitting coaches only)
·
Reservation can be made up to one month before a particular trip
·
Seats are assigned during reservation.
·
Phone reservation involves tickets being purchased within 24 hours after
making the reservation. Otherwise, the
reservation will be cancelled.
·
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:
o 2
soft-sleeping coaches (12 compartments each)
o 2
hard-sleeping coaches (12 compartments)
o 2
soft-seating coaches (60 seats)
o 9
hard-sitting coaches (80 seats each)
·
The following management reports will be available:
o Number of
reservations made for each departure date/train
o Number of
customers turned away because of full trains for each departure/train
o Number of
no-shows for each departure
o Number and
names of people who show up without reservation for each departure
o List of
high buyers of train tickets.
·
The expected reservations during test period may amount to approximately
25,000 per day. This volume varies by
hour, day, and season.
The following
dependencies 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
affect project development.
·
Team members are restricted from bringing their own equipment, and
insufficient equipment supply may hinder project development.
· Team members are restricted to bringing only the analysts of the team to China. This might affect the project development if more people are needed or the required skills are not available.
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 don’t foresee an need for any extra
staffing on the project. We have
categorized the list of required skills as follows:
·
Software programming and
development skills in Java on a Linux/Unix operating system
·
Software testing skills:
knowledge in use of tools and knowledge about trains and reservations
· Skills in using computers and the internet to be able to test the system for errors
·
Telecommunications and network skills
· Database skills in
Oracle
· Web Server skills in Apache
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.
The work fall into seperate categories where each category involves one or more people working on it. A reference to initial computing design structure is shown in Section 4.2.2 Software Design Description (SDD) to illustrate the functionalities of the work products. The initial design requires four work products however, this is a target of constant change after every review. The work products are divided according to their different contributions to the whole project. For instance, data storage and warehousing is a different module from the server since both have different functionalities. One holds data while the other controls traffic flow and access to the database.
The table below displays the work products and the types of reviews held for each one
Table 5. Work Products and Review Schedules
Work Products |
Review |
Database Warehousing |
Schema Design Review |
Server Implementation |
Design Review |
User Interface Design |
Functional Review |
Coding |
Code Reivew |
4.2.1 Software Requirements Specification (SRS).
It is too soon to write a Software Requirement Specification (SRS) since all information must first be gathered, sorted and organized. Once the exit criteria for the SPMP is reached (90% of all information is acquired) then commencing to write an SRS document is considered. The first draft of the SRS will be available after 26th October, 2000 when the second pass of the SPMP is done.
4.2.2 Software Design Description (SDD).
The software design description can never be implemented before even beginning the SRS. However, the figure below is not a concrete software design description but it is the design structure that the group thought feasible. Furhermore, the diagram helped to determine our resource requirements and it effectively focused our thoughts and refine our ideas. Once again, this is not an established SDD for the project but a rough implementation of the project design.
Figure 3: Software Design Description
Before establishing a complete set of requirements in the SRS, 90% of the gathered information relevant to the ARRS in the SPMP must be evaluated and fully understood. The SRS can be tested in two ways. First, we can validate the SRS by cross checking it with the SPMP to ensure all identified risks are resolved and the requirments are satisfied. The second test involves the CRM fully satisfied with the SRS, and agree to proceed to the next phase of the project.
The design must satisfy the SDD since it is drawn from the SRS. Reviews of the SDD must be based on the SRS, and the test criteria includes strictly validating the SDD against the SRS. Each risk in the SRS must be confronted and shown to be resolved in the SDD. Redesign or alteration of the SDD will be implemented if unsatisfied requirements are confronted during SDD validation tests or reviews.
Each developer will be responsible for a portion
of the project. Now there are two things that are important in the coding
phase. First, the code functionality must strictly meet the SDD, and the second
agenda is the consistency of code writing for the ease of product maintainance.
Therefore, weekly code reviews shall track the progress made by individuals,
and furthermore, eradicate any undetected serious errors. In addition, there
shall be consistency in the program, and the developers will become familiar
with each others code therfore making it easier for them to maintain the
product in the future. Finally, the code reviews will be checked against the
SDD to ensure the project implementation in the right direction.
Developers work will be validated and verified to satisfy the SRS and SDD by other developers before commencing to the system functional test. Once all modules have been verified, then only will the modules be integrated together. The system check will be performed by 10 Chinese testers who will make sure that the system meets the SRS and the SDD.
User documents will be uploaded online and the CRM will receive a hardcopy after the project completes
5. Work Packages, Schedule, and Budget.
In this section, the work packages, dependency relationships, resource requirements, allocation of budget and resources to work packages, and a project schedule are specified
Major divisions in the work planned are as follows
· Database Configuration:
A central database system will be needed for the group working in China. This package identifies the need to install and administer this database. Also, the reservation system will require databases to handle all the information regarding train schedules, reservations, passengers, etc. These databases need to be installed and administered throughout the implementation phase of the project.
· Server Organization and setup
One server will host the compilers (JDK 1.3, C++ compiler) needed for the development phase, and all developers will access this server through their workstations. The Server Organization and Setup will run a Linux operating system and an apache web server. Each city shall have one or more servers depending on the population buying tickets from that city. One server per city shall result in a bottleneck problem, therefore it is desirable to reduce the traffic using several servers if necessary. This package identifies the installation of the server, as well as setting up the whole network for the group working in China. System administration functions will be addressed here.
· Java Programming:
The following two parts are recognized for this package:
-Build / Test (general coding, as well as testing of any sort are included here).
-Defect Tracking (this is a system where defects found by the testing group are recorded, and later addressed by the programmers).
· GUI Design / HTML
Due to its importance (considering Human Factors), the GUI design is identified here as a separate package.
· Administrative activities
This part regards the logistical aspect of the project. Supplies’ provision, contacts with local authorities, trip planning in China for the group members are parts of this package.
All work packages identified in the above section will be
directly dependent upon the successful completion of the first two packages
mentioned (Database configuration and Server setup).
A smooth progression of all work packages will be dependent upon the Administrative activities part. This part regards logistics while in China, as mentioned above. All other work packages can be run in parallel.
The resource requirements are divided into four separate categories, and these may be needed at different times during the lifecycle of the project. The division of resources falls into hardware and software requirements, travel, computer time and number and types of personnel.
At the initial stages of the project, we need offices, phones, fax machines and other editorial and visual programs on each workstation. This phase of the project involves the four members of team 2 refining and polishing the SRS and SDS. The time frame varies from six months to one year for a satisfactory completion of these phases since they are vital a part to the project implementation.
Furthermore, a large chunk of resource requirements mostly involves hardware and software, however, major use of these resources come into play after the project design is completed. Some of the resources required are listed below:
· A network (LAN) is required to facilitate the whole operation. This network consists of a database server, several workstations and, a build server which hosts the compilers. Refer to section 4.2.2 Software Desing Description.
· Each person will have a separate workstation. Since there are 26 Chinese employees and four members of team 2, then we need 30 workstations for each employee.
· Linux operating system for different servers and apache server programs.
These are the basic computer resources required. For a detailed explanation refer to section 5.1 Work Packages. The coding period involves the use of all hardware and software as well as 30 persons working on the project. Therefore, all resources are used at this point in time.
Travel issues for maintainance purposes will be addressed after the completion of the project. Therefore, such resource requirements come at the end of the project. However, there will be travelling done to the three different cities once the installation of the software and testing begins. Once again, such requirements fall at the later stages of the project lifecyle.
In conclusion, use of resources is limited to a minimum during the initial stages of the project. However, this increases once the coding, testing and installation processes begin. Finally, the requirement of these resources stabalizes since some amount of maintainance is expected.
Figure 4 displays the relation of the resource requirement as a function of time.
Figure 4: Approximate Resources Vs Time Graph
5.4 Budget and Resource Allocation.
Table 6: Budget and Resource Allocation Table
|
Network / Database |
Programmers |
Analysts |
Testers |
Development Manager |
Administrative Facilitator |
Personnel |
1 Chinese person(with telecommunication experience) and one member of team 2 |
11 Chinese developers with 5 years or less experience and one member of team 2 |
2 Members from team 2 (one of them is the project manager) and 3 Chinese Analysts |
10 chinese testers |
Project Manager from Team 2 |
One Chinese person who speaks both Chinese and English. |
Hardware |
Two workstations, one per person, and one box for database warehouse |
12 workstations, one per person |
3 workstations, one per Chinese Analyst |
10 workstations, one per tester |
|
None |
Software |
Oracle DBMS |
Linux operating system and apache web server JVM and C++ compilers |
Unknown at this point. This will be updated as we progress to the SRS |
Windows NT operating system |
|
None |
Other |
|
|
|
|
|
None |
Budget
Some of the basic items required for the development process, and their prices are listed below. A link shows more detailed information about the resources.
Oracle : $200
Linux : $29.95
Apache : free software available on the web
Other (prior to acceptance of
project for four people)
Hotel and Food Expenses : $13,200 for hotel expenses and $5000 for food, thus $16,200 for four people.
One way ticket to China : $2341.40 each, therefore $9365.60 for four people.
Issue work visa to China : $30 each, total $120 for visa F (Business Visa)
Schedules for the project can only be determined once the prototype is accepted by the CRM. A schedule can be made up, however, it will be an impractical and unrealistic schedule. This section can be addressed properly after the SRS is partly understood and written.
6. Additional Components.
This section contains any additional components required for clarification of the different part of the SPMP.
An index to the key terms and acronyms used throughout the SPMP will be provided in the future.
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. |
E. General Information