Satisfaction of Specifications

Introduction

The general purpose of the system is to computerize Northam Papers by providing an easy to use customer database and delivery system. Customer specifications laid the foundation of the functionality of the Mammoth system. Functional specifications were then produced and provided a rough guide of the minimal system. Based on these specifications, the Overall and Detailed design documents were generated. These two documents formed the contract between Gorilla Soft and Mammoth. It is worth noting that the accounting and invoicing features were originally included in the Functional specifications but were removed from the Overall and Detailed design documents.

In general, the Overall and Detailed Design documents were organized into the following sections

General Customer Functions

Household Customer Functions
Retail Customer Functions
News Box Functions

General Delviery Functions

Carrier Functions
Delivery Route Functions
District Functions
Zone Functions

Publication Functions

Magazine Information Functions
Newspaper Information Functions

Report Functions

Daily delivery list generation for Carriers and Drivers
Demographics reports

The Mammoth System addresses most of the functions outlined within the Detailed design document. Only minor areas are incomplete in terms of functionality, mainly due to time constraints. The current Mammoth system does maintain a database of all working information needed for future expansion into the full blown version of Mammoth.

Other areas not specified in the Detailed design document include the areas of usability and efficiency. Areas of Human Computer Interface still need to be fully addressed to determine the full usability of the system. Also needing attention are areas of efficiency of the overall database when extended to the full two-hundred-thousand expected customers.

General Customer Functions

Household Customer Functions

The functions in this section (find, add, edit, delete and print) all worked and allowed the maintaining of a household customer database. The print function was not fully developed (at least to Gorilla Soft standards) and only printed out a screen shot of the form instead of generating a full report of the particular customer. In essence, the print function was fully working and up to the specifications outlined in the Detailed design document, though ideally it would be evolved into generating a more representative report.

From the household customer form, the funtions to find, add, edit and delete subscriptions were all available and functioning to standards outlined in the specifications. In addition to the specifications, features like providing carrier information, prices of products, and weekly delivery prices, were also available.

Customer complaints section was also available and fully functioning allowing the addition and tracking of complaints for individual customers.

Retail Customer Functions

As with household customers, functions in this section of find, add, edit, delete and print all worked and allowed of the maintaining of a retail customer database. The print function was not fully developed to Gorilla Soft standards although it does fulfill the specifications.

The ability to find, add, edit and delete newspaper and magazine consignment was fully available and functioning within the Mammoth system. An alternative viewing/finding function for magazine products was developed but was not linked to the general system. This additional function allowed viewing of all magazine products a retailer consigns in one form. It was hoped that further development of this function would add another layer of functionality into the system.

The customer complaint section was fully available (this is the same function as used for household customers). Due to time constraints though, it was not properly linked into the demonstration prototype.

General Delivery Functions

Carrier Functions

The maintenance of the Carrier information database is fully functional at to the outlined specifications. The ability to find, add, edit and delete worked to maintain information about individual carriers. As mentioned in other sections the print feature is available to the outlined specifications but does not produce a layed out report.

Delivery Route Functions

The delivery route information functions of find, add, edit, delete are functional and work to maintain a delivery route database.

Districts Functions

The districts information functions of find, add, edit, and delete are functional and work to maintain a database on the district in which customers and news boxes reside.

Delivery Zone Functions

The delivery zone functions of find, add, edit, delete are functional and work to maintain a database of delivery zones in which carriers deliver to.

Publication Functions

Magazine Functions

The database of magazine products available to Northam customers is full functional with the use of the find, add, edit and delete functions. These functions allow the maintenance of a potentially huge database of magazines and their various prices.

Newspaper Functions

The database of newspaper products available to Northam customers is fully functional with the use of the find, add, edit and delete functions.

Report Functions

Daily delivery list generation for Carriers and Drivers Functions

The generation of delivery lists for carriers and drivers is functional to the specifications outlined. Generation of this list traverses through the majority of the available tables within Mammoth and properly updates them.

A list of houses on each carrier's list is generated, only including those households who require a delivery on the specific day. The item to be delivered, number of copies as well as special delivery comments are produced for each household customer included. Customers included are ones who have not put deliveries of newspapers on hold and have newspapers to be delivered on the particular day of the week and/or magazines remaining on their subscription that need to be delivered on the specific day (magazines may be delivered weekly, biweekly, monthly or bimonthly).

