The Household, Publication, Carrier, and Route Modules hold up well in comparison with the User Manual's specifications and performed mostly as expected during the demonstration. Below is a detailed explanation of some of the primary functions of the system and how we felt our suppliers dealt with them, followed by a quick summary table. At the end of this document resides our brief opinion on how the project as a whole was executed, and what we would have done differently.
Some problems that we witnessed are as follows:
Changing the type of publication and a keyword addition was demonstrated in the edit function. After a change was made the 'Save' button was pressed causing all the edit fields to be cleared and returning the user to the search screen. A confirmation of the change would be preferred; as it stands now the user has recall that publication record to verify if indeed the change had been made. For the most part, the edit publication function worked as stated in the user manual and design document. The data entry was particularly nice with format of the input (e.g. the brackets and dash for the telephone number) already on screen thereby prompting the user to just fill in the numbers.
Again due to time constraints, the search function was not demonstrated. In particular we would like to verify that the keyword searches work and if there is any limit to the number of keywords that a publication may have.
It appeared that the price field was missing from publications in the database. The suppliers claimed it was part of billing, but we disagree. The price of a magazine or newspaper is expected of any publication system, for our customers will want to know. We have no idea why this wasn't implemented, for it would appear to be a relatively easy thing to do.
In general, the demonstration on the publication section was fairly well done except for the system crashes that occurred. If the package could be fixed to working order, we believe that the publication section has satisfied our original requirements. We see no new additional functions or subtraction of functions from our original specification for this section.
However, we found the software did not fully utilize the width of the window. For example, the software only displayed the upper part of the interface during the demonstration and it was annoying to scroll the screen down for the customer list which located at the lower part of the interface. While we observed that there was a lot of space left at both sides of the screen. Perhaps the interface can be rearranged with the customer list on the right side of the interface so that the width of the window can be fully utilized and the user has no need to scroll the screen frequently.
Another point that we found lacking was the inability to directly enter U.S. zip codes; the system presently only seems to allow Canadian postal codes. This could be implemented quite easily, and is perhaps just a detail that got pushed to the back burner, due to time constraints. The current solution to entering U.S. states or foreign countries in the field for 'Province' on the Add Customer screen is tedious; but once again, the ability to permanently add new states/countries to the listbox is likely an easy addition, and does not indicate a fatal shortcoming in the system.
One rather annoying part of the interface was that each time a new mode was selected, a new window was produced. There were tabs on the side to change modes, but instead they introduced a new window with each click.
The fact that a household's subscribed info was not displayed in the "Subscribed to" box was annoying. It was stated that it would work if there were at least 2 publications, but we have no proof of this.
As well, the smoothness of the demonstration was disturbed by the bugs in the software. This affected the confident of the customers.
| Publications | Add | demonstrated, satisfactory | Comments: None |
|---|---|---|---|
| Delete | not demonstrated | ||
| Edit | demonstrated, satisfactory | ||
| Search | ? | ||
| Households | Add | demonstrated, satisfactory | Comments: The Search function was very flexible, which is what we were looking for. |
| Delete | not demonstrated | ||
| Edit | demonstrated, satisfactory | ||
| Search | demonstrated, Good! | ||
| Carriers | Add | not demonstrated | Comments: The delete function still doesn't ensure database consistency, which is necessary before this could be considered a production version. |
| Delete | demonstrated, satisfactory | ||
| Edit | not demonstrated | ||
| Search | ? | ||
| Routes | Add | demonstrated, satisfactory | Comments: Delete - no database consistency yet, necessary before this could be considered a production version. Printout - we have their word that it works; no printer was available, and attempting to print caused a crash. Probably just bad luck. |
| Delete | demonstrated, satisfactory | ||
| Edit | not demonstrated | ||
| Search | not demonstrated | ||
| Printout | demonstrated, unknown | ||
| Help | Not Demonstrated | ||
In truth, we feel that the process both us and our suppliers used hindered the creation of the desired product rather than helping.
Much time was spent writing and reading documents, where it could have been much better spent consulting with our supplier group. We could have been going over first draft documents or testing prototypes instead. A cooperative approach in which we work with the suppliers as they produce rapid documents and prototypes would have a better chance in them producing a final product that we expect.
The supplier would spend a lot of valuable time producing a document that we were expected to find errors with. This kind of expectation hinders the design process, produces a competitive relationship between the two groups, and is generally unnecessary if proper communication is occurring. Under a more cooperative approach, the paperwork generated would simply serve to document what had already been agreed upon, instead of constant and useless bickering.
The expected length of the documents further hampered the process. As both of our guest speakers in the lectures had claimed, a document should contain as few words as necessary to state clearly what is expected. However, the unreasonably large "quotas" issued to us encouraged the exact opposite behavior. As a general example, we would come up with what was needed, write it down, realize that it is not even half of our target length, and would end up throwing out huge amounts of "filler" material. The original document was very readable and much more brief than the the final document that we would have to submit. No one wants to read (or write) an overly lengthy and verbose document. Overall, we feel that the project specifications should allow much greater freedom for the students to decide which process they want to use. This encourages experimentation and greater learning, as well as hopefully producing better documents and allowing more time to communicate between groups rather than worrying about deadlines for drawn-out documents.