ACKNOWLEDGEMENTS

I extend my profound gratitude to my project guide Mr Sukhjit Singh Sehra, for his interest, guidance and suggestions throughout the course of the project. I feel honoured and privileged to work under him .He shared his vast pool of knowledge with me that helped me steer through all the difficulties with ease. This project would not have been possible without his guidance and I would like to thank him for everything he has done for me.

Harleen Kaur Roll No.80101107043

Chapter 1 Software Development Life Cycle Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. A software development lifecycle, also known as a software development process, which is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a lifecycle model a more general term and a software development process a more specific term. A typical software development lifecycle comprises the following stages: Software Requirement Analysis This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc.... The requirement gathering process is intensified and focussed specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behaviour, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it. Software Analysis and Design In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc. are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Implementing the software product Implementation is the part of the process where software engineers actually program the code for the project. Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation may overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase.

Testing the software solution Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations. The implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase.

Deployment of the solution Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important and a lot of developers fail to realize that. It would not matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.

Maintenance of the product The software will definitely undergo change once it is delivered to the customer. There can be many reasons for this change to occur. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

1.1 SOFTWARE DEVELOPMENT MODELS 1.1.1 WATERFALL SOFTWARE DEVELOPMENT LIFE CYCLE MODEL The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order. A project begins with feasibility analysis. On the successful demonstration of the feasibility analysis, the requirements analysis and project planning begins. The design starts after the requirements analysis is done. And coding begins after the design is done. Once the programming is completed, the code is integrated and testing is done. On successful completion of testing, the system is installed. After this the regular operation and maintenance of the system takes place. The following figure demonstrates the steps involved in waterfall life cycle model.

fig 1: The Waterfall Software Life Cycle Model With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some important consequences. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system. The consequences of the need of certification are that each phase must have some defined output that can be evaluated and certified. Therefore, when the activities of a phase are completed, there should be an output product of that phase and the goal of a phase is to produce this product. The outputs of the earlier phases are often called intermediate products or design document. For the coding phase, the output is the code. From this point of view, the output of a software project is to justify the final program along with the use of documentation with the requirements document, design document, project plan, test plan and test results. Another implication of the linear ordering of phases is that after each phase is completed and its outputs are certified, these outputs become the inputs to the next phase and should not be changed or modified. However, changing requirements cannot be avoided and must be faced. Since changes performed in the output of one phase affect the later phases, which might have been performed. These changes have to make in a controlled manner

after evaluating the effect of each change on the project. This brings us to the need for configuration control or configuration management. The certified output of a phase that is released for the best phase is called baseline. The configuration management ensures that any changes to a baseline are made after careful review, keeping in mind the interests of all parties that are affected by it. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall model. For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product. Project Output in a Waterfall Model As we have seen, the output of a project employing the waterfall model is not just the final program along with documentation to use it. There are a number of intermediate outputs, which must be produced in order to produce a successful product. The set of documents that forms the minimum that should be produced in each project are:

Requirement document Project plan System design document Detailed design document Test plan and test report Final code Software manuals (user manual, installation manual etc.) Review reports

Except for the last one, these are all the outputs of the phases. In order to certify an output product of a phase before the next phase begins, reviews are often held. Reviews are necessary especially for the requirements and design phases, since other certification means are frequently not available. Reviews are formal meeting to uncover deficiencies in a product. The review reports are the outcome of these reviews.

Advantages of Waterfall Life Cycle Models

Easy to explain to the user Stages and activities are well defined Helps to plan and schedule the project Verification at each stage ensures early detection of errors / misunderstanding

Limitations of the Waterfall Life Cycle Model

The waterfall model assumes that the requirements of a system can be frozen (i.e. baseline) before the design begins. This is possible for systems designed to automate an existing manual system. But for absolutely new system, determining the requirements is difficult, as the user does not know the requirements. Therefore, having unchanging (or changing only a few) requirements is unrealistic for such project. Freezing the requirements usually requires choosing the hardware (since it forms a part of the requirement specification). A large project might take a few years to complete. If the hardware is selected early, then due to the speed at which hardware technology is changing, it is quite likely that the final software will employ a hardware technology that is on the verge of becoming obsolete. This is clearly not desirable for such expensive software. The waterfall model stipulates that the requirements should be completely specified before the rest of the development can proceed. In some situations it might be desirable to first develop a part of the system completely, an then later enhance the system in phase. This is often done for software products that are developed not necessarily for a client (where the client plays an important role in requirement specification), but for general marketing, in which the requirements are likely to be determined largely by developers.

1.1.2 PROTOTYPING SOFTWARE LIFE CYCLE MODEL The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. 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. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. 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. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear those constraints can be met or that algorithms can be developed to implement the requirements. The process model of the prototyping approach is shown in the figure below.

Fig2: Prototyping Model The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. However, some argue that prototyping need not be very costly and can actually reduce the overall development cost. 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. In addition, the cost of testing and writing detailed documents are reduced. These factors helps to reduce the cost of developing the prototype. On the other hand, the experience of developing the prototype will very useful for developers when developing the final system. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system. Advantages of Prototyping

