180 likes | 380 Views
Active Review for Intermediate Designs [Clements, 2000]. Introduction . A piloted software design review technique A blend of stakeholder-centric, scenario-based, architecture evaluation method (ATAM and ADR) Goal: expose design to allow early feedback Designers want:
E N D
Introduction • A piloted software design review technique • A blend of stakeholder-centric, scenario-based, architecture evaluation method (ATAM and ADR) • Goal: expose design to allow early feedback • Designers want: • To know if the design is tenable • To unveil the design to the community of software writers
Benefits • Provides valuable insight into design’s viability • Allow for timely discovery of errors, inconsistencies, or inadequacies
Active Design Reviews (ADR) • Effective technique for ensuring quality, detailed designs in software [Parnas, 85] • Actively engaging reviewers to utilize the design in a series of exercises • Conventional design review: • Examine stacks of documentation • Checklist to ensure design meets certain standards
ADRs evaluate detailed designs of modules • Questions address: • Quality and completeness of documentation • Sufficiency, fitness, and suitability of the services provided by the design
Architecture Tradeoff Analysis Method (ATAM) • A scenario-based design review techniques • Scenarios proven to be valuable in the evaluation of system and software designs • Relies on the present of the stakeholders • Elicits business goals for system and its architecture • Uses those goals and stakeholder participation to focus attention to key portions of the architecture
Benefits of ATAM • Benefits: • Financial gains • Forced preparation • Captured rationale • Early detection of problems • Validation of requirements • Improved architecture
Example Utility Tree Transaction response time (H, M) Performance Throughput 150 transactions/sec Training Usability Utility Normal operations Database vendor releases new version Maintainability
ARID • ADR/ATAM hybrid • ADR requires active reviewer participation • ATAM embraced stakeholder-generated scenarios • Three groups of participants: • ARID review team (facilitator, scribe, process observer) • Lead designer • Reviewers (stakeholders)
Phase One • Phase 1: Pre-meeting (between lead designer and facilitator) • Identify reviewers • Prepare design presentation • Facilitator ask “first order” questions • Identify areas to improve presentation • Set the pace for the presentation • A practice to the designer
Phase One … (2) • Prepare seed scenarios • Designer and facilitator prepare sample set of scenarios • E.g. a user in a particular context asks for help, and the system provides help for that context. • Prepare for the review meeting • Produce copies of presentation, seed scenarios, and review agenda
Phase Two • Phase 2: Review Meeting • Present ARID method (30 mins by facilitator) • Present design (no questions nor suggestions allowed except on factual clarification) • Scribe jots down every questions • Brainstorm and prioritize scenarios • Perform review • Provides pseudo code to solve problems posed by the scenario • Present conclusions
Output of ARID • Initial Architecture • System overview from a business perspective: • Most important functions • Any relevant technical, managerial, economic, or political constraint • Business goals that relate to the project • Major stakeholders • Major quality attributes • Set of seed of scenarios
Output of ARID … (2) • Set of scenarios and their prioritization from the brainstorming • The Utility Tree • Issues and problems