inspection process d'inspect… · web viewversion 1.2. this document has been produced for...

1

Inspection Process – Instruction

Version 1.2

This document has been produced for training purposes using the following textbook as a reference: Gilb, Tom, Graham, Dorothy: ‘Software Inspection’, Addison-Wesley. Refer to the textbook for detailed information about the inspection process.

5/17/2023

2

Table of Contents

RECORD OF CHANGES............................................................................................................................................ 4

DOCUMENT STATUS AND QUALITY.................................................................................................................... 4

1. INTRODUCTION................................................................................................................................................... 5

2. INSPECTION PROCESS OVERVIEW................................................................................................................. 6

3. DETAILED DESCRIPTION OF THE INSPECTION PROCESS........................................................................7

IP-100 PLAN DOCUMENT INSPECTION.................................................................................................................... 7IP-110 CONDUCT KICK-OFF MEETING.................................................................................................................... 9IP-120 CONDUCT DOCUMENT CHECKING.............................................................................................................11IP-130 CONDUCT LOGGING MEETING.................................................................................................................. 13IP-140 EDIT DOCUMENT...................................................................................................................................... 16IP-150 COMPLETE FOLLOW-UP, EXIT AND RELEASE ACTIVITIES...........................................................................18

4. BRAINSTORMING MEETING........................................................................................................................... 20

ACTIVITIES FOR INSPECTION LEADER DURING BRAINSTORMING..................................................................................20ACTIVITIES FOR CHECKERS DURING BRAINSTORMING.................................................................................................20

5. GLOSSARY........................................................................................................................................................... 21

6. CHECKLISTS....................................................................................................................................................... 22

CHECKING ROLES (RO)............................................................................................................................................. 22GENERIC DOCUMENT (GD)........................................................................................................................................ 23REQUIREMENT SPECIFICATION (RS)........................................................................................................................... 23USE CASE (UC)......................................................................................................................................................... 24SOURCE CODE (SC)................................................................................................................................................... 24C++ CODE (CC)........................................................................................................................................................ 25SAFETY CRITICAL CODE (SA).................................................................................................................................... 26PROJECT PLAN (PP)................................................................................................................................................... 27TEST PLAN (TP)........................................................................................................................................................ 27RULES FOR CHECKLISTS (CK).................................................................................................................................... 28

7. TAILORING GUIDELINES................................................................................................................................. 29

TAILORING OF INSPECTION PROCESS.......................................................................................................................... 29TAILORING OF CHECKLISTS........................................................................................................................................ 30TAILORING OF FORMS................................................................................................................................................ 30

Issue Log Form..................................................................................................................................................... 30

8. DEPLOYMENT GUIDELINES............................................................................................................................ 30

9. FORMS.................................................................................................................................................................. 32

INSPECTION REQUEST FORM...................................................................................................................................... 32INSPECTION MASTER PLAN FORM.............................................................................................................................. 32PROCESS BRAINSTORMING MEETING FORM................................................................................................................ 32INSPECTION DATA SUMMARY FORM........................................................................................................................... 32INSPECTION ISSUE LOG FORM.................................................................................................................................... 32INSPECTION CHANGE REQUEST FORM........................................................................................................................ 32Inspection Exit Form................................................................................................................................................ 32

5/17/2023

3

FiguresFigure 1 Document Generation Process.......................................................................................................................... 4Figure 2 Inspection Process............................................................................................................................................ 4

5/17/2023

4

RECORD OF CHANGES

*A - ADDED M - MODIFIED D – DELETED - N/A – NOT APPLICABLE

VERSIONNUMBER DATE

yyyy/mm/dd

NUMBER OF FIGURE, TABLE OR SECTION

A*MD

TITLE OR BRIEF DESCRIPTIONCHANGEREQUESTNUMBER

1.2 2003/09/05 7 A Tailoring of forms N/A1.2 2003/09/05 N/A A Document status and Quality Table N/A

DOCUMENT STATUS AND QUALITY

*NI – NOT INSPECTED I – INSPECTED E – ESTIMATED C - COMPUTED

VERSION NUMBER

DATEyyyy/mm/dd

STATUS*NI

I

NUMBER OF DEFECTS REMAINING

(Number /Page of 300 words or Number / 300 LOC)

* EC

1.1 2003/07/10 NI 1 defect par page E1.2 2003/09/05 NI 1 defect per page E

5/17/2023

5

1. IntroductionThis document contains a description of an Inspection Process (IP). In this process, a document is any information recorded on paper or electronic media. The process contains enough information to be used for training purposes.

As shown in Figure 1, to produce any document, other information are usually used. First, source documents, i.e., any document which contains information, which is necessary prerequisite for the correct production of the product document. Second, rules sometimes called standards specify the content and format of the product document. Rules specify how source documents are translated into a product.

Figure 1 Document Generation Process

As shown in Figure 2, once the author has sent a request for inspection to the inspection leader/coordinator, the product document is verified against the source document(s) and the rules used to create the product. As an example, a design document could have been created using a specification document, as a source document, and the rules of standards for content and format. In order to improve the defect removal effectiveness and efficiency, checklists are used.

Figure 2 Inspection Process

5/17/2023

DOCUMENT

PRODUCTION

ACTIVITIES

INSPECTION

PROCESS

SOURCEDOCUMENT(S)

SOURCEDOCUMENT(S)

RULES STANDARDS

PRODUCTDOCUMENT

CHECKLIST(S)and RULE(S)

PRODUCTDOCUMENT

LOG OF DEFECTSFOUND INPRODUCT

DOCUMENT

MEASURES

CHANGEREQUEST

INSPECTIONREQUEST

INSPECTED and EDITEDDOCUMENT

6

2. Inspection Process OverviewPlan Document Inspection. After receiving a Request for inspection from the author and meeting the entry criteria, the Inspection leader/coordinator selects a set of source documentation, checklists, checking rates, people, roles, and logging meeting rates to ensure maximum productivity.

Conduct Kick-off Meeting. The Inspection leader can elect to run a “kick-off” meeting prior to checking. Team improvement goals and corresponding strategies are adopted. Any necessary instruction is given.

Conduct Document Checking. The objective of individual checking is to identify a maximum of unique major issues which no other checker will bring to the logging meeting. To do this each checker should have at least one special role. The checking phase has a recommended time or rate, but checkers have instructions to deviate from that whenever individual ability, role or situation dictates, in order to increase productivity.

Conduct Logging Meeting. The team concentrates on logging items at a rate of at least one per minute. Items logged include potential defects (issues), improvement suggestions, and questions of intent to the author. The leader permits little other verbal meeting activity. Meetings last a maximum of two hours at the known optimum rate. If necessary, work must be chunked to avoid tiredness. Optimum checking rate for the meeting is determined by the percentage of new issues identified in the logging meeting as well as quality of documents.

