Task: Review the Design









var defaultQueryStr = '?proc={002674F9-6511-4D15-8623-B761D8C48986}&path={002674F9-6511-4D15-8623-B761D8C48986},{DAFB461E-9ADB-4849-8285-B7E3E72BDB43},_lJQIAEocEdqrjq4i3fchvA';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_e_O28N7KEdm8G6yT7-Wdqw", path: ["_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vChNQkJHEdq4z9xc-r201w", "_vChNREJHEdq4z9xc-r201w", "_XSr4YCFtEdqrX8YVzvtlIg", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_e_O28N7KEdm8G6yT7-Wdqw", path: ["_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vCtajUJHEdq4z9xc-r201w", "_vCtai0JHEdq4z9xc-r201w", "_J1u8gCGYEdqMcovRzkCQow", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_e_O28N7KEdm8G6yT7-Wdqw", path: ["_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vCtaj0JHEdq4z9xc-r201w", "_vCtakkJHEdq4z9xc-r201w", "_rw4S4Z5IEdq7s5zuJVEAAw", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_PEpmMCVuEdqSZ9OimJ-AzA", "_-kFhcCVuEdqSZ9OimJ-AzA", "_pV4NgSFsEdqrX8YVzvtlIg", "_XSr4YCFtEdqrX8YVzvtlIg", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_PEpmMCVuEdqSZ9OimJ-AzA", "_SkuIwCVwEdqSZ9OimJ-AzA", "_gM9X0CGFEdqMcovRzkCQow", "_J1u8gCGYEdqMcovRzkCQow", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_PEpmMCVuEdqSZ9OimJ-AzA", "_cn2akCVwEdqSZ9OimJ-AzA", "_zUDkgSGFEdqMcovRzkCQow", "_vllcADIKEdqGgPtrSpB0vQ", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vChNQkJHEdq4z9xc-r201w", "_vChNREJHEdq4z9xc-r201w", "_XSr4YCFtEdqrX8YVzvtlIg", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vCtajUJHEdq4z9xc-r201w", "_vCtai0JHEdq4z9xc-r201w", "_J1u8gCGYEdqMcovRzkCQow", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vCtaj0JHEdq4z9xc-r201w", "_vCtakkJHEdq4z9xc-r201w", "_rw4S4Z5IEdq7s5zuJVEAAw", "_Cgn1MCCdEdq3qtLcbHn6PQ", "_lJQIAEocEdqrjq4i3fchvA"]}];
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, true, true, false);










Task: Review the Design















This task defines how to conduct the review of a Design and how to address review findings.






Purpose



To verify that the design model fulfills the requirements on the system, and that it serves as a good basis for its implementation. To ensure that the design model is consistent with respect to the general design guidelines. To ensure that the design guidelines fulfill their objectives.



Relationships



RolesMain:



Technical Reviewer


Additional:
Assisting:



InputsMandatory:



Design Model


Navigation Map


Optional:



Analysis Model


Data Model


Design Model


Supplementary Specifications


Use-Case Model


User-Interface Prototype


External:


None




Outputs


Review Record






Steps




General Recommendations



Purpose General recommendations for each review. The "peer" reviewer has the same staffing profile as the Role: Software Architect, although with a more narrow focus on the technical issues. Leadership, maturity, pragmatism, and result-orientation are important to lesser degrees, but still important: a reviewer may uncover design defects that are likely to be unpopular if they threaten the schedule of the project. Still, it is better to raise critical issues early, when they can be resolved rather than blindly following a schedule that leads the project team down the wrong path. The design reviewer needs to balance risks against costs, remaining sensitive to the broader issues of project success. The design reviewer also needs to be a persuasive communicator who can raise and discuss sensitive issues. From a technical knowledge standpoint, the design reviewer needs to have experience as a Role: Designer.



Review the Design Model as a Whole



Purpose  To ensure that the overall structure for the Design Model is well-formed. To detect large-scale quality problems not visible by looking at lower-level elements.  The Design Model as a whole must be reviewed to detect glaring problems with layering and responsibility partitioning. The purpose of reviewing the model as a whole is to detect large-scale problems that a more detailed review would miss. In the Inception phase and early in the Elaboration phase, this review will be focused on the overall structure of the model, with special emphasis on layering and on interfaces. Package and Subsystem dependencies should be examined to ensure loose coupling between packaging elements. The contents of packages and subsystems should be examined to ensure high cohesion within packaging elements. In general, all elements should be examine to ensure that they have clear and appropriate responsibilities, and that their names reflect these responsibilities. Once at least architectural prototypes have been developed, a more comprehensive review of the design should be conducted. The model should first be reviewed for overall completeness, and then more carefully to discover defects.



Review Each Design Use-Case Realization



Purpose To ensure that the behavior of the system (as expressed in design use-case realizations) matches the required behavior of the system (as expressed in use cases), i.e. is it complete? To ensure that the behavior is allocated appropriately among model elements, i.e. is it correct?  Once the structure of the design model is reviewed, the behavior of the model needs to be reviewed. First, make sure that there is no missing behavior by checking to see that all scenarios for the current iteration have been completely covered by design use-case realizations. All of the behavior in the relevant use-case sub-flows must be described in the completed design use-case realizations. In cases where the behavior of the system is event-driven, you may have used statechart diagrams to describe the behavior of the use case. Where they exist, statechart diagrams need to be examined to ensure that they describe the correct behavior, see Guideline: Statechart Diagram for more details.  In real-time systems, where  Artifact: Protocols are used to describe interacting  Artifact: Capsules, they should be checked to see that they offer the correct behavior. Next, make sure the behavior of the design use-case realization is correctly distributed between model elements in the realizations: make sure the operations are used correctly, that all parameters are passed, and that return values are of the correct type.



Review Each Design Element



Purpose  To ensure that the internal implementation of the design element performs the behavior required of it.  For each design element  (e.g., design class or design subsystem) to which behavior is allocated, the internal design must be reviewed. For design subsystems this means ensuring that the behavior specified in the exposed interfaces has been allocated to one or more contained design elements.  For design classes, this means that the description of each operation is sufficient defined so that it may be implemented unambiguously.



Review Design Guidelines



Purpose To ensure that design related project-specific guidelines remain current, and to correct defects in the guidelines where they exist.  On the basis of the design review, look for defects in the design guidelines. Were the guidelines followed? If not, why? Are they correct? Were systematic defects detected that were introduced by erroneous guidelines? Are they complete? Would systematic defects have been reduced if the guidance was provided?



Prepare Review Record and Document Defects



Purpose To document the review results. To ensure that identified defects are documented.  Following each review meeting, the results of the meeting are documented in a Review Record. In addition, any defects are documented in accordance with the project's change management process.







Properties



Multiple Occurrences


Event Driven


Ongoing


Optional


Planned


Repeatable



More Information



Concepts


Usability Testing





Tool Mentors


Comparing and Merging Rational Rose Models Using Model Integrator


Publishing Web-based Rational Rose Models Using Web Publisher








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();
contentPage.processPage.fixDescriptorLinks();