Software Engineering Institute Carnegie Mellon

Active Reviews for Intermediate Designs (ARID)

Challenges:
How can you tell if a preliminary software design is going to be adequate for its intended use?

  • How can you introduce the design to its intended stakeholders in a way that will achieve buy-in and also reveal design defects in a constructive team-building fashion?
  • How can you get those stakeholders to reach consensus on, and then tell you what are the most important intended uses they intend to make of your design?
  • How can you familiarize the stakeholders with the intended design at the same time the design is reviewed?

Overview:
Active Reviews for Intermediate Designs (ARID) is a low-cost high-benefit method for reviewing preliminary software designs (such as for a component or a subsystem) for suitability in its intended usage context and environment. ARID relies on assembling the design's stakeholders to articulate what the important usage scenarios are, and then exercising the design to make sure those scenarios are satisfied by the design. The result is a high-fidelity design review coupled with high-quality familiarization with the design on the part of the stakeholders, both leading to early buy-in.

Benefits:
ARID is a low-cost design review method that produces early identification of places where the design is unsuitable, thus resulting in lower eventual project cost. Added benefits include open communication channels between the architect and the stakeholders, production of training material for the software design, and an articulated set of usage scenarios for the design.

Who Would Benefit:
Software architects and designers of major system components or subsystems, plus all of the design's stakeholders, typically the writers of components that use or interact with the part being reviewed.

Description:
ARID consists of 9 steps divided into two phases:

Phase 1: Rehearsal. First, a meeting between the lead designer and the review facilitator takes place to prepare for the exercise. This meeting usually lasts about a day. In this meeting, the following steps are taken:

Step 1: Identify reviewers. In this case, reviewers are the software engineers who will be expected to use the design. We aim for approximately a dozen stakeholders, but this can vary depending on the size of the user community.

Step 2: Prepare design briefing. The designer prepares a briefing explaining the design. A rule of thumb is to aim for two hours' worth of material. Include examples of using the design to solve real problems. The goal is to present the design in sufficient detail so that a knowledgeable audience member could use the design.

Step 3: Prepare seed scenarios. The designer and the review facilitator prepare a set of about a dozen seed scenarios. These are designed to illustrate the concept of a scenario to the reviewers, who have an opportunity to see a sample set.

Step 4: Prepare materials. Copies of the presentation, seed scenarios, and review agenda are produced for distribution to the reviewers during the Phase 2 meeting. The meeting is scheduled, stakeholders are invited, and steps are taken to assure the presence of a quorum of reviewers at the meeting.

Phase 2: Review. Next, the stakeholders are assembled and the main activities of the review commence. Nominally this phase takes about a day and a half.

Step 5: Present ARID. The review facilitator spends 30 minutes explaining the steps of ARID to the participants.

Step 6: Present design. The lead designer presents the two-hour overview presentation and walks through the examples. During this time, a scribe captures each question, or each instance where the designer indicated that some sort of resource (usually a kind of documentation) was on its way but not yet available. The resulting list is summarized to show potential issues that the designer should address before the design could be considered complete and ready for production.

Step 7: Brainstorm and prioritize scenarios. A session is held for scenario brainstorming and prioritization. Stakeholders suggest scenarios for using the design to solve problems they expect to face. After a rich set of scenarios is gathered, voting occurs. The scenarios receiving the most votes will then be used to "test" the design for suitability.

Step 8: Apply scenarios. For the scenarios that received the most votes, the facilitator asks the reviewers to jointly craft code (or pseudo-code) that uses the design services to solve the problem posed by each scenario. Reviewers make extensive use of the examples that were handed out as part of the designer's presentation. Code statements, captured by a scribe on a flipchart at the front of the room, are gathered that use the services to carry out the scenario. If the designer has to give a hint to get the group un-stuck, the facilitator must ask the scribe to record as an issue where and why the group stalled, as this would indicate an area where the design (or the materials handed out to represent it) are insufficient to allow a non-expert to proceed. Any discrepancies uncovered during the review are also recorded as issues.

Step 9: Summarize. At the end, the list of issues is recounted, the participants are polled for their opinions regarding the efficacy of the review exercise, and they are thanked for their participation.

Availability:
SEI staff will work with a customer team to apply the ARID method.

Additional Information:
Contact us for additional details or to arrange Active Reviews for Intermediate Designs (ARID) services.