UnReal Estate Catalog System Project Evaluation

Supplier Group #10

April 17,1997

• Satisfaction of the original Customer Specifications
• Usefulness of the Design Process
• The Test Plan
• The Management Structure
• Comparison of the time taken for each portion of the Project
• How the Project would change if was to be done in the "Real World"
• Things to change to make the project less work
• Lessons Learned
• Group Structure

The only portion that was not fully complete was the Import and Export of mass listings. These two functions were an enhancement to the original specifications that we at RIP thought would be needed and were not completed simply because we received no formatting specifications from UnReal Estate Inc.. These functions are already partially included and could be completed and fully tested for the company within three days of receiving the formatting information.

Back to Top

Another concern that our group had was the interaction of the Customer and Supplier groups. The Customer group cannot fulfill its Supplier’s needs with a simple and uninformative response to the massive amounts of information they receive. Several pages of comments cannot possibly cover all of the problems that a 100+ page document can have. One possible way of fixing this problem is to set one or several people as liaisons for the two groups and having them report back to their groups every week. This seems like a lot of work for that one or two people that get this job but it must happen to limit the size and number of errors in the document and subsequently the analysis.

Supplier Group Ten fortunately did not suffer the problem of lack of communication with its customer group to the extent that some other groups did. We were blessed with an excellent leader who took charge from the beginning and followed through until the very end. We also had an excellent idea of what and how the problems could be solved. This led to our group working smoothly and efficiently through the duration of the analysis and building of the UnReal Estates Catalog System.

Back to Top

Another thing that we did was to set one of our members to perform a regression test of the entire program. This included the observation of all help contexts, the performance of all of the tabs, buttons, displays and the error messages that came out within the program. All of the errors found were reported to the programming team and fixed at the soonest possible time. To do a true regression test would have taken the entire team a great deal of time and this was not feasible but the combination of the testing continually throughout the design process and the major test at the end the program is well tested.

Back to Top

We found it difficult to keep the group structures for the documentation in accordance with our original Management Plan. People moved from group to group, working on things that had to be completed. This had to happen simply because people had projects from other classes or from outside of school that would not allow them to spend the required time on that document. Our group leader delegated the responsibility well and we had no serious overlapping or document that was undermanned. To the point we followed our management plan very closely and adapted to any problems very well.

Back to Top

The Overall Design Document was also a problem with many of our members. This could be removed from the timeline or more likely incorporated in to the time spent on the Detailed Design Document. Since the ODD was a building block for the DDD we believe that using the extra time on simply building the DDD would have been beneficial and would have produced much better quality documents.

Back to Top

Another constraint that would have been removed in the business world would be that of the laborious documentation. Not to say that documentation is not needed in the real world but a lot of the documentation for the project contained a lot of "filler" to meet the number of page requirements. The Documentation time line would have also been specified by the Supplier in the real world not by an outside source. This would lead to a much less rushed set of documentation and thus, documentation of a better quality.

One of the most important differences would have been the removal of other outside factors that limited the amount of time that the group could work on the project. Several of the experienced members said that once you are put on a project you work on it and maybe several other small projects until completion. Few people in the real world have a daily work load as large as a student taking five courses (three of which are CPSC major classes). The fact that we would have been able to put a majority of our time and thought in to the project in the real world would have produced a much more comprehensive and complete system for our customers. (This is not saying that our system is not complete, but a lot of other groups have encountered this problem.)

Finally, a different approach to coding and testing the system would have been used. In industry, people that know how to engineer software are hired. All of the members in the group would be expected to work to a specific level of efficiency and all would have had access to the program. These are problems that the course seems to ignore. There was no dedicated software package for building a GUI-database program in a realistic fashion. A Client-Server version of Visual C++ or Delphi should have been available to all of the members of every group so that they could all work on the project, even to a limited extent. All of the people that have worked in industry in our group agreed that the fact that no platform existed hampered the coding and testing process immensely

Back to Top

