CPSC 451 Customer Group 11
CPSC 451 Customer Group 11
This document discusses Customer Group 11's reaction to the product demonstration given to us by Supplier Group 11 on April 17, 1997.
Here we comment on aspects of the system that we did and did not like, and comment on how we feel the prototype conforms to our specifications. We also comment on the design process employed during the whole period up to the presentation, and how the group interactions were handled.
In our original requirements specification document we indicated that we would like to have seen a simulation of an actual interaction at a pump. We saw that in our supplier's functional specifications they had supplied screen shots for this type of interaction, but in their demonstration this topic was not discussed in detail. At the beginning of the presentation, it was mentioned that this system had a "revolutionary interface" and that it was the only system that accepted debit cards. In the presentation, however, these topics were not mentioned or discussed at all beyond that point. Considering this was a very important feature of the system, we were expecting to see a detailed simulation of the pump interface.
Specifically, we expected to see a complete run through of what happens at the pump. For example, we would have liked to have seen the actual steps the customer would have taken if they were to put gas into their car. We were interested in seeing the initial screen and any subsequent screens that would follow after the customer entered needed information or completed a particular step.
Also, it was to our understanding that the delivery person's interaction with the system would be through the pump interface and not through the head office's system. For example, if a delivery person would like to fill a tank, he or she should be able to go to the station and complete the procedure directly.
Security has been one of our great concerns and all we were presented with was a security feature for the head office remote operation. The fact that the system administrator cannot delete himself is a very good security feature and even that the delivery people do not have access to their passwords. It was also nice to see that unauthorized users would not be able to break into the system.
A feature we didn't originally specify but do like is the detection of login failures. It would be great if that could be extended so that after three failed attempts to login as a specific user, that user's account is automatically suspended and the administrator notified. But that's just an extra feature and is not required.
Part of the system that we liked was the logging of who has attempted to access the system and who has failed. We also want to have a history list of the users who have attempted to log in the system. The list should list not only the users who have been successful in logging the system, but also those have failed in doing so. We think this will increase the security of the system.
The following requirements were satisfied by our supplier group:
The following were requirements missed by our supplier group:
The report generation processing performed basically as requested. The functionality in the report generation was simple and straightforward. The implementation of color-coded bars to indicate the different months made analysis of the various graphs extremely easy. And the interface for report generation was extremely easy to use. These were all requested, and were delivered.
However, our expectations were not met in the following areas. More details should have been added for all kinds of reports. For example, in the credit cards report, it would have been more helpful to have a field explaining the reason why the credit card was rejected and what the result was (Returned to the customer or sent back to the credit company for destruction). Also, there was a very limited selection of reports, and those that were available could only display information about quantities for each month.
The consensus of Petro 451 is that the design process used to produce the projects for this class have the potential of being a very useful tool in software engineering. The interview process in particular was an excellent method of communication between customer and supplier. As well, giving the customers the opportunity to annotate the documents created by the suppliers allowed concerns to be communicated effectively. In real life we believe that the communication methods used in the design process, along with the design process itself are an effective and reliable way of conducting software engineering.
The design methods themselves are sound. However, the manner in which they are incorporated into the course content and the fashion in which they were monitored by the teaching assistant battered, abused and corrupted the process which was meant to simulate real life. We, the members of Petro 451, feel that our hands have been tied behind our backs in regards to our functionality as customers. Our mandate was to behave as real life customers, respond to products delivered by our suppliers, and "use the teaching assistants as consultants...they are a valuable resource." If we actually were able to simulate real life the outcome of our endeavours would have been significantly different.
The first noticeable difference would have been the immediate dismissal of Group 11 Oil and Gas Solutions as the supplier of the Automated Gas Station. We believe the correspondence received from this group was at times offensive, and very unprofessional. For example, one paraphrased incident: ..."what are you guys selling drugs...". Another incident involved their initial response to our informal specifications, which in all fairness, was meant for their eyes only. However leaks do occur in the corporate world, and in this real world, if that document had fallen into our hands, Group 11 would have been looking for work.
To add insult to injury, it was Petro 451 who was penalized for lack of professionalism. We have questioned this matter extensively with the T.A., and have yet to receive an adequate and useful response. We had hoped to get this information earlier in the course so that we could have avoided this from reoccurring. We assume now we never will. This brings us to our next point. We were instructed to use the T.A. as a consultant. In the real world, consultants are accountable for their actions, and can be fired. As a customer, would anyone in their right mind continue to pay someone who can not clarify their own work?
Petro 451 was also handcuffed when evaluating the Automated Gas Station itself. Being marked on the basis of having "something nice to say" is ridiculous. We feel accuracy is a more important criteria. The truth is the "prototype" of the system we saw met a fraction of the specifications. The "completed" portions of the system were shoddy at best, and the uncompleted portions which we never saw, such as the "revolutionary customer interface" were the portions of the system that should have been shown to us first. It is our opinion that not near enough time was used implementing this prototype. The excuse of some specifications being hardware issues wore thin after a while. We could still have seen simulations of how the hardware would behave. After seeing the presentation as it was, in real life, Petro 451 would have probably inquired whether the hardware manufacturers also designed software.
In conclusion, it is the recommendation of this group to make some changes in the functionality of the customer groups in Computer Science 451. Allow the customers to be more accurate in their evaluations without fear of the whimsical "individual" tastes of the teaching assistant. If we happen to disagree, this too happens in the real world, and we should not be penalized for it. Not too much can be done to prevent poor quality projects from being produced. Perhaps Group 11 Oil and Gas Solutions had a keener sense of what was required by the course than what their system could have been.
This page was edited by all the Customer Group 11 members except the WebMaster, and HTML-formatted by the WebMaster.