Users are actively involved in the development It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency. Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed. Errors can be detected much earlier as the system is mode side by side. Quicker user feedback is available leading to better solutions.

Disadvantages:

Leads to implementing and then repairing way of building systems. Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

1.1.3 ITERATIVE ENHANCEMENT LIFE CYCLE MODEL The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented. At each step extensions and design modifications can be made. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in

the waterfall model. Furthermore, as in prototyping, the increments provide feedback to the client which is useful for determining the final requirements of the system. In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system. Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation and performing an analysis of the partial system are obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available. The process involved in iterative enhancement model is shown in the figure below.

Fig3: The Iterative Enhancement Model The project control list guides the iteration steps and keeps track of all tasks that must be done. The tasks in the list can be including redesign of defective components found during analysis. Each entry in that list is a task that should be performed in one step of the iterative enhancement process, and should be simple enough to be completely understood. Selecting tasks in this manner will minimize the chances of errors and reduce the redesign work.

1.1.4 THE SPIRAL LIFE CYCLE MODEL This is a recent model that has been proposed by Boehm. As the name suggests, the activities in this model can be organized like a spiral. The spiral has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. The structure of the spiral model is shown in the figure given below. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints. The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives and constraints. This will also involve identifying uncertainties and risks involved. The next step is to develop strategies that resolve the uncertainties

and risks. This step may involve activities such as benchmarking, simulation and prototyping. Next, the software is developed by keeping in mind the risks. Finally the next stage is planned.

fig 4: Spiral model The next step is determined by remaining risks. For example, its performance or userinterface risks are considered more important than the program development risks. The next step may be evolutionary development that involves developing a more detailed prototype for resolving the risks. On the other hand, if the program development risks dominate and previous prototypes have resolved all the user-interface and performance risks; the next step will follow the basic waterfall approach. The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented, prototype-oriented, simulation-oriented or some other approach. An important feature of the model is that each cycle of the spiral is completed by a review, which covers all the products developed during that cycle, including plans for the next cycle. The spiral model works for developed as well as enhancement projects.

Spiral Model Description

The development spiral consists of four quadrants as shown in the figure above

Quadrant 1: Determine objectives, alternatives, and constraints. Quadrant 2: Evaluate alternatives, identify, resolve risks. Quadrant 3: Develop, verify, next-level product. Quadrant 4: Plan next phases.

Although the spiral, as depicted, is oriented toward software development, the concept is equally applicable to systems, hardware, and training, for example. To better understand the scope of each spiral development quadrant, lets briefly address each one. Quadrant 1: Determine Objectives, Alternatives, and Constraints Activities performed in this quadrant include:

Establish an understanding of the system or product objectivesnamely performance, functionality, and ability to accommodate change. Investigate implementation alternativesnamely design, reuse, procure, and procure/ modify Investigate constraints imposed on the alternativesnamely technology, cost, schedule, support, and risk. Once the system or products objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks Engineering activities performed in this quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. Boehm describes these activities as follows: This may involve prototyping, simulation, benchmarking, reference checking, administering user questionnaires, analytic modeling, or combinations of these and other risk resolution techniques. The outcome of the evaluation determines the next course of action. If critical operational and/or technical issues (COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if the alternative chosen is operationally useful and robust enough to serve as a low-risk

base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) .The option of writing specifications would be addressed but not exercised. This brings us to Quadrant 3. Quadrant 3: Develop, Verify, Next-Level Product If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs, activities to develop, verify, next-level product are performed. As a result, the basic waterfall approach may be employedmeaning concept of operations, design, development, integration, and test of the next system or product iteration. If appropriate, incremental development approaches may also be applicable. Quadrant 4: Plan Next Phases The spiral development model has one characteristic that is common to all modelsthe need for advanced technical planning and multidisciplinary reviews at critical staging or control points. Each cycle of the model culminates with a technical review that assesses the status, progress, maturity, merits, risk, of development efforts to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral. Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations.

1.2 SOFTWARE MODEL USED This System is based on Linear Sequential Model (Waterfall Model) because of the following reasons: As our system follow a systematic, sequential approach to software development that begins at the system level and progress through analysis, design, coding, testing and support. As the user is required in the initial stage of the system to help the team members to know about the requirements, nature of program, information domain for the system etc. All requirements for the system have been explicitly stated at the beginning. There is very little scope of user deviation from current requirements, coding and testing after detailed analysis is much easy. Our system has blocking states because one team member has to wait for

other member of the team to complete the dependent tasks. Team members are not able to know about the changing requirements of the user as the users are present in the initial stage and then at the testing stage of the system. There is no modular structure as there is only one team to develop the system and to do all the tasks related to system such as analysis, design, coding, testing.

Chapter-2
2.1 EXISTING SYSTEM 2.1.1 PROBLEMS WITH EXISTING SYSTEM

No backup can be maintained as the data is large and duplication of data consumes lot of time. Analysis on data and access to database is tedious. Inability to obtain the status of a book rapidly. Booking room is a large process and may lead to chaos and is prone to errors. It is very difficult to search a particular booking of room because all the book registers are looked which requires very large work force and is a tedious and cumbersome process. It is a well known fact that sorting is a very difficult task if performed manually but it is essential and one of the major requirements for the proper functioning of the system in resolving the ambiguities in the data i.e. whenever a new booking is to be made in the hotel then whole of the sorting procedure has to be applied again which is not feasible and also not possible in real life situations as again and again different databases have to be maintained. the details of the guests are again searched up from different registers which wastes a lot of time.
2.2 INTRODUCTION TO PROPOSED SYSTEM

This Project has been developed for the convenience of a Hotel in order to help those persons who manage the whole system of the Hotel manually. This is developed as a Menu driven system to make it user friendly. And hence, user will not require a huge knowledge of computer operating. All the required operations can be done using sequential menus i.e the dialog boxes would appear as per requirement one after another by clicking required components from the menu. The software has the following key features: Menu Driven: The entire system is developed as a menu driven system. When the system is started the software starts with a flash screen and then the dialog box appears with required menus and

submenus. The dialog box contains menu. From the menus user can do the required operation by clicking menus and their submenus. Flexible: The system is as flexible as there is no need for the remembering of any command. There is a help menu consists the instructions for the usage of the software and information about the components in a step-by-step basis. User Friendly: This software is user friendly since the system entirely Menu driven.
2.3 ADVANTAGE OF PROPOSED SYSTEM

I have designed the given proposed system in the JSP to automate the process of Hotels.This project is useful for the authorities which keep track of all the users registered in a particular state .The authority can add hotel packages, room details, availability of rooms,online booking etc. The following steps that give the detailed information of the need of proposed system are: Performance: During past several decades, the records are supposed to be manually handled for all activities. The manual handling of the record is time consuming and highly prone to error. To improve the performance of the Hotel Management System, the computerized system is to be undertaken. This project is fully computerized and user friendly even that any of the members can see the report and status of the company. Efficiency: The basic need of this website is efficiency. The website should be efficientso that whenever a new user submits his/her details the website is updated automatically.This record will be useful for other users instantly. Control: The complete control of the project is under the hands of authorized person whohas the password to access this project and illegal access is not supposed to deal with. All the control is under the administrator and the other members have the rights to just seethe records not to change any transaction or entry. Security: Security is the main criteria for the proposed system. Since illegal access may corrupt the database. So security has to be given in this project.

2.4 OBJECTIVES

This project deals with the functions of a Hotel with the following menus : Guest details Room details Reservation Details Employee Details Reservation Payment details Reservation Check-In details Reservation Check-Out details Reservation Cancellation Details Employee Payment Details Consumable Details Hotel Management System capabilities include the basics such as transcripts, Payment Details, Employee attendance, and Consession as well as many other specialized capabilities, including access to status of the Hotel Rooms and Reservation on the Internet . With traditional methods Guests may not find out what is the source of their expenses in hotel.
2.5 AIM OF THE PROJECT

The project aims at the easy management of a Hotel to give fast and accurate service to the customers which includes:

Building up database for Guests , Reservation , Staff etc. Development of a new legal framework and Sustainability Analysis

What it does: Provides the details for Guests , Reservations, Employee etc. Provides the facility of searching immediately a particular Guest , Reservation , Employee etc. Provides the facility of backup the records at any critical position also provides to restore the required data.

Chapter 3 Requirement Analysis

3.1 SOFTWARE REQUIREMENT SPECIFICATION (SRS)

3.1.1 Introduction
The following subsections of the Software Requirements Specifications (SRS) document provide an overview of the entire SRS.

1.1Purpose
The Software Requirements Specification (SRS) will provide a detailed description of the requirements for the Hotel Management System (HMS). This SRS will allow for a complete understanding of what is to be expected of the HMS to be constructed. The clear understanding of the HMS and its functionality will allow for the correct software to be developed for the end user and will be used for the development of the future stages of the project. This SRS will provide the foundation for the project. From this SRS, the HMS can be designed, constructed, and finally tested. This SRS will be used by the software engineers constructing the HMS and the hotel end users. The software engineers will use the SRS to fully understand the expectations of this HMS to construct the appropriate software. The hotel end users will be able to use this SRS as a test to see if the software engineers will be constructing the system to their expectations. If it is not to their expectations the end users can specify how it is not to their liking and the software engineers will change the SRS to fit the end users needs.

1.2 Scope
The software product to be produced is a Hotel Management System which will automate the major hotel operations. The first subsystem is a Reservation and Booking System to keep track of reservations and room availability. The second subsystem is the Tracking and Selling Food System that charges the current room. The third subsystem is a General Management Services and Automated Tasks System which generates reports to audit all hotel operations and allows modification of subsystem information. These three subsystems functionality will be described in detail in section 2-Overall Description. There are two en users for the HMS. The end users are the hotel staff (customer service representative) and hotel managers. Both user types can access the Reservation and Booking System and the Food Tracking and Selling System. The General Management System will be restricted to management users.

