0% found this document useful (0 votes)
108 views27 pages

4 - AAS Software Reviews - All Sides

Software reviews involve several types of peer review processes to improve software quality, including informal buddy checking, walkthroughs where authors present to peers, and formal inspections. Modern code reviews are typically asynchronous, tool-based reviews of pull requests. Software reviews can be applied throughout the software lifecycle to requirements, design, code, testing, and maintenance.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
108 views27 pages

4 - AAS Software Reviews - All Sides

Software reviews involve several types of peer review processes to improve software quality, including informal buddy checking, walkthroughs where authors present to peers, and formal inspections. Modern code reviews are typically asynchronous, tool-based reviews of pull requests. Software reviews can be applied throughout the software lifecycle to requirements, design, code, testing, and maintenance.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

Analysis of Software Artifacts

Departamento de Engenharia Informática, FCTUC

Analysis of Software Artifacts (ASA)


Henrique Madeira,
Departamento de Engenharia Informática
Faculdade de Ciências e Tecnologia da Universidade de Coimbra
2022/2023

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 1

Software Reviews and Inspections

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 119

119

Henrique Madeira, 2022/2023 1


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Software reviews

• Software reviews are a “quality improvement processes for


written material”.
• Follow the general idea that written material (e.g., papers,
books, leaflets, … and software) must go to successive
review (“re view”) interactions to improve quality.
• Help supporting the objectives of:
– Project management
– Systems engineering
– Verification and validation
– Configuration management
– Quality assurance
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 120

120

Types of software reviews


• Buddy checking
Informal review of a document or work done by a person (other than the author). In
general, this does not involve the use of checklists to guide the process and as such
is not repeatable.

• Walkthrough
Presentation done by the author of an artifact to a peer audience to provide the
author comments and feedbacks. Usually, involves limited documentation of the
process and the issues uncovered, which makes defect tracking difficult.

• Review by circulation (often called asynchronous review)


Consist of circulating an artifact among peers for comments; operates like a
walkthrough but without holding a meeting. Not holding a meeting avoids potential
arguments over issues, but it also misses the benefits of discussion. Most software
companies use specific tools to enforce this type of reviews for code review.

• Formal inspection
Formal and managed peer review process.

Henrique M adeiraAdapted from Dr Issa Traore slides, University of Victoria, Canada Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 121

121

Henrique Madeira, 2022/2023 2


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Types of software reviews


• Buddy checking Software reviews involve several
Informal review of a document or work done by a person (other than the author). In
general, this does not involve the use of people:
checklists the costthe
to guide is process
normally high
and as such
is not repeatable.

• Walkthrough
Presentation done by the author of an artifact to a peer audience to provide the
author comments and feedbacks. Usually, involves limited documentation of the
process and the issues uncovered, which makes defect tracking difficult.

• Review by circulation (often called asynchronous review)


Consist of circulating an artifact among peers for comments; operates like a
walkthrough but without holding a meeting. Not holding a meeting avoids potential
arguments over issues, but it also misses the benefits of discussion. Most software
companies use specific tools to enforce this type of reviews for code review.

• Formal inspection
Formal and managed peer review process.

Henrique M adeiraAdapted from Dr Issa Traore slides, University of Victoria, Canada Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 122

122

Fagan's Inspection (formal inspections)

Software inspections were proposed by Michel Fagan, from IBM,


in 1976. Many variants have been proposed since then. Companies
such as Google have largely improved software inspections.
• Definition
“A highly structured, clearly defined process by which software
documents/artifacts are reviewed in detail by a team including the author
and, ideally, the customer.”

• Goal
To identify defects (i.e., faults or bugs) as closely as possible to the point of
occurrence in order to facilitate corrective actions.
M. E. Fagan, “Design and code inspections to reduce errors in program development”, IBM
System Journal. vol. 15, No. 3, pages 183–211, 1976.

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 123

123

Henrique Madeira, 2022/2023 3


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Modern code review (asynchronous reviews)

Reviews by circulation are often called modern code reviews


(although they have been proposed long time ago). These reviews
are often associated with pull requests in distributed version-
control systems like Git. They have three important features:
– Tool-based: reviews are part of a process workflow managed by a
specific tools: Critique (Google), CodeFlow (Microsoft),
Phabricator (Facebook), and many more.

– Asynchronous: no need for review meetings

– Lightweight: the process is simplified to make it possible to cover


large portions of the code

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 124

124

Essential bibliography on modern code reviews

• Alberto Bacchelli and Christian Bird, “Expectations, Outcomes, and Challenges


