1 / 18

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

TCTI-V2CCPP1-10 C en C++ Programmeren Week 3, les 1 : Inspection (Fagan style). Creating something. No requirements No control or feedback. Make!. A result. Creative process. Creating a product. Check it!. Make it!. Inspection. Feedback. Creative process. The result.

chibale
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Creating something • No requirements • No control or feedback Make! A result Creative process

  3. Creating a product Check it! Make it! Inspection Feedback Creative process The result

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

  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. 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. 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. 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. 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. Defect list • 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. 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. 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. 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. Fagan assignment 1 - input • You will all inspect a game conceptdocument. • The requirements documents are the Game conceptdocumentspecificaties 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. Fagan assignment 1 – specialist roles • Author • Are all requirements from the Game conceptdocumentspecificaties fulfilled? During the session: do I understand all defects found by the others? • User • Is an interesting game (for the intended audience)? • Techie • Are the technical requirements fulfilled, and are they achievable? • 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. Fagan assignment 1 – output Each inspector Annotates micro deficiencies on his hardcopy of the input document. 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.

More Related