instructional handbook for formal inspections · 13. contact each candidate inspector to determine...

Instructional Handbook for

Formal Inspections

i

Table of Contents

1.0 Introduction .........................................................................................................................11. 1 Purpose .........................................................................................................................11.2 Document Organization and Content ..............................................................................1

2.0 Instructions for the Roles of MODERATOR & LIBRARIAN ..............................................22.1 Planning Stage.................................................................................................................22.2 Overview Meeting ..........................................................................................................52.3 Preparation Stage ............................................................................................................52.4 Inspection Meeting .........................................................................................................72.5 Third-Hour ...................................................................................................................102.6 Rework Stage ...............................................................................................................102.7 Follow-Up Meeting ......................................................................................................11

3.0 Instructions for the Roles of INSPECTOR, READER, & RECORDER ..............................133.1 Planning Stage ..............................................................................................................133.2 Overview Meeting ........................................................................................................133.3 Preparation Stage ..........................................................................................................133.4 Inspection Meeting .......................................................................................................143.5 Third-Hour ...................................................................................................................163.6 Rework Stage ...............................................................................................................173.7 Follow-Up Meeting ......................................................................................................17

4.0 Instructions for the Role of AUTHOR ................................................................................184.1 Planning Stage ..............................................................................................................184.2 Overview Meeting ........................................................................................................194.3 Preparation Stage ..........................................................................................................194.4 Inspection Meeting .......................................................................................................194.5 Third-Hour ...................................................................................................................194.6 Rework Stage ...............................................................................................................204.7 Follow-Up Meeting ......................................................................................................20

Appendix A: Quick Reference GuideAppendix B: Forms with Instruction

B. 1 Required FormsB.2 Optional Forms

Appendix C: ChecklistsAppendix D: Certification of Inspection Participants

D.1 Moderator CertificationD.2 Inspector CertificationD.3 Librarian Certification

Appendix E: Inspection Type and ParticipantsAppendix F: Guidelines for Combining Roles

Introduction

1

1.0 Introduction

1.1 Purpose

The purpose of this document is to provide inspection participants with detailedinstructions on how to perform Formal Inspections.

1.2 Document Organization and Content

This document is divided into three main sections:

Section 2.0 Instructions for the Roles of MODERATOR & LIBRARIAN

This section provides instructions on performing the duties of Moderator. It includes allthe inspection duties which the Moderator is required to fulfill. The subset of theModerator's duties which can be delegated to a Librarian are also specified in this section.

Section 3. 0 Instructions for the Roles of INSPECTOR, READER, & RECORDER

This section provides instructions on performing the duties of Inspector and incorporatesinstructions for performing the additional duties required of the Reader and Recorder.

Section 4. 0 Instructions for the Role of AUTHOR

This section provides instructions on performing the duties of Author. The Author isrequired to participate in all Formal Inspection stages except for the Preparation Stage.However, if the Author elects to participate in the Preparation Stage the Author mustreference Section 3.3 (Preparation Stage) to find the appropriate instruction. In addition,this section points the Author to Section 3.4 (Inspection Meeting) to obtain the guidelinespertaining to the Inspection Meeting. All other duties required of the Author are outlinedwithin this section.

The Appendices contain: a Quick Reference Guide for Formal Inspections, the FormalInspection forms and instructions for the forms, checklists for various types of inspections,certification requirements for Formal Inspection participants, suggested

Introduction

22

participants for various types of inspections, and guidelines for combiningFormal Inspection roles. When the Formal Inspection forms, in Appendix B,are referenced in the text their titles are written in BOLD TYPE AND ALLLETTERS ARE CAPITALIZED. References to individual items on theforms are written in Bold Type And The First Letter Of Each Word IsCapitalized

Moderator & Librarian

33

2.0 Instructions for the Roles of MODERATOR & LIBRARIAN

This chapter contains instructions for fulfilling the roles of Moderator and Librarian.The Moderator must fulfill all the responsibilities of an Inspector plus additionalresponsibilities. This section covers both the Inspector specific and the Moderatorspecific responsibilities. The Librarian assists the Moderator but does not participate asan Inspector. A subset of the Moderator's duties can be delegated to the Librarian. Theduties of the Moderator that can be delegated to the Librarian are written in italics.Any time expended by the Librarian should be recorded as part of the Moderator'stime. In addition to the instructions provided in this section, it is suggested thatModerators attend bimonthly Moderator Meetings to obtain feedback and lessonslearned from other Moderators in the organization.

2.1 Planning Stage

1 Ensure that entrance and exit criteria have been established for this type of workproduct.

2. Meet with the Author to discuss the product and determine if the Author feelsthe product is ready for inspection.

3. Determine if the size of the product is within the prescribed guidelines for thetype of inspection. Refer to Appendix A, (Quick Reference Guide) for guidelineson the optimal number of pages or lines of code to inspect for each type ofinspection. If the product exceeds the prescribed guidelines, break the productinto parts and inspect each part separately.

4. Obtain from the Author a hard copy of the product and verify that the time,date, and version of each unit is recorded on the submitted product. Obtain acopy on electronic media, if available, and ensure that the time, date, andversion information matches the information recorded on the hard copy. Instructthe Author that no modifications are to be made to the part of the productunder inspection until after the Inspection Meeting.

5. Ensure that the appropriate entrance criteria have been fulfilled. (Examples:


4 Planning Stage4

does the product conform to project standards, has the document been runthrough a tool that checks spelling, has the code been successfully compiledwithout errors?). If the product does not meet the entrance criteria or if theModerator does not feel that the product is ready for inspection, theModerator should return the product to the Author for further development.

6. Obtain the following information from the Author and record it on the specifiedform. (A complete set of inspection forms are provided in Appendix B. Inaddition, a copy of the set of inspection forms can be obtained from the DataManager.)

INSPECTION ANNOUNCEMENT form:

a) Scheduled Delivery Date,

b) Size of the Work Product: for documents, the number of pages, thespacing (single, double, diagram), and the font size; for code andpseudo-code, the number of lines and whether that includes commentsand/or blank lines,

c) the percentage information for the Nature of Work,

d) a list of all Reference Documents that may be needed for the inspection.

INSPECTION SUMMARY REPORT form

a) Approx. Person-Hours Expended (prior to inspection) DevelopingWork Product.

7. Discuss candidates for Inspectors with the Author, select the Inspection Teammembers, and assign roles to the Inspectors. Suggestions are given in AppendixE, (Inspection Type and Participants).

8. Determine if an Overview Meeting is needed. An Overview should be scheduled ifthe Inspectors need background information to successfully fulfill their roles. Thismeeting occurs when the project is new, a novel technique is used in the workproduct, the Inspectors are new to the project, inspections are new to the project,or it is the first inspection on a particular type of work product (Examples:requirements, designs, code, etc.)

9. If an Overview Meeting is needed, work with the Author to set a tentative datefor the meeting which will allow enough time for the Author to prepare. Refer toAppendix A for guidelines on the amount of lead time needed to prepare for theOverview.


Planning Stage 55

10. With the Author's assistance, set a tentative date for the Inspection Meetingwhich will allow enough time for the Inspectors to prepare for the InspectionMeeting. Refer to Appendix A for guidelines on the amount of lead time neededto prepare for the Inspection Meeting. (Note: If a project inspection schedulehas been established, set the Inspection Meeting date according to thatschedule.)

11. Obtain from the Author copies of the Reference Documents needed for theinspection or obtain a list of relevant sections of the Reference Documents ifthe documents are already available to the inspection team members.

12. Obtain from the Author the time in person-hours expended during thePlanning Stage and record it under Planning on the INSPECTIONSUMMARY REPORT form.

13. Contact each candidate Inspector to determine the following:

a) they are Certified Inspectors,

b) they will be able to attend the Overview if one is scheduled,

c) they will be able to attend the Inspection Meeting.

Repeat this process with each Inspector until the entire Team, including the Author,is in agreement on the date and time of the Overview and the Inspection Meeting.

14. Reserve a conference room for the Overview Meeting, if one is scheduled, andfor the Inspection Meeting. Be sure the room is equipped with the properaudiovisual or computer equipment if any is needed.

15. Contact the Data Manager to obtain a unique Inspection ID. The InspectionID must be recorded on all inspection forms. The Data Manager will assist increating a meaningful Inspection ID.

16. Fill in the Planning Start Date and Project Start Date on the INSPECTIONSUMMARY REPORT.

17. Complete the INSPECTION ANNOUNCEMENT form. Be sure to indicate,in the Comments section, the date and time the INDIVIDUALPREPARATION LOG should be returned to the Moderator. This timeshould be at least 4 business hours before the scheduled Inspection Meetingtime.

18. Assemble the following items for the Inspection Package:


6 Planning Stage6

a) the INSPECTION ANNOUNCEMENT form,

b) the blank INDIVIDUAL PREPARATION LOG form,

c) a blank INDIVIDUAL PREPARATION LOG continuation form,

d) the blank FORMAL INSPECTIONS LESSONS LEARNED form(Optional),

e) the INSPECTION SUMMARY REPORT from the first inspection ifthis is a re-inspection,

f) the product being inspected,

g) any reference material that the Author wishes to include in the package,

h) the appropriate Checklist for the type of inspection. Checklists areprovided in Appendix C.

Specify the location of any reference documents not included in the inspectionpackage in the Reference Documents section of the INSPECTIONANNOUNCEMENT. Fill in the Inspection ID # on all forms.

19. Make a copy of the entire Inspection Package for each Inspector, including theAuthor.

20. Optional: The Moderator or an Inspector designated by the Moderator cancomplete the Preparation Stage prior to the copying and distribution of theInspection Packages to the entire Team. This optional step is done to ensure thatthe product is ready for inspection. If the product is found to contain too manydefects or potential Open Issues during the preparation stage, the productshould be given back to the Author for further development work based on theinformation provided by the Moderator or the designated Inspector on theINDIVIDUAL PREPARATION LOG. This step will save considerable timesince the rest of the Inspectors will not have to invest time on a product that isnot ready for inspection. This step is highly recommended if the Author is newto the inspection process or inspections are new to a project. If this optional stepis performed and it is determined that the product is not ready for inspection, theData Collection Package should be completed. The package should include: theitems listed in Step 24, the INDIVIDUAL PREPARATION LOG completedby the designated Inspector, and the INSPECTION SUMMARY REPORTcompleted by the Moderator. The INSPECTION SUMMARY REPORTshould contain a Comment explaining the situation and state the number ofadditional hours the Author spent completing the product before it


Planning Stage 77

was resubmitted for inspection. Submit this Data Collection Package to theData Manager as soon as the development on the product is complete and it isready to be submitted to the inspection process again, then start over at step 1of this section.

21. Fill in the Inspection ID # on each of the following forms and add them to theModerator's Inspection Package:

a) the blank DETAILED INSPECTION REPORT form,

b) the INSPECTION SUMMARY REPORT form,

22. Fill in the Inspection ID # on each of the following forms and add them to theRecorder's Inspection Package:

a) the blank INSPECTION DEFECT LIST form,

b) a blank INSPECTION DEFECT LIST continuation form.

If an overhead projector will be used to record the Defects, transparencies of theseforms should be inserted into the Recorder's package instead of paper copies.

23. Distribute the Inspection Package to each Inspector including the Author in atimely manner to allow enough time for preparation.

24. Begin assembling a Data Collection Package that will be sent to the DataManager when the inspection process is complete. This package should startwith the following items:


b) the INSPECTION SUMMARY REPORT from the first inspection ifthis is a re-inspection,

c) the product being inspected,

d) any reference material that the Author wishes to include in the package,

e) the Checklist for the inspection if it differs from those provided inAppendix C.

More items will be added to this package as the inspection process continues.

25. Record the total time in person-hours expended by the Moderator during the


8 Planning Stage8

Planning Stage on the INSPECTION SUMMARY REPORT form. Thetotal person-hours which the Librarian spent assisting the Moderator shouldbe added to this total.

2.2 Overview Meeting

I Begin by introducing yourself and stating the purpose of the Overview. Be sureall key personnel are in attendance. Reschedule the Overview if they are not.

2. Introduce the Author and then turn the meeting over to the Author.

3. When the Author has completed the Overview presentation ask if there are anyquestions.

4. Thank the Author and remind everyone of the time and location of theInspection Meeting. Also remind them when to turn in their INDIVIDUALPREPARATION LOG forms.

5. Adjourn the meeting.

6. Record the time in person-hours expended by the Moderator, the Inspectors, andthe Author during the Overview Stage on the INSPECTION SUMMARYREPORT form. Also, obtain from the Author the number of hours spentpreparing for the Overview and record it on the same form.

2.3 Preparation Stage

1. Look through the Inspection Package to ensure that the following items areincluded:




d) the blank FORMAL INSPECTIONS LESSONS LEARNED REPORTform (Optional),

e) the INSPECTION SUMMARY REPORT from the first inspection ifthis is a re-inspection,


9 Preparation Stage9

h) the appropriate Checklist for the type of inspection,

i) the blank DETAILED INSPECTION REPORT form,

j) the INSPECTION SUMMARY REPORT form,

Obtain any items which are missing from the Inspection Package beforecontinuing.

2. On the INDIVIDUAL PREPARATION LOG form, record the Date PackageReceived and the Approx. # of Formal Inspections Participated in to Date.

3. Look over the product being inspected for organization and understanding.

4. Review the Checklist provided with the Inspection Package.

5. Review the product using the Checklist as a guide to help identify possibleDefects.

6. Refer to the documents listed under the Reference Documents section on theINSPECTION ANNOUNCEMENT for more information and to verify anyspecific references contained in the product.

7. If a portion of the product is unclear or appears to be incorrect, record aDescription of the problem on the INDIVIDUAL PREPARATION LOG.Record the Location of the Defect/Concern and specify if it is a potential MajorDefect, Minor Defect or Open Issue by checking the appropriate box. (Optional:Provide the Suggested Classification by: indicating Missing, Wrong, or Extra;indicating the Type of the Defect/Open Issue from the categories listed on theprovided Checklist; and indicating in the Origin box the product in which theDefect/Open Issue probably originated, if other than the product beinginspected.) If the same Defect appears in multiple locations, you may record thelocation in the Location(s) box and record the Defect number assigned to the firstoccurrence in the Description box to avoid having to rewrite the Description foreach occurrence. Defects which are Trivial (not Major or Minor) such astypographical errors, punctuation, or improvements in verbiage should be markedon the document in red. Trivial Defects are recorded on the work product only,not on the INDIVIDUAL PREPARATION LOG. Trivial Defects that havebeen recorded on the work product are given to



the Author after the Inspection Meeting is complete.

8. Repeat steps 5-7 until the review of the product is complete and all concernshave been recorded.

9. Record the date and time in person-hours spent on this exercise on theINDIVIDUAL PREPARATION LOG form.

10. Verify that all Inspectors have turned in their INDIVIDUAL PREPARATIONLOGS by the time specified in the Comments section of the INSPECTIONANNOUNCEMENT. Contact any Inspectors who failed to turn in theirINDIVIDUAL PREPARATION LOG forms on time. (Note: The Author is notrequired to complete an INDIVIDUAL PREPARATION LOG.)

11. Review each INDIVIDUAL PREPARATION LOG to ensure that allInspectors have checked one of the boxes to indicate whether they will beprepared for their roles. Reschedule the Inspection Meeting if the Moderator orany of the other Inspectors have indicated that they need more Preparation time.

12. Review the Total Hours expended by the Inspectors to determine if theInspectors have spent enough time in preparation. Each Inspector should spendapproximately the same amount of time in preparation as is expected to be spentduring the Inspection Meeting. Contact any Inspectors who have spentsignificantly less time in preparation, and determine if there is sufficient reasonfor rescheduling the inspection.

13. Review the kinds of Defects logged to determine if the Inspectors are adequatelyprepared. A large deviation in the number of Defects found may be an indicationthat some of the Inspectors did not have adequate time to prepare. Contact anyInspectors who recorded a low number of Defects to determine if the InspectionMeeting needs to be rescheduled.

14. Use the INDIVIDUAL PREPARATION LOGS to efficiently organize theInspection Meeting. The following is a list of possible scenarios:

a) If the logs indicate that a particular section of the product containsnumerous Defects, the Moderator may instruct the Reader to read ratherthan paraphrase that section of the product.

b) If the Recorder's log indicates numerous Defects in a particular section ofthe product, the Moderator may appoint an alternate Recorder for thatsection. If another Inspector had fewer Defects identified for thatparticular section, then the Moderator could appoint that Inspector as thealternate Recorder. This would give the Recorder sufficient time duringthe meeting to explain the identified Defects without having to rush


Preparation Stage 1111

through the recording process

c) The logs may indicate that additional reference materials need to bebrought to the Inspection Meeting.

15. Review the list of Inspectors to determine the seating arrangement. Therecommended seating arrangement is to have the Author beside the Moderatorand to have the Reader and Recorder across the table from the Author.

16. Assemble all relevant Reference Documents to bring to the Inspection Meeting.

17. Record the date and time in person-hours expended during these additionalpreparation activities on your INDIVIDUAL PREPARATION LOG form.Record your Completion Date and calculate and record the Total Hours spentin the Preparation Stage. The total person-hours which the Librarian spentassisting the Moderator should be included in the Total Hours.

