SOFTWARE ENGINEERING

LAB 11 (W13:5/Oct/) Cover Case Study On Software Project Management Plan Automated Railway Reservation System Page 59 87 Reference: [http://www.geocities.com/cs5391/]

DELIVERABLE FOR PLANNING PHASE OF SDLC

PROJECT MANAGEMENT - PROJECT PLANNING CHECKLIST

Project Scope 1. 2. 3. 4. Are there clearly defined business goals and objectives? Y/N Are the goals and objectives in the scope section of the plan document? Y/N Have assumptions been included? Y/N Have constraints been identified? Y/N

Deliverables 1. Is there a list of all the deliverables for the project? Y/N Completion Criteria 1. Is the completion criteria clearly defined? Y/N Acceptance Criteria 1. Is the acceptance criteria clearly defined? Y/N Project Schedule (WBS) 1. Is there a clear WBS? Y/N 2. Is the project schedule structured into overview and sub-phases? Y/N 3. Are dependencies identified in the plan? Y/N 4. Are external dependencies linked to activities in the plan? Y/N 5. Are public & resource holidays identified in the schedule? Y/N 6. Is there a Gantt chart? Y/N 7. Has work effort been estimated? Y/N 8. Has task duration been estimated? Y/N 9. Has skill level of resources been taken into account? Y/N 10. Have the estimates been supplied by or validated by the resource assigned to it? Y/N 11. Has PM effort been included in the plan? Y/N 12. Have all activities been decomposed to an individual effort estimate i.e. no more than 5 days effort per activity. Y/N 13. Has the Cost Estimates (Budget) been calculated from the WBS? Y/N Milestones & Dates 1. Have key milestones & dates been identified in the plan? These are the key points at which they project will be reviewed for performance? Y/N Resources 1. Resources Resource Requirements: are named resources assigned to activities, appropriate to their skills? 2. Y/N 3. Is Resource Loading based on 5 days per week/ normal working hours? Y/N 4. Have resource requirements, hardware/additional software costs been estimated? Y/N 5. Has any necessary resource training been scheduled in to the project schedule? Y/N

6. Are resources available to the project 100%? Y/N Project Organisation: 1. Have Roles and responsibility been assigned? Y/N 2. Have you produced an Organisational Chart for the project? Y/N Plan Reviews: 1. Has the Project Plan been reviewed internally? Y/N Plan Updates: 1. Have the necessary activities to update the Project Plan/ Budget at the end of each phase been identified in the WBS? Y/N

LAB 11

Software Project Management Plan

Automated Railway Reservation System

Huitang Li Vahid Keshmiri Yasin Esmail Zaida M. Morales Natasha Dunaeva Rehan Khan November 17, 2000
Version 1.0 1.1 1.2 2.0 2.1 2.2 Changes Made First Group Review Date 9/17/00

Second Group Review 9/24/2000 CRM Review Version 10/01/2000 First Pass After Review Situation update Second Situation 10/20/2000 11/13/2000 11/17/2000

Update

Table of Contents
1. Introduction. 1.1 Project Overview. 1.2 Project Deliverables. 1.3 Evolution of the SPMP. 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 countrys railway system. Furthermore, the railroad use is expected to increase as the population grows and new railways are added. Therefore, the CRM have expressed great concern about automizing their reservation system. Currently, the train tickets can usually be purchased at the China International Travel Service (CITS) desk in major tourist hotels, through advance booking offices or foreign desks at the train stations. In order to keep up with the increasing use of the railroad system in China, the existing reservation systems needs to be refined. Thus the Chinese Railway Ministry (CRM) requests proposals to build a prototype of an Automated Railroad Reservation System (ARRS) based on their current railway system. The new ARRS needs to be scalable enough so that it can accommodate the increase in reservations caused by new railroad building in China. The proposal must express this ideology in the project plan (PP) and implement a prototype to illustrate this functionality. The PP and the prototype to be presented will be evaluated on the feasibility of the development plan and process description. However, the management approach and appropriateness to the project at hand will play an important part in the selection of the proposal. 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.

1.1 Project Overview.

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, that will be designed to provide an electronic version of the railway passenger reservation system in China. The ARRS will have a user-friendly graphical interface, and it will be cost effective compared to the current non-electronic version of the reservation system. The objectives of the development effort are as follows:

To provide existing clerks with a new environment in which to make reservations for railroad travel. To provide an avenue for customers to obtain their tickets in a more convenient way. To regain control of the railway ticket sales in order 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 refine the requirements. To collect statistics in a more efficient manner for future railroad development and construction. To increase efficiency of reservations.

Furthermore, the project is divided into major work tasks that enables to determine the phase of the project plan. The list below indicates the work activities: Problem specification Risk Analysis Design stage Implementation Testing and evaluation Quality Assurance Maintenance Project resources fall into two categories: people and equipment. People working for the ARRS include 26 professional software developers of Chinese nationality, who shall be provided by the CRM, and other 6 members from our management team. Furthermore, the CRM will also provide the necessary hardware and software for implementing the project. The ARRS system structure to be developed will include a central database to keep all reservation information, and several web servers to process all reservation transactions. Travelers will be able to obtain their tickets online through a web browser, by calling a reservation desk or a travel agency. 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 SPMP (version 1) SPMP (version 2) Software Requirement Specification Prototype One Software Development Plan High Level Design Specification High Level Function Prototype Detail Design Specification Detail Product Prototype System Construction Plan System Construction Prototype Testing and Evaluation Specification Final Product Delivery Date October 5, 2000 December 7, 2000 December 7, 2000 December 7, 2000 TBD TBD TBD TBD TBD TBD TBD TBD TBD Delivery Location Austin, TX Beijing, China Beijing, China Beijing, China TBD TBD TBD TBD TBD TBD TBD TBD Beijing, China Quantity 1 1 1 1 TBD TBD TBD TBD TBD TBD TBD TBD TBD

1.3 Evolution of the SPMP. 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. 1.4 Reference Materials. 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 Situation Update Chinese Railway Passenger Reservation System http://www.cs.swt.edu/~donshafer/Marketing%20Update(1).htm China 2000 http://www.china2thou.com/ Pressman, Roger S., Software Engineering: A Practitioners Approach, McGraw-Hill Companies, Inc., 1997. 1.5 Definitions and Acronyms. APMM AsiaPac Marketing Manager ARRS Automated Railroad Reservation System CASE Computer Aided Software Engineering 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 PMP Project Management Professional TBD To be determined UML Unified Modelling Language

2. Project Organization.
This section refers to the process model for the project and its organizational structure. 2.1 Process Model.

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

2.2 Organizational Structure. 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 2. Table 2: Project Interfaces Organization Customer: APMM Subcontractor: None Software Quality Assurance: CRM Software Configuration Management: Team 2 Liaison Don Shafer Don Shafer Don Shafer Don Shafer 86-1-5128931 cs5391@yahoo.com Contact Information 86-1-5128931

Change Control: Team 2

Don Shafer

cs5391@yahoo.com

2.4 Project Responsibilities. The project responsibilities are presented in Table 3. Table 3: Project Responsibilities. Role Project Leader Project Management Team/Analysts Description Leads project team; responsible for project deliverables Assisting in building SPMP, SRS and prototype, as well as doing the necessary requirement and risk analysis for the project Person Yasin Esmail Zaida M. Morales Vahid Keshmiri Huitang Li Natasha Dunaeva Rehan Khan Project Development Manager Programming Manager Leads Chinese software developers; responsible for project deliverables 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. 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 Responsible for designing of software and distributing work among Code Developers Responsible for writing programming code Responsible for testing and validation process in his/her team; leads Test Technician in the testing TBD

TBD

Software Managers

TBD

Development Engineers Code Developers Test Engineer

TBD TBD TBD

process and reports the results of the testing process to the software manager Test Technician Quality Assurance Manager Quality Engineer Performs the testing and validation procedure; reports found errors to Test Engineer Responsible for quality assurance; reports to Software Manager and Project Development Manager Performs quality assurance procedure; reports the results to Quality Assurance Manager TBD TBD

TBD

3. Managerial Process.
This section specifies the management process for this project. 3.1 Management Objectives and Priorities. Poor management process increases the failure rate of any project. Therefore, it is essential to establish the management objectives and priority for the ARRS. The goal of the project is to satisfy the requirements with a feasible development process that will improve the reservation process for the Chinese Railway System. 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 at reduced cost. This will be achieved by early reviews of existing or new information and implementation on a regular basis. In order to achieve the established management goals, management priorities must be rrecognized and acted upon immediately. The ARRS priorities involves delivery of the project plan and a prototype to the CRM. Therfore, gathering and analysing information must be completed in order to fully comprehend the ARRS problem domain. Furthermore, this enables flexibility in finding innovative solutions for the problem, approximate cost schedules for the ARRS and evaluate and resolve major risks. The flexibility matrix in Table 4 communicates the characteristics of the different project dimensions Table 4. Flexibility Matrix.

Project Dimension Cost Schedule Scope (functionality)

Fixed

Constrained

Flexible X

X 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. Assumptions on which the project management plan is based are as follows: Ten trains transport the passengers between three cities known as Guangzhou, Shanghai and Nanjing. These trains originate only in cities Guangzhou and Shanghai, and they make a stop at Nanjing before arriving to their destination. Five trains travel from Guangzhou to Shanghai each day and five other trains travel from Shanghai to Guangzhou each day. Two of the trains traveling from Guangzhou to Shanghai stop at Nanjing each day, and one of the trains traveling from Shanghai to Guangzhou stops at Nanjing each day. No trains originate Nanjing. 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.

are:

Dependencies, or external events, upon which the project is dependent on CRM trains occasionally may become non-operational. In that case, a new train will be dispatched, but a delay of up to a few days could occur. Scalping of tickets is a popular activity in China, and CRM wants to discourage such practices.

26 developers will be provided by the CRM as follows: 1 project manager who speaks English very well. 3 analysts, who have had extensive experience in developing applications, none speak English, all read English, and all have a fair ability to write in English. 1 Programmer/Analyst who has extensive telecommunications skills and communicates fairly well in English. 11 Programmers with 5 or more years experience in developing extensive applications. 3 of this group have excellent English communication skills. 10 Programmers with less than 5 years experience. The Ministry is extremely interested in these people receiving onthe-job training so they must be used. Only 2 of this group can communicate in English. The CRM will provide all the required hardware and software resources for the development of the project. A facilitator from CRM will help to make arrangements with government authorities, organize travel arrangements, and serve as a host to China. The telecommunications channels available in China are sufficient for the development of a feasible client server system. Three additional analysts are available from Banglore Software Development in Banglore, India. Our company hired them in case we required some form of help for the ARRS project. A software design company located in Australia is sponsored by our organization to aid if neccessary. Two documentation specialists from our company. Three field applications mangers from the Taiwan office.

Constraints, under which the project is to be conducted, are: The number of trains from city Guangzhou to Shanghai and from Shanghai to Guangzhou is limited to 5 trains. The number of passengers that can be taking a train at once is limited to 1080 passengers.

Two of the trains traveling from Guangzhou to Shanghai stop at Nanjing each day and one of the trains traveling from Guangzhou to Shanghai stops at Nanjing each day. No trains originate Nanjing.

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 have limited access to the Internet, and thus they may not be able to get to the system.

3.3 Risk Management. 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 Size of the software being very large and larger number of users than planned The software not being accepted by the CRM Cost factor involved in this project Customer requirements amy change Technology will not meet Risk Monitoring Reviewing constant feedbacks from the customers in project meetings Response from the CRM, reviewed on every project meeting Reviewing reports on expenditure and other cost related tp the estimated cost in the SPMP CRM participation in design process and reviewing feedback information in group meetings Constantly reviewing project Risk Management Being flexible in the software design to accommodate the necessary changes Early and intensive interaction with the customer for the success of project. Have additional funding allocated for it in advance and using it in case of emergencies. A new prototype will replace the previous one to accommodate the change Exploring alternatives for the

expectation Lack of training on tools and staff being inexperienced The prototype not being delivered on time

progress reports by Project Development Manager and software managers Reviewing progress report by software managers to determine the status of the project Constant reviews among team members to ensure continuous progress on the prototype

outdated technologies Providing adequate training that is necessary for the completion of the project Setting deadline 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. In addition, it is also an organizational structure and a series of activities, which help ensure a persistent high quality by product monitoring and control during the development of the software Quality Assurance (QA) includes procedures, techniques and tools used to ensure that a product meets or exceeds 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 Team 1, 2, 3 Software Manager

Management Team

Once per two weeks Every eight days

Status Report

Project Development Manager

Status Report Status Report

Programming Manager Development Engineer, Test Engineer and Quality Assurance Manager

Project Development Manager Team 1, 2, 3 Software Manager

Once a week Weekly

Progress report Status Report

Quality Software Manager and Project Weekly as needed Assurance Team Development Manager Test Technician and Code Developers Development Engineer and Test Engineer As needed

3.5 Staffing Approach. We intend to use the people recommended by the CRM for various tasks. At the moment, we dont foresee a need for any extra staffing on the project. The staffing approach for this project is as follows: Management Team Yasin, Zaida, 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. Vahid and Huitang will receive UML and CASE training in the next two weeks in USA and apply this new knowledge on this project to improve work efficiency and effectiveness. They will not go to China. However, parts of their jobs will serve as home knowledge base for client training and project plan advising. 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 approach used for the project development is an objected oriented technique, and thus, the programming language will be object oriented as well. Furthermore, Function Points will be used to track defects on the modification and maintenance. More details will be added as the Software Requirements Specification is further developed. The CASE tool and its object oriented development methodology with unified modeling language representation (UML) and instant Java code generation is used in this software development project. The manager with Project Management Professional (PMP) knowledge works closely with international marketing groups to use all the varied hardware and software capabilities within the corporation to win new international business. 4.2 Software Documentation. 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 Database Warehousing Server Implementation User Interface Design Coding Review Schema Design Review Design Review Functional Review Code Review

4.2.1 Software Requirements Specification (SRS). This requires separate documentation so 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

4.2.3 Software Test Plan. 90% of the gathered information relevant to the ARRS in the SPMP must be evaluated and fully understood. The problem domain must be explored extensively then we proceed to the SRS. 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 and verification 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 others code. This makes it easier for them to maintain the product in the future. Finally, the code reviews will be verified against the SDD to ensure that the project implementation follows the process we originally intended. Developers 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. 4.2.4 User Documentation. User documents will be uploaded online and the CRM will receive a hardcopy after the project completes. The two document specialists from our organization will prepare these documents. 4.3 Project Support Functions. The project manager is responsible for the project configuration management. Zaida is assigned the job for software quality assurance, the testers from CRM are responsible for verification and validation while Rehan and Natasha are the supervisors for planning and inspecting the verification and validation. 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 Concept Internal Case Exploration Study Communicate with CRM Initial Project SPMP Pass #1 Plan Review by CRM SPMP Pass #2 Travel & Meeting with Orientation 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 Source Code & Construction Executable Week
1 2 3 4 5 6 7 8 9 10 11 12

System Verification & Validation

System Delivery

Program Review by CRM Testing Summary Report Review by CRM Customer Acceptance Feedback System Delivery & Maintenance

5.2 Dependencies. Figure 5: Dependencies of the Main Work Packages

5.3 Resource Requirements. 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 four members of team 2, then we need 30 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 30 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. The other resource that is worth acknowledging since it may be used extensively throughtout China. The wireless resource falls in both the software and hardware categories. According to our Liason, Don Shafer,

the mobile phones have excellent reception in China, and several Chinese own these mobile units. Furthermore, the technology to have access to the internet is possible through specially designed mobile phones that support WAP structure. Therefore, we decided to use the semi-conductor fabrication plant in Taiwan to design the components that provide the support for internet access. Additionally, the cellular phone assembly plant in Guangzhou can assemble these components to be sold to the Chinese. Finally, the application design such as WML (language interpreted by the WAP technology) shall be implemented by us so that the Chinese have the ability to access the ARRS using their mobile units. 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 Development, Management Programming Team and and Software Project Managers Quality Assurance Manager and Quality Development Engineer and Code Developer Test Engineer and Test Technician

Development Engineer Manager Personnel 1 Chinese 4 Chinese 6 Chinese person (with analysts/ analysts/ English programmers programmers skills) and 4 members of team 2 Hardware Two 4 6 workstations, workstations, workstations, one per one per person one per person, and person one box for database warehouse Other

9 Chinese analysts/ programmers

6 Chinese analysts/ programmers

9 workstations, one per person

9 workstations, one per person

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, wireless equipement. 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
Project Management Team Wages for 2 months Traveling Expenses (Round Trip Air-Fare for 4 people) Traveling Expenses (Round Trip Train-Fare for 4 people) Issue Work Visa to China (Visa F Business Visa) Living Expenses (30 Days) Eating Expenses (30 Days) Software Oracle Linux Apache

Allocated Budget $39166 $6000 $240 $180 $1800 $6000 $200 $29.95 Free software available on the web

Hardware

Provided by CRM

Total
6. Additional Components.

$53,616

This section contains any additional components required for clarification of the different part of the SPMP. 6.1 Index. 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 Personnel Shortfalls Unrealistic schedules and budgets Risk Management Techniques Staffing with top talent, job matching; team building; morale building; cross training; pre-scheduling key people Detailed, multi source cost and schedule estimation; design to cost; incremental development; software reuse; requirement scrubbing

Developing the wrong Organizational analysis; mission analysis; ops-concept software functions formulation; user surveys; prototyping; early users' manuals Developing the wrong Task analysis; prototyping; scenarios; user characterization user interface (functionality, style, workload) Gold Plating Continuing stream of requirement changes Requirement scrubbing; prototyping; cost-benefit analysis; design to cost High change threshold; information hiding; incremental development (defer changes to later increments)

Shortfalls in externally Benchmarking; inspections; reference checking; compatibility furnished components analysis Shortfalls in externally Reference checking; pre-award audits; award-fee contracts; performed tasks competitive design or prototyping team building Real-time performance Simulation; benchmarking; modeling; prototyping; shortfalls instrumentation; tuning Straining computerscience 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 2 3 4 5 Identify the projects top10 risk items Present a plan for resolving each risk item Update list of top risk items, plan, and results monthly Highlight risk-item status in monthly project reviews. Compare with previous months ranking status Initiate appropriate corrective actions

D. General Information