Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also:

Slides:



Advertisements
Similar presentations
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Advertisements

CSE101 Lab 3 Lecture Productive Team Work and Meeting CSE 101 Yinong Chen 1.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
Applied Software Project Management Andrew Stellman & Jennifer Greenehttp:// Applied Software Project Management Introduction.
Applied Software Project Management INTRODUCTION Applied Software Project Management 1 5/20/2015.
Code Inspections CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 22, 2007.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Quality is about testing early and testing often Joe Apuzzo, Ngozi Nwana, Sweety Varghese Student/Faculty Research Day CSIS Pace University May 6th, 2005.
SE 555 Software Requirements & Specification Requirements Validation.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Why Software.
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
Course Technology Chapter 3: Project Integration Management.
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
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Copyright Course Technology 1999
Software Quality Chapter Software Quality  How can you tell if software has high quality?  How can we measure the quality of software?  How.
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.
Applied Software Project Management Andrew Stellman & Jennifer Greenehttp:// Applied Software Project Management Chapter 1: Introduction.
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
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.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality Part 4:
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.
Formal and Informal Peer Reviews
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Software Project Planning Chapter 2 Applied Software Project Management, Stellman & Greene.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
Applied Software Project Management
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Chapter 19 Verification and Validation.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Chapter 12: Software Inspection Omar Meqdadi SE 3860 Lecture 12 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Code Reviews James Walden Northern Kentucky University.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Software Defects.
W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Reviews mae, fall 11. Review What: – Have skilled people assess your work –Requires that you have work product that is reviewable Why: – Find problems.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Senior DesignSeattle Pacific UniversitySenior Design Design-1 Seattle Pacific University Stages of Engineering Design 1. Identify project and goals 2.
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 Configuration Management (SCM)
Software Inspections and Testing
Applied Software Project Management
QA Reviews Lecture # 6.
The Software Testing Life Cycle
Chapter 3: Project Integration Management
Code Reviews Assignment Each team should perform a code review
Software Reviews.
MPATE-GE 2626: Thesis in Music Technology
Presentation transcript:

Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also:

Inspections  To get approval for completion of a work product  To prevent defects  “... it costs more to not do inspections than it does to do them.” report from Software Engineering Institute  Goals: For team to reach consensus and approve/understand each work product Repair known defects early in the process  See paragraph 3, p. 75  Choice of moderator is important Objective Time conscious Understands issues Prepares author and inspectors to critique work (not criticize) and come up with solutions

Inspecting the work product  Process Preparation – each inspector marks defects; perhaps each submits a list of defects before the meeting Overview – if someone is not prepared, meeting is rescheduled Page-by-page review – team identifies new wording  If not resolved, logged as open and assigned to inspector who raised the issue Rework – changes are made in the inspection log Follow-up – moderator sends revision and asks for approval of inspectors Approval – moderator gets signatures

Managing the author’s expectations  Nobody likes to have their work criticized  Purpose of discussions is not to teach inspectors about the project, but to change the document so that all will approve  If an inspector did not understand something in the document, the document should most likely be revised  It is tempting for the author to get defensive, but must remember the goal is to clear up ambiguity  One way to sidestep this issue is to have all defects sent to moderator. Thus author is prepared to respond appropriately.  Sometimes the author is excluded from the meeting or asked to not talk

Standard objections to inspections  Inspections take too long In fact may take about 2 hours  Authors don’t like others criticizing their work Note that all make mistakes Author may not have enough information Author will feel worse when defects are caught later  People are protective of their work

Deskchecks  Less formal than a full inspection; often used for vision and scope documents  Sent to selected team members  Does not produce written logs  May be done as a preliminary to inspection

Walkthroughs  Author calls meeting of users, stakeholders, engineers, managers, etc., solicits comments, ensures that all present understand the work product (set of slides perhaps)  Good for brainstorming new or alternative ideas  Guidelines: Verify that all who need to review the work product are present Verify that all present understand the purpose of the walkthrough Describe each section of material to be covered Present material in each section, ensuring that all understand Lead a discussion to identify any missing sections or material Document all issues raised Follow up as needed

Code Reviews  Team examines a section of code and fixes defects Code that doesn’t properly implement requirements Code that doesn’t function as programmer intended, or Code that is not wrong, but could be improved  Only a subset of carefully chosen code is used One estimate ~2 hours to review 400 loc Tricky code, difficult environment, novice programmer?  Process There is a knowledgeable code reader who briefly describes purpose of code blocks and sets pace Author may respond to questions If defect is found, fix is made if easy to do so Good to switch readers

Pair Programming  Like tennis doubles, but much more fun  Two work together at a single computer and continuously review each other’s work  Ensures that at least two people know the product  Junior-level and senior-level can work together  People may be more thorough with someone reading their work, or more energized working together

Other...  Use inspections to manage commitments  Diagnosing review problems Defects are likely introduced long before any code is written Problems found too late … when QA finds problem Big, useless meetings when a project went sour The indispensable “hero” is tough to schedule and over allocated and the only one who seems to know what is going on  Code reviews and pair programming can alleviate dependence on a hero