18. Review the following steps provided in Section 2.4 (Inspection Meeting) beforethe meeting starts.

2.4 Inspection Meeting

1. Arrive at least 10 minutes early to arrange the room and set up any equipmentneeded. Bring all reference materials, your Inspection Package, and theINDIVIDUAL PREPARATION LOGS from each Inspector to the meeting.Also bring your appointment book so you will know when you are available ifThird-Hour Meetings are necessary as a result of this inspection.

2. Have a seating arrangement in mind and instruct the Inspectors where to sit asthey arrive.

3. If an Overview was not held, begin the meeting by introducing yourself and statethe name of the work product which is being inspected.

4. Introduce all the Inspectors and give their roles or allow them to give thisinformation. Be sure all Inspectors are in attendance. Reschedule the InspectionMeeting if they are not.

5. Return each Inspector's INDIVIDUAL PREPARATION LOG.

6. Ask each Inspector to state the Total Hours spent in preparation which shouldbe obtained from their INDIVIDUAL PREPARATION LOG. Calculate the


12 Inspection Meeting12

total number of person-hours spent by all the Inspectors and record it on theINSPECTION SUMMARY REPORT form in the Preparation boxesRecord the preparation time for the Author and the Moderator separate fromthe other Inspectors.

7. Remind everyone of the following:

a) the objective of the inspection is to find and classify Defects, not topropose solutions or grade the Author,

b) give the Recorder enough time to write down each Defect/Open Issuebefore continuing with the inspection,

c) discussion of the issue should not exceed 3 minutes,

d) address the Reader or the Moderator when raising issues or askingquestions about the product,

e) be willing to accept the responsibility for resolving/closing any Open Issueswhich may be assigned to you.

8. Turn the floor over to the Reader to begin the presentation of the product beinginspected.

9. As the Reader presents the product being inspected, refer to your INDIVIDUALPREPARATION LOG to know when to raise issues you are concerned about.Stop the Reader and read aloud the Defect/Concern Description from yourINDIVIDUAL PREPARATION LOG.

10. If, during the inspection, you discover a new Defect which you did not record onyour INDIVIDUAL PREPARATION LOG, bring it to the attention of therest of the Inspection Team.

11. If the Inspection Team agrees that a Defect has been identified, instruct theRecorder to write the Location and Description of the Defect on theINSPECTION DEFECT LIST form, and obtain agreement on theClassification of the Defect. Instruct the Recorder to indicate the product inwhich the Defect/Open Issue originated if the origin is other than the productbeing inspected. Be sure the initials of the finder are recorded in the Finder'sInitials box on the INSPECTION DEFECT LIST in case the Author hasquestions about the Defect after the Inspection Meeting is over. If the Defectwas initially found in the Inspection Meeting, place an asterisk by the findersinitials to indicate that the defect was found during the meeting.

12. If the Inspection Team cannot reach an agreement as to whether or not a


Inspection Meeting 1313

particular portion of the product contains a Defect or what the Defect is within3 minutes, instruct the Recorder to write the Location and Description of theissue and classify it as an Open Issue on the INSPECTION DEFECT LISTform. No further classification is needed at this time for the Open Issue.Determine which individuals are required to resolve the Open Issue, instruct theRecorder to write the initials of each of those individuals in the Comments boxon the INSPECTION DEFECT LIST form, and instruct the Recorder to putan asterisk by the name of the Inspector responsible for resolution/closure of theOpen Issue if other than the Author.

13. Instruct the Recorder to report aloud the number that was assigned to theDefect/Open Issue on the INSPECTION DEFECT LIST, and instruct theInspectors to record that number on the Number Assigned to Defect/OpenIssue space provided on the INDIVIDUAL PREPARATION LOG form.Recording the Number Assigned to the Defect/Open Issue on theINDIVIDUAL PREPARATION LOG is important for the following reasons:

a) The same Defect may appear in multiple locations, however, theInspectors should not be allowed to list all occurrences of the Defect atonce. Each occurrence of the Defect should be identified when theReader reaches the location of that occurrence and not before. Thisaction prevents the Inspectors from skipping back and forth to differentlocations in the product which disrupts the flow of logic that the Readeris trying to maintain.

b) When a Defect identical to one previously recorded is identified inanother location, the Inspector identifying the Defect can refer theRecorder back to the specific Number Assigned to Defect/Open Issuewhere the Defect was previously recorded. The Recorder need onlyrecord the additional Defect location for the previously described Defect.

c) At the end of the inspection when the Recorder reads back the Defectsand Open Issues along with the respective Defect numbers, eachInspector can easily locate the corresponding Defect on theINDIVIDUAL PREPARATION LOG from the associated NumberAssigned to Defect/Open Issue. Any issue recorded on theINDIVIDUAL PREPARATION LOG which was found not to be aDefect should have a checkmark for that Number Assigned toDefect/Open Issue to indicate that the issue was addressed butdetermined not to be a Defect/Open Issue.

14. If the Defect is in another document, assign an Inspector the responsibility ofwriting a Discrepancy Report/Change Request and instruct the Recorder to notethe Inspector's initials in the Comments box on the INSPECTION DEFECTLIST.



15. Wait for the Recorder to finish recording the issue before instructing the Readerto continue with the presentation of the product being inspected. Do not allowthe Inspectors to bring up new concerns while the Recorder is still writing.

16. Repeat steps 9-15 until the entire product is inspected or 2 hours have elapsed.

17. If the inspection is not completed in 2 hours, then agree on a date and time tohold a second Inspection Meeting. Complete the inspection process for theportion of the document which has been inspected by performing the remainingsteps in this section.

18. At the end of the Inspection Meeting, instruct the Recorder to read each Defectnumber and the associated Defect Description from the INSPECTIONDEFECT LIST. Also, instruct the Inspectors to verify that each concern theyhad on their INDIVIDUAL PREPARATION LOG was addressed and thosedetermined to be Defects are included in the list of Defects read by the Recorder.Any issue which was not addressed in the meeting (does not have a number orcheckmark on the Number Assigned to Defect/Open Issue line) should beraised while the Recorder is reading back the Defects. Optional: At this point, aclosure date can be specified for the Open Issues and the date can be recorded inthe Comments box. The date would reflect the date by which the Open Issuemust be resolved, not the date by which it must be fixed.

19. Go around the table and ask each Inspector to comment on the inspection. EachInspector should express an opinion on whether the product needs to be Re-inspected and encourage the Inspectors to provide positive comments about theproduct.

20. Based on the inputs from the other Inspectors, decide if the product needs to bere-inspected. If a large number of Major Defects were identified, or if a MajorDefect is highly critical, or if there were a large number of Open Issues requiringrework, the product should be re-inspected. If a re-inspection criteria has beenestablished for the project, compare the current inspection against the criteria todetermine if a re-inspection is required.

21. The date and time for the Third-Hour Meeting(s) required to resolve OpenIssues should be scheduled at this time. When a meeting is required to resolve anissue, reserve a conference room or specify an office where the meeting will takeplace. Specify which Inspectors are required at each Third-Hour meeting. Thisinformation is obtained from the Comments box on the Inspection Defect List.Inspectors need only attend the meetings to which they were assigned in order tomake the most efficient use of their time. If the same Inspectors are required toresolve several Open Issues, consider grouping those Open Issues



into one Third-Hour Meeting. Remind those responsible for resolving/closingOpen Issues that the resolution of each Open Issue must be relayed to theModerator (the OPEN ISSUE REPORT form may be used to record theresolution), that they should obtain the description of the Open Issue from theINSPECTION DEFECT LIST before leaving the Inspection Meeting, andthat all Open Issues need to be resolved by the assigned closure date. If aclosure date was not assigned, the Open Issues must be closed prior to theFollow-Up Meeting. All time expended in resolving these issues must bereported to the Moderator by the Inspector responsible for closure. Encouragethe Inspectors to help the Author resolve all Open Issues as soon as possible sothat the Rework process is not delayed.

22. Collect all INDIVIDUAL PREPARATION LOGS and have all Inspectorsturn in their copies of the product to the Author if they have redlined any TrivialDefects.

23. End the meeting on a positive note by commending the Author and theInspectors.

24. Encourage the Inspectors to make use of the FORMAL INSPECTIONSLESSONS LEARNED REPORT form to inform the Data Manager of theircomments, suggestions or criticisms on the Formal Inspection process.

25. Thank everyone for participating in the inspection and excuse everyone exceptthe Author and the Recorder.

26. Ask the Author for the Estimated Person-Hours for Rework and theEstimated Rework Completion Date. The Estimated Rework CompletionDate should be within the suggested guidelines provided in Appendix A so thatsubsequent development efforts are not delayed. Determine a tentativeScheduled Follow-Up Date and record all these dates on the INSPECTIONDEFECT LIST.

27. Verify that all Defects recorded on the DETAILED INSPECTION REPORThave been classified and that the Author has been given a copy of theINSPECTION DEFECT LIST.

28. For each Defect recorded on the INSPECTION DEFECT LIST, have theRecorder read aloud what Type of Defect it is, whether it is Major or Minor,and whether it is Missing, Wrong, or Extra. This information is recorded on theDETAILED INSPECTION REPORT by placing a mark in the appropriate boxas the Defect Classification is called out by the Recorder. When all Defects havebeen recorded on the DETAILED INSPECTION REPORT, total the columnsboth horizontally and vertically. Always use a pencil for filling out this form sinceit may be updated once all of the Open Issues have been



resolved.

29. Complete the items on the INSPECTION SUMMARY REPORT form labeledInspection Meeting Date, # Participants, Meeting Length, Defects Found,Open Issues, and Status. Also, record the Number of Representatives fromEach Area, including the Author's area of expertise. This may be a fractionalnumber if one Inspector represents multiple areas. However, the total number ofrepresentatives should equal the number of inspection participants recorded under# Participants.

30. Record separately the time in person-hours expended by the Moderator, theAuthor, and the other Inspectors during the Inspection Meeting in the Meetingcolumn on the INSPECTION SUMMARY REPORT form. Be sure to add theextra time expended by the Author, the Moderator, and the Recorder forcompleting the forms after the meeting. Use the following formulas to calculateMeeting time:

Inspectors = Meeting Length x (# Participants - # Authors - 1 for theModerator)

Author(s) = (Meeting Length + Author's time spent on forms) x # Authors

Moderator = Meeting Length + Moderator's time spent on forms + any timethe Recorder spent helping the Moderator with the forms.

2.5 Third-Hour

1. Work to resolve any Open Issues to which the Moderator was assigned. Attendthe Third-Hour meetings to which you were assigned.

2. The Moderator must ensure that each Inspector who was assigned theresponsibility of closing an Open Issue performs the following: relays theresolution of the Open Issue to the Moderator so that it can be recorded oneither the Comments box on the INSPECTION DEFECT LIST or on anOPEN ISSUE REPORT form if additional recording space is required; resolvesthe Open Issue by the closure date specified in the Comments box on theINSPECTION DEFECT LIST, or if a closure date was not assigned, resolvesthe issue prior to the Follow-Up Meeting; records the times expended by allInspectors involved in resolving the Open Issues, and reports the times to theModerator.

3. Complete any Discrepancy Reports/Change Requests assigned to you.


Third Hour Meeting 1717

4. Ensure that the resolutions of all Open Issues to which the Author was notassigned are communicated to the Author.

5. During this stage, you may suggest solutions for correcting Defects if the Authorrequests your assistance.

6. If requested, assist the Author by providing clarification on Defects which youidentified in the Inspection Meeting.

7. Work with the Author to obtain a Waiver from the Manager for any unaddressedOpen Issue.

8. Work with the Author to obtain a Waiver from the Manager for any Major Defectwhich will not be corrected by the Follow-Up Meeting.

9. Contact the Author and ensure that the Rework will be complete by theEstimated Rework Completion Date recorded on the INSPECTIONDEFECT LIST. If the Rework will not be complete, make the appropriateadjustments to the Scheduled Follow-Up Date which was recorded on theINSPECTION DEFECT LIST.

10. Prior to the Scheduled Follow-Up Date, check with the Author to schedule atime and location for the Follow-Up Meeting.

11. Record on the INSPECTION SUMMARY REPORT form, under the Third-Hour column, the time in person-hours expended by the Moderator, theInspectors, and the Author(s) during the Third- Hour. This includes the timespent on resolving Open Issues, completing Discrepancy Reports/ChangeRequests/Waivers, and assisting the Author with Defect clarification orsolutions. In addition, obtain all assigned Discrepancy Reports/Change Requests.

2.6 Rework Stage

Their are no duties for the role of Moderator during the Rework stage.

2.7 Follow-Up Meeting

1. Obtain a hard copy of the corrected work product from the Author. Verify thatthe time, date, and version of each unit is recorded on the submitted product.


18 Follow-Up Meeting18

Obtain a copy on electronic media, if available, and ensure that the time, date,and version information matches the information recorded on the hard copy.Instruct the Author that no further modifications are to be made to the part ofthe product which has been inspected without the proper approval

2. Verify that any new defects discovered during the Third-Hour or Rework stagesare recorded on the INSPECTION DEFECT LIST and update theDETAILED INSPECTION REPORT accordingly.

3. Ensure that the reworked product meets the entrance criteria (standards,automatic checking, etc.) If it does not, return the product to the Author forfurther rework.

4. Obtain from the Author the completed INSPECTION DEFECT LIST, allOPEN ISSUE REPORTS, and a copy of any Waivers obtained.

5. Obtain from the Author and record on the INSPECTION SUMMARYREPORT the time in person-hours expended during the Third-Hour andRework. In addition, record the Actual Rework Completion Date on theINSPECTION DEFECT LIST.

The Moderator or an Inspector designated by the Moderator performs steps 6-11.Assistance from the Author may be requested at the discretion of the Moderator or theModerator's designee.

6. Review every item on the INSPECTION DEFECT LIST.

7. Verify that the Location of Correction(s) is recorded on the INSPECTIONDEFECT LIST.

8. Verify that all Major Defects and Open Issues determined to be Major Defectshave been corrected and no new Defects have been inserted.

9. Verify that all Minor Defects and Trivial Defects that were fixed were fixedcorrectly and that no new Defects were inserted in the process.

10. Check off each item on the INSPECTION DEFECT LIST to indicate that theRework is complete.

Check off each Open Issue that has been resolved and verify that a description of theresolution is included in the Comments box on the INSPECTION DEFECT LISTor on the OPEN ISSUE REPORT if one was completed.

12. Update the columns and totals on the DETAILED INSPECTION REPORTand the Defects Found section of the INSPECTION SUMMARY REPORT if


Follow-Up Meeting 1919

any of the Open Issues were determined to be Defects.

13. Verify that each Open Issue has been addressed.

14. Verify that a waiver has been written for any Major Defect which has not beencorrected.

15. Send the product back for additional Rework if any of the corrections areunacceptable, if any Open Issues have not been addressed, if waivers have notbeen obtained for the Major Defects that have not been corrected, or if theproduct fails to meet the exit criteria for this type of inspection.

16. Complete the INSPECTION SUMMARY REPORT form by completing theDefects Reworked, Open Issues, and Discrepancy Reports/ChangeRequests/Waivers sections. Record the time in person-hours expended by theModerator and the Author during the Follow-Up Stage. Total all the hoursexpended in the inspection process. Record anything unusual about theinspection in the Comments section. Set a Re-inspection Target Date if a Re-inspection is required. (Optional: Provide comments which may be helpful inimproving the Formal Inspection process on the Formal Inspections LessonsLearned Report.)

17. Add the following items to the Inspection Package that is sent to the DataManager:

a) each Inspector's original INDIVIDUAL PREPARATION LOG,

b) the INSPECTION DEFECT LIST,

c) the DETAILED INSPECTION REPORT,

d) the INSPECTION SUMMARY REPORT,

e) any completed OPEN ISSUE REPORT forms or Waivers,

f) J) a copy of the Inspection Certified work product.

18. File the Data Collection Package with the Data Manager. Send a copy of theINSPECTION SUMMARY REPORT to the project Quality AssuranceRepresentative if one has been assigned.

19. If the product is to be re-inspected, start with the Planning Stage and executethe Formal Inspection process again on the reworked product.

Inspector, Reader, & Recorder

2020

3.0 Instructions for the Roles of INSPECTOR, READER, &RECORDER

This chapter contains instructions for fulfilling the roles of Inspector, Reader, andRecorder. The Reader and Recorder must fulfill all the responsibilities of an Inspectorplus additional responsibilities. These additional responsibilities are outlined for each ofthe different roles and are indicated in italics.

3.1 Planning Stage

There are no duties for the roles of Inspector, Reader, or Recorder during thePlanning Stage.


1. I Arrive on time for the Overview Meeting. If you are unable to attend, notify theModerator so that the Overview Meeting can be rescheduled.

2. Ask questions about any parts of the Overview presentation which are unclear.Before the meeting is concluded, you should obtain enough information about theproduct to fulfill your role as Inspector.


1. Look through the Inspection Package to ensure that the following items areincluded:






d) the blank FORMAL INSPECTIONS LESSONS LEARNED form(Optional),