The Hotel Management Systems objectives is to provide a system to manage a hotel that has increased in size to a total of 100 rooms. Without automation the management of the hotel has become an unwieldy task. The end users day-to-day jobs of managing a hotel will be simplified by a considerable amount through the automated system. The system will be able to handle many services to take care of all customers in a quick manner. The system should be user appropriate, easy to use, provide easy recovery of errors and have an overall end user high subjective satisfaction.

1.3 Definitions, Acronyms, and Abbreviations.

SRS Software Requirements Specification HMS Hotel Management System Subjective satisfaction The overall satisfaction of the system End users The people who will be actually using the system

1.4 Overview
The SRS is organized into two main sections. The first is The Overall Description and the second is the Specific Requirements. The Overall Description will describe the requirements of the HMS from a general high level perspective. The Specific Requirements section will describe in detail the requirements of the system.

2 The Overall Description

Describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead it provides a background for those requirements, which are defined in section 3, and makes them easier to understand.

2.1 Product Perspective

The HMS is an independent standalone system. It is totally self contained. 2.1.1 Hardware Interfaces The HMS will be placed on PCs throughout the hotel. 2.1.2 Software Interfaces All databases for the HMS will be configured using Oracle 8i. These databases include hotel rooms and customers information. These can be modified by the end users. The

room database will include the room numbers and if they are vacant or occupied. The customers information database will contain all the information of the customer such as first name, last name, number of occupants, assigned room, default room rate(may be changed), phone number, whether or not the room is guaranteed, credit card number, confirmation number, automatic cancellation date, expected check in date and time, actual check in date and time, expected check out date and time, amount owed by customer, and abbreviated customer feedback.

2.2 Product Functions

Reservation and Booking System Allows for typing in customer information and rates, Has a default room rate that is adjustable o Includes a description field for the changed rate o When a customer checks in, the room number will be changed to occupied in the database o Ability to modify a reservation o When no rooms are available and a customer would like to extend their reservation their information will be placed in a database and when there are rooms available the first customer on the list will have the room o When a customer checks out the amount owed is displayed o If the internal clock states that is a customers time to have checked out and customer has not checked out, adds an extra night to amount owed and provides a report o Records that room is vacant o Records payment o Allows for space to write customers feedback Tracking and Selling Food System o Tracks all meals purchased o Charges the current room as necessary General Management Services and Automated Tasks System o Reports generated to audit hotel occupancy, future occupancy, room revenue, and food revenue o Exception reports listing exceptions to the normal cost o Allows addition, deletion and modification of information on rooms menu items and prices, user profiles Creation of users and assigning passwords

2.3 User Characteristics

Educational level of HMS computer software Low Experience of HMS software None Technical Expertise Little

2.4 Apportioning of Requirements

The audio and visual alerts will be deferred because of low importance at this time.

2.5 Assumptions and Dependencies

- The system is not required to save generated reports. - Credit card payments are not included 3.2 Functional Requirements Functional requirements define the fundamental actions that system must perform. The functional requirements for the system are divided into three main categories, Reservation/Booking, Food, and Management. 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 number of occupants. 1.5. The system shall record the room number. 1.6. The system shall display the default room rate. 1.6.1. The system shall allow the default room rate to be changed. 1.6.2. The system shall require a comment to be entered, describing the reason for changing the default room rate. 1.7. The system shall record the customers phone number. 1.8. The system shall display whether or not the room is guaranteed. 1.9. The system shall generate a unique confirmation number for each reservation. 1.10. The system shall automatically cancel non-guaranteed reservations if the customer has not provided their credit card number by 6:00 pm on the check-in date. 1.11. The system shall record the expected check-in date and time. 1.12. The system shall record the expected checkout date and time. 1.13. The system shall check-in customers.

1.14. The system shall allow reservations to be modified without having to reenter all the customer inforamtion. 1.15. The system shall checkout customers. 1.15.1. The system shall display the amount owed by the customer. 1.15.2. To retrieve customer information the last name or room number shall be used 1.15.3. The system shall record that the room is empty. 1.15.4. The system shall record the payment. 1.15.5. The system shall record the payment type. 1.16. The system shall charge the customer for an extra night if they checkout after 11:00 a.m. 1.17. The system shall mark guaranteed rooms as must pay after 6:00 pm on the check-in date. 1.18. 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.

3.3 Nonfunctional Requirements Functional requirements define the needs in terms of performance, logical database requirements, design constraints, standards compliance, reliability, availability, security, maintainability, and portability. 1. Performance Requirements Performance requirements define acceptable response times for system functionality. o The load time for user interface screens shall take no longer than two seconds. o The log in information shall be verified within five seconds. o Queries shall return results within five seconds. 2.Logical Database Requirements The logical database requirements include the retention of the following data elements. This list is not a complete list and is designed as a starting point for development. Booking/Reservation System o Customer first name o Customer last name o Customer address o Customer phone number o Number of occupants o Assigned room o Default room rate o Rate description o Guaranteed room (yes/no) o Credit card number o Confirmation number o Automatic cancellation date o Expected check-in date o Expected check-in time o Actual check-in date o Actual check-in time o Expected check-out date o Expected check-out time o Actual check-out date o Actual check-out time o Customer feedback o Payment received (yes/no) o Payment type

