Software Reviews Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt) QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR) ABSTRACT � WHAT IS A REVIEW ? � WHY REVIEWS ? � DEFECT CLASSIFICATION � SCHEDULE AND DURATION � REVIEW TYPES � WALKTHROUGHS � INSPECTIONS � THE FINAL REPORT � DEFECT PREVENTION Software Engineering / Fernando Brito e Abreu 2 6/28/2005 1
What is a Review ? � An evaluation of any deliverable done by other team members besides the author � A validation technique (e.g.: detection of discrepancies with the requirements spec) � A verification technique (e.g.: detection of non conformities with adopted standards) 3 6/28/2005 Software Engineering / Fernando Brito e Abreu Why Reviews ? � To counteract against perceptive mismatch � Inability to deal with detailed information chunks and loosely defined complex interactions � George Miller, "The Magical Number 7 ± 2 : Some Limits in our Capacity for Processing Information", Psychological Review , n.63, p.81-97, 1956. Software Engineering / Fernando Brito e Abreu 4 6/28/2005 2
Why Reviews ? � To share responsibility � In most Engineering areas (e.g. Civil or Mechanic) projects are signed both by author and reviewer (thus becoming co-responsible) 5 6/28/2005 Software Engineering / Fernando Brito e Abreu Why Reviews ? � Defects found earlier cost less to remove � Better visibility and control of the development process � Continuous learning � Positive impact in teamwork � Easier maintenance � Less harm when somebody leaves a project � Considerable reduction of testing effort and remaining defects [Freedman90] Software Engineering / Fernando Brito e Abreu 6 6/28/2005 3
Schedule and Duration � Schedule : � Immediately after the conclusion of a given stage of an identified deliverable � Included in Project Plan and done regularly and repetitively � No immunity! � Duration � Depends on deliverable dimension and complexity � Hint: a fixed percentage of the time spent developing it � [Britcher88] proposes they should not exceed 2 hours � Short reviews (e.g.: 1 h), done often, are preferable 7 6/28/2005 Software Engineering / Fernando Brito e Abreu What to Review? � All kinds of deliverables are eligible � If possible we should review everything � but often we cannot afford that extra effort � therefore we must select a sample � Sampling has a statistic connotation � How to sample the material to review? Software Engineering / Fernando Brito e Abreu 8 6/28/2005 4
What to Review? � Shall we select: � a random sample (like in other areas of industry? � a representative sample � of best practices? � of average practices? � of worst practices? � The aim is to maximize review efficiency! � Complexity metrics can (should) be used ... 9 6/28/2005 Software Engineering / Fernando Brito e Abreu Reviews Types REVIEWS Informal Formal Internal Walkthroughs Inspections External Demonstrations Audits Software Engineering / Fernando Brito e Abreu 10 6/28/2005 5
Walkthroughs � Revisions in which one participant makes a description of the analyzed deliverable � Usually the presenter is the author (not compulsive) � All participants try to identify defects and non conformities � No distinct role is assigned to participants (except presenter) � Detail and speed depend on presenter preparation � This type of review should not be long, therefore also not the sample being reviewed 11 6/28/2005 Software Engineering / Fernando Brito e Abreu Walkthroughs � Bad aspects � Lack of formality often leads to uncontrolled situations � Less effectiveness and efficiency compared to Inspections � Defects found are often neither classified nor recorded � Good aspects � Small cost (no preparation time is required ...) � Not much intrusive � Applicable in small organizations � Can bootstrap Inspections! Software Engineering / Fernando Brito e Abreu 12 6/28/2005 6
Inspections (Peer Reviews) � Initially proposed by M. E. Fagan at IBM [Fagan76] and matured during a decade of usage [Fagan86] � Effective technique for defects detection � Formal review technique with well-defined input and output requirements 13 6/28/2005 Software Engineering / Fernando Brito e Abreu Inspections � A group of participants is nominated � Deliverable to review, as well as related others, must be made available beforehand (e.g.: 3 or 4 days) � Participants must be familiar with inspections procedures � specific training is required to be able to participate � Each participant has a well defined role : moderator, reader, producer and recorder Software Engineering / Fernando Brito e Abreu 14 6/28/2005 7
Inspections - Moderator � Directs the meeting, registering attendance and individual preparation times � Avoids deviations during the inspection (e.g.: tendency to propose solutions) � Avoids or solves conflicts � Must adopt a non authoritarian role � Registers the total meeting duration � Submits results to the defect tracking system � Deliberates about the meeting follow-up 15 6/28/2005 Software Engineering / Fernando Brito e Abreu Inspections - Reader � Divides (before the meeting) the reviewed deliverable in small sections for presentation purposes � Describes each section, with adequate granularity, during the meeting � Guarantees the inspection pace, adopting a rhythm, neither too fast, nor too slow � Example:200 documented LOCs per hour Software Engineering / Fernando Brito e Abreu 16 6/28/2005 8
Inspections - Producer (author) � Assures that the deliverable to be reviewed, as well as others inter-related ones, are available for all participants in advance � During the meeting will contribute with his/her particular knowledge of the deliverable being reviewed to solve emerging doubts � After the meeting must guarantee that defects found are removed (other person can be assigned) 17 6/28/2005 Software Engineering / Fernando Brito e Abreu Inspections - Recorder � Responsible for the synthesis of opinions expressed by all participants � Registers the following: � physical location of defects found ( note : that is why all material should be printed with line numbers ) � description of defects � category of each defect (from checklist) � defects root cause (if identified) Software Engineering / Fernando Brito e Abreu 18 6/28/2005 9
Inspections - All participants � Try to identify defects, conformance to internally adopted standards and synchronic traceability before the meeting � Only report a given defect when the reader goes through the corresponding section of the deliverable being reviewed � Help to classify and identify the root cause of defects found � Sign the participation document 19 6/28/2005 Software Engineering / Fernando Brito e Abreu Inspection role accumulation Reader Recorder Author Moderator Yes Yes No Reader No No Recorder No Software Engineering / Fernando Brito e Abreu 20 6/28/2005 10
The Final Report � In all types of review a final report must be produced. It should include: � detected defects � defects classification � meeting date � meeting duration � participants � total preparation time � estimated time/effort for detected defects removal 21 6/28/2005 Software Engineering / Fernando Brito e Abreu The Final Report (continued) � Plays a very important role for all participants in the development process: � project manager � client � programmer � quality assurance team � Data collection and report generation should be computer supported! Software Engineering / Fernando Brito e Abreu 22 6/28/2005 11
Inspections - Gold Rules � Inspections are for peers. Upper management representatives should not be present! � Solution for defects removal should not be sought! � The product, not the producer, is being reviewed! � Checklists should be used for defect mining (e.g. JavaCheck) � Inspection team becomes, as a whole, co- responsible for the quality of the deliverable � Remaining defects must be assumed by the team 23 6/28/2005 Software Engineering / Fernando Brito e Abreu Inspection Costs FIXED FOR EACH MEETING � Organizing effort � Planning (schedule/staff) � selecting “sample” � Setting sampling criteria � contacting participants � Setting defect and fault � Meeting room classification scheme � Preparation effort � Form development � Meeting effort � Reporting defects � Building / selecting tool found � Training � Correction effort (?…) Software Engineering / Fernando Brito e Abreu 24 6/28/2005 12
Inspection Benefits (revisited) � Better teamwork / motivation � Exchange of experience / knowledge between the participants (acts as actual training) � Identification of specific training needs � Break in the monotony (by exchanging roles) � Incentive to increase performance (have less errors than the average) � Promotion of a Quality Culture 25 6/28/2005 Software Engineering / Fernando Brito e Abreu Inspection Benefits (revisited) � Standards enforcement � Reduction in defect rate and in V&V costs � Increased understanding / visibility of ongoing projects � Reduction of personal turnover � Database of inspection results - allows to base defect prevention actions (causal analyses) � Several of these benefits are not tangible! Software Engineering / Fernando Brito e Abreu 26 6/28/2005 13
Recommend
More recommend
