Formal Software Reviews COP 4331 and EEL 4884

Formal Software Reviews COP 4331 and EEL 4884 Processes for OO Software Development Dr. David A. Workman School of Computer Science and Electrical Engineering November 4, 2008 Nov. 4, 2008 (c) Dr. David A. Workman

References 2. Classical and Object-Oriented Software Engineering, 4 th Ed. by Stephen Schach, Mc. Graw-Hill, 1998 3. Software Engineering, 4 th Ed. , 2. by Roger Pressman, Mc. Graw-Hill, 1997 4. IEEE Standard for Software Reviews (1028 -1997) Nov. 4, 2008 (c) Dr. David A. Workman 2

Formal Reviews 1 • Principles – Everyone has blind spots that allow faults to creep into a document – Review task must be assigned to someone other than the author – Review by a team of experts with a broad range of knowledge and skills increases the chances of finding a fault. • Walkthroughs – – – – – 1 Text: 4 to 6 individuals in the review team should include at least one member of the producer team should include the lead from the producer team should include a client representative team should include a representative of the team responsible for the next phase of development team should include an SQA representative team members should be as experienced as possible review materials should be distributed well in advance of the review meeting each reviewer should prepare two lists: a list of items the reviewer does not understand, and a list of items the reviewer believes is incorrect. Section 5. 2 Nov. 4, 2008 (c) Dr. David A. Workman 3

Formal Reviews 1 • Walkthroughs (continued) – Review meeting should be chaired by the SQA representative - quality of the product is a direct reflection on the competence of the SQA organization – Purpose of the walkthrough is to detect and record faults, not fix them • • correction by committee may be inferior to correction by individual correction by committee takes at least as long and costs much more not all items flagged as fault are actually incorrect two hours does not provide enough time to find and correct faults. – Method 1 for conducting a walkthrough: • reviewer presents lists of items • producer addresses each item • recorder logs items that are identified as incorrect by producer – Method 2 for conducting a walkthrough: • Producer walks reviewers through the document • reviewers interrupt when one of their itemized issues comes up • recorder documents items in fault – Method 2 is usually most effective because verbalization by producer frequently results in the discovery of faults he/she missed by non-verbal inspection passes – Walkthroughs are supposed to be interactive discussions not dominated by presenter. 1 Text: Section 5. 2 Nov. 4, 2008 (c) Dr. David A. Workman 4

Formal Reviews 1 1. Inspections 1. proposed by M. E. Fagan [1976] 2. Inspection Method: 1. (overview)An overview of the document to be inspected is generated by Producer 2. (preparation) Reviewers try to understand document in detail; they list the faults by type and frequency 3. (inspection) producer walks through the document with review team; leader of review team prepares a document of faults agreed to by producer and reviewer 4. (rework) producer corrects faults 5. (follow-up) lead reviewer ensures all issues are satisfactorily resolved If more than 5% of the material reviewed has to be reworked, a second formal inspection is scheduled and conducted. 3. 4. 5. 6. Team of 4 inspectors The checklist of faults is essential Fault statistics and severity are important Fagan's experiments: 1. 67% of all faults were detected by inspections; 38% fewer faults were detected in the first 7 months of operation 2. 82% of all faults detected were found during design and implementation inspections 1 Text: Section 5. 2 Nov. 4, 2008 (c) Dr. David A. Workman 5

Formal Reviews 1 • Size 1 Software Engineering, Fourth Ed. , by Roger Pressman, Mc. Graw-Hill, 1997 3 -5 people • Length at most two hours • Preparation approximately two hours per participant • Scope Narrowly focussed and concentrated on a small set of work products or a key parts of a single product to ensure that review objectives can be accomplished within time constraints. • Process – Producer of work product informs team lead that a product is ready for review – Team lead contacts review leader and submit work product for examination – Review leader examines work product to determine its readiness for review, generates review copies, distributes copies to 2 -3 reviewers, and schedules review meeting. – Reviewers examine work product and prepare notes for review meeting. Nov. 4, 2008 (c) Dr. David A. Workman 6

Review Meetings • Participants Review leader, all reviewers, and the producer. One reviewer is assigned as the scribe. The scribe is charged with documenting all important issues raised during the review. • Review Process – – – Producer presents an agenda and brief overview of work product Producer “walks through” work product explaining key decisions and features Reviewers raise issues based on advanced preparation Scribe documents valid problems and errors At the end of the meeting, all participants must agree to: (1) accept product without modification (2) reject due to severe errors or problems (once addressed, product must be resubmitted for review) (3) accept conditionally on correction of minor errors (no additional review req’d) – All participants “sign-off” on a review form that documents the work product, the participants, and the outcome of the meeting. This form should be placed under configuration control along with “surviving” issues documented by the recorder and attached to the review form. Nov. 4, 2008 (c) Dr. David A. Workman 7

Review Guidelines • • • Review Product, not Producer Set an agenda and follow it Limit debate and rebuttle Enunciate problem areas, but don’t attempt to solve every problem noted Take written notes Limit number of participants and insist upon advanced preparation Develop checklist for each work product likely to be reviewed Allocate resources and schedule time formal reviews as part of project planning Conduct meaningful training of all reviewers Review earlier reviews This is beneficial in uncovering flaws in the review process Nov. 4, 2008 (c) Dr. David A. Workman 8

Review Structure Reviewer Team Producer Team Chair Scribe Team Lead Presenters Reviewers Client Nov. 4, 2008 (c) Dr. David A. Workman 9