o o o o o o

Total Bill.Food Services Meal Meal type Meal item Meal order Meal payment (Bill to room/Credit/Check/Cash)

3.Design Constraints The Hotel Management System shall be a stand-alone system running in a Windows environment. The system shall be developed using Java and an Access or Oracle database. 4. Standards Compliance There shall be consistency in variable names within the system. The graphical user interface shall have a consistent look and feel. 5. Reliability Specify the factors required to establish the required reliability of the software system at time of delivery. 6. Availability The system shall be available during normal hotel operating hours. 7. Security Customer Service Representatives and Managers will be able to log in to the Hotel Management System. Customer Service Representatives will have access to the Reservation/Booking and Food subsystems. Managers will have access to the Management subsystem as well as the Reservation/Booking and Food subsystems. Access to the various subsystems will be protected by a user log in screen that requires a user name and password. 8. Maintainability The Hotel Management System is being developed in Java. Java is an object oriented programming language and shall be easy to maintain. 9. Portability The Hotel Management System shall run in any Microsoft Windows environment that contains Java Runtime and the Microsoft Access database.

3.4 Hardware & Software Requirements

Software Requirements: 1. Microsoft Windows XP or Higher 2. SQL Server 2000 3. Visual Basic .NET 4.OLDB drivers to connect the front end and back end systems Hardware Requirements:

1. 2. 3. 4. 5.

PC with 1.7 Ghz Processor or higher(Pentium, AMD or higher recommended) 512 MB RAM for Win XP or later version 20GB HDD CD-ROM Drive VGA or higher resolution monitor(SVGA recommended)

Chapter 4 PLANNING
4.1 INTRODUCTION Project planning consists of following essential activities: 1. Estimating project attributes have to be estimated: (a) Cost How much is it going to cost to develop the software? (b) Duration How long is it going to take to developthe product ? (c) Effort How much effort would be required to develop the product? 2. Scheduling : After estimations are made, the schedules for manpower and other resources have to be developed. 3. Staffing : Staff organisation and staffing plans have to be made. 4. Risk management : Risk identification , analysis and abatement planning have to be done.

4.2 METRICS FOR PROJECT SIZE ESTIMATION The project size is a measure of the problem complexity in terms of the effort and time required to develop the project. Currently two metrics are popularly being used to estimate size: Lines of code Function point

LINES OF CODE It is the simplest among all metrics available to estimate project size. This metric measures the size of project by counting the number of source instructions in the developed program. While counting the number of source instructions, lines used for commenting the code and the header lines. FUNCTION POINT METRICS Function point metric overcomes many of the shortcomings of the LOC metrics. One of the important advantage of using the function point metric is that it can be used to easily estimate the size of the software product directly from the problem specifications. The conceptual idea behind the function point metric is that the size of the software product is directly dependent on the number of different functions or features it supports. Each function when invoked reads some input data and transforms it into the corresponding output data. Function point is computed in three steps:

The first step is to compute the unadjusted function point (UFP). In the next step, the UFP is refined to reflect the differences in the complexities of the different parameters of the expression for UFP computation. In the third and the final step, FP is computed by further refining UFP to account for the specific characteristics of the project that can influence the development effort. UFP= (no. of inputs)*4+(no. of outputs)*5+(no. of inquiries)*4+(no. of files)*10+(no. of interfaces)*10 The complexity level of each of the parameters are graded as simple, average or complex. Finally, FP is given as the product of UFP and TCF that is FP=UFP*TCF where TCF is a technical complexity factor. For function point Fi, i=1 to 14 so we have F1 to F14 parameters and each parameter can have value from 0 to 5. 0 means ' not required' 5 means ' absolutely essential'

Table 1 : parameters for Fi GRADE VALUES F1 - Does the system require reliable back up and recovery? F2 - Are data communications required? F3 - Are there distributed processing functions? F4 - Is performance critical? F5 - Will the system run in an existing heavily utilised operational environment? F6 - Does the system require online data entry? F7 - Does the online data entry require the input transaction to be built over multiple screens or operations? F8 - Are the master files updated online? F9 - Are the inputs, outputs, inquiries complex? 5

4 0 5 3

1 1

1 2

F10 - Is the code designed to be reusable? F11 - Are conversion and installation included in the design? F12 - Is the system designed for multiple installations in different organisations? F13 - Is the application designed to facilitate change and ease of use by the user? F14 - Is the internal processing complex? Fi =

1 3 4

5 39

Table 2:Calculation of Function Point for library automation system: Measurement Weighting Count Factor Parameter (average) Number of user inputs Number of user outputs Number of user inquiries Number of files Number of external interfaces Count Total 8 17 6 5 0 4 5 4 10 7

Weighting Count 32 85 24 50 0

191

Function point = Total count x (0.65 + 0.01 x (Fi)) = 191 x (0.65 + 0.01 x 39) = 191 x (0.65 + 0.39) = 191 x 1.04 = 198.64 199

