Final evaluation Document

back to the main page

Design process discussion

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.

Back to the top

How Useful Was the Design Process

The following comments discuss how useful the design process was from the viewpoint of students playing the role of Customers. "Usefulness" of the design process is considered to mean how useful the design process was in helping students gain practical learning about the role of a customer with regard to:
  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

The following are offered as suggestions on how to improve the assignment and the design process from the customers viewpoint.

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.
Our customer group feels that more interaction with the supplier group during the course of the design process would likely have led to a smoother interchange of information between us and our supplier. The use of the web as a means of communicating requirements to our supplier is not felt to be something that should be promoted. The web page postings are a convenient means of documenting information and progress, but should only be used after these matters are worked out in face to face discussion between the customer and supplier. Specifically, if we were to do this course again (and we are not suggesting we should) we would have set up a liaison subgroup to work with the customer during the design process and would have requested the supplier to meet with the subgroup prior to every deadline to work through issues. In addition to a liaison group, other task subgroups could have been assigned the responsibility to work each of the stages of the design process.

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

We at Dairy Air would like to take this opportunity to thank each of the members of the Mootronix team for the effort they put into the development of the UDDERS system.