Of Modern Code Review”, International Conference on Software Engineering.
ICSE, 2013.
• Caitlin Sadowski Emma Söderberg Luke Church Michal Sipko Alberto Bacchelli,
"Modern Code Review: A Case Study at Google", International Conference on
Software Engineering, Software Engineering in Practice track (ICSE SEIP), 2018.
• Moritz Beller, Alberto Bacchelli, Andy Zaidman, and Elmar Juergens, “Modern
Code Reviews in Open-Source Projects: Which Problems Do They Fix?”,
International Conference on Software Engineering. ICSE, Proceedings of the 11th
Working Conference on Mining Software Repositories, 2014.
• Shaumik Daityari, “12 Best Code Review Tools for Developers (2021 Edition)”,
July 27, 2020, (https://kinsta.com/blog/code-review-tools/), accessed on March 22,
2021.

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 125

125

Henrique Madeira, 2022/2023 4


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Used through the entire software life cycle

• Reviews are applicable to software products throughout


the software life cycle
– Requirements We will study in particular reviews in these
– Design two phases of the software life cycle.
– Coding Specifically, reviews of:
– Testing • Software requirements specification (SRS)
• Cleanly compiled code
– Maintenance

• Software reviews are one of the techniques used in


Software Quality Assurance (SQA)

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 126

126

What is a software artifact?

• The term “software artifact” (sometimes also referred as


“software product”) is used in a very broad sense to describe any
kind of tangible (in lato senso) element produced during the
software lifecycle.
• Examples of software artifacts:
– Contracts − Use cases
– Master project plan − UML diagrams
– Progress reports − ER diagrams
– Software design descriptions − Source code
– Release notes − Testing specification
– Software requirements specifications (SRS) − Installation plans
– … − …
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 127

127

Henrique Madeira, 2022/2023 5


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

What is a defect?

• Any occurrence in a work product that is determined to be


incomplete, incorrect, or missing
• Any instance which a requirement is not satisfied (Fagan,
1986)
• Informal synonyms: bug, fault, issue, problem

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 128

128

IEEE standard for software reviews

The 1028-2008-IEEE Standard for Software Reviews and


Audits defines 5 types of review:
– Management Reviews
– Technical Reviews
– Inspections (Formal Peer Review)
– Walkthroughs
– Audits
Very often, the terms “software review” and “software inspection”
are used interchangeably. Technically, software review is the generic
name. But when it is used in a more restrictive sense, software
review means a less formal software inspection. In fact, there are
several variants of the process original proposed by Michel Fagan.
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 129

129

Henrique Madeira, 2022/2023 6


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Common attributes, steps, and goals

• All types of reviews have these attributes in common:


– Team participation
– Documented results of the review
– Documented procedures for conducting the review

• Common steps
– Use a static analysis technique
– Perform a visual examination of the software products/artifacts
– Detect (and correct later on):
• Defects
• Violation of design standards
• Other problems

• Common Goal: detect defects early and prevent their


leakage downstream
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 130

130

The place of software reviews


in the big picture
• In software engineering, software reviews are included in
the Software Quality Assurance activities.
• The major role of the Software Quality Team is the
reviewing activity. It includes:
– Verification and validation (in general)
– Specific verification and reviewing activities:
• Software reviews and inspections To be studied
• Testing later on in the
course.
• Traceability of software deliverables
• Auditing of selected key software items
• Standards and Guidelines

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 131

131

Henrique Madeira, 2022/2023 7


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Why SQA activities pay off?

Henrique M adeira Picture from Chris Durand, CTO, Bridge360 Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 132

132

Quality improvement due to reviews


• Reviews are technical activities, not management.
• Reviews are proactive tests; find errors that cannot be found
through (dynamic) testing
• Reviews can find 60-100% of all defects (according to empirical
and field studies).
• Review data can assess/improve quality of:
– Product.
– Software development process.
– Review process itself.
• Reviews are training: improve domain knowledge, development
skills, corporate culture, and group/team building.
• Reviews reduce project rework (rework could represent a large
fraction of project cost; up to 45%).
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 133

133

Henrique Madeira, 2022/2023 8


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Quality improvement due to reviews


• Reviews are technical activities, not management.
• Reviews are proactive tests; find errors that cannot be found
through (dynamic) testing
• Reviews can find 60-100% of all defects (according to empirical
and field studies).
Cost of
rework

• Review data can assess/improve quality of:


– Product.
– Software development process.
– Review process itself.
• Reviews are training: improve domain knowledge, development
skills, corporate culture, and group/team building.
• Reviews reduce project rework (rework could represent a large
fraction of project cost; up to 45%).
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 134

134

Inspections (Formal Peer Reviews)

• Goal: confirms that the software product satisfies:


– Specifications
– Specified quality attributes
– Regulations, standards, guidelines, plans
– Identifies deviations from standard and specification
(find anomalies, in general; much more than code bugs)

• Failure to do so results in logging a defect


The focus is on finding defects; not
try to solve them during the inspection

Management is encouraged not to look


at individual inspection results
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 135

135

Henrique Madeira, 2022/2023 9


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Software products/artifacts subject to inspections

Nearly any product or element produced in the software


development lifecycle:
• Software requirements specification
• Software design description
• Source code
• Software test documentation
• Software user documentation
• Maintenance manual
• Release notes
• Etc…

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 136

136

Inspection materials

• Source document
• Checklists
• Supporting documents
• Invitations
• Inspection plan
• Issue/defect log
• Data summary

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 137

137

Henrique Madeira, 2022/2023 10


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Inspections roles
• The roles established for the inspection
– Designated moderator
An inspector responsible for organizing and reporting on inspection
– Author
Developer of software product
– Reader
An inspector who guides the examination of the product (often reads aloud)
– Recorder
An inspector who enters all the defects found on the defect list
– Inspector
Member of inspection team. Often chosen to represent specific role such as
designer, tester, technical writer, SQA, etc.

• All members can identify defects. Very often, the recorder


role is assumed by other inspector.
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 138

138

Inspections roles: minimum format

• At a minimum a formal inspection includes:


– Designated moderator
– Author of the work
– At least one peer inspector

• Walkthroughs generally do not include designated


moderator and are often led by the author of the software.

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 139

139

Henrique Madeira, 2022/2023 11


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Steps of inspection

• Planning • Planning begins when inspection entry


criteria have been met; the product is
complete and of a reasonable quality level
• Overview
• Inspection team is selected and roles
• Preparation assigned
• Moderator is selected – usually a peer or
• Meeting technical leader. Selection may be made by
developer, but this is generally not an ideal
• Rework situation
• Moderator verifies that:
• Follow-up o The product meets entry criteria and
schedules future steps.
o The inspection package compiled (work
product, standards, defect type list, etc.)
• Moderator sends inspection announcement
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 140

140

Steps of inspection (cont.)

• Planning The overview meeting is conducted by the


designated moderator with the following goals:
• Overview • Presents inspectors with any background
information needed to properly review
• Preparation software product
• Ensure inspection team obtains common
• Meeting understanding of the software product.
• Rework • Ensure each team member understands role
and responsibility.
• Follow-up • Data collected is author preparation time and
time spent in the overview meeting.

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 141

141

Henrique Madeira, 2022/2023 12


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Steps of inspection (cont.)

• Planning
• Overview • Individual activity (done by all inspectors)
• Author provides all the material required for
• Preparation inspection.
• Meeting • Inspectors study the material and complete
inspection log.
• Rework • Defects are noted at this step, but not collected

• Follow-up

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 142

142

Steps of inspection (cont.)

• Meeting is conducted by moderator


• Planning
• Agenda includes:
o Introduction
• Overview o Establishing readiness (moderator records
individual preparation time; if inadequate,
• Preparation reschedule inspection meeting)
o Examining material and recording defects
• Meeting o Debrief

• Rework
• Follow-up

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 143

143

Henrique Madeira, 2022/2023 13


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Steps of inspection (cont.)

• Planning During the meeting the moderator should:


o Ensure focus of meeting remains on identifying defects
o Ensure that the reader proceeds at an appropriate pace and
• Overview all inspectors participate
o Ensure each inspector fulfills the role assigned
• Preparation o Ensure defects identified are categorized by severity, type,
and class, based on team consensus
• Meeting o Record work product issues where team consensus cannot
be reached
o Record non-product issues as identified
• Rework
o Ensure maximum meeting time is not exceeded (2 hours)
o Ensure the entire work product is inspected (or 2 hour
• Follow-up limit reached)
o Ensure inspection defect list is complete and accurate
o Review all issues recorded and record any resolutions
o Determine need for reinspection
o Record total inspection time
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 144

144

Common meeting problems

• Interpersonal tensions are most likely to arise at this point


• Experienced moderators can detect and defuse this tension
• The more inspections that occur, the less likely
interpersonal tensions are to interfere
• Effort should be made by all participants to keep emphasis
on producing quality product, not making fault finding
personal

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 145

145

Henrique Madeira, 2022/2023 14


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Steps of inspection (cont.)

• Planning
• Performed by the author in response to defect
disposition determined at meeting
• Overview
• Preparation
• Meeting
• Rework
• Follow-up

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 146

146

Steps of inspection (cont.)

• Planning • The follow up of the work depends on the project


management process; in general is the project
manager that assures that the defects are corrected
• Overview and conform to project standards .
• Preparation • In some cases, the inspection moderator could be
in charged of assuring that the corrections are
done.
• Meeting
• One important issue is to determine if the rework
• Rework was significant enough to justify a reinspection

• Follow-up

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 147

147

Henrique Madeira, 2022/2023 15


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Inspection steps overview

Product documents Reviewed documents

Product documents Rules/


checklist

Entry Exit
Planning/ Preparation Inspection Rework
Overview

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 148

148

Summary of the roles:


responsibilities of the moderator
• Understand the information being inspected
• Lead the team in an effective discussion
• Mediate disputes
• Recognize key issues and keep the team focused on them
• Maintain an unbiased view of the information being
presented
• Assign responsibilities appropriately

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 149

149

Henrique Madeira, 2022/2023 16


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Data collected from each inspection


(often just a subset)

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 150

150

Summary of the roles:


responsibilities of the author
• Insure that the work product is ready for inspection
• Make required information available on time
• Support the moderator in making meeting arrangements, providing
copies of materials, and establishing schedules for any required
corrective action
• Promptly resolve all problems identified
• Remain objective and avoid becoming defensive

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 151

151

Henrique Madeira, 2022/2023 17


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Summary of the roles:


responsibilities of the reader
• Be thoroughly familiar with the work product being
inspected
• Identify logical chunks of information and be able to
paraphrase the information in each chunk to allow the
moderator to keep the team focused on one chunk at a time
• Support the moderator

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 152

152

Summary of the roles:


responsibilities of the inspectors
• Be thoroughly familiar with the work product being inspected as well
as the appropriate documents and standards for the product
• Identify discrepancies between the work product and applicable
documents and standards
• Focus on identifying problems, not solving them
• Remain objective
• Criticize the product not the producer
• Support the moderator

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 153

153

Henrique Madeira, 2022/2023 18


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Summary of the roles:


responsibilities of the recorder
• Be thoroughly familiar with the work product being
inspected
• Record all issues raised by the team and ensure that they are
recorded correctly
• Record additional information as requested by the
moderator
• Support the moderator

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 154

154

Responsibilities of the project manager

• Help decide what to inspect


• Include inspections in project schedules
• Allocate resources for inspections
• Support inspection training
• Participate in the selection of moderators
• Support the moderator in completing any required rework

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 155

155

Henrique Madeira, 2022/2023 19


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Main software reviews targets considered

• Reviews are applicable to software products throughout


the software life cycle
– Requirements We will study in particular reviews in these
– Design two phases of the software life cycle.
– Coding Specifically, reviews of:
– Testing • Software requirements specification (SRS)
• Cleanly compiled code
– Maintenance

• Software reviews are one of the techniques used in


Software Quality Assurance (SQA)

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 156

156

Requirements inspections

“If you can only afford to do one inspection on a project,


you will get the biggest return on investment from a
requirements inspection. A requirements inspection should
be the one inspection that is never skipped.”
- Steven R. Rakitin

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 157

157

Henrique Madeira, 2022/2023 20


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Why are requirements inspections important?

• Requirements are the most common source of problems in


the development process
• Requirements are written in natural language by people
who typically have little or no training in writing software
requirements
• Natural language (English, Portuguese,…) is imprecise,
ambiguous, and nondeterministic

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 158

158

Attributes of good requirements specifications

• Unambiguous
• Complete
This is the key for checklist
• Verifiable of a review of requirements
• Consistent
• Modifiable
• Traceable
• Usable

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 159

159

Henrique Madeira, 2022/2023 21


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Requirements inspection objectives

• Make sure each requirement in the Software Requirements


Specification (SRS) is clear, concise, internally consistent,
unambiguous, and testable
• Make sure each requirement in the SRS is consistent and
traceable to the document that preceded the SRS

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 160

160

IEEE standard for SRS


EEE-SA Std. 830-1993 (in part, covered by ISO/IEC 12207)

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 161

161

Henrique Madeira, 2022/2023 22


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

IEEE standard for SRS


EEE-SA Std. 830-1993 (in part, covered by ISO/IEC 12207)

Example of one requirement


(taken from a real SRS)

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 162

162

Typical support documents used in


inspections
• Checklists
– Moderator checklist
– Inspector checklist
– Artifact/Language specific checklist (Requirements, code, etc.)
– Others…
• Inspection Issue Log (used by individual inspectors during
preparation and used as inspection log in the meeting)
• Inspection Summary Report
• Typos List
• Inspection Lessons Learned Questionnaire

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 163

163

Henrique Madeira, 2022/2023 23


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Requirements inspection checklist example

1. Do requirements exhibit a clear distinction between functions and data?


2. Do requirements define all the information to be displayed to users?
3. Do requirements address system and user response to error conditions?
4. Is each requirement stated clearly, concisely, and unambiguously?
5. Is each requirement testable?
6. Are there ambiguous or implied requirements?
7. Are there conflicting requirements?
8. Are there areas not addressed in the Software Requirements Specification
(SRS) that need to be?
9. Are performance requirements (such as response time, data storage
requirements) stated?
Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 164

164

Code inspections
• Inspectors use checklists for each programming language to
help in the task of finding defects. The fault classes are
similar across the different languages.
• In general, the defect classification used is general, and
works for different types of products
• Elaborate defect classifications can be used such as
Orthogonal Defect Classification (ODC).
(addressed later on in the course)

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 165

165

Henrique Madeira, 2022/2023 24


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Code inspections checklists example


• Inspectors use checklists for each programming language to
help in the task of finding defects. The fault classes are
similar across the different languages. Example:

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 166

166

Typical support documents used in


inspections: Inspection Issue Log

Inspection Issue Log

Project: ___________________ Origin: Requirements, Design, Implementation, Testing


Inspection ID: ___________________ Type: Missing, Wrong, Extra, Usability, Performance,
Meeting Date: ___________________ Style, Clarity, Question
Recorder: ___________________ Severity: Major, minor

Defects Found: ____ Major, ____ minor Defects Corrected: ____ Major ____ minor

Origin Type Severity Location Description

1.
Used by individual inspectors during
2. preparation and used as inspection log in
the meeting by the moderator.
3.

4.

Henrique M adeira 5. Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 167

167
6.

7.

8. Henrique Madeira, 2022/2023 25

9.
Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Typical support documents used in


inspections: Inspection Summary Report

Inspection Summary Report

Inspection Identification:

Project:
Inspection ID:
Meeting Date:

Work Product Description:

Inspectors Signature Preparation Time


1. Author: _____________________ _________________________ ________ hours
2. Moderator: _____________________ _________________________ ________ hours
3. Recorder: _____________________ _________________________ ________ hours
4. Reader: _____________________ _________________________ ________ hours
5. Inspector: _____________________ _________________________ ________ hours
Henrique M adeira 6. Inspector: _____________________ _________________________
Analysis of ________ hours
Software Artifacts, DEI-FCTUC, 2022/2023 168

7. Inspector: _____________________ _________________________ ________ hours


168
Inspection Data

❏ Pages or ❏ Lines of Code: Meeting Time: ________ hours


Planned for Inspection: _____ Total Planning Effort: ________ labor hours
Actually Inspected: _____ Total Overview Effort: ________ labor hours
Total Preparation Effort: ________ labor hours
Typical support documents used in inspections: Actual Rework Effort: ________ labor hours

Inspection Lessons Learned Questionnaire


Product Appraisal

ACCEPTED NOT ACCEPTED


___ as is ___ reinspect following rework
___ conditionally upon verification ___ inspection not completed

Verifier: __________________
Inspection Lessons Learned Questionnaire
Projected Rework Completion Date:
1. Did the inspection meet the author’s and team’s objectives? If not, why not?

2.Copyright
Does the© team
2001 feel
by Karl
theyE.were
Wiegers. Permission
able to is granted
significantly to use,
improve modify,of
the quality and
thedistribute this document.
work product
through the inspection?

3. Did everyone have sufficient time to do preparation? If not, how much time do they need prior
to the inspection meeting?

4. Did anyone use the checklist or rules for this type of work product during preparation? Was it
helpful in finding defects? Can the checklist or rules be improved?

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 169

169 5. Were the right participants present? If not, who was missing or didn’t need to be there?

6. Were the inspection entry and exit criteria followed correctly?


Henrique Madeira, 2022/2023 26

7. How could the meeting be run better?


Analysis of Software Artifacts
Departamento de Engenharia Informática, FCTUC

Typical support documents used in inspections:


Typos List log

Typo List
Record any typographical errors that you find during your inspection preparation on this list,
including spelling, grammatical, formatting, and style errors. These should be corrected but need not
be discussed at the inspection meeting. They will not be counted as defects.

Inspector:
Scheduled Inspection Meeting Date:
Work Product Description:

Page Line Number


Number or Section Description of Typo

Henrique M adeira Analysis of Software Artifacts, DEI-FCTUC, 2022/2023 170

170

Copyright © 2001 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

Henrique Madeira, 2022/2023 27

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy