Another negative aspect of the design process was a lack of customer involvement during the development stages of the software. In order to design an interface that will satisfy the customer, there has to be more interaction between the developer and the customer. The design process used allowed this kind of interaction only through written documents, with the exception of one very short meeting. Although these documents were helpful, they sometimes created ambiguities or left the concerns of both parties unresolved. With the design process that was used, the customers only really see the software at the very end of the process. If the customer group wanted something changed at this point, it would certainly be harder to do than if the problem was addressed early in the design process.
An advantage of the design process was that it provided a structured and systematic way to develop the software. Each stage of the design process led the group a step closer to the finished product. The development of a software program is a difficult task. The design process was beneficial since it broke the task down into smaller, more manageable stages. With each stage the group was able to concentrate on doing a more complete job. The documents, with the exception of their size, were also helpful. Every group member had unrestricted access and information from previous design stages could be referenced easily.
The timing of the user manual caused a lot of revisions. It may have been more useful to write this either first or last, rather than after the detailed design document and before the the actual code was completed. If the manual was written before the design documents then all the pseudocode could have been based on the manual. This would have prevented having to revise the pseudocode later and the programmers could have worked directly from it. This would place the emphasis on designing a user friendly system, since it would demand a closer interaction between the programming and user interface teams right from the start of the project. If the user manual was written last then it would be an exact reflection of how the software functioned and would not need a major revision after the system was completed.
In general, the difficulties of implementing the test plan resulted from both the time frame of the project and the importance of this stage in the project. If we had two years and/or 100 programmers to develop this system, perhaps the entire test plan would have been implemented as written out. Also, had the system to be designed been a very important real world system where the slightest error would have resulted in drastic consequence, again the full test plan would have been implemented to the letter by the group.
Even with the limited manner that the test plan was implemented, we are nonetheless quite confident that the majority of the bugs have been eliminated in the project. Major errors, level A and B bugs are relatively unknown in the project, and minor errors such as level C and D errors are few and far between in our experience.
The test plan also seemed to stress several areas that were outside of the concerns of the programmers. Given that this project was written for the Sun architecture available in the terminal rooms, the version of hardware, the windowing system, and the operating systems were all constant in most respects. If this project had been required to operate on all Unix machines, or (heaven forbid) all the differing PC compatible machines, then the full testing from architecture to architecture, machine to machine would have been necessary.
Regardless of how far we deviated from the specified test plan, the role of the Bug Manager was fully implemented by the group. This person did end up tracking each stage of the project and was keenly aware of where bugs had been found, and what the status of those bugs were, whether corrected or uncorrected as the case may be. He was also keenly aware of what stage the various modules were at and the stages of their completion, and what stages the testing was at in each component.
If we were to do this type of project over again, we would perhaps change the test plan to reflect more closely what was actually done. Granted, given more time we would love to do more testing.
We did not have an autocratic leader but rather a loose oligarchy with no absolute definition of power. Our Project Leader served to organize the group into smaller teams, plan successive stages and provide the focus for the group. Then, in the smaller teams, as needed several people rose to the occasion to lead the team, either they had a good sense of what was required for a section or they saw a need for more control to be exercised. Everyone had a sense of working together to complete the task at hand. The lack of management titles served us well in that it eliminated some of the problems caused by inane or unreasonable requests from a manager who lacked knowledge of what the people in their group were doing. All of our leaders grew from within the teams created, hence their effectiveness. It should be noted that this style would not have worked well if all the members of the group were not self motivated and mature in their attitude. In all, we wound up with more people involved in process management then we had initially planned, but only what was absolutely necessary because we let leaders evolve rather than be assigned.
Another concern we have is that in a "real" project, the informal specification of requirements would have much more importance and take up much more time than it was given in the course. We feel it is important that the consumer state clearly what kind of interface they want, what functions they want, how the system will be used, etc. It should not be up to the supplier to come up with these things for the consumer. Our problem during the project was that consumer group 9 did not clearly state that they wanted a graphical interface in their informal specification, so we described a text based interface for them in our functional specification and management plan (because of time restraints, we were unable to get the needed information from the consumer group). In a "real" project there would be a lot more phone calls and interviews before the functional specification and management plan is written. One suggestion for solving this is to provide a more clear and in-depth description of the requirements for the informal specification of requirements so as to provide guidelines for the consumer group.
One suggestion that we would like to present is involving the customer group in a pseudo lazy evaluation way. This would mean that the customer group should behave as a real business that has minimal time in participating with the development process. Although this may undermine the "Software Engineering Standards" in development, it is fair to say there were no S.E.I standards used in any of the supplier groups development processes. It boiled down to a "get this over with" scenario. Customers should submit documents when there is a problem not be forced to find them. We feel the customer groups acted with too much knowledge and undermined what would really occur.
A simple suggestion would be to install a good package onto the network. This would level out the playing field and provide those with less fortunes a way to quickly and relatively painlessly develop the required software. If that is an unreasonable suggestion then a room of PCs with the stated appropriate software would accomplish the same task.
To dispell this problem a lift on quotas would empower those involved to write quality documents that take as much effort as is needed. Documents can then be judged on the quality and presentation as opposed to meeting the right size, which we lost marks on for the User Manual.
It is conceivable to us that the work loads could be reduced to make life easier here in Computer Science, but intuitively that is not the goal of this program. The amount of work involved in this course is tremendous, and with a small course load manageable. Unfortunate to most of the students the latter is not the case; yet with the opinions that have been expressed we hope that all of the ideas have not fallen on deaf ears.
It was important to organize our group as soon as possible. This includes choosing a group leader, and breaking down the group into smaller subgroups. A group leader should be able to help others to follow the rules agreed on by all members in the group. Also, he should be able to make the final decision on an issue or discussion. We found that smaller groups are more efficient than a large group. It is very difficult and inefficient to set up a meeting for all group members at one time. Also, if the group contains too many members, communication may become inefficient.
In order to meet the needs of the customers, it is better to keep the customers involved in the project. We learned that it is very easy to misunderstand what the customers require since we were not in contact with them enough. In fact, we should have had someone dealing with them regularly. If we did this we would not only make sure we produced and implemented what the customers desired, but we would also encourage a more positive customer/supplier relationship.
Communication was very important in the group work. We had a big problem in the early stages of the project because of a lack of proper communication. The first time the documentation subgroup wrote the specification, the document was full of inconsistent and redundant information. It was because the members in the subgroup worked individually and they did not have enough communication.
Prepare before meetings. It is wasting time for all present in a meeting if you don't know what to do or what the purpose of the meeting is. Always be aware and understand what needs to be done during a meeting. For example, everyone should read all the requirements on the web page before going to a meeting, not after or reading those requirement during the meeting.