Assignment 5: Design Doc

Grade Value: 75 points

Due: Tuesday October 14, in class

Target Time: This exercise should take around 2-5 hours as a group.

brief

A fundamental step in any implementation is designing the system architecture. This is an important process that will allow you to plan ahead, save rewriting time, and communicate with both the members of your group, and to us.

assignment

• Describe the major responsibilities of the system.
• Describe how the system was broken down into its components (identifying each top-level component and the roles/responsibilities assigned to it).
• Provide some rationale for choosing this particular decomposition of the system (perhaps discussing other proposed decompositions and why they were rejected).
• Then for each major component:
  • Describe the major [public] interfaces/services it provides to the other components of your system. For example, this might include resources, data, types, constants, methods, and/or exceptions.
  • Any special responsibilities that were not previously discussed.
  • Rough schedule: lay out a schedule for implementing each part of the component, or the entire component (if the component is sufficiently simple and small). Make sure to specify who will be doing each part of the implementation.

Feel free to make use of design patterns, either in describing parts of the architecture (in pattern format), or for referring to elements of the architecture that employ them.

Notes on Scheduling

As you're aware, you only have a couple weeks to build your application. This is a very short time, so proper planning is incredibly important. Break your application development into three stages: alpha, beta, and launch. (The schedule for the course has been updated to reflect this new schedule.)

Alpha release: This is a release just for your group members, so it does not need to be completely functional. The point is to have the basic skeleton, as well as the core feature(s) implemented. Since you'll be using it yourself, you'll get some valuable insight into the pain points for power-users. You'll also start catching some of the early show-stopper bugs.

Beta release: This release is for "friends and family," so you'll want most of the functionality finished. However, make sure you don't over-commit; as Getting Real puts it, Fix Time and Budget, Flex Scope.

Launch: This is the public release. We'll be offering CS147 students experiment hours in return for testing your projects, so you could sizable traffic. This is when you start running A/B tests, analyzing logs, and putting on polish. Again, It's better to make half a product than a half-assed product.

More detail is coming on each of the releases, but use these notes to lay out a schedule. The schedule you submit is not set in stone; it's for us to be able to discuss with you, and for your planning.

We suggest you break down tasks to 1-8 hours, so that your planning will be sufficiently granular.

in studio

Create a diagram of your application. This diagram can be a class diagram, like the above example. If you're not using classes, the diagram should convey an overview of your data, as well as functions/methods being called to act upon the data.

You'll have 10 minutes to present your diagram and explain your architecture to the class.