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.
The Chinese Railroad Ministry (CRM) requests proposals to build a prototype of an automated railway reservation system (ARRS) for their current railroad system and new railroad building in China.
The project objective is to build a prototype of an automated railway reservation system for the Chinese Railroad Ministry (CRM). Its foundation must be based on a feasible development plan and process description. The 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
The deliverables are as follows:
§ Delivery date: 17th October 2000
§ Location: 6 East Chang’an Street Beijing China
§ Quantity: Unknown
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.
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
CRM – Chinese Railroad Ministry
ARRS – Automated Railroad Reservation System
PP - Project Plan
CITS – China International Travel Agency
The ARRS requires frequent user interaction, thus it would be best to use the Prototype model since it incorporates all or most software qualities in the final product. Currently, the process model includes the following stages, although this may change in the future:
· Requirement analysis
· Prototype
· Design
· Coding
· Testing
· Release
· Maintenance
Figure
1: Baseline Life Cycle
Figure 2:
Organization Chart
2.3 Organizational
Interfaces.
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 |
|
Table 2.4
Project Responsibilities.
|
Role |
Description |
Person |
|
Project Manager |
leads project team; responsible for project deliverables |
Team 2 |
|
Development |
|
CRM |
|
Analysts/Architects Project Leaders Developers/ testers |
|
Team 2 and CRM |
3.1 Management Objectives and Priorities.
A flexibility matrix might be helpful in communicating what dimensions of the project are fixed, constrained and flexible. Each degree of flexibility column can contain only one "X".
Table 3.
Flexibility Matrix.
|
Project Dimension |
Fixed |
Constrained |
Flexible |
|
Cost |
|
X |
|
|
Schedule |
X |
|
|
|
Scope (functionality) |
|
|
X |
3.2 Assumptions, Dependencies, and Constraints.
The project objectives include building a prototype, and the priorities involves the prototype meets the user specification and is has a feasible development plan under fixed schedule. The assumption are the operation of ten trains travelling between two cities. The prototype must be made around these assumptions and constraints however, the product may accommodate on a larger scale
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 prototyping being rejected by the CRM. This puts a lot strain on our time and money.
3.4 Monitoring and
Controlling Mechanisms.
Define the reporting mechanisms, report formats, review and audit mechanisms, and other tools and techniques to be used in monitoring and controlling adherence to the SPMP. Project monitoring should occur at the level of work packages. Include monitoring and controlling mechanisms for the project support functions (quality assurance, configuration management, documentation and training).
A table may be used to show the reporting and communication plan for the project. The communication table can show the regular reports and communication expected of the project, such as weekly status reports, regular reviews, or as-needed communication. The exact types of communication vary between groups, but it is useful to identify the planned means at the start of the project.
Table 4.
Communication and Reporting Plan.
|
Information Communicated |
From |
To |
Time Period |
|
Status report |
Project Team |
Project Manager |
Weekly |
|
Status report |
Project Manger |
Software Manager, Project Team |
Weekly |
|
Project Review |
Project Team |
Software Manager |
Monthly |
|
|
|
|
|
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
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.
Identify the computing system(s), development method(s), standards, policies, procedures, team structure(s), programming language(s), and other notations, tools, techniques, and methods to be used to specify, design, build, test, integrate, document, deliver, modify or maintain the project deliverables.
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).
The SRS clearly and precisely describes each of the essential requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces. Each requirement is defined such that its achievement is capable of being objectively verified and validated by a prescribed method, for example, inspection, analysis, demonstration, or test.
4.2.2 Software Design Description (SDD).
The SDD describes the major components of the software design including databases and internal interfaces.
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.
Describe how the user documentation will be planned and developed. (This may be just a reference to a plan being built by someone else.) Include work planned for online as well as paper documentation, online help, network accessible files and support facilities.
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.
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.
Appendices may be included, either directly or by reference, to provide supporting details that could detract from the SPMP if included in the body of the SPMP. Suggested appendices include:
A. Current Top 10 Risk Chart
B. Current Project Work Breakdown Structure
C. Current Detailed Project Schedule