1 / 40

Quality Management Peer Review

Quality Management Peer Review. Supannika Koolmanojwong CSCI577. Outline. Quality Management In CMMI 1.3 In ISO 15288 In CSCI577ab. Objectives of QM. To ensure the high quality process in order to deliver high quality products. Quality Management in CMMI 1.3.

wei
Download Presentation

Quality Management Peer Review

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. Quality ManagementPeer Review Supannika Koolmanojwong CSCI577

  2. Outline • Quality Management • In CMMI 1.3 • In ISO 15288 • In CSCI577ab (c) USC-CSSE

  3. Objectives of QM • To ensure the high quality process • in order to deliver high quality products (c) USC-CSSE

  4. Quality Management in CMMI 1.3 (c) USC-CSSE

  5. PPQA - Product and Process Quality Assurance (c) USC-CSSE

  6. PPQA - Product and Process Quality Assurance (c) USC-CSSE

  7. PPQA for Agile development (c) USC-CSSE

  8. CM – Configuration Management (c) USC-CSSE

  9. CM – Configuration Management (c) USC-CSSE

  10. CM – Configuration Management (c) USC-CSSE

  11. MA – Measurement and Analysis (c) USC-CSSE

  12. VER - Verification (c) USC-CSSE

  13. VER - Verification (c) USC-CSSE

  14. VAL - Validation (c) USC-CSSE

  15. VAL - Validation (c) USC-CSSE

  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. (c) USC-CSSE

  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. (c) USC-CSSE

  18. Quality Management in 577ab • IIV&V • Configuration Management • Defect Reporting and Tracking • Testing • Buddy Review • Architecture Review Board • Core Capability Drive through • Design Code Review • Document template • Sample artifacts (c) USC-CSSE

  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 (c) USC-CSSE

  20. Coding Guidelines • C: http://www.gnu.org/prep/standards/standards.html • C++ : http://geosoft.no/development/cppstyle.html • Java: http://geosoft.no/development/javastyle.html • Visual Basic: http://msdn.microsoft.com/en-us/library/h63fsef3.aspx (c) USC-CSSE

  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 (c) USC-CSSE

  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, IIV&V, Automated Analysis (c) USC-CSSE

  23. Peer Review • Reviews performed by peers in the development team • Can be from Fagan’s inspections to simple buddy checks • Peer Review Items • Participants / Roles • Schedule (c) USC-CSSE

  24. Defect Classification • Severity : Major/ Minor • Type: Missing / Wrong / Extra • Category • Logic , Syntax, Clarity. Performance, Interface, … (c) USC-CSSE

  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.  (c) USC-CSSE

  26. Orthogonal Defect Classification http://www.research.ibm.com/softeng/ODC/DETODC.HTM (c) USC-CSSE

  27. (c) USC-CSSE

  28. (c) USC-CSSE

  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 (c) USC-CSSE

  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 (c) USC-CSSE

  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 (c) USC-CSSE

  32. Avoidable defects • Changes in analysis, design, code or documentation arising from human error • Can be avoided though better analysis, design, training (c) USC-CSSE

  33. Product Assurance • Requirements Verification • IIV&V • Automated Analysis (c) USC-CSSE

  34. Configuration Management • Configuration items and rationale • Identification systems • Storage of configuration items • Configuration Controls • Status and accounting • Baselining events (c) USC-CSSE

  35. Defect and Change Management • Processes • Change Control Board (c) USC-CSSE

  36. COQUALMO •  Cost, Schedule and Quality (c) USC-CSSE

  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 (c) USC-CSSE

  38. Coding defects introduction range (c) USC-CSSE

  39. Defect Removal Profiles (c) USC-CSSE

  40. Partion of COQUALMO Rating Scale COCOMO II p.263 (c) USC-CSSE

More Related