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 reservation’s 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 user’s 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 guest’s personal details such as

Name, Age, Nationality, and Duration of stay, are input during booking in. The booking

office orders for preparation of the guest’s room before his/ her check in date.

The documents are transferred manually to the filling department for compilation of the

guest’s 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 guest’s file to the accountant on the next table. Here the guest

pays accommodation and meals fee. The guest’s 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


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


2. Requirement Specification

2.1 Functional Requirement Specification

1. Reservation/Booking1.1. The system shall record reservations.1.2. The system shall record the customer’s first name.1.3. The system shall record the customer’s 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 customer’s 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. Food2.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. Management3.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


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


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.

Boehm’s [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


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


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:

Low Average High Total

EI 3 x 6 = 18 0 0 18

EO 4 x 2 = 8 0 0 8

EQ 0 0 0 0

ILF 0 7 x 1 = 7 0 7

EIF 0 10 x 1 = 10 0 10

Total Number of Unadjusted Functional

Points282

Multiple Value Adjustment Factor = 0.65 +

0.01 * DI 1.02

Total Adjusted Function Points = UFP * TCF 287.64

BIT/CSE/120050131525 Page no. 7


‘Degree of Influence’ Table: [Table 2]

S.No. Degree Of Influence Value

1 Data communications 5

2

Distributed data

processing 2

3 Performance 2

4

Heavily used

configuration 1

5 Transaction rate 4

6 On-Line data entry 6

7 End-user efficiency 0

8 On-Line update 1

9 Complex processing 1

10 Reusability 6

11 Installation ease 0

12 Operational ease 0

13 Multiple sites 5

14 Facilitate change 4

Based on Functional Point Analysis our Line of Code would be: 1.25KLOC for the module.

‘Cocomo Model’ Table: [Table 3]

Cocomo Model

Effort(PM) =

a1 * (kloc) ^ a2

Development Time(months) =

b1 * (Effort) ^ b2

Organic E= 2.4 * (1.25) ^ 1.05 = 3.03 T = 2.5 * (3.03) ^ 0.38 = 3.81

Effort = 3.03 Person-Months

Time = 3.81 Months

BIT/CSE/120050131525 Page no. 8


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.

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


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


BIT/CSE/120050131525 Page no. 11


2-Level DFD: Fig. 4.

BIT/CSE/120050131525 Page no. 12

Search Room0.4.1

Hotel database

Cancellation0.7.1

Search room by facility Search room

by Rent Search room by floor

Cancel due to personal reason

Cancel due to miss behaviour

Cancel due to lack of facility


4.1.2 ER – Diagram [Fig. 5]

BIT/CSE/120050131525 Page no. 13


4.2 Object Oriented Approach

4.2.1 Use Case Diagram [Fig. 6]

BIT/CSE/120050131525 Page no. 14


4.2.2 Class Diagram [Fig. 7]

BIT/CSE/120050131525 Page no. 15


4.2.3 Sequence Diagram

Book Room [Fig. 8]

BIT/CSE/120050131525 Page no. 16


Payment

Fig. 8.

BIT/CSE/120050131525 Page no. 17


4.2.4 Activity Diagram Fig. 9

BIT/CSE/120050131525 Page no. 18


BIT/CSE/120050131525 Page no. 19


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. 20


Table Name: Registration

Description: It stores the information of the customer.


C_id Int Primary Key

email_id nvarchar(MAX) Stores the email id of the

user

username nvarchar(MAX) Stores the username of

the user

password nvarchar(MAX) Stores the password of

the user

phone_no numeric(10, 0) Stores the phone no

Table Name: Cutomer_Login

Description: It stores the information of Customer.


Ad_id Int Primary Key

Username nvarchar(50) Stores the username of the

Customer

BIT/CSE/120050131525 Page no. 21


Password nvarchar(50) Stores the password of the

Customer

5.2 User Interface Design

Log In Page [Fig. 10]

Register Page [Fig. 11]

Admin Login [Fig. 12]

BIT/CSE/120050131525 Page no. 22


BIT/CSE/120050131525 Page no. 23


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 )

BIT/CSE/120050131525 Page no. 24


b. Inline

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. */

}

BIT/CSE/120050131525 Page no. 25


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.

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 compiler’s 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. 26


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 user-

training, 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. 27


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. 28


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. 29


7.3 Preparation of test cases

Some Test Cases are as follows:

Test Case: Log In [Table 6]

Sr.

No

Input Values Test case Conditional being checked Result

1 Email Empty Please Enter valid Username Successful

3 Email Already

Exists or not

Login ID should be unique Successful

4 Password Empty Please Enter valid Password Successful

5 Password If wrong

Password

Enter Password Successful

6 Password Length Length should be less than or

equal to 10 character

Successful

Test Case: Registration [Table 7]

Sr.

No

Input Values Test case Conditional being checked Result

1. First Name Empty It must not be empty Successful

2 Last Name Empty Last Name must not be empty Successful

3 Email Empty Enter valid Email ID. Successful

4 Password Empty Enter valid Password. Successful

5 Password Length Minimum 8 characters required Successful

6 Confirm

Password

Empty Password and confirmation

password must be same

Successful

7 Date Of Birth Select Enter valid Username and

Password.

Successful

BIT/CSE/120050131525 Page no. 30


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. 31


References

www.SoftwareMetrics.Com

NOAA National Weather Service NWS/OHD General Software Coding Standards

and Guidelines

www.arpitchauhan90files.com

BIT/CSE/120050131525 Page no. 32


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. 33


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.

[Fig. 13]

BIT/CSE/120050131525 Page no. 34

Requirements & Analysis

System Design

Class Design

Implementation

Testing

Deployment

Maintenance


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 doesn’t match reality well.

2. Doesn’t 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.

BIT/CSE/120050131525 Page no. 35


2. Iterative Development

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]

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.

BIT/CSE/120050131525 Page no. 36

Requirements Defination

System & Software Design

Implementation & Unit Testing

Integration & System Testing

Operation & Maintenance


3. Spiral Model

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.

[Fig. 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.

BIT/CSE/120050131525 Page no. 37

Testing & Evaluation Requirements

Indentification

DesignImplementation

Final Project Release

Start Here


Disadvantages:

1. Can be a costly model to use.

2. Risk analysis requires highly specific expertise.

3. Project’s success is highly dependent on the risk analysis phase.

4. Doesn’t 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

previous release. The process continues till the complete system is achieved.

[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.

BIT/CSE/120050131525 Page no. 38

Requ

irem

ents Design &

Development Testing Implementation

Design & Development Testing Implementation

Design & Development Testing Implementation

Build 1

Build 2

Build N

http://istqbexamcertification.com/what-are-the-software-development-life-cycle-phases/

http://istqbexamcertification.com/what-is-a-software-testing/

http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/

http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/


Disadvantages:

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.

[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. 39

Requirement Gathering Quick Design Building Prototype

Customer EvaluationRefing PrototypeEngineer Product

Start

Stop


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. 40

Hotel Management System

Documents

Transcript of Hotel Management System