Our group also spent quite a bit of time trying to understand the assignment specifications. We felt that the assignment specifications could have been more detailed in some areas. A lot of the time the assignment specs seemed to be quite ambiguous and not very clear at all. A good portion of our group meetings were spent on discussions of what exactly the assignment was about and what details the TA's would be looking for. This leads us to another area that ate up a lot of group time. It seemed like the majority of the time the TAs were not very clear on what they were actually looking for on specific assignments. When asked, the TA's could not give our group members any clear or straight answers on the marking scheme or the specific details that they were looking for. So in most of our group meetings we were left with the task of actually guessing what the TAs would be looking for. Unfortunately, our group wasted a lot of time on these topics.

Our group also felt that the actual length of the documents was a little wasteful of time and effort. It began to seem that quantity was more applauded than qualtity. We would have rather pointed our efforts towards the actual design techniques rather than the length of the documents. Focusing our efforts on producing long, boring discussions of something that could have been said in half the amount of space was very labourous and time consuming. It would have taken individuals a lot less time to get straight to the point rather than trying to discuss all topics extensively just for the sake of document length.

Another major area for time consumption for a few individuals was the actual coding of the product. It turned out that only one or two individuals knew the same programming languages. So we ended up picking a language that only a couple of individuals were very familiar with. Although we had twelve people in our group, only one or two people actually coded the project. As you could imagine, this ate up a lot of time for those individuals. Perhaps a brief overview of an object oriented, GUI interfaced programming language could be taught in this class or in a prerequisite class. This would alleviate the work load for the programmers in each group.

Also, more meetings with the Customer group would have aleviated a lot of confusion. A lot of the time, we thought that we were on the right track as to what exactly the customer was looking for, but then in the following assignment there always seemed to be a requirement that we were not aware of. If the flow of communication between the customer and supplier group would have been kept up, this problem most likely could have been avoided. Because organizing a meeting so that everybody could attend from both the customer and the supplier group would be quite hard, maybe a weekly meeting time that would be set by the lecturer would help in this area. If the flow of communication could be kept up, a lot of confusion and extra work could be avoided.

Back to Top

Another main lesson that our group learned was that an effective leader should be elected before we dive into the project. An effective leader should be able to ensure that the flow of communication is maintained, should have great management and organizational skills, and should have strong work ethics. Our group was very fortunate to have a leader that had all of the qualities listed above. Our group leader was able to organize individuals into subgroups for each assignment. He was able to maintain the flow of communication between these subgroups so that two different subgroups were not working on the same thing and so that all subgroups would produce a document that was consistent in some sort of way. Our group leader was very disciplined in his work habits and work ethics and was able to motivate other group members to have the same sort of discipline. Without a group leader, our group would not have been able to produce documents of the type of quality that we have produced.

We also learned that trying to work as a whole on the assignements could become quite difficult at times. The most effective way to deal with such large assignments and such a large group was to split the assignment into smaller parts and then to split the group into sub-groups. This way, for each individual, there were less people and there was less work to worry about. This also allowed each subgroup to meet more conveniently since there were fewer timetable conflicts to deal with.

This leads us into the topic of consistency. We learned that it was essential to set a standard way of writing the documents so that the editting stages would be less work. Setting guidelines and standards for each assignment helped guide the authors of each section and produced a document that was thoroughly consistent.

Another important lesson that we learned had to do with trust and honesty. Individuals had to trust that all other members of the group would be able to finish their part of the assignment on time. On the other end, individuals had to be honest as to how they were doing with respect to their part of the assignment. If honesty was not met, then individual group members would find it hard to trust their peers.

Back to Top

Throughout the semester, people's roles always seemed to change. Although some people said that they would code, at some time they would end up doing a little technical writing. One individual seemed to land the position of "head programmer" even though no one had elected him. The following break down of the semester will show you how the roles of certain individual's changed throughout the term:

First meeting, preassigned duties:

Duties people actually had fulfilled by the end of the term:

Back to Top