The Hotel Computer ScienceTM Overall Project Evaluation Tuesday April 2, 1996

Hotel CPSC Homepage
ACME Design Solutions Homepage

Evaluation of ACME Design's Hotel Booking System :

With respect to the functionality of the program if it was fully implemented it appears the system would have met most of our defined specifications. One unfortunate result of the system not being fully functional was that it made it impossible for us to determine how effectively errors are handled by your system. We may need further clarification of this aspect of the system before delivery. We will go over system functionality in detail in the next two sections.

Summary of expected system functions:

FRONT DESK

Customer Inquiries
To search for available rooms based on:
• arrival date
• length of stay
• number of rooms needed
• beds/room
• handicaped
• non/smoking
• special rooms
Comments:
1. Group bookings not done. Weren't told how they were planning to implement this.
2. Normal booking didn't work. Large problem.

Reservations/check-ins
To go from an availability inquiry to a reservation always require the user to start from scratch with a new reservation. This seems to be a little bit inconvient for user to go throught this two passes process and it would be nice if there is any direct way to do this.
Comments:
1. Reservation process wasn't shown to be working adequately.
2. Check in worked but checking out did not.

Registration
• cancelled
• changed
• display all reservations for a given date
• record car informationn
• confirm information at reservation
  • #of guests
  • check out date
  • method of payment
  • names of occupants
Comments:
1. Payment of bill wasn't described or demonstrated. Had account summery but did not show how payment was accepted into the system.
2. Didn't show how to edit existing reservations.
3. Didn't show how deposits on reservations were handled.

Payments
upon check out :

itemise bill room service phone charges taxes room charge etc show total, charge, amount paid and amount still owing print out and display to screen
Comments:
1. Sales report wasn't implemented.
2. Sales tax updates not implemented.

Leave a message
trigger message indicator
Comments:
1. Message system worked.

General Comment:

1. Most of the things that they promised didn't end up working.
2. Most of what was implemented was hardcoded

FOOD SERVICES

Order
Take order by phone,enter name and any special instructions, then the cost will be calculated and can be shown on a seperate report
access to an on line menu
display order to cooks
print order to paper for records
order complete remove from list of orders

Comments:
1. interface was done well and the general appearance of the kitchen screen was very nice.
2. The layout made the kitchen screen easily recognizable. For example the buttons were well placed (but somewhat crowded), easily accessible,and gave the screen a nice appearance.
3. Functionality of the actual kitchen module was lacking. For example, when an order was placed by selecting a food item from the list box menu but then garbage appeared in the appropriate boxes of the ordered information.
4. It seemed by appearance that only one item could be ordered by a particular individual. This is a big problem because usually a person will order many items, not just one.
5. They have resolved the disagreement of the delivery person assignment between the kitchen and supplier group. Instead of preassigning the delivery person when the order is placed, the order is printed out and whomever is available makes the order.
6. They never addressed how the actual cook is going to see the order.
7. It would be nice to actually see how secure the system really was.

1. Overall the basic kitchen requirements have been met in theory and we are generally happy with the demo version.

MANAGMENT

Administrator
Update all records in the database such as employee records, menu information, hotel charges, as well as generate reports, change taxes, and calculate total revenue.
Comments:
1. Employee record updates and additions implemented.
2. Didn't look like the administrator could change specific items on a customer's bill. eg. Adding damage done to rooms.
3. We especially like the menu editing function because adding new items can be done very easily. It would have be nice to actually see the item being added to the data base.

No online help is available for this system

Overall project evaluation:

Our project was developed using the WWW as the main medium of communication between the customer and supplier groups. We were very fortunate to use this technology in the project. In many ways the use of online communication between the groups has benefitted us as individuals. There was less need for scheduling "face-to-face" meetings with the supplier group, since the documents pertaining to the project were available on the WWW. The organization of materials on the Web made referencing the needed documents simple for our group members, and saved us from the use of large amounts of paper. The problem of distance between parties negotiating the development of a product such as our "hotel booking system" were be eliminated. Not incidentally, considerable money and natural resources were saved by eliminating paper from the process. This method could be considered as the future of software development.

However, in the short timeframe that our respective groups were expected to work in, the benefits of extensively using on-line communication were limited. With the brief time allowed between the production of customer and supplier documents, it seemed that some documents were not even read. This is evident in that some of our customer group amendments have been repeatedly overlooked by the supplier group until relatively late in the project. An example of this was as the concept of group bookings which was constantly overlooked by the supplier group, despite gentle reminders in our amendments.

Communicating through documents, whether on the web or in paper also has some limitations.Closer communication between groups is essential to improving the design process. This could best be accomplished by more "face-to-face" meetings in response to each document produced, provided that the groups have read the document. At times we felt ignored, as the supplier group was sometimes slow to respond to amendments or suggestions we had presented to them. For example, we had received no response to our request for screen snapshots of the system until their initial presentation. At times like this, we were unsure as to how the development of the system was coming along. If we, as the customers, can be in closer contact with the supplier group, then we would have a clearer understanding of how each group interprets the system. As we found in our project, we were relatively distant from our supplier group. Interaction with them would have put the project on a more personal level. In this context,it would be less likely that important points would be overlooked, and any conflict in ideas could be corrected before expanding to the point of chaos.

Our major criticism of the design assignment was that we were rushed. While this forced us to be very organized it also meant we were sometimes less thorough than we would have liked. A good example of this was the Informal Specification of Requirements the initial specification for the desired system. The problem was that our group had barely enough time to learn the name of each member before the document was due. Each member of the customer group was also a member of a different supplier group, working on a separate project. This resulted in a great deal of shifting from one context to another. Much of our time as a group was spent on the production of the documents as opposed to the efficient design of the booking system. Time allotted between customer and supplier group reports meant producing rushed jobs. The focus of most members of all groups involved in the projects was on the supplier groups. Had our customer groups been given more time to develop the initial design, perhaps the supplier groups could have avoided finding as many conflicts in the systems, and would not have had to change them as much from the initial specifications.

Overall, we felt that the design process encouraged detailed documentation and forced team organization. As a medium, the WWW was an excellent choice however, more face to face meetings could have enhanced our system design. Given the amount of time to complete the project the development process was a success. The design process was initially confusing for both the customer and supplier group as we were immediately drawn into a deadline situation without first having established group structure or a feel for the system and companies we were to represent. This forced us to get organized and we were fortunate that our group "clicked" early and developed an efficient process for getting the work done. A suggestion that may enhance the benefits of using the WWW in the software design process is to extend the software engineering course to a full year.