Conduct Process brainstorming (Optional). Immediately after each logging meeting, time is used to brainstorm the process causes of major defects, and to brainstorm improvements to remove these causes. These suggestions are stored in a database. This meeting shall last no more than half an hour. The objective is to maximize production of useful ideas and personal commitment to change within that time.

Edit Document. Issue analysis and correction action is undertaken by an editor. Some written action must be taken on all logged issues - if necessary by sending change requests to other authors. The editor makes the final classification of issues (logged at the logging meeting) into defects, and reports final defects measures to the leader. Edit also deals with improvements and can deal with questions to author.

Complete Follow-up, Exit and Release Activities.

Follow-up. The Inspection leader shall determine that some appropriate written action has been taken on all logged issues. The leader is not responsible for the correctness, the editor is.

Exit. The Inspection leader determines whether the formal exit criteria have been met before signing off completion of the Inspection. These include: Follow-up completed, measures delivered, planned rates kept to, and level of remaining defects within acceptable bounds.

Release. The product document is made available, as officially ‘Inspected’ with an estimate of the number of remaining major defects in a “warning label”.

5/17/2023

7

3. Detailed Description of the Inspection Process

IP-100 Plan Document InspectionStep description The Inspection process begins with a ‘Request for Inspection’ Form completed by the author(s) of a document. This is given to the Inspection Coordinator of the organization who finds an Inspection Leader. The Inspection Leader will coordinate the inspection of the document submitted.

As part of the Inspection planning, the Inspection Leader checks the product and its source documents against relevant (generic and specific) entry criteria. The purpose of entry criteria is to reduce the probability that the Inspection team will waste scarce resources; only to discover that product approval (“exit”) is impossible or not economic, due to some factors, which should have been corrected before the Inspection began.

The Inspection Leader determines how many inspection cycles will be necessary (if the document is too big for one inspection cycle), who should participate, and other practical details. The main output of this step is an Inspection Master Plan (IMP) for all the people on the Inspection team, including author(s).

ENTRY CRITERIA

Request for Inspection Form completed by the author of the document to be inspected.

Inspection Leader assigned (Inspection Leader is not author of document to be inspected)

Inspection Team Leader is properly trained (about 3 to 5 days of theory and practice)

Product document has exited from a spell check

Source documents have exited from inspection

INPUTS

Source documents (i.e. documents that had to be used to generate the product document)

Product document, lines are numbered (i.e. document to be inspected)

Rules and Checklists

Blank Inspection Master Plan (IMP) Form

System/Hardware specification

ACTIVITIES

Activities for Inspection Leader

1. After a cursory examination (5 minutes) of the product document, determine if entry conditions are fulfilled (e.g. less than 1 major defect per page, document is line numbered, exited from spell check):

a. If not, return to author for clean-upb. Or discuss what to do about source documents, rulesc. Work to remove failed entry condition

2. Determine which documents are to be used:a. Source Documents (e.g. standards, hardware specifications)b. Checklistsc. Candidate document chunks

3. Determine specialist roles to be played (e.g. tester, user). See attachment4. Determine checking rates for individual checkers (pages/hour)5. Determine logging meeting optimum rates (pages/hour and issues logged/minute)

5/17/2023

8

6. Prepare Inspection Folder. a. An electronic/paper folder is used to capture all documents produced during the inspection.

7. Identify participants (e.g. checkers)8. Send call for meeting, e.g. e-mail, memo: (date, time, duration, location)9. Make copies of source and product documents (paper or electronic)10. Fill-in IMP form 11. Fill-in Effort Log Form (if used by the organization conducting the inspection)12. Update Inspection Data Summary Form (Planning Section only)13. Put documents in Inspection folder

EXIT CRITERIA

Participants identified

Call for meeting sent

OUTPUTS

INSPECTION FOLDER

Inspection Request Form

Product Document

Source Document(s)

Inspection Master Plan (IMP)

E-mail or Memo to call kick-off meeting

Filled Effort Log Form (if used by the organization)

MEASURES

Effort to plan Inspection (Staff-hours)

5/17/2023

9

IP-110 Conduct Kick-off MeetingStep description: A kick-off meeting is held to ensure that the checkers know what is expected of them in the inspection process. The kick-off meeting may include the distribution of documents, role assignments, feedback on process changes, training in Inspection procedures, and the setting of targets and corresponding strategies for Inspection productivity goals.

ENTRY CRITERIA

Inspection Master Plan (IMP) completed

INPUTS

Inspection Folder

ACTIVITIES

A. Activities for Inspection Leader

1. Update novices on procedures, rules, checklists2. Distribute IMP, source, and product documents3. Ask if any questions as to the Inspection Master Plan (IMP)4. Review procedures, rules, checklists5. Update checklist (if applicable)6. Explain to all participants (checkers) the confidentiality of the process7. Assign roles to checkers, if applicable 8. Modify/Set checking rate : i.e. number of pages per hour9. Set date for logging meeting10. Reserve a room for the logging meeting11. Update IMP12. Update Inspection Data Summary Form (Kick-off meeting section)13. Fill-in Effort Log (if used by the organization)14. Put document in Inspection Folder

B. Activities for Checkers

1. Make sure you have all pages of all documents you are supposed to have2. Ask for clarification if you do not understand the inspection master plan or your role 3. Agree to your assigned role or modify them4. Ask for detailed briefings on rules, checklists, source documents so that you can do your checking

better.5. Ask any questions you like about the Inspection process6. Make any suggestions you like for the team or your role in it7. Make a commitment to spending the necessary checking time before the logging meeting

EXIT CRITERIA

All participants (checkers) committed to the inspection plan

5/17/2023

10

OUTPUTS

Inspection Folder

IMP Updated

Effort Log Updated (if used by the organization)

Updated Data Summary Form

MEASURES

Effort (Staff-hours)

5/17/2023

11

IP-120 Conduct Document CheckingStep description: The checkers work alone on the product document using the source documents, the rules, the procedures and the checklists provided. The aim of each checker is to find the maximum number of potential defects, mainly by looking for discrepancies between a source document and the document generated from it, i.e. product document. The issues are identified as objectively as possible according to the rules, the checklists, and the understanding of the participants. The issues are recorded for later personal reference, e.g., logging meeting, on the product document.

ENTRY CRITERIA

None

INPUTS

Source Documents

Product Document

Rules and checklists

ACTIVITIES

A. Activities for checkers

1. Try to identify a maximum number of potential issues on behalf of your team, and to help the authora. If you get a ridiculous high number of issues, consult with the Inspection Leader

2. Play your assigned role to the full3. Do not be shy of noting any kind of issue you think you have found4. You do not have to write a perfectly presented log. It is better to concentrate on finding more

issues, but you may write any notes you like, any way you like. They are normally your private notes.a. Circle the offending words and write the checklist tag number.

5. If you have any difficulty, consult with your Inspection Leader6. If you believe the assigned rate is too fast for your purpose, slow down. Consider consulting with

