Skip to content

Peer Review Logistics

Neil Ernst edited this page Nov 18, 2017 · 7 revisions

Format

Before Tuesday Nov 21

  1. Send the other team (see below) your design docs. Since they are in Markdown in your private repo, the easiest thing to do is to "print" your wiki pages to PDF, and email those. Include these elements of the M2 submission: design decisions, runtime diagram, and structural diagram. You do not need to include the allocation views.
  2. Print your 2 diagrams for presentation.
  3. Identify the presenter, lead questioner, and scribe (note-taker) for the 21st.

In-class

since time is tight, I will be strictly enforcing the schedule.

12:20-12:30 - get together in groups with other team.

12:30-12:35 - The first listed team will walkthru their design in ~5 mins. Explain both diagrams and any key patterns you are using (the design rationale is a good guide). The second team listens (no interruptions except obvious clarifications).

12:35-12:50 - Second team uses the seed scenarios and pre-arranged questions to probe design decisions and critique (note: not criticize) the other design, following the ARID concepts presented earlier.

12:50-12:55 - float/changeover time

12:55-1:00 - second team presents

1:00 - 1:15 - first team questions second team

After class

Follow M3 deliverables and prepare a single wiki page outlining your findings.

Refactor your current design in response to obvious risks identified by the other team.

Teams

(lookup emails on Team Contacts.)

First Team Second Team Problem #
1 3 3
2 5 2
4 7 1
6 10 2
8 14 1
9 12 3
11 Omar/12* 3

* - Present to Omar; listen to team 12 and ask questions there. Team 12 - send docs to 9 and 11 please.

Seed Scenarios

(format: quality attribute, quality attribute scenario, response measure)

Problem 1

  1. Security - Customers cannot double-book a car that was reserved by someone else. RM: this never happens.
  2. Modularity - A new type of car can be added to the app. RM: within 2 days.
  3. Availability - The web application does not go down. RM: more than 5 minutes every day.

Problem 2

  1. Modularity - A new user group type (e.g. SchoolGroup) can be added. RM: within 2 days.
  2. Performance - Rink calendar is able to calculate free time. RM: in under 30s.
  3. Security - Only Managers can cancel rink bookings, not other users. RM: at any time.

Problem 3

  1. Modularity - New event types can be added. RM: within 2 days.
  2. Security - Customer event data is not able to be accessed except by company staff. RM: never.
  3. Integratability - New connections to temp agencies can be added. RM: within 1 week, using a JSON API.