-
Notifications
You must be signed in to change notification settings - Fork 21
Peer Review Logistics
- 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.
- Print your 2 diagrams for presentation.
- Identify the presenter, lead questioner, and scribe (note-taker) for the 21st.
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
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.
(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.
(format: quality attribute, quality attribute scenario, response measure)
- Security - Customers cannot double-book a car that was reserved by someone else. RM: this never happens.
- Modularity - A new type of car can be added to the app. RM: within 2 days.
- Availability - The web application does not go down. RM: more than 5 minutes every day.
- Modularity - A new user group type (e.g. SchoolGroup) can be added. RM: within 2 days.
- Performance - Rink calendar is able to calculate free time. RM: in under 30s.
- Security - Only Managers can cancel rink bookings, not other users. RM: at any time.
- Modularity - New event types can be added. RM: within 2 days.
- Security - Customer event data is not able to be accessed except by company staff. RM: never.
- Integratability - New connections to temp agencies can be added. RM: within 1 week, using a JSON API.