reviews checklists
DESCRIPTION
TRANSCRIPT
SoftwareSoftware Quality Assurance Quality AssuranceReviews & Checklists Reviews & Checklists
Seminar: Oana FEIDIQuality Manager – Continental Automotive
PrerequisitesPrerequisitesrework cost in average is responsible for
~40% of the total software development cost
engineers spend up to 1/3 of their compiling & testing, relying on these activities to detect defects
reviews – an inexpensive& effective approach for reducing rework◦ NASA – by introducing software reviews activities in
its projects 29% of total improvement in its process 10% in the reliability on its products
Software Quality activitiesSoftware Quality activitiessoftware reviews
◦ objective: finding analysis and design defects in SW artifacts produced in the initial phases of SW development
testing patterns & formal procedureschange controlSW metrics
◦ used to trace SW QA and to evaluate the impact of various methodologies and procedures
Documented & stored records
ReviewReviewA software review is
"A process or meeting during which a software product is [examined by] project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval” [IEEE 1028:1997 – “IEEE Standard for software reviews”]
The earlier errors are found, the lower the costs of correcting the errors and the higher the probability of correcting the errors
correctly
Categories Walkthrough Code Inspection
Source: http://cronos.cos.ufrj.br/publicacoes/reltec/es55601.pdf
Reviews targetsReviews targetsto have a more comprehensible project,
that facilitates comprehension by other developers, by describing in a condensed way what is described in the code
saving implementation time, by removing problems with faulty logic and missing functionality before implementation
improving the efficiency of the reviews, since fewer artifacts need to be reviewed together and defects are removed incrementally, rather than at one time
WalkthroughsWalkthroughs “ a designer or programmer leads members of the
development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems" [IEEE 1028:1997 – “IEEE Standard for software reviews”]
Objectives to gain feedback about the technical quality or content of the
document to familiarize the audience with the content
IEEE 1028 recommends three specialist roles in a walkthrough:
author, who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items;
walkthrough leader, who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author); and
The recorder, who notes all potential defects, decisions, and action items identified during the walkthrough meeting.
The teamThe team An inspection team usually consists of four people
Moderator Programmer Test specialist Program’s designer
Moderator Distributes materials and schedules the inspection
session Leads the session
ensures that the discussions proceed along productive lines
ensures that the participants focus their attention on finding errors, not correcting them
Records all errors found Ensures that the errors are subsequently corrected
Review flowReview flowPlanning: - verify materials meet entry criteria - schedule meeting - distribute documents
Meeting: - materials presented by authors / materials reviewed as a group - defects recorded - metrics collected (if necessary)
Rework: - author fixes defects alone
DONE
Additional defects found - inspection repeats
Review template structureReview template structureLocation of error
chapter, function, …
Severity major, minor
Type error or remark algorithm,
documentation, data usage
Time spent per review
Review template
Metrics:• effort per review• findings per review• number of lines reviewed
"Walking on water and developing software from a specification are easy if both are frozen.” Edward V Berard
Specification reviewSpecification reviewWhat to look for:
◦ Inconsistencies◦ Missing “else” branch of a specification◦ Misinterpretation – unclear requirements◦ Requirements that are excluding one
another
Exercise 1 (working groups): document the review of the following specification ◦ Use the checklist from the following link as
support: http://www.processimpact.com/reviews_book/requirements_review_checklist.doc
Specification to review
Requirements review checklist
Static code analysisStatic code analysisperformed without actually executing
programs built from that softwareCode compliance to certain guidelines
◦ M.I.S.R.A. compliance- Motor Industry Software Reliability Association
◦ Example of MISRA rules
Exercise 2 (homework): check the compliance of a .c file using the Q-AC Free Trail license from the following link: http://www.programmingresearch.com/qac_main.html◦ Bring the metrics & reports in the next
seminar
Code InspectionsCode Inspections A set of procedures and error-detection techniques Concentrates on discovering errors, not correcting
them
Objective: to find errors in the program, thus improving the quality of work
Benefits The programmer receives feedback concerning
programming style, choice of algorithms and programming techniques
The other members of the team: share experience
Optimal amount of time: 90-120 min Rate: average 150 program statements/hour Comments should be directed toward the program,
rather than the programmer
Code inspectionCode inspectionCorrectness of the algorithm
implementation/specification ◦ Exercise 3 (working groups): identify if the
following .c code implements correctly the Bubble sort algorithm
◦ Use the following checklist as support
bubble_sort.txt
Code_checklist
ChecklistChecklist An important part of the inspection is the use of
checklist to examine the program for common errors
As general as possible Based on lessons learned
THANK YOU!