The Hotel Computer ScienceTM

Overall Project Evaluation

Tuesday April 2, 1996

Hotel CPSC Homepage
ACME Design Solutions Homepage

The product presented on April 4th was generally attractive and, as far as it was implemented, appeared to meet most of our requirements. We are plaesed with this; however the incomplete state of the project makes it difficult for us to evaluate many features of the program. Though this was intended to be the final demonstration of the system before delivery it is clear that some work still needs to be done before it is actually ready for us to use. We assume this does not present an insurmountable challenge and that if we continue to work together with the same cooperative spirit as we have so far you will still be able to achieve the final goal of this project -- installing a working system at Hotel Computer Science on time. It is with this hope that we offer the following evaluation

Evaluation of ACME Design's Hotel Booking System :

The interface designed by ACME was generally attractive but clearly not fully realized. Many of the screens had buttons on them that did not seem to serve any purpose (For example, on many of the screens there was a row of about ten small buttons below the menu bar) we assume that before the system is installed these extraneous buttons will be removed. It may also be appropriate to use buttons with recognizable icons. The interface also seemed to make use of a lot of screens and could be drastically simplified. For example, the registration screen could have a check box or some other indicator that would have show a customer has checked into the hotel. This would have removed the extra check-in screen. It would be easier for us to work with a simpler system and it may save you time in implementing it.

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:

This is provided as a checklist for what we expect of the delivered system


General Comment:

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


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



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.