feasibility study and project plan - school of computing...
TRANSCRIPT
S c h o o l o f C o m p u t i n g a n d I n f o r m a t i o n S c i e n c e s - F I U
Fall 10
Feasibility Study and Project Plan
Quota System
Group 7
Eduardo Pena
Vanessa Ramirez
Eduardo Tibau
CIS 4911 Senior Project
Coordinator: Prof. Peter J. Clarke
Mentor: Dr. Masoud Sadjadi
September 14, 2010
2
Abstract
As technology advances, new IT courses and learning methodologies arise. In Spring 2009 the
IT Automation course was introduced to FIU. Sponsored by Kaseya and lectured by Dr. Masoud
Sadjadi, the purpose of this course is to get students familiar with IT automation. To achieve this goal,
students have access to certain online resources. These online resources are of limited capacity making
it necessary to use an appointment system for their use. At the beginning the appointments were taken
care by hand, this turned out to be time consuming and a hard task to maintain. Later on a scheduling
system was developed to allow students to make these reservations online through Moodle. This
scheduling system provides a better user experience, but it is difficult to control a fair distribution of
these resources among users. With this problem in hand, our goal is to develop a system that will
interact with the current scheduler, and allow the administrator to define usage policies. In this
document we have analyzed the current system, and defined the user requirements at a high level.
Also, we propose three alternative solutions to the problem, along with a feasibility study of these
solutions. Finally, a project plan is presented including tasks, milestones, and deliverables.
3
Table of Contents 1. Introduction ....................................................................................................................................................................... 4
1.1. Problem definition ................................................................................................................................................... 4
1.2. Background ................................................................................................................................................................ 4
1.3. Definitions, Acronyms, and Abbreviations ...................................................................................................... 5
1.4. Overview of document ........................................................................................................................................... 6
2. Feasibility Study ................................................................................................................................................................ 7
2.1. Description of Current System ............................................................................................................................. 7
2.2. Purpose of New System ......................................................................................................................................... 7
2.3. High-level Definition of User Requirements ................................................................................................... 8
2.4. Alternative Solutions ............................................................................................................................................... 8
2.4.1. Description of Alternatives ........................................................................................................................ 8
2.4.2. Selection Criteria ........................................................................................................................................... 9
2.4.3. Analysis of Alternatives ............................................................................................................................ 11
2.5. Recommendations ................................................................................................................................................. 12
3. Project Plan....................................................................................................................................................................... 14
3.1. Project Organization ............................................................................................................................................. 14
3.1.1. Project Personnel Organization ................................................................................................................ 14
3.1.2. Hardware and Software Resources ......................................................................................................... 15
3.2. Identification of Tasks, Milestones and Deliverables ................................................................................. 16
4. Appendix ........................................................................................................................................................................... 18
4.1. Appendix A - Project schedule ........................................................................................................................... 18
4.2. Appendix B - Diary of Meetings ......................................................................................................................... 20
4.3. Appendix C – Feasibility Matrix ......................................................................................................................... 22
4.4. Appendix D – Cost Matrix .................................................................................................................................... 24
5. References ........................................................................................................................................................................ 26
4
1. Introduction
This chapter provides an introduction to the document. First, on section 1.1 a clear definition of the
problem is presented. Then, on section 1.2 an overview of the background information to allow the
reader to understand more about the problem. Finally, section 1.3 defines certain words to be used
in the document, and section 1.4 provides an overview of the different chapters of the document.
1.1. Problem definition
In the IT Automation class at FIU, students are expected to develop scripts and procedures in a
lab setting. A limited number of resources are available for this course, which primarily include
mentors and virtual labs. The latter refers to different virtual environment configurations
designed for students to solve a particular IT problem. At the moment, a system is being
developed to allow students to schedule these resources. However, the system does not
provide an efficient way to manage these resources so that all the students have a fair share.
The scheduling system gives students the freedom to reserve resources for the labs at the time
that better fits with their schedule as long as they are available. However, this freedom results
in misuse of resources as seen in previous prototypes. For instance, some students do not use
the system on a regular basis and wait until deadlines to complete the required hours for the
course. An excessive demand of requests puts a lot of pressure on the system, which cannot
provide enough resources. Another case is when students schedule resources along the
semester but do not use them all. The waste of resources is also an issue that needs to be
addressed since it is an unfair practice that affects other students.
1.2. Background
The IT Automation course was first offered in Spring 2009 at FIU (Sadjadi). Sponsored by Kaseya
and lectured by Dr. Masoud Sadjadi, this course has the objective of preparing students in the
IT management and automation field. Students are expected to learn the necessary skills to
master different IT automation tools in a lab setting.
Dr. Sadjadi has been working with graduate and undergraduate students to develop a system
that would facilitate the management of resources for the IT Automation course. The
prototypes that have been developed so far are based on Web Services. Moreover, a familiar
interface is provided through Moodle (Moodle Community), which is commonly used by IT
students at FIU. The first prototype allowed students to schedule virtual labs only. The last
5
prototype allowed students to schedule the different resources available for the course. It also
gives the administrator the capability to configure settings through the same interface. The
prototype is still in development but the expected release is on Spring 2011.
1.3. Definitions, Acronyms, and Abbreviations
IT: Information Technology.
Kaseya: Company that offers IT Systems Management Software and Network Management
Software for IT Departments and Managed Service Providers.
Resources: In this particular context, this term refers only to virtual labs, mentoring, and
certificate exams.
Virtual Lab: Different virtual environment configurations designed for students to solve a
particular IT problem.
Mentoring: Time used by teacher assistants to help students.
Certificate Exams: Virtual environments specifically for graded exam sessions.
CMS: Course Management System also known as a Learning Management System (LMS) or a
Virtual Learning Environment (VLE).
Moodle (Moodle Community): An open source CMS that educators can use to create effective
online learning sites.
JavaScript: A scripting programming language most commonly used to add interactive features
to web pages.
phpScheduleIt (Korbel): A web application written in PHP developed by Nick Korbel for
resource reservation and management.
PHP: (Hypertext Preprocessor) is a popular general-purpose server side scripting language that
can be embedded into HTML to create web applications.
Web Service: A standardized way of integrating web-based applications that share business
logic, data, and processes through a programmatic interface across a network.
6
FullCalendar (Shaw, 2010): A jQuery plugin developed by Adam Shaw, which provides a full-
sized, drag & drop calendar that uses AJAX to fetch events on-the-fly for each month and is
easily configured to use your own feed format.
jQuery: JavaScript Library that simplifies HTML document traversing, event handling,
animating, and Ajax interactions for rapid web development.
Quota: Limited time the students will have in the new system to allocate resources.
1.4. Overview of document
Chapter one provides an introduction to this document and begins with a detailed definition of
the problem. After this, background information on the problem previously described is
provided. Finally, a list of definitions, acronyms, and abbreviations used across the document is
given followed by an overview of each chapter's contents.
Chapter two contains the feasibility study conducted to determine whether a feasible solution
exists for the given problem. This chapter begins with a complete description of the current
system and its deficiencies. Next, the purpose for the new system is explained in detail, followed
by a list of the requirements given by the user as part of the possible solution. After this, a list of
alternative solutions is provided along with a brief description for each of these solutions. Then,
the criteria used to evaluate the possible solutions are explained followed by the summary of
the analysis of each solution according to the mentioned criteria. To conclude this chapter, a
recommendation is given explaining why one of these solutions is more feasible than the others.
Chapter three explains how the team plans to develop the chosen solution. It explains how
personnel are organized and what role will each team member play during the development
process. After this, a list of the resources needed to develop the solution is provided. Finally a
detailed table of tasks, milestones and deliverables shows exactly what each team member will
be doing on each phase.
Finally, chapter four contains the appendices that were used to create this document. These
appendices include a project schedule, the diary of meetings, and the feasibility matrix.
7
2. Feasibility Study
The following chapter will analyze the different possible solutions to the problem in question. First,
section 2.1 describes the current scheduling system along with its limitations and constraints. Then,
section 2.2 provides an overview of the new system and its main goals. Next, section 2.3 defines the
user requirements at a high level. Finally, section 2.4 will talk about three possible solutions to the
problem, followed by recommendations on section 2.5.
2.1. Description of Current System
Dr. Sadjadi and his research team developed the current scheduling system. This scheduling
system provides an interface through Moodle that allows students to reserve different types of
resources. The resources available at the moment include virtual labs, mentoring and
certificate exams.
The main interface of the scheduler is a JavaScript calendar, based on FullCalendar jQuery
plugin (Shaw, 2010), with all the desired scheduling functionality added to it. Students can
select for which resource they want to reserve time and schedule it on the calendar. The
calendar will show the users not only their appointments but also the availability of resources
to make the scheduling process easier.
At the moment the system doesn’t have any type of policy towards the use of resources.
Students can reserve an unlimited amount of resources, leaving other students without
available time slots. This is an unfair distribution of resources that inevitably leads to wasted
resource usage time. Furthermore, administrators don’t have access to any kind of report
about usage. Since this is the case, there is no way to prevent or penalize students with unused
allocated resources.
2.2. Purpose of New System
The purpose of the new system is to allow a fairer distribution of resources between students.
Also, the new system should give the administrator more control over the resources and their
use. The way to control these resources will be through different reports and usage policies.
Ultimately, the administrator will make sure that the students are using the resources in a fair
and efficient manner.
8
Consequently, since it will be easier to find available resources, students will have a better
experience throughout the course. They will waste less time trying to allocate the resources
they need, and will optimally have more resources available for their use.
2.3. High-level Definition of User Requirements
The high-level user requirements are the following:
1. The system shall allow the administrator to define policies about usage time, availability,
cost, and other fixed factors about each resource in a user-friendly manner.
2. The system shall provide a way to modify these policies without affecting previously
reserved time slots.
3. The system shall allow students to allocate and release resources.
4. The system shall provide students with reports about their usage of resources.
5. The system shall display the number of hours of a resource that the student can reserve.
6. The system shall allow students to request additional time on a resource (outside of their
normal quota) upon approval.
7. The system shall provide an interface with the scheduling system to check the available
quota, and the request’s compliance with the applicable policies.
2.4. Alternative Solutions
This section presents different alternative solutions for the problem stated above. Sub-section
2.4.1 contains a description of each solution and how it should be implemented. Next, sub-
section 2.4.2 presents the selection criteria on which the analysis of each of these alternatives
was based. A summary of this analysis is shown in sub-section 2.4.3.
2.4.1. Description of Alternatives
• Alternative 1: PhpScheduleIt adaptation
PhpScheduleIt is a web application written in PHP developed by Nick Korbel for
reservations and resource management (Korbel). The system includes a full user log in
and registration system, user profile management, a scheduling and reservation
system, and numerous administration tools. On the administrative side phpScheduleIt
supports a fixed group of policies that can be defined for each resource. The system
administrator can also decide what resources are available for each user. In order to
9
use phpScheduleIt as a solution for the given problem, the system will be wrapped
inside a Moodle module so it can interact with the existing system's modules. The
source code will be modified to fit user requirements and discard unwanted
functionality.
• Alternative 2: Fair scheduling algorithm
Modify the existing scheduling system to allow a fairer distribution of resources. The
new scheduler will handle a priority-based system, where a determined number of
minimum resources for each student will be considered high priority resources.
Additional resources acquired by students will have lower priorities. This way every
student will have a chance to use their high priority resources over the additional lower
priority resources of other students. Additionally there will be scheduling periods
where students will choose when to use their resources before the schedule is locked.
During this period other student’s high priority resources may replace some student’s
lower priority resources. The students whose resources were removed will have a
chance to reschedule their lower priority resources before the scheduling period ends.
Once the scheduling period is over students may only choose open time slots to spend
their resources until the next scheduling period begins.
• Alternative 3: Quota System
A new custom-made module that will interact with existing modules of the current
system. This module will work with quota or credit types instead of handling resources
directly. Each type of resource will have a value in a given type of credit. As it most
important feature, the new module will allow the creation of user designed policies to
determine whether resources should be assigned to a student. These policies can be
applied to students individually or as a group. Additionally, system administrators will
be able to give students access to additional resources should the student need them.
2.4.2. Selection Criteria
10
This sub-section describes the criteria used to evaluate each of the solutions proposed in the
previous sub-section. The following types of feasibility were considered for this analysis:
operational, technical, schedule, economic.
Operational Feasibility
• Performance
Is the solution’s throughput and response time adequate?
• Information
Do end users and administrators get timely, pertinent, accurate and usefully
formatted information?
• Control
Are there effective controls to protect against fraud and to guarantee
information accuracy and security?
• Services
Are current services reliable? Are they flexible and expandable?
• User Friendliness
Is the solution easy to use?
• Requirement Compliance
Does the solution satisfy all user requirements?
Technical Feasibility
• Expertise
Does the team possess the expertise required to develop the solution?
• Technology
Does the team possess the tools required to develop the solution?
11
Schedule Feasibility
• Preparation
How long does it take the team to learn the base system's technology?
• Design and Implementation
How long does it take to design and implement the solution?
Economic Feasibility
• Maintenance
How much does it cost to maintain the system after development is
complete?
2.4.3. Analysis of Alternatives
This sub-section contains a summary of the pros and cons involved with implementing each of
the proposed solutions based on the feasibility matrix. (Appendix C) The score associated with
each alternative is based on the sum of the score given to the alternative for each individual
criterion. This score given corresponds to a one to ten grading scale.
Table 1 phpScheduleIt adaptation score summary
Alternative 1: phpScheduleIt adaptation
Score Pros Cons
5.57
- Working system with
useful functionality.
- Useful statistical
information displayed.
- Fixed policies
- Hard to scale and
maintain.
- Hard to modify.
- Must understand complex
code.
12
Table 2 Fair scheduling algorithm score summary
Alternative 2: Fair scheduling algorithm
Score Pros Cons
7.49
- System designed to solve
problem.
- Moodle based application.
- Fixed policies.
- Not very scalable
- Must learn about current
system.
Table 3 Quota system web service score summary
Alternative 3: Quota system
Score Pros Cons
8.65
- System designed to solve
problem.
- Flexible policies.
Flexibility in scheduling.
- Moodle based application.
- Very scalable.
- More than one web service
required.
- Minor changes in existing
module.
Not optimal utilization of
resources.
2.5. Recommendations
The primary goal of the new system is to ensure fair distribution of existing resources among
students. Even though all proposed solutions achieve this primary goal, some are more flexible
in specific aspects than others.
The quota system web service solution provides the user with the most flexibility regarding
policy implementation for resource management compared to the other two alternatives,
which only allow the user to change parameters from a fixed set of policies. The quota system
also adapts to the current system without having to modify any of the existing code, while in
13
order to implement the other solutions existing code must be understood and altered. Keeping
the current system unchanged translates into students not having to learn how to use a brand
new system; instead, students will face the same familiar user interface with minor additions.
The team recommends the implementation of the new quota system web service, since it
satisfies all user requirements with a simple, scalable module, while maintaining a familiar user
interface, and providing the most flexible resource control solution.
14
3. Project Plan
This chapter describes the work plan for this project, hardware and software resources, tasks
and milestones for each deliverable. Section 3.1 described the project organization. In section
3.1.1 the team roles are defined for each member and deliverable. Section 3.1.2 describes the
software and hardware resources available to the team to develop this project. In section 3.2 a
breakdown of the project is detailed with every task and milestone for each deliverable.
3.1. Project Organization
This section will describe the roles and responsibilities of team members, and the resources
available for this project.
3.1.1. Project Personnel Organization
In this section the team roles are shown for each deliverable of the project.
Table 4 Deliverables
ID Deliverable
FS-PP Feasibility Study and Project Plan
RD Requirements Document
DD Design Document
FD Final Deliverable
Table 5 Team Roles
Team Member FS-PP RD DD FD
Eduardo Pena •Requirement
Analyst
•Technical Writer
•Requirement
Analyst
•Technical Writer
•Minute Taker
•System Analyst
Designer
•Technical Writer
•Developer
•Technical
Writer
•Minute Taker
Vanessa Ramirez •Project Manager
•Technical Writer
•Project Manager
•Requirement
Analyst
•Project Manager
•System Analyst
Designer
•Project
Manager
•Lead Tester
•Developer
15
Eduardo Tibau Requirement
Analyst
Minute Taker
Requirement
Analyst
Development
Team Manager
Development
Team Manager
Minute Taker
3.1.2. Hardware and Software Resources
This section describes the hardware and software minimum requirements for
development.
Personal computers:
Hardware Specification
Three portable computers with the following minimum specifications:
o RAM Memory: 2GB
o Hard disk space: 100GB
o Processor: Intel Core 2 Duo
o Network: 10/100 Mb/s
Software Specification
o Any operating system
o Eclipse IDE
o MS Office Suite
o AXIS2
o Apache
o PHP 5
o Java Development Kit (JDK) 1.6
o MySQL
o PostgreSQL
16
Server:
Hardware Specification
o RAM Memory: 1GB
o Hard disk space: 40GB
o Processor: Intel Core 2 Duo
o Network: 10/100 Mb/s
Software Specification
o Any operating system
o AXIS2
o Apache
o PHP 5
o Java Development Kit (JDK) 1.6
o PostgreSQL
3.2. Identification of Tasks, Milestones and Deliverables
This section describes in detail the work plan for the project including the tasks and milestones
that compose the deliverables shown in table 1. A Gantt chart was built as well to show the
project schedule (Appendix A).
Table 6 Milestones
ID Milestones Deliverable
M1 Problem statement and description FS-PP
M2 Feasibility study and Project Plan FS-PP
M3 Final document FS-PP
M4 Scope of the system, Current System problems and
limitations and Project plan
RD
M5 Proposed system requirements RD
M6 Final Document RD
M7 System methodology and design. DD
M8 Detailed design DD
M9 Final document DD
M10 Final version of FS-PP, RD and DD FD
M11 Implementation of web service FD
M12 Implementation of interface FD
17
M13 System Validation FD
M14 Final document and product FD
Table 7 Tasks
ID Task Milestone
T1 Problem statement M1
T2 Background M1
T3 Feasibility study M2
T4 Project plan M2
T5 Terminology and overview M3
T6 Integration and revision of final document M3
T7 Scope of the system M4
T8 Current System problems and limitations M4
T9 Project plan M4
T10 Functional requirements M5
T11 Analysis of system requirements M5
T12 Terminology and overview M6
T13 Integration and revision of final document M6
T14 Design methodology M7
T15 System design M7
T16 Static and Dynamic model M8
T17 Code Specification M8
T18 Terminology and overview M9
T19 Integration and revision of final document M9
T20 Final version of FS-PP document M10
T21 Final version of RD document M10
T22 Final version of DD document M10
T23 Credit Manager web service M11
T24 Policy Manager web service M11
T25 Credit Manager Moodle module M12
T26 Policy Manager Moodle module M12
T27 Policy Manager integration test M13
T28 Credit Manager integration test M13
T29 System integration test M13
T30 User guide M14
T31 Integration and revision of final document M14
18
4. Appendix
4.1. Appendix A - Project schedule
Figure 1 Project schedule
19
20
4.2. Appendix B - Diary of Meetings
Date 08/24/2010
Time 16:30 – 17:30
Location Dr. Sadjadi’s office
Attendees All members and Dr. Sadjadi
Absentees
Discussion � Brief introduction of Eduardo P. and Eduardo T. to Dr. Sadjadi.
� Description of the current issues with the scheduler, and what we need to do to
improve it.
� Talked about taking the project from a software engineering path.
Decision � Have a meeting to further discuss the problem statement on 8/26/2010.
� Vanessa has to make a draft of the problem statement since she is the one with
more knowledge of the current system and its problems.
Open issues None
Date 08/25/2010
Time 20:00 – 21:00
Location Eduardo’s house
Attendees All members
Absentees
Discussion � Prepared the problem statement for 8/26 meeting, uploaded it to basecamp
Decision None
Open issues None
Date 08/26/2010
Time 17:00 – 18:00
Location Dr. Sadjadi’s office
Attendees All members and Dr. Sadjadi
Absentees
Discussion � Continued the talk about the project, specifically about high-level user
requirement.
� Presented the problem statement to Dr. Sadjadi.
� Agreed to work 10 hours per week. On-campus meetings with Dr. Sadjadi
Tuesdays 17:00-18:00, and Wednesdays 14:30-17:00
Decision � Divide the first deliverable, and start working on it.
� Vanessa needs to work on defining the milestones for the project.
� Everyone needs to start looking for possible solutions to the problem.
Open issues None
21
Date 08/31/2010
Time 14:00 – 17:00
Location ECS 212
Attendees All members
Absentees
Discussion � Searching for alternative solutions. Found phpScheduleIt
� Coming up with two solutions to the problem. Option one, priority reservation
system, needs to modify the existing modules in order to integrate it. Option
two, quota web service system that handles credits and talks to the shopping
cart, scheduler and its own administrative interface with reports.
Decision
Open issues Try to explain our own solutions to Dr. Sadjadi to get some feedback from him.
Date 08/31/2010
Time 17:00 – 17:45
Location Dr. Sadjadi’s office
Attendees All members and Dr. Sadjadi
Absentees
Discussion � Further talk about the problem.
� Revision of the problem statement. It turned out to be fine.
� Presentation date.
Decision � Keep looking for alternatives. Select from the pool of other alternatives one
which we think is the best.
� Choose a presentation date on next class and notify Dr. Sadjadi about it.
Open issues Try to explain our own solutions to Dr. Sadjadi to get some feedback from him.
Date 09/6/2010
Time 15:00 – 22:30
Location Eduardo’s house
Attendees All members
Absentees
Discussion � Each member worked on the respective part of deliverable 1.
� Decided to make phpScheduleIt one of the alternative solutions along with our
two options.
Decision � Integrate the various parts of the document into one single file to present it.
� Make the presentation for deliverable 1
� Overview of document and terminology by Eduardo P. Due 9/10
� Ask about cost matrix, if there won’t be any costs associated with any of the 3
alternatives
Open issues Try to explain our own solutions to Dr. Sadjadi to get some feedback from him.
22
4.3. Appendix C – Feasibility Matrix Table 8 Feasibility Matrix
Feasibility
Type
Type
Wt.
Criteria Criteria
Wt.
Alternative 1 Alternative 2 Alternative 3
Observations Score Observations Score Observations Score
Operational 50% Performance 10% No web service calls
involved.
System has one database.
10 System contained within
the same web service.
System has one database.
9 System must call other
web services.
More than one database.
7
Information 10% Users and Administrators
are informed about
resource use.
Graphs and other visual
aids to view information.
10 GUI designed specifically
for this purpose.
10 GUI designed specifically
for this purpose.
10
Control 10% System manages its own
database.
9 Information contained
within existing system.
One web service.
10 Information contained
within existing system.
More than one web
service.
8
Services 10% System is fully developed.
Hard to scale.
2 Complex large system.
Hard to scale.
6 Simple separated
modules.
Very scalable.
10
User
Friendliness
20% Too many options.
Overkill of user
requirements.
Information saturated
views.
7 GUI designed to present
relevant data only.
Easy access to all required
functionalities.
10 GUI designed to present
relevant data only.
Easy access to all required
functionalities.
10
Requirement
Compliance
40% Fixed, limited policies. 6 Fixed, limited policies. 6 Flexible policy system.
Custom made to meet
user requirements.
10
Type Score 6.9 7.9 9.5
Technical 20% Expertise 70% No knowledge about PEAR
databases.
6 Medium knowledge of
Moodle based web
applications.
8 Medium knowledge of
Moodle based web
applications.
8
Technology 30% No PEAR database
manager.
8 All required tools installed. 10 All required tools installed. 10
Type Score 6.6 8.6 8.6
23
Schedule 20% Preparation 40% Complete implemented
system unknown.
2 Current scheduling system
code unknown.
Time required to learn
Moodle development.
5 Time required to learn
Moodle development.
8
Design and
Development
60% Complete implemented
system unknown.
2 Rework current design.
Complex algorithm design.
6 Start design from the
beginning.
7
Type Score 2 5.6 7.4
Economic 10% Maintenance 100% Person in charge must
know in extent system
code.
4 Person in charge must
know Moodle.
7 Person in charge must
know Moodle.
7
Type Score 4 7 7
Total Score 5.57 7.49 8.65
24
4.4. Appendix D – Cost Matrix Table 9 Personnel Costs
Alternatives Project Duration
Weeks
(10 h/w)
Personnel Total Hours Total Cost
($15 per hour)
phpScheduleIt 20 3 200 $9000
Fair Scheduling
Algorithm
25 3 250 $11250
Quota System 15 3 150 $6750
Table 10 Risks Costs
Risk Item Probability phpScheduleIt Fair Scheduling
Algorithm
Quota System
Recovery
Cost
Risk
Value
Recovery
Cost
Risk
Value
Recovery
Cost
Risk
Value
Risk 1: Personnel
could work fewer
hours than
estimated due to
sickness or personal
issues.
0.3 $450 $135 $612.5 $183.75 $350 $105
Risk 2:
Requirements could
change drastically
which could change
the system design.
0.2 $4500 $900 $6250 $1250 $3200 $640
Risk 3: Time
estimations for
deliverables could
not match the time
necessary to
complete the
project.
0.25 $5500 $1350 $7000 $1750 $4000 $1000
Total $2385 $3183.75 $1745
25
Table 11 Software and Hardware Costs (All alternative have the same costs)
Item Cost
Computers $6,490
Developer Tools (Open Source) $0
Project Management Tools (Microsoft Office 2007, MS Project) $1,100
Total $7,590
Table 12 Project Costs
Alternatives Personnel Costs Hardware and Software Risk Mitigation Total
phpScheduleIt $9000 $7,590 $2385 $18.975
Fair Scheduling
Algorithm
$11250 $7,590 $3183.75 $22023.75
Quota System $6750 $7,590 $1745 $15780
26
5. References
Korbel, N. (n.d.). Introduction to phpScheduleIt. Retrieved 08 28, 2010, from phpScheduleIt:
http://php.brickhost.com/readme.html
Moodle Community. (n.d.). About. Retrieved 08 28, 2010, from Moodle: http://moodle.org/about/
Sadjadi, M. (n.d.). it Automation Home Page. Retrieved 08 24, 2010, from S. Masoud Sadjadi's Home
Page: http://users.cis.fiu.edu/~sadjadi/
Shaw, A. (2010). FullCalendar. Retrieved from http://arshaw.com/fullcalendar/