Design Review

Teams are asked to present their system design in the fourth sprint of the fall semester. This presentation is to be focused on just the architecture and other design elements; the final semester presentation will be the place to review the features added (or planned) and the process. The design presentation is to be about 10 minutes in length covering

  • Basic project goals: a slide giving a high level view of the core project goals. On a project that continues work done by previous teams, you might also add the primary goal(s) for the current team.
  • Overall architecture/high-level design: a UML diagram, created using Enterprise Architect, showing the core structure of the system with key technologies, probably in a slide.
    • Include at least one class diagram with only key attributes and methods – certainly no constructors, getters, setters, types, or other detail not absolutely essential to understanding the core structure. The primary diagram must not be reverse engineered from code, but supporting diagrams may be if you have a key aspect you can focus on.
    • Consider using package, sequence, state diagrams to explain key elements of your design.
  • One or more of the following:
    • Challenges with the technology the team encountered and their experience with addressing those challenges.
    • Design challenges faced by the team this semester and how they were overcome.
    • For multi-year projects, technical issues you faced when onboarding and what you learned about project documentation.
    • Again for multi-year projects, issues you identified with the original architecture and possible steps the team might take to address those issues.
    • Anything else about the technical details of the project that you believe would be useful to other students.

It should be designed so everyone in the room can take away at least one significant observation. Do not write full sentences; the audience will be distracted by reading them and cannot digest the full content.

One to two students should present this, though all need to review it. Do practice the presentation at least once, but do not practice it so many times it becomes rote. If you talk too quickly, your key points will be missed.

Additional Notes

  • Include names of all team members in the first slide.

  • The final slide should review one or two main design points - that is, contain the takeaways for your audience.

  • If using JetBrains products to show fragments of code, put them in Presentation Mode (on the View menu) so the fonts are large enough for viewers. Similar suggestions apply to other IDEs.

  • Review presentation from back of room, ensure all text readable.

  • Review presentation for extraneous detail; for example, types are rarely useful in diagrams, simplify command prompts to something like $ or >. For presentations, often all you need is class names and a few attributes and operations. The goal is to discuss structure, not specify interfaces.

  • Drop connectives such as “and”, “so”, “but” - often these mark places to introduce a sublist

Scoring Presentations

Different instructors will evaluate presentations in different ways, but one model is to break the total points into four areas:

  1. Good observations about system design
  2. Uses UML effectively
  3. Practiced, with an appropriate length
  4. Good audience member