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

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

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: Efforts=3.0(KLOC) 1.12 Person-Months 3. Embedded Model: Efforts=3.6(KLOC) 1.20 Person-Months

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)

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. Field Name

Data type

Description

Ad_id

Int

Primary Key

Username

nvarchar(50)

Stores the username of the Customer

Password

nvarchar(50)

Stores the password of the 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 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. 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

3

Email

Already

Login ID should be unique

l Successfu

4

Password

Exists or not Empty

Please Enter valid Password

l Successfu

5

Password

If

Password

Password Length

6

l Successfu

wrong Enter Password

l Length should be less than Successfu or equal to 10 character

Test Case: Registration

l

[Table 7]

Sr.

Input Values

Test case

Conditional being checked

Result

No 1.

First Name

Empty

It must not be empty

Successfu

2

Last Name

Empty

Last Name must not be empty

l Successfu

3

Email

Empty

Enter valid Email ID.

l Successfu

4

Password

Empty

Enter valid Password.

l Successfu

Minimum 8 characters required

l Successfu

5

Password

Length

6

Confirm

Empty

Password

7

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

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

Recommend Documents