If this were a real project we would have a slightly different strategy to approach the problem.

Below are a few proposed changes in our group structure:

Our group philosophy revolved around a rotating leadership structure, where every member of the group had an equal say in any matter that concerned the group. While this fostered an environment conducive for team work (and thus helping achieve quality development), in the "real" world, where most development structures are decidedly more hierarchical in nature (to deal with teams that may not work as well together as the members of Squidsoft did), it is very likely that a strong team leader would be in place.

The documentation team would work alongside the coding team and testing team in order to write accurate documentation that would anticipate any concerns / difficulties potential users might have with the system. Unfortunately, under the current structure of the course, this was not possible to the extent that Squidsoft would have preferred.

Also, Group break downs would have be handled more effectively. The planning of subgroups would have to be somewhat more formalized (perhaps drawing a chart detailing each person's experience, and what subgroups they are/were members of, to help determine future subgroup assignments). As well, stricter deadlines would need to be set. If each sub-group had to present its work at various points of development to the rest of the group, then an environment fostering a high quality of workmanship would be set.

Another topic of concern would be with Customer Relations

There would have to be more respect for the customer's concerns about the project. As aforementioned, there should be more communication between the supplier and customer groups - there must be an effort to make the customer group feel like an integral part of the design process. Specifications from the customer would be "combed" over in more detail, and any points of contention would be raised immediately.

Some dissenting opinions are as follows:

The coding team consisted of two people, one of which spent one week (Reading Week) to develop the first of many versions of the prototype, while the other was busy familiarizing himself with the new language (Visual Basic) and the printing routines. This rushed and chaotic implementation plan (as mentioned in the "proposed changes to design assignment" section) is not conducive for quality work - more time should be allotted for the implementation phase.

The lack of communication between the customer and supplier group as mentioned earlier in the "proposed changes" section was a point of contention with all Squidsoft members.

Find Button  

Demo Script  
Source Code  

Main Page