Rationale: Roles are assigned with the objective of increasing both an individual”s Productivity, and the SQC team”s Productivity. Productivity in SQC is measured by the number of Major Issues per page found by the team (Effectiveness). Roles can however be assigned to support any current, local objective of the SQC Process (for example, training). Effective assignment of roles permits each Checker to find a relatively large number of unique Issues. It can also enable a larger volume in total of Documentation to be checked during the SQC (as Checkers can be role-assigned to use different sets of Documentation).
1. Roles ensure the Documentation is checked from several different perspectives. Roles can be roughly classified as follows:
• Stakeholder – using a Checklist, Check from a particular Stakeholder viewpoint (like “tester”)
• Document or territory – “where” the Checking shall take place
• Defect Type – what kinds of Defects are we to especially look for (use Rules and Checklists)
The Team-Leader can plan the Checking to concentrate on specific Stakeholder views (Stakeholder roles) and/or specific Documents (Document roles). The Team-Leader might first assign Stakeholder view roles with their associated Rules. They then might decide which Documents to assign to each Role. Finally, they might consider whether any of the Documents require special attention and assign additional Document roles (and Rules) accordingly. Examples of Stakeholder view roles are user, tester, designer, maintainer, legal advisor and marketing. An example of a Document Role would be to spend more effort on Checking that the marketing plan, a source Document, is consistent with the Rules.
2. Roles are for use during the Checking Sub-Process and are agreed during Kickoff. In the Specification-Meeting, if “double checking” is carried out during the Specification-Meeting, roles would again apply and might be intentionally modified.
This Concept entered by Adore
Table of contents: