Skip to content

Review Plan

Brendan Wadey edited this page Dec 16, 2023 · 24 revisions

We are reviewing Team 10, and being reviewed by Team 15.

We will be performing the Architecture Package review following the 6 Step Review Process:

  1. Establish purpose of review
  2. Establish the subject of the review
  3. Build or adapt appropriate question sets
  4. Plan the details of the review
  5. Perform the review
  6. Analyze and summarize results

This page documents the question set used as part of the 6 step review process. The question set format neatly includes almost all steps of the review process, except for the analyze and summarize results step.


Review Plan

Question Set Name: Ascertaining the Effectiveness of the Provided Maintainer Architecture Package

Purpose:

The purpose of this question set is to determine the effectiveness of the provided Architecture Package from the perspective of Maintainers, as well as determine whether or not Maintainers would be able to perform their duties with the information provided therein.

Stakeholders and Concerns:

All those with a Maintainer role should be involved and have their concerns represented.

Questions:

Respondents: All Maintainers

  1. Before reading the AD, list the basic issues you may have with maintaining the provided architecture, using information already known prior to the review (such as the basic description of the system).
  2. Find and record all places in the AD where one of these basic issues were covered or addressed.
  3. Find and record all places in the AD where one of these basic issues were not covered or addressed.
  4. Record all instances of description insufficient or too vague for Maintainer understanding.
  5. Record any concerns over rationale, in instances where it is provided or should be provided.
  6. Record any concerns over constraints, in instances where they are provided or need to be provided.
  7. Would you be able to maintain the provided software system using the given AD?
  8. What supplementary tools, diagrams or descriptions would be needed in the AD to further aid maintaining the provided software system?
  9. Record and communicate any remaining issues or questions to the Architects who provided the AD.

Expected Answers:

Every Maintainer should be able to form a decent grasp of the described architecture, and identify points within the AD which satisfy their concerns.

Criticality: Questions revealing lacking documentation which directly hinders the Maintainers from performing their duties are the most critical.

Advice: N/A (as an all-hands meeting is required, there are no other review sessions that will take place before or after this one. As such, there is no advice to be gained from them which would inform this review.)


Review Results

Scheduling System

Q1.

  • If the dependencies are not known that application cannot be run. Particularly if we don't know what framework they are using. Getting started should be documented in a README.
  • We don't know which database back-end they are using
  • How can we determine that a schedule is incorrect or inefficient. Requirements and specifications/constraints are needed.

Q2.

  • Codebase includes a README
  • C&C diagram to provide overview of system relationships

Q3.

  • Requirements that demonstrate that the scheduling algorithm is correct.
  • Dependencies are implied in codebase, but not in wiki.

Q4.

  • Lack of accompanying description for C&C Diagram
  • Missing rationale regarding decisions made
  • No sub-view for each micro-service - lack of C&C diagram
  • Lack of deployment/allocation view for each micro-service
  • Missing requirements/constraints on each micro-service

Q5.

  • Lack of accompanying description for C&C Diagram
  • Missing rationale regarding decisions made
  • No sub-view for each micro-service - lack of C&C diagram
  • Lack of deployment/allocation view for each micro-service
  • Missing requirements/constraints on each micro-service

Q6.

  • Lack of accompanying description for C&C Diagram
  • Missing rationale regarding decisions made
  • No sub-view for each micro-service - lack of C&C diagram
  • Lack of deployment/allocation view for each micro-service
  • Missing requirements/constraints on each micro-service

Q7.

  • Ultimately, despite a strong descriptive introduction to each micro-service and the components, there is a lack of diagramming and technical description.

Q8.

  • Lack of Allocation View in SAD

Q9.

  • Listing dependencies between 3 micro-serice and their APIs.

Results of Team 15's Review of Our Package

As the review process was done in pairs, Team 10 reviewed our AD. Here is the result of their review:

For their review, see their wiki page.