Presentation on theme: "Process and Product Quality Assurance (PPQA) Intermediate Concepts of CMMI Presentation Assignment Nicolae Giurescu."— Presentation transcript:
Process and Product Quality Assurance (PPQA) Intermediate Concepts of CMMI Presentation Assignment Nicolae Giurescu
Importance of PPQA Provides objective insight into processes and associated work products. –Visibility into projects processes. –Objective evaluations. Independent group. Defined criteria. –Identifying, documenting and resolving noncompliance issues.
Benefits of PPQA Supports delivery of high-quality products and services. Provides feedback on projects processes implementation. Identifies opportunities for process improvement. Identifies dead processes, that exists only in the process documentation.
PPQA Depends on … Project Planning –For identifying processes and associated work products that will be objectively evaluated. Verification –For more information about satisfying specified requirements. Peer reviews Inspections Tests, …
PAs that Depend on PPQA ALL the rest. –For objective feedback into processes and associated work products and services, regarding their conformance to applicable process descriptions, standards and procedures. –For ensuring that the noncompliance issues are addressed.
Ordering of SPs in PPQA SG 1 Objectively Evaluate Processes and Work Products. –SP 1.1 Objectively Evaluate Processes. –SP 1.2 Objectively Evaluate Work Products and Services. SG 2 Provide Objective Insight. –SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues. –SP 2.2 Establish Records. Note: Can be concurrent and repetitive.
Critical SPs in PPQA - 1 In communicating the noncompliance issues it is important to focus on data, not cause, and never on assigning blame. SP Communicate and Ensure Resolution of Noncompliance Issues. –Sub practice 1, Resolve each noncompliance with the appropriate members of the staff where possible. –Sub practice 2, Escalate noncompliance issues that cannot be resolved within the project to the appropriate level of management designed to receive and act on noncompliance issues.
Critical SPs in PPQA - 2 Records of PPQA activities are prime sources for process improvement and lessons learned. SP Establish records. –Sub practice 1, Record process and product quality assurance activities in sufficient detail such that status and results are known. –Sub practice 2, Revise the status and history of the quality assurance activities as necessary.
Generic Practices and PPQA GPs with special significance: –GP 2.2 Plan the Process –GP 2.3 Provide Resources –GP 2.4 Assign Responsibility –GP 2.5 Train the People –GP 2.7 Identify and Involve Relevant Stakeholders –GP 2.10 Review Status with Higher Management !!! PPQA implements GP 2.9 Objectively Evaluate Adherence, for all other PAs
QA Actions vs. Project Expectations - 1 Coaching and support for the R&D process institutionalization and milestones preparation (inputs, objectives, outputs). Document reviewing and dedicated processes structuring reviewing activities –System Design Specifications –Requirements Traceability –Software Test Plan, …
QA Actions vs. Project Expectations - 2 Quality Assurance Plan –Definition / Customization of specific projects processes: Defect tracking Project tracking Design change Risk management –List of QA tasks planned for the project Noncompliance management
Broken Traceability Matrix Problem: X % of bad links from requirements to design in subsequent documentation baselines Quick fix: verify all and correct bad links Root causes: –Links to old versions –Lack of time to properly update the traceability Solution Migrate from Word to DOORS Store in the same database all engineering specs
Forgotten Requirement Changes Problem: X% of requirement changes not reflected into the design and test cases Quick fix: –Rework if possible –Report the change to future versions Root causes: –Changes not communicated –Changes occurred to late to be considered Solution: Automatic notification Joint requirement reviews
Unmanaged Defect Reports Problem: defects discovered during the development phase were solved in an ad-hoc way Quick fix: none considered Root causes: –No system to manage defects during development Solution: Start managing defects during development, same way as during maintenance
Being Late Problem: X% of missed schedule milestones Quick fix: –Revised schedule Root causes: Imposed schedule milestones –Ever changing WBS –Wrong task estimations –Insufficient resources Solution: Incremental integration and development plan
50% of issues are related to process problems that have been corrected