4.3 EFFORT AND COST ESTIMATION TECHNIQUE: COCOMO-A HEURISTIC ESTIMATION TECHNIQUE COCOMO (constructive cost estimation model) was proposed by Boehm, 1981. Boehm postulated that any software development project can be classified into any one of the following three categories based on the development complexity: organic semidetached embedded

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 team members are experienced in developing similar types of projects. SEMI DETACHED: A development project can be considered to be of semi detached type,if the development team consist 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. EMBEDDED: A development project is considere to be of embedded type if the software being developed is strongly coupled to complex hardware or if stringent regulations on the operational procedures exist. Accoridng to Boehm,software cost estimation should be done through three stages: Basic COCOMO Intermediate COCOMO Complete COCOMO

In our project LAS, we have used basic COCOMO model for estimating size,time,effort and cost. BASIC COCOMO MODEL The basic COCOMO model gives an approximate estimate of the project parameters.The basic COCOMO estimation model is given by the following expressions: Effort=a(Size in kLOC)^b PM Time =c(Effort)^d months where time is the estimated time to develop the software, effort is the effort required to develop the software For organic : a=2.4 b=1.05 c=2.5 d=0.38

Calculation of effort: In C++, 1 Function Point =125 LOC So, Size in kLOC= (199*125)/1000 =2.4875 kLOC

Effort=a(Size in kLOC)^b PM E=2.4(2.4875)^1 =5.97 PM Calculation of time: Time =c(Effort)^d months =2.5(5.97)^0.38 =2.79 months

Calculation of cost: From the basic COCOMO estimation formula for organic software:

Effort=5.97 PM Time =2.97 months Assuming that the average salary of software developer is Rs.10,000 per month. Cost required to develop the project=5.97*10,000 = Rs 59700

4.4 System Study

This Project is on Hotel Management System, in which there are hotel staffs, floating customers, regular customers etc. The hotel has several rooms of different tariffs. When a customer checks in, the staff search for a particular room according to the customers choice and if the room is available, the customer is assigned a room. The rooms can be booked in advance. When the customer checks out, he has to pay the bill charged by the hotel authority.

4.5 FEASIBILITY STUDY AND RISK ANALYSIS

Depending on the results of the initial investigation, the survey is expanded to a more detailed feasibility study. A feasibility study is a test of a system proposal according to its workability, impact on the organization, ability to meet users needs, and effective use of resources. It focuses on three major questions: 1. What are the users demonstrable needs and how does a candidate system meet them? 2. What resources are available for given candidate systems? Is the problem worth solving ? 3. What is the likely impact of the candidate system on the organization? How well does it fit within the organisations master MIS plan? Each of these questions must be answered very carefully. They revolve around investigation and evaluation of the problem, identification and description of the candidate systems, specification of performance and the cost of each system, and final selection of the best system. The objective of a feasibility study is not to solve the problem but to acquire a sense of its scope. During the study the problem definition is crystallized and aspects of the problem to be included in the system are determined. The result of the feasibility study is a formal proposal. The proposal consists of the following: 1. Statement of the problem: A carefully worded statement of the problemthat led to analysis. 2. Summary of findings and recommendations: A list of the major findings and recommendations of the study. It is ideal for the user who requires quick access to the results.

3. Details of findings: An outline of the methods and procedures undertaken by the existing system, followed by coverage of the objectives and procedures of the candidate system. 4. Recommendations and conclusions: Specific recommendations regarding the candidate system, including personal assignments, costs, project schedules and target dates. After the management reviews the proposal, it becomes a formal agreement that paves the way for actual design and implementation. This is a crucial decision point in the life cycle. Many projects die here, whereas more promising ones continue through implementation. Changes in the proposal are made in writing, depending on the complexity, size and cost of the project. It is simply common sense to verify changes before committing the project to design.

The dimensions that define the feasibility of project are

4.5.1 ECONOMIC FEASIBILITY

The cost incurred in making this software product is nothing in comparison to the amount of expenses made by the organization in managing the library activities. The cost of the software is one long time investment and its maintainability is very easy.The product being complemented by a user manual and documentation is reusable and open to new changes.
4.5.2 TECHNICAL FEASIBILITY

The software is a newly developed application so it does need any other software or hardware. The technical feasibility is high the software can be deployed on any machine having Turbo C++ Compiler and the software requires minimum hardware requirements.
4.5.3 ENVIRONMENTAL FEASIBILITY

The software is simple, and staff members and students can use it with no difficulties at all. The user needs not be trained in using the software

Chapter 5 DESIGN
5.1 INTRODUCTION Design process translates the customers requirements into the software representation that can be assessed for quality before coding. It has following goals: Ensuring that functionality conforms to requirements. Increasing quality such as usability, efficiency, reliability, maintainability, and reusability.

5.2 DESIGN CONCEPTS COHESION

Cohesion is the quantitative indication of the degree to which a system module focuses on just one thing .It is a measure of the relative functional strength of the module. COUPLING