the Inspection Leader about this.7. Focus on major issues, do not spend a lot of time and effort finding and noting minor issues 8. Update lower part of Inspection Master Plan (IMP) Form with your own measures (e.g. effort)

B. Activities for Inspection Leader

1. Check novices after a while to make sure they are finding issues2. Help them to learn to find issues if they have trouble3. Check for issues yourself only if you deem it the best use of your time for the team results,

otherwise concentrate on managing the team.4. Be available to any team member needing help5. Verify that checkers have really had time to check at the optimum rates. If necessary, consider

delaying the planned logging meeting to allow time for all checkers to do their job.

5/17/2023

12

EXIT CRITERIA

None

OUTPUTS

Inspection Master Plan (lower part only) completed by each checker

MEASURES


5/17/2023

13

IP-130 Conduct Logging MeetingStep description: A logging meeting is convened for three purposes:

a. Firstly, to log the issues which have already been identified by each checker in individual checking.

Issues are not recorded as “defects” at this point because they may not be defects. They are simply “matters requiring attention”. At this stage, no discussion is allowed. Anything logged at the meeting is an “item”. An item can be an “issue” (an assertion about a potential defect), which may be evaluated as a real defect when the editor investigates it. An item can also be a “question of intent” to the author, or a process improvement suggestion. Questions of intent are answered at the conclusion of the logging meeting. Answers may immediately lead to the logging of related issues.

b. The second purpose of the meeting is to discover more major issues during the meeting. This is stimulated by the synergy between peers, and by giving enough time to permit more checking to take place during the “logging” meeting.

c. The third purpose is to identify and log ways of improving the development or the Inspection process. This may include improvement suggestions to procedures, rules or checklists. Issues could also be identified in source documents. Such improvement items will be sent to the appropriate process or document owner for consideration.

An optional process brainstorming session could be held at the end of the logging meeting with the aim of getting at the root causes of some of the major issues logged.

The person who chairs the logging meeting is the Inspection Leader.

ENTRY CRITERIA

None

INPUTS

Inspection Folder

Data Summary Form

Issue Log Forms

Checkers data (lower portion of Inspection Master Plan)

ACTIVITIES

A. Activities for Leader

1. Gather individual checking measures from the IMP Forms (e.g. see lower part of IMP form)

a. Record it on Data Summary Form

b. Evaluate if it is worth holding logging meeting

a) If estimated number of remaining defects is equal or lower than exit criteria (e.g. 0.25 defect per page), logging meeting can be cancelled

b) If inspected document is so polluted with defects that it should require a rewrite, logging meeting should be cancelled.

5/17/2023

14

c. If canceling meeting, log any process improvements

2. Remind team of strategy agreed at the Kick-off meeting

3. Decide and announce a recording sequence and content (e.g. “major only”, “sources first”)

4. Assign scribe task or take it on yourself

5. Remind author to validate the written log and seat close to the scribe

6. Begin logging process.

Ways to conduct Logging :

a. Verbatim

b. Paraphrase

c. Mixed styles – Verbatim and Paraphrase

d. Section by section or line by line enumeration : ‘Does anyone have an issue with section X

e. Perspective based : Inspectors stand in for specific stakeholders

f. Line by line : Inspectors state: Checklist tag number, keyword of violation.

7. Make sure that unique majors not in checklist get evaluated for inclusion in an updated checklist.

8. Keep recording pace at one to four issues logged per minute

9. Stop discussions: focus on logging issue not solving the issue

10. Decide how to handle lack of time:

a. Reschedule continuation

b. Re-chunk the remainder

11. Consult with author, Is this sample enough?

12. Conduct brainstorming (optional, see attachment)

13. Collect Issue Log Forms from scribe(s)

14. Update Data Summary Form (Logging and Process Brainstorming Sections)

15. Update Inspection Folder

B. Activities for Checkers

1. Contribute your checking data quickly at the beginning to the Leader so it can be noted.

2. Follow the agreed logging priority and sequence

3. When someone has logged an issue you also had identified, keep silent, and go on to the next one.

4. Speak clearly, so everyone can hear

5. Direct your remarks to the scribe

6. Make sure the scribe is following you

7. Report your issue in seven words or fewer.

a. e.g. checklist tag number, keyword of violation, severity (if applicable)

8. Do not discuss anybody else’s issue reports. We want them logged whatever the misunderstanding

9. Do not justify or explain you report

a. If you absolutely must discuss something, make a note and do it later with the appropriate parties

10. Be supportive and encouraging, especially to novices

5/17/2023

15

a. Do not attack or belittle anybody

C. Activities for Author

1. Report your own noted issues after giving your team-mates a chance

2. Do not say “I found that too”

3. Thank your colleagues for their efforts on your behalf

4. Learn as much as possible about avoiding issues as an author

5. Respect the opinion of team-mates. Do not justify or defend

6. Check the logging for legibility and intelligibility

D. Activities for Scribe

1. Make sure the author/editor is sitting so that your writing is visible

2. Note down, on Issue Log Form, only words necessary for the author to understand the issue.

3. Insist on standard reporting sequence (use a table tent card with the sequence on the table)

4. Do not let checkers go too fast. Ask them to slow down and to wait for your OK signal to report a new issue.

5. If you are not sure, check it with the Leader and the author before continuing

6. If you are exhausted, consider passing the pen to a team-mate

7. Report your own issues last, possibly letting another person log them

8. When there are many of the same generic error, log multiple by getting a guess as to approximate quantity, and noting it in the right-hand margin.

EXIT CRITERIA

None

OUTPUTS

Inspection Folder Issue Log Forms

Data Summary Form updated

MEASURES


5/17/2023

16

IP-140 Edit DocumentStep description: Someone, usually the author, is given the Issue Log (and improvement suggestions) to resolve. This person is known as the editor. The real issue may be judged to be quite different for the perceived issue as logged by checker. If the issue is defect, it is now classified as a defect, usually determined by the current rules, sources and procedures. If an issue is not a defect, an ordinary comment or footnote should be added to avoid future misinterpretations. The editor cannot directly correct a defect in a source document, so a Change Request (CR) to its owner is made. The editor may also make further process improvement suggestions, and may also make other improvements or corrections to the document they “own”. The editor will also update the Issue Log.

ENTRY CRITERIA

None

INPUTS

Inspection Folder Blank Change Request Form

ACTIVITIES

A. Activities for Leader

For a novice editor, the Leader must :

1. Give guidance on issue classification

2. Help to deal with issues logged against source documents (for example, via Change Request)

3. Give guidance on dealing with issues that, in the editor’s opinion, are not really issues

4. Set expectations as to how long the process will take (estimate it and tell editor)

5. Give advice concerning the next step (follow-up)

6. Collect Issue Log Forms completed from Editor

7. Update Data Summary Form (Editing, Follow-up and Exiting Section)

B. Activities for Editor

1. Correct logged issues according to your source documents.

