© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Finalizing Software Architectures.

Slides:



Advertisements
Similar presentations
A GUIDE TO CREATING QUALITY ONLINE LEARNING DOING DISTANCE EDUCATION WELL.
Advertisements

Software Quality David Jones, Director. 2 Agenda What is it and why is it important? How do we deliver it? Conclusions.
What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Static Technique. Static Technique - Review  A way of testing software work products  Program code, requirement spec., design spec.  Test plan, test.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
6.1 Copyright © 2014 Pearson Education, Inc. publishing as Prentice Hall Building Information Systems Chapter 13 VIDEO CASES Video Case 1: IBM: Business.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
System Implementations American corporations spend about $300 Billion a year on software implementation/upgrade projects.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
System Implementations American corporations spend about $300 Billion a year on software implementation/upgrade projects.
Software Quality Assurance For Software Engineering && Architecture and Design.
Team Leadership AGED 3153.
Security Assessments FITSP-M Module 5. Security control assessments are not about checklists, simple pass-fail results, or generating paperwork to pass.
Types of Formal Reports Chapter 14. Definition  Report is the term used for a group of documents that inform, analyze or recommend.  We will categorize.
Project Life Cycle Introduction and Overview © Ed Green Penn State University All Rights Reserved.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Software Design Processes and Management.
S/W Project Management
Computers Are Your Future Eleventh Edition Chapter 13: Systems Analysis & Design Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall1.
Security Assessments FITSP-A Module 5
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Design.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Detailed Design Overview and Mid-Level Class Modeling.
S oftware Q uality A ssurance Part One Reviews and Inspections.
Software Quality Assurance Activities
Chapter 121 The Examine Process Chapter 12 Achieving Quality Through Continual Improvement Claude W. Burrill / Johannes Ledolter Published by John Wiley.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Multimedia Specification Design and Production 2013 / Semester 1 / week 9 Lecturer: Dr. Nikos Gazepidis
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Requirements Specification for Lab3 COP4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of Computer Science University.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
© 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.
Process Improvement. Improving the Test Process In the Software V&V course, Prof. Uwe asked the question: How to improve the Testing Process?
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Systems Analysis and Design in a Changing World, Fourth Edition
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Software Engineering Lecture # 1.
Project management Topic 8 Quality Review. Overview of processes Prepare for Quality Review Questions list Meeting Agenda Review Meeting Sign-off Product.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
Task Analysis Lecture # 8 Gabriel Spitz 1. Key Points  Task Analysis is a critical element of UI Design  It describes what is a user doing or will.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Prototyping.
Task Analysis Lecture # 8 Gabriel Spitz 1. Key Points  Task Analysis is a critical element of UI Design  It specifies what functions the user will need.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Alternative Generation, Evaluation, and Selection.
Quality Assurance. Define Quality (product & service) Exceeds the requirements of the customer. General excellence of standard or level. A product which.
© 2013 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. The Value Review.
44222: Information Systems Development
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
1 Sobah Abbas Petersen Adjunct Associate Professor, NTNU Researcher, Sintef TDT4252 Modelling of Information Systems Advanced Course TDT4252,
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
Systems Analysis Lecture 5 Requirements Investigation and Analysis 1 BTEC HNC Systems Support Castle College 2007/8.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Stages of Research and Development
Software Reviews Ashima Wadhwa.
Software Quality Assurance
Project planning The systems life cycle.
Software Configuration Management (SCM)
Software Quality Assurance
Chapter 5 Determining System Requirements
Topic for Presentaion-2
Software Quality Assurance
Effectively Training Parents in Behavior Analytic Interventions
Chapter 5 Architectural Design.
Unit IV – Chapter 2 V-Test Model.
Presentation transcript:

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Finalizing Software Architectures

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2 Objectives  To present SAD quality characteristics  To survey different kinds of reviews  To present an example of an architecture inspection checklist  To present active design reviews in detail  To advocate continuous review during the design process

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 3 Topics  SAD quality characteristics  Reviews  Types of reviews  An architecture inspection checklist  Active design reviews  Continuous review

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 4 SAD Quality Characteristics 1  Feasibility—The SAD specifies a program that can be built.  Adequacy—The SAD specifies a program that will satisfy its requirements.  Well-Formedness—The notations in the SAD are used correctly.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 5 SAD Quality Characteristics 2  Completeness—The SAD includes all required sections; contains models needed to explain the design; and specifies all important component characteristics, relationships, interactions, etc.  Clarity—The SAD is understandable to someone familiar with the problem and notations.  Consistency—A single program can satisfy the specifications in the SAD.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6 Reviews A review is an examination and evaluation of a work product or process by a team of qualified individuals.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7 Types of Reviews  Desk Check—An assessment of a design by the designer  Walkthrough—An informal presentation to a team of designers  Inspection—A formal review by a trained inspection team  Audit—A review conducted by experts from outside the design team  Active Review—An examination by experts who answer specific questions about the design

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 8 An Architecture Inspection Checklist  The notations used for each model are correct.  Every required section of the SAD is present.  The SAD specifies the program’s main components.  The SAD specifies the states and state transitions for all components with important states.  The SAD specifies important or complex component collaborations.  The SAD specifies each component’s responsibilities.  The SAD specifies each component’s interface.  The SAD specifies each component’s important properties.  The SAD specifies each component’s important relationships to other components.  The SAD clearly states the connections between different architectural models.  The SAD states the rationale for all important design decisions.  Each design rationale states the problem to be solved and the constraints on the designer.  Each design rationale summarizes the major design alternatives and their evaluations.  Each design rationale explains why the final design was selected.  All specifications are clear.  No specification contradicts any other specification in the SAD.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 9 Active Design Reviews  Remedies problems with traditional reviews Lack of expertise Cursory reviews  Forces reviewers to engage the document in their areas of expertise by asking them to answer specific questions about design details

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 10 Active Design Review Process

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 11 Review Preparation  Identify Review Goals—Designers choose aspects of the design they want checked.  Choose Reviewers—Designers identify two to four qualified reviewers and obtain their consent to do the review.  Create Questions—Designers formulate questions to be answered by reviewers. Force reviewers to understand the design Ask reviewers to solve problems, explain something, etc.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 12 Review Performance  Hold an Overview Meeting—Designers sketch the architecture, explain the process, set deadlines, etc.  Do Reviews—The reviewers do their reviews on their own. May meet with designers are send s to get clarification, explanations, etc. Deliver their results when complete

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 13 Review Completion  Study Reviews—Designers study the review results. May meet with reviewers or questions

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 14 Continuous Review  The sooner a defect is fixed, the cheaper it is to fix.  Reviews must be done when design artifacts are complete as a final quality check.  Reviews should also be done during the design process to catch defects as soon as possible.  Different kinds of reviews are appropriate at different stages of the process (discuss).

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 15 Summary  A SAD should be reviewed when substantially complete to ensure that it Specifies a feasible and adequate architecture; Has well-formed models; and Is complete, clear, and consistent.  Various sorts of reviews can be used.  An effective form of review is the active review.  Reviews should be done when artifacts are complete and also throughout the design process.