Customer Group #9 Evaluation of Project: Gen U

This evaluation is broken down into the categories suggested in the course outline. The focus of this evaluation, however, is in the recommendations we have provided in the section on Proposals for Improvement.

Satisfying Requirements:

We take the original specifications to mean the informal specification document produced by us (the customer group). We were very impressed with the demonstration of the registration program by our suppliers. It flowed well and showed us the basic functionality we requested. The performance time constraints were met and exceeded.

The product had several extras such as context sensitive help, direct selection from the screen, and all information displayed on the same screen. The implementation of these features is a perfect example of how a supplier can give the customer what they want, when the customer doesn't even know it's possible, or what to ask for. This action will definitely encourage return business.

We required the system to be simple enough for a first time computer user to be able to operate easily, and this appears to be the case. Any student could add, modify or delete lectures, labs or tutorials easily. The restrictions such as class size, prerequisite checks, maximum number of courses registered in, and registration deadlines were all handled. The login security function meets our requirements. Although the online help was sufficient, we feel it could have been presented in a more pleasing manner.

Added to project:

Our requirements document vaguely defined the user interface, so as to allow the supplier more freedom in designing an easy to use interface. As such, the requirements focused on functionality. We did not directly specify the system administration functionality which the supplier added. The graphical user interface was a good addition to the project that we were expecting (we assumed this was understood, but did not clearly specify in the requirements document). The context sensitive help was just what we wanted, but once again was not clearly specified by us.

Subtracted from the project:

The multi-user capability was not demonstrated on the system. Due to time constraints we agreed to implement this at a later date. Also, the telephone dial in feature which was originally mentioned in our requirements document was sacrificed by mutual agreement, in favour of the graphical user interface. We feel this was a worthwhile trade-off. We still hope the dial in feature may be implemented at a future date.

At this time the product does not allow students to print time tables, or system administrators to print class lists. Our suppliers assured us this would be working in the very near future.

The only other feature that we discussed, but was not implemented at this time, was the ability to search for a student by last name. The suppliers did not feel this was a necessary feature.

Design Process:

We did not feel the design process was entirely suited to our needs. However, we did learn how to work (well?) in large groups. We accomplished a lot more when the work was divided and alloted to smaller groups, though. Natural group dynamics eventually resulted in small groups forming to do specific tasks regularly and on time.

We were made aware of the communication required between group members, and the supplier group. For example, from our original specifications the suppliers thought we wanted a text based system solely to support the dial in feature. This was discussed AFTER they had put a great deal of work into what they thought was the system we wanted. As it turned out, we were willing to sacrifice this feature (since it was very low on our priority list) in favour of the graphical user interface, and they had to go back to the drawing boards.

The course structure did not allow a lot of flexibility in the design process. If the purpose of the couse was to show us what we did not know, then it succeeded. If the course was to provide us with techniques to handle the problems, it did not give us much practical experience with them.

The size restrictions on the documentations encouraged us to focus on filler, rather than quality of the content. We felt that what needed to be said could have been said in a more efficient manner, in less space. This also made it difficult for the group reviewing the documentation, since the bulk made it less interesting, and the deadlines did not give us enough time to review the document before the next meeting.

Proposals for Improvement:

We hope that since the following proposals for improvement come from the heart, they will be taken to heart. We have taken advantage of this platform to express our concerns about the current course format, and instead of just complaining, hope that we have provided some positive direction for improvement. Afterall, one of the things we have learned from this course is that exposure to many different viewpoints is very useful. This is from the viewpoint of the student.

We did not feel that it would take a whole semester to introduce us to the problems. Since the learning cycle takes at least three exposures to a new concept before it is learned, we felt that three shorter projects could be used. The first exposure would be simply that - a first exposure - to concepts that are new and probably not understood. Without increasing the difficulty of the project, during the second exposure the student gets to work with the concepts through a directed exercise. The third exposure would be implementation on their own. An advantage to this is that it would allow students to explore different methods of development, rather than being restricted by the documents and the waterfall method. This would constitute a practical example of the theory behind CMM. To complement the projects, it is suggested that the first 15 or so minutes of each lecture be dedicated to discussion regarding the projects - the purpose of each document, the change from how the last project was done, etc. During this past semester there appeared to be very little connection between the lectures and the projects. This system may provide the necessary link.

Since there didn't appear to be a smooth flow connecting lectures, it is requested that the lectures and projects focus more directly on object oriented programming. While the projects conveyed many valuable lessons - the importance of communication, documentation, and timing - they could have included the importance of OO programming.

The timing on the deadlines for documentation was awkward. As it was, documents were due at 1:00 p.m. on Tuesdays or Thursdays, which did not give most people enough time to review the documents before the labs. This resulted in many 10 minute meetings, with plans to meet at another time not being very successful. If the deadlines were on Monday or Wednesday, the lab time would have been more useful. As a result we could have made better use of the TAs. Rooms should also have been designated for labs. A lot of time was wasted looking for an available room to meet in, then making sure everyone in your group, as well as your TA knew where you were. If the rooms were designated, the TAs could have attended on a regular basis, and conducted a mini-tutorial of about 10 minutes to each group. This would have cleared up some of the problems with documentation. Being available to answer questions does not necessarily mean we as students will know what questions need to be asked.

The short deadlines given to the customer groups played down the importance of properly reviewing the supplier documentation. If the role of the customer is actually an important one, the deadlines should be adjusted.

The importance of the customer reviewing the supplier documents was unclear. This experience may be valuable if you were asked to evaluate someone else's project (real world) to determine if it met the needs of the Customer.

Other suggestions included having the same project for all groups, so we could look at the same problem from two different angles. It was felt this would make it easier to come up with an interesting project, it would be easier for the TAs to grade, and it would encourage more discussion between fellow students that were not in your group.

Since part of our mark depended on the appearance of our web page, and documents, a tutorial (by the TAs?) would have been beneficial. Also, an addition to Mildred's web page providing links to all of the projects - even if it wasn't until after the project was finished - would have been interesting. This would have added to our experience by seeing how other groups completed their projects. While this is possible now, those of us that are new to the web were not able to take advantage of this process.

Overall, the course has been interesting and challenging, but as we have been taught - there's always room for change and improvement.