Final evaluation Document

What we liked about UDDERS:

We liked the security implementation and features in UDDERS. With it being one of the most important parts of the system, the organization, different groups of users, differing levels of access, and protective measures were all extremely satisfying to us. The features and depth of the security were well beyond the required specifications. The implementation of security features was not up to our standards; specifically the ability for a new user to go without a password severely compromises the UDDERS system.

How UDDERS satisfied our initial specifications:

1. Reservation Booking was implemented efficiently, and seemed easy to use. Fields were easily identifiable, and the screen wasn't cluttered at all, even with the vast amounts of information that needed to be displayed.
   
   
2. Flight Scheduling closely resembled our previous requirements, with the ability to Add, Modify, Cancel, and Print all available for use.
   
   
3. Airplane Information closely related to our informal specifications. Adding, Modifying, Deleting, and Printing were all usable.
   
   
4. Issuing tickets and checking in both also satisfied our requirements. They were handled brilliantly, and were both very intuitive.
   
   
5. Searching ability is well implemented and very powerful, though not very intuitive.

How UDDERS did not satisfy the required specifications:

1. Generation of printed output such as: Revenue lists, Compensation lists, and Seating lists appeared to be lacking, although Mootronix assured us during the demonstration that this will be delayed to April 30 at the latest. These reports were to be generated on a daily, monthly and yearly basis.
   
   
2. The handling of GST was unseen during the demonstration, and was required in our previous documents.
   
   
3. Refunding a customer for canceling a flight only when they have flight insurance was not covered during the demonstration; the status of this feature is unknown.
   
   
4. Compensation for passengers who are overbooked on a flight and rebooked on another did not seem to be part of the system.
   
   
5. Plane functions such as Deleting and Adding a Plane contained field values that didn't appear to work. Since these primary functions are very important to our daily operations, we would expect that these be completed immediately.
   
   
6. As mentioned many times on previous meetings, the ability to physically change seating arrangements is not necessary. The current process of adding seats is tedious even if it is done infrequently.
   
   
7. The confirmation when deleting/removing a record was not in place throughout the system.
   
   
8. The time offset for flights was not done automatically by the system. It was envisioned that a user would simply enter the departure time, and duration of flight and the system would automatically calculate the arrival time in the destination city taking into account time zone differences.

Our overall impressions of UDDERS

Overall the UDDERS system meets most of the major requirements specified by the design documents. The general look and feel of the system is a good starting point for further development. Usability studies would be in order to fully determine and improve the current implementation of the system. Dairy Air's requirements for the system were quite specific and the effort put forth by Mootronix in the UDDERS system is appreciated.

How Useful Was the Design Process

1. specifying the business needs to be satisfied by a software application,
   
   
2. specifying the scope of the problem domain to be addressed by the application,
   
   
3. interacting with a contractor / supplier of an application.

The design process overall was judged to have created a reasonably good environment to provide students with a "feeling" of being in the position of customer. The simulation was not complete by any means, but generally the customer group feels that many of the challenges and issues that a real customer would face in trying to articulate their needs and interface with a contractor arose during the design process.

The design process certainly allowed students to experience the difficulty that customers have in clearly articulating their needs in the form of specifications. This difficulty is present even if the customer thinks they "know" their business. The task of defining and getting consensus and internal consistency on the needs of Dairy-Air was not an easy job, despite the superficial simplicity of the assignment scope.

The role playing also simulated the challenge that customers face with managing a contractor. The time pressures to handle and respond to a contractor's supply of design documents seemed real. This aspect highlighted the ongoing commitment that a customer has to effectively interface with a contractor. This pointed out that the customer's commitment to a successful project is significant and should not be treated lightly.

Suggested Improvements to the Assignment

Whether the attitude of students or a property of the process, the structure of customers and suppliers seemed too often to degrade to an "us and them" approach to the assignment. Perhaps more time could be spent at the beginning of the course to discuss,

1. the purpose of the course assignment structure,
   
   
2. the roles that groups are to play,
   
   
3. the practical learning that the students should be looking for during the assignment from the roles that they are playing, and
   
   
4. guidance in setting up the groups.

In terms of the running of the assignment we would recommend the following,

1. make the grading criteria used by the T/A's for each of the assignment components clear at the beginning of the assignment. There were some surprises when we found out how our work efforts were being graded, i.e., what was considered important and what wasn't,
   
   
2. make more time available during the demos for customers to actually try out the prototypes being demonstrated. We found that not previously having seen the system actually working, the demo went too quickly to be able to judge how well the system actually met the specifications agreed to with the supplier,
   
   
3. the assignment descriptions should be "tighter" when handed out to the customer groups. We feel that there is too much looseness in the interpretation of the minimum / maximum system requirements.

Final note