ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki [email protected] Quality Management...

ReviewsReviews

Copyright, 2002 © Jerzy R. Nawrocki

[email protected]

www.cs.put.poznan.pl/jnawrocki/mse/quality/

Quality ManagementQuality Management

Auxiliary MaterialAuxiliary Material

Quality ManagementQuality Management

Auxiliary MaterialAuxiliary Material

J. Nawrocki, Reviews

IntroductionIntroductionIntroductionIntroduction

The relative time to identify defects (IBM ):

• during design reviews: 1• during code inspections: 20• during machine test: 82

Some fix time dataSome fix time dataSome fix time dataSome fix time data

Cost of fixing a defect


Statementof work

IntroductionIntroductionIntroductionIntroduction

• Statement of work

• External commitments

• Project at selected milestones

• The software baseline (audit)

Reviews at CMM Level 2


Generic FTR procedureGeneric FTR procedureGeneric FTR procedureGeneric FTR procedure

Parameters to be specified in SDP

• Name of the product• URL of the standard doc-struct• Due date for approved product• Producer• Review leader (SQA group)• Recorder (SQA group)• Reviewers (including recorder)• Expected preparation time• Expected meeting duration

SD P



Steps (I)

• Producer informs the project leaders + review leader + area manager (Bartek) that the product is ready and sends them a copy of it.

• The review leader contacts all the participants of the review meeting to establish the date of the meeting (preferably in 3 days). He also distributes copies of the product to the reviewers.



Steps (II)

• The review leader is responsible for establishing an agenda for the review meeting.

• The meeting takes place• The recorder prepares a review

report and sends it to the participants of the meeting. A copy of it must also go to the project managers, the area manager and the SDS supervisor.


FTR meetingFTR meetingFTR meetingFTR meeting

A proposed agenda (I)

• Review leader: Introduction of the agenda. Participants can propose some changes.

• Recorder: Collecting the preparation forms (copies)

• Producer: Presentation of the material. The producer “walks through” the material and explains, while reviewers raise issues. The recorder takes notes of valid defects and problems.



A proposed agenda (II)

• Recorder: Summary of defects and problems.

• All attendees except producer: Anonymous (in written) presentation of early decision.

• Recorder: Collecting of early decisions and their presentation.

• Producer: “Last word”• All attendees except producer:

Making final decision



The decision

• Accept. No modifications are necessary

• Accept provisionally. There are some minor defects that must be corrected but no additional review is required (the project manager is responsible for checking the follow-up).

• Reject. There are severe defects and another review is necessary.



The decision

• If the decision made by the reviewers is not clear (e.g. some are for Accept, some for Reject), the final decision belongs to the area manager.


Preparation form for FTRPreparation form for FTRPreparation form for FTRPreparation form for FTR

Heading

Name of the product & its version: ...Producer: .............................................Reviewer: .............................................The product received on: ...................Expected preparation time: ...............Actual preparation time: ....................Meeting scheduled on: ......................Early decision: ....................................



Body

Severe defects & problems (e.g. hidden problems, ambiguity, lack of understanding, etc.)

Problem description (annotation)

Problem description (annotation)

Minor problems (e.g. spelling, grammar, format etc.)

Problem description (annotation)Problem description (annotation)



• Education: don’t understand• Communication: not

properly informed• Oversight: omitted doing

something• Transcription: knew & did

but made a mistake• Process: due to the process

““Two” or “too”?Two” or “too”?

Annotations - Basic defect causes


Fagan inspectionsFagan inspectionsFagan inspectionsFagan inspectionsD

esig

nD

esig

nC

ode

Cod

eT

est

Tes

t

External specifications (function)

Internal specifications (module) - I0

Logic specifications (logic) - I1 design inspec

Coding (logic) - I2 code inspec

Unit testing

The lifecycleThe lifecycleThe lifecycleThe lifecycle

Function, component, system test


Fagan inspectionsFagan inspectionsFagan inspectionsFagan inspections

Other inspections:

IT1 - test plan inspection

IT2 - test case inspection

PI0, PI1, PI3 - publication inspections



DesignDesignDesignDesign CodeCodeCodeCodeUnitUnit

testtestUnitUnit

testtestI1 I2 I3

Net savings (hours/KLOC):

I1: 94

I2 : 51

I3 : -20


Design

er

Design

er


Implem

entor

Implem

entor

Mod

erat

or

Mod

erat

or Tester

Tester

Reviewsession



1. Overview (whole team)

2. Preparation (individual)

3. Inspection (whole team)

4. Rework

5. Follow-up

Design

er

Design

er Implem

.

Implem

.

Mod

erat

or

Mod

erat

or Tester

Tester

Reviewsession



Overview (whole team) 500 not necessaryOverview (whole team) 500 not necessary

Preparation (individual) 100 125Preparation (individual) 100 125

Inspection (whole team) 130 150Inspection (whole team) 130 150

Rework 50 60Rework 50 60

Follow-up - -Follow-up - -

II11 II22

Rate of progress (loc/h)Rate of progress (loc/h)

• Inspection session <= 2 hours• 1 - 2 sessions per day



CD: CB definition

CU: CB usage

IC: Interconnect calls

LO: Logic

MD: More detail

MN: Maintainability

OT: Other

PE: Performance

PR: Prolog ...

Design error typesDesign error types

Question:

What should be

the design error types

for UML?



CC: Code comments

CU: CB usage

DE: Design error


LO: Logic

MN: Maintainability

OT: Other

PE: Performance

PR: Prolog ...

Code error typesCode error types

Question:

What should be

the design error types

for Java or HTML?



Are all constants defined?

If a queue is being manipulated , can the execution be interrupted; If so, is queue protected by a locking structure?

Are registers being restored on exits?

Are all increment counts properly initialised (0 or 1)?

Are absolutes shown where there should be symbolics?

Are all blocks shown in design necessary?

Checklist for design inspectionChecklist for design inspection

Ex

Ex

Wr

Wr

Mis

sing

Mis

sing



Is correct condition tested?

Is correct variable used or test?

Is each branch target correct?

Is the most frequently exercised test leg the THEN clause?

Are all required parameters passed set correctly?

Does the inline expansion contain all required code?

Checklist for code inspection Checklist for code inspection T

est b

ranc

hT

est b

ranc

hIn

terc

onne

ctIn

terc

onne

ct



PR/M/Min L3: the prologue in the REMARKS

section needs expansion.

LO/W/Maj L172: NAME-CHECK is performed one

time too few.

DE/W/Min L175: the design should allow for the

occurrence of a period in a last

name.

Error listError list



CC: Code comments

CU: CB usage

DE: Design error


LO: Logic

MN: Maintainability

OT: Other

PE: Performance

PR: Prolog

Major MinorMajor Minor

M W E M W E M W E M W E

Date ..............Code inspection report

Mod/Mac: .......................

TotalTotal


Active design reviewsActive design reviewsActive design reviewsActive design reviews

• Parnas and Weiss, 1985

• Questions posed by the author of the design - to encourage a thorough review

• Several brief reviews focusing on a part of a work product (part of a design document)


Phased inspectionsPhased inspectionsPhased inspectionsPhased inspections

1 Compliance with required internal documentation format. Also spelling and grammar can be checked here.

2. Source code layout.

3. Readability.

4. Good programming practice (gotos, global variables, ..).

5. Correct use of various programming constructs (updating control variables for while, closing files, ...).

6. Functional correctness.


Phased inspectionsPhased inspectionsPhased inspectionsPhased inspections

Defects:• indigenous• seeded


SummarySummarySummarySummary

Review procedures can be stated in a generic form.

The main difference between a Fagan inspection and walk-through is:

• lack of checklists for walk-throughs, and

• lack of presentations for Fagan inspections.


Further readingsFurther readingsFurther readingsFurther readings

• M. Fagan, “Design and Code Inspections ..”, IBM System J., vol. 15, no.3, 1976, 182-211.

• M. Fagan, “Advances in Software Inspections”, IEEE TSE, vol. SE-12, no. 7, 1986.

• J.C. Knight, E.A. Myers, An improved inspection technique, CACM, vol. 36, No.11, Nov. 1993, pp. 51-61.


Quality assessmentQuality assessmentQuality assessmentQuality assessment

1. What is your general impression? (1 - 6)

2. Was it too slow or too fast?

3. What important did you learn during the lecture?

4. What to improve and how?

Date post:	05-Jan-2016
Category:	Documents
Upload:	mae-kennedy
View:	212 times
Download:	0 times

ReviewsReviews Copyright, 2002 © Jerzy R. Nawrocki [email protected] Quality Management...

Documents