Software Project Management Plan
Automated
Railway Reservation System
Huitang Li
Vahid Keshmiri
Yasin Esmail
Zaida M. Morales
Natasha Dunaeva
Rehan Khan
October
20, 2000
|
|
Changes Made |
Date |
|
1.0 |
9/17/00 |
|
|
1.1 |
9/24/2000 |
|
|
1.2 |
CRM Review Version |
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 and Schedule.
5.2 Dependencies.
5.3 Resource Requirements.
5.4 Budget and Resource Allocation.
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 goal of the project is to create a working prototype of the ARRS. The system will be designed to provide an electronic version of the railway passenger reservation system in China. The system will have a user-friendly graphical interface and will be more cost effective compared to the current non-electronic version of the reservation system.
The
objectives of this development effort are:
·
To provide existing clerks with a new environment in which to
make reservations for railroad travel.
·
To provide an avenue for customers to get their tickets in a more
convenient way.
· To
regain control of the railway ticket sales to avoid scalping and overselling of
tickets.
·
To implement a prototype of a scaled down version of the final system to
test the solution and further
develop requirements.
· To collect statistics in a more efficient manner for future railroad development and construction.
· To increase efficiency of railroads.
The major work activities for the project include:
· Problem specification
· Risk Analysis
· Design stage
· Implementation
· Testing and evaluation
· Quality Assurance
· Maintenance
Project resources
for the ARRS include 26 professional software developers of Chinese
nationality, which will be provided by the CRM, and the 6 members from our
management team. 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.
Table 1: Project Deliverables
|
Deliverable |
Delivery Date |
Delivery Location |
Quantity |
|
SPMP (version 1) |
October 5, 2000 |
Austin, TX |
1 |
|
SPMP (version 2) |
December 7, 2000 |
Beijing, China |
1 |
|
Software Requirement Specification |
December 7, 2000 |
Beijing, China |
1 |
|
Software Development Plan |
TBD |
TBD |
TBD |
|
High Level Design Specification |
TBD |
TBD |
TBD |
|
High Level Function Prototype |
TBD |
TBD |
TBD |
|
Detail Design Specification |
TBD |
TBD |
TBD |
|
Detail Product Prototype |
TBD |
TBD |
TBD |
|
System Construction Plan |
TBD |
TBD |
TBD |
|
System Construction Prototype |
TBD |
TBD |
TBD |
|
Testing and Evaluation Specification |
TBD |
TBD |
TBD |
|
Final Product |
TBD |
Beijing, China |
TBD |
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:
·
Introduction –
Chinese Railway Passenger Reservation System Prototype
http://www.cs.swt.edu/~donshafer/project_documents/5391_Case.html
· China 2000
§ Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill Companies, Inc., 1997.
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
SDS – Software Design Specification
SPMP - Software Project Management Plan
GUI – Graphical User Interface
QAM – Quality Assurance Manager
PDM – Project Development Manager
TBD – To be determined
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.
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 2.
Table 2: 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 3.
Table 3: Project
Responsibilities.
|
Role |
Description |
Person |
|
Project Leader |
Leads project team; responsible for project deliverables |
Yasin Esmail |
|
Project Management Team/Analysts |
Assisting in building SPMP, SRS and doing necessary requirement and risk analysis for the project |
Zaida M. Morales Vahid Keshmiri Huitang Li Natasha Dunaeva Rehan Khan |
|
Project Development Manager |
Leads Chinese software developers; responsible for project deliverables |
TBD |
|
Programming Manager |
Responsible for the communication between the Management Team and the rest of the software development team; the Programming Manager is also responsible for reallocating the human resources and equipment of the project. |
TBD |
|
Software Managers |
Responsible for managing the team of 7 people; does the design of the software; after reviewing reports from Test Engineer decides whether code needs to be sent back to Development Engineer for improvement or to be send to Quality Assurance Manager for quality assurance phase |
TBD |
|
Development Engineers |
Responsible for designing of software and distributing work among Code Developers |
TBD |
|
Code Developers |
Responsible for writing programming code |
TBD |
|
Test Engineer |
Responsible for testing and validation process in his/her team; leads Test Technician in the testing process and reports the results of the testing process to the software manager |
TBD |
|
Test Technician |
Performs the testing and validation procedure; reports found errors to Test Engineer |
TBD |
|
Quality Assurance Manager |
Responsible for quality assurance; reports to Software Manager and Project Development Manager |
TBD |
|
Quality Engineer |
Performs quality assurance procedure; reports the results to Quality Assurance Manager |
TBD |
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 and allow flexibility in finding creative solutions for the problem. However, quality is always the first priority and will not be compromised. The central idea of the management of this project is the on time delivery of a reliable and good quality product, along with an intensive and early exchange of ideas and concepts necessary for the successful completion of the project. This will be achieved by early reviews of existing or new information and implementation on a regular basis.
The flexibility matrix in Table 4
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.
Assumptions on which the project management
plan is based are as follows:
·
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 C 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
§
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
·
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 that accommodates
1080 passengers at a time. 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 following management reports will be available:
§
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. This volume varies by hour, day,
and season.
· Chinese Ministry will provide us with information about identification process used in China, so that it can be applied to the reservation system and scalping of tickets is avoided.
· Network connection will always remain established.
Dependencies, or
external events, upon which the project is dependent on are:
· Scalping of tickets is a popular activity in China.
·
26 developers will be provided by the CRM.
·
The number of trains from city A
to city C and from city C to city A is limited to 5 trains.
·
The number of
passengers that can be taking a train at once is limited to 1080 passengers.
·
The number of
trains that can travel from city B to city A is limited to one and the number
of trains that can travel from city A to city B is limited to two.
·
The functional
prototype should be available after 30 days upon the arrival of the management
team to China. This may prove to be a
serious time constraint on the development of a successful prototype.
·
Communication with the Chinese team members may prove
to be difficult since some Chinese developers do not speak English and the
management team does not speak Chinese.
Even with the presence of a translator, communication may be difficult.
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.
· The majority of the Chinese population does not have or have a limited access to the Internet.
Table 5 gives a detailed description of the process used to identify, analyze, and manage the risk factors associated with the project.
Table 5: Risk Management.
|
Potential Risk |
Risk Monitoring |
Risk Management |
|
Size of the software being very large and larger number of users than planned |
Reviewing constant feedbacks from the customers in project meetings |
Being flexible in the software design to accommodate the necessary changes |
|
The software not being accepted by the CRM |
Response from the CRM, reviewed on every project meeting |
Early and intensive interaction with the customer for the success of project. |
|
Cost factor involved in this project |
Reviewing reports on expenditure and other cost related factors involved in this project |
Have additional funding allocated for it in advance and using it in case of emergencies. |
|
Customer will change requirements |
CRM participation in design process and reviewing feedback information in group meetings |
A new prototype will replace the previous one to accommodate the change |
|
Technology will not meet expectation |
Constantly reviewing project progress reports by Project Development Manager and software managers |
Exploring alternatives for the outdated technologies |
|
Lack of training on tools and staff being inexperienced |
Reviewing progress report by software managers |
Providing adequate training that is necessary for the completion of the project |
|
The prototype not being delivered on time |
Constant reviews by the respective team for having correct user requirements |
A date being set before the actual time for submission of the project |
3.4 Monitoring and Controlling Mechanisms.
Reporting
Auditing Mechanism will be as follows: The Report Formatting procedure will be that it will discuss the progress of the project .How is the present phase going , it will also include the errors and difficulties that team had during that phase .In the last the future plans for the next phase of the project
Software Quality Assurance Plan
The Software Quality Assurance Plan is a proposal for the Software Quality Assurance System of the organization, an organizational structure and a series of activities that must help ensure a persistent high quality for the software developed by the Development department of the organization.
Quality Assurance (QA) consists of the procedures, techniques and tools used to ensure that a product meets or exceeds pre-specified standards during its development cycle.
The purpose of this Software Quality
Assurance Plan (SQAP) is to define the techniques, procedures, and
methodologies that will be used to assure
timely delivery of the software that meets specified requirements within
project resources.
Management
Within an organization, Quality Assurance should be carried out by an independent software quality assurance team that reports to Software Manager and project development manager The Quality Assurance team will be associated with a particular development group but also responsible for Quality Assurance across the organization. Figure 3 shows the basic management structure for software Quality Assurance.
Figure 3: Basic Management Structure
The Quality Assurance team must, in the first place, ensure the quality of the software process. So, the Quality Assurance team:
· Defines process standards such as how reviews should be conducted, and when reviews should be held;
· Monitors the development process to ensure that the standards are being followed; and
·
Reports the software process to software manager and
project development manager.
Responsibilities
The Quality Assurance team is responsible
for the development and maintenance of the product and process standards, The
QA team is responsible for proposing and establishing techniques, procedures,
and methodologies that may be effective used to assure timely delivery of the
software that meets specified requirements within project resources.
Communication and Reporting Plan
Table 6 shows the reporting and communication plan for the project. This may change as the project progresses.
Table 6:
Communication and Reporting Plan.
|
Information Communicated |
From |
To |
Time Period |
|
Project Review |
Project Development Manger |
Management Team |
Once per two weeks |
|
Status Report |
Team 1, 2, 3 Software Manager |
Project Development Manager |
Every eight days |
|
Status Report |
Programming Manager |
Project Development Manager |
Once a week |
|
Status Report |
Development Engineer, Test Engineer and Quality Assurance Manager |
Team 1, 2, 3 Software Manager |
Weekly |
|
Progress report |
Quality Assurance Team |
Software Manager and Project Development Manager |
Weekly as needed |
|
Status Report |
Test Technician and Code Developers |
Development Engineer and Test Engineer |
As needed |
We intend to use the people recommended by the CRM for various tasks. At the moment, we don’t foresee a need for any extra staffing on the project. The staffing approach for this project is as follows:
· Management Team – Yasin, Zaida, Vahid, Huitang, Natasha, Rehan.
· The Project Management Team decides who is qualified enough to be Project Development Manager among the 26 people provided by the CRM.
· The Software Manager for team 1, team 2, and team 3 and the Programming Manager is interviewed by the Project Development Manager and the Project Management Team. The Project Development Manager decides who gets to be manager of which team.
· The Software Manager of team 1, team 2, and team 3 and the Programming Manager will decide who will become Development Engineer, Test Engineer, Code Developer, and Test Technician. In the end, the Project Development Manager approves the decision.
· The Project Development Manager and the Project Management Team staff the Quality Assurance Manager and the Quality Engineer positions.
· The Project Manager gets to decide or redistribute the work force among teams in the case that any member of the team gets sick. Nevertheless, he needs to inform the Project Development Manager about it.
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. More details will be added as the Software Requirements Specification is further developed.
The work falls into separate 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.
Table 7 displays the work products and the types of reviews held for each one.
Table 7: Work Products and Review Schedules
|
Work Products |
Review |
|
Database Warehousing |
Schema Design Review |
|
Server Implementation |
Design Review |
|
User Interface Design |
Functional Review |
|
Coding |
Code Review |
4.2.1 Software Requirements Specification (SRS).
Refer to the SRS document for more information.
4.2.2 Software Design Description (SDD).
Figure 4 is not a concrete software design description, but it is the basis for the design structure that we will develop at a later time. Furthermore, the diagram helped to determine our resource requirements and it effectively focused our thoughts and refined our ideas. Once again, this is not an established SDD for the project but a rough implementation of the project design. More information will be provided during the High Level Design and Detailed Design phases.
Figure 4: 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 requirements are satisfied. The second test will occur when the CRM is fully satisfied with the SRS and agrees to proceed to the next phase of the project.
The design must satisfy the SDD, since it is based on the SRS. Reviews of the SDD must be based on the SRS, and the test criterion 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. There are two things that are important in the coding phase.
First, the code functionality must strictly meet the SDD. The second important part is the consistency
of code writing for the ease of product maintenance.
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 other’s code. This makes 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.
Developer’s work will be validated and verified to satisfy the SRS and SDD by other developers before commencing the system and functional tests. Once all modules have been verified, only then will the modules be integrated together. Ten Chinese testers, who will make sure that the system meets the SRS and the SDD, will perform the system test.
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
5.1 Work Packages and Schedule.
Table 8 shows 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.
Table 8: Work
Packages and Schedule
|
Work Packages, Tasks & Activities |
Week |
||||||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
||
|
Concept Exploration |
Internal Case Study |
|
|
|
|
|
|
|
|
|
|
|
|
|
Communicate with CRM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial Project Plan |
SPMP Pass #1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Review by CRM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SPMP Pass #2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Travel & Orientation |
Meeting with CRM Representatives |
|
|
|
|
|
|
|
|
|
|
|
|
|
Meeting with 26 programmers |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Recruiting into Organizational Chart |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OOP Training |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Initial SRS |
SRS Pass #1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Prototype 1 (Screens) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SRS Review by Team |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Final SPMP |
Pass #3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Final SRS |
SRS Review as per SPMP |
|
|
|
|
|
|
|
|
|
|
|
|
|
SRS Submission to CRM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Design |
High level Design |
|
|
|
|
|
|
|
|
|
|
|
|
|
High Level Review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prototype 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Detail Level Design |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Detail Level Review |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prototype 3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
System Construction |
Source Code & Executable Program |
|
|
|
|
|
|
|
|
|
|
|
|
|
Review by CRM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
System Verification & Validation |
Testing Summary Report |
|
|
|
|
|
|
|
|
|
|
|
|
|
Review by CRM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Customer Acceptance Feedback |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
System Delivery |
System Delivery & Maintenance |
|
|
|
|
|
|
|
|
|
|
|
|
Figure 5: Dependencies of the Main Work Packages
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 six 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 a vital part of the project implementation.
Furthermore, a large chunk of resource requirements involves hardware and software. However, major use of these resources comes 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 to host the compilers. Refer to section 4.2.2 - Software Design Description for more information.
· Each person will have a separate workstation. Since there are 26 Chinese employees and six members of team 2, then we need 32 workstations for each employee.
· A Linux operating system for different servers and apache server programs is also required.
These are the basic computer resources required. The coding period involves the use of all hardware and software, as well as 32 persons working on the project. Therefore, all resources are used at this point in time.
Travel issues for maintenance 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 traveling 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 lifecycle.
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. Close to the end of the project, the requirement of these resources stabilizes since some amount of maintenance is expected.
Figure 6 displays the relation of the resource requirement as a function of time.
Figure 6: Approximate Resources Vs Time Graph
5.4 Budget and Resource Allocation.
Table 9: Resource Allocation
|
|
Project Management Team and Project Development
Manager |
Development, Programming and Software Managers |
Quality Assurance Manager and Quality Engineer |
Development Engineer and Code Developer |
Test Engineer and Test Technician |
|
Personnel |
1 Chinese person (with English skills) and 6 members of team 2 |
4 Chinese analysts/ programmers |
6 Chinese analysts/ programmers |
9 Chinese analysts/ programmers |
6 Chinese analysts/ programmers |
|
Hardware |
Two workstations, one per person, and one box for database warehouse |
4 workstations, one per person |
6 workstations, one per person |
9 workstations, one per person |
9 workstations, one per person |
|
Other |
|
|
|
|
|
Required software for the project includes: Oracle DBMS, Linux Operating System, Apache Web Server, Sun Java Virtual Machine 1.2, Sun Java Development Kit 1.2, C/C++ Compiles, Internet Explorer or Netscape Navigator, and some version control software, such as CVS or CMVC.
Budget
Some of the basic items required for the development process, and their prices are listed in Table 10.
Table 10: Budget Allocations
|
Resource Description |
Allocated Budget |
|
Project
Management Team Wages for 2 months |
$39166 |
|
Traveling
Expenses (Round Trip Air-Fare for 6 people) |
$6000 |
|
Traveling
Expenses (Round Trip Train-Fare for 6 people) |
$240 |
|
Issue
Work Visa to China (Visa F – Business Visa) |
$180 |
|
Living
Expenses (30 Days) |
$1800 |
|
Car
Rental (30 Days) |
$1500 |
|
Eating
Expenses (30 Days) |
$6000 |
|
Software
Oracle Linux Apache |
$200 $29.95 Free software available on the web |
|
Hardware |
Provided by CRM |
|
Total |
$55,116 |
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, multi source 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 top10 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 |
D. General Information