Project Plan
For Hotel Reservation System (HRS)
Version 1.0
Submitted in partial fulfillment of the requirements of the degree of MSE
Cem Oguzhan
CIS 895 – MSE Project
Kansas State University
1.
Task Breakdown ......................................................................................................... 3
1.1.
Inception Phase ................................................................................................... 3
1.2.
Elaboration Phase................................................................................................ 3
1.3.
Production Phase ................................................................................................. 3
2. Cost Estimate .............................................................................................................. 4
2.1.
COCOMO ........................................................................................................... 4
3. Architecture Elaboration Plan ..................................................................................... 5
3.1.
Revision of Vision Document ............................................................................. 6
3.2.
Revision of Project Plan...................................................................................... 6
3.3.
Architecture Design ............................................................................................ 6
3.4.
Development of Prototype .................................................................................. 6
3.5.
Test Plan.............................................................................................................. 6
3.6.
Formal Technical Inspections ............................................................................. 6
3.7.
Formal Requirements Specification .................................................................... 6
1. Task Breakdown
1.1. Inception Phase
The inception phase is focused on the project requirements. The phase involves developing
documentation, which will be presented during the first presentation. These documents include a
vision document, software quality assurance plan, and project plan. A vision document will
outline the project requirements. A software quality assurance plan will describe the require
documents for the project. Also, it will ensure that the quality product is developed. A project
plan will detail the phases and estimate time for the deliverables.
In the first presentation, the developer will demonstrate at least one executable prototype. The
executable prototype will display the feasibility of the project.
The inception phase will be completed once the committee members approve all required
documentation after the first presentation.
1.2. Elaboration Phase
The elaboration phase is focused on the architecture design of the system. An architecture design
will be developed to describe the product. A formal requirements specification will be developed
to describe and verify formal specification of the product. A test plan will be developed to outline
all test activities and how to report to the test results. Two technical inspectors will inspects the
architecture design artifacts and submit a formal report. The developer will demonstrate another
executable prototype in the second presentation. Also, according to committee members’ feedback
on the vision document, the software quality assurance plan, and the project plan will be revised.
The elaboration phase will be completed once the committee members approve all required
documentation after the second presentation.
1.3. Production Phase
The production phase is focused on implementation and testing of the system. Most of time, the
developer will spend time on coding. The final product will be tested according to the test plan to
ensure all requirements are meet. All test results will be analyzed and documented. Also, the
developer will write a user manual, which describes how to install, run and use the software.
The production phase will be completed once the committee members approve all required
documentation and final version of the software product after the third and the last presentation.
The grant chart below shows a schedule for finishing the tasks in each phase.
2. Cost Estimate
2.1. COCOMO
The COnstructive COst MOdel (COCOMO) developed by Barry Boehm will be used to estimate
project effort and time. There are three modes, based on software domains, to estimate project
effort and time in COCOMO. These modes are organic, semidetached and embedded. Organic
mode projects are less complex developments and it has fair flexibility. Embedded mode projects
are usually similar to defense projects. Complexity, reliability and real-time issues are played
bigger role in embedded mode projects. Semidetached mode projects represent between organic
and embedded mode projects. The Hotel Reservation System is a web application, which will
have average complexity and fair flexibility. Therefore, the Hotel Reservation System is an
organic mode project. COCOMO cost estimation for organic mode projects follow this formula:
Effort = 3.2*EAF*(Size) ^1.05
Time = 2.5*(Effort) ^0.38
where:
Effort = number of staff months
EAF = Effort Adjustment Factor
Size = number of lines of code for completed product. It is measured in KLOC (thousands of
lines of code)
Time = total number of months
The Effort Adjustment Factor is the product of the 15 adjustment parameters. Each adjustment
parameter is defined as very low, low, nominal, high, or very high. The table 1 below shows all
the adjustment factors and their ranges.
IDENTIFIER
EFFORT ADJUSTMENT FACTOR RANGE
RELY
Required reliability
0.75 - 1.40
DATA
Database size
0.94 – 1.16
CPLX
Product complexity
0.70 – 1.65
TIME
Execution time constraint
1.00 – 1.66
STOR
Main storage constraint
1.00 – 1.56
VIRT
Virtual machine volatility
0.87 – 1.30
TURN
Computer turnaround time
0.87 – 1.15
ACAP
Analyst capability
1.46 – 0.71
AEXP
Applications experience
1.29 – 0.82
PCAP
Programmer capability
1.42 – 0.70
VEXP
Virtual machine experience
1.21 – 0.90
LEXP
Language experience
1.14 – 0.95
MODP
Use of modern practices
1.24 – 0.82
TOOL
Use of software tools
1.24 – 0.83
SCED
Required development schedule
Table 1. COCOMO project characterization parameters
1.23 – 1.10
My adjustment factors as follow:
 RELY as normal and a value of 1.14.
 DATA as high and a value of 1.1.
 CPLX as normal and a value of 1.4
 TIME as normal and a value of 1.3
 STOR as low and a value of 1.1.
 VIRT as low and a value of 0.95.
 TURN as low and a value of 0.92.
 ACAP as high and a value of 0.8.
 AEXP as normal and a value of 1.0.
 PCAP as normal and a value of 1.1.
 VEXP as normal and a value of 1.0.
 LEXP as normal and a value of 1.06.
 MODP as high and a value of 0.9.
 TOOL as high and a value of 0.9
 SCED as high and a value of 1.15.
The EAF value is calculated to 1.9. I looked at similar web application examples and based on the HRS
prototype, I estimated the size to be 2400 LOC.
Effort = 3.2*1.9*(2.4) ^1.05 = 15.2 staff months
Time = 2.5*(15.2) ^0.38 = 7 months (the development time)
I think that 15.2 staff months for Effort is kind of high for a student project. The reason for that COCOMO
is generally designed for large project, which has more than one developer. This is a school project and it
has only one developer. One developer means there is no team meetings, reviews and integration of the
parts of the product. Also, the application is not depended other application. Therefore, I think that 8-9 staff
months would be more realistic value for Effort. The new development time can be calculated as:
Time = 2.5*(8.5) ^0.38 = 5.6 months
3. Architecture Elaboration Plan
The following tasks have to complete before the second presentation is given.
3.1. Revision of Vision Document
Based on the feed back provided by the committee members during the first presentation, the
vision document will be updated. The revised vision document will be submitted to the major
professor for approving.
3.2. Revision of Project Plan
Based on the feed back provided by the committee members during the first presentation, the
project plan document will be updated, which is estimation of cost and time for the project. The
revised project plan document will be submitted to the major professor for approving.
3.3. Architecture Design
The architecture of the product will be documented. UML diagrams will be used for describing
architecture of the product.
3.4. Development of Prototype
The executable prototype will be built. It will show that the requirements describe in the vision
document can be implemented.
3.5. Test Plan
A test plan will be developed to outline all test activities to ensure all requirements are satisfied
and how to report to the test results.
3.6. Formal Technical Inspections
The architecture design will be inspected by two MSE students. Those are Esteban Guillen
and Kevin Sung.
3.7. Formal Requirements Specification
OCL will be used to define and verify formal specification of the product.