1 / 33

Quality Management Systems: Methods and Techniques of Software Quality Management

Quality Management Systems: Methods and Techniques of Software Quality Management Karl Heinrich Möller Gaertnerstr. 29 D-82194 Groebenzell Tel: +49(8142)570144 Fax: +49(8142)570145 Email: karl-heinrich.moeller@t-online.de. Definitions User friendliness Software Development as a Process

dmathew
Télécharger la présentation

Quality Management Systems: Methods and Techniques of Software Quality Management

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 Management Systems: Methods and Techniques of Software Quality Management Karl Heinrich Möller Gaertnerstr. 29 D-82194 Groebenzell Tel: +49(8142)570144 Fax: +49(8142)570145 Email: karl-heinrich.moeller@t-online.de

  2. Definitions User friendliness Software Development as a Process Faults as a cost factor Fault causing factors Strategies to fault reduction Topics

  3. Quality:Degree to which a set of inherent characteristics fulfils requirements Note 1:The term quality can be used with adjectives such as poor or excellent Definition of Quality ISO 9000:2000; Par. 3.1.1

  4. Characteristic:Distinguishing feature Note 1:A characteristic can be inherent or assigned Note 2:A characteristic can be qualitative or quantitative Note 2:There are various classes of characteristics(physical, sensory, behavioural, temporal, etc.) Definition of Characteristic ISO 9000:2000; Par. 3.5.1

  5. Nonconformity:Non - fulfilment of a requirement Definition of Nonconformity ISO 9000:2000; Par. 3.6.2

  6. Defect:Non - fulfilment of a requirement related to an intended or specified use Note:The distinction between the concepts defect and nonconformity is important as it has legal connotations, particularly those associated with product liability. Definition of Defect ISO 9000:2000; Par. 3.6.3

  7. Quality-related Costs :Those costs incurred in ensuring and assuring satisfactory quality, as well as the losses incurred when satisfactory quality is not achieved Quality losses: Losses caused by not realizing the potential of resources in processes and activities Definition of Quality Cost and Losses ISO 8402:1995; Par. 4.2 and 4.3

  8. Defect Prevention Costs:Group of quality costelements to collect costs which will be caused by taking measures of prevention and correction in order of QM Test CostsGroup of quality cost elements to collect costs which will be caused by all planned quality tests Defect Costs Group of quality cost elements to collect costs which will be caused by the losses incurred when satisfactory quality is not achieved Definition of Quality Cost Elements Internationally not defined

  9. Development of software should incorporate two characteristics:Development process of high quality (will result in high productivity, efficiency)Products with high customer value (will result in high sales) --> Assuring the economic survival Quality Objectives of Software Development

  10. 1. FunctionalitySuitability, Accuracy, Interoperability, Security, Functionality Compliance 2. ReliabilityMaturity, Fault Tolerance, Recoverability, Reliability Compliance 3. UsabilityUnderstand ability, Learn ability, Operability, Attractiveness, Usability Compliance 4. EfficiencyTime Behaviour, Resource Utilisation, Efficiency Compliance 5. MaintainabilityAnalysability, Changeability, Stability, Testability, Maintainability Compliance 6. PortabilityAdaptability, Install ability, Co-Existence, Replace ability, Portability Compliance ISO 9126:2001 Software Engineering; Quality Model

  11. User Friendliness Design Characteristic Product Characteristic Requirement Hardware Independency Portability Insularity Accuracy Reliability Completeness Robustness Efficiency Consistency Usability User Adaptability Hardware Efficiency Accessibility Testability Connect ability Self-explanatoribility Comprehensibility Diagnose ability Readability Changeability Upgradeability

  12. Development Process as Waterfall Model Development Process Market Product Concept Require-ments Field Product Defini-tion Integr. & funct. Test Implem. & Test System Test Design Product Planning Real Product Realisation Customer Satisfaction Product Maintenance Defects

  13. Development Process Product Planning Realisation Field Schedule =fct(Product Structure + Process) Product Structure Product Part B Part A Part C Part D Schedule Product Planning Realisation Part A Realisation Part B Realisation Part C System Test Realisation Part D

  14. By using metrics and setting objectives: Without Clear Objectives Quality Cannot be Improved Quality Assurance for Software Development

  15. Quality improvement through measurement Presence of qualityHow good is this product? - Subjective metrics Absence of qualityWhat is wrong with this product? - Objective metrics Two Approaches to Quality Measurement

  16. Resistance Open Metrics are too expensive Metrics are not obvious Metrics are not connected to the business Hidden Management Developers Open and Hidden Resistance

  17. Overcoming Resistance Involve Everyone Build Trust Metrics Program Champion Work Circles Open and Hidden Resistance

  18. Management 9 Quality Assurance, Config.-Management 6 Corrections in ... amount to 6% of the costs Corrections in ... amount to 10% of the costs Correct. in ... Corrections in integration testand system test amount to 18% of the costs 1 4 5 10 6 12 10 10 18 Architecture Design 9 CodingFunctional Test Detailed Design Integration Test & System Test Requirements Faults as a Cost Factor (to Boehm) Total amount of costs for finding and correcting the defects: 39%

  19. Fault Stream Development Process Time Design Require-ments Implemen-tation 40% 10% 50% Stream of Faults Goal: <25% Goal: <5% 50% 25% 5% 7% 3% 10% Requirement Review Design Review Code Review Functional Test System Test Deploy-ment Fault Finding Process

  20. Improvement Potential Deploy-ment System Test Require- ments Functional Test Coding Design Fault Origin 10% 50% 40% Fault detection 10% 50% 7% 5% 3% 25% Costs per Fault 6 kDM 20 kDM 1 kDM 1 kDM 1 kDM 12 kDM

  21. Fault Distribution in Moduls 100% Number of faults 90% 50% Number of modules 50% 10% 100% fault concentration in a small number of modules

  22. Fault rates as a function of the change rate fault driving factors fault rate faults/k DNLCC DNLCC NLCC

  23. Fault rates as a function of the module length fault driving factors fault rate for new modules faults/kNLCC log (NLCC)

  24. Fault rates as a function of the module length fault driving factors faults rate for changed modules faults/k DNLCC log (DNLCC)

  25. Code changes Short modules „Old“ Programming Languages Data flow instead of control flow More missing than defect Late changes, corrections Incomprehensible Messages Logic expressions Missing initialization Particular Factors for High Fault Rates

  26. Early Fault Removal for a Operating System

  27. Fault Rates and Productivity

  28. 1. Introducing less faults in developing(will be about 5% per year for experienced development teams) 2. Finding faults earlier(Reducing field defects at about 50% in particular years possible) 3. Fault Prevention by re-use Strategies for Reducing Faults

  29. Fault Introduction AnalysisWhere Faults are Introduced within the Process Target GoalsFor Faults Found in Development and the Fieldwithin all FunctionsFor all Products Monitoring the Target GoalsThrough Reporting and ProjectionComparison with PlanCorrective Action Supporting Measures- Found Faults Counts for all Phases- Management Support of Quality Improvement- Improved Review Methods- Methods Training- Tools Use- Many Small Steps Strategies for Reducing Faults

  30. Forecasting Methods 1. Forecasting rest faults by faults found 2. Forecasting faults based on the defect input in older versions 3. Forecasting faults with a database based on experience 4. Forecasting faults by introducing faults synthetically Strategies for Reducing Faults

  31. Strategies for Reducing Faults Detected faults in total Years 0 1 2 3 4 5 6

  32. Strategies for Reducing Faults faults found in % of all faults F(t) Fault found 100% Deployment F(t) = N(1-e-t) 90- 97% Pilot 85- 95% faults to find System Test faults found 60- 75% Development Time t(x)

  33. Strategies for Reducing Faults Version n • Version n + 1 • Forecasting of the faults to expect • New agreement with the development group for number of faults to find • Version n - 1 • Analysis of the fault rates between defined milestones • Programming language • Change rate • Group • Module group Difference of the fault rates of the version n-1 and n Fault forecasting for product lines

More Related