© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.

Slides:



Advertisements
Similar presentations
1.Quality-“a characteristic or attribute of something.” As an attribute of an item, quality refers to measurable characteristics— things we are able to.
Advertisements

Software Quality Assurance Plan
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
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”
Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003.
1 Software Testing and Quality Assurance Lecture 2 Software Verification & Validation.
Code Inspections CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 22, 2007.
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited Review objectives Formal design reviews (FDRs) Participants Preparations.
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations.
SE 555 Software Requirements & Specification Requirements Validation.
SOFTWARE PROJECT MANAGEMENT Project Quality Management Dr. Ahmet TÜMAY, PMP.
Verification and Validation
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
Design Reviews Peer Reviews. Agenda Peer Reviews Participants of Peer Review Preparation for a Peer Review Session The Peer Review Session Post-peer Review.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Context of Software Product Design.
Copyright Course Technology 1999
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Use Cases Descriptions and Use Case Models.
Introduction to Software Quality Assurance (SQA)
Software Inspections and Walkthroughs By. Adnan khan.
Applying the Inspection Process. What Software Artifacts Are Candidates for Inspection? Software Requirements Software Designs Code Test Plans.
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.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Software Quality Assurance
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
CPSC 873 John D. McGregor Session 4 Requirements V & V - continued.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
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.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Code review. informal formal ad hoc reviewpair programmingwalk throughinspection/review.
Project quality management. Introduction Project quality management includes the process required to ensure that the project satisfies the needs for which.
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Finalizing Software Architectures.
Reviews mae, fall 11. Review What: – Have skilled people assess your work –Requires that you have work product that is reviewable Why: – Find problems.
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.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Prototyping.
Software Requirements Specification Document (SRS)
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Alternative Generation, Evaluation, and Selection.
Advances In Software Inspection
Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also:
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
Information Technology Project Management, Seventh Edition.
1 Software Testing and Quality Assurance Motivation and Review of Software Verification & Validation (2)
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
© Mahindra Satyam 2009 Inspections and Reviews QMS Training.
Software Reviews Ashima Wadhwa.
Software Quality Control and Quality Assurance: Introduction
Software Configuration Management (SCM)
John D. McGregor Session 4 Requirements V & V - continued
Peer Reviews 11/21/2018.
QA Reviews Lecture # 6.
Software Reviews.
Presentation transcript:

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2 Objectives  To explain product design finalization  To present SRS quality criteria and assign responsibility for them  To define several types of reviews  To examine inspections in detail

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 3 Topics  Product design finalization  SRS quality characteristics  Reviews  Inspections Roles Process Activities Checklists

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 4 Software Product Design Process

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 5 Design Finalization  Final product design step  Ensures that requirements are properly documented Designer review  Ensures that requirements are valid (that is, the product design is good) Stakeholder review

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6 SRS Quality Characteristics 1  Well-formedness—An SRS is well formed if it conforms to all rules about stating requirements.  Clarity—An SRS is clear if it is easy to understand.  Consistency—A set of requirements is consistent if a single product can satisfy them all.  Completeness—An SRS is complete if it includes every relevant requirement.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7 SRS Quality Characteristics 2  Verifiability—Every requirements in an SRS must be verifiable.  Uniformity—A description has uniformity when it treats similar items similarly.  Feasibility—An SRS contains feasible requirements when designers are confident that they can be satisfied.  Developers should check all these characteristics.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 8 SRS Quality Characteristics 3  Correctness—An SRS is correct if it specifies a product that satisfies stakeholder needs and desires, subject to constraints.  Proper requirements prioritization—All requirements are prioritized in accord with stakeholder needs and desires.  Stakeholders should check these requirements validation characteristics.

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

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 10 Types of Reviews  Desk check—An examination of a work product by an individual. Often the author (proofreading) Checklists  Walkthrough—An informal examination of a work product by a team of reviewers. No assigned roles, no set process Usually preparation (desk check) by reviewers  Inspection—Formal work product review by trained team of inspectors with assigned roles using a checklist to find defects. Mandatory preparation Formal review process

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 11 Requirements Inspections  Find as many defects as possible  Not intended to evaluate the author  Not intended to correct defects  Expensive and time consuming  Efficient and cost effective  Can be used for any work product

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 12 Inspection Roles  Moderator—Manages and facilitates the process  Inspector—Searches for defects  Author—Originates the work product  Reader—Reads the work product during the inspection meeting  Recorder—Notes defects found, issues, inspection characteristics, etc.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 13 Inspection Process

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 14 Preparation Activities  Readiness check Usually done by the moderator Ensures that the work product has no obvious defects  Overview meeting Short (~20 minutes) Tasks  Schedule review meeting  Distribute work product, checklist, etc.  Answer questions May be done electronically  Each inspector carefully reviews the work product using a checklist Takes several hours

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 15 Inspection Meeting  Moderator insures that inspectors are ready; if not, the meeting is rescheduled  Reader reads through the work product  Inspectors note defects or raise issues  Recorder notes all defects, issues, comments, collects data, etc.  The meeting should not last more than two hours  There should not be more than one inspection meeting per day

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 16 Inspection Checklist  Must be specific to work products and projects  Should be modified continuously Checklist items should be removed if they rarely turn up defects Checklist items should be added to find defects that are often missed

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 17 Requirements Inspection Checklist Example  Every requirement is atomic.  Every requirement statement uses “must” or “shall.”  Every requirement statement is in the active voice.  Terms are used with the same meaning throughout.  No synonyms are used.  Every requirement statement is clear.  No requirement is inconsistent with any other requirement.  No needed feature, function, or capability is unspecified.  No needed characteristic or property is unspecified.  All design elements are specified to the physical level of abstraction.  Every requirement is verifiable.  Similar design elements are treated similarly.  Every requirement can be realized in software.  Every requirement plays a part in satisfying some stakeholder’s needs or desires.  Every requirement correctly reflects some stakeholder’s needs or desires.  Every requirement statement is prioritized.  Every requirement priority is correct.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 18 Inspection Conclusion  The author corrects defects found by inspectors.  The moderator ensures that all defects are dealt with.  If the work product is much changed or still appears to have defects, another inspection may be scheduled.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 19 Summary  Design finalization ensures that the SRS is of high quality.  Designers and stakeholders review the SRS for various quality characteristics.  Reviews include desk checks, walkthroughs, and inspections.  Inspections are reviews with explicit goals, assigned roles, and a formal process, that relies on checklists to find defects.