e) the INSPECTION SUMMARY REPORT from the first inspection if thisis a re-inspection,

f) the product being inspected,

g) reference material which may have been submitted by the Author,

h) the appropriate Checklist for the type of inspection,

i) Recorder: the blank INSPECTION DEFECT LIST form,

j) Recorder: a blank INSPECTION DEFECT LIST continuation form.

Obtain any items which are missing from the Inspection Package beforecontinuing.

2. On the INDIVIDUAL PREPARATION LOG form, record the Date PackageReceived and the Approx. # of Formal Inspections Participated in to Date.

3. Look over the product being inspected for organization and understanding.

4. Review the Checklist provided with the Inspection Package.

5. Review the product using the Checklist as a guide to help identify possibleDefects.

6. Refer to the documents listed under the Reference Documents section on theINSPECTION ANNOUNCEMENT for more information and to verify anyspecific references contained in the product.

7. If a portion of the product is unclear or appears to be incorrect, record aDescription of the problem on the INDIVIDUAL PREPARATION LOG.Record the Location of the Defect/Concern and specify if it is a potential MajorDefect, Minor Defect or Open Issue by checking the appropriate box.(Optional: Provide the Suggested Classification by: indicating Missing,Wrong, or Extra; indicating the Type of the Defect/Open Issue from thecategories listed on the provided Checklist; and indicating in the Origin box theproduct in which the Defect/Open Issue probably originated, if other than theproduct being inspected.) If the same Defect appears in multiple locations, youmay record the location in the Location(s) box and record the Defect number



assigned to the first occurrence in the Description box to avoid having torewrite the Description for each occurrence. Defects which are Trivial (notMajor or Minor) such as typographical errors, punctuation, or improvements inverbiage should be marked on the document in red. Trivial Defects are recordedon the work product only, not on the INDIVIDUAL PREPARATION LOG.Trivial Defects that have been recorded on the work product are given to theAuthor after the Inspection Meeting is complete.

8. Repeat steps 5-7 until the review of the product is complete and all concerns havebeen recorded.

9. Record the date and time in person-hours spent on this exercise on theINDIVIDUAL PREPARATION LOG form.

10. Reader: After completing the INDIVIDUAL PREPARATION LOG, reviewthe product again to decide whether to paraphrase or to read the productverbatim. Usually, the only portions of the product which are read verbatim arethose sections containing complicated logic which cannot be relayed adequatelythrough paraphrasing.

11. Reader: Become familiar with the Reference Documents since they may bereferred to during the presentation of the product at the Inspection Meeting.

12. Reader: Record on the INSPECTION PREPARATION LOG the date andtime in person-hours expended on preparing for the Role of Reader.

13. Recorder: At this time you may wish to make a set of abbreviations for the typeof classifications that are on the Checklist. This is done to speed the recordingof the Type on the INSPECTION DEFECT LIST during the InspectionMeeting. (For example: Acc, Clar, Complet, Comply, Comput, etc., for thecorresponding types Accuracy, Clarity, Completeness, Compliance,Computation.)

14. If you are able to complete the Preparation by the time specified in theComments section of the INSPECTION ANNOUNCEMENT, check the boxon the INDIVIDUAL PREPARATION LOG form labeled I am prepared formy role in the inspection. Record your Completion Date and calculate andrecord the Total Hours spent in the Preparation Stage. Return the completedINDIVIDUAL PREPARATION LOG to the Moderator by the time specifiedon the INSPECTION ANNOUNCEMENT. The Moderator will return themto the Inspectors at the Inspection Meeting. If you are unable to complete thePreparation on time, check one of the boxes on the INDIVIDUALPREPARATION LOG form labeled Please reschedule this inspectionbecause I need more preparation time, or Do not reschedule thisinspection, I will be prepared in time for the inspection. If either of theseboxes is



checked, make a copy of the first page of the INDIVIDUAL PREPARATIONLOG and return it to the Moderator by the time specified on the INSPECTIONANNOUNCEMENT.

15. Review the following steps provided in Section 3.4 (Inspection Meeting) beforethe meeting starts.


1. Bring the Inspection Package to the meeting. Also bring your appointment bookso you will know when you are available if Third-Hour Meetings are necessaryas a result of this inspection. (Obtain your original INDIVIDUALPREPARATION LOG from the Moderator.)

2. During the meeting remember the following:

a) the objective of the inspection is to find and classify Defects, not topropose solutions or grade the Author,

b) give the Recorder enough time to write down each Defect/Open Issuebefore continuing with the inspection,

c) discussion of the issue should not exceed 3 minutes,

d) address the Reader or the Moderator when raising issues or askingquestions about the product,

e) be willing to accept the responsibility for resolving/closing any Open Issueswhich may be assigned to you.

3. Reader: Begin the presentation of the product being inspected when instructedto do so by the Moderator. Guide the Team through the product. Present theproduct as you perceive it and note any parts difficult to understand. Be able torelate material back to higher level work products (requirements, designs, etc.)if necessary.

4. As the Reader presents the product being inspected, refer to yourINDIVIDUAL PREPARATION LOG to know when to raise issues ofconcern. Stop the Reader and read aloud the Defect/Concem Description fromyour INDIVIDUAL PREPARATION LOG.

5. If, during the inspection, you discover a new Defect which you did not record



on your INDIVIDUAL PREPARATION LOG, bring it to the attention of therest of the Inspection Team.

6. When another Inspector raises an issue, indicate your agreement or disagreementthat the issue is a Defect.

7. On issues that are agreed to be Defects, provide input on the Location andClassification of the Defect to the Recorder.Recorder: Record the Location, Description and Classification of the Defect onthe INSPECTION DEFECT LIST form. Indicate the product in which theDefect/Open Issue originated, if the origin is other than the product beinginspected. Also record the initials of the finder in the Finder's Initials box incase the Author has questions about the Defect after the Inspection Meeting isover. If the Defect was initially found in the Inspection Meeting, place anasterisk by the finders initials to indicate that the defect was found during themeeting.

8. Recorder: If the Defect is in another document, record the initials of the personassigned with writing a Discrepancy Report/Change Request in the Commentsbox.

9. If the Inspection Team cannot reach an agreement as to whether or not aparticular portion of the product contains a Defect or what the Defect is within 3minutes, an Open Issue will be recorded for that portion of the product.Recorder: Record the Location and Description of the issue and classify it asan Open Issue on the INSPECTION DEFECT LIST form. No furtherclassification is needed at this time for the Open Issue. Record the initials of theperson(s) assigned with resolving the issue in the Comments box. Place anasterisk by the name of the Inspector that the Moderator designates asresponsible for closing the Open Issue if that Inspector is different from theAuthor. Record the initials of the person who raised the Open Issue in theFinder's Initials box.

10. Recorder. Before allowing the inspection to continue, report aloud the NumberAssigned To Defect/Open Issue. Indicate to the Team when you have finishedrecording the issue so the Reader may continue with the presentation of theproduct being inspected.

11. Record the number of the Defect/Open Issue in the Number Assigned toDefect/Open Issue space provided on the INDIVIDUAL PREPARATIONLOG. If the concern which you had recorded on your INDIVIDUALPREPARATION LOG was determined not to be a Defect/Open Issue, place acheckmark in the space provided for the Number Assigned to Defect/OpenIssue. This is to indicate that your concern had been addressed but it wasdetermined not to be a Defect/Open Issue.



12. Reader: Once a Defect/Open Issue is identified, wait for the Recorder to finishwriting down the required information on the INSPECTION DEFECT LISTand for the Inspectors to finish writing the Number Assigned to Defect/OpenIssue before resuming the presentation of the product.

13. The same Defect may appear in multiple locations, however, the Inspectorsshould not list all occurrences of the Defect at once. Each occurrence of theDefect should be identified when the Reader reaches the location of thatoccurrence and not before. This action prevents the Inspectors from skippingback and forth to different locations in the product which disrupts the flow oflogic that the Reader is trying to maintain. In addition, when a Defect identicalto one previously recorded is identified in another location, the Inspectoridentifying the Defect can refer the Recorder back to the specific NumberAssigned to Defect/Open Issue where the Defect was previously recorded.The Recorder need only record the additional Defect location for thepreviously described Defect.

Recorder: Record all additional locations of a Defect on the INSPECTIONDEFECT LIST.

14. Always wait for the Recorder to finish recording the Defect information beforeyou identify another Defect.

15. Repeat steps 3-14 until the entire product is inspected or 2 hours have elapsed.

16. Recorder: Once the entire product has been inspected and all Defects havebeen classified, read aloud each Defect/Open Issue Description on theINSPECTION DEFECT LIST. Make sure that you state the NumberAssigned to Defect/Open Issue so that the other Inspectors can easily locatethe corresponding information on their INDIVIDUAL PREPARATIONLOG.

17. Listen carefully as the Recorder reads the Description of each Defect/OpenIssue and its associated number that has been recorded on the INSPECTIONDEFECT LIST. Point out any discrepancies on the INSPECTION DEFECTLIST. Use the Number Assigned to Defect/Open Issue to help you locate thecorresponding item on your INDIVIDUAL PREPARATION LOG. Verifythat the Recorder recorded each Defect identified on your INDIVIDUALPREPARATION LOG that was found to be a Defect. Verify that those itemsrecorded on the INDIVIDUAL PREPARATION LOG which were found not tobe Defects have been checked off to indicate that they were addressed during themeeting. Any issue which was not addressed in the meeting (does not have anumber or checkmark on the Number Assigned to Defect/Open Issue line)should be raised while the Recorder is reading back the Defects.

18. At the end of the Inspection Meeting you will be asked to comment on the



inspection. You should express your opinion on whether the product needs to beRe-inspected and provide positive comments about the product.

19. The Comments box on the INSPECTION DEFECT LIST indicates whichInspectors are required to resolve Open Issues. Inspectors are only required toattend Third-Hour Meetings for issues to which they were assigned to make themost efficient use of their time. If you were assigned to an Open Issue whichrequires a Third-Hour Meeting to resolve, then indicate the dates and timeswhen you will be available for a Third-Hour Meeting. If the same Inspectors arerequired to resolve several Open Issues, consider grouping those Open Issuesinto one Third-Hour Meeting. If you were assigned the responsibility for closingany Open Issues you must obtain the description of the Open Issue from theINSPECTION DEFECT LIST before leaving the Inspection Meeting.

20. Be sure all your issues have been addressed before leaving the meeting.

21. Turn in your INDIVIDUAL PREPARATION LOG to the Moderator and turnin your copy of the product to the Author if it contains redlines of TrivialDefects.

22. Optional: You are encouraged to make use of the Formal Inspection LessonsLearned Report to inform the Data Manager of your comments, suggestions,or criticisms on the Formal Inspection Process.

23. Recorder: Assist the Moderator in completing the DETAILED INSPECTIONREPORT.

3.5 Third-Hour

1. Work to resolve any Open Issues to which you were assigned. Attend theThird-Hour meetings to which you were assigned. If no Open Issues wererecorded during the Inspection Meeting, proceed to Section 3.6.

2. If you were assigned the responsibility of closing any Open Issues, you mustensure that: the resolution of each Open Issue is relayed to the Moderator (theOPEN ISSUE REPORT form may be used to record the resolution), each openIssue is resolved by the closure date specified in the Comments box on theINSPECTION DEFECT LIST, or if a closure date was not assigned, the issueis closed prior to the Follow-Up Meeting, the times expended by all Inspectorsinvolved in resolving the Open Issues is recorded, and the times are reported tothe Moderator.

3. Complete any Discrepancy Reports/Change Requests assigned to you and


Third Hour 2727

provide the moderator with a copy.

4. Ensure that the resolutions of Open Issues to which the Author was not assignedare communicated to the Moderator and the Author.

5. During this stage, you may suggest solutions for correcting Defects if the Authorrequests your assistance.

6. If requested, assist the Author by providing clarification on Defects which youidentified in the Inspection Meeting.

7. Report to the Moderator any time spent in steps 1 through 6.

3.6 Rework Stage

There are no duties for the roles of Inspector, Reader, or Recorder during the ReworkStage.


There are no duties for the roles of Inspector, Reader, or Recorder during the Follow-Up Meeting.

Author

2828

4.0 Instructions for the Role of AUTHOR

This chapter contains instructions for fulfilling the role of Author. The Author isrequired to participate in all the Formal Inspection stages except for the PreparationStage. Author(s) are not required to inspect their own work product, therefore theycan elect not to perform the Preparation Stage.

4.1 Planning Stage

1 Make sure you have fulfilled all the entrance criteria before submitting the workproduct to the Moderator.

2. When the product is ready for inspection, schedule a meeting with the Moderatorto discuss the product. If a product will not be ready by the date scheduled tobegin the inspection process, notify the Moderator.

3. Inform the Moderator of the Size of Work Product. The Moderator willdetermine if the size of the product is within the prescribed guidelines for thetype of inspection. Refer to Appendix A, (Quick Reference Guide) for guidelineson the optimal number of pages or lines of code to inspect for each type ofinspection.

4. Provide to the Moderator a hard copy of the product and verify that the time,date, and version of each unit is recorded on the submitted product. Provide acopy on electronic media, if available, and ensure that the time, date, and versioninformation matches the information recorded on the hard copy. Remember thatno modifications are to be made without the proper approval to the part of theproduct submitted for inspection until after the Inspection Meeting is completeand the Rework Stage is started.

5. Demonstrate to the Moderator that the entrance criteria have been fulfilled.(Examples: the product conforms to project standards; the document has been runthrough a tool that checks spelling; the code has been successfully compiledwithout errors).

6. Give the Moderator the following information to be recorded on the specifiedform:

Author

Planning Stage 2929

INSPECTION ANNOUNCEMENT form:

a) Scheduled Delivery Date,

b) Size of the Work Product: for documents, the number of pages, thespacing (single, double, diagram), and the font size; for code andpseudo-code, the number of lines and whether that number includescomments and/or blank lines,

c) the percentage information for the Nature of Work,

d) a list of all Reference Documents that may be needed for the inspection.

INSPECTION SUMMARY REPORT form:

a) Approx. Person-Hours Expended (prior to inspection) DevelopingWork Product.

7. Discuss candidates for Inspectors with the Moderator. Assist the Moderator inselecting the Inspection Team members and assigning roles to the Inspectors.Suggestions are given in Appendix E, (Inspection Type and Participants).

8. Assist the Moderator in determining if an Overview Meeting is needed. AnOverview should be scheduled if the Inspectors need background information tosuccessfully fulfill their roles. This situation occurs when the project is new, anovel technique is used in the work product, the Inspectors are new to theproject, inspections are new to the project, or it is the first inspection of aparticular type of work product (Examples: requirements, designs, code, etc.)

9. Provide the Moderator with a tentative date for the Overview which will allowenough time to prepare for the Overview. Refer to Appendix A for guidelines onthe amount of lead time needed to prepare for the Overview.

10. Provide the Moderator with a tentative date for the Inspection Meeting whichwill allow enough time for the Inspectors to prepare for the inspection. Refer toAppendix A for guidelines on the amount of lead time needed to prepare for theInspection Meeting.

11. Provide copies of the Reference Documents needed for the inspection or providea list of relevant sections of the Reference Documents if the documents arealready available to the inspection team members.

12. Provide the Moderator with the time in person-hours expended by you during

Author

30 Planning Stage30

the Planning Stage.


1. Prepare the necessary materials for the Overview if one was scheduled. Notify theModerator if more time is needed.

2. Arrive early for the meeting to set up any needed equipment.

3. Once the Moderator has introduced you, present the background informationneeded by the Inspectors.

4. Be prepared to answer any questions that may arise.

5. Provide the Moderator with the number of hours spent preparing for theOverview.


The Preparation Stage is optional for the Author(s). If the Author(s) choose to inspecttheir own product, they should follow the steps outlined in Section 3.3 (PreparationStage).


In addition to the steps contained in this section, the Author should follow the stepsoutlined in the Section 3.4 (Inspection Meeting). Those steps, as well as the stepscontained in this section, should be reviewed before the Inspection Meeting begins.

1. Provide answers and clarification to questions that arise during the meeting.

2. Collect from the Inspectors all copies of the work product which contain redlinesof Trivial Defects after the meeting is over.

3. Once the inspection is complete, provide the Moderator with the EstimatedPerson-Hours for Rework, Estimated Rework Completion Date, and atentative Scheduled Follow-Up Date. The Estimated Rework Completion Dateshould be within the suggested guidelines provided in Appendix A so thatsubsequent development efforts are not delayed.

4. Make sure you obtain a copy of the INSPECTION DEFECT LIST before

Author


leaving the meeting.

4.5 Third-Hour

1. Work to resolve any Open Issues to which the you were assigned. Attend theThird-Hour meetings to which you were assigned.

2. If you were assigned the responsibility of closing any Open Issues, you mustensure that: the resolution of each Open Issue is relayed to the Moderator (theOPEN ISSUE REPORT form may be used to record the resolution), each OpenIssue is resolved by the closure date specified in the Comments box on theINSPECTION DEFECT LIST, or if a closure date was not assigned, the issueis closed prior to the Follow-Up Meeting, the times expended by all Inspectorsinvolved in resolving the Open Issues is recorded, and the times are reported tothe Moderator.

