Quality Management Peer Review

1
Quality ManagementPeer Review

• Supannika Koolmanojwong
• CSCI577

2
Outline

• Quality Management
• In CMMI 1.3
• In ISO 15288
• In CSCI577ab

3
Objectives of QM

• To ensure the high quality process
• in order to deliver high quality products

4
Quality Management in CMMI 1.3
Process Areas Process Areas
Configuration Management (CM) Product Integration (PI)
Causal Analysis and Resolution (CAR) Project Monitoring and Control (PMC)
Decision Analysis and Resolution (DAR) Project Planning (PP)
Integrated Project Management (IPM) Quantitative Project Management (QPM)
Measurement and Analysis (MA) Requirements Development (RD)
Organizational Performance Management (OPM) Requirements Management (REQM)
Organizational Process Definition (OPD) Risk Management (RSKM)
Organizational Process Focus (OPF) Supplier Agreement Management (SAM)
Organizational Process Performance (OPP) Technical Solution (TS)
Organizational Training (OT) Validation (VAL)
Process and Product Quality Assurance (PPQA) Verification (VER)
5
PPQA - Product and Process Quality Assurance
6
PPQA - Product and Process Quality Assurance
7
PPQA for Agile development
8
CM Configuration Management
9
CM Configuration Management
10
CM Configuration Management
11
MA Measurement and Analysis
12
VER - Verification
13
VER - Verification
14
VAL - Validation
15
VAL - Validation
16
Quality Management in ISO 15288

• Activities
• Plan quality management.
• Establish quality management policies
• Establish organization quality management
  objectives
• Define responsibilities and authority for
  implementation of quality management.
• Assess quality management.
• Assess customer satisfaction and report.
• Conduct periodic reviews of project quality
  plans.
• The status of quality improvements on products
  and services is monitored.
• Perform quality management corrective action.
• Plan corrective actions when quality management
  goals are not achieved.
• Implement corrective actions and communicate
  results through the organization.

17
Configuration Management in ISO 15288

• Activities
• Plan configuration management.
• Define a configuration management strategy
• Identify items that are subject to configuration
  control.
• Perform configuration management
• Maintain information on configurations with an
  appropriate level of integrity and security
• Ensure that changes to configuration baselines
  are properly identified, recorded, evaluated,
  approved, incorporated, and verified.

18
Quality Management in 577ab

• IIVV
• Configuration Management
• Defect Reporting and Tracking
• Testing
• Buddy Review
• Architecture Review Board
• Core Capability Drive through
• Design Code Review
• Document template
• Sample artifacts

19
Quality Guidelines

• Design Guidelines
• Describe design guidelines on how to improve or
  maintain modularity, reuse and maintenance
• How the design will map to the implementation
• Coding Guidelines
• Describe how to document the code in such as way
  that it could easily be communicated to others

20
Coding Guidelines

• C http//www.gnu.org/prep/standards/standards.htm
  l
• C http//geosoft.no/development/cppstyle.html
• Java http//geosoft.no/development/javastyle.html
  
• Visual Basic
• http//msdn.microsoft.com/en-us/library/h63fsef3.a
  spx

21
Quality Guidelines

• Version Control and History
• Chronological log of the changes introduced to
  this unit
• Implementation Considerations
• Detailed design and implementation for as-built
  considerations
• Unit Verification
• Unit / integration test
• Code walkthrough / review / inspection

22
Quality Assessment Methods

• Methods, tools, techniques, processes that can
  identify the problems
• Detect and report the problem
• Measure the quality of the software system
• Three methods of early defect identification
• peer review, IIVV, Automated Analysis

23
Peer Review

• Reviews performed by peers in the development
  team
• Can be from Fagans inspections to simple buddy
  checks
• Peer Review Items
• Participants / Roles
• Schedule

24
Defect Classification

• Severity Major/ Minor
• Type Missing / Wrong / Extra
• Category
• Logic , Syntax, Clarity. Performance, Interface,

25
Defect terminologies

• Activity This is the actual activity that was
  being performed at the time the defect was
  discovered.
• Trigger The environment or condition that had to
  exist for the defect to surface. What is needed
  to reproduce the defect?
• Impact For in-process defects, select the impact
  which you judge the defect would have had upon
  the customer if it had escaped to the field. 