2. If, in your opinion a logged issue is due to, or first requires correction of a source or checklist, then write a CR to the owner of the source document

a. Insert a note in your document about the pending CR you sent

3. You may change a severity (major, minor) classification to one which you believe is more correct than originally logged. Change the final count appropriately on the issue log forms.

4. Indicate on the issue log form how and where you have edited for each issue, so as to make the Leader’s follow-up process obvious and easy

5/17/2023

17

5. You do not need to respond to an issue in the way indicated by the checkers. Fix the real issue in a responsible way. An issue becomes a defect only when you acknowledge it by making a correction.

6. You may make corrections to defects, which you spot yourself during editing work. Include them in your defect count.

7. You may make improvements and optimizations to your document without counting them as defects, but take great care as these changes will not have been inspected.

a. Inform the Inspection Leader about any additional changes you have made.

8. Send Improvements to the process, to the appropriate owner.

9. Complete Issue Log Form

EXIT CRITERIA All issues have been edited

OUTPUTS Inspection Folder

Issue Log Updated (e.g. effort, number of defects)

Updated Data Summary Form

Change Request Form sent to document owner (if applicable)

MEASURES


5/17/2023

18

IP-150 Complete Follow-up, Exit and Release ActivitiesStep description: The Inspection leader checks that satisfactory editor action has been taken on all logged issues. Change Request (CR) to correct defects in any source document must have been sent to the owner of the document.

The issues classified as “defects” in the product document must have been corrected by the editor. The Inspection Leader checks to make sure that the editor has taken action to correct all known defects, although the Leader does not have to check the corrections themselves.

Process improvement suggestions should be sent to the process owner in question.

The exit process is performed by the Inspection Leader, using applicable exit criteria. For example, follow-up must be complete, the checking rates must be within acceptable limits.

If a document has been divided up to be inspected in separate inspection cycles, all chunks must have exited before the document as a whole can exit Inspection.

ENTRY CRITERIA

None

INPUTS

Inspection Folder

Blank Inspection Exit Form

ACTIVITIES

A. Activities for Inspection Leader during Follow-up

1. Check completeness:

i) All logged issues responded to in writing on Issue Log Form

ii) Defects corrected in updated version

iii) Sample fixes look credible and responsible (to you). You do not have to prove each fix is correct.

2. If the editor is new or novice to editing, then you must sample enough to guarantee that proper editing has been done.

3. If CR (or other Memos to other authors and owners) are issued, then check that they are logged in any Configuration Management (CM) system you have, and that the editor has made appropriate notes in the candidate document about the pending CR

4. Collect and analyze the now final (adjusted by editor) measures in the Data Summary form.

Put them in the database.

5. Compute number of probable major defects remaining for the pages you have inspected.

Compute probable major defects in entire document, if you have only inspected a sample or a chunk at that time.

6. Compute net savings (total hours probably saved). This is the time saved due to “defects corrected now”, minus time used for the entire Inspection process needed to eliminate the defects.

5/17/2023

19

7. Complete Inspection Exit Form

8. Update Data Summary Form

B. Activities for Inspection Leader during Exit

1. Check exit criteria.

2. Help others meet exit criteria which have failed, e.g. database not updated

3. If all conditions are met, release the document chunk as ‘Inspected’

4. If the Inspection was only for sampling purposes, then the computed (estimated) defect per page is put on the front page with the exit signature.

C. Activities for Inspection Leader during Release 1. Document the release (as “document INSPECTED”) on the latest version of the document

2. Include data about estimated remaining issues per page.

EXIT CRITERIA

1. All editing has been completed.

2. All necessary Change Requests (CR) cross-references are inserted in the appropriate document(s)

3. Data summary form is completed

4. Database has been updated.

5. Exit Form completed

6. Check that the rate (pages or lines per hour) of individual checking and of the logging meeting did not exceed the known optimum rate by more than 20 % on average. (Otherwise you may have missed to many defects which will then be sent of to others, even after correcting the defects you did find).

7. Either the author/owner or the Inspection Leader can veto the exit based on their subjective belief that release would be a danger to their document customers.

8. There are no more than 0.25 (or 2 to 3 for beginners) major defects per page remaining, calculated based on estimated/measured removal effectiveness (between 30 % and 88%) and estimated or measured defect insertion rate (e.g. 17%).

OUTPUTS

Inspection FolderData Summary Form CompletedData base UpdatedExit Form completed

Inspected and Edited Document

MEASURES


5/17/2023

20

4. Brainstorming MeetingA process brainstorming meeting (optional) is held with the aim of getting at the root causes of some of the major issues logged, and to generate suggestions for improving the software development process. “Brainstorming” is a technique for generating a number of ideas in a limited time, without any discussion of the value of the ideas. The brainstorming meeting is conducted with the same people who were involved in the logging meeting, and will last for at most 30 minutes. Sometimes additional people will attend who were not in the logging meeting, such as process group members

Up to 10 major issues are selected for analysis. The issues with the highest severity (potential damage) should be chosen first (Pareto analysis). For each potential defect selected, the root causes are brainstormed, and improvements which could be made to prevent that type of defect from occurring again are suggested. Improvements include both small simple things, which an individual could begin doing immediately, as well as major investments. The meeting-scribe records causes and improvement suggestions in the Brainstorming Log Form.

Activities for Inspection Leader during Brainstorming1.Remind team of basic rules (reporting, structure, three minutes each, brainstorming mode, purpose).

2.Suggest a strategy for selecting issues to be discussed (e.g., first logged majors).

3.Be the scribe (usually).

4.Keep timing at about three minutes maximum each.

5.Log issue identification, classify (education, and so on using Brainstorming Form). One minute.

6.Log suggestions as to root cause: Keywords, conflicting views OK. One minute.

7.Log suggestions as to improvements in work process.

a. Solicit practical, “we could and would do it ourselves” ideas. One minute.

8. Transmit Brainstorming Log Form to appropriate owner ( e.g. SQA, Process group)

Activities for Checkers during Brainstorming

1. When the Inspection Leader suggests a defect to be analyzed, find it in your documentation.

2. Help to brainstorm the defect cause classification (Communication, Oversight, Transmission, Education, Process).

a. Communication failure: Breakdown of communications between 2 groups

e.g. information not received)

b. Oversight: Something was not considered or handled

e.g. not enough time, forgot about something

c. Transcription error

d. Education: (e.g. did not fully understand the context)

e. Process: The process somehow misdirected an action (optional classification)

3. Brainstorm keywords about the root cause. (Do not use more than one minute as a team for this).

4. Brainstorm keywords about suggested process cure, which would prevent such errors happening in the future. One minute maximum for the team.

5. Do not try to get the whole truth. You do not have time. The SQA/Process group will study this in more depth later.

5/17/2023

21

5. GlossaryAdapted from: Gilb, Tom, Graham, Dorothy: ‘Software Inspection’, Addison-Wesley, 1993.

