Architecture review methods Assumptions Types of reviews Prework The review Follow-on activity Value of architecture review Other types of reviews.

Slides:



Advertisements
Similar presentations
INITIAL ON BOARDING COACHING
Advertisements

Beta Testing: The Contractor’s Perspective Trns·port User Group Meeting October 2005.
Agile Usability Testing Methods
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
On-the-Spot: Needs Assessment. Objectives To recognize the importance of conducting a rapid initial assessment before deciding whether and how to respond.
Hospital Information System (HIS) Stakeholder Consultation
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
1 reviews8 Software Reviews, Walkthroughs, and Inspections The standard technique to ensure quality in software development.
MED  Problem of the Day: SEND +MORE MONEY.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
Active Review for Intermediate Designs [Clements, 2000]
Prototyping. CS351 - Software Engineering (AY2004)2 Scenario Customer: “We would like the word processor to check the spelling of what is typed in. We.
SE 555 Software Requirements & Specification Requirements Validation.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
QUALITY ASSURANCE PROJECT Conducting Effective Meetings The purpose of this module is to enhance participants’ knowledge and skill in observing team meetings.
Requirements Engineering
Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman
Leaders Manage Meetings
PROGRAMS MONITORING AND SUPERVISION
S/W Project Management
Team Launch Introduction. Real projects are large and complex, and most software is created by teams Merely throwing people together does not result in.
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
PDHPE K-6 Using the syllabus for consistency of assessment © 2006 Curriculum K-12 Directorate, NSW Department of Education and Training.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Page 1 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure.
1 Performance Management Program SETTING OBJECTIVES COACHING EVALUATING GIVING & RECEIVING FEEDBACK.
COMMUNITY AWARENESS / EMERGENCY RESPONSE BEST PRACTICE EXAMPLES AND TOOLS David Sandidge Director, Responsible Care American Chemistry Council May 31,
© 2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Developing a Library Marketing Plan, Part 2 Implementing the Plan Mark E. Ibach Marketing & PR Coordinator South Central Library System.
INTERNATIONAL LABOUR ORGANIZATION Conditions of Work and Employment Programme (TRAVAIL) 2012 Module 13: Assessing Maternity Protection in practice Maternity.
Requirements Verification & Validation Requirements Engineering & Project Management.
Software. Software or Programs A set of detailed directions telling the computer exactly what to do, one step at a time. Can be one line of code or several.
Chapter 12: Systems Investigation and Analysis. Agenda  How to Develop a CBIS?  Systems Development Life Cycle (SDLC)  Prototyping  Join Application.
LIANZA Sept Getting it together for libraries : Designing a collaborative learning centre Karen Kealy, Manager, Planning and Projects Information.
INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
Overall Quality Assurance, Selecting and managing external consultants and outsourcing Baku Training Module.
Process Assessment Method
Learning Paths Simplified Kim Simmons, BMC Software Learning: Re-Imagined.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Facilitate Group Learning
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
Project management Topic 7 Controls. What is a control? Decision making activities – Planning – Monitor progress – Compare achievement with plan – Detect.
Project Initiation at The Regence Group 12/19/2015John Garrigues1.
Computer Science 340 Software Design & Testing Software Architecture.
Advances In Software Inspection
ICME Interdisciplinary Case Management Experience.
Publishing Services Bureau Web Communications Services Tips for managing the publication process Communications Workshop October 23, 2003.
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
© 2013 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. The Value Review.
CHAPTER 4 PLANNING. Introduction Plans – Methods formulated beforehand for achieving a desired result. – Plans should specify at minimum what will you.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Project Management ISE 5101 Karl Smith Project Monitoring & Control I Project Meetings.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
CCSAS V2 Impacts on Business and Legal Processes October 4, 2006.
Assessment Centres workshop Arti Kumar, Senior Careers Adviser / CETL Fellow Marie O’Flaherty Careers Adviser.
Software Architecture in Practice
Architecture & System Performance
Architecture & System Performance
Version 0.1Assessment Method Overview - 1 Process Assessment Method An objective model-independent method to assess the capability of an organization to.
Architecture review methods
Architecture review methods
Dr. Rob Hasker SE 3800 Note 9 Reviews.
QA Reviews Lecture # 6.
Agenda Purpose for Project Goals & Objectives Project Process & Status Common Themes Outcomes & Deliverables Next steps.
Presentation transcript:

Architecture review methods Assumptions Types of reviews Prework The review Follow-on activity Value of architecture review Other types of reviews

Assumptions The architecture team believes that the review may be helpful to them The review will be conducted by a small team of experienced architects from outside the project There will be an opportunity to apply learning from the review to the software

Types of reviews Early Architecture is just emerging Focus is on assessing direction Regular Architecture is mostly done Focus is on validating against requirements Quality attribute assessment Architecture has a problem or coming change Focus is on how to fix or adapt

Types of pre-work Define review objectives Form review team Set agenda Collect and excerpt existing documentation Prepare talks (and possibly docs) specifically for the review Checklists Prototype and/or measure

Sample checklist questions - performance Are the key scenarios defined? Are frequencies for key scenarios known? Has hardware been selected? If not, is the economically-feasible range known? Do budgets exist for shared resources (CPU, memory, disk space, disk accesses, etc)? Do developers know their resource allocations? Do developers have a way to check their resource utilization?

The review “Typical” agenda Ground rules Recording methods

“Typical” agenda Introductions Purpose and objectives Requirements Overall architecture Architecture for critical subsystems Quality attributes Reviewers’ caucus Reviewers’ feedback to the project team

Ground rules Do not design on the fly!!! But it’s OK to suggest approaches or resources Most aspects of the project have some connection with the architecture, so all types of questions are in order But time is limited All participants’ ideas may have value But time is limited

Recording methods Scribe(s) “snow” cards Overuse of Singleton pattern – likely to limit scalability DESPerf/Cap CR

Follow-on activity Written report Communication with upper management and/or project sponsor Project response to issues raised Ongoing consulting

Value of architecture review Decisions made as part of pre-work Documentation written Amplification of projects’ up-the-chain messages Once in a while, uncovering a critical issue Education for project team Improved cross-project awareness Identifying cross-project trends

Other types of reviews Business case Requirements Software design UI design Code reviews, code inspections Test plans Project management