Presentation is loading. Please wait.

Presentation is loading. Please wait.

W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)

Similar presentations


Presentation on theme: "W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)"— Presentation transcript:

1 W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)

2 W 3 L 1 sh 2 Creating something Make! n No requirements n No control or feedback Creative process A result

3 W 3 L 1 sh 3 Creating a product Make it! Check it! Creative process Inspection Feedback The result

4 W 3 L 1 sh 4 Fagan inspection - principles  A product (document, source file,..) has been created,  according to a set of requirements.  Someone wants to make sure that the product meets the requirements.  The author is basically competent but not perfect.  Inspection is NOT used for:  Rating the author  Assigning blame

5 W 3 L 1 sh 5 Fagan inspection - goals  Either:  state that the product is (sufficiently!) conform the requirements, or  produce a list of non-conformities (and iterate: creative process, inspection) Secondary goals:  Improve standards, requirements and processes  Learn from your peer’s work

6 W 3 L 1 sh 6 Fagan inspection - steps 1. The mandate for creating the product is established. 2. Requirements are established. 3. The author writes the document. 4. The moderator and inspectors are appointed, tasks are assigned, budget (inspection rate) is established. 5. The inspectors inspect, each on their own. They note the defects (non-conformities) they find. 6. In a moderated round-table session the defects are presented, duplicates are deleted, limited discussion is possible. Defense is not! 7. The author re-works the document according to the defects lists. 8. Depending on the severities, the document is finalized, or a new inspection is held.

7 W 3 L 1 sh 7 Step 1 : mandate A basic principle! (see also prince2): the mandate must come first. Mandate must include some guidelines as to what is to be done, and a budget to do it. This is mostly outside the scope of the author and the inspection team.

8 W 3 L 1 sh 8 Step 2 : requirements A defect is by definition a “failure to conform to a requirement”, so without requirements there can be no defects.* It is the job of the one who starts the (sub) project to establish the requirements. Note: it is NOT the job of the author! Requirements must be numbered, so a defect can refer to a specific requirement. * Without requirements you can submit an empty document. Or “main(){}”.

9 W 3 L 1 sh 9 Step 3 : the document The document is prepared and presented to the moderator. The moderator performs a limited (a few minutes) check to prevent wasting everyone's time. It must be possible to refer to a specific part of the document, so it must have page numbers and line numbers (!). Note: in word you can enable line numbers, or you can use a ‘vertical ruler’ as background. Neither is ideal, but it will do.

10 W 3 L 1 sh 10 Step 4 : participants, tasks The moderator is an independent guardian of the process, often from a different department (can be QA). The inspectors can be assigned according to the aspects that are deemed important. For instance for a subsystem design document:  A system designer to check that the subsystem fits within the overall design;  A programmer to check that the design can be implemented;  A tester to check that the design can be tested. Each inspector is allocated a time budget (typically 20 pages/hour), and a task to concentrate on.

11 W 3 L 1 sh 11 Step 5 : inspection Each inspector carefully reads the document and notes any defects he finds. For each defect he notes on a defect list form:  The severity  Its location in the document (page, line)  The requirements document (if there is more than one) and the requirement to which it fails to conform  If needed, a short description of the defect.  Defects must be in the order in which they appear in the document (= sorted by page/line).

12 W 3 L 1 sh 12 Defect list SeverityLocationRequirementDescription m12, 23CodeStd 12.7The } is one level too deep M18, 55ReqDoc 18.9.4-7The required screen refersh rate will not be met when the whole screen is refreshed each iteration. M = Major defect:  Not solving this defect will cost the company money.  The repair work on this defect should be re-checked. m = minor defect:  This looks unprofessional, but it won’t cause costly trouble.  It might be wrong, but everyone will read what is meant.  I trust the author to do what is appropriate.

13 W 3 L 1 sh 13 Defect list – off the scale G = Giga major defect:  Anything that puts the rework of the document at risk. The author is not competent, the requirement documents are totally wrong, the company has dropped this line of work, this is against the law, etc.  This should be very rare! Follow-up is often on the moderator, or on the initiator of the document, rather than on the author. M = Major m = minor µ = micro  Layout issues, misspelling, non-optimal wording, punctuation. etc.  Don’t put this on your defect list, just annotate your copy of the document and hand it over to the author.

14 W 3 L 1 sh 14 Step 7 : session The moderator holds a round-table session with the author and all inspectors. The document is scanned (page-by-page, or even line- by-line), each inspector mentions the defects he deems important enough to mention. The aim is that the author understands what the inspectors mean, NOT that he agrees with them. The only discussion that is allowed is to get the opinion of the inspector clear. Clarification of the document is not allowed (the document should speak for itself). The moderator receives the defects lists, notes the statistics, hands copies to the author.

15 W 3 L 1 sh 15 Step 8 : rework, finalization The author re-works the document. Handling of micro and minor defects is his responsibility. The reworking of major defects can require a check by the inspector or the moderator. The author presents the reworked document to the moderator. The moderation checks that all majors are appropriately corrected. Depending on the amount and severity of the defects the document is either finalized (gets the moderators OK stamp) or it enters a re-inspection.

16 W 3 L 1 sh 16 Fagan assignment 1 - input  You will all inspect a game conceptdocument.  The requirements documents are the Game conceptdocument specificaties and the Basic document requirements (can be found on sharepoint).  Inspection time is the allotted time for the assignment.  Four inspectors inspect each document. They each fill in a defect form.  The defect form template can be found on sharepoint.  Each inspector basically checks the full document on all aspects, but there are ‘specialist’ roles.

17 W 3 L 1 sh 17 Fagan assignment 1 – specialist roles 1. Author Are all requirements from the Game conceptdocument specificaties fulfilled? During the session: do I understand all defects found by the others? 2. User Is an interesting game (for the intended audience)? 3. Techie Are the technical requirements fulfilled, and are they achievable? 4. Moderator Is it conform the Basic document requirements The ‘author’ is a person from the group that wrote the conceptdocument, the others are from other groups.

18 W 3 L 1 sh 18 Fagan assignment 1 – output Each inspector 1. Annotates micro deficiencies on his hardcopy of the input document. 2. Enters minor, major (and giga) defects on the defect form. Prints a hardcopy of this defect form. The next assignment will be a Fagan Inspection session. You will need the above documents (and the requirement documents) for that session.


Download ppt "W 3 L 1 sh 1 TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style)"

Similar presentations


Ads by Google