A key reason that the HMS system, as demonstrated, could only have been considered a prototype is that the demonstration was the first time the customers actually saw any ideas implemented. The paper descriptions of the system (in the various design documents) were insufficient in imparting the customer with any real knowledge of the system interface and/or operation.
The system did however, largely conform to specifications as delineated in the final design document. The 'project delivery' section of the final design document clearly describes which features of the system were not to be included in the final product. Those functions that were to be excluded from the final product were in fact absent while those functions promised were delivered. There were a few exceptions to this though.
The maintenance functions were largely vapour-ware. These functions were never very clearly defined by our group. The customer group's failure to give us any meaningful feedback [on any of our design documents] resulted in this set of functions being conceptualized using the 'by-guess-and-by-golly' method. The maintenance screen as demonstrated was largely a non-functional shell.
The automatic room availability search, although to be omitted, was in some sense implemented. When admitting a patient, the 'room' field became a pull down menu which listed all the available rooms in a particular ward. This function was implemented as the programming team found it to be trivial to produce.
The staff scheduling functions were a little flaky in the prototype. This was largely due to the programming team's lack of experience with complex relational database systems. The consistency checks promised with this module were left largely unimplemented. This would include checking to see if a particular staff member chosen for a shift was otherwise occupied in another ward or O/R at the chosen time. Given more time, the programming team would have completed this facility, but time constraints (from this course and others) prevented this. Likewise, the operating room schedule functions were not constructed with any validity checking of staff shifts (all other aspects of the O/R schedule screen were delivered as promised though).
The patient administration and the staff administration screens (and associated functions) were given the most attention by the programming team. It was felt that these functions collectively formed the nucleus of the system and hence much time and effort was directed at these areas. All aspects of these two screens were delivered as promised in the final design document. One thing that the programming team would have liked to have implemented (given more time) was identification of the particular mode a screen was in (such as edit mode or browse mode) and the selective locking and unlocking of function keys (depending on which mode the screen was in).
Except for the ERD and Data Flow Diagrams, the design documents were not used in the implementation of the project. This is for two reasons: our group was roughly split into design and programming teams, and other than documents, there was little communication between the two groups. Secondly, the contrived situation surrounding the project encouraged hacking code rather than following any method.
The course may have been more useful if the focus was on process, and not on building a project. The scope of building a project is too large, especially using the waterfall method. If, however, a process was used to define a small project, and then the process was examined and improved roughly according to the SEI model and then re-re-applied to a new small project, the course may have been more useful.
Part of the concern here is that the goals of the course were unclear. If the goal of the course was to use and understand processes used to produce a software product, then the course failed. If the course was to point out the difficulties involved in large group projects, then the course succeeded.
The waterfall design process seemed to be imposed by the documents required at various stages. Emphasis on quantity rather than quality of the documents resulted in just that; pages of specifications that looked good at first glance but may not hold up to closer scrutiny.
We felt that the imposed format of the project robbed our group members of any creative instincts that they may have possessed. It became very clear quite early in the course that successful documents were those that more or less exactly followed the marking scheme/assignment specifications in general form (and not always content). We found that at times, the imposed format was completely inappropriate for our cognitive model of the project; this was often a source of strife and confusion within the group.
Many members felt that the strict format of the documents at times ran contrary to their own views and ideas. As the course progressed it seemed that we were turning out documents from a cookie cutter mold with the solitary goal of getting our marks. More freedom of choice [regarding the design model and document format] would have helped to eliminate this problem.
We do realize that the personnel available to administer/grade the projects is [given shrinking budgets] somewhat limited. Also, groups given free reign [in their choice of design method] may result in unsatisfactory/inadequate work. There will always be people who would take advantage of an open format in order to lessen/alleviated their workload.
Also, it is realized that there is limited time available for this course; freedom to choose a particular design model may simply not be possible due to time constraints. Freedom and flexibility must be in some way granted to the students though. One thing this project has taught us is that one model will not work for all types of software design situations. Perhaps, if this were a full year course, more time would be available for more meaningful project work [that would allow for more freedom and flexibility]. A full year course would allow the instructor(s) time to familiarize students with the various design methods that can be used. Software engineering is a very important area for our profession; there should be more attention paid to this area [in the undergraduate curriculum].
The use of electronic submissions via the web allowed for greater flexibility when preparing documents. We were able to make changes right up until the submission time as we did not have to worry about the time overhead of printing off hard copy. One disadvantage of this approach was that without actually seeing the physical document, it was allowed to grow beyond a useful size. Carl Williams mentioned that small usable documents were better than 'forklift documents'. This is intuitive as we all know that large documents simply are not read; at times the sheer size of a document can intimidate potential readers.
Using the Web did not completely prevent the printing of documents. In mass group meetings where the submission of the customer group were discussed, everyone had to have a printout to be able to participate. As well, since the Web lends itself to graphics and numerous screen dumps, laser printing of documents (especially the overall design document and user manual) was expensive; printing in a text form left out many important graphics. Perhaps if there were more workstations available to undergrad's, group meeting could have been held in front of a terminal thus eliminating the need for hard copy. As it is though, one almost has to fist-fight fellow students for the use of a terminal.
The instructor's use of the web to post lecture notes was very innovative. Allowing the students access to the source material for various lectures was a privilege not normally enjoyed in undergrad courses. There was one problem with this approach though. Often during lectures, the instructor(s) would skip over large sections of material by remarking that it was 'on the web so there is no reason to cover it in class'. For some minor topics, this treatment was acceptable but at times, large and complex topics were skipped over in this fashion.
The formal method suggested splitting up testing after the system was produced; this was found to be difficult in the educational setting. The communication between members required to perform the formal testing was found to be difficult given conflicting workloads from other courses. Another difficulty was that only a few of the group members had access (ha ha) to the development platform (MS Access); it was found that the programming team often worked as a separate entity.
The formal test plan only tested the validity of the system, not its usefulness. Problems in the interfaces that would not be revealed by the formal test plan may have been revealed by a usability study involving the customer group. However, such a usability study was not feasible within the scope of this course (time constraints mostly). A prototyping design method would have suggested a more feasible/flexible test plan that may have produced a better, more usable interface.
In the beginning, everyone was involved in the process. We discovered quickly that this did not work, and led only to disagreement on process and a lack of progress. Splitting the group into two or three smaller groups, and getting all together occasionally to discuss progress, was more manageable and efficient. The small groups changed from document to document, based on who had time and what the skills of the people were. People without well defined skill sets were underutilized for most of the project, but some effort was made later to assign tasks to even out the project load.
In general, we found that we lacked a clear vision of where to go and how to get there. The committee approach that we fell back on was unwieldy and inefficient. However, everyone in the group felt able to express their opinion, and we all learned to compromise.
Some slippage of internal deadlines occurred, but was limited to the external deadlines imposed by the course. Each group took as much time as necessary to fulfill the requirements; the project tended towards Parkinson's law: the project expanded to fill all the time available between deadlines.
People management could have been more effective. Some people were underutilized until the end of the course. Some people did little work in comparison, for no ascertainable reason. In the real world, both of these situations would have been dealt with early in the project. This would have resulted in a more even workload, and less resentment.
We had one group member who ended out being dead weight. This individual did not make any real contribution to the project. In the future, group members may be able to identify such an individual and then rectify the situation (either through increased communication or through various methods of controlled pain and torment).
We would have liked to have used a prototyping methodology to produce the system. The waterfall method turned out to be almost completely inappropriate for a small project that was required in such a short amount of time. The lack of contact with the customer group resulted in an interface that, while usable, may not have suited the customer's needs. As well, the prototyping methodology may have been more efficient, allowing for a more dynamic management structure and more creativity.
The attitude of the group would hopefully have been more positive. The course framework resulted in a 'give them what they want' (meaning 'go for marks, not quality') attitude. Often, we were more concerned with the size of a particular document. For example, if it was specified that a document was to be 40-50 pages in length, our chief goal was to use up that space; at times the quality of the submission suffered in this quest for more material. We were not accountable to anyone within the group, or really anyone outside of the group with regards to the quality of the documents submitted. In some of our documentation, there were some sections that were included specifically to see if the reader was 'awake'. We found that these sections were not found by either the customers or the markers. This led us to believe that the documents were not being consumed for the quality of content, but for their appearance; a big document that was well formatted seemed to be a sure bet for good marks (beauty is only skin deep).
In a real project, all the people would have similar skill, and a knowledge of the platform, either through experience or training. This lack of consistency and knowledge made it difficult to make usable documents and a usable system. Also, as only a few group members were familiar with the development platform chosen, only a few individuals were involved in the actual development of the finished product (actually, one person did ALL the programming - the other members of the 'programming team' took him out to dinner a few times). If the platform had been more accessible, perhaps more people would have been involved in the programming phase.
As such, members of the group had little in the way of team/group skills at the beginning of the course. Various methods (of group management) were experimented with and some were discarded and some were retained and modified. Initially, the collective mindset was still that of initial effort producing results. As the project progressed, the concept of team effort and particularly of breaking a big task up into a lot of little tasks was embraced by most group members. Perhaps, the most important lesson learned from this project was not that of a software design paradigm but of the dynamics of group work; this is a skill that all group members will find invaluable in future careers.
It was felt that the course structure did not allow for any innovation or creativity. The project specification imposed conformity to a very specific process, allowing little room for deviation. Software engineers must be flexible in their approach to new and changing problems; this is a point that Carl Williams emphasized. This course did not allow the student to experiment and learn, but instead demanded unswerving conformity.
We felt that more emphasis should have been placed on process development and implementation, not the development of a hypothetical system. As programming was not the chief aim of the course, this aspect should have been downplayed. Perhaps, it would have been more effective to have the groups develop a design process. The groups would then put this process to use and evaluate the effectiveness of their choice. This approach would emphasize the software development process and would provide the students with a more meaningful project experience within the goals of the course.