Hotel Management System

SE [160701]
Hotel Management System
1. Problem Definition
1.1 Proposed System

The Hotel Reservation system will provide service to on-line customers, employee, and an
administrator. Online customers can make searches, reservations and cancel an existing
reservation on the hotel reservations web site. Administrator can add/update the hotel and the
room information approve/disapprove a new employee account application and generate a
monthly occupancy rate report for each hotel. The development of this new system contains
the following activities, which try to automate the entire process keeping in the view of
database integration approach. This system maintains users personal info, address, and
contact details. User friendliness is provided in the application with various controls provided
by system rich user interface. This system makes the overall project management much easier
and flexible. Various classes have been used for maintaining the details of all the users and
catalog. Authentication is provided for this application. Only registered users can access.
Report generation feature is provided used to generate different kind of reports. This system
is providing more memory for the users to maintain data. This system is providing
accessibility control to data with respect to users.
1.2 Existing System

The existing system uses paperwork and direct human language communication by mouth to
manage the hotel. This delays information transmission in the hotel. Booking is done through
phone calls or through visit to the hotel booking office. The guests personal details such as
Name, Age, Nationality, and Duration of stay, are input during booking in. The booking office
orders for preparation of the guests room before his/ her check in date.
The documents are transferred manually to the filling department for compilation of the
guests file. On the reporting date the file is transferred to the reception. On checking in the
guest is given the key to his allocated room, he also specify if he needs room service.
The receptionist hands over the guests file to the accountant on the next table. Here the guest
pays accommodation and meals fee. The guests file is updated on daily basis of his
expenditure costs. The accounts department generates the bills on daily basis and delivered to
the guests in their rooms at dusk by the service maids. The guest pays at the accounts desk,
where the receipts are generated. For a one meal customer the bill is generated immediately
BIT/CSE/120050131525
Page no. 1
SE [160701]
after ordering and he pays at the accountant desk before leaving. During checking out of
guests, their expenditure outlines are generated a day before check outdate.
BIT/CSE/120050131525
Page no. 2
SE [160701]
2. Requirement Specification
2.1 Functional Requirement Specification
1. Reservation/Booking
1.1. The system shall record reservations.
1.2. The system shall record the customers first name.
1.3. The system shall record the customers last name.
1.4. The system shall record the room number.
1.5. The system shall display the default room rate.
1.6. The system shall record the customers phone number.
1.7. The system shall display whether or not the room is guaranteed.
1.8. The system shall generate a unique confirmation number for each reservation.
1.9. The system shall record the expected checkout date and time.
1.10. The system shall check-in customers.
1.11. The system shall checkout customers.
1.12.
The system shall charge
the customer for an extra night if they checkout after 11:00 a.m..
1.13.
The system shall record
customer feedback.
2. Food
2.1. The system shall track all meals purchased in the hotel (restaurant and room
service).
2.2. The system shall record payment and payment type for meals.
2.3. The system shall bill the current room if payment is not made at time of
service.
2.4. The system shall accept reservations for the restaurant and room service.
3. Management
3.1. The system shall display the hotel occupancy for a specified period of time
(days; including past, present, and future dates).
3.2. The system shall display projected occupancy for a period of time (days).
3.3. The system shall display room revenue for a specified period of time (days).
3.4. The system shall display food revenue for a specified period of time (days).
3.5. The system shall display an exception report, showing where default room
and food prices have been overridden.
3.6. The system shall allow for the addition of information, regarding rooms,
rates, menu items, prices, and user profiles.
3.7. The system shall allow for the deletion of information, regarding rooms, rates,
menu items, prices, and user profiles.
3.8. The system shall allow for the modification of information, regarding rooms,
rates, menu items, prices, and user profiles.
3.9. The system shall allow managers to assign user passwords.
BIT/CSE/120050131525
Page no. 3
SE [160701]
2.2 Non-Functional Requirement Specification