Change Request a formal record of an issue raised for a document not under the direct control of the editor, and requiring resolution or change by the owner of the document. Responsibility for document update is always with the document owner.

Checklist A specialized set of questions designed to help checkers find more defects, and in particular, more significant defects. Checklists concentrate on major defects. A checklist should be no more than a single page per subject area.

Defect an error made in writing in a document or code which violates a rule. A logged issue becomes an ‘official’ defect when the editor classifies it as such during editing. Items may be classified as defects directly from issues, or from questions of intent or from improvement suggestions.

Informal synonyms: bug, fault, issue, problem.

Edit the process of working through the issue log to give each issue a final classification, to correct any defects in the documents for which the editor is currently responsible, and to raise any change requests (CR) required.

Effectiveness (or actual defect-finding effectiveness) the percentage of major defects discovered at any one specified stage or cumulation of stages of Inspection or test, compared to the total major defects found so far.

Efficiency (Major) defects found per work-hour. A measure of individual or team ability to exploit their time.

Fix-fail-rate the percentage of edit correction attempts which fail to correct the defect.

Default: 17% – one out of six correction attempts (Fagan, 1986).

Items the set of things written down at the logging meeting. This consists of issues, improvement suggestions and questions of intent to the author.

Major a severity classification for issues and defects. It is used when the defect would probably have significantly increased costs to find and fix later in the development process, for example in testing or in use.

Minor an issue or defect which is not major. The cost of fixing this type of defect is not of the same order of magnitude as for major defects.

Question of intent an item logged at the logging meeting, which is not classed as an issue or as an improvement suggestion, but which requires some oral reply or explanation from the author at the end of the logging meeting.

5/17/2023

22

Rule a procedure for writing a product document using the task source document implied or specified in the rules. A rule specifies the content and format of the task product documents. A rule specifies how source data is translated into product by a task.

Traditional term: ‘standard’. A standard is anything which guides an activity, whereas a rule is a specific type of standard procedure related only to documents, and states what must be written.

Scribe the person who records or logs items at a meeting. Issues, improvement suggestions, and questions of intent to the author are logged at the logging meeting.

Source any document which contains information which is a necessary prerequisite for the correct production of the product document using the pertinent rules.

Traditional term: ‘high-level document’.

6. Checklists

Checking Roles (RO)Version 1.0, Dated July 17, 2003.

The checkers could be assigned a particular role, which ensures that they have a unique viewpoint. This role should be assigned with a view to their special interests and expertise.

It is important to note that “roles” encourage and permit individuals to do a particular defect-searching task better than their colleagues. It does not give them exclusive territory over that defect type, and any defect is fair game for all checkers. Nor is the Inspection Leader limited to suggesting only one single role to one person. Multiple and overlapping roles may be assigned.

The Inspection Master Plan (IMP) form and the kick-off meeting should make all checkers aware of the special roles of the other checkers.

The important thing for the final results is that the duplication of potential defect assertions is minimized, and unique issue contributions maximized.

Examples of roles:

RO 1 (BACKWARDS) - Concentrate on the material from the back pages first (if applicable).

RO 2 (CALCULATIONS) - Concentrate on all calculations, measurements, data estimates and predictions.

RO 3 (CROSS-REFERENCES) - Concentrate on all cross-references and implied corrections.

RO 4 (FINANCIAL) - Concentrate on cost and revenue implications, estimates uncertainty, dates, quantities.

RO 5 (GRAPHICAL) - Concentrate on all graphics and symbols.

RO 6 (INTERFACES) - Concentrate on all interfaces (if applicable).

RO 7(QUALITY) - Concentrate on all aspects of quality attributes directly and indirectly (e.g. portability, performance)

RO 8 (STANDARDS) - Pay special attention to the standards used to develop the document.

RO 9 (RISKS) - Inspect document for specific risks (schedule risk)

RO 10 (SERVICE) - Concentrate on field service, maintenance, supply, installation.

