Formal and Informal Peer Reviews

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

MODELING THE TESTING PROCESS Formal Testing (1.0) Requirements Software Design Risk Data Approved, Debugged, Eng. Tested Code Automated Test Tools Tested.
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
More CMM Part Two : Details.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
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.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003.
Stepan Potiyenko ISS Sr.SW Developer.
Code Inspections CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 22, 2007.
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.
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.
KENDA ALBERTSON Formal Peer Review Processes for Software and Documents.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
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.
Copyright Course Technology 1999
Software Inspections and Walkthroughs By. Adnan khan.
Slide 6.1 CHAPTER 6 TESTING. Slide 6.2 Overview l Quality issues l Nonexecution-based testing l Execution-based testing l What should be tested? l Testing.
Page 1 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
Software Reviews. Introduction/Motivation When creating written documents, it is a good idea to have someone else proof read your work. Oftentimes an.
S oftware Q uality A ssurance Part One Reviews and Inspections.
Software Quality Assurance Activities
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.
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
S Q A.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
IT Requirements Management Balancing Needs and Expectations.
Georgia Institute of Technology CS 4320 Fall 2003.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
© Mahindra Satyam 2009 Configuration Management QMS Training.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
OHT 7.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software development methodologies: - The software development life cycle.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Inspection and Review The main objective of an Inspection or a Review is to Detect Defects. (Today -there may be some other goals or broader definition.
Inspection and Review The main objective of an Inspection or a Review is to detect defects. This activity and procedure was first formalized by Mike Fagan.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also:
Management of Software Project CSM Review By:Nafas.
Peer Review Presented by : Basker George. Peer ( 同等的人 ) Review( 回顾 ) During the development of software, defects are inevitably ( 不可避免 ) injected. Defect.
Peer Review Overview Meeting [Date] [Product name]
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
1 Definition Quality costs Plan Team Characteristics Implementation documentation Reviews & Audit Software Quality Assurance.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
SQA COMPONENTS IN THE PROJECT LIFE CYCLE C HAPTER 8 Dr. Ahmad F. Shubita.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
Review Techniques SEII-Lecture 16
Software Project Configuration Management
Software Quality Control and Quality Assurance: Introduction
CIS 375 Bruce R. Maxim UM-Dearborn
Software Configuration Management (SCM)
Software Verification and Validation
Software Configuration Management
CMMI – Staged Representation
Inspection and Review The main objective of an Inspection or a Review is to detect defects. (Not for Giving Alternative Solutions) This activity and procedure.
QA Reviews Lecture # 6.
Engineering Processes
Code Reviews Assignment Each team should perform a code review
Software Reviews.
3. Software Quality Management
Presentation transcript:

Formal and Informal Peer Reviews Peer Review Process Formal and Informal Peer Reviews Good Afternoon, In today’s class we are going to focus on the relationship between organizational structure, organizational culture; organizational design and strategy in a global environment.

Objectives Understand the Peer Review process Subprocess to the Verification and Validation Process Understand how defect measures are used for process improvement

Peer Review Because... Deliver quality products Catch defects earlier in the lifecycle Improve skills and knowledge Improve process performance

CMMI Basis Peer reviews are part of Verification “...to ensure that selected work products meet their specified requirements.” SG 2: “Peer reviews are performed on selected work products.” The Peer Review Process is an appendix to the Verification and Validation Process BPS/16-Verification and Validation

Peer Review Roles Employee Responsibilities Project Manager 1. Identifies and schedules reviews 2. Identifies personnel resource needs 3. Assigns moderator 4. Does not attend the review Author 1. Creates work product to be reviewed 2. Prepares and present overview, as needed 3. Completes rework Moderator 1. Works with producer/developer/author to schedule formal peer review 2. Ensures that review discussion focuses on the product and not the producer/developer/author. 3. Briefs inspection team roles 4. Distributes inspection materials 5. Ensures that the recorder documents all errors and action items Quality Assurance (QA) 1. Ensures PR process is followed Reviewer 1. Reviews work products for errors and issues, recording review time spent and findings on an inspection problem report (IPR) Scribe (recorder) 1. Completes the IPR, recording duration of the PR and all defects and issues identified

Terms Defect—A flaw that causes a work product to fail to perform a required function or behave contrary to documented expectations Major defect—A defect that if not corrected prevents the product from meeting its requirements. Requires correction before the work product may be promoted to the next phase in the lifecycle. Minor defect—A defect that if not corrected means the product will not meet specifications, design, or standards completely, but will not prevent the product from otherwise operating or serving its purpose. A project manager may decide to permit a work product to be promoted to the next phase in the lifecycle without all minor defects being corrected. This decision must be documented on the IPR form.

Terms Other defect—A deviation from standards and specifications; or a trivial issue, such as a format/spelling/grammar errors or other typos that do not affect meaning. A large number of format/spelling/grammar errors or other typos may constitute one major defect because a document that does not get the spelling/grammar/formatting right may be perceived as unlikely to have the facts right either. If disregard for coding standards results in code that, while meeting the requirements, will be difficult to maintained or will complicate current or future integration or interfaces, it may constitute a major defect. Defect type—A classification of a defect indicating what sort of error was committed. The choice of types differs depending on what is being reviewed.

Types of Peer Reviews Material Reviewed Type of Review Code Design Document Requirements Type of Review Formal Informal

Material Reviewed This table shows a standard arrangement of work products and types of reviews, but this scheme may be modified and documented in the SDP. Work Product PR Type Recommended Participants Major software units Required Formal Experts in the coding language; testers Major software unit design Informal Requirements analysts, developers/coders; testers Minor software units, updates Recommended Another developer Requirements Requirements specialists, designers, coders, testers System test description Testers, technical writers, QA analysts User's guide/release notes Developers; requirements analysts; technical writers

Resources (in BPS) Process /13-Verification and Validation Peer Review Form /13-Verification and Validation/ Tools Guides and Templates/ Peer Review Form.xls Guidelines /13-Verification and Validation/ Tools Guides and Templates/ Guidelines for <x> Reviews.doc Standards /Organizational Process Assets/Standards

Formal Peer Reviews Planning and preparing Conducting the peer review Documenting the findings Follow-up work

Formal PR: Plan and Prepare Project manager selects reviewers Moderator sets time and place Two days (at least) before the review, sends: Invitation Material to be reviewed IPR form Review guidelines Standard to be used

Formal PR: Conduct the Review Discuss the work product, not the author Come prepared with a list of defects and questions Set a time limit Do not solve problems during the peer review, document them Consensus on major/minor/other, category

Formal PR: Document Findings Complete information Select Type Size and time are required for measurements

Formal PR: Document Findings Types listed on page 1 and in process Defect Recording Follow-Up Work Disposition: Deferred, Closed, No Action

Formal PR: Document Findings

Formal PR: Follow-Up Project manager and author determine what to correct Finish IPR form and put it in the project’s SDLC Info/Peer Review directory. QA checks to see whether action items are completed Billing: Follow-Up Work on IPR form does not include defect correction, just work to complete the form PR review, meeting, and form work bill to Peer Reviews Defect correction work bill to Debug

Informal PR Project manager assigns a reviewer Findings can be in IPR, e-mail, annotation, etc. Findings still go in /Peer Reviews Author updates work products based on the review results, consulting with the reviewer as needed. As in formal peer review follow-ups, the project manager resolves disagreements over defects and other issues. Once all the changes have been agreed to and made, the author forwards the modified work product to the project manager or to the CM group for inclusion in the project baseline.

Measurements Collected in MA spreadsheet Reviews Page Dashboard Page

Additional Analysis Negative correlation between % of IPR time spent on review and defects per review hour

Additional Analysis Correlation between review time per LOC and defects found per LOC

Review VER SP 2.1: Prepare for peer reviews How do we prepare? Schedule Select work product for review Invitation Guidelines/standards Review material Training

Review VER SP 2.2: Conduct peer reviews Things to remember during a peer review Review the work, not the author Don’t solve defects, document them Develop consensus on defects, type, category List defects on IPR form Correct defects, update form

Review VER SP 2.3: Analyze peer review data Data collected where? Used for what? IPR forms MA spreadsheet Additional analysis Used for process improvement, to check process efficiency, etc.