Digicorp Code Inspection Process


Published on

This presentation describes the code inspection process done at Digicorp. It can not be called Fagan Inspection process but we have taken inspiration from the same.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Digicorp Code Inspection Process

  1. 1. Digicorp Code Inspection Process Abhishek Desai
  2. 2. History <ul><li>Michael Fagan developed the formal software inspection process at IBM in the mid 1970s, hence the term &quot;Fagan inspection&quot; . To qualify as a true inspection, the activity follows a specified process and the participants play well-defined roles. </li></ul>
  3. 3. Inspection Team <ul><li>3 – 8 people consisting of following roles </li></ul><ul><ul><li>Moderator </li></ul></ul><ul><ul><li>Author </li></ul></ul><ul><ul><li>Reader </li></ul></ul><ul><ul><li>Recorder </li></ul></ul><ul><ul><li>Inspector </li></ul></ul><ul><li>A person who is not involved in a project but who has the skill set and defect detection abilities should be there as Inspector </li></ul><ul><li>One person from QA team should also be there as Inspector </li></ul>
  4. 4. Formal Inspection Process <ul><li>Planning </li></ul><ul><ul><li>Decide the project to inspect </li></ul></ul><ul><ul><li>Identify critical modules to inspect </li></ul></ul><ul><li>Overview meeting </li></ul><ul><ul><li>Not needed if information related to project is known </li></ul></ul><ul><li>Preparation ( Sample Checklist ) </li></ul><ul><li>Inspection meeting </li></ul><ul><ul><li>Max 2 hours </li></ul></ul><ul><ul><li>Outcome </li></ul></ul><ul><ul><ul><li>Accepted </li></ul></ul></ul><ul><ul><ul><li>Accepted with minor revisions </li></ul></ul></ul><ul><ul><ul><li>Major revisions needed and second inspection required </li></ul></ul></ul><ul><li>Rework </li></ul><ul><li>Follow up </li></ul><ul><ul><li>If more than 10% of project is modified additional inspection may be required </li></ul></ul><ul><ul><li>Define exit criteria </li></ul></ul>
  5. 5. Guiding Principles <ul><li>Check your egos at door </li></ul><ul><li>Critique the product not the producer </li></ul><ul><li>Find problems during review; don’t fix them </li></ul><ul><li>Limit inspection meetings to a maximum of two hours </li></ul><ul><li>Avoid style issues unless they impact performance or understandability </li></ul><ul><li>Inspect early and often, formally and informally </li></ul><ul><li>Decide the conventions to inspect </li></ul><ul><ul><li>Source listing page by page or </li></ul></ul><ul><ul><li>Call tree </li></ul></ul>
  6. 6. Keeping Records <ul><li>Sample issue list </li></ul><ul><li>Development phase in which error was introduced </li></ul><ul><li>Severity scale </li></ul><ul><ul><li>Cosmetic </li></ul></ul><ul><ul><li>Minor </li></ul></ul><ul><ul><li>Severe </li></ul></ul><ul><ul><li>Fatal </li></ul></ul><ul><li>Describe Error detected in detail </li></ul><ul><li>Standards violations or style suggestions may apply to the entire product. </li></ul><ul><li>Summary report </li></ul>
  7. 7. Reviews and Testing <ul><li>code/inspect/compile/link/test </li></ul><ul><li>code/compile/inspect/link/test </li></ul><ul><li>code/compile/link/test/inspect/retest </li></ul>
  8. 8. Notes for Developers/Authors <ul><li>Inspection results will not be used against developers at performance appraisal time. </li></ul><ul><li>Separate your ego from your work products, everyone do need reviews, you don’t have to become defensive during the inspection meeting. </li></ul><ul><li>Participants should be prepared adequately prior to the inspection meeting. </li></ul><ul><li>The items being inspected have to be documented adequately for a reviewer to be able to understand and critique them (this is actually an inspection result in itself). </li></ul><ul><li>Make sure you are properly trained for the inspection process. Reading this manual is of utmost importance before participation. </li></ul><ul><li>Author has to take the results of the inspection seriously and make the suggested changes. </li></ul><ul><li>Inspection meetings should not lose their focus. It should not wander into interesting discussions about technical solutions, and fail to cover the scheduled material. </li></ul><ul><li>The project schedule should incorporate time for inspections. </li></ul>
  9. 9. Happy Coding!