We liked a number of the built-in constraints on user input, such as in fields for postal codes and phone numbers, and we appreciated the effort that was made to disable buttons that weren't applicable, particularly when logging in. We also liked the fact that we were able to make selections from lists in many cases where this was appropriate rather than typing in information, and we especially liked the mechanism that was used for selection of departure points, arrival points and flight times on the booking screen.
We realize that our requirements were fairly broad, and not as well specified initially as they might have been, and we appreciate the effort that was made to meet most of them, particularly in specifying seating for planes, which was a thorny area. After viewing the results, however, we believe it might have been better if the suppliers had concentrated their efforts in this initial phase of development to the more manageable areas of our specification.
What we didn't like about the ATICS system
1. Perhaps the greatest omission was the 15% overbooking feature. Difficult as it may have been to implement, it was one of the few features that was specified to us, the customer group, as something that had to be implemented. That it is absent is a fairly serious problem with Jury Systems' design for the prototype.
2. Assigning particular seats is difficult. Though Jury Systems provided a facility for selecting seats, it is inconsistent between the booking of flights and the production of boarding passes. There is no obvious correlation between the seat number as specified on the booking screen and the row and column on the boarding pass screen.
3. Furthermore, even given the absence of the 15% overbooking feature, it was impossible in this prototype to issue refunds or rebook a flight.
4. When searching by flight, there was no list of passengers on a flight in the search results. We did request such a feature and suspect it would not be too difficult to add.
5. The search facility as implemented was nearly useless. Even if Jury Systems had permitted searching on any given field in the database, as we had specified, the search results cannot be used as inputs to other operations. By contrast, in the hospital database system, it is possible to search for a record on a set of criteria and then alter the fields in the record when it is displayed.
6. In general, the error checking in the prototype seemed poor. In the demonstration, our customer representative had trouble entering a new booking agent record and entering a new flight booking record, and no message appeared to explain what had happened. It turns out that certain operations in the prototype have to be done in a particular order, but there is no facility to enforce that the user performs those operations in that order. One particularly glaring problem was that the administrator designing a new aircraft had to enter the seating capacity of the aircraft, which could easily have been calculated from the number of rows and columns in the plane, and no checking at all was done to ensure that the number the administrator entered was correct.
7. Jury Systems' prototype facility for designing aircraft is more difficult to use than it needs to be. Their future enhancement is awaited eagerly.
8. The system seems fundamentally inconsistent in its design. There are many windows which could be collapsed into few. There is at least one button that does nothing.
9. The windows themselves were cluttered and unattractive. Some fields were not justified, there were spelling mistakes in field labels and field contents, and much screen real estate was not used at all.
Throughout the project, our customer group realized that several aspects of the design process that were enforced during the design project would be very useful in our future endeavors. First of all, while we generally hold the view that more "face to face" meetings with our supplier group would have been helpful, the documentation deliverables that were required of the customer group proved effective. Such documentation enabled our customer group to stay up to date on the progress of the project without having to arrange frequent, time consuming, group meetings. It also gave our group members a reference point from which to draw up any questions and/or concerns that we could discuss when we did actually get together. Secondly, the documented correspondence between groups served the purpose of making it very clear what was expected of, and requested from, both groups. The step by step design process used for these projects aided in modularizing a fairly large task into smaller, manageable chunks. By taking it one step at a time, our customer group could observe the progress being made and was able to clear up any misunderstandings as they arose. Our customer group also used this to our advantage by being able to more easily see what it was that we wanted from a design perspective and formalizing these realizations into official requirements. One must also note that in the real world, having a record which documents the project at hand is very important in making clear what is expected of your supplier. Finally, and perhaps most importantly, as potential software engineers we thought that this opportunity to see the design process from a customer point of view was very beneficial. As a vendor of a software system, it is important to realize what it is that your customer wants, and this opportunity perhaps provided us with a little more perspective on this issue.
Overall Appearance
We find that many areas of the GUI could be improved upon prior to final delivery. We would like the application to have a more pleasing, and consistent appearance across all screens for both the agent and administrator. Option buttons should be consistently spaced in all screens, not staggered in one, and spaced straight across, and unevenly in another. Data entry fields should all be justified to one side or the other, we prefer left justification. Also, these field boxes should line up better horizontally across the screen. In general more careful consideration should be given to the overall layout of the screens to reduce white space and cluttered areas.
Creating a New Airplane
Since our airplanes do have a variable number of seats per row, it is necessary to accomodate this. It would be acceptable to us to create rows with width equal to the maximum seats per row and then making unavailble those seats which do not exist. This would be good for the proposed graphical table as well where perhaps an `X' could be put in the unavailable spots giving an overall shape of the airplane in the table.
Differences for the design assignment
If it were our decision we would make several changes to the design assignment which result from our experience as a "Customer" group. We feel that if it were possible customer groups should be eliminated altogether as they are a distraction from the emp hasis of the project, being a member of a supplier team. We also felt we were in many ways inadequate as customers, not providing consistent feedback, or even knowing ourselves what we should have about our "business" due to lack of experience in, or det ailed knowledge of, the business which we were assigned to simulate.
Customers could be simulated in another way for which we have three ideas:
Each of these has it's advantages and disadvantages, but they are just something to think about. Given that none of the above might be practical or possible, we suggest at least combining the supplier and customer groups so there aren't conflicts in ever yone's schedules as there were with being part of two separate groups. This would allow for more interaction between the groups, which is another thing we feel is necessary. It is very difficult to communicate through huge assigned documents only, some things are simply better done face to face, and this would result in a clearer specification of the system for both sides.