RO 11 (SYSTEM) - Concentrate on the wider system implications (hardware, documentation, selling, timing of delivery

RO 12 (MAINTAINER) - Inspect from the point of view of someone who has to maintain the document

5/17/2023

23

RO 13 (TESTER) - Concentrate on test considerations (testability, test requirements, order of testing and order of development for parallel testing, and so on).

RO 14 (USER) - Concentrate on the user or customer point of view.

RO 15 (SAFETY) - Concentrate on all aspects of safety attributes directly and indirectly. Safety is defined in ISO 9126-1:2001 as the capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use.

RO 16 (SECURITY) - Concentrate on all aspects of security attributes directly and indirectly. Security is defined in ISO 12207:1995 as the capability of the software product to protect information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems are not denied access to them.

Generic Document (GD)Version 1.0, Dated July 17, 2003.

This checklist specifies the requirements that must be satisfied by any document that is subject to inspections.

GD 1 (COMPLETE) - All information relevant to the purpose of the document must be included or referenced.

GD 2 (RELEVANT) - All information must be relevant to the purpose of the document and the section in which it resides.

GD 3 (BRIEF) - Information must be stated briefly.

GD 4 (CLEAR) - Information must be clear to all checkers.

GD 5 (CORRECT) - Information must be free of technical errors.

GD 6 (CONSISTENT) - Information must be consistent with all other information in the document and its source documents.

GD 7 (UNIQUE) - Ideas should be stated once only and thereafter referenced.

GD 8 (REFERENCE) - References must be cited for non-original or derived statements.

GD 9 (COMMENT) - All form of comment, note, suggestion, or idea that does not form an official part of the document must be clearly distinguished as such.

GD 10 (RISK) - Any known or suspected adverse consequences of any statement must be clearly indicated.

GD 11 (UNCERTAINTY) - Any known or suspected uncertainty or tolerances associated with quantitative values must be clearly indicated.

GR 12 (PURPOSE) - The document should have an explicit statement of purpose.

GD 13 (STATUS) - A document shall show its Inspection status clearly: “INSPECTED” (from the Document Inspection Process) or “NOT INSPECTED”. Not exited status shall be assumed until other status is claimed. When a document has a status “INSPECTED” the number of issues probably remaining shall be noted next to the “exit” declaration.

Requirement Specification (RS)Version 1.0, Dated July 17, 2003.

RS 1 (TESTABLE) – All requirements are verifiable (objectively)

RS 2 (TRACEABLE) – All requirements must be traceable to a systems specification, contractual/proposal clause.

RS 3 (UNIQUE) – Requirements must be stated only once

5/17/2023

24

RS 4 (ELEMENTARY) – Requirements must be broken into their most elementary form

RS 5 (HIGH LEVEL) – Requirement must be stated in terms of final need, not perceived means (solutions)

RS 6 (QUALITY) – Quality attributes have been defined.

RS 7 (HARDWARE) – Hardware environment is completely defined (if applicable).

RS 8 (SOLID) – Requirements are a solid base for design

Use Case (UC)Version 1.0, Dated July 17, 2003.

Adapted from Karl Wiegers’ Web site (www.Processimpact.com)

UC 1 (Standalone) - The use case a standalone, discrete task

UC 2 (Goal) - The goal, or measurable value, of the use case clear

UC 3 (Actor) - The actor(s) benefit from the use case are identified

UC 4 (Essential) - The use case written at the essential level, rather than as a specific scenario

UC 5 (Details) -The use case free of design and implementation details

UC 6 (Alternative) -The anticipated alternative flows are documented

UC 7 (Exception) – The known exception conditions are documented

UC 8 (Action) – The common action sequences are split into separate use cases

UC 9 (Dialog) - The dialog sequence for each flow are clearly written, unambiguous, and complete

UC 10 (Pertinent) - The actor and step in the use case are pertinent to performing that task

UC 11 (Feasible) - The flow defined in the use case is feasible

UC 12 (Verifiable) - The flow defined in the use case is verifiable

Source Code (SC)Version 1.0, Dated July 17, 2003.

SC 1 (project)- The document (code) must meet all relevant project requirements.

SC 2 (unconfined) - The code should confine itself to the problem at hand, as defined in the module header, problem report or design document.

SC 3 (regression) - The code should introduce no regressions in performance, functionality, or other qualities, except as noted in the module header or other accompanying documentation.

SC 4 (incompatible) - The code should not introduce incompatibilities with other systems, e.g., create a library dependency. Where this is unavoidable, the situation must be clearly documented in the module header or other accompanying documentation.

SC 5 (hard-coded) - The code should use symbolic constraints, instead of hard-coded values, whenever appropriate.

SC 6 (interface) - Module preambles should describe the interface between the module and the ‘outside world’. The preamble should describe entry and exit conditions and a statement of the module's purpose. The preamble should include any orientation necessary for understanding the module as a whole.

SC 7 (style) - For modifications, the coding style should match that of the surrounding code. The author may use differing styles where he or she deems appropriate.

5/17/2023

25

SC 8 (comments) - The level of commentary should match the complexity of the code. Explanatory text should be complete and relevant.

C++ Code (CC) Version 1.0, Dated July 17, 2003.

Adapted from: Humphrey, W., ‘Introduction to the Personal Software Process’, Addison Wesley, 1997.

CC 1 (COMPLETE) - Verify that the code covers all the design.

CC 2 (INCLUDES) - Verify that ‘includes’ are complete.

CC 3 (INITIALIZATION) - Check variable and parameter initialization:

At program initiation.

At start of every loop.

At function/procedure entry.

CC 4 (CALLS) - Check function call formats:

Pointers

Parameters

Use of "&".

CC 5 (NAMES) - Check name spelling and use:

Is it consistent ?

Is it within the declared scope ?

Do all structures and classes use “.” Reference ?

CC 6 (STRINGS) - Check that all strings are:

Identified by pointers,

Terminated in NULL

CC 7 (POINTERS) - Check that:

Pointers are initialized NULL,

Pointers are deleted only after new,

New pointers always deleted after use.

CC 8 (OUTPUT FORMAT) - Check the output format:

Line stepping is proper.

Spacing is proper.

CC 9 (PAIRS) - Ensure the { } are proper and matched.

CC 10 (LOGIC OPERATORS) Verify that the proper use of ==, =, //, and so on.

Check every logic function for proper ( }.

CC 12 (SYNTAX) - Check every line of code for:

Instruction syntax

Proper punctuation.

CC 13 (STANDARDS) - Ensure the code conforms to the project’s coding standards.

CC 14 (FILE OPEN AND CLOSE) - Verify that all files are:

Properly declared

5/17/2023

26

Opened, and

Closed.

Safety Critical Code (SA)Version 1.0, Dated July 17, 2003.

Adapted from: Almaida, J., et al, ‘Best Practices in Code Inspection for Safety-Critical Software’, IEEE Software, May/June 2003, p 56-63.

SA 1 (RETURN) - Routine Return Method

All paths that conduct to the end must have a returned value

Parameter receiving and stack cleaning must be coherently established

SA 2 (INTERRUPTION) - Interruption Handling Routines and Critical Regions

Verify, if routines activated by hardware interruptions make all the correct housekeeping before returning

Verify, in the case of interrupt handling routines, the correct process of return

Check, for the interrupt handling routines, preventing the corruption of portions of code that were executed before the interruption occurrence

Check the link process for verifying if the correct memory address of each routine is generated and written into the proper interrupt vector table position or equivalent.

The maximum execution time of the interruption service must be limited

The use of the global symbols, identified as being addressed by interrupt service routines, must be verified in the entire source code for critical regions

SA 3 (LOOP) - Repetitive loop control

If the loop control variables are tested and updated in a correct way

If the type of variables used in loop control is consistent with the form of their use

SA 4 (INPUT/OUTPUT) - Input/output tests

Existence of an input test guarantying that the routine had reached its end in the previous execution

Existence of output test guarantying that the routine had started from its beginning in the previous execution

SA 5 (FLOW) - Check of program flow control

Verification of control structures through selector blocks

Interrupt disabling commands must have their corresponding enabling commands

For Assembly language, stack commands must have the the corresponding unstack commands

In the case of Assembly language, if all operands are correctly referenced to their register/memory segment

SA 6 (UNUSED) - Avoid unused source code

SA 7 (VARABLES/CONSTANTS) - Use of variables/constants

Verify indexes against the limits of vectors and matrixes before addressing them

Check the place and scope of declared symbols, verifying if double declarations have not occurred

When a program module needs to re-declare a symbol in the same scope of a declaration or header file, the types present in the external declarations have to be consistent

Verify if all global and static symbols are initialized

5/17/2023

27

SA 7 (COMMENTS) – Use source code comments

SA 8 (LEGIBILITY) – Increase source code legibility

Avoid abbreviations in names of constants, variables and routines, as well as very long names

Use of a mechanism for word delimitation, as for example separator characters, capital letter, etc

Coherent and consistent criteria for variable and routine names

Use of prefixes and/or suffixes related to symbol functions

Different representation for constants and variables

Use of indentation with consistent criteria

Use of brackets whenever they contribute to expression clarity, even if they are semantically unnecessary

Avoid extremely complex structures

SA 9 (PRE-PROCESSOR) – Avoid use of pre-processor directives

SA 10 (OPTIMIZATION) – Avoid use of code optimization

Project Plan (PP)Version 1.0, Dated July 17, 2003.

PP 1 (OBJECTIVES) – Plan sates the objectives of the project, with reference to business needs

PP 2 (WBS) – Plan contains the Work Breakdown Structure (WBS) for all tasks.

PP 3 (DEPENDENCIES) – Plan includes the dependencies between WBS tasks and highlight the critical path

PP 4 (RESOURCES) – All resources are specified.

PP 5 (TRAINING) – All training needs are identified.

PP 6 (SCHEDULE) – Plan includes the schedule for all tasks, and who will perform them.

PP 7 (CONTINGENCY) – Plan includes a contingency of at least 15%.

PP 8 (DELIVERABLES) – Plan specifies all the deliverables and the required format.

PP 9 (APPROVAL) – Plan is approved by the relevant manager with responsibility for the project.

Test Plan (TP)Version 1.0, Dated July 17, 2003.

Adapted from : Gilb and Graham Inspection Course Notes, 1995

TP 1 (Intro) – An introduction summarizes software items to be tested.

TP 2 (Refenrence) - References to project plan, quality plan and test design document are provided

TP 3 (Item) – Identify test items including version level, hardware and software requirements, and references to requirements specifications and design documents

TP 4 (Feature) – List features to be tested and features not to be tested ( with reasons)

TP 5 (Approach) – Describe test approach to be used, including techniques and level on comprehensiveness

TP 6 (Criteria) – Specify pass/fail criteria, and person responsible for the decision.

TP 7 (Suspend) – Specify test suspension and resumption criteria

TP 8 (Environment) – Specify test environment, including tools required, user involvement and special equipment

TP 9 (Schedule) – Specify schedule, resources required, responsibilities and contingencies

5/17/2023

28

TP 10 (Stop) – Specify test stopping criteria

TP 11 (Measure) – Measures are identified and defined

TP 12 (Effectiveness) – The effectiveness of the testing process is measured using defect data collected during testing and post-release. Plan specifies how defect data is collected and analysed.

TP 13 (Efficiency) The cost of all test activities is collected.

Rules for Checklists (CK)Version 1.0, Dated July 17, 2003.

Adapted from: Gilb, Tom, Graham, Dorothy: ‘Software Inspection’, Addison-Wesley.

CK 1 (PAGE)- No checklist shall exceed a single page of text (about 60 lines).

CK 2 (EXIT) - All checklists shall have successfully exited from an Inspection against this checklist and the Generic Document (GD) checklist before being taken into use.

CK 3 (REF) - All checklists shall have a unique code for reference. For example this is ‘CK’.

CK 4 (MAJOR) – Checklist items identify major defects

CK 5 (VERSION) – All checklist should have a version number (e.g. Version number X) or release date (e.g. DD-MM-YYYY).

CK 6 (NEW) - When items of checklists are deleted, their reference code (like ‘CK 6’) shall not be reused by essentially different checklists. Mark ‘deleted and code not to be reused’. This is to permit long-term analysis of the usefulness of particular checklists which cause reporting of issues.

5/17/2023

29

7. Tailoring Guidelines

Tailoring of Inspection Process

1. Checking and logging rates Start with reasonable rates (see Gilb chapter 12)

e.g. 10 pages per hour, 300 LOC per hour.

2. Documents subjected to inspections Management should determine which documents will be inspected (e.g. specifications) List of documents subjected to inspections should be in the project plan or SQA plan

3. Ways to conduct logging:1. Verbatim2. Paraphrase3. Mixed styles – Verbatim and Paraphrase4. Section by section or line by line enumeration

o Does anyone have an issue with section X ?’5. Perspective based

o Inspectors stand in for specific stakeholders6. Line by line

o Inspectors state: Checklist tag number, offending word(s). 4. Number of checkers

Effectiveness versus Efficiency For best effectiveness at finding defects: 4 to 6 checkers For efficiciency (cost per defect): 2 to 4 checkers

IEEE Standard 1028: 3 to 6 checkers.

5. Conducting a ‘virtual’ kickoff meeting Using e-mail or web meetings

6. Deleting a process step Deleting the logging meeting

If estimated number of remaining defects is equal or lower than exit criteria (e.g. 0.25 defect per page), logging meeting can be cancelled

If inspected document is so polluted with defects that it should require a rewrite, logging meeting should be cancelled.

7. Documenting the status of a document

3. At step 150, Activities for Inspection Leader during Release. The Inspection Leader is asked to document the release (as “document INSPECTED”) on the latest version of the document. The leader is also asked to include data about estimated remaining issues per page. There are two ways to document the status and estimated quality level of the document:

i) Stamped on the cover page of the document

