Quality Management Systems Review Techniques Karl Heinrich Möller Gaertnerstr. 29

1. Quality Management Systems Review Techniques Karl Heinrich Möller Gaertnerstr. 29 D-82194 Groebenzell Tel: +49(8142)570144 Fax: +49(8142)570145 Email: karl-heinrich.moeller@t-online.de

2. The Hidden Factory Rework Production -V. Feigenbaum-

3. Formal Process Definitions Objectives List of products or services that must be delivered by the operation – including operational constraints (e. g. effort, head-count, elapsed time, etc.) Entry Criteria For each objective, the items that are required to commence the operation (and standards of acceptance of each one) Exit Criteria For each objective, the items that must be delivered by the operation (and standards of acceptance of each one) Function For each objective, the work process within the operation that must be executed to convert input items (that satisfy ENTRY CRITERIA) into output items (that meet the EXIT CRITERIA) while meeting objective/operational criteria Note: ENTRY CRITERIA (and standards of acceptance) and EXIT CRITERIA (and standards of acceptance) must be agreed with supplier and customer operations, respectively

4. Formal Process Definition OBJECTIVES (WHAT must be done) EXIT CRITERIA ENTRY CRITERIA • FUNCTIONS • (HOW each OBJECTIVE • will be accomplished) • Mini-Process • Method & Tools • Resources/Skill Levels

5. Costs per Default Life-cycle default rework costs Typical cost per default (Person.Hours) Small System Program Program Requirements - IR 1 1 High Level Design - I0 1 Low Level Design - I1 1 Code - I2 1 1 Unit Test 3 4 Function Test 5 7 System/Acceptance Test 12 20 Field/in use 20+ 30+

6. Metrics - Size Non-Commentary Source Statements = NCSSThe Sum of executable code instructions and declaratives. Instructions that invoke Macros are counted once only. Expanded macro instructions are also counted only once. Comments are not included.NCSS will be used as „Lines-Of-Code“ (LOC)When Statement Sizes are mentioned during pre-code Phases, they are estimates Other Measures sometimes used Executable Statements „Card Image“ Statements ..Etc... Sometimes including Commentary „Function Points“ Note: Each of he above measures arouse some controversy. However, consistent use of any one metric throughout the life-cycle does enable progress.

7. Objective of Inspection To find every deviation from the EXIT CRITERIA EXIT CRITERIA are the requirements of the operation that the work product must meet. Each deviation from Requirements is a default

8. Purpose of Inspection Find defects immediately after they are caused Reduce defect rework to a minimum Reduce impact of defect rework on later schedules Measure work product against EXIT CRITERIA to determine whether an operation is complete. - To give real measurement against project management check-points Provide Data from the earliest work product for improvement of the development process Provide Software authors the quickest feed-back on defects & how to recognize and avoid them in future

9. Development Process and Inspection Requirements IR Inspection High Level Design I0 Inspection Test Plan Low Level Design IT1 I1 Inspection Code I2 Inspection Test Cases IT2 Unit Test Function Test Component Test User Documentation PI0 System Test PI1 PI2 Deployment

10. Exit Criteria for High Level Design I0 Inspection There may be 20 items in these Exit Criteria, including (Note qualification/quantification of attributes, wherever possible): Design satisfies product requirements Design satisfies the objectives of the high level design operation Level of detail (or level of abstraction) One Design statement will generate 15-25 NCSS Control flow down to the module name level Control block structure defined down to the field name level only All rework from I0 completed and verified

11. 6-Step Inspection Process Operation Objective 1. Planning Materials meet entry criteria Participants, Roles Schedule Meeting place 2. Overview Group Education 3. Preparation Individual Preparation to fulfil assigned roles 4. Inspection Find defects 5. Rework Rework all defects 6. Follow-up Verify all defects resolved

12. Inspectors and their Roles Each role has a unique function to perform Moderator - manages the team through the 6-step inspection process, while playing an active role as an inspector. (Pre-requisite is competence in programming, ability to be tactful, diplomatic, forceful and work well with others) Author - Creator of the product or specification that is being inspected. Vested interest is to ensure that the product completely meets exit criteria without ambiguity. Reader(s) - Usually a developer. Reads the code or spec. - expresses in his/her own words what each statement means - with a level of understanding that they would need to implement it. (This is Step-4 of the inspection process).If the Req. Spec. includes product externals, an intended end-user should also read through typical work scenarios during Step-4 while utilizing the externals. (Externals and work scenarios must make sense together) Tester - Will consider testability, interactions with other products/systems, and performance implications

13. Schedule/Resource Changes due to Inspections Resource Without inspections Inspection & Rework Time Inspections use 15% of net resource and are front-end loaded Inspections reduce net resource 10 - 40% and usually shorten (never lengthen) schedule Schedule With inspections

14. Uses of Inspection Data Acceptability of product - or reinspect / rework ? Feed-Back Programmers learn to avoid making defects Development process problem identification Inspection process problem identification Feed-Forward Product does / does not meet Entry Criteria of the next operation Defect rate distribution used to identify defect prone code

15. Abuses of Inspection Data Personnel Performance Appraisal Use the faults found in testing instead. This provides incentive to clean out all the defects using inspection. A single use of inspection data against a person will set-back or perhaps ruin implementation of the process. Management sometimes wish to participate in inspections for technical reasons. If their presence impairs team synergy, they should leave/not attend.

16. Fagan Inspections Fagan Inspections and Performance Appraisal - Manager‘s Pact with developers - 1. My job is to help you advance your career. 2. Your job includes letting me know how I can help you advance your career. How can I help you do better? 3. Your career advancement depends upon how well you perform your present assignment. 4. Your performance will NOT be judged by the number of defects found in inspections. 5. Defects found by testing by others or by downstream operations WILL contribute to your performance appraisal.(These defects WILL also contribute to my performance appraisal) Signed:___________________________ Date: __________ Manager, Department:________________________________________

17. Exit Criteria Problem: Incomplete and non-specific Exit Criteria postpones tasks to be handled by later operations, which require much higher level of resource to resolve - because later operations are designed to satisfy different objectives IDEA/Proposal: Develop specific complete and unambiguous definitions for all exit criteria items for all development. Benefits: Maximum resource will be needed to execute the complete process - because each process operation will accomplish what it is designed to do most effectively. Action: Develop Exit Criteria ....... Your next assignment.

18. Design Change Control - Design Change- Is any addition, deletion or modification to already certified (inspected) Requirements, Design or Code (where the change affects design). Includes fixes for defects found by inspection or test Originates from any operation in the Life-cycle process. I.E. Requirements, Design Improvement, Defect Rework or adaptive/enhancement/corrective Maintenance

19. Design Change Control Process (1) Generally Required Characteristics 1. Anyone (including the user ) can originate a design change request. 2. Design change is initiated when any certified (inspected/verified) Level of design must be changed. E.g. after Is, Io or in test, etc. 3. Format of design change request includes Problem Statement (Description of what the user needs and purpose of the change) Description of the solution, if known Components, Modules Documents affected Impact size estimates (e.g. NCSS, Bytes) Estimated resource required Schedule dates (Start, inspection dates, test dates, completion) Manager and Programmer responsible

20. Design Change Control Process (2) Generally Required Characteristics 4. Approval is required of a forum of managers, user and designers/system analysts before changing any certified level of design. 5. Design changes are often bunched by function. 6. Each approved design change is tracked through all steps of its implementation (i. e. design, inspection, coding, inspection, test and installation) in the same way as a product.