1. Performance: This describes how the website behaves to a request sent in by a client.
Like suppose a client sends in a request then with what speed the website handles the
request of the client describes this.
2. Availability: The website should be available whenever a client request access. Like
at a particular instant of time if there are multiple users trying to access the site the
website should acknowledge the request of all the clients.
3. Reliability: The website should be reliable, that is it should store data correctly and
accurately whenever an input is given. Whenever data is to be stored it should be
cross-checked whether the data is stored correctly or not.
4. Security: The data that is stored securely by the website. The website should
incorporate some encryption technique in order to prevent the leakage of the website
database.
5. Data Integrity: The system should maintain data integrity that is, it should maintain
the data correctly so that data on the server side and client side remain the same.
6. User Interface: The user interface should be maintained on a medium level so that
even the clients with slow connection speeds can easily browse the website.
7. Efficiency: The website incorporates binary search tree algorithm for better
efficiency during searching of the content in the database.
8. Accessibility: The data should be controlled on the priority bases so that its access is
dependent on the priority level of the client accessing the data.
BIT/CSE/120050131525
Page no. 4
SE [160701]
3. Project Management
4.1 Effort Estimation:
COCOMO (Constructive Cost Estimation Model) was proposed by Boehm 1981. Boehm
postulated that any software development project can be classified into a one of the following
categories based on development complexity: organic, semidetached and embedded. In order
to classify a product into the identified categories, Boehm requires us to consider not only the
characteristics of the product but also of the development team and the development
environment. Roughly speaking, the three product classes correspond to application, utility
and system programs, respectively. Normally data processing programs are considered to be
application programs. Compilers, linkers etc. are utility programs. Operating systems and real
time system programs etc. are system programs. System programs interact directly with the
hardware and typically involve meeting timing constraints and concurrent processing.
Also the utility programs are three times as difficult to write as application programs and,
system programs are roughly three times as difficult as utility programs. Thus, the relative
levels of product development complexity for the three categories (application, utility and
system programs) of products are 1:3:9.
Boehms [1981] definitions of organic, semidetached and embedded systems are elaborated
as follows:
1. Organic: We can consider a development project to be of organic type, if the project

deals with developing a well understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar types of projects.
2. Semidetached: The project can be considered of this type is the development team
consists of a mixture of experienced and inexperienced staff. Team members may
have limited experience on related systems but may be unfamiliar with some aspects
of the system being developed.
BIT/CSE/120050131525
Page no. 5
SE [160701]
3. Embedded: The project can be considered of this type, is the software being
developed is strongly coupled to complex hardware, or if stringent regulations on the
operational procedures exist. Here we have chosen the embedded model since all the
team members are new in the field of the software development and also the software
product size is relatively small.
Estimation of Development Efforts
1. Organic model:
Efforts=2.4(KLOC) 1.05 Person-Months
2. Semi-Detached Model:
3. Embedded Model:
Functional Point Analysis

The idea of function points - slicing the system into smaller parts - focuses on five types of
components:
EI - external inputs, which are the components responsible for introducing changes
in system's internal data.
EO - external outputs, which are the ways system's internal data can be presented,
but beware - there are a few similarities with EQ components, though.
EQ - external inquiries, which are the methods for reading system's data without
modifying it.
EIF - external interface files, which are responsible for exchanging data with other
systems.
ILF - internal logical files, which are files that are being used by the system itself.
BIT/CSE/120050131525
Page no. 6
SE [160701]
How to perform Function Points Analysis?

Every FPA must be begun with grouping the components of the system we'd like to analyse.
That's why the five groups (listed above) are distinguished. Once the components are selected
and grouped, we can turn to analysing itself.
We need to classify the complexity of each category. We therefore have three possibilities the complexity could be low, average, or high. Then, the thing is to count the scores.
Sum the values, the total represents the number of application's function points.
Functional Point Analysis Table: [Table 1]

Functional Point Analysis
Component:
Complexity:
EI
EO
EQ
ILF
EIF
Low
Average
High
3 x 6 = 18
0
0
4x2=8
0
0
0
0
0
0
7x1=7
0
0
10 x 1 = 10
0
Total Number of Unadjusted Functional
Points
Multiple Value Adjustment Factor = 0.65 +
0.01 * DI
Total Adjusted Function Points = UFP * TCF
Degree of Influence Table:

S.No.
1
Degree Of Influence
Data communications
BIT/CSE/120050131525
Total
18
8
0
7
10
282
1.02
287.64
[Table 2]
Value
5
Page no. 7
SE [160701]
Distributed
2
3
processing
Performance
Heavily
4
5
6
7
8
9
10
11
12
13
14
configuration
Transaction rate
On-Line data entry
End-user efficiency
On-Line update
Complex processing
Reusability
Installation ease
Operational ease
Multiple sites
Facilitate change
data
2
2
used
1
4
6
0
1
1
6
0
0
5
4
Based on Functional Point Analysis our Line of Code would be: 1.25KLOC for the module.
Cocomo Model Table:
[Table 3]
Cocomo Model
Organic
Effort(PM) =
Development Time(months) =
a1 * (kloc) ^ a2
E= 2.4 * (1.25) ^ 1.05 = 3.03
b1 * (Effort) ^ b2
T = 2.5 * (3.03) ^ 0.38 = 3.81
Effort = 3.03 Person-Months

Time = 3.81 Months
4.2 Project Plan:
Gantt chart
In software project scheduling the timeline chart is created. The purpose of timeline chart is
to emphasize the scope of individual task. Hence set of tasks are given as input to the Gantt
chart.
The Gantt chart is also called as Time Line chart.
BIT/CSE/120050131525
Page no. 8
SE [160701]
The Gantt chart can be developed for entire project or it can be developed for individual
functions.
In the Gantt chart
1. All the tasks are listed at the left most columns.
2. The horizontal bars indicate the time required by the corresponding task.
3. When multiple horizontal bars occur at the same time on the calendar, then that means
concurrency can be applied for performing the tasks.
In most of projects, after generation of Gantt chart the project tables are prepared. In project
tables all the tasks are listed along with actual start and end dates and related information.
Fig. 1. [Gantt chart]
BIT/CSE/120050131525
Page no. 9
SE [160701]
4. Analysis
4.1 Procedure Oriented Approach
4.1.1 Data Flow Diagrams
0-Level DFD:-
Fig. 2. [0 Level DFD]
1-Level DFD:
Fig. 3. [1 Level DFD]
BIT/CSE/120050131525
Page no. 10
SE [160701]
BIT/CSE/120050131525
Page no. 11
SE [160701]
2-Level DFD:
Fig. 4.
BIT/CSE/120050131525
Page no. 12
SE [160701]
4.1.2 ER Diagram
BIT/CSE/120050131525
[Fig. 5]
Page no. 13
SE [160701]
4.2 Object Oriented Approach

4.2.1 Use Case Diagram
BIT/CSE/120050131525
[Fig. 6]
Page no. 14
SE [160701]
4.2.2 Class Diagram
[Fig. 7]
4.2.3 Sequence Diagram

BIT/CSE/120050131525
Page no. 15
SE [160701]
Book Room
[Fig. 8]
Payment
Fig. 8.
BIT/CSE/120050131525
Page no. 16
SE [160701]
4.2.4 Activity Diagram
BIT/CSE/120050131525
Fig. 9
Page no. 17
SE [160701]
BIT/CSE/120050131525
Page no. 18
SE [160701]
5. Designing
5.1 Data Dictionary
A database is an inherent collection of data with some inherent meanings, designed, built,
and populated with data for a specific purpose. The following guidelines are been
followed during the database design:
Descriptive names for the tables, columns and indexes
Singular names for tables and columns
Proper data type for each column

This document describes the tables that are used to design the software, its
attributes, data type, constraints, and relationship among these tables

Some of the Tables are as follows:
Table Name: Admin

Description: It stores the information of Admin.
Field Name
Data type
Description
Ad_id
Int
Primary Key
Username
nvarchar(50)
Stores the username of the

Admin
Password
nvarchar(50)
Stores the password of the

Admin
BIT/CSE/120050131525
Page no. 19
SE [160701]
Table Name: Registration

Description: It stores the information of the customer.
Field Name
Data type
Description
C_id
Int
Primary Key
email_id
nvarchar(MAX)
Stores the email id of the

user
username
nvarchar(MAX)

user
password
nvarchar(MAX)

user
phone_no
numeric(10, 0)
Stores the phone no
Table Name: Cutomer_Login

Description: It stores the information of Customer.
Field Name
Data type
Description
Ad_id
Int
Primary Key
Username
nvarchar(50)

Customer
Password
nvarchar(50)