ii) Under the record of changes table.

RECORD OF CHANGES*A - ADDED M - MODIFIED D – DELETED – N/A – NOT/APPLICABLE

VERSIONNUMBER DATE

yyyy/mm/

NUMBER OF FIGURE, TABLE OR SECTION

A*MD

TITLE OR BRIEF DESCRIPTIONCHANGEREQUESTNUMBER

5/17/2023

30

dd

DOCUMENT STATUS AND QUALITY

*NI – NOT INSPECTED I – INSPECTED E – ESTIMATED C - COMPUTED

VERSION NUMBER

DATEyyyy/mm/dd

STATUS*NI

I

NUMBER OF DEFECTS REMAINING

(Number /Page of 300 words or Number / 300 LOC)

* EC

Tailoring of Checklists1. Deleting items on checklist

a. When items of checklists are deleted, their reference code (like ‘CK 6’) shall not be reused. Mark ‘deleted and code not to be reused’. This is to permit long-term analysis of the usefulness of particular checklists which cause reporting of issues.

Tailoring of Forms

Issue Log FormIdeally, all defects are detected at the phase during which they were produced. In reality, many defects escape the current phase defect detection activities and are discovered only later during development or worst, during operation at the customer’s site. In other to measure the defect containment effectiveness, it is necessary to identify the origin of defects. To do this, another field, called Origin, can be added to the Issue Log Form. This field indicates the life cycle activity which the defect was injected into the document. The following lifecycle activities, are independent of the development life cycle of a project: Systems specification, software specification, design, coding, unit testing, integration testing, acceptance testing.

The identification of the origin of defects is also used to perform root cause analysis and defect prevention. This activity should reduce the number of defects injected at each development stage and should help to increase software quality. It should also reduce development effort since it is less expensive not to inject a defect than to spend the effort to identify it, eliminate it and to update the software documentation.

8. Deployment Guidelines

1. Criteria to select document to be inspected Important documents of the development cycle ( e.g. specification)

Bellcore found that 44% of all defects were due to defects in requirements and design.

2. If a project has already produced documents, it is suggested to start inspecting document produced at the current development phase.

e.g. if the design document3. Process Brainstorming

5/17/2023

31

Conduct process brainstorming at the end of the logging meeting (10-15 minutes) once every 5 logging meeting

4. It is not recommended to assign the role of the scribe to a secretary. Each participant to the logging meeting (not the author) should alternate in recording issues.

5. During initial deployment, it is suggested to inspect original documents only. After a few months, it is suggested to inspect fixes, i.e. documents that have been modified, in order to determine if modifications should also be inspected. According to Weller, (‘Lessons Learned from Three Years of Inspection Data’, IEEE Software, September 1993), up to 75% of fixes have defects.

