CSE 503 - Brief for Design Charette

University of Washington

Spring 2004

instructor: Rob DeLine

ta: Miryung Kim

due Mon 7 Jun 2004

The goal of the design charette is to give you the opportunity to try out the skills and ideas that you have been learning in CSE 503 on an open-ended problem. You are to work in teams, ideally of four people. To give us a chance to review each project during the final exam period, there must no be more than seven teams in total. You are free to divide the work among team members however you see fit. All team members will receive the same grade, based on the teams' total output.

The problem brief

The problem is to design an email system for a multinational corporation, in the same vein as Outlook/Exchange or Lotus Notes. Since these kinds of systems are so familiar, I won't include a lengthy description of what email is. I will count on you to use your own experience and intuitions. Instead, I'll highlight some aspects of the problem you may not have considered in a business context.

Obviously, solving the problem in its general form would take a professional team several years. Instead of trying to solve the whole problem, your team should focus on some aspect of the problem that you find particularly interesting. The team's presentation and report should concentrate on that aspect. You should feel free to choose an aspect of the problem based on your own research interests and your experience from previous courses and employment. Here are some example aspects you might consider, which is not an exhaustive list:

• Availability. A key property of any communication medium is that it be up and running as much of the time as possible. Every time an employee cannot send or recieve email, the company loses money. The design should especially avoid catastrophic failures in which large portions of the company are unable to communicate due to localized phenomena, like a power outage at a particular building or a backhoe severing a particular network connection.
• Operating costs. Although buying equipment, like server machines, is fairly inexpensive, attracting and retaining the qualified personnel to maintain these machines is quite expensive. The system should be designed to minimize operating costs, in particular, requiring as few technicians as possible to maintain the servers while still maintaining high availability.
• Security. The company intends to use the email system for sensitive discussions, including hiring decisions, private employee information like salaries and health records, and details of the company's intellectual property. Allowing an unintended person (including someone outside the company) to read such email could cause the company public embarrassment (including stock price drop) and leave it open for law suits. The system should protect the information against both accidental leaks and attacks from outside the company.
• Evolution. As the world uses email more and more, the email's content becomes more sophisticated. Today, HTML-based email is replacing text-only email. Tomorrow, email might include streaming video or live applications. The design should accomodate these kinds of expected changes.
• User interface. To support modern business travelers, the system should allow an employee to access his/her email through some widely available communication mechanism, such as a phone line or web browser, whenever the employee is on the road. Understandably, the system may present less functionality through such a public user interface, compared with the functionality available through a desktop machine on the company's intranet. When using the system through public communication media, other aspects like security come into play.

What the team must produce

The spirit of the assignment is that you are seven teams competing for the same lucrative contract. Your job is to convince us that your design has demonstrated properties that make it the best choice among the competitors. Since different teams will concentrate on different aspects of the problem, the teams' designs are not competing head-to-head. Instead, your teams are competing in terms of how responsibly they handled their individual aspects of the system.

Each team must produce both a presentation and a report about its design:

• During the final exam period, your team will give a fifteen minute presentation, which must include time for feedback. During the fifteen minutes, the team should expect to be interrupted with clarifying questions and comments. Hence you should plan for five to ten minutes of content. This is a very short amount of time, so your presentation should jump right into the aspect you chose, the features of your design that handle that aspect, and the evidence you have gathered on why your design exhibits important properties of that aspect of the problem. Your presentation can use any media you like, but laptop presentations, transparencies, or posters are probably the easiest to prepare. One or more team members or your choice may give the presentation. The presentation should not be a slick sales pitch, but instead should concentrate on the engineering content of the design.
• During the final exam period, your team will also hand in a written report, summarizing the design and its proven properties. The reports should be about ten pages, not including appendices in which you can record specifications, algorithms, and other detailed listings. The report should state the aspect of the problem you focussed on, a description of the issues that arise for that aspect, and a discussion of how your design handles those issues. The report's structure is open-ended, but must include the following:
  • A description of the system archicture. This description does not have to be in a formal architectural description language, but should consist of informal pictures (such as box-and-line diagrams) and text. If there are parts of the system that are less interesting for your chosen aspect, these parts can be omitted or briefly sketched.
  • At least two uses of the methods discussed in the course: Jackson's problem frames, Alloy, Spin, Zing, weakest preconditions, or Esc/Java. For instance, you might: use Alloy to demonstrate properties of your system's key data structures; use Spin to demonstrate that your system cannot get into particular bad states; or use weakest preconditions to prove correct a central algorithm in your system.

Customer FAQ

Since it's impossible to predict everything that the teams will want to know about the problem, we'll simulate a dialog with the "customer". Each time you have a question or need a clarification about the problem to be solved, send me (Rob) email. I'll act as the customer and add the question and its response to the FAQ below. I'll post the questions in the order I receive them, at least until there are too many and we need to categorize them by subject.

Q. Why are there no interesting questions in this FAQ?

A. Because no one has asked a real question yet.