3. Complete any Discrepancy Reports/Change Requests assigned to you and providethe Moderator with a copy.

4. Obtain from the Moderator the resolution of any Open Issues to which you werenot assigned.

5. During this stage, you may request assistance in correcting Defects.

6. If you require clarification on a Defect, request assistance from the Inspectorwhose initials appear in the Finders Initials box on the INSPECTIONDEFECT LIST.

7. Work with the Moderator to obtain a Waiver from the Manager for anyunaddressed Open Issue.

8. Work with the Moderator to obtain a Waiver from the Manager for any MajorDefect which will not be corrected by the Follow-Up Meeting.

9. Track all time in person-hours expended during the Third-Hour activities so thatit can be reported to the Moderator at the Follow-Up Meeting.

4.6 Rework Stage

1. Track all time in person-hours expended during the Rework stage so that it can bereported to the Moderator at the Follow-Up Meeting.

Author

32 Rework Stage32

2. Correct all Major Defects and Open Issues determined to be Major Defects.Verify that no new Defects were inserted in the correction process.

3. Correct Minor Defects and Trivial Defects as cost and schedule allow. Verify thatno new Defects were inserted in the correction process.

4. Indicate the Location of Correction(s) on the INSPECTION DEFECT LISTonly if the location of the correction is different from the location of the Defect.

5. Communicate to the Moderator that the Rework will be complete by theEstimated Rework Completion Date recorded on the INSPECTIONDEFECT LIST. If the Rework will not be complete by the ScheduledFollowUp Date, inform the Moderator.

6. Record any new defects discovered during the Third-Hour or Rework stages onthe INSPECTION DEFECT LIST.

7. Ensure that the reworked product meets the entrance criteria (standards,automatic checking, etc.)

8. Prior to the Scheduled Follow-Up Date check with the Moderator to schedule atime and location for the Follow-Up Meeting.


1. Provide the Moderator with a hard copy of the corrected work product andrecord the time, date, and version of each unit on the submitted work product.Provide a copy on electronic media, if available, and ensure that the time, date,and version information matches the information recorded on the hard copy.

2. Verify to the Moderator that the reworked product meets the entrance criteria.

3. Give the Moderator the completed INSPECTION DEFECT LIST, all OPENISSUE REPORTS, and a copy of any Waivers obtained.

4. Provide the Moderator with the time in person-hours expended during theThird-Hour Meetings and the Rework Stage. Provide the Moderator with theActual Rework Completion Date.

5. If requested, provide the Moderator with assistance in the process of verifying thecorrections.

Appendix A: Quick Reference Guide

Appendix B: Forms with Instructions

B.1 Required Forms

The forms contained in this section are required to be completed during the Formal Inspectionprocess.

Inspection ID # ______________________________

INSPECTION ANNOUNCEMENT

Project:Subsystem:Unit(s) or Section(s) / Version:

Distribution Date: Scheduled Delivery Date*:Change Authorization(s):

Is this a Re-inspection? NoYes, Reason:

Inspector's Name

Revision B 4/1992 LaRCRevision E 11/1991 JPL

Overview MeetingDate:Time:Place:

Inspection MeetingDate:Time:Place:

Mail Stop/Phone Role Area of Expertise

Distribution:

Moderator

Recorder

Reader

Inspector

Inspector

Inspector

Inspector

Inspector

Inspection Type:SY:

SU:

R0:

I0:

I1:

I2:

IT1:

IT2:

Other:

Size of Work Product*:

Nature of Work*: New: ____% Modified: ____% Reused: ____% Deleted: ____%

Reference Documents*:

Comments:

R1:

(This form is completed by the Moderator, except for: *Moderator and Author.)

1

2 3

4

5

6

7

8

9

10

11 12

13

14

15

16

Inspector

System Requirements

Subsystem Requirements

Functional Design

Architectural/Preliminary Design

Detailed Design

Source Code

Test Plan

Test Procedures and Functions

Software Requirements

INSTRUCTIONS FOR THE INSPECTION ANNOUNCEMENT FORM

1 Unique Inspection ID assigned by the Data Manager during the Planning Stage prior to distributing theInspection Packages.

2 Date, time, and place of the Overview Meeting if one is scheduled.

3 Date, time, and place of the Inspection Meeting

4 Date that the Inspection Package is distributed to each Inspector.

5 Title or acronym of the project for which the product is being produced.

6 Title or acronym of the subsystem for which the product is being produced.

7 Name(s) or acronym(s) and version number(s) of the unit(s) or section(s) of a document being inspected. Botha hard and soft copy should be submitted for inspection and both should have the same version number.

8 Delivery date of the product being inspected according to the schedule.

9 If applicable, list the name(s) of the person(s) who can authorize changes on the product being inspected.

10 Check the appropriate box to indicate whether this is a re-inspection. If "Yes", indicate the reason for there-inspection in the space provided. (For example, a large number of Major Defects, a large number of Open Issues, portionsof the product contained To Be Determined (TBD) sections during the first inspection.)

11 Indicate the name, mail stop, and phone number of all Inspectors according to their role in the InspectionMeeting. List the Author as an Inspector. Also indicate the Area(s) of Expertise each Inspector representsfrom the following categories:

Project EngineeringSystem EngineeringH/W DevelopmentS/W DevelopmentUser/Customer

TestingQuality AssuranceOperationsScience TeamOther

12 Check the appropriate box or record the Inspection Type in the space provided.

13 Size of the work product being inspected using one of the following methods:

Pages (PG) - indicate whether double-spaced, single-spaced, or drawings; also font size if known;Pseudo Lines of Code (PLOC) - indicate whether this number includes comment lines and/or blank lines;Source Lines of Code (SLOC) - indicate whether this number includes comment lines and/or blank lines.

14 Indicate what percent of the product being inspected is New, Modified, Reused, and Deleted. Should total to 100percent.

15 List all Reference Documents either included in the Inspection Package or available for more information on theproduct being inspected. Indicate where these documents can be found.