Coupling is the measure of the relative interdependence among the software module. Coupling depends on interface complexity between the system modules. For a good quality product, the design of the software should be clearly understood . An efficient system must have High cohesion and Low coupling. ABSTRACTION

Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose. REFINEMENT

It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a stepwise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts. MODULARITY

Software architecture is divided into components called modules.

CONTROL HIERARCHY

A program structure that represent the organization of program components and implies a hierarchy of control.

5.3 DATA FLOW DIAGRAM

The data flow diagram is used to represent a system or software at any level of abstraction. DFDs may be portioned into levels that represent increasing information flow and functional detail. Thus, the DFD offers a mechanism for functional modeling as well as information flow modeling. And, it satisfies the second operational analysis principle.
DFD Level 0

Da ta

User
Da t aR

Re sp on s

Da
e

ta

se pon s Re

Database
est

1.0
eq ue st

Hotel Management Systems

R ata D

equ

DFD Level 2

5.4 ER-DIAGRAM Database will be consisting of number of tables. First of all an ER-diagram showing the entity and their relationships is created. Then entity sets and relations are converted into tables as per requirement. Careful study of the input-output requirements reveals the attributes of the tables. Finally the table structures are refined applying normalization. Here, normalization up to 3NF has been adopted..

GuestID

fig:5
GuestID Guest Guest

Reserves Reserves ID Date ID ResPayData Amt DueAmt ISA ResPayDat Status Amt BookPayDate RoomNo
Qty

Have BookingCode Have Reservation BookingCode Fr_dt Reservation Res Date Type Rooms Res Type MiscPayData IS Unit A
CstPUnit Desc

To_dt Fr_dt RoomID Charge To_dt BookedRooms RoomID ToDt Charge FromDt

a
Qty

areof

ConsPayDat DueAmt e Status

KepsInfo

Rooms

Hav

ItmID BookPayD ate Consumables Room Unit No

Qt y

Qt y

Name MiscPay Desc Data

are of

From Dt

Bills

ConsPay Price Date

CstPU nit Uni t Des c KepsChInfo

BookedRoo ms To Dt Rooms

BookingPayData
KepsI nfo

ID

Hav

BookCode

ItmI D

RoomID

Consumab les Bil ls Un it Pri ce

Na me

De sc

5.5 Database tables to be used:

Table: LOGIN Column Name

Name PassWord
GroupID

Data Type CHAR(30) VARCHAR(50) Int

Description The name which the user use as LOG-IN Name.(Part of Primary Key) PassWord of the user. Combination of Name and PassWord is Unique (Part of Primary Key) Group in which the Guest belongs to. Depending on value of this field Certain access will be denied for this User (Foreign Key).

Table: GUESTS Column Name GID FirstName LastName City Country GuestType CreateDate Contact No. State PIN

Data Type Description VARCHAR(50) Unique Identification(Guests ID) for every guest ( Primary Key) VARCHAR(50) First name of the guest VARCHAR(50) Last name of the guest VARCHAR(50) The name of the city where the guest lives VARCHAR(20) Which Country the guest belongs to VARCHAR(50) Refers the Type of GUEST DATETIME Date on which this information was fed into the database. It is todays date VARCHAR(50) Contact No. of the Guest Varchar(25) The name of the state where the guest lives Int Pin No of the Guest.

Table: ROOMRES Column Name Data Type BookingCode Int RoomID Int FromDt DateTime ToDate DateTime Status Varchar(50) ChkInDt DateTime ChkOutDt DateTime

Description Unique Identification for Room ID of the Room The date from which the room is booked The date upto the room will be book CheckedIn/CheckedOut/NotCheckedIn The Check In date The Check Out date

Table: ROOMS Column Name Data Type Int RoomID Type FloorNo Description Charge MinAdv VARCHAR(10) Int VARCHAR(100) Int Int

Description Unique identification for every Room(Primary key) Type of the room Floor Number viz. 1, 2, 3, etc Description of the room Charge of the room Advance Payment for the Room

Table: EMPLOYEES Column Name Data Type int EmpID FirstName LastName City State Country JoinDate BirthDate PIN ManagedBy Designation ContactNo VARCHAR(50) VARCHAR(50) VARCHAR(50) VARCHAR(50) VARCHAR(50) DateTime DateTime BigInt BigInt VARCHAR(30) BigInt

Description Unique identification for every Employee(Identity Field)(Primary key) First name of the Employee Last name of the Employee Employees City Employees State Employees Country Date on which the Emplyee joins in the hotel Birth date of th employee PIN Code of the area where the employee lives Managed by Designation of the Employee Contact number of the Employee

Table: SHIFTSCHEDULES (stores info about the shift for every employee, whether first, second, night or general) Column Name Data Type Description EmpID BigInt Refers ID column of EMPLOYEES table(Foreign key) Location VARCHAR(8) Duty place of employee for the week viz. Room No 45 to 60 or Restaurant or Banquets FromDt DATETIME The Date from which the duty starts ToDt DATETIME The Date upto the duty countinues ShiftNo CHAR(1) Whether first shift, second shift, night shift or general shift (store only 1, 2, N or G here)