Customer
BIT/CSE/120050131525
Page no. 20
SE [160701]
5.2 User Interface Design
Log In Page
[Fig. 10]
Register Page
[Fig. 11]
Admin Login
[Fig. 12]
BIT/CSE/120050131525
Page no. 21
SE [160701]
BIT/CSE/120050131525
Page no. 22
SE [160701]
6. Coding
6.1 Coding Standards
General coding standards pertain to how the developer writes code. The SISEPG has come
up with a small set of items it feels should be followed regardless of the programming
language being used.
a. Indentation
Proper and consistent indentation is important in producing easy to read and
maintainable programs. Indentation should be used to:
Emphasize the body of a control statement such as a loop or a select statement
Emphasize the body of a conditional statement Emphasize a new scope block
A minimum of 3 spaces shall be used to indent. Generally, indenting by three or four
spaces is considered to be adequate. Once the programmer chooses the number of
spaces to indent by, then it is important that this indentation amount be consistently
applied throughout the program. Tabs shall not be used for indentation purposes.
Examples:
/* Indentation used in a loop construct. Four spaces are used for indentation. */
for ( int i = 0 ; i < number_of_employees ; ++i )
{
total_wages += employee [ i ] . wages ;
// Indentation used in the body of a method. package

void get_vehicle_info ( )
{
System.out.println ( VIN: + vin ) ;
System.out.println ( Make: + make ) ;

System.out.println ( Model: + model ) ;
System.out.println ( Year: + year ) ; }
/* Indentation used in a conditional statement. */
IF ( IOS .NE. 0 )
WRITE ( * , 10 ) IOS
ENDIF
10
FORMAT ( Error opening log file: , I4 )
b. Inline
BIT/CSE/120050131525
Page no. 23
SE [160701]
Comments Inline comments explaining the functioning of the subroutine or key

aspects of the algorithm shall be frequently used. See section 4.0 for guidance on the
usage of inline comments.
c. Structured Programming
Structured (or modular) programming techniques shall be used. GO TO statements
shall not be used as they lead to spaghetti code, which is hard to read and maintain,
except as outlined in the FORTRAN Standards and Guidelines.
d. Classes, Subroutines, Functions, and Methods
Keep subroutines, functions, and methods reasonably sized. This depends upon the
language being used. For guidance on how large to make software modules and
methods, see section 4.0. A good rule of thumb for module length is to constrain each
module to one function or action (i.e. each module should only do one thing). If a
module grows too large, it is usually because the programmer is trying to accomplish
too many actions at one time.
The names of the classes, subroutines, functions, and methods shall have verbs in
them.
That
is
the
names
shall
specify
an
action,
e.g.
get_name,
compute_temperature.
e. Source Files
The name of the source file or script shall represent its function. All of the routines in
a file shall have a common purpose.
f. Variable Names
Variable shall have mnemonic or meaningful names that convey to a casual observer,
the intent of its use. Variables shall be initialized prior to its first use.
g. Use of Braces
In some languages, braces are used to delimit the bodies of conditional statements,
control constructs, and blocks of scope. Programmers shall use either of the following
bracing styles:
for (int j = 0 ; j < max_iterations ; ++j) {
/* Some work is done here. */ }
or the Kernighan and Ritchie style:

for ( int j = 0 ; j < max_iterations ; ++j ) {
/* Some work is done here. */
}
It is felt that the former brace style is more readable and leads to neater-looking code
than the latter style, but either use is acceptable. Whichever style is used, be sure to be
consistent throughout the code. When editing code written by another author, adopt
the style of bracing used.
BIT/CSE/120050131525
Page no. 24
SE [160701]
Braces shall be used even when there is only one statement in the control block. For
example:
Bad:
if (j == 0)
printf (j is zero.\n);
Better:
if (j == 0) {
printf (j is zero.\n); }
h. Compiler Warnings
Compilers often issue two types of messages: warnings and errors. Compiler warnings
normally do not stop the compilation process. However, compiler errors do stop the
compilation process, forcing the developer to fix the problem and recompile.
Compiler and linker warnings shall be treated as errors and fixed. Even though the
program will continue to compile in the presence of warnings, they often indicate
problems which may affect the behavior, reliability and portability of the code.
Some compilers have options to suppress or enhance compile-time warning messages.
Developers shall study the documentation and/or man pages associated with a compiler
and choose the options which fully enable the compilers code-checking features.
For example the Wall option fully enables the gcc code checking features and should
always be used:
gcc -Wall
BIT/CSE/120050131525
Page no. 25
SE [160701]
7. Testing
7.1 Test Methods
Testing is the process of running a system with the intention of finding errors.
Testing enhances the integrity of a system by detecting deviations in design and
errors in the system. Testing aims at detecting error-prone areas. This helps in
the prevention of errors in a system. Testing also adds value to the product by
conforming to the user requirements.
The main purpose of testing is to detect errors and error-prone areas in
a system. Testing must be thorough and well-planned. A partially tested system
is as bad as an untested system. And the price of an untested and under-tested
system is high.
The implementation is the final and important phase. It involves usertraining, system testing in order to ensure successful running of the proposed
system. The user tests the system and changes are made according to their
needs. The testing involves the testing of the developed system using various
kinds of data. While testing, errors are noted and correctness is the mode.
The objectives of testing are:
Testing is a process of executing a program with the intent of finding errors.
A Successful test case is one that uncovers an as- yet-undiscovered error.

The various types of testing on the system are:
1. Unit Testing.
2. Integration Testing
3. System testing
4. User Acceptance Testing
1.1. Unit Testing:

Unit testing focuses efforts on the smallest unit of software design. This is
known as module testing. The modules are tested separately. The test is carried
BIT/CSE/120050131525
Page no. 26
SE [160701]
out during programming stage itself. In this step, each module is found to be
working satisfactory as regards to the expected output from the module.
1.2. Integration Testing:
Data can be lost across an interface. One module can have an adverse
effect on another, sub functions, when combined, may not be linked in desired
manner in major functions. Integration testing is a systematic approach for
constructing the program structure, while at the same time conducting test to
uncover errors associated within the interface. The objective is to take unit
tested modules and builds program structure. All the modules are combined and
tested as a whole.
1.3. System Testing:
System testing is the stage of implementation. This is to check whether the
system works accurately and efficiently before live operation commences.
Testing is vital to the success of the system. The candidate system is subject to
a variety of tests: on line response, volume, stress, recovery, security and
usability tests. A series of tests are performed for the proposed system is ready
for user acceptance testing.
1.4. User Acceptance Testing:
User acceptance of a system is the key factor for the success of any system.
The system under consideration is tested for the user acceptance by constantly
keeping in touch with the prospective system users at the time of developing
and making changes whenever required.
BIT/CSE/120050131525
Page no. 27
SE [160701]
7.2 Special test Methods

Validation:
At the culmination of the integration testing, Software is completely
assembled as a package. Interfacing errors have been uncovered and corrected
and a final series of software test begin in validation testing. Validation testing
can be defined in many ways, but a simple definition is that the validation
succeeds when the software functions in a manner that is expected by the
customer. After validation test has been conducted, one of the three possible
conditions exists.
a) The function or performance characteristics confirm to specification and are
accepted.
b) A deviation from specification is uncovered and a deficiency lists is created.
c) Proposed system under consideration has been tested by using validation test
and found to be working satisfactory.
Output Testing:
After performing the validation testing, the next step is output testing of
the proposed system, since no system could be useful if it does not produce the
required output in a specific format. The output format on the screen is found to
be correct; the format was designed in the system design time according to the
user needs. For the hard copy also; the output comes as per the specified
requirements by the user. Hence output testing did not result in any correction
for the system.
BIT/CSE/120050131525
Page no. 28
SE [160701]
7.3 Preparation of test cases

