Design milestone (SDS++)

The goal of this milestone is to define your software system's design along with planning information.

Due: Thursday April 19, by 11:00PM The PM for the team will submit, via DropBox, a link to the document, which will reside on the team's web page.

The purpose of this next team assignment is to accomplish the detailed architectural design and phased product delivery plan for your system, before you implement your ideas in code. A common name for this document is a System Design Specification (SDS), although in our case, we are augmenting the design with planning components: hence, SDS++. You will have an architecture section and a process section. Among other things, your SDS++ will answer the questions: what are your modules (packages, classes, or other units of abstraction), what are the responsibilities of each class, and how do the classes interact/collaborate?

Note that the SDS++ will be a living document. You will be asked to provide updates to it at periodic points in the development cycle. As part of developing the SDS++, you may need to revise your SRS. Keeping these documents up to date with changes as they happen will make it easier to keep your team and customers in sync, and to meet your later deliverables. There is one deliverable; no presentation is required.

In evaluating your work, we will be looking to see that you have addressed all the necessary elements of an architecture, covered well the planning material described above, and made reasonable decisions related to all project components.


System Architecture

The System Architecture document provides a detailed definition of the system’s software components. It identifies the major modules and their functionality, and the interfaces between modules. It should address the design of the system from the customer's viewpoint, as well as that of the developer or administrator. (This may require separate perspectives and/or diagrams.)

Describe, in detail, what data your system stores, and how. If it uses a database, give the high-level database schema. If not, describe how you are storing the data and its organization.

For at least one design decision for which you seriously considered an alternative, briefly describe that alternative. Discuss its pros and cons and why you chose the design you did.

If there are particular assumptions in your design, identify them.

You (and more especially your readers!) may find it useful to first create a customer view of the system (at a high level of abstraction) and/or a UML class/dependence diagram of the modules of the system.

The architecture section must include at least two views of the system architecture, with one view being a UML class diagram. You also must include two UML sequence diagrams outlining two of the use cases from your SRS.

The UML class diagram must include all major classes and enough detail to answer questions about the design and to let design be critiqued. Your diagram should display all major classes, attributes (fields), methods (do not list get/set/is methods), inheritance/interface relationships, and associational relationships (named and directed, with multiplicity adornments).

Include classes for all aspects of your system, such as user interface, data modeling, database interaction, any “helper” classes or utility code, etc. (In the past, some groups have focused too much on user interface classes and have done a poor job capturing the details of the “model” of your system, the classes that actually represent the important data and behavior necessary for the task.)

The UML sequence diagrams should depict your product executing two of its important use cases. These can be the same use cases you wrote about in your requirements document (SRS). The sequence diagrams show the “life” of a user's interaction with the system (e.g., web request). Your diagram should show all participants (objects) in the sequence, all important directed messages between them, and their return values (if any), Show the request's path as it interacts with each part of your system to accomplish the task. Make sure that the state of the system at the end of the path through the diagram matches the expectations from the use case to which it relates.

Design tips

Your design should use the design principles discussed in this class and prior ones. Here are some general design tips, which essentially come down to “put functionality in a logical place”.

Process

The process section of your document should address the six topics described below.

Risk assessment

Identify the top five risks to successful completion of your project. For each, give:

Explicitly state how this has changed since the SRS.

When deciding which risks to include, you can informally multiply the likelihood by the impact to determine the importance of a given risk. You should pay attention to risks in proportion to their importance. Don't belabor low-likelihood, low-impact risks.

Project Schedule

Identify milestones (external and internal), define tasks along with effort estimates (at granularity no coarser than 1-person-week units), and identify dependences among them. (What has to be complete before you can begin implementing component X? What has to be complete before you can start testing component X? What has to be complete before you can run an entire (small) use case?) This should reflect your actual plan of work, possibly including items your team has already completed. Consult your SRS Feature List for input.

To build a schedule, start with your major milestones (tend to be noun-like) and fill in the tasks (tend to start with a verb) that will allow you to achieve them. A simple table or spreadsheet is fine for this size of a project. Schedule tools, like MS project, are also good as they track dependencies, but may have some ramp up to learn and so may not be worth the effort for a project as small as yours.

Team structure

Describe your team structure (how you have organized the team, what are members' roles and responsibilities), elaborate on milestones (external and internal), define tasks, and specify the team member responsible for each task. This should reflect your actual plan of work, including items your team may have already completed. You may find yourself revisiting your organization during the lifecycle of the project. Describe the way your team will communicate, for example: date/time of weekly meeting, location of weekly status reports, wiki, email alias, etc.

Test plan

Describe what aspects you plan to test and why they are sufficient, as well as how specifically you plan to test those aspects in a disciplined way. Discuss unit test, system (integration) test, and usability test strategy, along with any specific test suites identified to capture the requirements (SRS). Identify the mechanism that you will use to track bugs that occur during use and testing. (For a large project, use of a specialized bug tracking tool is critical. For this project, we do not require it, but whatever you use must be kept up to date and visible to your customers in the class, and the course staff.)

We will not have covered this material in class by the time the SDS++ is due. Do your best and plan to revisit this section during a later spiral of the lifecycle. Below is a sample structure for the section.

Documentation Plan

Define the documentation that you plan to deliver with the system, e.g., user guides, admin guides, man pages, help menus.

Coding style guidelines

For each programming language that you will use in the implementation of your project, provide a link to a pre-existing coding style guideline that the members of your project will follow. Do not try to make up your own guidelines. Briefly state how you plan to enforce these guidelines.