© Mahindra Satyam 2009 Defect Management and Prevention QMS Training.

Slides:



Advertisements
Similar presentations
Project Management Concepts
Advertisements

Process and Product Quality Assurance (PPQA)
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
More CMM Part Two : Details.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
Corrective & Preventive Action Programme l Corrective and preventive action managed by one programme l Closely linked to the internal audit programme l.
Root Cause Analysis Procedure (IMSP525) Training
Project Integration Management Sections of this presentation were adapted from A Guide to the Project Management Body of Knowledge 4 th Edition, Project.
SE 450 Software Processes & Product Metrics 1 Defect Removal.
ENERGETIC MATERIALS Co. Root Cause Analysis Guidelines 1.
Project Management Basics
Root Cause Analysis: Why? Why? Why?
ISO 9000 Certification ISO 9001 and ISO
SystematicSystematic process that translates quality policy into measurable objectives and requirements, and lays down a sequence of steps for realizing.
Overview of DMAIC A Systematic Framework for Problem Solving
Photocopies Occasionally need uncontrolled copies
Problem Management SDG teamIT Problem Management Process 2009 Client Services Authors: M. Begley & R. Crompton, Client Services.
4. Quality Management System (QMS)
Project Lifecycle Section 6 - Closeout. Project Manager’s Role During Project Close-Out  Ensure that all project deliverables have been completed and.
What is Business Analysis Planning & Monitoring?
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
 A project is “a unique endeavor to produce a set of deliverables within clearly specified time, cost and quality constraints”
Module 8: Risk Management, Monitoring and Project Control We would like to acknowledge the support of the Project Management Institute and the International.
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
© Mahindra Satyam 2009 Project Metrics QMS Training.
COMPGZ07 Project Management Presentations Graham Collins, UCL
PMP® Exam Preparation Course
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
Project Planning QMS Training.
Why do we … Life cycle processes … simplified !!!.
Software Quality Assurance Lecture #2 By: Faraz Ahmed.
SacProNet An Overview of Project Management Techniques.
Project monitoring and Control
Project Tracking and Monitoring QMS Training. 2 Objective To track and monitor the progress of the project and take appropriate corrective actions to.
Georgia Institute of Technology CS 4320 Fall 2003.
© Mahindra Satyam 2009 Project Initiation QMS Training.
© Mahindra Satyam 2009 QMS Training Conducting Contract Review.
Setting up a Course and using the Course Tutor Guide Workshop A Kim Tree.
© Mahindra Satyam 2009 Configuration Management QMS Training.
ISO NON-CONFORMANCE, CORRECTIVE AND PREVENTIVE ACTION.
© Mahindra Satyam 2009 Risk Management QMS Training.
© Mahindra Satyam 2009 QMS Overview- DH/RH Module.
1 TenStep Project Management Process ™ PM00.9 PM00.9 Project Management Preparation for Success * Manage Quality *
Project quality management. Introduction Project quality management includes the process required to ensure that the project satisfies the needs for which.
1 EMS Fundamentals An Introduction to the EMS Process Roadmap AASHTO EMS Workshop.
Estimation QMS Training. Objective To arrive at accurate estimates for the project Mahindra Satyam Confidential2.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
Evaluate Phase Pertemuan Matakuliah: A0774/Information Technology Capital Budgeting Tahun: 2009.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Economic Justification. Good Enough Quality Time to market Time to market Time to profit Time to profit.
TOTAL QUALITY MANAGEMENT
QMS Training TM Module.
~ pertemuan 4 ~ Oleh: Ir. Abdul Hayat, MTI 20-Mar-2009 [Abdul Hayat, [4]Project Integration Management, Semester Genap 2008/2009] 1 PROJECT INTEGRATION.
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
WORKSHOP ON ACCREDITATION OF BODIES CERTIFYING MEDICAL DEVICES INT MARKET TOPIC 9 CH 8 ISO MEASUREMENT, ANALYSIS AND IMPROVEMENT INTERNAL AUDITS.
© Mahindra Satyam 2009 Inspections and Reviews QMS Training.
Project Management PTM721S
Software Quality Control and Quality Assurance: Introduction
Causal Analysis & Resolution (CAR) Support Category
Global 8D Problem Solving
9/18/2018 Department of Software Engineering and IT Engineering
Software Quality Engineering
QUALITY ASSURANCE “Go High or Go Home!”.
QA Reviews Lecture # 6.
MODULE 7 Definitions Module 7 page 1.
Software Reviews.
Presentation transcript:

© Mahindra Satyam 2009 Defect Management and Prevention QMS Training

2 © Mahindra Satyam 2009 Objective To examine work products and identify defects and to ensure that the identified defects are fixed

3 © Mahindra Satyam 2009 Objective  To track defects to closure  To analyze the defects to identify root causes  To take necessary action to prevent recurrence of defects

4 © Mahindra Satyam 2009 Process Defect Management Defect Prevention in Projects Defect Prevention at Organization Level

5 © Mahindra Satyam 2009 Defect Management Identify Defects Assign Defects for Correction Defect Analysis and Correction Verify Defect Correction

6 © Mahindra Satyam 2009 Identify Defects  Defects are identified through – Reviews – Inspections – Testing  The identified defects are recorded in – Quantify, or – Defect Tracking Form, or – Review Reports