Some Test Cases are as follows:
Test Case: Log In
[Table 6]
Sr.
Input Values
Test case
Conditional being checked
Result
No
1
Email
Empty
Please Enter valid Username
Successfu
Email
Already
Login ID should be unique
l
Successfu
Password
Exists or not
Empty
Please Enter valid Password
l
Successfu
Password
If
Password
Password
Length
l
Successfu
wrong Enter Password
l
Length should be less than Successfu
or equal to 10 character
Test Case: Registration
[Table 7]
Sr.
Input Values
Test case
Conditional being checked
Result
No
1.
First Name
Empty
It must not be empty
Successfu
Last Name
Empty
Last Name must not be empty
l
Successfu
Email
Empty
Enter valid Email ID.
l
Successfu
Password
Empty
Enter valid Password.
l
Successfu
Minimum 8 characters required
l
Successfu
Password
Length
Confirm
Empty
Password
Password
Date Of Birth
Select
password must be same

Enter valid Username
Password.
BIT/CSE/120050131525
and
l
confirmation Successfu
l
and Successfu
l
Page no. 29
SE [160701]
8. Conclusion & Future Enhancement
Conclusion:
By developing this application we conclude that each and every step of software development
life cycle is very important in order to develop good application.
Also referring to various process models is a great help as it helps us to choose the best one
according to our requirements.
Future Enhancement:
The project is very dynamic in itself and is not limited to a handful of features. If in the future
this project can be taken as a basis for implementation on a large scale, it would not be that
difficult to enhance its functionalities. Many more features could be added to it which can
make it one of the very few and technically advanced college communication social system
being designed.
BIT/CSE/120050131525
Page no. 30
SE [160701]
References
www.SoftwareMetrics.Com
NOAA National Weather Service NWS/OHD General Software Coding Standards and
Guidelines
www.arpitchauhan90files.com
BIT/CSE/120050131525
Page no. 31
SE [160701]
Appendix I
Short form Used:
CSE: Computer Science & Engineering.
SE: Software Engineering
SRS: Software Requirement Specification.
ID: Identity.
I/P: Input.
O/P: Output.
COCOMO: COnstructive COst estimation MOdel.
LOC: Line Of Code.
KLOC: Line Of Code in Kilos.
DFD: Data Flow Diagram.
E-R Diagram: Entity-Relationship Diagram.
UML: Unified Modelling Language.
BIT/CSE/120050131525
Page no. 32
SE [160701]
Appendix II
Study of various Software Development Models
(a) There are basically five types of models. They are as follow:
1. Waterfall Model
The Waterfall Model The waterfall model is the classical model of software engineering. This
model is one of the oldest models and is widely used in government projects and in many
major companies. As this model emphasizes planning in early stages, it ensures design flaws
before they develop. In addition, its intensive document and planning make it work well for
projects in which quality control is a major concern.
The pure waterfall lifecycle consists of several non-overlapping stages, as shown in the
following figure. The model begins with establishing system requirements and software
requirements and continues with architectural design, detailed design, coding, testing, and
maintenance. The waterfall model serves as a baseline for many other lifecycle models.
Requirements &
Analysis
System Design
Class Design
Implementation
Testing
Deployment
Maintenance
[Fig. 13]
BIT/CSE/120050131525
Page no. 33
SE [160701]
1. Requirements & Analysis: Establishes the components for building the system, including
the hardware requirements, software tools, and other necessary components. Also establishes
the expectations for software functionality and identifies which system requirements the
software affects. Requirements analysis includes determining interaction needed with other
applications and databases, performance requirements, user interface requirements, and so on.
2. System design: Determines the software framework of a system to meet the specific
requirements. This design defines the major components and the interaction of those
components, but it does not define the structure of each component. The external interfaces
and tools used in the project can be determined by the designer.
3. Class design: Examines the software components defined in the architectural design stage
and produces a specification for how each component is implemented.
4. Implementation: Implements the detailed design specification by writing actual code.
5. Testing: Determines whether the software meets the specified requirements and finds any
errors present in the code.
6. Deployment: System is deployed on various platforms and in various configuration.
Unexpected interactions can occur in the customer environment which are to be resolved.
7. Maintenance: Addresses problems and enhancement requests after the software releases.
Advantages:
1. Easy to understand and implement.
2. Widely used and known.
3. Reinforces good habits: define-before- design, design-before-code.
4. Works well on mature products and weak teams.
Disadvantages:
1. Idealized doesnt match reality well.
2. Doesnt reflect iterative nature of exploratory development.
3. Software is delivered late in project, delays discovery of serious errors.
4. Difficult and expensive to make changes to documents.
2. Iterative Development
BIT/CSE/120050131525
Page no. 34
SE [160701]
The problems with the Waterfall Model created a demand for a new method of developing
systems which could provide faster results, require less up-front information, and offer
greater flexibility. With Iterative Development, the project is divided into small parts. This
allows the development team to demonstrate results earlier on in the process and obtain
valuable feedback from system users. Often, each iteration is actually a mini-Waterfall
process with the feedback from one phase providing vital information for the design of the
next phase. In a variation of this model, the software products, which are produced at the end
of each step (or series of steps), can go into production immediately as incremental releases.
[Fig. 14]
Requirements
Defination
System & Software
Design
Implementation &
Unit Testing
Integration & System
Testing
Operation &
Maintenance
Advantage:
1. We can only create a high-level design of the application before we actually begin to
build the product and define the design solution for the entire product.
2. We are building and improving the product step by step. Hence we can track the defects
at early stages.
3. We can get the reliable user feedback.
Disadvantage:
1. Each phase of an iteration is rigid with no overlaps.
2. Costly system architecture or design issues may arise because not all requirements are
gathered up front for the entire lifecycle.
3. Spiral Model
BIT/CSE/120050131525
Page no. 35
SE [160701]
The spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral.
Requirements are gathered during the planning phase. In the risk analysis phase, a process is
undertaken to identify risk and alternate solutions. A prototype is produced at the end of the
risk analysis phase. Software is produced in the engineering phase, along with testing at the
end of the phase. The evaluation phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral. In the spiral model, the angular
component represents progress, and the radius of the spiral represents cost.
[Fi
Final
Project
Requireme
nts
Indentifcat
ion
Testing &
Evaluation
Start Here
Design
Implementa
tion
g. 15]
Advantages:
1. High amount of risk analysis.
2. Good for large and mission-critical projects.
3. Software is produced early in the software life cycle.
Disadvantages:
BIT/CSE/120050131525
Page no. 36
SE [160701]
1. Can be a costly model to use.