A list is also generated for each driver. These lists detail a route that includes a listing of news boxes, and retail outlets that need to be delivered to. As with carrier lists, pertinent information of what products, and the amount and special delivery comments are also included for each new box and retail outlet. Missing from this list are carrier drop points, in which bundles of products are to be dropped off to each carrier for further distribution. Unfortunately due to time constraints, this minor part of the function was unfinished.

Demographic Reports

Due to time constraints none of the function to create reports were finished. All necessary information is stored within the Mammoth System thus it only requires a minimal amount of time to create these functions.

Design Process Evaluation

At first, our group's design process was not very organized. Group meetings were very much dominated by conversation in which we were trying to directly deal with specific system requirements. Our time would have been better spent if the group concentrated on the general system functionality which is adding, modifying, and deleting existing data elements in data structures. Proper organization of data structures is very beneficial to the system, considering that system is nothing more than a database which needs to be constantly nurtured.

A great deal of time was devoted by the group in producing a large amount of documentation. The documentation served its purpose in aiding design but overshadowed the actual implementation of the system. If small prototypes were experimented on in the earlier stages of design process then we would have gained a better knowledge of system functionality and behavior. This interim would have aided the production of a great deal of the documentation. A large contributor to the difficulty of the system production is quite visibly the lack of experience by all of the group members in creating and documenting the system.

If our group was given the chance to work together on another system, there are many things that we would have done differently. First of all we would have started implementation at a much earlier stage. Leaving implementation to a later stage, caused us to try to rush out working product. Secondly, the documentation would be an ongoing process. We seemed to try to do the documentation all in one foul swoop, this took away from the final product. Also the group work would have been spread out more evenly. There were a few people who seemed to be doing the majority of the work. As a result some people had only a vague knowledge of the system. This lead to confusion, and a lot of repetition in the documentation.

One good aspect of the design process, and this project, is that we all came out with a better understanding of group interaction. Everyone seemed to find a niche in the group, whether it was documentation, implementation, or any other aspect of the design process. This lead to more efficient use of group members, and group time.

Proposed Changes to the Assignment

By far the biggest change that our group felt necessary was the use of object-oriented design and analysis. We think that the first few lectures should have been a crash course in OOD and OOA. Our group only had knowledge of structured analysis and design. In our opinion this was a hindrence, not an asset. The assignment should have been an application of OOD and OOA.

We also believe the projects should have been more tightly specified. In our case the system rapidly grew to encompass far more functionality than we could have ever hoped to accomplish. This was largely due to the customer group's expectations. If the projects specified more exactly what functionality had to be included feature creep would have been more easily avoided. Our project proved to be a land-mine of features. It was this way not because we were being ambitious, but because the project was so vague.

Lastly we think that the student questionaires that were administered at the beginning of the class should have been more explicit. For example, one question was along the lines of, "Do you have experience with Access?" A better quesiton would have been, "Have you every developed an application with Access?" In our case, we had five people with Access experience. None of us had ever put together an application.

The Test Plan

Our test plan was definitely under-utilized. Unbelievably, the implementation people did use it to do some unit testing. However, there was practically no formal integration testing. Once again, had we focused the project more tightly, we probably would have made good use of the testing plan.

The testing plan did serve a purpose in that it made us think of just how many things had to be accounted for. After writing a lot of the test cases many of the functions were re-designed. In this sense it was useful.

Planned and Unplanned Group Structuring

Our group did stick more or less to our original attempt at group organization. It did this largely because our design was very flexible.

Basically, we had a group leader, a head of documentation, and a head of implementation. Every one else was free to move from sub-project to sub-project as necessary.

The group leader stayed in his role for the entire project. Originally, the documentation manager was supposed to have the final pass through each of the documents. However, this quickly became the role of the group leader (largly because he had worked as a proof-reader).

The managers quickly over-lapped their roles. Infact, by the end of the project they were working side-by-side on implementation. This came as a big shock to everyone as earlier on in the project they pretty much locked horns on a regular basis.

The rest of the group moved from sub-project to sub-project as they saw fit. We did try to over-lap one sub-project with another throughout the semester. This gave people a chance to hop back-and-forth. This was hoped to keep boredom to a minimum, as well as keep us moving forward. However, certain members quickly became entrenched in certain roles. For instance, two members of the group ended up putting together a large part of each assignment together a few days before the deadline. As they finished up two or three other members went through what was done and made any additions (usually lots) and fixes that were necessary. So, we found that a sort of pipe-line quickly appeared.