16 Include any additional comments that may be helpful to the Inspectors. (For example, indicate the date and time thatthe INDIVIDUAL PREPARATION LOG form should be returned to the Moderator.

Inspection ID # _____________________________

INDIVIDUAL PREPARATION LOG

Date Package Received:Completion Date:

Inspector's Name:Approx. # of Inspections Participated in to Date:

Preparation Log: Date Time Expended

DEFECTS/CONCERNSTotal Hours:

The Moderator needs to receive a copy of this form at least 4 hours before the scheduled Inspection Meeting.Please return in a timely manner with the appropriate box checked below.

I am prepared for my role in the inspection.

Please reschedule this inspection because I need more preparation time.

Do not reschedule this inspection, I will be prepared in time for the inspection.

Revision B 4/1992 LaRCRevision E 11/1989 JPL (This form is completed by each Inspector.)

# Location(s) Description Suggested Classification

1

Number Assigned to Defect / Open Issue: ____

2

3



Major DefectMinor DefectOpen IssueType

MissingWrongExtraOrigin





4




1

11

2

3

4

5

6

7 8 9 10

12

12

12

12

Page ____ of ____13

1

INSTRUCTIONS FOR THE INDIVIDUAL PREPARATION LOG FORM

1 Unique Inspection ID assigned by the Data Manager during the Planning Stage prior to distributingthe Inspection Packages.

2 Name of the Inspector.

3 Approximate number of Formal Inspections that the Inspector has participated in prior to thisinspection.

4 Date that the Inspector received the Inspection Package.

5 Date that the Inspector completes the INDIVIDUAL PREPARATION LOG form.

6 Date and time expended in "X.X" person-hours each time the Inspector reviews the product or areference document. Once completed, indicate the total hours expended in the Preparation Stage forthis inspection. (Note: "X.X" refers to the fractional number that specifies the hours and minuteswhich were expended in this activity.)

7 Number of the Defect/Concern in sequential order.

8 Location of the Defect/Concern in the product.

9 Brief description of the Defect/Concern.

10 Give suggestions for the classification of the Defect/Concern. Classify it as either a potential MajorDefect, Minor Defect, or Open Issue. Optional: classify it as Missing, Wrong, or Extra; indicate thetype of the Defect/Open Issue from the categories listed on the provided Checklist; and indicate theproduct in which the Defect/Open Issue probably originated if other than the product beinginspected.

11 Return a copy of this form to the Moderator at least 4 hours prior to the Inspection Meeting or bythe time indicated by the Moderator on the INSPECTION ANNOUNCEMENT form. Check one ofthe three boxes provided.

12 During the Inspection Meeting, if a Defect/Concern on this form is determined to be a Defect/OpenIssue, specify the number which the recorder assigns to that particular Defect/Open Issue.

13 Record the page number of this page and the total number of INDIVIDUAL PREPARATIONLOG form pages.

DEFECTS/CONCERNS#

Page ____ of ____

INDIVIDUAL PREPARATION LOG (cont'd)


Location(s) Description Suggested Classification






















(This form is completed by each Inspector.)

10987

13

12

12

12

12

12

12

12

Inspection ID # _____________________________1

INSTRUCTIONS FOR THE INDIVIDUAL PREPARATION LOG FORM


2 Name of the Inspector.

3 Approximate number of Formal Inspections that the Inspector has participated in prior to thisinspection.

4 Date that the Inspector received the Inspection Package.

5 Date that the Inspector completes the INDIVIDUAL PREPARATION LOG form.

6 Date and time expended in "X.X" person-hours each time the Inspector reviews the product or areference document. Once completed, indicate the total hours expended in the Preparation Stage forthis inspection. (Note: "X.X" refers to the fractional number that specifies the hours and minuteswhich were expended in this activity.)

7 Number of the Defect/Concern in sequential order.

8 Location of the Defect/Concern in the product.

9 Brief description of the Defect/Concern.

10 Give suggestions for the classification of the Defect/Concern. Classify it as either a potential MajorDefect, Minor Defect, or Open Issue. Optional: classify it as Missing, Wrong, or Extra; indicate thetype of the Defect/Open Issue from the categories listed on the provided Checklist; and indicate theproduct in which the Defect/Open Issue probably originated if other than the product beinginspected.

11 Return a copy of this form to the Moderator at least 4 hours prior to the Inspection Meeting or bythe time indicated by the Moderator on the INSPECTION ANNOUNCEMENT form. Check one ofthe three boxes provided.

12 During the Inspection Meeting, if a Defect/Concern on this form is determined to be a Defect/OpenIssue, specify the number which the recorder assigns to that particular Defect/Open Issue.

13 Record the page number of this page and the total number of INDIVIDUAL PREPARATIONLOG form pages.

Inspection ID #

INSPECTION DEFECT LIST

Estimated Rework Completion Date*: Actual Rework Completion Date*:

Scheduled Follow-Up Date*:Estimated Person-Hours for Rework*:



Description# Location(s)Finder's Initials Classification

Location ofCorrection(s) ***

Comments

1

Corrected**

2

3

4

(This form is completed by the Recorder, except for: *Moderator and Author **Moderator only ***Author only)








1

3 5

4

5 Major DefectMinor DefectOpen IssueType


2

6 7 8

9

10

13

1411

Page ____ of ____12

1

INSTRUCTIONS FOR THE INSPECTION DEFECT LIST FORM

1 Unique Inspection ID assigned by the Data Manager during the Planning Stage prior to distributing the Inspection Packages.

After the Inspection Meeting -

2 The Author(s) reports to the Moderator the total time in "X.X" person-hours estimated for Rework.

3 The Author(s) reports to the Moderator the estimated Rework completion date.

4 Date scheduled between the Author(s) and the Moderator for the Follow-Up Meeting to review the corrections made to the product by the Author(s) during theRework Stage.

After completion of the Rework -

5 Date the Rework is completed by the Author(s). The completion date is revised if the Moderator returns the product to the Author(s) for further Rework.

During the Inspection Meeting. For each Defect/0pen Issue identified -

6 Number of the Defect/Open Issue in sequential order.7 Location of the Defect/Open Issue in the product.8 Concise description of the Defect/Open Issue.9 Initials of the Inspector who raised the Defect/Open Issue in the meeting. If the error was initially found in the meeting, place an asterisk by the finders initials toindicate that the defect was found during the meeting.10 Classify the Defect/Open Issue in each of the following categories:

- Major Defect, Minor Defect, or Open Issue;- Missing, Wrong, or Extra;- Type of the Defect/Open Issue from the categories listed on the provided Checklist;- Product in which the Defect/Open Issue originated if other than the product being inspected.

(Note: When the Open Issues are resolved, this block should be updated to reflect the Classification of any Open Issue which was determined to be a Defect.)

11 The initials of the persons required to close an Open Issue are listed in this box. An asterisk is placed beside the name of the person responsible forclosure/resolution if that person is not the Author. Specify the date by which a recorded Open Issue must be closed and once it is closed record the resolution of theissue. If more room is needed use an OPEN ISSUES REPORT form. This box is also used to indicate non-routine circumstances, waivers, action item results, Defectswhich require extra time to correct, etc.12 Record the page number of this page during the meeting and record the total number of INSPECTION DEFECT LIST pages once the meeting is complete.

During the Rework and Follow-Up stage: For each Defect identified -

13 During the Rework Stage, the Author should indicate the location of all corrections in the product.

14 During the Follow-Up Stage, the Moderator, or the Moderator's designee, should indicate that the Defect was properly "Corrected" by placing a check in the box.

Inspection ID # Page ____ of ____

INSPECTION DEFECT LIST (cont'd)

Description# Location(s)Finder's Initials Classification

Location ofCorrection(s) ***

Comments Corrected**














112

11 14

13

10

9

876

(This form is completed by the Recorder, except for: *Moderator and Author **Moderator only ***Author only)

INSTRUCTIONS FOR THE INSPECTION DEFECT LIST FORM


After the Inspection Meeting -

2 The Author(s) reports to the Moderator the total time in "X.X" person-hours estimated for Rework.

3 The Author(s) reports to the Moderator the estimated Rework completion date.

4 Date scheduled between the Author(s) and the Moderator for the Follow-Up Meeting to review the corrections made to the product by the Author(s) during theRework Stage.

After completion of the Rework -

5 Date the Rework is completed by the Author(s). The completion date is revised if the Moderator returns the product to the Author(s) for further Rework.

During the Inspection Meeting. For each Defect/0pen Issue identified -

6 Number of the Defect/Open Issue in sequential order.7 Location of the Defect/Open Issue in the product.8 Concise description of the Defect/Open Issue.9 Initials of the Inspector who raised the Defect/Open Issue in the meeting. If the error was initially found in the meeting, place an asterisk by the finders initials toindicate that the defect was found during the meeting.10 Classify the Defect/Open Issue in each of the following categories:

- Major Defect, Minor Defect, or Open Issue;- Missing, Wrong, or Extra;- Type of the Defect/Open Issue from the categories listed on the provided Checklist;- Product in which the Defect/Open Issue originated if other than the product being inspected.

(Note: When the Open Issues are resolved, this block should be updated to reflect the Classification of any Open Issue which was determined to be a Defect.)

11 The initials of the persons required to close an Open Issue are listed in this box. An asterisk is placed beside the name of the person responsible forclosure/resolution if that person is not the Author. Specify the date by which a recorded Open Issue must be closed and once it is closed record the resolution of theissue. If more room is needed use an OPEN ISSUES REPORT form. This box is also used to indicate non-routine circumstances, waivers, action item results, Defectswhich require extra time to correct, etc.12 Record the page number of this page during the meeting and record the total number of INSPECTION DEFECT LIST pages once the meeting is complete.

During the Rework and Follow-Up stage: For each Defect identified -

13 During the Rework Stage, the Author should indicate the location of all corrections in the product.

14 During the Follow-Up Stage, the Moderator, or the Moderator's designee, should indicate that the Defect was properly "Corrected" by placing a check in the box.

Inspection ID # _________________________________________

DETAILED INSPECTION REPORTData Manager:

Defects found in Inspected Product:

Revision E 11/1989 JPLRevision B 4/1992 LaRC

(This form is completed by the Moderator.)

ClarityCompletenessCompliance

ConsistencyCorrectnessData Usage

FunctionalityInterfaceLevel of DetailMaintainability

PerformanceReliabilityTestabilityTraceabilityOther

Total Identified

Checklist Defect Types Total

Major MinorMissing Wrong Extra

P. Schuler, MS 125A

Accuracy

Computation

Feasibility

Modularity

Fault Tolerance

1

2

3

4

5

Missing Wrong Extra

INSTRUCTIONS FOR THE DETAILED INSPECTION REPORT FORM

Immediately after the Inspection Meeting -


2 Name and mail stop of the Data Manager responsible for collecting the Formal Inspection statistics.

3 For each Defect on the INSPECTION DEFECT LIST form, place a mark in the proper column according to the classification of theDefect on that form. Each Defect should be classified as Major or Minor; as Missing, Wrong, or Extra; and by Type.

4 Total number of Defects for each Checklist Defect Type.

5 Total number of Defects recorded under each column.

During Follow-Up

The moderator should update this form to reflect each Open Issue which was determined to be a Defect.

INSPECTION SUMMARY REPORTInspection ID # _________________________________________

Inspection Meeting Date:Follow-Up Completion Date:Project Start Date:

Planning Start Date: # Participants: Meeting Length:

Total Time Expended in Person-Hours

Inspectors

Author(s)

Moderator

Planning ReworkMeetingPreparationOverview TotalFollow-UpThird-Hour Number of Representatives from Each Area:

Project Office:Systems Engineering:H/W Development:S/W Development:User/Customer:

Testing:Quality Assurance:Operations:Science Team:Other:

Defects Reworked: # Major: ____ # Minor: ____ # Closed Found to be Defects: # Closed Found Not to be Defects:

Comments:

Data Manager:

Discrepancy Reports/Change Requests/Waivers:STATUS: PASS RE-INSPECTION REQUIRED

Re-inspection Target Date: ________________

Moderator's Signature

Revision B 4/1992 LaRCRevision E 11/1989 JPL (This form is completed by the Moderator and submitted to the Data Manager and, if applicable, the Project QA Representative after Follow-Up has been completed.)

P. Schuler, MS 125A

Defects Found: # Major: ____ # Minor: ____

Approx. Person-Hours Expended (prior to inspection) Developing Work Product:

Open Issues: # Identified: ___ # Closed: _____

1

2

3

4

5

6

7

8

9

10

11

12 13 14

15

16

17

18

INSTRUCTIONS FOR THE INSPECTION SUMMARY REPORT FORM1 Unique Inspection ID assigned by the Data Manager during (the Planning Stage prior to distributing the Inspection Packages.

2 Date that the Planning process was initiated.

3 Date of the Inspection Meeting.

4 Approximate time expended in person-hours by the Author(s) in developing the work product, or parts of the work product, under inspection.

Note: If this is a re-inspection, this number should not have changed from the number of hours reported at the first inspection since Rework time is separate from Development

time.

5 Total number of participants including the Author(s) and all Inspectors.

6 Length of the Inspection Meeting in “X.X” hours.

7 Date that the Follow-Up Stage was completed.

8 was awarded.


10 Total time expended in “X.X” person-hours by all Inspectors in each stage of the inspection process.

Note: The times for the Author(s) and the Moderator are tracked separate from the other inspection participants.

11 Number of Representatives from each area of expertise. Include the Author's expertise. This may be a fractional number if one Inspector represents multiple areas. However,

the total number of representatives must equal the number of inspection participants listed under #5.

12 Total number of Major and Minor Defects found in the product being inspected. These totals should include the number of Open Issues which were determined to be

Defects.

13 Total number of Major and Minor Defects corrected during the Rework Stage. All Major Defects shall be corrected. A waiver shall be obtained and recorded under #16 for

each Major Defect which is not corrected.

14 Total number of Open Issues identified in the product during the Inspection Meeting prior to the Third-Hour and Follow-Up stages.

Total number of Open Issues closed (resolved) after the Inspection Meeting.

Total number of resolved Open Issues that were determined to be Defects.

Total number of resolved Open Issues that were determined not to be Defects.

Note: A waiver should be obtained and recorded under #16 for each Open Issue which has not been addressed.

15 Include any additional comments that may be helpful to the Data Manager.

16 Provide a brief description of any Discrepancy Reports/Change Requests/Waivers generated and their associated Defect/Open Issue number from the INSPECTION

DEFECT LIST form. Waivers should be obtained for Major Defects not corrected and for Open Issues which have not been addressed.

17 Check the appropriate box to indicate whether the product is now "Inspection Certified" (Pass) or a re-inspection is required. If a re-inspection is required, indicate a target

date for the Re-inspection Meeting.

18 Moderator's signature indicating the completion of the inspection process

B.2 Optional Forms

The forms contained in this section are optional. The purpose and use of the forms isdiscussed in the following text.

OPEN ISSUE REPORT:This form is used to record the resolution and the action taken to resolve Open Issues. It isused if the Comments box on the INSPECTION DEFECT LIST does not provide enoughspace for recording the appropriate information. It can also be used to record solutions whichwere identified during the Third-Hour Meeting.

FORMAL INSPECTIONS LESSONS LEARNED REPORT :This form is used to provide comments that may be helpful in improving the FormalInspection process.

MANAGEMENT INSPECTION SUMMARY REPORT :This form is used to give Managers visibility into Formal Inspection progress and status on aspecific project subsystem. It can be a useful part of the project Risk Management Programsince it brings to management's attention statistics concerning: the number of DiscrepancyReports/Change Requests/Waivers, the number of Open Issues that have not been closed,and the number of Major Defects that have not been corrected.

TEST REPORT:This form is used to record and track the correction of Errors discovered during testing orafter delivery. The Form also contains valuable statistics that are used for processimprovement, causal analysis, evaluating the effectiveness of Formal Inspections, andproviding data for estimating testing time on future projects.

FINAL COMPLETION REPORT:This form provides information on the total time spent developing the product andperforming inspections. It also provides information on the percentage of the product whichwas inspected, data on the total number of Defects which were not corrected before deliveryas well as the number of Errors identified after delivery. This form is useful in determiningthe effectiveness of the Formal Inspections process and the quality of delivered productsbased on the number of Errors discovered after delivery.

Inspection ID # _____________________________

OPEN ISSUE REPORT

Number which was assigned to the Open Issue on the INSPECTION DEFECT LIST form:

Issue Raised By:

Description:

Assigned to:

Estimated Closure Date:

Total Person-Hours Expended for Resolution:

Actual Closure Date:

Third-Hour MeetingDate:

Place:Time:

Action Taken / Resolution:

Revision B 4/1992 LaRC (This form is completed by the Recorder and the person responsible for Closure and a copy is returned to the Author and Moderator.)*Place the name of the person responsible for Closure on this line.

*

(optional)

1

2

3

4

5

6 7

9

8

10

Inspector's Time:_____ Author's Time:_____ Moderator's Time:_____

INSTRUCTIONS FOR THE OPEN ISSUE REPORT FORM


2 Number which was assigned to the Open Issue on the INSPECTION DEFECT LIST form.

3 Name of the Inspector who raised the Open Issue in the Inspection Meeting.

4 Clear description of the Open Issue.

5 Name(s) of the person(s) assigned to resolving the Open Issue. The name of the person responsiblefor closing the Open Issue should be placed on the first line by the asterisk (*)

6 Estimated date for closure of the Open Issue.

7 Actual date for closure of the Open Issue.

8 Date, time, and place of the Third-Hour Meeting for resolving this Open Issue if a meeting isneeded.

9 Brief description of the final resolution of the Open Issue and any actions taken to bring it toclosure (such as writing a change request to a higher level document).Note: If the Open Issue is determined to be a Defect, then the Classification of the Defect should berecorded on the INSPECTION DEFECT LIST form.

10 Total time expended in "X.X" person-hours, by the Inspector(s), Author(s), and Moderator, toresolve the Open Issue.

Inspection ID # ____________________________

FORMAL INSPECTIONS LESSONS LEARNED REPORT

Area of Expertise:

Submitter: Data Manager:

Inspection Type:

Revision B 4/1992 LaRC (This form is completed by any Inspector and submitted to the Data Manager.)

Comments:

Project Office

Systems Engineering

H/W Development

S/W Development

User/Customer

Testing

Quality Assurance

Operations

Science Team

Other:

Stage of Inspection:Planning

Overview

Preparation

Inspection Meeting

Third-Hour

Rework

Follow-Up

Suggested topics to be considered:

- Unique approaches for methods, practices, and standards- Useful management planning and control techniques- Major problem areas and how resolution was attained; identification of unresolved problems- Successful aspects and shortcomings of the inspection process- Recommendation for future applications

P. Schuler, MS 125A

(optional)

1

2 3

4

56

7

SY:

SU:

R0:

I0:

I1:

I2:

IT1:

IT2:

Other:

R1:

System Requirements

Subsystem Requirements

Functional Design

Architectural/Preliminary Design

Detailed Design

Source Code

Test Plan

Test Procedures and Functions

Software Requirements

INSTRUCTIONS FOR THE FORMAL INSPECTIONS LESSONS LEARNEDREPORT FORM


2 Name and phone number of the person submitting the form.


4 Check the appropriate box or record in the space provided your Area of Expertise.

5 If the comments pertain to a particular inspection type, then check the appropriate box or record inthe space provided the Inspection Type.

6 If the comments pertain to a particular stage of the inspection process, then check the appropriatebox for the Stage of Inspection. Otherwise, leave this section blank.

7 Include all comments that may be helpful in improving the Formal Inspection Process.

MANAGEMENT INSPECTION SUMMARY REPORT

Project:Subsystem:

Inspection ID #

PG/PLOC/ SLOC

Inspection Type

Inspection Status

Complete In Progress

If Inspection Process Complete

# Inspection Meetings

% Defects Fixed

Major Minor Total

# Person-Hours

Fix TotalDetect

Hours Within Current Guidelines?

Comments:

Data Mgr.:

Revision B 4/1992 LaRCRevision E 11/1989 JPL (This form is completed by the Moderator.)

Discrepancy Reports/Change Requests/Waivers:

P. Schuler, MS 125A

# Closed Found to be Defects: # Closed Found Not to be Defects:

Open Issues: # Identified: ___ # Closed: _____

(optional)1

2

3

4 5 6 78

9 10 11

12

13

14

Page ____ of ____15 1

INSTRUCTIONS FOR THE MANAGEMENT INSPECTION SUMMARY REPORT FORM

1 Title or acronym of the project for which the report is being produced.

2 Title or acronym of the subsystem for which the report is being produced.


4 Unique Inspection ID assigned to each work product, or portion of work product, which has entered the inspection process.

5 Size of the work product, or portion of work product, given in Pages (PG), Pseudo Lines of Code (PLOC), or Source Lines of Code (SLOC).

6 Inspection Type according to one of the following categories:SY: System RequirementsSU: Subsystem RequirementsRO: Functional DesignRI: Software RequirementsI0: Architectural/Preliminary Design

I1: Detailed DesignI2: Source CodeFTI: Test PlanIT2: Test Procedures and FunctionsOther

7 Check the appropriate status box to indicate whether the inspection is Complete or In Progress.

8 Total number of Inspection Meetings held for the work product to date. Overview and Third-Hour Meetings are not included in this number.

9 Percent of the Major Defects that were fixed, percent of the Minor Defects that were fixed, and percent of the total number of Defects that were fixed.Note: If the percent of Major Defects fixed is not 100% then list the waivers that were obtained for those defects not fixed under #14.

10 Total time expended in "X.X' person-hours to detect Defects, to fix Defects, and the total to detect and fix Defects. These numbers should come from the INSPECTIONSUMMARY REPORT form Item #10 under the following stages:

Detect - Planning, Overview, Preparation, and MeetingFix - Rework, Third-Hour, and Follow-UpTotal - Detect and Fix.

11 Indicate whether the total person-hours to detect and fix is within the guidelines provided in the Estimated Timing Schedule section of the current version of the "QuickReference Guide"

12 Total number of Open Issues identified in the product during the Inspection Meetings prior to the Third-Hour and Follow-Up stages.Total number of Open Issues closed (resolved) after the Inspection Meeting.Total number of resolved Open Issues that were determined to be Defects.Total number of resolved Open Issues that were determined not to be Defects.Note: A waiver should have been obtained and should be listed under #14 for each Open Issue which has not been closed (resolved).

13 Include any additional comments that may be helpful to the Manager.

14 Provide a brief description of any Discrepancy Reports/Change Requests/Waivers generated and their associated Defect/Open issue number from die INSPECTIONDEFECT LIST form. Waivers should be obtained for Major Defects not Reworked and unresolved Open Issues.

15 Record the page number of this page and the total number of MANAGEMENT INSPECTION SUMMARY pages.

Note: The Data Manager can generate this form automatically with all items completed, except for #7 In Progress, from the information stored in the data base.

MANAGEMENT INSPECTION SUMMARY REPORT (cont'd)

If Inspection Process Complete

Revision B 4/1992 LaRCRevision E 11/1989 JPL (This form is completed by the Moderator.)

Page ____ of ____

4 5 6 78

9 10 11

15

(optional)

Inspection ID #

PG/PLOC/ SLOC

Inspection Type

Inspection Status

Complete In Progress

# Inspection Meetings

% Defects Fixed

Major Minor Total

# Person-Hours

Fix TotalDetect

Hours Within Current Guidelines?

INSTRUCTIONS FOR THE MANAGEMENT INSPECTION SUMMARY REPORT FORM




4 Unique Inspection ID assigned to each work product, or portion of work product, which has entered the inspection process.

9 Size of the work product, or portion of work product, given in Pages (PG), Pseudo Lines of Code (PLOC), or Source Lines of Code (SLOC).

10 Inspection Type according to one of the following categories:SY: System RequirementsSU: Subsystem RequirementsRO: Functional DesignRI: Software RequirementsI0: Architectural/Preliminary Design

I1: Detailed DesignI2: Source CodeFTI: Test PlanIT2: Test Procedures and FunctionsOther

11 Check the appropriate status box to indicate whether the inspection is Complete or In Progress.

12 Total number of Inspection Meetings held for the work product to date. Overview and Third-Hour Meetings are not included in this number.

16 Percent of the Major Defects that were fixed, percent of the Minor Defects that were fixed, and percent of the total number of Defects that were fixed.Note: If the percent of Major Defects fixed is not 100% then list the waivers that were obtained for those defects not fixed under #14.

17 Total time expended in "X.X' person-hours to detect Defects, to fix Defects, and the total to detect and fix Defects. These numbers should come from the INSPECTIONSUMMARY REPORT form Item #10 under the following stages:

Detect - Planning, Overview, Preparation, and MeetingFix - Rework, Third-Hour, and Follow-UpTotal - Detect and Fix.

18 Indicate whether the total person-hours to detect and fix is within the guidelines provided in the Estimated Timing Schedule section of the current version of the "QuickReference Guide"

19 Total number of Open Issues identified in the product during the Inspection Meetings prior to the Third-Hour and Follow-Up stages.Total number of Open Issues closed (resolved) after the Inspection Meeting.Total number of resolved Open Issues that were determined to be Defects.Total number of resolved Open Issues that were determined not to be Defects.Note: A waiver should have been obtained and should be listed under #14 for each Open Issue which has not been closed (resolved).

20 Include any additional comments that may be helpful to the Manager.

21 Provide a brief description of any Discrepancy Reports/Change Requests/Waivers generated and their associated Defect/Open issue number from die INSPECTIONDEFECT LIST form. Waivers should be obtained for Major Defects not Reworked and unresolved Open Issues.

22 Record the page number of this page and the total number of MANAGEMENT INSPECTION SUMMARY pages.

Note: The Data Manager can generate this form automatically with all items completed, except for #7 In Progress, from the information stored in the data base.

TEST REPORT

Project:

Subsystem:

Unit(s) or Section(s) / Version:

Name of Tester: Date:

Type of Test Phase: Unit Test Integration Test Acceptance Test Testing After Delivery Due to Problem Report

Other Test:

Total Number of Errors Discovered During Testing: _______Total Hours Spent Testing: _______

#

1

2

3

4

*If error was identified by the Customer/User place a "C" in the box and if it was identified by the Tester place a "T" in the box.

Revision B 4/1992 LaRC

**Specify the Product in which the Error Originated.

(This form is completed by the Tester, except for : ***Author / Developer. This form is returned to the Moderator after the test phase is completed.)

Data Manager:

Date, Brief Description, and Error Type Discovered By*

Hours toFind / Fix Origin** Speculation as to why Error was not found previously

Re-inspected? Yes No, why?




P. Schuler, MS 125A

(optional)

***

***

***

***

1

2

3

7

4

5

6

8 9

10 11 12 1314 15

16

16

16

16

Page ____ of ____17 1

/

/

/

/

INSTRUCTIONS FOR THE TEST REPORT FORM



3 Name(s) or acronym(s) and version number(s) of the unit(s) or section(s) of a document being tested.

4 Name of the Tester conducting the test.


6 Date that the testing activity began.

7 Check the appropriate box to indicate the type of test being conducted.

8 Total time expended in "X.X" person-hours to conduct the test activity.

9 Total number of Errors which were discovered during the testing activity.

10 Number of the Error in sequential order.

11 Record the date that the Error was discovered, a brief description of the Error and determine the type of Error from the Checklist Defect Types listed on the DETAILEDINSPECTION REPORT form.

12 Place a "C" in the box to indicate that the Error was originally discovered by the customer or place a "T" in the box to indicate that the Error was discovered by a Tester.

13 Total time expended in "X.X" person-hours to find the origin of the observed Error and the time to fix the Error.

14 The Tester or Author/Developer should specify the product in which the Error originated (such as the Requirements Document, Design Document, or Code).

15 The Tester or Author/Developer should speculate as to why the Error was not found previously.

16 Check the appropriate box to indicate whether the product was re-inspected after the Error was corrected. If "No", indicate the reason the product was not re-inspected.

17 Record the page number of this page and record the total number of TEST REPORT form pages.

Note: Errors in the testing activities equate to Defects in the inspection activities

TEST REPORT (cont'd)

# Date, Brief Description, and Error TypeDiscovered By*

Hours toFind / Fix Origin** Speculation as to why Error was not found previously

Page ____ of ____






*If error was identified by the Customer/User place a "C" in the box and if it was identified by the Tester place a "T" in the box.

Revision B 4/1992 LaRC

**Specify the Product in which the Error Originated.

***

***

***

***

***

16

16

16

16

16

17

10 1112 13

14 15

(optional)

(This form is completed by the Tester, except for : ***Author / Developer. This form is returned to the Moderator after the test phase is completed.)

/

/

/

/

/

INSTRUCTIONS FOR THE TEST REPORT FORM



6 Name(s) or acronym(s) and version number(s) of the unit(s) or section(s) of a document being tested.

6 Name of the Tester conducting the test.


7 Date that the testing activity began.

8 Check the appropriate box to indicate the type of test being conducted.

18 Total time expended in "X.X" person-hours to conduct the test activity.

19 Total number of Errors which were discovered during the testing activity.

20 Number of the Error in sequential order.

21 Record the date that the Error was discovered, a brief description of the Error and determine the type of Error from the Checklist Defect Types listed on theDETAILED INSPECTION REPORT form.

22 Place a "C" in the box to indicate that the Error was originally discovered by the customer or place a "T" in the box to indicate that the Error wasdiscovered by a Tester.

23 Total time expended in "X.X" person-hours to find the origin of the observed Error and the time to fix the Error.

24 The Tester or Author/Developer should specify the product in which the Error originated (such as the Requirements Document, Design Document, orCode).

25 The Tester or Author/Developer should speculate as to why the Error was not found previously.

26 Check the appropriate box to indicate whether the product was re-inspected after the Error was corrected. If "No", indicate the reason the product was notre-inspected.

27 Record the page number of this page and record the total number of TEST REPORT form pages.

Note: Errors in the testing activities equate to Defects in the inspection activities

FINAL COMPLETION REPORT

Project Start Date:

Project Completion Date:

To be completed by the Project Manager.

Product Approx. Person-Hours Spent InDevelopment

PG/ PLOC/ SLOC

Errors Discovered After Delivery

6 Months

3 Years +

2Years

1Year

System RequirementsSubsystem RequirementsFunctional DesignSoftware RequirementsArchitectural DesignDetailed Design

Source CodeTest PlanTest ProceduresOther

TOTAL

Data Manager: P. Schuler, MS 125A

(optional)

2 4

3

56

7

8

14

Project:1

Revision B 4/1992 LaRCRevision B 4/1992 LaRC

To be completed by the Data Manager.

*

%

Total Major

Identified ClosedIdentifiedFixed

Total Open IssuesTotal Minor

Identified Fixed

10 11 12 13 TotalPerson-Hours Spent In Inspections

9

*Percent of Delivered Work Product Inspected.

INSTRUCTIONS FOR THE FINAL COMPLETION REPORT FORM


2 Date that the project was initiated. For an in-house project, this would be the date that theConcept Phase began. For a contracted project, this would be the date the contract wasawarded. (This date should be the same as the date given on the INSPECTION SUMMARYREPORT form, #8)

3 Date that the project was completed.

4 Name and mail stop of the Data Manager responsible for collecting the Formal Inspectionstatistics.

The following is completed by the Project Manager for each product -

5 Types of the products developed for the project. If other types of products were developed,list them under "Other".

6 Approximate time expended in person-hours in development of the products including timeexpended in inspections.

7 Indicate the total number of Pages (PG), Pseudo Lines of Code (PLOC), or Source Lines ofCode (SLOC) in the delivered products.

8 Number of Errors discovered 6 months, 1 year, 2 years, and 3 years+ after delivery of theproducts.

The following is completed by the Data Manager for each product -

9 Total time expended in “X.X” person-hours in inspections.

10 Indicate what percent of the delivered product was inspected.

11 Total number of Major Defects identified and fixed.Note: If these two numbers are not equal, list the waivers which were written for the Major

Defectswhich were not corrected on a separate piece of paper and attach it to this form.

12 Total number of Minor Defects identified and fixed.

13 Total number of Open Issues identified and closed (resolved).(Note: If these two numbers are not equal, list the waivers which were written for the OpenIssues which were not closed on a separate piece of paper and attach it to this form.)

14 Total each column.

Appendix C: Checklists

This Appendix contains the Checklists that have been compiled as of the date of thispublication. These Checklists can be tailored to the project domain and requirements.

Software Product Assurance April1990

SY - Functional Requirements Checklist

CLARITY

1 Are goals of the system defined?2 Are requirements specified in an implementation free way so as not to obscure the original

requirements?3 Are implementation and method and technique requirements kept separate from functional

requirements?4 Is the terminology consistent with the user and/or sponsor's terminology?5 Are the requirements clear and unambiguous? (I.e., are there aspects of the requirements that you do

not understand; can they be misinterpreted?)

COMPLETENESS

1. Are requirements stated completely, addressing relevant aspects, yet tolerant of temporaryincompleteness? Have all incomplete requirements been captured as TBDs?

2. Has a feasibility analysis been performed and documented?3. Is the impact of not achieving the requirements documented?4. Have trade studies been performed and documented?5. Have the security issues of hardware, software, operations personnel and procedures been addressed?6. Has the impact of the project on users, other systems, and the environment been assessed?7. Are the required functions, external interfaces and performance specifications prioritized by need date?

COMPLIANCE

1. Does this document follow the projects system documentation standards? JPL's standards?

CONSISTENCY

1. Are the requirements stated consistently without contradicting themselves or other system'srequirements?

FUNCTIONALITY

1. Are all functions clearly and unambiguously described and alphabetized?2. Are all described functions necessary and sufficient to meet mission/system objectives?3. Are "don't care" conditions truly "don't care"? Are "don't care" conditions explicitly stated? (Consider

portability to identify "don't care" conditions.)

INTERFACES

1. Are all external interfaces clearly defined?2. Are all internal interfaces clearly defined?3. Arc! all interfaces necessary, sufficient, and consistent with each other?

MAINTAINABILITY

1. Have the requirements for system maintainability been specified?2. Are requirements written to be as weakly coupled as possible so that rippling effects from changes is

minimized?

PERFORMANCE1 Are all required performance specifications and margins listed?

(e.g., consider timing, throughput, memory size, accuracy and precision.)2. For each performance requirement defined:

a. Do rough estimates indicate that they can be met?b. Is the impact of failure defined?

RELIABILITY1. Are there reliability requirements?2. Are there error detection, reporting, and recovery requirements?3. Are undesired events (e.g., single event upset, data loss or scrambling operator error) considered and

their required responses specified?4. Have assumptions about the intended sequence of functions been stated? Are these sequences required?5. Do these requirements adequately address the survivability of the system from the point of view of

hardware, software, operations personnel and procedures?

TESTABILITY

1. Can the system be tested, demonstrated, inspected or analyzed to show that it satisfies requirements.2. Are requirements stated precisely to facilitate specification of system test success criteria and

requirements?

TRACEABILITY

1. Are all functions, structures and constraints traced to mission/system objectives?2. Is each requirement stated in such a manner that it can be uniquely referenced in subordinate

documents?3. Can all of the requirements be allocated to hardware, software, and operations personnel and

procedures.

Software Product Assurance April 1990

R0 - Functional Design Checklist

CLARITY

1. Have the hardware and software environments been described? Have all external systems beenincluded?

2. Has the high level architecture been described, illustrated and made consistent with the lower leveldescriptions?

3. Has the primary purpose for the software been defined?4. Has the overall functional design been described?

COMPLETENESS1. Have feasibility analyses been performed and documented (e.g., prototyping, simulations, analogies to

current system)?2. Have all design and implementation goals and constraints been defined?3. Have the capabilities of each component for each stage or phased delivery been identified?4. If assumptions have been made due to missing information, have they been documented?5. Have all TBD requirements from FRD been analyzed?6. Have trade studies been performed and documented?7. Have all tradeoffs and decisions been described and justified? Are selection criteria and alternatives

included?8. Has the subsystem been sized (using lines of code or an alternate method)?

COMPLIANCEI . Does the documentation follow project and/or JPL standards?

CONSISTENCY1. Arc the requirements in this document consistent with each other?2. Are the requirements consistent with the FRD, external interfaces, and any other related documents?

CORRECTNESS1. Does the design seem feasible with respect to cost, schedule, and technology?2. Have initialization, synchronization, and control requirements been described? Do state diagrams

clearly represent the timing?3. Have assumptions about intended sequences of functions been stated? Are these sequences required?4. Are the requirements consistent with the actual operating environment (e.g., check hardware timing,

precision, event sequencing, data rates, bandwidth)?

DATA USAGE1. Are data elements named and used consistently?2. Has all shared data between subsystems been identified?3. Have the means for shared data management been described? Are the subsystems which set and/or use

the shared data indicated?4. Has the dataflow among hardware, software, personnel, and procedures been described?

FUNCTIONALITY1. Are all described functions necessary and sufficient to meet the mission/system objectives?2. Are all inputs to a function necessary and sufficient to perform the required operation?3. Are all the outputs produced by a function used by another function or transferred across an external

interface?4. Do all functions clearly state how the output is derived from input or shared data?5. Are all functional states defined?

INTERFACE

1. Are the internal and external interfaces clearly defined?2. Have all interfaces between systems, hardware, software, personnel, and procedures been functionally

described?

3. Have the requirements for data transferacross each interface been stated?4. Have the number and complexity of the interfaces been minimized and are they consistent?5. Are the inputs and outputs for all the interfaces sufficient and necessary?

LEVEL OF DETAIL1. Are the requirements free of unwarranted design?2. Does each requirement in the FRD trace to one or more requirements in the FDD?3. Is there enough detail to proceed to the next phase of the life cycle?4. Have ail "TBDs" been resolved?

MAINTAINABILITY1. Have the requirements for software maintainability been specified?2. Have risk -areas of the design been identified and isolated? Does the design complexity agree with

development risk, cost, and schedule?3. Have all inherited or procured subsystems been documented? Has a cost/benefit analysis beenidentified?4. Are reusable parts of other designs being used? Have their effect on design and integration beenstated?5. Are the requirements weakly coupled? Have the number of requirements that are affected when one

requirement is changed been minimized?6. Have analyses been done for cohesion, coupling, traffic statistics, etc?7. Do the design features enable the system to meet maintainability requirements?

PERFORMANCE1. Are all performance attributes, assumptions, and constraints clearly defined?2. Do all explicit and Implicit performance requirements have metrics expressed (e.g., timing, throughput,

memory size, accuracy, precision)?3. For each performance requirement identified (explicit or implicit):

a. Have the performance estimates been documented?b. Do rough estimates indicate that they can be met? Is the impact of failure defined?c. Do experiments, prototypes, or analyses verify that the requirements can be met?

RELIABILITY1. Has an explicit reliability goal been stated?2. Do the design features enable the system to meet reliability requirements?3. Are normal operating conditions/errors taken into account? Are special states considered (e.g., cold

starts, abnormal termination, recovery)?4. Have fault tolerance features been identified or analyzed?5. Have the subsystem level error detection, reporting, and recovery features for internal and external

errors been described?

TESTABILITY1. Can the program sets be tested, demonstrated, analyzed, or inspected to show that they satisfy

requirements?2. Can the subsystem components be developed and tested independently? incrementally?3. Have any special integration or integration testing constraints been levied?

TRACEABILITY1. Are the priorities of the requirements documented? Is the impact of not achieving the requirements

defined?2. Are requirement traceability exceptions justified?3. Have all of the requirements been allocated to hardware, software, personnel, or procedures?4. Are all functions, structures, and constraints traced to requirements and vice versa?5. Are requirements stated in a manner so that they can be uniquely referenced in subordinatedocuments?6. Are the architectural components for each stage of implementation identified for reference in

subordinate documents?

Software Product Assurance

April 1990

R1 - Software Requirements Checklist

CLARITY

1. Are the goals of the subsystem defined?2. Is the terminology consistent with the users' and/or sponsors' terminology?3. Are the requirements clear and unambiguous?4. Is a functional overview of the program set provided?5. Is an overview of the operational modes, states, and concept described?6. Have the software environment (co-resident program sets) and hardware environment (specific

configurations) been specified?7. If assumptions that affect implementation have been made, are they stated?8. Have the requirements been stated in terms of inputs, outputs, and processing for each function?

COMPLETENESS1. Are required attributes, assumptions, and constraints of the program set completely listed?2. Have all requirements and constraints been assigned a priority?3. Have the criteria for assigning requirement priority levels been defined?4. Have the requirements been stated for each delivery or staged implementation?5. Have requirements for installation (packaging, site preparation, operator training) been specified?6. Have the target language, development environment, and run-time environment been chosen?

COMPLIANCE1. Does the documentation follow project and/or JTIL standards?

CONSISTENCY1. Are the requirements consistent with each other?2. Are the requirements here consistent with the requirements in related documents?3. Are the requirements consistent with the actual operating environment (e.g., check hardware timing,

precision, event sequencing, data rates, bandwidth)?3. Do the requirements stay within the capability of the requirements allocated by the FDD?

DATA USAGE1. Have the data type, rate, units, accuracy, resolution, limits, range, and critical values for all internal

data items been specified?2. Have the data objects and their component parts been specified?3. Has the mapping between local views of data and global data been shown?4. Has the management of stored and shared data been described?5. Has a list of functions that set and/or use stored and shared data been provided?6. Are there any special integrity requirements on the stored data?7. Have the types and frequency of occurrence of operations on stored data (e.g., retrieve, store, modify,

delete) been specified?8. Have the modes of access (e.g., random, sequential) for the shared data been specified?

FUNCTIONALITY1. Are all described functions necessary and sufficient to meet the mission/system objectives?2. Are all inputs to a function necessary and sufficient to perform the required operation?3. Does each function clearly describe how outputs (and shared data) are generated from inputs (and

shared data)?4. Are all function states defined?

INTERFACE1. Are the inputs and outputs for all the interfaces sufficient and necessary?2. Are all the outputs produced by a function used by another function or transferred across an external

interface?3. Are the interface requirements between hardware, software, personnel, and procedures included?4. Have the contents, formats, and constraints of all the displays been described in the SRD or SOM-1?

5. Are all data elements crossing programset boundaries identified?6. Are all data elements described here or in the SIS-1?9. Has the data flow between internal software functions been represented?

LEVEL OF DETAIL1. Are the requirements free of design?2. Have all "TBDs" been resolved?3. Have the interfaces been described to enough detail for design work to begin?4. Have the accuracy, precision, range, type, rate, units, frequency, and volume of inputs and outputs been

specified for each function?5. Have the functional requirements been described to enough detail for design work to begin?6. Have the performance requirements been described to enough detail for design work to begin?

MAINTAINABILITY1. Are the requirements weakly coupled (i.e., changing a function will not have adverse and unexpected

effects throughout the subsystem)?2. Will the requirements minimize the complexity of the design?3. Have FRD and FDD maintainability requirements been levied to functions?4. Have FRD and FDD portability requirements been levied to functions?5. Has the use of inherited design or code or pre-selected tools been specified?

PERFORMANCE1. Have the FRD and FDD performance requirements been allocated to each function?2. Have the resource and performance margin requirements been stated along with tile means for

managing them?

RELIABILITY1. Have quality factors been specified as measurable requirements or prioritized design goals?2. Have FRD and FDD reliability requirements been levied to functions?3. Have FRD and FDD availability requirements been levied to functions?4. Have FRD and FDD security/safety requirements been levied to functions?5. Are error checking and recovery required?6. Are undesired events considered and their required responses specified?7. Are initial or special states considered (e.g., cold starts, abnormal termination)?8. Have assumptions about intended sequences of functions been stated? Are these sequences required?

TESTABILITY1. Can the program set be tested, demonstrated, analyzed, or inspected to show that it satisfies the

requirements?2. Are the individual requirements stated so that they are discrete, unambiguous, and testable?3. Have the overall program set acceptance criteria been established?4. Have clear pass/fail criteria for the acceptance tests been established?5. Have the test methods (test, demonstration, analysis, or inspection) been stated for each requirement?

TRACEABILITY1. Are all functions, structures, and constraints traced to requirements, and vice versa?2. Have the FDD and ISFD requirements been allocated to functions of the program set?3. Do the requirements (or traceability matrix) indicate whether they are imposed by the FDD or whether

they are derived to support specific FDD requirements?4. Have the FRD, FDD, and any derived design goals and implementation constraints been specified and

prioritized?5. Is each requirement stated in a manner that it can be uniquely referenced in subordinate documents?


I0-Architecture Design ChecklistCLARITY1. Is the architecture, including the data flows, control flows, and interfaces, clearly represented?2. When appropriate, are there multiple, consistent, representations of the design (i.e. static vs. dynamic)?3. Are all of the assumptions, constraints, decisions, and dependencies for this design documented?4. Are the goals defined?COMPLETENESS1. Have all TBDs been resolved in requirements and specifications?2. Can the design support suspected changes in these TBD requirements?3. Have the impacts of the TBDs been assessed?4. Has a risk plan been made for the parts of the design which may not be feasible?5. Have design trade offs been documented? Does the documentation include the definition of the trade

space and the criteria for choosing between tradeoffs?6. Has design modeling been performed and documented?

CQMPLIANCE1. Does the documentation follow project and/or JPL standards?

CONSISTENCY1. Are data elements, procedures, and functions named and used consistently throughout the program setandwith external interfaces?2. Does the design reflect the actual operating environment? Hardware? Software?

CORRECTNESS1. Is the design feasible from schedule, budget, and technology standpoints?2. Is there wrong, missing, or incomplete logic?

DATA USAGE1. Is the conceptual view for all composite data elements, parameters, and objects documented?2. Is there any data structure needed that has not been defined, or vice versa?3. Has the management and use of shared and stored data been clearly described?4. Have the lowest level data elements been described? Have value ranges been specified?

FUNCTIONALITY1. Do the specifications for each module fully implement the functionality required in the SRD and SIS-1

?2. Is the abstract algorithm specified for each sublevel module?3. Will the selected design or algorithm meet all of its requirements?

INTERFACES1. Is the operator interface designed with the user in mind (i.e. vocabulary, useful messages)?2. Are the functional characteristics of the interfaces described?3. Will the interface facilitate trouble-shooting?4. Are all interfaces consistent with each other, other modules, and requirements in SRD, SIS-1/2?5. Do all interfaces provide the required types, amounts, and quality of information?6. Have the number and complexity of interfaces been minimized?

LEVEL OF DETAIL1. Has the size of each sublevel module been estimated (lines of code)? Is it reasonable?2. Are all possible states or cases considered?3. Is the design of sufficient detail to proceed to the detailed design phase?

MAINTAINABILITYI. Is the design modular?2. Do the modules have high cohesion and low coupling?

PERFORMANCE1. Has performance modeling been performed and documented when appropriate?2. Are the primary performance parameters specified (e.g., real time, memory size, speed requirements,

amount of disk I/0)?3. Do processes have time windows (e.g., flags may be needed to "lock" structures, semaphores, some

code may need to be non-interruptible)?4. Have the critical path(s) of execution been identified and analyzed?

RELIABILITY1. Does the design provide for error detection and recovery (e.g. input checking )?2. Are abnormal conditions considered?3. Are all error conditions specified completely and accurately?4. Does the design satisfy all systems integrity commitments for this product?

TESTABILITY1. Can the program set be tested, demonstrated, analyzed, or inspected to show that it satisfies

requirements?2. Can the program set be integrated and tested in an incremental manner?

TRACEABILITY1. Are all parts of the design traced back to requirements in SRD, SIS-1, other project documents?2. Can all design decisions be traced back to trade studies?3. Has the history of inherited designs been documented?4. Are all known risks from inherited designs identified and analyzed?

Software Product Assurance April 199011 - Detailed Design Checklist

CLARITYI. Is the intent of all units or processes documented?2. Is the unit design, including the data flow, control flow, and interfaces, clearly represented?3. Has the overall function of the unit been described?

COMPLETENESSI. Are all variables, pointers, and constants defined and initialized?2. Have the specifications for all units in the program set been provided?3. Have all the acceptance criteria been described?4. Have the algorithms (e.g., in PDL) used to implement this unit been specified?5. Have all the calls made by this unit been listed?6. Has the history of inherited designs been documented along with known risks?

COMPLIANCE1. Does the documentation follow project and/or JPL standards?2. Has the unit design been created using the required methodology and tools?

CONSISTENCY1. Are data elements named and used consistently throughout the unit and unit interfaces?2. Are the designs of all interfaces consistent with each other and with the SIS-2 and SSD-1?3. Does the detailed design, together with the architectural design, fully describe the "as-built" system?

CORRECTNESS1. Is there logic missing?2. Are literals used where a constant data name should be used?3. Are all conditions handled (greater-than, equal-to, lcss-than-zero, switch/case)?4. Are branches correctly stated (the logic is not reversed)?

DATA USAGE1. Are all the declared data blocks actually used?2. Have all the data structures local to the unit been specified?3. Are all routines that modify shared data (or files) aware of the access to the shared data (or files) by

other routines?4. Are all logical units, event flags, and synchronization flags defined and initialized?

FUNCTIONALITY1. Does this design implement the specified algorithm?2. Will this design fulfill its specified requirement and purposes?

INTERFACE1. Do argument lists match in number, type, and order?2. Are all inputs and outputs properly defined and checked?3. Has the order of passed parameters been clearly described?4. Has the mechanism for passing parameters been identified?5. Are constants and variables passed across an interface treated as such in the unit's design (e.g. a

constant should not be altered within a subroutine)?6. Have all the parameters and control flags passed to and returned by the unit been described?7. Have the parameters been specified in terms of unit of measure, range of values, accuracy, andprecision?8. Is the shared data areas mapped consistently by all routines that access them?

LEVEL OF DETAIL1. Is the expansion ratio of code to design documentation less than 10:1?2. Are all required module attributes defined?3. Has sufficient detail been included to develop and maintain the code?

MAINTAINABILITYI. Does this unit have high internal cohesion and low external coupling (i.e., changes to this unit do not

have any unforeseen effects within the unit and have minimal effect on other units)?2. Has the complexity of this design been minimized?3. Does the header meet project standards (e.g., purpose, author, environment, nonstandard features used,

development history, input and output parameters, files used, data structures used, units invoking thisone, units invoked by this one, and explanatory notes)?

4. Does the unit exhibit clarity, readability, and modifiability to meet maintenance requirements?

PERFORMANCE1. Do processes have time windows?2. Have all the constraints, such as processing time and size, for this unit been specified?

RELIABILITY1. Are default values used for initialization and are they correct?2. Arc boundary checks performed on memory accesses (i.e., arrays, data structures, pointers, etc.) to

insure that only the intended memory locations are being altered?,3. Is error checking on inputs, outputs, interfaces, and results performed?4. Are meaningful messages issued for all error conditions?5. Do return codes for particular situations match the global definition of the return code as documented?6. Are undesired events considered?

TESTABILITY1. Can each unit be tested, demonstrated, analyzed, or inspected to show that they satisfy requirements?2. Does the design contain checkpoints to aid in testing (e.g., conditionally compiled code, data assertiontests)?3. Can all logic be tested?4. Have test drivers, test data sets, and test results for this unit been described?

TRACEABILITY1. Are all parts of the design traced back to the requirements?2. Can all design decisions be traced back to trade studies?3. Have all the detailed requirements for each unit been specified?4. Have the unit requirements been traced to the SSD-1? Have the SSD-1 specifications been traced to the

unit requirements?5. Has a reference to the code or the code itself been included?

Software Product Assurance April 1990IT1 - TEST PLAN CHECKLIST

COMPLETENESS1. Does the Test Plan specify the overall approach and policy for acceptance test?2. Does the Test Plan clearly specify the order of the steps of all integration testing?3. Does the Test Plan include a description of the type of hardware and software system environment to

be used?4. Does the Test Plan define success criteria for all tests?5. Does the Test Plan adequately describe the functions being tested?6. Does the Test Plan explicitly describe those functions that will not be tested during integration test?7. Does the Test Plan describe conditions under which testing will be balled and resumed during

integration test?8. Does the test case set adequately exercise all significant code changes, particularly interface

modifications?9. Does the Test Plan adequately describe integration test baselines?10. For a phased delivery, does the Test Plan establish test baselines in each phase for use in the next

phase?11. Does the Test Plan define sufficient and proper regression testing?

COMPLIANCE1. Does the Test Plan list all the specifications, standards, and documents necessary for its development?

CONSISTENCY1. Has the order of integration tests been defined to match the order of integration specified in higher

level documents?2. Is the Test Plan consistent with higher level test plan documents?

CORRECTNESS1. Are the Test Plan entrance and exit criteria realistic?2. Are all necessary drivers and stubs identified and available to test the function as specified?3. Are all dependencies between the input simulator and the hardware addressed?

LEVEL OF DETAIL1. Is the coverage of the test case set sufficiently complete to provide confidence that the functions being

tested operate correctly within their intended environment?2. Does the test case set include adequate coverage of illegal and conflicting input combinations?3. Does the test case set include adequate usage of default input values?4. Does the test case set exercise an adequate number of program error paths?

MAINTAINABILITY1. Are control and incorporation of changes to the specifications, design, or coding that may occur during

test contained in the Test Plan?

RELIABILITY1. Is sufficient test data collected and documented to support estimation of the software's reliability?

TESTABILITY1. Is the testing approach feasible?

2. Are all those requirements considered untestable and unable to be tested identified, and is it explainedwhy they are untestable or unable to be tested?

3. Has development and procurement of test facilities (input simulators and output analyzers), methods,and tools been scheduled with adequate lead time?

4. Are the testing schedules described to a sufficient level of detail (testing schedules are described foreach individual function to be tested)?

5. Is the method of estimating resource usage required for testing identified?6, For multiple builds, have all requirements been identified on a per-build basis?7. Have the roles and responsibilities for all personnel involved in the test activity been identified?8. Is the specification of test facilities consistent with the test success criteria?9. Are there any scheduling conflicts among the testing personnel schedules?10. Does the Test Plan call for the participation of independent quality assurance personnel to verify test

activity?11. Does the Test Plan call for independent testing?

TRACEABILITY1. Do the acceptance tests exercise each requirement specified in higher level documents (FRD, FDD,

SRD)?2. Are the test acceptance criteria traceable to higher level requirements documents (SIS, UG/SOM,

FRD, SRD, FDD)?3. Does the test case set for integration test exercise each interface described in higher level documents

(SIS and SSD)?


IT2 - TEST PROCEDURE & FUNCTION CHECKLIST

CLARITY1. Are the operator instructions explicit and clear for case of execution of the test procedure?2. Are the operator instructions presented step-by-step and in the order in which they must be performed?3. Are the steps of the set-up and test procedures precise, unambiguous, and listed as individual items?4. Are there "progress" messages that will notify the operator when significant parts of the test are being

executed?5. Are the criteria for success and failure clear and unambiguous?

COMPLETENESS1. Is the function being tested accurately described?2. Is the function being tested the latest revision?3. Is the description of the purpose of this test procedure complete and accurate?4. Is each requirement associated with this function exercised by this test procedure?5. Is the expected response to each step of the test procedure described with the operator instructions for

that step?6. Are there criteria for test success and failure?7. Does the test procedure list the precedence of tests?S. Does the test procedure indicate the significance of proper evaluation of test results?9. Are all normal and abnormal completion messages identified?10. Does the procedure state whether or not it is possible to continue in the event of a program stop or

indicated error? If so, does it indicate the method for restarting or other recovery action?11. Are an adequate number of control paths in the tested function exercised?12. Do the test procedures lead to the determination of success or failure?13. Are an adequate number of logical condition expressions in the tested function exercised?14. Do the test cases demonstrate the program's response to illegal and conflicting input data?

CONSISTENCY1. Are all dependencies of the test procedure identified?

CORRECTNESS1. Do the observed results of performing the procedure agree with the expected program behavior?2. Are the interfaces between the code being tested and the test equipment and software correct?3. Are the formats of the input data correct?

PERFORMANCE1. If a performance criterion is associated with any step of the test procedure, is that criterion explicitly

stated along with the operator instructions for that step?

RELIABILITY1. Has the test equipment been validated and calibrated?2. Has the test software been validated?3. Have all input data been verified?4. Is sufficient test data collected and documented to support estimation of the software's reliability?

TESTABILITY1. Does the test procedure identify all of the equipment, software, and personnel required for testing?2. Can the test procedure be performed with minimal support from the development team?3. Is the test procedure consistent with the capabilities of the test facilities?4. Is the testing schedule described to a sufficient level of detail?5. Does the Test Plan call for the participation of independent quality assurance personnel to vary testing

activity?6. Does the Test Plan call for independent testing?

TRACEABILITY1. Does the test procedure list all specifications, procedures, handbooks, or manuals required for

operation?2. Is the traceability shown between the requirements and the acceptance test combinations?3. Are the criteria for success traced to requirements?5. Is the creator of each test case dataset identified?

1

I2 –ADA Inspection Checklist

This checklist is intended for use in the inspections at the conclusionof code and unit testing. Both the CSU and the results of itsregression testing are evaluated in these inspections.

Entrance CriteriaSuccessful completion of CSU unit testing as per SDH entry 5 -6.

Inspection MaterialThe following items will be required material for an I2 level Adasource code inspection:

− Compilation listing with line and page numbers and portabilitysummary.

− − Reports from the Adamat quality assurance tool as per SDH entry

7- 6.− − Regression test result report as specified In SDH entry 5 -6.

General

1.0 Does the code implement the intent of the detailed design asdocumented in the SDD and any applicable RFAs?

2.0 Does the implementation of the CSU adhere to the standards andmethodologies specified in the SDH?

3.0 Is the size of the CSU within limits specified in SDH entry 3-7?

4.0 Does the code contradict the information contained in anysupporting documentation such as the textual part of the SDD orthe package/entity diagrams?

5.0 Is the code accompanied by explanatory comments?

Checklist for compliance to Ada coding standard

These checklist items have been derived from the NASA Ada Style Guideno SEL-87-002 (ASG). Desirable and undesirable features are marked(Good) and (Avoid) respectively Where appropriate, examples andexplanations have been provided to aid clarity.

2

DECLARATON AND TYPES

1.0 Are all objects which do not change declared as constants? (Good)

2.0 Does the code use numeric literals or expressions in place ofconstant objects? (Avoid)

3 0 Are the constant objects declared without a type? (Avoid)Universal constants should be used only for truly type lessentities e.g. pi or number of things.

4.0 Are separate types being used for values that belong to logicallyindependent sets? (Good)

5.0 Is an integer type used where an enumerated type is moreappropriate? (Avoid)

6.0 Are the rangeand accuracy of floating point types specified?(Good)

7 0 Are array types being used where record types would be moreappropriate? (Avoid)

8 0 Is any array object declared with an anonymous type, i.e.declaredwithout a type identifier? (Avoid)Good: type RADAR_SITESis array(l .. 28) of PLACES;

Radar_Site : RADAR_SITES;Bad: Radar_Site : array(I .. 28) of PLACES;

Notes for the reviewer:

I. The ASC contains both standards (mandatory) and recommendations orguidelines. This checklist was derived from the standards only.

II. The checklist items related to prologue and naming conventions aregoverned by the SDH entries 3-6 and 3-5.

III. Some of the ASG standards are inapplicable. These are shown as strucktext. When an ASC standard has been changed or modified, the originalappears as struck text.

IV. Checklist items related to exception handling is governed primarily bythe SDH entry 3-17.

3

9.0 Are type and object declarations accompanied with explanatorycomments? (Good)

10 0 Does the program text use a consistent and clear indentationscheme? (Good)

EXCEPTIONS1.0 Are exceptions being used normal processing such as returning

normal status information or as devices for normal flow control?(Avoid)

2.0 Do the exception handlers conform to the logging guidelines givenin SDH entry 3-17? (Good)

3.0 Do the task bodies provide a handler for each predefined exception(in the STANDARD package)? (Good)

4.0 Is there a “when others” handler in the outer most frame of eachtask body and main program? Also, is the use of the "when others"handler consistent with the guidelines given in SDH entry 3 -17)?(Good)

5.0 Is there provision for handling I/0 exceptions in the proceduresthat perform 1/07 (Good)

6.0 Do the units interfacing with non-Ada environments transformerror-status information into user defined exceptions (Good)

7.0 Does each cask handle the exceptions raised within it? (Good)

8.0 Is any exception propagated outside its static scope? (Avoid)

9.0 Are any checks suppressed using PRAGMA SUPPRESS? (Avoid)

GENERIC UNITS

1.0 Does the use of generic units conform to the guidelines given inSDH entry 3-14? (Good)

2.0 Are the actual subprograms provided during instanti ationconceptually consistent with the corresponding generic formalparameters? (eg. are their actions similar?) (Good)

3.0 Does the prologue associated with the generic units conform to theguidelines given in the SDH entry 3-5? (Good)

4

INPUT-OUTPUT

1.0 Are "end-of -line" or "end-of-page" characters being used for lineor page formatting? (Avoid)− use of New_Line and New_Page is preferable

2.0 Is there any unnecessary use of Low_Level_I0? (Avoid)

LEXICAL ELEMENTS_

1.0 Does the code redefine the meaning of any identifier in thepackage STANDARD? (Avoid)

2.0 Does the code deviate from the following lexical conventions?(Avoid)− Reserved identifiers in lower case− Type identifiers in upper case− Identifiers are meaningful− Indentation and layout of program text is consistent

NAMES AND EXPRESSIONS

1.0 Are arrays and records initialized using assignments to individualcomponents rather than with aggregates? (avoid)

2.0 Are explicit type conversions used where a type qualifiedexpression is meant? (Avoid)Good: INTENSITY_TYPE(2.55)Bad : INTENSITY_TYPE(2.55)

3.0 Is type qualification being used in avoidable situations? (avoid)

4.0 Are type names common nouns such as DEVICE_TYPE,AUTHORITY_LEVEL_TYPE, USER_NAME_TYPE? (Good)

5 0 Are the names of non-Boolean objects nouns such as:Current_User : USER_NAME;Line_Printer : DEVICE; (Good)

6 0 Are the names of the Boolean valued objects predicate clauses suchas:User_Is_Available : BOOLEAN;List_Empty : BOOLEAN; (Good)

5

PACKAGES

1.0 Does each package fulfil one or more of the following: (Good)− Model an abstract entity appropriateto the problem domain.− collect a cohesive set of types and objects.− group together program units for configuration control or

visibility reasons.

2.0 Are all non-trivial nested package bodies declared as subunits?(Good)

3.0 Does the private part of any package specification containextraneous information? (Avoid)− The private part should contain nothing other than the

information needed for full definition of the private types anddeferred constants

4.0 Is the package name a meaningful noun phrase e.g.Vehicle_Controller, Utility_Package, Parser_Types (Good)

5.0 Do the package names have the prefix and suffix as specified inSDH entry 3-6? (Good)

6.0 Does the package specification prologue text conform to the SDHentry 3-5? (Good)

7.0 Do the package body and body stub prologue texts conform to theSDH entry 3-5? (Good)

PROGRAM STRUCTURE AND COMPILATION

1.0 Are all non-trivial nested units made into separate subunits?(Good)

2.0 Does any unit import another unit it does not need to see? (Avoid)− Units needed by the body should be imported by the body, not the

specification.− Units needed by a subunit should be imported by the subunit, not

its parent.

3.0 Is each compilation unit in a separate file? (Good)

4.0 Was the unit compiled with the current versions of the projectstandard library units? (e.g. standard type packages?) (Good)

6

STATEMENTS

1.0 Are loops rather than array slice assignments being use d, to copyall or part of an array? (Avoid)

2.0 Are "if" and "case" statements being used improperly? (Avoid)− “case" statements should be used in all selections controlled

by an enumerated type ocher than a BOOLEAN, when the "if"statement should be used.

3.0 Are blocks being used in place of procedures? (Avoid)

4 0 Are there any '!go to" statements? (Avoid)

5 0 Are the related sequences of statements collected together intogroups by blocking them with blank lines? (Good)

6 0 Do the "if", "case", "loop" and block statements follow aconsistent and meaningful indentation scheme? (Good)

7 0 Is the code well documented? Do the comments accurately reflectthe logic of the statements?

SUBPROGRAMS

1.0 Does each subprogram perform a single, conceptua l action at itslevel of abstraction? (i.e., are subprograms functionallycohesive)? (Good)

2.0 Are overloaded functions being used in cases other than thefollowing? (Avoid)

− widely used utility subprograms performing similar actions ondifferent types of arguments

− overloading of operators

3.0 Are procedure names imperative verbs eg. Obtain_Next_Token,Increment_Line_Counter (Good)

4.0 Are the names of BOOLEAN valued functions predicate clauses eg.Stack_Is_Empty, Last_Item, Device_Not_Ready (Good)Non-BOOLEAN function names may be noun phrases eg. Top_Of_Stack,Sensor_Reading, X_Component (Good)

5.0 Does the subprogram specification prologue text conform to the SDH

7

entry 3-5? (Good)

6 0 Are parameter modes missing from procedure specification s?(Avoid)

7 0 Do the subprogram body and body stub prologue texts conform tothe SDH entry 3-5? (Good)

TASKS

1.0 Are task types being used where a directly named task would bemore appropriate? (Avoid)

2.0 Is there unnecessary use of dynamically cre ated tasks? (Avoid)

3.0 Is there a proper termination mechanism for each task? (Good)− Tasks nested within the main program should terminate by

reaching its "end" or have a selective wait with a terminatealternative.

− Tasks nested within library packages (or dependent upon anylibrary package) SHOULD NOT USE the "terminate" alternative, asthese tasks will not terminate due to a terminate alternative(LRM). Some other provision is necessary for proper terminationof these tasks.

4.0 Does the body of the accept statement contain any actions notessential for the rendezvous? (Avoid)

5.0 Does the task directly or indirectly call its own entry? (Avoid)

6.0 Does any task use a "busy wait" loop in place of a delaystatement? (Avoid)

7.0 Does the code rely upon the execution pattern of tasks (e.g. known timepattern, fixed, etc.) for synchronization? (Avoid)

8.0 Are there any concurrently executing tasks that share a commonvariable? (avoid)

9.0 Is each variable that is shared by tasks identified bydocumentary comments at its point of declaration? (Good)Conversely, does each task clearly identify and document the listof variables it shares with other tasks? (Good)Note: this does nor apply to parameters exchanged during

8

rendezvous

10.0 Is each task name a noun phrase describing the function of thetask, eg. Sensor_Interface, Status_Monitor (Good)

11.0 Does the task specification prologue text conform to the SDH entry3-5? (Good)

12.0 Do the task body and body stub prologue texts conform to the SDHentry 3-5? (Good)

13.0 Is each accept statements accompanied an by the RWP projectstandard documentary comment? (Good)

14.0 Is the mode of any rendezvous parameter missing from the acceptstatement? (Avoid)

REPRESENTATION CLAUSES AND IMPLEMENTATION DEPENDENT FEATURES

1.0 Are the representation clauses and implementation features wherenecessary, hidden inside the package bodies? (Good)

2.0 Is there documentation to identify and document the use of machinedependent or low-level features? (Good)

3.0 Are representation clauses or implementation dependent featuresbeing used except for the following purposes? (Avoid)− increase efficiency to meet requirement− interfacing hardware, foreign code or foreign data− interrupt handling− specify task storage size

4.0 Are representation clauses placed away from the objects theyaffect? (Avoid)

VISIBILITY

1.0 Does the scope of any identifier (local or imported from anotherunit) extend further than necessary? (Avoid)

2.0 Is the "use" clause being used in cases other than the following?(Avoid)− for packages of commonly used utilities− importing packages with overloaded operators

9

− predefined I/0 packages eg. Text_Io, and instantiations ofits components

− to make imported enumerated rated constants directly visiblewithout the use of the dot notation

3.0 In cases when a package is directly visible (use clause) areunqualified names being used for referring to any imported entityother than those listed in 2 above. (Avoid)

The following apply to the CSU regression testing.

1.0 Does the regression test baseline include tests for all majorareas of concern such as: critical performance requirements, code -or data. structures requiring high accuracy, critical errorhandling, areas of high technical risk, major areas of controland/or decision points, etc.?

2.0 Are the test data used in the regression tests representative ofthe normal, error and stressed running conditions?

3.0 Are the regression test results comparable to those expected? Arethe discrepancies, if any, between the obtained and expectedresults documented and justified?

Software Product Assurance April 25,1988I2 - Code Inspection Checklist

“C”

FUNCTIONALITY1. Does each unit have a single function?2. Is there code which should be in a separate function?3. Is the code consistent with performance requirements?4. Does the code match the Detailed Design?

DATA USAGEA. Data and Variables1. Are declarations grouped into externals and internals?2. Do all but the most obvious declarations have comments?3. Is each name used for only a single function?

B. Constant1. Are all constant names upper case?2. Are constants defined via "# define”?3. Are constants that are used in multiple files defined in an INCLUDE header file?

C. Pointers Typing1. Are pointers declared and used as pointers (not integers)?2. Are pointers initialized?

LINKAGE1. Are "INCLUDE" files used according to project standards?2. Are nested "INCLUDE" files avoided?3. Is all data local in scope (internal static or external static) unless global linkage is specifically necessary and

commented4. Are the names of macros all upper case?

LOGICA. Lexical Rules for Operators1. Are unary operators adjacent to their operands?2. Are primary operators "->"."()" adjacent to there operands?3. Do assignment and conditional operators always have space around them.4. Are commas and semicolons followed by a space?5. Are keywords followed by a blank?6. Is the use of "(" following function name adjacent to the identifier?7. Are spaces used to show precedence? If precedence is at all complicated, are parens used (esp. with bitwise

ops)?B. Evaluation Order1. Are parentheses used properly for precedence?2. Does the code depend on evaluation order, except in the following cases?

a. exprl, expr2b. exprl ? expr2 : exp2c. exprl && expr2d. expr1 || expr2

3. Are shifts used properly?4. Does the code depend on order of effects? (e.g. i = i++;)

I2 – C -1

C. CONTROL1. Are "else_if" and "switch" used clearly? (generally "else_if" is clearer,but -switch" maybe used for

not-mutually-exclusive cases, and may also be faster).2. Are "goto" and "labels" used only when absolutely necessary, and always with well-commented code?

MAINTENANCE1. *Are non-standard usages isolated in subroutines and well documented?2. Does each unit have one exit point?3. Is the unit easy to change?..4. Is the unit independent of specific devices where possible?5. Is the system standard defined types header used if possible (otherwise use project standard header, by

"include")?CLARITYA. Comments1. Is the unit header informative and complete?2. Are there sufficient comments to understand the code?3. Are the comments in the units informative?4. Are comment lines used to group logically-related statements?5. Are the functions of arrays and variables described?6. Are changes made to a unit after its release noted in the development history section of the header?B. Layout1. Is the layout of the code such that the logic is apparent?2. Are loops indented and visually separated from thesurrounding code?C. Lexical Control Structures1. Is a standard project-wide (or at least consistent) lexical control structure pattern used?

I2 – C - 2

Software Product Assurance April 25,1988I2 - Code Inspection Checklist

FORTRANFUNCTIONALITY1. Do the units meet the design requirements?2. Does each unit have a single purpose?3. Does the code match the Detailed Design specifications?

DATA USAGEA. General1. Are all variables defined, initialized, and used?2. Are there typos, particularly "O" for zero, and "I" for one?3. Are there misspelled names which are compiled as function or subroutine references?4. Are declarations in the correct sequence? (DIMENSION, EQUIVALANCE, DATA).

B. Common/Equivalence1. Are there local variables which are in fact misspellings of a COMMON element?2. Are the elements in the COMMON in the right sequence?3. Do EQUIVALENCE statements force any unintended shared data storage?4. Is each EQUIVALENCE commented?

C. Arrays1. Are all arrays DIMENSIONed?2. Are array subscript references in column, row order? (Check all indices in multi-dimensioned

arrays.)3. Are array subscript references within the bounds of the array?4. Are array subscript references checked in critical cases?5. Is each array used for only one purpose?

D. Variables1. Are the variables initialized in DATA statements, BLOCK DATA, or previously defined by

assignments or COMMON usage?2. Should variables initialized in DATA statements actually be initialized by an assignment

statement; that is, should the variable be initialized each time the unit is invoked?3. Are variables used for only one purpose?4. Are variables used for logical unit assignments?5. Are the correct types (REAL, INTEGER, LOGICAL, COMPLEX) used?

E. Input and Output1. Do FORMATs correspond with the READ and WRITE lists?2. Is the intended conversion of data specified in the FORMAT?3. Are there redundant or unused FORMAT statements?4. Should this unit be doing any I/O? Should it be using a message facility?5. Are messages understandable?

F. Data1. Are all logical unit numbers and flags assigned correctly?2. Are constant values constant?

LINKAGE1. Are the parameters of the calling program and routine of the correct type, order, and number?2. Is an array passed to a subroutine only when an array is defined in the subroutine?3. Does the subroutine return an error status output parameter?4. If array dimensions are passed (dynamic dimensioning) are they greater than 0?5. Does a subroutine modify any input parameter? If so, is this fact clearly stated?6. Do subroutines end with a RETURN statement and not a STOP or a CALL EXIT?7. Does a FUNCTION routine have only one output value?

LOGICA. Loops1. Are the loop parameters expressed as variables?2. Is the loop index within the range of any array it is subscripting?3. Is the index variable only used within the DO loop?4. Does the loop handle all the conditions required?5. Is loop nesting in the correct order?B. Branches1. Are branches handled correctly?2. Are branches commented?3. When using computed GO TOs, is the fall-through case tested, checked, and handled correctly?4. Are floating point comparisons done with tolerances and never made to an exact value?C. Lexical Rules1. Are parentheses used correctly?2. Is the use of mixed-mode expressions avoided?3. Do integer comparisons account for truncation?4. Are complex numbers used correctly?5. Is the precision length selected adequate?

MAINTENANCE1. Are library routines used?2. Is non-standard FORTRAN isolated in subroutines and well documented?3. Is the use of EQUIVALENCE limited so that it does not impede understanding the unit?4. Is the use of GO TOs limited so that it does not impede understanding the unit?5. Is there no self-modifying code? (No ASSIGN statements, or PARAMETER statements.)6. Is the unit independent of specific devices where possible?6. Are type declarations implicit rather than explicit when possible?

CLARITY1. Is the unit header informative and complete?2. Are there sufficient informative comments to understand the code?3. Are comment lines used to group logically-related statements?5. Are the functions of arrays and variables described?

Appendix D: Certification of Inspection Participants

D.1 Moderator CertificationTo obtain Moderator Certification, complete the following activities:1. Complete the NASA course entitled "Formal Inspections for Software Development".2. Acting in the role of Moderator, conduct a minimum of three inspections while observed by

a Certified Moderator or Certified Instructor designated by the Chief Moderator.D.2 Inspector CertificationTo obtain Inspector Certification to fulfill the role of Reader, Recorder, Author or Inspector,complete the following activities:1) Complete the NASA course entitled "Formal Inspections for Software Development".Note: Langley personnel may complete the course created at LaRC (which is a condensed

version of the NASA course) and participate in an actual inspection as an Inspector. Thecourse provides an overview of the process and the basic knowledge the students need toparticipate as an Inspector. This class is generally used to train those Inspectors that areaffiliated with the project but are not participating in the actual software developmentprocess. The class is usually attended by members of the Science Team, users of the finalproduct, domain specialists, and representatives from other subsystems that are notsoftware intensive, like thermal or optical, but which have a vested interest in thefunctionality of the software. However, it is strongly recommended that all Inspectorsattend the longer NASA class, since its workshop provides an opportunity for students toparticipate in an inspection with an instructor present to answer questions concerning theprocess. In addition, this class covers the material in greater detail than the condensedclass, and gives the student a better understanding of the rationale behind the steps of theprocess.

D-3 Librarian Certification

No certification is required to fulfill the role of Librarian.

Appendix E: Inspection Type and Participants

This appendix gives suggestions on the possible areas of expertise from which inspectionparticipants could be chosen for each different type of inspection. The actual participants arechosen based on specific project needs, criticality, budget and schedule. Note that participantswith more than one area of expertise can be chosen to decrease the size of the Inspection Team.

Inspection Type Participants

SY - System Requirements System Requirements Analyst/System Engineer (Author)Peer System Requirements AnalystThe Engineer responsible for each subsystem requirements(Examples: Software, Optical, Thermal, Electronics)System Test EngineerUser(s)Quality Assurance

SU - Subsystem Requirements Software Requirements Analyst (Author)Peer Software Requirements AnalystSystem Requirements AuthorDeveloper responsible for Architectural DesignAn Engineer from each subsystem the software must interfacewith (Examples: Optical, Thermal, Electronics)Test EngineerLead Software Subsystem EngineersSoftware Engineer responsible for software interfacingAlgorithm DeveloperPerformance RepresentativeOperations EngineerAuthor of User's Guide or Software Operator's ManualUser(s)Quality Assurance


I0 - Architectural Design Architectural Designer (Author)Peer Architectural DesignerSubsystem Requirements AuthorDeveloper responsible for detailed designTest EngineerAlgorithm DeveloperPerformance RepresentativeOperations EngineerAuthor of User's Guide or Software Operator's ManualAn Engineer from each subsystem the software must interface with(Examples: Optical, Thermal, Electronics)User(s)Software Maintenance EngineerQuality Assurance

Il - Detailed Design Detailed Designer (Author)Peer Detailed DesignerArchitectural Design AuthorSoftware Development EngineerTest EngineerAlgorithm DeveloperAn Engineer from each subsystem the software must interface with(Examples: Optical, Thermal, Electronics)Software Maintenance EngineerUser(s)Quality Assurance

I2 - Source Code Software Development Engineer (Author)Peer Software Development EngineerDetailed Designer AuthorTest EngineerSoftware Maintenance EngineerRequirements or Architectural Design AuthorQuality Assurance

IT 1 - Test Plan Test Engineer (Author)Peer Test EngineerArchitectural Design AuthorUser of the function(s) within the projectQuality Assurance


IT2 - Test Procedures Test Engineer (Author of the test cases being inspected)Individual experienced in running functional verification test casesIndividual experienced in coding user-oriented functional test

casesQuality Assurance

Other - User's Guide User's Guide Developer (Author)Peer User's Guide DeveloperSoftware Test EngineerSystems EngineerUser(s)Quality Assurance

Appendix F: Guidelines for Combining RolesIf a limited staff is available to perform the inspections, some of the Inspectors' roles can beoverlapped. The role of Reader and Recorder can be fulfilled by the same Inspector since theReader cannot continue reading/paraphrasing the work product once a Defect is located and thatDefect has been recorded. However, it is preferable to have the Author overlap as the Recorderrather than the Reader. This gives the Reader time to regain the flow of logic while the Defect isbeing recorded. If the Author takes on the additional role of Recorder, the Author must eitherread the Defects aloud at the time they are recorded or use a transparency and overhead projectorto record the Defects so that all the inspection participants can view the recording of the Defects.Lastly, the Moderator could fulfill the role of Recorder. However, the Moderator may not beable to retain adequate control of the meeting and record the Defects at the same time.Controlling the meeting is one of the main responsibilities of the Moderator.