Appendix A Project Plan

ORSS SOFTWARE PROJECT PLAN

GOALS AND OBJECTIVES

The Online Resource Scheduling System is a Web-based scheduling system. It is designed for colleges, universities, and schools . The purpose of this system is to provide an online service for the faculty to reserve any type of resource such as computer systems, VCRs, projectors, and videotapes. This scheduling system can accept the requestors' orders, make a schedule for the orders, and do some critical checks. It will enable faculty members to make their orders at anytime and from anyplace. The system will be able to create new orders and update old orders.

Configuration Identification: ORSS-01.

System Statement of Scope

General Requirements

The following general requirements were specified for our project titled ORSS:

• A Web-based application allowing users easy access and use
• The ability to originate or update resource reservations
• The ability to link to the faculty database to verify "authorized users"
• A method to maintain and update a resource database
• The ability to limit simultaneous reservations against total resources available
• A way to search for resources available
• A method to disallow duplication of "special" classrooms
• The ability to disallow duplicate orders from the same user
• A method to print a confirmation from the Web site
• The ability to send e-mail confirmations to the user
• The ability to print a daily list
• Database administration interface. There will be a need for the Resource Center office to maintain the database of the resources. There will also be a need to link to the faculty database to verify "authorized users." If neither of these databases exists, Global Associates will need to create them and train personnel in the maintenance and administration of both.
• Online help. We will need to develop an online help program for this system, which will include a detailed help menu and "online" telephone assistance.
• Training. We will need to conduct training for the Resource Center staff as well as all full-time faculty members. We may consider a training manual for the adjunct faculty, or conduct training sessions at times when they are available.

System Context

Multiple users will be using the product simultaneously and from many different locations. The only requirement is access to the Internet.

Major Constraints

Security

This project will be uploaded to a server and this server will be exposed to the outside world, so we need to research and develop security protection. We will need to know how to configure a firewall and how to restrict access to only "authorized users." We will need to know how to deal with load balance if the number of visits to the site is very large at one time.

Database

We will need to know how to maintain the database in order to make it more efficient, and what type of database we should use. We will also have a link to the faculty database to verify the users.

PROJECT ESTIMATES

This portion of the document provides cost, effort, and time estimates for the project using two estimation techniques: Process-Based and Lines of Code (COCOMO II model).

Historical Data Used for Estimates

We obtained the following data according to "2001 Computer Industry Salary Survey" from EDP Staffing Service Inc. for Northeast area.

Job Function : Web Developer (Java/ASP)

• Low $U.S.79,500
• Median $U.S.92,500
• High $U.S.105,500

Job Function : Sr. Database Analyst/Admin.

• Low $U.S.78,100
• Median $U.S.87,200
• High $U.S.105,900

Low is the salary paid at the 25th percentile of all respondents in this data set; median is the 50th percentile; high is the 75th percentile. Data: 2001 Computer Industry Salary Survey (EDP Staffing Service Inc.) http://www.edpstaffing.com/salary.html

We estimate labor cost per month for two Web programmers and one database analyst using the low salary level. (The low salary level is used due to the slowdown in the U.S. economy.) Note that 15 percent overhead is added in the average labor cost per month.

$(((79,500/12)*2 + (78,100/12)*1)/3) * 1.15 $7,500

Note  

Members ' roles will be discussed in Section 5.0: Project Team Organization.

Estimation Techniques Applied and Results

Two estimation techniques have been used to generate two independent results for higher accuracy.

• Process based
• Lines of code (LOC) (COCOMO II Model) (Figure A1)

  
  Figure A1: COCOMO II Model

2.2.1 Process-Based Estimation

The process is divided into smaller tasks , for process-based estimation purposes (see Table A1). We estimated, in person-months, the effort required to perform each task. We defined the following software functions:

• User interface (UI)
• Database management (DB)
• Report generation (RG)
• Bug fixing (BF)
• Program integration (PI)

Table A1: Process-Based Estimation Table

	Activity/Task
Function	Cust. Comm.	Planning	Risk Analysis	Engineering		Construction Release		Cust. Eval.	Totals
				Analysis	Design	Code	Test
UI	0.50	0.20	0.05	0.10	0.30	0.50	0.80	0.10	2.55
DB	”	0.30	0.10	0.20	0.30	0.20	0.20	”	1.30
RG	0.20	0.20	0.02	0.05	0.40	0.40	0.10	0.05	1.42
BF	0.20	0.10	0.02	0.10	0.10	0.30	0.10	0.05	0.97
PI	0.02	0.10	0.05	0.20	0.10	0.30	0.50	”	1.27
Total	0.92	0.90	0.24	0.65	1.20	1.70	1.70	0.20	7.51
% Effort	12.25	11.98	3.20	8.66	15.98	22.64	22.64	2.66	100.0

Based on the historical data we obtained, the estimated effort is approximately 7.5 person-months, and the estimated project cost is $7500 — 7.5 = $56,250 .

2.2.2 LOC-Based Estimation

The estimates in Table A2 are based on "best-effort" estimation from previous programming experiences and existing software size .

Table A2: LOC-Based Estimation

Functions		Estimated LOC
User interface	UI	1000
Database management	DB	500
Report generation	RG	500
Bug fixing	BF	500
Program integration	PI	200
Total estimated lines of codes		2700

The estimates for LOC are plugged into the COCOMO II formula for effort and duration estimation. The basic COCOMO II model is used in Table A3.

Table A3: COCOMO II Formula

Project Name ORSS
Total Size 2700
Total Effort 8.764317
Overall	Schedule (%)	Schedule (Months)	Effort (%)	Effort	Staff
Plans and requirements	16.23	1.187959	7.00	0.6135	0.516434
Product design	24.12	1.764864	17.00	1.4899	0.84422
Programming	55.53	4.063943	63.65	5.5785	1.372679
Integration and test	20.35	1.489218	19.35	1.6959	1.138782

Results in Table A3 indicate that the total effort is 8.8 person-months to finish the project. Because we have three team members, we will finish the project in approximately three months . Based on that calculation, the estimated project cost will be $7500 — 3 — 3 = $67,500 .

Project Resources

2.3.1 People

This project requires two Web developers and one database analyst in order to be finished in time. The developers must have adequate experience in Web design and have knowledge of HTML, JavaScript, Photoshop, ASP (VB Script), and Access. Experience in how to set up a Web server is preferred. The database analyst should be able to analyze, design, and maintain an efficient and secure database. The candidates must also have good personal communication skills.

2.3.2 Minimal Hardware Requirements

Development

Three IBM PC or compatibles with the following configurations:

• Intel Pentium III 700 MHz processor
• 512 MB SDRAM
• 40G hard disk space
• Internet connection

User Server-Side

IBM PC or compatible with the following configurations:

• Intel Pentium IV 1.7 GHz processor
• 512 MB SDRAM
• 80G hard disk space
• Internet connection

User Client-Side

IBM PC or compatible with the following configurations:

• Intel Pentium III 450 MHz processor
• 128 MB SDRAM
• 20 GMB hard disk space
• Internet connection

2.3.3 Minimal Software Requirements

Development

• Windows 2000 Professional Version
• FrontPage 2000 or DreamWeaver 4.0
• Microsoft Access 2000

User Server-Side

• Windows 2000 Server Version with Internet Information Server (IIS)
• Microsoft Access 2000

User Client-Side

• Windows 98 or higher operating system
• Internet Explorer browser 4.0 or Netscape Navigator 4.0

RISK MANAGEMENT

Scope and Intent of RMMM Activities

This project will be uploaded to a server and this server will be exposed to the outside world, so we need to develop security protection. We will need to configure a firewall and restrict access to only "authorized users" through the linked faculty database. We will have to know how to deal with load balance if the number of visits to the site is very large at one time.

We will need to know how to maintain the database in order to make it more efficient, what type of database we should use, who should have the responsibility to maintain it, and who should be the administrator. Proper training of the aforementioned personnel is very important so that the database and the system contain accurate information.

Risk Management Organizational Role

The software project manager must maintain a track record of the efforts and schedules of the team. They must anticipate any "unwelcome" events that might occur during the development or maintenance stages and establish plans to avoid these events or minimize their consequences.

It is the responsibility of everyone on the project team with the regular input of the customer to assess potential risks throughout the project. Communication among everyone involved is very important to the success of the project. In this way, it is possible to mitigate and eliminate possible risks before they occur. This is known as a proactive approach or strategy for risk management.

Risk Description

This section describes the risks that may occur during this project.

3.3.1 Description of Risks

• Business impact risk. This risk would entail that the software produced does not meet the needs of the client who requested the product. It would also have a business impact if the product no longer fits into the overall business strategy for the company.
• Customer characteristics risk. This risk is the customer's lack of involvement in the project and their non-availability to meet with the developers in a timely manner. Also, the customer's sophistication as to the product being developed and ability to use it are part of this risk.
• Development risk. Pressman describes this as "risks associated with the availability and quality of the tools to be used to build the product." The equipment and software provided by the client on which to run the product must be compatible with the software project being developed.
• Process definition risk. Does the software being developed meet the requirements as originally defined by the developer and client? Did the development team follow the correct design throughout the project? The above are examples of process risks.
• Product size risk. The product size risk involves the overall size of the software being built or modified. Risks involved would include the customer not providing the proper size of the product to be developed, and if the software development team misjudges the size or scope of the project. The latter problem could create a product that is too small (rarely) or too large for the client, and could result in a loss of money to the development team because the cost of developing a larger product cannot be recouped from the client.
• Staff size and experience risk. This would include appropriate and knowledgeable programmers to code the product as well as the cooperation of the entire software project team. It would also mean that the team has enough team members who are competent and able to complete the project.
• Technology risk. Technology risk could occur if the product being developed is obsolete by the time it is ready to be sold. The opposite effect could also be a factor: if the product is so "new" that the end users would have problems using the system and resisting the changes made. A "new" technological product could also be so new that there may be problems using it. It would also include the complexity of the design of the system being developed.

Risk Table

The risk table provides a simple technique to view and analyze the risks associated with the project. The risks were listed and then categorized using the description of risks listed in section 3.3.1. The probability of each risk was then estimated and its impact on the development process was then assessed. A key to the impact values and categories appears at the end of the table.

Probability and Impact for Risk

Table A4 is the sorted version of Table A3 by probability and impact.

Table A4: Risks Table (sorted)

Risks	Category	Probability (%)	Impact
Customer will change or modify requirements	PS	70	2
Lack of sophistication of end users	CU	60	3
Users will not attend training	CU	50	2
Delivery deadline will be tightened	BU	50	2
End users resist system	BU	40	3
Server may not be able to handle larger number of users simultaneously	PS	30	1
Technology will not meet expectations	TE	30	1
Larger number of users than planned	PS	30	3
Lack of training of end users	CU	30	3
Inexperienced project team	ST	20	2
System (security and firewall) will be hacked	BU	15	2
Impact values:
1 - catastrophic
2 - critical
3 - marginal
4 - negligible
Category abbreviations:
BU - business impact risk
CU - customer characteristics risk
PS - process definition risk
ST - staff size and experience risk
TE - technology risk
The above table was sorted first by probability and then by impact value.

PROJECT SCHEDULE

Following is the master schedule and deliverables planned for each stage of the project development life cycle, and their respective planned completion dates.

Deliverables and Milestones

Table A5 lists deliverables and milestones.

Table A5: Deliverables and Milestones

Activities	Deliverable	From Date	To Date	Milestone
Meetings	Weekly meetings	02/04/02	05/07/02	05/07/02
Requirements	Assess functional requirements	02/18/02	02/22/02	03/01/02
	Demonstrate system	02/19/02	02/27/02
	Evaluation of testing needs	02/25/02	02/27/02
	Assess nonfunctional requirements	02/18/02	02/27/02
	Final requirements specification	02/27/02	03/01/02
Documentation	Quality assurance plan	02/04/02	02/06/02	05/03/02
	Project plan	02/07/02	02/15/02
	Requirements document	02/18/02	03/01/02
	Design document	03/04/02	03/15/02
	User guide	04/30/02	05/02/02
	Final project notebook	04/29/02	05/03/02
	Maintenance plan	04/29/02	05/03/02
Programmer training	Web design training	03/01/02	03/07/02	03/12/02
	Database design training	03/08/02	03/12/02
Preliminary design	Brainstorming	03/13/02	03/14/02	03/20/02
	Architectural layout	03/15/02	03/20/02
Detailed design	Design user interface	03/21/02	04/01/02	04/01/02
	Database design	03/21/02	04/01/02
Coding	Build database	04/02/02	04/04/02	04/19/02
	User interface of campus version	04/05/02	04/19/02
	User interface of in-house version	04/05/02	04/19/02
Integration testing	In-house testing	04/22/02	04/26/02	04/26/02
	Necessary modifications	04/23/02	04/26/02
Post-test	On-campus testing	04/29/02	05/03/02	05/03/02
	Necessary modifications	04/30/02	05/03/02
Modification	"Clean-up" and finalized for delivery, additional "perks"	05/06/02	05/07/02	05/07/02
Faculty training	In-house training	05/08/02	05/08/02	05/10/02
	Campus training	05/09/02	05/10/02

Work Breakdown Structure

Figure A2 shows a work breakdown structure.

PROJECT TEAM ORGANIZATION

The structure of the team and the roles of the team members are defined in this section. The project team organization is divided into four parts . First is the conceptual planning phase. Second is the software design and development part. The third section is editing/master testing and maintenance. The final phase of the project is training and user documentation.

Figure A2a: Work Breakdown Structure

Figure A2b: Work Breakdown Structure (cont'd)

Team Structure

We separate part of the team project by following the responsibilities of the team members and dividing the functions of the system.

Conceptual Planning

• Interview and specify software scope
• Database reengineering
• Overall process specifications
• Draft documentation

Software Design and Development

• Database design and development
• User interface and control facilities
• Function development
• Report generation
• Draft documentation

Editing/Master Testing and Maintenance

• Maintenance system
• Integration testing
• Report software errors
• System documentation

Training and User Documentation

• Training sessions
• User documentation

This organization of the project team allows the project planner to know the area of responsibility for each team member and all of the functions of the team project.

TRACKING AND CONTROL MECHANISMS

Quality Assurance Mechanisms

• Careful monitoring of the project
• Maintaining close contact with the client using weekly meetings and regular e-mail contacts to communicate
• Having periodic status meetings in which each team member reports on his or her progress and problems
• Careful monitoring of each phase as it relates to the milestone dates listed in Chapter 4
• Paying careful attention to all of the testing results, and making changes as needed as quickly as reasonably possible and then retesting the changes

Change Management and Control

• A change request is submitted and evaluated to assess technical merit, potential side effects, overall impact on other configuration objects and system functions, and the projected cost of the change.
• An engineering change order is generated for each approved change.
• Access control and synchronization control are implemented.
• The change is made, and appropriate software quality assurance (SQA) activities are applied.
• Appropriate version control mechanisms are used to create the next version of the software.