Transcript Process and Product Quality Assurance

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 project’s 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 project’s 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 2.1-1 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 2.1-2 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 project’s
processes:
•
•
•
•
Defect tracking
Project tracking
Design change
Risk management
– List of QA tasks planned for the project
• Noncompliance management
QA Mode
Plan
Describe
Verification
Execute
SDS
Design &
Implementation
RM
SWRS
SWTP
SWTD
SWIVTP
SWIVTD
SWTR
SWIVTR
TLA
SW
Release
HLD
DD
IMPL
Legend:
TLA: Top-level Architecture
HLD: High-level Design
DD: Detailed Design
IMPL: Implementation
IMPL
<Released>
SWP Review
CR
Change Management
SWDP
Schedules
Project Management <Project Scope Inputs>
SCMP
SCML
SW Configuration Management <Project Scope Inputs>
Release
Sheet
PPQA Reports
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 e-mail 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
Audit interne pour 2002
2002 Internal Audits
35
30
Quantité/Quantity
30
25
20
15
11
10
7
5
0
Fabrication/
Manufacturing
R&D
4
4
4
Service technique/
Technical Service
Vente et
Commercialisation/
Sales & Marketing
Autre/Other
Total
50% of issues are related to process problems that have been corrected
PRICE OF NON CONFORMANCE
$20,000,000
$15,000,000
$10,000,000
$5,000,000
$0
1
2
3
4
5
6
YEAR
1997
1998
1999
2000
2001
2002
PONC
16,591,847
18,831,888
11,065,418
15,001,036
10,529,454
6,501,548
Thank you!