Final Evaluation of Project

Satisfaction of Original Design Requirements

From the demo, it is apparent that most of the modules (with the notable exception of the Billing System) have been successfully implemented by our suppliers. The screens appeared just as described in the User Manual, and the functions appear to be intuitive and relatively simple to use.

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.


The demonstration on the publication section was very brief. The supplier group only presented half of the functions that were available. The functions that were presented include adding and editing a publication. The demonstration on the adding function was well presented except for the system crash when they tried to edit a publication. When the system was rebooted again they showed us how to add a new publication by clicking on new and entering the required information for the following fields:

  1. Publication Name
  2. Publisher Name
  3. Distributor Name
  4. Distributor Phone
  5. Publication Type (e.g. Newspaper, Magazine)
  6. Publication Frequency (e.g. Daily, Weekly, Monthly)
  7. Key words (e.g. Automotive, trucks, Calgary)
  8. Number of Subscribers (default is zero)
  9. Publication Description
When the information was saved, we were able to see the new publication on the list of existing publications in the database.

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.



The interface of the 'Households section' was clean and easy to understand with well labeled buttons for different operations and grayed out buttons for those unapplicable operations.

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.

User Manual

The demonstration of the 'Households section' was consistent with the user manual.

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.


The demonstration succeeded to bring out the things that the demonstrators wanted us to know for the 'Households section', such as the search of a customer and the adding of a new customer. However, the demonstrators could not have covered all the operations concerning this section due to the time limits. For example, the 'Edit' mode of the customer was not mentioned until we asked about it. Perhaps the demonstrators should have utilized the limited time to cover more operations to us instead of introducing the team members.

As well, the smoothness of the demonstration was disturbed by the bugs in the software. This affected the confident of the customers.

Functionality Summary
Publications Adddemonstrated, satisfactory Comments:
Deletenot demonstrated
Editdemonstrated, satisfactory
Households Adddemonstrated, satisfactory Comments:
The Search function was
very flexible, which is
what we were looking for.
Deletenot demonstrated
Editdemonstrated, satisfactory
Searchdemonstrated, Good!
Carriers Addnot demonstrated Comments:
The delete function still doesn't
ensure database consistency, which
is necessary before this could be
considered a production version.
Deletedemonstrated, satisfactory
Editnot demonstrated
Routes Adddemonstrated, 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.
Deletedemonstrated, satisfactory
Editnot demonstrated
Searchnot demonstrated
Printoutdemonstrated, unknown
HelpNot Demonstrated

The Design Process and What We Would Have Done Differently

At the beginning of the project, we would all meet at one place to attempt to produce what was expected. This never seemed to work very well, for most of our time was spent arguing, socializing over other topics, and otherwise wasting time. As time went on, one person would get organized and split up the project into subsections that could be assigned to others. This worked far better for time, but tends to produced a document that has many different (and sometimes conflicting) opinions.

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.

Back to our main page

Last Modified Apr. 7, 1996 by
Darrell Nash