Root Cause Analysis for Customer Reported Problems. Topics
|
|
|
- Myles Douglas
- 9 years ago
- Views:
Transcription
1 Root Cause Analysis for Customer Reported Problems Copyright 2008 Software Quality Consulting Inc. Slide 1 Topics Introduction Motivation Software Defect Costs Root Cause Analysis Terminology Tools and Process Integrating RCA into Defect Life Cycle Triage Team Summary and Action Plan Copyright 2008 Software Quality Consulting Inc. Slide 2 1
2 Motivation Customer Reported Problems (CRPs) are critically important Represent gaps in knowledge of how customers use software May reflect deficiencies in development and test processes Often lead to disruptive, expensive, unplanned releases CRPs represent opportunities: To turn potential dissatisfaction into satisfaction To learn more about how customers use your software To identify areas for process improvement Copyright 2008 Software Quality Consulting Inc. Slide 3 Motivation How successful are you at finding defects your customers are likely to find? Total defects you found Total you found + Customer-reported defects based on at least n months of Customer use Use of this measure How good a job are we doing of Act Like a Customer Testing TM? Release 1 Release 2 Act Like a Customer Testing is a trademark of Software Quality Consulting, Inc. Jones, C., Software defect-removal Efficiency, IEEE Computer, Vol. 29, No. 4, April 1996, pp Copyright 2008 Software Quality Consulting Inc. Slide 4 2
3 Motivation Act Like a Customer Testing TM Testers need domain knowledge to be effective Write tests based on customer use in their environment Software has has lots lots of of defects Customers typically find find a small percentage of of the the total Focus your testing efforts on on finding those defects your Customers are are likely to to find find Act Like a Customer Testing is a trademark of Software Quality Consulting, Inc. Copyright 2008 Software Quality Consulting Inc. Slide 5 Root Cause Analysis Root Cause Analysis (RCA) helps: understand causes of customer dissatisfaction reduce expensive rework by preventing recurrence identify process weaknesses improve customer satisfaction RCA can provide answers to: Root Cause Analysis What happened? Why did it happen? How did we miss it? What can we do to prevent it? Copyright 2008 Software Quality Consulting Inc. Slide 6 3
4 Software Defect Costs Copyright 2008 Software Quality Consulting Inc. Slide 7 Software Defect Costs A recent study commissioned by National Institute of Standards and Technology found that defective software costs US economy $60 billion annually Are you measuring your defect costs? The Economic Impacts of Inadequate Infrastructure for Software Testing, NIST Planning Report 02-3, May 2002 Copyright 2008 Software Quality Consulting Inc. Slide 8 4
5 Software Defect Costs Pre-release Find/Fix Cycle Cycle Cycle can can take take from from hours hours per per defect defect Use Use $150 $150as as fully fully loaded labor labor cost costfor for Engineering time... time... Cost Cost per per defect defect is: is: x $150 $150 = $4,500 For For defects: 3,000 3,000 x $150 $150 = $450,000 Testing uncovers potential defect defect Potential defect defect reported Dev. Dev. investigates & verifies defect defect Dev. Dev. fixes fixes defect defect & does does some some testing Fix Fix included in in next next version New New release to to Test Test System Test Test performs regression testing Copyright 2008 Software Quality Consulting Inc. Slide 9 Software Defect Costs Post-release Find/Fix Cycle Cycle Cycle can can take take hours hours per per defect defect Use Use $150 $150fully loaded labor labor cost costfor for Engineering time... time... Cost Cost per per defect defect is: is: x $150 $150 = $9,000 For For defects: 6,000 6,000 x $150 $150 = $900,000 Tasks Tasks identified for for Pre-Release Find/Fix Cycle Cycle plus plus Update documentation New New version released New New version distributed to to Customers Customers install install new new version Support resolves issues issues with with new new version Copyright 2008 Software Quality Consulting Inc. Slide 10 5
6 Software Defect Costs Programs do not acquire bugs as people acquire germs, by hanging around other buggy programs. Programmers must insert them. Dr. Harlan Mills IBM Fellow Copyright 2008 Software Quality Consulting Inc. Slide 11 Software Defect Costs Reported Defect Injection Rates for a sample of 810 experienced software engineers: Group All Upper Quartile Upper 10% Upper 1% Avg. no. defects injected per (KLOC) KLOC = 1 defect per 8 LOC Software is released with some known defects and a significant number of unknown defects Humphrey, W., The Quality Attitude, news@sei newsletter, Number 3, Copyright 2008 Software Quality Consulting Inc. Slide 12 6
7 Software Defect Costs Please try this at work: Defects injected - Defects found Estimated no. of unknown defects where: defects injected = size (KLOC) X Copyright 2008 Software Quality Consulting Inc. Slide 13 Software Defect Costs A simple example One million LOC = 1,000 KLOCs Avg. defect injection rate of 120 defects/kloc 120,000 defects injected Assume 95% found = 114,000 defects found Unknown defects = defects injected defects found = (120, ,000) = 6,000 Copyright 2008 Software Quality Consulting Inc. Slide 14 7
8 Root Cause Analysis Used to investigate root cause of major disasters: Airplane crashes Space Shuttle accidents Chemical and nuclear plant disasters RCA requires effective problem solving skills Finding root cause may be difficult because: We have an incomplete problem definition Causal relationships are unknown We often focus on finding solutions and assigning blame Gano, D., et. al., Apollo Root Cause Analysis A New Way Of Thinking, Apollonian Publications, 1999 Copyright 2008 Software Quality Consulting Inc. Slide 15 Terminology Event Any failure of software and services (including code, documentation, installation, customization, training, etc.) that impacts customers Causal Factors Factors that contribute to occurrence of an event Causal Relationships Cause and effect sequence in which a specific action creates a condition that contributes to or results in an event US Dept of Energy, Root Cause Analysis Guidance Document, DOE-NE-STD , February 1992 Copyright 2008 Software Quality Consulting Inc. Slide 16 8
9 Corrective Action (CA) Terminology Action to eliminate root cause of a reported problem Immediate CA is taken soon after problem is reported to help customer recover workaround, hot fix, etc. Long Term CA taken to prevent recurrence results in changes to process and procedures Quality Management Systems Fundamentals and Vocabulary, ISO-9000:2000 Copyright 2008 Software Quality Consulting Inc. Slide 17 Terminology Root Cause Cause that, if corrected, prevents recurrence of this and similar events Attributes of root causes: Represent specific underlying causes of events Can be reasonably identified Can be fixed by Management Lead to effective corrective actions Rooney, J. and Vanden Heuvel, L., Root Cause Analysis for Beginners, ASQ Quality Progress, July 2004, p Copyright 2008 Software Quality Consulting Inc. Slide 18 9
10 Terminology Root Causes represent specific underlying causes of events Goal is to identify specific underlying causes More specific investigation is about why an event occurred, easier it is to recommend changes that prevent recurrence RCA Process needs to be reasonable Investigation must be cost-effective Good RCA Process helps keep ROI high Rooney, J. and Vanden Heuvel, L., Root Cause Analysis for Beginners, ASQ Quality Progress, July 2004, p Copyright 2008 Software Quality Consulting Inc. Slide 19 Terminology Root Causes can be fixed by Management Vague classifications such as operator error, hardware failure, or external factors are not helpful We need to know exactly why an event occurred before effective CA can be taken to prevent recurrence Root Causes lead to effective CA Corrective Actions should directly address identified root causes If recommendations are vague -- specific root cause was probably not found Copyright 2008 Software Quality Consulting Inc. Slide 20 10
11 Terminology Root Cause Analysis (RCA) Process of investigating, understanding, categorizing root causes Performed by small cross-functional team as part of Triage Process Analysis based on factual information obtained from: Documents and records Interviews Brainstorming sessions Use tools such as: Why Tree Pareto Analysis Copyright 2008 Software Quality Consulting Inc. Slide 21 Tools Why Tree Can help identify an appropriate CA What should be done immediately to resolve this CRP What should be done long term to prevent recurrence What is it about way we work that allowed this event to occur? Most root causes are found in way we work Start with a specific event and ask Why did this happen? Copyright 2008 Software Quality Consulting Inc. Slide 22 11
12 Tools Why Tree Start with event and ask Why until no more answers Copyright 2008 Software Quality Consulting Inc. Slide 23 Immediate Corrective Action Use Why Tree to help develop an Immediate CA Workaround, hot fix, patch, new CD, config changes, Implement CA Collect data to determine effectiveness with Customer Document Immediate CA in Bug Tracking System Add results of RCA as attachment to CRP Identify effectiveness measures determines if CA resolves problem ensures that real root cause found Copyright 2008 Software Quality Consulting Inc. Slide 24 12
13 Long Term Corrective Action Use Why Tree to develop Long Term CA Review existing business processes and procedures Identify process weaknesses directly related to root cause Identify recommendations to prevent recurrence Some changes may require Management review and approval Identify effectiveness measures determine if long term CA prevents recurrence Implement recommendations Collect data to determine effectiveness Document Long Term CA in Bug Tracking System Copyright 2008 Software Quality Consulting Inc. Slide 25 RCA Process RCA Process occurs as part of Triage Triage Team reviews all CRPs Consider RCA for all CRPs Triage Team appoints RCA Team to investigate Support, SQA, Dev Report back to Triage Team Copyright 2008 Software Quality Consulting Inc. Slide 26 13
14 RCA Process Step 1 - Data Collection Majority of time analyzing events is spent gathering data and information Complete information and thorough understanding of events required to identify causal factors and real root causes Begin with accurate statement of what happened in Customer s own words Descriptions of events in Customer s language is sometimes filtered Data collection will initially be sketchy use Why Tree to identify additional data to collect Rooney, J. and Vanden Heuvel, L., Root Cause Analysis for Beginners, ASQ Quality Progress, July 2004, p Copyright 2008 Software Quality Consulting Inc. Slide 27 RCA Process Step 1 - Data Collection Collect general information about Customer: Is Customer power user or novice? Has Customer received training? Is Customer s use and/or data unique? More questions? Collect information about Customer s environment: Standard release or customer-specific release? Platform/database/operating system releases? Received hot fixes recently? Installed? More questions? Customer Support staff can help gather this information Use checklist of questions to ask when Customer calls Copyright 2008 Software Quality Consulting Inc. Slide 28 14
15 RCA Process Step 2 Determine What Happened Start creating a Why Tree Begin with event in Customer s language Application crashed on startup Then ask Why? Continue asking Why until there are no more answers Process will identify additional information to collect Was feature defined in Requirements Spec? Was feature tested? If so, how? Was user training effective? Are there metadata, platform, or configuration issues? Other questions? Copyright 2008 Software Quality Consulting Inc. Slide 29 Simple Example Copyright 2008 Software Quality Consulting Inc. Slide 30 15
16 RCA Process Step 3 Identify Immediate Corrective Action Based on info collected, RCA Team identifies an immediate CA to resolve customer s immediate problem RCA Team also identifies effectiveness checks Determines if immediate CA resolves customer s problem Immediate CA is implemented RCA Team: collects data from customer to verify effectiveness immediate CA and other relevant info attached to CRP in Bug Tracking System reports back to Triage Team with results and effectiveness Copyright 2008 Software Quality Consulting Inc. Slide 31 RCA Process Step 4 - Root Cause Identification Based on Why Tree and supporting information RCA Team reviews info and identifies most probable root causes Ensure that most probable root causes meet criteria: Represent specific underlying causes of events Can be reasonably identified Can be fixed by Management Can lead to effective corrective actions Root cause documented and results attached to CRP in Bug Tracking System Copyright 2008 Software Quality Consulting Inc. Slide 32 16
17 Simple Example Copyright 2008 Software Quality Consulting Inc. Slide 33 RCA Process Step 5 Long Term Corrective Action Most root causes found in way you work Review process and procedures Long term CA often results in changes to way you work Are procedures written? Followed? Unwritten procedures result in inconsistent results Are existing procedures/training ineffective? Are additional procedures/training required? Effectiveness Measures How will you know that root cause has been eliminated? Copyright 2008 Software Quality Consulting Inc. Slide 34 17
18 RCA Tools Pareto Analysis 80% problems result from 20% causes Can help determine what problems to address As root causes are identified, add them to list RC Root Cause Description 1 Feature was defined but not tested 2 Feature was tested but the test was inadequate 3 Feature was not defined in Functional Spec 4 Feature was defined in Functional Spec but not in Use Cases 5 Design was inadequate/inappropriate - Design review not held 6 Design was inadequate/inappropriate - Design review didn't catch it 7 Coding was inadequate/incorrect - Code review not held 8 Coding was inadequate/incorrect - Code review didn't catch it 9 Installation / configuration issues 10 Metadata issues 11 Environment / Version compatibility issues 12 User training issues Copyright 2008 Software Quality Consulting Inc. Slide 35 RCA Tools Pareto Analysis Use Pareto Analysis to identify root causes that warrant long term corrective action CRP # RC #1 RC #2 RC #3 RC #4 Etc Totals Copyright 2008 Software Quality Consulting Inc. Slide 36 18
19 Real Example Copyright 2008 Software Quality Consulting Inc. Slide 37 Summary RCA Process Can be very effective at discovering real root causes Helps identify WHAT, WHY, and HOW Leads to immediate CA and long term CA Improves Customer Satisfaction Reduces rework and eliminates unplanned releases Fits within typical Defect Life Cycle Process Performed by Triage Team with support from staff Includes effectiveness measures to determine if CA is effective Copyright 2008 Software Quality Consulting Inc. Slide 38 19
20 Additional Workshops Software Development for Medical Device Manufacturers Peer Reviews and Inspections Computer System Validation Risk Management Writing and Reviewing Requirements for Software Software Verification & Validation 21 CFR Part 11: Electronic Records and Electronic Signatures Process Validation For more information, please visit Copyright 2008 Software Quality Consulting Inc. Slide 39 Additional Workshops Project Retrospectives Root Cause Analysis for Customer Reported Problems Writing Software Requirements Estimating and Scheduling Best Practices Software Verification & Validation for Practitioners and Managers Accurate Schedules Using the Yellow Sticky Method Predictable Software Development TM Peer Reviews and Inspections Improving the Effectiveness of Testing Risk Management for Embedded Software Development For more information, please visit Predictable Software Development is a trademark of Software Quality Consulting, Inc. Copyright 2008 Software Quality Consulting Inc. Slide 40 20
21 Thank you... If you have questions, please call or ... Subscribe to my e-newsletter For a free subscription and to view past newsletters, visit Copyright 2008 Software Quality Consulting Inc. Slide 41 21
EFFECTIVE ROOT CAUSE ANALYSIS AND CORRECTIVE ACTION PROCESS
JOURNAL OF ENGINEERING MANAGEMENT AND COMPETITIVENESS (JEMC) Vol. 1, No. 1/2, 2011, 16-20 EFFECTIVE ROOT CAUSE ANALYSIS AND CORRECTIVE ACTION PROCESS Branislav TOMIĆ 1, Vesna SPASOJEVIĆ BRKIĆ 2 1 Bombardier
Software Quality Data Part 1: Basic and Derived Metrics
Abstract We measure, quantify and report on software quality. But can we control it? Can we actually assure quality (as opposed to just measuring it)? This is the first of three papers in which we will
FSW QA Testing Levels Definitions
FSW QA Testing Levels Definitions 1. Overview This document is used to help determine the amount and quality of testing (or its scope) that is planned for or has been performed on a project. This analysis
SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART
Software Productivity Research an Artemis company SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART Capers Jones, Chief Scientist Emeritus Six Lincoln Knoll Lane Burlington, Massachusetts 01803
CUSTOMER GUIDE. Support Services
CUSTOMER GUIDE Support Services Table of Contents Nexenta Support Overview... 4 Support Contract Levels... 4 Support terminology... 5 Support Services Provided... 6 Technical Account Manager (TAM)... 6
Noorul Islam College of Engineering M. Sc. Software Engineering (5 yrs) IX Semester XCS592- Software Project Management
Noorul Islam College of Engineering M. Sc. Software Engineering (5 yrs) IX Semester XCS592- Software Project Management 8. What is the principle of prototype model? A prototype is built to quickly demonstrate
Root Cause Analysis for IT Incidents Investigation
Root Cause Analysis for IT Incidents Investigation Still trying to figure out what went wrong? Even IT shops with formal incident management processes still rely on developers and/or support specialists
MKS Integrity & CMMI. July, 2007
& CMMI July, 2007 Why the drive for CMMI? Missed commitments Spiralling costs Late delivery to the market Last minute crunches Inadequate management visibility Too many surprises Quality problems Customer
Information Technology Engineers Examination. Information Technology Service Manager Examination. (Level 4) Syllabus
Information Technology Engineers Examination Information Technology Service Manager Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination
Formal Software Testing. Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com
Formal Software Testing Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com Scope of Testing Find defects early Remove defects prior to production Identify Risks Unbiased opinion When Should Testing
Personal Software Process (PSP)
Personal Software Process (PSP) Application of CMM principles to individuals Developed by Watts Humphrey of the Software Engineering Institute (SEI) in the early 1990s Extensive supporting materials: books,
Quality Management. Lecture 12 Software quality management
Quality Management Lecture 12 Software quality management doc.dr.sc. Marko Jurčević prof.dr.sc. Roman Malarić University of Zagreb Faculty of Electrical Engineering and Computing Department of Fundamentals
Nova Software Quality Assurance Process
Nova Software Quality Assurance Process White Paper Atlantic International Building 15F No.2 Ke Yuan Yi Road, Shiqiaopu, Chongqing, P.R.C. 400039 Tel: 86-23- 68795169 Fax: 86-23- 68795169 Quality Assurance
International Journal of Information Technology & Computer Science ( IJITCS ) (ISSN No : 2091-1610 ) Volume 5 : Issue on September / October, 2012
USING DEFECT PREVENTION TECHNIQUES IN SDLC Karthikeyan. Natesan Production Database Team Singapore Abstract : In our research paper we have discussed about different defect prevention techniques that are
The Personal Software Process (PSP) Tutorial
The Personal Software Process (PSP) Tutorial Watts Humphrey / Jim Over Speaker: Daniel M. Roy (STPP, visiting scientist SEI) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213
<name of project> Software Project Management Plan
The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor
Root Cause Analysis Concepts and Best Practices for IT Problem Managers
Root Cause Analysis Concepts and Best Practices for IT Problem Managers By Mark Hall, Apollo RCA Instructor & Investigator A version of this article was featured in the April 2010 issue of Industrial Engineer
Camber Quality Assurance (QA) Approach
Camber Quality Assurance (QA) Approach Camber s QA approach brings a tested, systematic methodology, ensuring that our customers receive the highest quality products and services, delivered via efficient
CSTE Mock Test - Part I - Questions Along with Answers
Note: This material is for Evaluators reference only. Caters to answers of CSTE Mock Test - Part I paper. 1. A branch is (Ans: d) a. An unconditional transfer of control from any statement to any other
Maintenance Program Guide
Maintenance Program Guide www.tibco.com http://spotfire.tibco.com/ www.datasynapse.com Global Headquarters 3303 Hillview Avenue Palo Alto, CA 94304 Tel: +1 650-846-1000 Toll Free: 1 800-420-8450 Fax: +1
Measuring Return on Investment of Model-Based Design
Measuring Return on Investment of Model-Based Design By Joy Lin, Aerospace Industry Marketing Manager, MathWorks As embedded systems become more complex, it is becoming more difficult to maintain quality
Certified Software Quality Engineer (CSQE) Body of Knowledge
Certified Software Quality Engineer (CSQE) Body of Knowledge The topics in this Body of Knowledge include additional detail in the form of subtext explanations and the cognitive level at which the questions
Maximize Software Development ROI With Quality Assurance. Showing the value of the Quality Process
Maximize Software Development ROI With Quality Assurance Showing the value of the Quality Process Thibault Dambrine Agenda Software Quality Assurance ROI - Quantifying the Cost of Quality - Justifying
copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering: A Practitioner s Approach, 6/e Chapter 26 Quality Management copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student
Quality Management System General
Audit Date: Quality Management System General Requirement: 4.1 and 4.2.2-QMS General Verify Scope Comments/Evidence/Findings: Verify the Exclusions is applicable and justified How are the processes in
Effective Root Cause Analysis For Corrective and Preventive Action
Effective Root Cause Analysis For Corrective and Preventive Action Manuel Marco Understanding Key Principles Requirement need or expectation that is stated, generally implied, or obligatory Generally implied
Creating a ITIL-based Software Incident Categorization Model for Measurement: A Case Study
Creating a ITIL-based Software Incident Categorization Model for Measurement: A Case Study Sanna Heikkinen, Antti Suhonen, Mika Kurenniemi, and Marko Jäntti University of Eastern Finland School of Computing
QUALITY POLICY MANUAL Document: 01-090000 Revision: E Effective Date: January 15, 2010
Section i INTRODUCTION QUALITY POLICY STATEMENT: The purpose of our business is to provide continuity of electrical power to keep businesses in business. We do this by helping clients solve their power
Information Technology Engineers Examination. Information Security Specialist Examination. (Level 4) Syllabus
Information Technology Engineers Examination Information Security Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination
Software Quality Assurance. Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman
Chapter 16 Software Quality Assurance Slide Set to accompany Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit
ISO 9001 Quality Management Systems. Tips for Internal Auditing
ISO 9001 Quality Management Systems Tips for Internal Auditing ...taking steps to improving your internal auditing. ISO 9001 Tips for Internal Auditing If you are developing or modifying your internal
Verification and Validation of Software Components and Component Based Software Systems
Chapter 5 29 Verification and Validation of Software Components and Component Based Christina Wallin Industrial Information Technology Software Engineering Processes ABB Corporate Research [email protected]
Learning from Our Mistakes with Defect Causal Analysis. April 2001. Copyright 2001, Software Productivity Consortium NFP, Inc. All rights reserved.
Learning from Our Mistakes with Defect Causal Analysis April 2001 David N. Card Based on the article in IEEE Software, January 1998 1 Agenda What is Defect Causal Analysis? Defect Prevention Key Process
Compliance Case Study #3 Manual Processes, Performance, Responsibilities, and Training
Compliance Case Study #3 Manual Processes, Performance, Responsibilities, and Training Paul L. Pluta, Timothy J. Fields, and Alan J. Smith IMAGEZOO/GETTY IMAGES Compliance Case Studies discusses compliance
074-8432-552 Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements
Page 1 of 7 Software Supplier Process Requirements 1.0 QUALITY SYSTEM FRAMEWORK 1.1 QUALITY POLICY The Seller shall document and implement a quality program in the form of Quality manual or detailed Quality
Change Request Process Overview
Industry Best Practices Process Overview by Garth Wilcox This white paper outlines a process for requesting and managing changes to an application during the product development cycle. It also discusses
An Introduction to. Metrics. used during. Software Development
An Introduction to Metrics used during Software Development Life Cycle www.softwaretestinggenius.com Page 1 of 10 Define the Metric Objectives You can t control what you can t measure. This is a quote
Metrics in Software Test Planning and Test Design Processes
Master Thesis Software Engineering Thesis no: MSE-2007:02 January 2007 Metrics in Software Test Planning and Test Design Processes Wasif Afzal School of Engineering Blekinge Institute of Technology Box
OVERVIEW. In all, this report makes recommendations in 14 areas, such as. Page iii
The Office of the Auditor General has conducted a procedural review of the State Data Center (Data Center), a part of the Arizona Strategic Enterprise Technology (ASET) Division within the Arizona Department
SOFTWARE REQUIREMENTS
SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities
Minimizing code defects to improve software quality and lower development costs.
Development solutions White paper October 2008 Minimizing code defects to improve software quality and lower development costs. IBM Rational Software Analyzer and IBM Rational PurifyPlus software Kari
I.3 Quality Management
I.3 Quality Management [Sommerville2004] Quality Management System [ISO 9000]: The organizational structure, responsibilities, procedures, processes and resources for implementing quality management Concerned
Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University
Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or
Establishing a Defect Management Process Model for Software Quality Improvement
Establishing a Management Process Model for Software Quality Improvement Hafiz Ansar Khan Abstract remains in the whole life of software because software is developed by humans and to err is human. The
Software Testing & Analysis (F22ST3): Static Analysis Techniques 2. Andrew Ireland
Software Testing & Analysis (F22ST3) Static Analysis Techniques Andrew Ireland School of Mathematical and Computer Science Heriot-Watt University Edinburgh Software Testing & Analysis (F22ST3): Static
CPET 545 SOA and Enterprise Applications. SOA Final Project Project Scope Management 11-13-2008
CPET 545 SOA and Enterprise Applications Examples of Tasks and Subtasks o SOA Project Plan (checklist) Statement of work Resources Schedule Risk plan SOA Final Project Project Scope Management 11-13-2008
HOW TO CREATE USEFUL SOFTWARE PROCESS DOCUMENTATION ABSTRACT
HOW TO CREATE USEFUL SOFTWARE PROCESS DOCUMENTATION Linda Westfall The Westfall Team [email protected] 3000 Custer Road, Suite 270, PMB 383 Plano, TX 75075 ABSTRACT Whether our organization is
Basic Testing Concepts and Terminology
T-76.5613 Software Testing and Quality Assurance Lecture 2, 13.9.2006 Basic Testing Concepts and Terminology Juha Itkonen SoberIT Contents Realities and principles of Testing terminology and basic concepts
Measuring and Managing In-process Software Quality Stephen H. Kan IBM Rochester, Minnesota USA [email protected]
Measuring and Managing In-process Software Quality Stephen H. Kan IBM Rochester, Minnesota USA [email protected] Abstract Using in-process metrics to determine the quality status of a software project under
DOE O 226.1A, IMPLEMENTATION OF DEPARTMENT OF ENERGY OVERSIGHT POLICY CONTRACTOR ASSURANCE SYSTEMS CRITERIA ATTACHMENT 1, APPENDIX A
DOE O 226.1A, IMPLEMENTATION OF DEPARTMENT OF ENERGY OVERSIGHT POLICY CONTRACTOR ASSURANCE SYSTEMS CRITERIA ATTACHMENT 1, APPENDIX A DEFINITIONS Assurance systems encompass all aspects of the processes
Domain 1 The Process of Auditing Information Systems
Certified Information Systems Auditor (CISA ) Certification Course Description Our 5-day ISACA Certified Information Systems Auditor (CISA) training course equips information professionals with the knowledge
Jonathan Wilson. Sector Manager (Health & Safety)
Jonathan Wilson Sector Manager (Health & Safety) OHSAS 18001:2007 Making Life Easier For Health & Safety Managers Workshop Agenda 1. Introduction 2. Why Manage Health & Safety 3. OHSAS 18001 and OHSMS
An approach to Return on Investment (ROI) for Independent Verification and Validation (IV&V) at NASA
An approach to Return on Investment (ROI) for Independent Verification and Validation (IV&V) at NASA Bob Hunt September 2012 1 NASA IV&V The NASA IV&V Program was established in 1993 as part of an Agency-wide
Capability Maturity Model Integration (CMMI SM ) Fundamentals
Capability Maturity Model Integration (CMMI SM ) Fundamentals Capability Maturity Model Integration and CMMI are are service marks of Carnegie Mellon University 2008, GRafP Technologies inc. 1 What is
How To Make A Successful Product From A Successful Recipe Card
Collaboration Between Support Staff and Software Testers Cem Kaner David Pels September, 1998 A Success Story Successful mass-market product (category: edit/layout of text and graphics) with high per unit
14620 Henry Road Houston, Texas 77060 PH: 281-447-3980 FX: 281-447-3988. WEB: www.texasinternational.com QUALITY MANUAL
14620 Henry Road Houston, Texas 77060 PH: 281-447-3980 FX: 281-447-3988 WEB: www.texasinternational.com QUALITY MANUAL ISO 9001:2008 API Spec Q1, 9th Edition API Spec 8C 5 Th Edition MANUAL NUMBER: Electronic
What do you think? Definitions of Quality
What do you think? What is your definition of Quality? Would you recognise good quality bad quality Does quality simple apply to a products or does it apply to services as well? Does any company epitomise
Defect Analysis and Prevention for Software Process Quality Improvement
Defect Analysis and Prevention for Software Process Quality Improvement Sakthi Kumaresh Research Scholar, Bharathiar University. Department of Computer Science, MOP Vaishnav College for Women, Chennai.
How To Write Software
1 Medical Device Software - Software Life Cycle Processes IEC 62304 2 Credits John F. Murray Software Compliance Expert U.S. Food and Drug Administration Marcie R. Williams Medical Device Fellow Ph.D.
IT Service Management
RL Consulting IT Service Management Incident/Problem Management Methods and Service Desk Implementation Best Practices White Paper Prepared by: Rick Leopoldi vember 8, 2003 Copyright 2003 RL Information
Examination SUBJECT. Version:
SUBJET Version: 1 Which of the following statements best describes Business nalysis? Business nalysis provides the reasoning for initiating a project. Business nalysis is the strategic part of the project
Bottom-Line Management
pci Bottom-Line BOTTOM-LINE BUSINESS ANALYSIS THE ONLY 4 LEVEL INTEGRATED CURRICULUM TAKING PEOPLE FROM BEGINNER TO EXPERT 1. Business Analyst Foundations 2. High Quality Business Requirements 3. Use Cases
Contents of the ISO 9001:2008 Quality System Checklist
Contents of the ISO 9001:2008 Quality System Checklist Page Hyperlinks (click underlines) This SAMPLE document includes 4 clauses of the standard. You receive the Windows.doc file (with hyperlinks). You
Q uick Guide to Disaster Recovery Planning An ITtoolkit.com White Paper
This quick reference guide provides an introductory overview of the key principles and issues involved in IT related disaster recovery planning, including needs evaluation, goals, objectives and related
An ITIL Perspective for Storage Resource Management
An ITIL Perspective for Storage Resource Management BJ Klingenberg, IBM Greg Van Hise, IBM Abstract Providing an ITIL perspective to storage resource management supports the consistent integration of storage
Test Plan (a Real Sample) SoftwareTestingHelp.com Live Project Training - OrangeHRM
www.softwaretestinghelp.com Test Plan (a Real Sample) SoftwareTestingHelp.com Live Project Training - OrangeHRM 2/1/2014 SoftwareTestingHelp.com Name of the tester Note: This is a sample test plan created
INDEPENDENT VERIFICATION AND VALIDATION OF EMBEDDED SOFTWARE
PREFERRED RELIABILITY PRACTICES PRACTICE NO. PD-ED-1228 PAGE 1 OF 6 INDEPENDENT VERIFICATION AND VALIDATION OF EMBEDDED SOFTWARE Practice: To produce high quality, reliable software, use Independent Verification
Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to [email protected].
An e-newsletter published by Software Quality Consulting, Inc. March 2010, Vol. 7 No. 2 [Text-only Version] Welcome to Food for Thought, an e-newsletter from Software Quality Consulting. I've created free
The ROI from Optimizing Software Performance with Intel Parallel Studio XE
The ROI from Optimizing Software Performance with Intel Parallel Studio XE Intel Parallel Studio XE delivers ROI solutions to development organizations. This comprehensive tool offering for the entire
Software Engineering: Analysis and Design - CSE3308
CSE3308/DMS/2004/25 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 Software Quality CSE3308 - Software Engineering: Analysis
Effective Software Verification for Medical Devices
STERLINGTECH AND KLOCWORK WHITE PAPER NOVEMBER 2009 Effective Software Verification for Medical Devices Achieving compliance and meeting productivity goals with static analysis In addition to producing
Emergency Power System Services Industrial UPS, Batteries, Chargers, Inverters and Static Switches
Emergency Power System Services Industrial UPS, Batteries, Chargers, Inverters and Static Switches Downtime Is Not An Option The industrial uninterruptible power supply (UPS) is the foundation of your
Introduction to Functional Verification. Niels Burkhardt
Introduction to Functional Verification Overview Verification issues Verification technologies Verification approaches Universal Verification Methodology Conclusion Functional Verification issues Hardware
Change Management for Rational DOORS User s Guide
Change Management for Rational DOORS User s Guide Before using this information, read the general information under Appendix: Notices on page 58. This edition applies to Change Management for Rational
NEOXEN MODUS METHODOLOGY
NEOXEN MODUS METHODOLOGY RELEASE 5.0.0.1 INTRODUCTION TO QA & SOFTWARE TESTING GUIDE D O C U M E N T A T I O N L I C E N S E This documentation, as well as the software described in it, is furnished under
Keywords: SQA,Black Box Testing( BBT), White Box testing(wbt).
Volume 3, Issue 10, October 2013 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Enhancing Software
Performance Indicators for Disaster Recovery
Disaster Recovery Plan to ISO 17799 Introduction A disaster recovery plan attempts to run associated processes to transition smoothly in the event of a natural or human-caused disaster. To plan effectively,
How CMMI contributes to Software Testing
How CMMI contributes to Software Testing Dr. Uwe Hehn method park Software AG [email protected] Contents 1. Motivation for S/W Quality Models 2. Why Testers should have some knowledge of Quality Models
SOFTWARE MANAGEMENT PROGRAM. Software Testing Checklist
SOFTWARE MANAGEMENT PROGRAM Software Testing Checklist The following checklist is intended to provide system owners, project managers, configuration managers, and other information system development and
IBM Tivoli Network Manager 3.8
IBM Tivoli Network Manager 3.8 Configuring initial discovery 2010 IBM Corporation Welcome to this module for IBM Tivoli Network Manager 3.8 Configuring initial discovery. configuring_discovery.ppt Page
QUALITY MANAGEMENT SYSTEM (QMS) ASSESSMENT CHECKLIST
1. QUALITY MANAGEMENT SYSTEM QUALITY MANAGEMENT SYSTEM (QMS) ASSESSMENT CHECKLIST 1.1 Quality Management System General 1.1.1 Is objective evidence available to demonstrate that the MDSAP site has defined,
Cost of Poor Quality:
Cost of Poor Quality: Analysis for IT Service Management Software Software Concurrent Session: ISE 09 Wed. May 23, 8:00 AM 9:00 AM Presenter: Daniel Zrymiak Key Points: Use the Cost of Poor Quality: Failure
Applaud Solutions Technical Support Policies
Applaud Solutions Technical Support Policies Effective Date: 06-May-2011 Overview Unless otherwise stated, these Technical Support Policies apply to technical support for all Applaud Solutions products.
Advancements in the V-Model
Advancements in the V-Model Sonali Mathur Asst. Professor, CSE Dept. ABES Institute of Technology Ghaziabad, U.P-201009 Shaily Malik Lecturer, CSE Dept. Maharaja Surajmal Institute of Tech. Janakpuri,
Description of Services for A Quality Assurance Engineer for SQA Assignment for eservices Development Projects ICTA/CON/IC/P5/411B
Description of Services for A Quality Assurance Engineer for SQA Assignment for eservices Development Projects ICTA/CON/IC/P5/411B 1. Introduction The Information and Communication Technology Agency of
A Framework for Incident and Problem Management
The knowledge behind the network. A Framework for Incident and Problem Management By Victor Kapella Consulting Manager International Network Services Incident and Problem Management Framework April 2003
