Project Plan: For Hotel Reservation System (HRS)

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 1.23 – 1.10
Table 1. COCOMO project characterization parameters
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.

Project Plan: For Hotel Reservation System (HRS)

Uploaded by

Copyright:

Available Formats

Project Plan: For Hotel Reservation System (HRS)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Plan: For Hotel Reservation System (HRS)

Uploaded by

Copyright:

Available Formats

Project Plan

For Hotel Reservation System (HRS)

Submitted in partial fulfillment of the requirements of the degree of MSE

1.1. Inception Phase

1.2. Elaboration Phase

1.3. Production Phase

IDENTIFIER EFFORT ADJUSTMENT FACTOR RANGE

My adjustment factors as follow:

Effort = 3.21.9(2.4) ^1.05 = 15.2 staff months

Time = 2.5*(8.5) ^0.38 = 5.6 months

3. Architecture Elaboration Plan

3.2. Revision of Project Plan

3.3. Architecture Design

3.4. Development of Prototype

3.5. Test Plan

3.6. Formal Technical Inspections

3.7. Formal Requirements Specification

You might also like