Times Taken

Here is a summary of the estimated times for each of the components of the supplier component of the course. In our opinion the percentages are probably much more accurate than the numbers of hours. These were come to in about five minutes of discussion with between the whole group.

Functional Specifications	16 hours	10.8%
Overall Design Document	25 hours	16.9%
Detailed Design Document	35 hours	23.6%
User Manual	28 hours	18.9%
Implementation	32 hours	21.6%
Presentation	12 hours	8.1%
Total	148 hours	100%

On average we spent from one-and-a-half to three hours in the allocated labs. This usually included at least two-thirds of the group. It also seemed that there were meetings every second weekend. These meetings lasted between four and six hours and usually included between one-third and one-half of the group. One average each group member spent between one and three hours each week working alone.

It seems that the most work was accomplished during the weekend sessions. The labs basically gave us all a chance to touch base, but useful work was definitely accomplished during the lab sessions.

Were This the Real World

If this had been a real project, we would have done things much differently. To start, we would have had a team of one or two individuals work as liasons with the customers up until the point where a reasonable specification could be drawn up.

At that point we would hand-pick a design team based on experience. The design team would begin drawing up the system. The liasons would still work with the customers as design continued. At as early a stage as possible some sort of prototype would be thrown together and displayed to the customers to further focus the specification.

As the design process winded down, we would move some of the designers to implementation as well as adding some additional implementation specialists. These would include Human Computer Interaction, Database, and Network specialists. Meetings between all the implementation specialists as well as the designers and liasons would occur very frequently. Again a more functional prototype system would be thrown together as quickly as possible to let feedback from the customers flow back through the liasons to the designers and finally to the implementors.

This prototype-refine process would continue until a satisfactory working product was finished. Note that, unlike some large software companies, we would not release the product until it was in fact workable. The decision as to whether the system would be workable or not would be left to the customers.

Lessons learned

It came as a surprise to no one that working in a large group in a university course environment is an almost impossible challenge. Undoubtedly every team member expected from the start that it would be difficult working in a team of twelve people. Perhaps the lessons learned here will come from recognizing that even though team members expected the difficulties from the start, not much effort was invested in processes to deal with those difficulties intially or as they arose. So, the lesson learned here was that processes must exist for every situation that can be encountered. If a new situation is encountered a new process needs to be created.

The aspect of the project where most team members felt that useful lessons were learned is in the area of Communications. Communication within the team and with the customer are vital to the success of the project. More specifically, within the team, communication amongst team members is vital to get the project going and to keep it flowing. We found it absolutely crucial to have an effective way of knowing who is working on what, the details of what everyone is assigned to do, and the status of their assigned tasks. The university environment is a very difficult one in which to try to emulate what could go on in a real project. The lack of common space (e.g., a team room) for the group to use makes team sharing of information difficult. The transition from face to face contact, use of paper/white board, etc., to a Web page as a means of sharing information is not as seamless as we might think. We learned that by far the best method of communication is face-to-face as often as humanly possible.

A tremendous amount of time was devoted in this course to preparing lengthly documents. The completion of these documents, their use in setting requirements, and communicating designs to our customer group became the focus / obsession of the effort. A lot more time should have been spent working face to face with a customer liason group on the specs and designs. Paper (or Web pages) should not be the way in which a software developer interacts with a customer.

An accepted practice for working group projects is to break the large task into smaller more manageable ones. After working through the subtasks, the different parts can be assembled to satisfy the larger task. An important lesson learned is that while this approach sounds fine in theory, in practice with a large group it is extremely difficult to accomplish. The reality is that without a high degree of specification for each subtask, assembling the overall product usually takes a lot of rework. The other reality with splitting a team into subtask teams is that once subdivided it becomes very difficult for the subgroups to resist going their own way without much regard for how all of the components contribute to the whole.

Having experienced people is the strongest asset a team can have. While several team members had some experience with the chosen development environment, the degree of experience was not adequate. The lesson is that any team assembled needs to carefully choose the development environment.

There is some debate within the team around what they learned regarding the adage "the Customer is always right". Some felt they should stick to this adage. Others felt that the customer only thinks they know what is best for them. Regardless, a common lesson is that a good project team should be open to investing the time to understand the customers needs.

Back to Project Evaluation Title page