The system consists of six main sections. This is a brief description of the sections as they were implemented in the program from the specifications. Below the actual functionality of the screens will be discussed. The main sections include:
The functions that carry across all screens with the exception of the billing system are as follows:
A record of money owing, or other billing system related reports are not available in this version of the project.
As you can see, the demonstrated product adheres quite closely to the minimal system we promised the user.
The minimal system that will be implemented is separated into five major subject components: customers, publications, subscription, routes, and carriers. Each one of these parts will contain functions that will allow the user to add, modify and delete their perspective data. This data and the rules for its entry are covered in the previous paragraphs. There will also be various functions that allow the user to view the data of one of the subjects by individual record, and by a group of records.
There are also more specific functions. A user will be able to suspend a customers account for a specific time period or indefinitely. There will also be a function that will create a print out of the days deliveries as was specified previously.
Due to perceived time constraints this proposed system will not contain a billing system. After much discussion it was determined that the billing system was too complex to be created as scheduled. An enhancement that may be added in the future is to add a partial billing system. This would not include anything as specific as a list of payments for a particular invoice, but more likely would include enough functionality for it to work along side a separated billing system. Some the functions covered in this system would include summary showing total monies owed and total number of subscribers by publication, daily summary information showing how many copies of each publication were sold that day, ability to generate bills for households, and ability to update balances when a payment for an invoice is received.
Although the specification of the groups remained constant the membership of them did not. This was largely do to the fact that the work needed from these groups (i.e. documentation, implementation, presentation and interface) was not evenly distributed throughout the course of the semester. However it worked out better to have flexible groups, because it allowed a more efficient use of human resources.
All of the information produced in the meetings was not always posted somewhere as originally planned. But due to time constraints it would not have been feasible to do it anyway, i.e. it took too much time to post everything that was happening and no one had time to look at it when it was posted. At times this did cause some confusion as to what each subgroup was working on but this situation would always be inherent due to the time constraints given and not something that could be fixed if this project was done again.
The initial testing plan was not fully implemented. This was do to the fact that the implementation of the project took longer then originally planned. However, testing was done by the programmers while they were creating the system and some was done later on by the members of the demonstration team. Many of the system's bugs were caught during the testing. But of course Murphy's Law, which states "Anything that can go wrong will go wrong", came true during our demo. Unfortunately we did not manage to test for all the possible errors and they picked an opportune time to show up. The most noticeable bug occurred when we changed computers. The system was designed on a standard desktop PC using Windows 95. For demo purposes we transferred the program to a laptop thinking, naively, that everything would work the same. Not so, the system did not seem to function as it had on the desktop PC. The major bug that was encountered however was not due to the lack of effort of the members on the our programming team, but they were due lack of effort on the Microsoft team (i.e. Windows 95 is still somewhat bug ridden).
This project demanded more on document writing than the actual software development. Although having a working program was crucial for the demo, the majority of the marks are earned from writing functional specification and various design documents.
As was just mentioned above, most part of the project focused on writing documents which were part of the design process. Interfaces between different modules were defined in the design process. The design process was complete enough to be used as a reference from which our group could produce code and a user manual, and carry out tests. Overall, the design process helped to reduce the time in coding.
We would still split into subgroups, as that is a real time saver during meetings and helps avoid scheduling conflicts, however we would meet more often as an entire group and go over any comments or problems that anyone has. This would help the documentation people know how far the programmers are and vice versa. This would be known as internal communication which was not too much of a problem within the supplier group. External communication, that is communication with our customer group, was limited. So much in fact that we only met with them on one occasion. To improve communication as a whole, more emphasis should be placed on supplier-customer group meetings.
On a related topic, given that the documentation team was separate from the programming team, when the documenters had to write the user manual and design documents, they had to make up how they thought the system should look and not in fact how it would. In essence there was a lack of communication between the two teams. To prevent this problem we, as a group, should have met and discussed in more detail how the system would specifically function. To help combat this specific problem, we think that the framework of the program should be completed well before the presentation. It would then be more clear to find any errors or problems in the system or to even see if it works at all. For such a relatively small project, we don't think that is too much additional work, and it would increase the quality of the final product as well as the documents concerning it.
Another way we could have made the project less work is by explicitly stating how the various documents should be written. For example, during the user manual, we divided the sections, e.g. Customers, Publications, Carriers, etc., and gave one to each person of the documentation team. However, before hand we did not go into very much detail on exactly what should be done for each section, and as a result, two days before it was due, we discovered that everyone had done it differently. It was too much work for the editors to fix, so each person had to redo their section so that they all matched. This type of situation occurred frequently and as a result each document required a considerable amount of editing to ensure integrity and uniformity. If we would have discussed this earlier, we wouldn't have had to do all that work over again. And this was not the only document in which this happened. As a result the editors of our documents had way too much work on their hands, work that could have mostly been avoided. With better communication as to the format of the sections, both the editors and documenters would have to do less work.
This leads to a most important topic, document standardization. In a project that required huge amounts of document writing it was essential that all submitted documents conformed to a physical standard. That is format and layout as well as writing style. For the first few documents this was a problem. Each group member had their own ideas as to how the document should look. This was a nightmare for the editors who had to take all the sections, combine them, then organize them. To combat the problem we sat down and discussed a standard submission format. This worked much better and reduced the overall amount of editing. So for future groups we would like to stress the importance of documentation standards. You will thank us in the end.
We also should have chosen to implement the system using a language/program in which more people were familiar. We used Access, with which only one person in our group had previous experience. As a result, the programming team first had to learn how to use Access before they could even start. And since it was for Windows 95, only three people in the group could use it and had the software at home. Access also does not lend itself well to teamwork as much as some of the other languages we could have chosen, and as a result in the end only a couple of people did the majority of the programming.
As mentioned before, there should have been more meetings with the customer group. Hearing vocally their concerns would have been much more effective than reading them in a document. Even though there were a few meetings, I think that more meetings would have led to a final product that would better meet the customer's requirements.
To help reduce unnecessary work, I think the project outline itself should be written more clearly. Instead of stipulating the number of pages that a document should be, let the groups decide for themselves, using the number of pages as a guideline. By specifying the number of pages we sometimes felt that our document was too short so we introduced "filler" to make up the remaining pages. This led to redundancy. As well, the number of pages expected in each document seemed excessive. If a minimum size of a document was not enforced, we believe that document quality would increase as more time would be dedicated to quality rather than quantity. We also believe this would more similarly model the real world. Customers do not want to read hundreds of pages of similar if not redundant information, they just want a concise document that answers their questions and addresses their concerns.
Although we almost neglected the design of the interface as a group, we feel that it is one of the most important parts. The drawing of storyboards should have involved the whole group, allowing us to test that the program made sense logically and to make sure that the whole group understood every detail. We detected many oversights while writing the documents which could have been avoided if the interface was better known from the start. To help alleviate this we recommend that at least one of the team leaders have taken CPSC 481 to allow implementation of the methods learned in that course.
A real project would not necessarily include a time constraint. It would be the responsibility of the suppliers to estimate the length of time to produce a program, according to their past experience or other methods learned during this course. The supplier could even postpone the delivery of the final product if it were not be possible to deliver on time. This would allow the supplier to complete the project thoroughly. Just think of what Windows 95 would look like if Microsoft could not postpone the delivery date (although it could still be improved).
The customers would most probably not be Computer Science students or Computer Science graduates. They might not have the knowledge, the resources, or the understanding of the problem to produce a complete set of informal specifications. In those cases, the supplier would have to meet with the customer and try to get the information using specific methods such as questionnaires and a first draft of interface storyboards.
Our supplier team appreciated greatly the efforts of the customer team in giving us feedback on the formal specifications and on the user manual. The constructive input they supplied us with might not be of the same quality coming from a customer who is not as knowledgeable when it comes to Computer Science. Again, the supplier might have to meet with the customer for a demonstration of the product. This demonstration could be done using scenarios to describe situations where the customers would use the program in the future or story boarding to get feedback on a second draft of the interface design, providing an additional level of detail by creating an illustrated version of the scenarios.
As Computer Science students we all have access to at least one computer connected to the Internet. Also, most of us have been exposed to the use of a web browser and to the techniques involved in designing a site on the web. It would be inappropriate to expect all of our customers to have such access. Frequent meeting with printed documents and telephone communication could replace the very useful media that is the Internet. And if the purpose of using the Web was to save paper, well this proved to be almost impossible. We required many pages of printouts to allow for design layout and content. However the Web increased accessibility and promoted increased communication.
For our project, the testing part was not an ongoing process but merely one step negotiated quickly with the customer team. A real life situation would necessitate thorough testing. Each step of the design should be tested with future users. Scenarios should be shared with them to verify that we are on the way to completing the expected piece of software.
Involving the user is one priority of designing good software. During the project, this task was an easy one as the customer team was easily accessible through the web and around the department. The difficulty of identifying future users in a real project is a major obstacle to involving them. The supplier should take the necessary steps to make sure that the customers involved with testing and designing the software is a good representation of the future users.
One of the topics that came up was in regards to communication. We discovered that for a large group doing a single project, communication is essential. If communication breaks down, not only does group dynamic suffer, but the actual code begins to suffer as well. It is also interesting to note that communication between the customers and suppliers is almost equally important, since it is difficult to give the customers what they want if you do not know what that is.
Similar to the above, we also discovered that a large group does not necessarily complete large tasks any faster than a smaller one. In fact, sometimes the large group is at a disadvantage. Again, communication may be one of the sticking points, while at other times, an overabundance of communication could also create a bottleneck. For example, suppose a meeting between the full group is taking place. Our group consisted of eleven people, and each of them is going to have a different opinion. Some would be more insistent upon having their view heard than others, and in a variation of that, some will be more vehement about having their opinions used than other members. So during the meeting time, approximately half of the meeting would be spent hearing all of the opinions, and trying to placate the more insistent members of the group.
Our group did discover a better method of dealing with this problem than meeting in the full group. We learned very rapidly that the group dynamics of a much smaller group seem to be greater than that of the large group. In fact, it seems a case of the whole being more than the sum of its parts. Yet other problems occur with this method. Communication remains an issue and becomes more difficult to achieve between the smaller groups. However, our managerial group discovered this factor, and managed to pull things together appropriately.
Along this line, we come to the issue of group dynamics. We learned a lot about this issue very quickly, and not always avoiding the issue before it came up. One of the first things that we learned is that good group dynamics are critical to the success of any group project. Without them, the group falls apart, forgetting about their true task. Also, we learned that positive group dynamics have a cumulative effect. As the dynamic improves, the members of the group tend to greater productivity, and willingness to contribute also increases. It would seem that group dynamic is a self feeding cycle. However, we also learned that it takes only a single person or a single major setback to prevent the positive effect of good group dynamics, meaning that as long as you are making an effort to cultivate group dynamics, that effort in itself will contribute. Part of what creates that effort is equal respect for all the members and their views, which as mentioned above, has its own drawbacks and pitfalls.
One of the other important factors in a group project is planning. As it was once said by a famous philosopher "If you fail to plan, you plan to fail." This is utterly true when it comes to group projects. Even coding becomes secondary to planning in a group project. Without planning, communication becomes difficult, no-one knows what they are supposed to be doing, and the project becomes like the infinite monkeys - no matter how long you let them type for, they'll never produce what you want.
On a final note, the presenters would like to mention that presenting a project is a great learning experience. They noted that it was one of those things for which practice makes perfect and that there is always something to learn from when it comes to presentations, which is a useful skill for the future, regardless of what that future may be.
Page maintained by Ian Mayhood - Last Updated: April 8, 1996