2. Risk analysis requires highly specific expertise.
3. Projects success is highly dependent on the risk analysis phase.
4. Doesnt work well for smaller projects
4. Evolutionary model
This life cycle is also referred as the successive versions model and sometimes as the
incremental model. In incremental model the whole requirement is divided into various
builds. Multiple development cycles take place here, making the life cycle a multi-waterfall
cycle. Cycles are divided up into smaller, more easily managed modules. Each module
passes through the requirements, design, implementation and testing phases. A working
version of software is produced during the first module, so you have working software early
on during the software life cycle. Each subsequent release of the module adds function to the
Requirem ents
previous release. The process continues till the complete system is achieved.
Build 1
Design &
Development
Build
2
Design
&
Development
Build
N
Design
&
Development
Testing
Implementatio
n
Testing
Implementatio
n
Testing
Implementatio
n
[Fig. 16]
Advantages:
1. Generates working software quickly and early during the software life cycle.
2. This model is more flexible less costly to change scope and requirements.
3. It is easier to test and debug during a smaller iteration.
4. Lowers initial delivery cost.
Disadvantages:
BIT/CSE/120050131525
Page no. 37
SE [160701]
1. Needs good planning and design.

2. Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
3. Total cost is higher than waterfall.
5. Prototyping Model
The basic idea here is that instead of freezing the requirements before a design or coding can
proceed, a throwaway prototype is built to understand the requirements. This prototype is
developed based on the currently known requirements. By using this prototype, the client can
get an actual feel of the system, since the interactions with prototype can enable the client
to better understand the requirements of the desired system. Prototyping is an attractive idea
for complicated and large systems for which there is no manual process or existing system to
help determining the requirements. The prototype are usually not complete systems and many
of the details are not built in the prototype. The goal is to provide a system with overall
functionality.
Requirement
Sta
Gathering
Sto
p
Engineer
Product
Quick Design
Building
Prototype
Refing
Prototype
Customer
Evaluation
[Fig. 17]
Advantages:
1. Users are actively involved in the development
2. Errors can be detected much earlier.
3. Quicker user feedback is available leading to better solutions.
4. Missing functionality can be identified easily
5. Confusing or difficult functions can be identified.
BIT/CSE/120050131525
Page no. 38
SE [160701]
Disadvantages:
1. Leads to implementing and then repairing way of building systems.
2. Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
3. Incomplete application may cause application not to be used as the full system was
designed.
4. Incomplete or inadequate problem analysis.
(b) The model suitable for my project is Prototyping Model. It is suitable because my
project, Hotel Management System involves a lot of end user interactions. So, it would be
very beneficial to get regular feedbacks from the end user to produce a useable system with
better User Interface.
BIT/CSE/120050131525
Page no. 39

Hotel Management System

Uploaded by

Document Information

Original Description:

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

Hotel Management System

Uploaded by

Copyright:

Available Formats

SE [160701]