26
Orthogonal Defect Classification
Target Defect Type Triggers Impact Severity Qualifier
Operational Concept / Requirements Correctness Completeness Consistency Clarity / Testability Traceability Design Conformance Logic/ Flow Backward Compatibility Lateral Compatibility Concurrency Internal Document Language Dependency Side Effect Rare Situations Simple Path Complex Path Coverage Variation Sequencing Interaction Workload/Stress Recovery/Exception Startup/Restart Hardware Configuration Software Configuration Blocked Test (previously Normal Mode) Installability Serviceability Standards Integrity/Security Migration Reliability Performance Documentation Requirements Maintenance Usability Accessibility Capability Major Minor Missing Wrong / Incorrect Extra
Design / Code Assign/Init Checking Alg/Method Func/Class/Object Timing/Serial Interface/O-O Messages Relationship Design Conformance Logic/ Flow Backward Compatibility Lateral Compatibility Concurrency Internal Document Language Dependency Side Effect Rare Situations Simple Path Complex Path Coverage Variation Sequencing Interaction Workload/Stress Recovery/Exception Startup/Restart Hardware Configuration Software Configuration Blocked Test (previously Normal Mode) Installability Serviceability Standards Integrity/Security Migration Reliability Performance Documentation Requirements Maintenance Usability Accessibility Capability Major Minor Missing Wrong / Incorrect Extra
http//www.research.ibm.com/softeng/ODC/DETODC.HTM
27
Opener Section (These attributes are usually available when the defect is opened.) Opener Section (These attributes are usually available when the defect is opened.) Opener Section (These attributes are usually available when the defect is opened.)
Defect Removal Activities Triggers Impact
Design Rev, Code Inspection, Unit test, Function Test, System Test. Design Conformance Logic/ Flow Backward Compatibility Lateral Compatibility Concurrency Internal Document Language Dependency Side Effect Rare Situations Simple Path Complex Path Coverage Variation Sequencing Interaction Workload/Stress Recovery/Exception Startup/Restart Hardware Configuration Software Configuration Blocked Test (previously Normal Mode) Installability Serviceability Standards Integrity/Security Migration Reliability Performance Documentation Requirements Maintenance Usability Accessibility Capability  
28
Closer Section (These attributes are usually available when the defect is fixed.) Closer Section (These attributes are usually available when the defect is fixed.) Closer Section (These attributes are usually available when the defect is fixed.) Closer Section (These attributes are usually available when the defect is fixed.) Closer Section (These attributes are usually available when the defect is fixed.)
Target Defect Type Qualifer Age Source
Design/Code Assign/Init Checking Alg/Method Func/Class/Object Timing/Serial Interface/O-O Messages Relationship Missing Incorrect Extraneous Base New Rewritten ReFixed Developed In-House Reused FromLibrary Outsourced Ported
29
Requirement Defect Type (1/2)

• A requirements defect is an error in the
  definition of system functionality
• Correctness Wrongly stated requirements
• Examples
• An incorrect equation, parameter value or unit
  specification
• A requirement not feasible with respect to cost,
  schedule and technology
• Completeness Necessary information is missing
• Examples
• Missing attributes, assumptions, and constraints
  of the software system.
• No priority assigned for requirements and
  constraints.
• Requirements are not stated for each iteration or
  delivery

30
Requirement Defect Type (2/2)

• Consistency A requirements that is inconsistent
  or mismatched with other requirements
• Examples
• requirements conflict with each other
• Requirements are not consistent with the actual
  operation environment (eg. Test, demonstration,
  analysis, or inspection) have not been stated.
• Traceability A requirement that is not traceable
  to or mismatched with the user needs, project
  goals, organization goals

31
Unavoidable defects

• Changes arising because of
• The dynamic of learning
• Exploration in IKIWIKI situations
• Code or screen content reorganization taken on as
  an afterthought
• Replacement of stubs of placeholders in code

32
Avoidable defects

• Changes in analysis, design, code or
  documentation arising from human error
• Can be avoided though better analysis, design,
  training

33
Product Assurance

• Requirements Verification
• IIVV
• Automated Analysis

34
Configuration Management

• Configuration items and rationale
• Identification systems
• Storage of configuration items
• Configuration Controls
• Status and accounting
• Baselining events

35
Defect and Change Management

• Processes
• Change Control Board

36
COQUALMO

•  Cost, Schedule and Quality

37
Current COQUALMO System
COCOMO II
Software development effort, cost and schedule
estimate
COQUALMO
Software Size Estimate
Defect Introduction Model
Software platform, Project, product and personnel
attributes
Number of residual defects Defect density per
unit of size
Defect Removal Model
Defect removal profile levels Automation,
Reviews, Testing
38
Coding defects introduction range
39
Defect Removal Profiles
40
Partion of COQUALMO Rating Scale
COCOMO II p.263
Very Low Low Nominal High Very High Extra High
Automated Analysis Simple compiler syntax checking Basic compiler capabilities Compiler extension Basic req. and design consistency Intermediate-level module Simple req./design More elaborate req./design Basic dist-processing Formalized specification, verification. Advanced dist-processing
Peer Reviews No peer review Ad-hoc informal walk-through Well-defined preparation, review, minimal follow-up Formal review roles and Well-trained people and basic checklist Root cause analysis, formal follow Using historical data Extensive review checklist Statistical control
Execution Testing and Tools No testing Ad-hoc test and debug Basic test Test criteria based on checklist Well-defined test seq. and basic test coverage tool system More advance test tools, preparation. Dist-monitoring Highly advanced tools, model-based test