Product Design and Implementation Plan

Overview

The aim of this project is easily stated: produce a software design and implementation plan for the project whose requirements you addressed in Project 01. Working from this starting point you can now begin to produce a more specific design, and to formulate a schedule for implementing your design in the time allowed. The development of the design, following the guidance of the book, should begin with the identification of the objects which represent the sets of information which must be managed and the set of operations on the objects required to implement the intentions expressed in the requirements.

One way to approach this is to see how you chose to group information as you designed the GUI rapid prototype. These sets of data are reasonable first candidates for object definitions. Sometimes a given window in your GUI design will represent a single object, sometimes more than one. Occasionally the difficulty you have in describing sets of objects that correspond to the elements of your GUI will be an indication of problems with your candidate object definitions, your GUI RP design, or both.

While generating an object oriented design description is easier said than done, how to do it cannot really be explained in great detail. The only way to really learn this aspect of software engineering is by doing it. We have discussed examples in class, but they will only make sense up to a certain point until you try to do your own design. Also, you should expect to have to try several ways of describing the software design before you find one that works well. The only examples which work the first time are those done in class by a professor who has worked them out beforehand! However, note that I have the group notebooks from several groups and different semesters in my office so you might check there for ideas on presentation if your own do not seem to be working too well.

Software Architecture/Design

The text describes how to refine a software design from an initial identification of the major objects, through detailed pseudo-code for each function which operates on the objects. This series of operations will represent the major part of the work required for this project. As with many aspects of the work required for this class, it will require a measure of judgment on your part as to how detailed you should be in your description. Clearly, one can take pseudo-code to an extreme, producing 90% of the source code for the product. This would be un-usably detailed and complex. On the other hand, one could describe the pseudo-code a such a high level (e.g. "does what is necessary") that no implementation details, data structure properties, or usable direction are available to help guide the developer implementing a given part of the product. Such a presentation would be un-usably simplistic.

Your group's objective is to produce a software design document which falls at a reasonable point between the two unacceptable extremes. I suggest that you produce a document that devotes 3-5 pages to straight rhetoric giving an overview of your design, and then supplement that with 10-15 pages of rhetoric and pseudo-code which present the major parts of your design and how they could be implemented. The aim of this is to express enough of your opinions to guide a developer without drowning them in details. That means that "obvious" aspects of the algorithms are not mentioned as they should not be required by a reasonably aware and well informed developer. For example, you could, and should, write "Read a line from the input file and get the file name contained within it" instead of specifying several character pointer or string manipulations. The rapid prototype should be useful here as you may well be able to write sections of your document using screen-shots of parts of the rapid prototype to illustrate specific points, as opposed to a long set of words required to explain a point if no rapid prototype was available.

Implementation Plan

The text and class discussion described the Cocomo model and discussed the basic elements of a software development plan (SDP). While a full blown SDP will be overkill for this project, I would like you to try using the Cocomo model, and to formulate an implementation schedule. This schedule should take roughly 3-5 pages and describe the set of intermediate deliverables which you will use as milestones in your project. For example, since you will have roughly 4 weeks for implementation and integration, I would suggest weekly milestones which represent a reasonable and realistic series of iterative refinement steps for your product. I have also described this as the "thin" development method as opposed to "thick" development method in class discussions.

So, if you are following the "thin" method, then at the end of the first week you would perhaps have the GUI framework with mostly stub routines corresponding to the proposed operations, but with one or two of the most important functions implemented. At the end of the second week you might plan to have 50% of the functions finished, at the end of week 3 you might expect 100%, and then devote week 4 to testing and completing the documentation. You should also allow for some activities (for example, documentation) to proceed in parallel with coding, integration, and testing.

Please include a fairly detailed list of the responsibilities of each group member. Assume a group with the same number of members as your group, for simplicity, but your plan should not be so specific that it is appropriate only for the members of your specific group. Imagine that another group of the same size would be doing the implementation. However, by the end of Project 3 you will be expected to all agree on the list of activities reflecting your actual development experience, and to document the division of labor that took place within your group.

What to Hand In

Your group should prepare a report which includes: (1) a section describing the software architecture design, (2) a section presenting an estimate of the work required derived using the Cocomo model, and (3) a development plan citing weekly milestones and the responsibilities of each group (hypothetical) member.

This report should be a part of the project folder that you turn it. The folder should contain a copy of the GP01 report that you turned in earlier. The project folder will later be augmented with the final report and necessary documentation after the implementation & integration phase in GP3.

Your group should also prepare a 20 minute presentation, which is appropriate for a group, like yours, taking over development of this product from you and planning to implement your design. In previous semesters, every group presentation was given. Due to the size of the class, however, this semester we will randomly choose groups to give as many design presentations as time allows, and then favor those groups not chosen for the first presentation to give the final product delivery presentations at the end of the semester.

You should include a copy of your presentation slides in the project folder you hand in.