Table: RESERVATIONS Column Name Data Type BookingCode Bigint GuestID BookingDate BigInt DATETIME

Description Auto-generated unique identification for every booking made by customers(Primary Key) (Identity Field) Name of the guest (if different from BookieName) Date of the Booking

Table: RESPAYDATA (stores info about all payments made by guests) Column Name Data Type Description BookingCode Bigint Booking Code for the guest. Refers BOOKINGCODE column of RESERVATION table ID Int ID of the Booking Date DATETIME Date of the payment.(System date) Status VARCHAR(50) Cleared / Not cleared / Pending PayMode VARCHAR(10) Mode of the Payment, whether Cheque or Cash or Credit Card PayAmount Money Amount paid by the Customerl DueAmount Money The due amount of the Bill ExpType VARCHAR(50) Lodging / Fooding / Together

Table: CONSUMABLES Column Name Data Type Int ItemId Name Description Unit Price ItemType VARCHAR(50) VARCHAR(255) VARCHAR(25) Money Varchar(20)

Description Unique Identification for every consumable (Food Or Beverage) (Primary key) Name of the dish/drink viz. Idly-Sambar, BreadOmelets, Chicken Tikka, Malt Whisky, etc. Any extra information you want to store about this dish/drink Unit of Measurement of this dish/drink viz. ml, slices, numbers, etc. Price Per Dish What Kind of item it is ( Whether ColdDrink or Rice Item etc)

Table: ROOMPAYDATA Column Name Data Type BookingCode Bigint

ID RoomID FromDt Type

Int Int DATETIME VARCHAR(30)

Description Booking Code for the guest. Refers BOOKINGCODE column of RESERVATION table ID of the Booking Id of the Room The From Which the Room is Booked Refund Room Book Cancellation Room Update

Table: CONSPAYDATA Column Name Data Type BookingCode Bigint

ID Quantity Name

Int Int VARCHAR(50)

Description Booking Code for the guest. Refers BOOKINGCODE column of RESERVATION table ID of the Booking Quantity Name

Table: MISCPAYDATA Column Name Data Type BookingCode Bigint

ID Quantity Unit Cons_Per_Unit

Int Int VARCHAR(25) Int

Description Booking Code for the guest. Refers BOOKINGCODE column of RESERVATION table ID of the Booking Quantity Unit of Measurement of this dish/drink viz. ml, slices, numbers, etc. The usage per unit

Table: BILLS Column Name BillNo Amt Tax PayMode BillDt

Data Type Bigint Int Int VARCHAR(10) DATETIME

Description Unique Identity of every Bill Amount of Bill Taxable Amount of the Bill Mode of the Payment, whether Cheque or Cash or Credit Card Date of the Bill

Table: RESPAYDATABILLS Column Name Data Type BookingCode Bigint

ID BillNo Date Amount

Int Bigint DATETIME Int

Description Booking Code for the guest. Refers BOOKINGCODE column of RESERVATION table ID of the Booking Unique Identity of every Bill Date of Payment Amount of Payment

4.5 FRAMEWORK

Fig 6:login menu

Fig7: Main Screen of Hotel Management System

This is the main screen of Hotel Management System. User has to click on the menu to work for a specific work. As for example, if user wants to reserve a room then he has to click on the Reservation menu and the click on Booking menu.

Fig:8 reservation This is the screen of the reservation of rooms. Here we have to enter the PAN and then click on the Confirm Booking If the PAN exists then it will Confirm Booking otherwise it will display a message that The Guest Does nt exists. Now well click on the link i.e. Click to Search an Existing Guest or Add a new Guest then this form will appear on the screen.

Fig4: Screen to Add Guest Information This is the screen to add Guest Information. After adding the guest information the we have to enter the PAN we have to click on Confirm Booking button then well getReservation code then we have to click on Click to book available Rooms then the following window will open:

Fig5: Screens of Room Reservation

Fig8: Screens of Reservation Bill Pay

Fig9: Screens of Reservation Expences

Fig8: Screen of Rooms

Fig 11: Screen for Check-In and Check-Out

5.5 CONCLUSION

After we have completed the project we are sure the problems in the existing system would overcome. The LIBRARY MANAGEMENT SYSTEM process made computerized to reduce human errors and to increase the efficiency. The main focus of this project is to lessen human efforts. The maintenance of the records is made efficient, as all the records are stored in the ACCESS database, through which data can be retrieved easily. The navigation control is provided in all the forms to navigate through the large amount of records. If the numbers of records are very large then user has to just type in the search string and user gets the results immediately. The editing is also made simpler. The user has to just type in the required field and press the update button to update the desired field.

The Books and Students are given a particular unique id no. So that they can be accessed correctly and without errors. Our main aim of the project is to get the correct information about a particular student and books available in the library. The problems, which existed in the earlier system, have been removed to a large extent. And it is expected that this project will go a long way in satisfying users requirements. The computerization of the Library Management will not only improves the efficiency but will also reduce human stress thereby indirectly improving human recourses.