7 © Mahindra Satyam 2009 Assign Defects for Correction  PL assigns each defect to team member – typically the author of the work product  The assignee is responsible for analyzing and correcting the defect

8 © Mahindra Satyam 2009 Defect Analysis and Correction  Reproduce the defect to confirm it as a defect  Analyze the defect to identify the source i.e. work product which contains this defect – Defect originated in the work product under correction, or – a work product from earlier phase – e.g. a code defect may be because of a faulty design  List all the work products that need to be changed to resolve the defect  Make the correction to all the identified work products

9 © Mahindra Satyam 2009 Defect Analysis and Correction  Record defect resolution and analysis information in Quantify / Defect Tracking Form / Review Report

10 © Mahindra Satyam 2009 Verify Defect Correction  Each defect has to be verified after correction – This verification is recorded in the Defect Tracking Form – Verification for defect identified in testing is done in the subsequent test run – Verification for defect identified in review / inspections is done through follow- up action  A defect once verified is considered closed

11 © Mahindra Satyam 2009 Defect Prevention in Projects Prepare Defect Prevention Plan Conduct Task Kick-off meeting Select defect data for causal analysis Conduct Causal Analysis Implement defect prevention action plan Closure of Defect Prevention Action(s) Communicate DP data to PMG

12 © Mahindra Satyam 2009 Prepare Defect Prevention Plan  PL plans for defect prevention activities within the project while planning the project  This includes: – Identification of causal analysis team – Schedule of Task Kick-off Meetings – Schedule and frequency of causal analysis meetings – Plans for defect prevention actions – Frequency and criteria for evaluation of effectiveness of defect prevention actions

13 © Mahindra Satyam 2009 Conduct Task Kick-off meeting  PL conducts a task kick-off meeting at the beginning of each phase  Task Kick-off meeting shall discuss – Input / deliverables for the phase – Applicable standards, procedures, templates – Inputs from the DP action database and earlier phases of the project regarding common defects, causes and preventive actions applicable to the phase  Outcome of the task kick-off meeting are – Understanding of expectations in terms of deliverables and activities – Understanding of the common defects that occur in the phase – Defect prevention actions to be taken in that phase

14 © Mahindra Satyam 2009 Conduct Task Kick-off meeting  If any suggested DP actions from past projects are selected for implementation, these are to be planned and documented in DP Action Planning Form

15 © Mahindra Satyam 2009 Select Defect Data for Causal Analysis  Select defects for causal analysis – it may not be feasible to analyze each and every defect – select a set of defects that would give maximum benefit – criteria could be type of defects, severity of defects, customer reported defects etc. – Pareto analysis is recommended for selection of defects

16 © Mahindra Satyam 2009 Conduct Causal Analysis  Schedule causal analysis meeting – conduct causal analysis meeting at a time when it can benefit the project – e.g. For coding phase, conduct causal analysis meeting after a few code reviews have happened. This will allow to plough back the learning in the same phase of the project. – At the same time there should be enough defects to identify patterns and causal analysis be meaningful

17 © Mahindra Satyam 2009 Conduct Causal Analysis  Causal analysis meeting to be attended by all relevant team members  Causes to be identified by those who injected the defects during the brainstorming session of causal analysis  Use Cause & Effect diagrams to do the causal analysis  Try to identify the root cause of the defects  For every cause identified ask “why?” till there is no more an answer, this is probably the root cause  Identify preventive actions  Document the causal analysis and preventive actions in DP Action Planning Form

18 © Mahindra Satyam 2009 Implement Defect Prevention Action Plan  Implement the identified actions – Actions that can not be implemented immediately in the project, are passed on to process management group for incorporation in organization wide DP database

19 © Mahindra Satyam 2009 Closure of Defect Prevention Action(s)  For actions that are implemented, evaluate the effectiveness based on identified criteria – Reduction in defect density – Reduction in particular type of defects – Reduction in rework – Reduction in testing effort  PL updates the DP Action Planning Form – Details of implemented actions, experiences etc. – Actual results of implemented actions

20 © Mahindra Satyam 2009 Communicate DP data to PMT  PL communicates the DP data (DP action planning form) to PMT on an ongoing basis  PL sends this: – After every Causal Analysis Meeting – After Intro / Retro Meetings – After closure and effectiveness evaluation of action implementation

21 © Mahindra Satyam 2009 Defect Prevention at Organization Level Gather DP data from projects Analyze DP Data

22 © Mahindra Satyam 2009 Gather DP Data from Projects  PMG gathers DP data from projects on an ongoing basis  From this PMG identifies the information that needs to be disseminated across organization  This dissemination will be through the Project Knowledge Base available in Qualify  The information can be categorized under – Suggested prevention actions – Successful Prevention actions

23 © Mahindra Satyam 2009 Analyze DP Data  The DP data gathered across the organization is analyzed – to identify the common causes of defects across organization – to take appropriate process improvement actions Successful actions will be studied to identify improvements to organization's standard process

24 © Mahindra Satyam 2009 Objective Met  Defects are tracked to closure  Defects are analyzed to identify root causes  Appropriate actions are taken to prevent recurrence of defects