5/17/2023

9. Forms

Inspection Request Form

Inspection Master Plan Form

Process Brainstorming Meeting Form

Inspection Data Summary Form

Inspection Issue Log Form

Inspection Change Request Form

Inspection Exit Form

5/17/2023

REQUEST FOR INSPECTION

Section filled by document author(s):

Name of author(s): Project name:

Date of request: Charge code: YYYY-MM-DD Identification of product document to be inspected: (Must be line numbered for the inspection)

Document ID: Version: Document section(s)/page(s):

Document Title:

Document Description

.

Physical pages: Logical pages (300 words/page or 100 SLOC/page): Identification of source document(s) used to create the product document:

Title and Date Version Number Relevant Sections or Pages

Section filled by Inspection Leader:

Inspection Leader: Checkers Name (including author(s)) Roles to be played

Document Category:

Doc. Sub-category:

Proposed meetings: Date Location Start Time End Time

Kick-off: Inspection Identification (ID) Number

Logging meeting:

INSPECTION MASTER PLAN

Inspection Description:

Date requested: Inspection Leader: Inspection ID: YYYY-MM-DD

Author(s): Project name:

Document ID: Charge code:

Document Title: Physical pages:

Document Description Logical Pages:

. Exit Criteria which applies

MeetingsDate

YYYY-MM-DD LocationPlanned Start

Time Planned End TimeActual Start

Time Actual End Time Elapsed TimeKick-offLogging #1Logging #2 Process Brainstorm Documents

Title of Document and Date Version Number Relevant Sections or Pages Product(s) Source(s)

Checker Name Relevant Sections or Pages Roles to be played Checklist to be used

Planned individual checking Average time to log an issue Rate Time (Number of issues per minute)

issue Page(s) per hour Hrs Mins /minute

Measures of individual checking (report them at the start of the logging meeting)

Time spent

Number of Pages

Inspected My checking rateNumber of Majors

Number of Minors

Number of Questions

Number of Improvements or Suggestions

Hrs mins Pages/hour

My checking rate was faster than planned because: ______________________________________________________

INSPECTION DATA SUMMARY

Inspection Description:

Date of report: Inspection Leader: Inspection ID: YYYY-MM-DD

Document ID/Version: Physical pages:

Document Title: Logical Pages:Planning:

Date requested:

Checking rate (physical):

Checking rate (logical):

Planning Effort (hrs): Maximum checking rate allowed:

Kick-off:

Number of participants: kick-off duration (hour): Kick-off Effort (s-h):

Checking: Individual Results (to be reported at start of logging meeting)

Checker NamesIndividual Checking

TimePages

Inspected Major Issues

NotedMinor Issues

NotedQuestions

NotedImprovements /

Suggestions NotedChecking

Rate

Within planned Checking Rate:

Total Checking

Effort Average

Checking RateLogging:

Number of Checkers: Logging Duration (Hour): Logging Effort (staff-hour):

Major Issues Logged Minor Issues Logged Questions of Intent Logged Improvements/Suggestions Logged New Items

Logged

Logging Rate(Items/min): Detection Effort (staff-hour): Logging Meeting Rate (pages/hour):Process Brainstorm (Optional):

Number of participants: Brainstorming duration (Hour): Brainstorming Effort (staff-hour):

Editing, Follow-up and Exit:

Major defects edited: Minor defects edited: Change Requests (CRs) raised:

Edit Effort (hour): Follow-up Effort (hour): Exit Time (hour):

Control Effort (hour):Defect Removal Effort (hour): Exit Date:

Estimated Remaining Major Defects per Page: Estimated Effectiveness (Major defects/total):

Efficiency (Number of Majors/hour): Estimated Development Effort Probably Saved (hour):Notes:

Estimated Effectiveness = 30%-50% for CMM Level 1, 60% for CMM Level 2, 70% for CMM 3, 80% for CMM Level 4,

90% for CMM Level 5

INSPECTION ISSUE LOGDocument ID: INSPECTION ID:Document Title:

Item No.Document

PageLine Number /

Location

Maj

or

Min

or

New

Que

stio

n

Imp/

Sug

g

Checklist Tag Checker initials Description (key offending words)

No. of Occurences

Editor Note

1

2

3

4

5

6

7

8

9

10

11

12

13 SUBTOTAL: (Among issues logged on this page) (Found during logging meeting) Major defect:

Major issues logged: New issues logged: _________ Minor defect:

Minor issues logged: # CRs:

Improvement/suggestions logged: Edit Time: Questions of intent logged: Issues (major + minor) logged: Items logged: Page __of ___

Process Brainstorming Meeting Form

Date of process brainstorming meeting : _________________________ Start time : ________________________

Software Inspection Identification : ____________________________Inspection Leader : __________________________

Document Reference : ________________________________________________________________________________

Other Document References : __________________________________________________________________________

Brainstorm Item no.

IssueRef. Classification of

Cause (tick)Root Cause(keywords)

ImprovementSuggestions (keywords)

1

CommunicationOversightTranscriptionEducation

2


3


4


5


6


7


8


9


10


Stop time : _______ Brainstorming meeting duration : ____ (min.) No. of people : ____

Total Brainstorming time (in work-hours for all) : ____ hrs

CHANGE REQUEST

Change Request Information:

Date of Change Request (yyyy-mm-dd): Change Request Number:

To (Document Originator): Phone number:

Reply required by (yyyy-mm-dd): Identification of document to be changed:

Document Identification: Version: Document section(s) or page(s):

Document Title:

Document description

Change description:

Athorized by: On date (yyyy-mm-dd): Response from Document Originator:

Change accepted. Date scheduled (yyyy-mm-dd): Date performed (yyyy-mm-dd):

Change not accepted. Detail of reasons why it was not accepted:

I am not the Document Owner. Document Owner is :

Phone number: Location/department.:

I have forwarded a copy of this Change Request to the actual Document Owner.

New Document Owner: Date forwarded (yyyy-mm-dd): Measures of effort and duration:

Time spent on this CR (hours:minutes)Start date

(yyyy-mm-dd)End date

(yyyy-mm-dd)

X

INSPECTION EXIT FORM

Inspection

ID: This certifies that the document (or part of the document): Document ID: Document title: . . Document pages or sections: Originator/Author: has exited from the Inspection Process and successfully met the Exit Criteria Exit Criteria Checklist: Initials: 1.All editing has been completed 2.All necessary change request cross-references are inserted in this document 3.Data summary is completed and sent to the database 4.There are no more major defects per page remaining in this document than the number specified in the Inspection Master Plan (this value is confidential) 5.Checking & logging rates did not exceed the known optimum rates by more than 20% on average 6.Either the originator/author or the Inspection Leader agree that the release of this document can be safely used as a source or as a basis for any other document

Exit Date (yyyy-mm-dd): Inspection Leader:

Inspection Leader's Signature: