1 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 of Electrical Engineering and Measurements, 2014
2 The software quality challenge Software is (IEEE definition): Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. The uniqueness of the software development process: High complexity, as compared to other industrial products Invisibility of the product Opportunities to detect defects ( bugs ) are limited to the product development phase
3 Quality Concepts Variation control is the heart of quality control Software engineers strive to control the process applied resources expended end product quality attributes
4 The software quality challenge Factors affecting defect detection in software products vs. other industrial products (source: Software Quality Assurance From Theory to Implementation, p. 6)
5 significant parts of advanced devices as well as of household machines and other products include embedded software components (usually termed firmware ) that are integrated into the product. These software components (the firmware) share the same characteristics of the usuall software products
6 Software quality IEEE definition Software quality is: 1. The degree to which a system, component, or process meets specified requirements. 2. The degree to which a system, component, or process meets customer or user needs or expectations.
7 Software quality management and software lifecycle Collecting requirements and defining scope of IT project (focus on verification if defined requirements will be testable) Designing the solution (focus on planning test process e.g. what type of tests will be performed, how they will be performed in context of test environments and test data. Solution implementation supported by creating test cases and scenarios, executing them and registering defects including coordination of fixing them. Change management, supported by verification how planned changes can influence the quality of created solution and eventual change of test plan. Closing project, supported by realization number of tests focused on complex verification of overall quality of created solution. It can include System Integration Tests, User Acceptance Tests and Operational Acceptance Tests.
8 Causes of software errors Classification of the causes of software errors: (1) Faulty definition of requirements faulty definition of requirements, usually prepared by the client, is one of the main causes of software errors Erroneous definition of requirements Absence of vital requirements Incomplete definition of requirements Inclusion of unnecessary requirements, functions that are not expected to be needed in the near future (2) Client developer communication failures Misunderstandings resulting from defective client developer communication are additional causes for the errors that prevail in the early stages of the development process
9 Causes of software errors... Classification of the causes of software errors: (3) Deliberate deviations from software requirements The developer reuses software modules taken from an earlier project without sufficient analysis of the changes and adaptations needed to correctly fulfill all the new requirements; due to time or budget pressures, the developer decides to omit part of the required functions in an attempt to cope with these pressures (4) Logical design errors (5) Coding errors (6) Non-compliance with documentation and coding instructions (7) Shortcomings of the testing process (8) Procedure errors (9) Documentation errors
10 Software quality assurance The IEEE definition Software quality assurance is: 1. A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. 2. A set of activities designed to evaluate the process by which the products are developed or manufactured. Contrast with quality control. Software quality assurance is (expanded definition): A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines.
11 SQA SQA should not be limited to the development process. It should be extended to cover the long years of service subsequent to product delivery. Adding issues directly related to the software product introduces quality issues that integrate software maintenance functions into the overall conception of SQA. SQA actions should not be limited to the technical aspects of the functional requirements, but should include also activities that deal with scheduling and the budget.
12 The objectives of SQA activities Software development (process-oriented): 1. Assuring an acceptable level of confidence that the software will conform to functional technical requirements. 2. Assuring an acceptable level of confidence that the software will conform to managerial scheduling and budgetary requirements. 3. Initiating and managing of activities for the improvement and greater efficiency of software development and SQA activities. This means improving the prospects that the functional and managerial requirements will be achieved while reducing the costs of carrying out the software development and SQA activities. Software maintenance (product-oriented): 1. Assuring with an acceptable level of confidence that the software maintenance activities will conform to the functional technical requirements. 2. Assuring with an acceptable level of confidence that the software maintenance activities will conform to managerial scheduling and budgetary requirements. 3. Initiating and managing activities to improve and increase the efficiency of software maintenance and SQA activities. This involves improving the prospects of achieving functional and managerial requirements while reducing costs.
14 Product operation software quality factors Correctness requirements are defined in a list of the software system s required outputs Reliability requirements deal with failures to provide service. They determine the maximum allowed software system failure rate, and can refer to the entire system or to one or more of its separate functions. Efficiency requirements deal with the hardware resources needed to perform all the functions of the software system in conformance to all other requirements. Integrity requirements deal with the software system security, that is, requirements to prevent access to unauthorized persons, to distinguish between the majority of personnel allowed to see the information and a limited group who will be allowed to add and change data. Usability requirements deal with the scope of staff resources needed to train a new employee and to operate the software system.
15 Product revision software quality factors Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for software failures, to correct the failures, and to verify the success of the corrections. The capabilities and efforts required to support adaptive maintenance activities are covered by the flexibility requirements. These include the resources (i.e. in man-days) required to adapt a software package to a variety of customers of the same trade, of various extents of activities, of different ranges of products and so on. Testability requirements deal with the testing of an information system as well as with its operation.
16 Product transition software quality factors Portability requirements tend to the adaptation of a software system to other environments consisting of different hardware, different operating systems, and so forth. Reusability requirements deal with the use of software modules originally designed for one project in a new software project currently being developed. Interoperability requirements focus on creating interfaces with other software systems or with other equipment firmware (for example, the firmware of the production machinery and testing equipment interfaces with the production control software). Interoperability requirements can specify the name(s) of the software or firmware for which interface is required. They can also specify the output structure accepted as standard in a specific industry or applications area.
17 The SQA system an SQA architecture SQA system always combines a wide range of SQA components, all of which are employed to challenge the multitude of sources of software errors and to achieve an acceptable level of software quality SQA system components can be classified into six classes: Pre-project components. To assure that (a) the project commitments have been adequately defined considering the resources required, the schedule and budget; and (b) the development and quality plans have been correctly determined. Components of project life cycle activities assessment. The project life cycle is composed of two stages: the development life cycle stage and the operation maintenance stage. The development life cycle stage components detect design and programming errors. Its components are divided into the following sub-classes: Reviews, Expert opinions, Software testing. Components of infrastructure error prevention and improvement eliminate or at least reduce the rate of errors, based on the organization s accumulated SQA experience Components of software quality management. control of development and maintenance activities and the introduction of early managerial support actions that mainly prevent or minimize schedule and budget failures and their outcomes Components of standardization, certification, and SQA system assessment Organizing for SQA the human components
18 Software project life cycle components main components are: Reviews Expert opinions Software testing Software maintenance Assurance of the quality of the subcontractors work and the customer supplied parts.
19 Reviews The design phase of the development process produces a variety of documents. The printed products include design reports, software test documents, software installation plans and software manuals, among others. Reviews can be categorized as formal design reviews (DRs) and peer reviews.
20 Software Reviews Purpose is to find defects (errors) before they are passed on to another software engineering activity or released to the customer Software engineers (and others) conduct formal technical reviews (FTR) for software engineers Using formal technical reviews (walkthroughs or inspections) is an effective means for improving software quality
21 Review Roles Presenter (designer/producer). Coordinator (not person who hires/fires). Recorder records events of meeting builds paper trail Reviewers maintenance oracle standards bearer user representative others
22 Formal Technical Reviews Involves 3 to 5 people Advance preparation (no more than 2 hours per person) required Duration of review meeting should be less than 2 hours Focus of review is on a discrete work product Review leader organizes the review meeting at the producer's request Reviewers ask questions that enable the producer to discover his or her own error (the product is under review not the producer) Producer of the work product walks the reviewers through the product Recorder writes down any significant issues raised during the review Reviewers decide to accept or reject the work product and whether to require additional reviews of product or not
23 Why do peer reviews To improve quality Catches 80% of all errors if done properly; both coding errors and design errors Enforce the spirit of any organization standards Training and insurance
24 Expert opinions Expert opinions support quality assessment efforts by introducing additional external capabilities into the organization s in-house development process.
25 Statistical Quality Assurance Information about software defects is collected and categorized Each defect is traced back to its cause Using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the "vital few" defect causes Move to correct the problems that caused the defects
26 Software testing Software tests are formal SQA components that are targeted toward review of the actual running of the software. tests are based on a prepared list of test cases that represent a variety of expected scenarios examine software modules, software integration, or entire software packages (systems) Software testing programs are constructed from a variety of tests, some manual and some automated. All tests have to be designed, planned and approved according to development procedures. test report will include a detailed list of the faults detected and recommendations about the performance of partial or complete recurrent tests following a subsequent round of corrections based on the test findings
27 Software maintenance components Software maintenance services vary in range and are provided for extensive periods, often several years. Corrective maintenance User s support services and correction of software code and documentation failures. Adaptive maintenance Adaptation of current software to new circumstances and customers without changing the basic software product. Functionality improvement maintenance The functional and performance - related improvement of existing software, carried out with respect to limited issues
28 Infrastructure components for error prevention and improvement goals of SQA infrastructure are the prevention of software faults or, at least, the lowering of software fault rates, together with the improvement of productivity This class of SQA components includes: Procedures and work instructions detailed definitions for the performance of specific types of development activities in a way that assures effective achievement of quality results Templates and checklists Staff training, retraining, and certification Preventive and corrective actions Configuration management Documentation control
29 Verification and Validation Verification and Validation are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose The PMBOK guide : "Validation - The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification. "Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation."
30 Validation Perspectives Reliability validation Does measured system reliability meet its specification? Is system reliability good enough to satisfy users? Safety validation Does system operate so that accidents do not occur? Are accident consequences minimized? Security validation Is system secure against external attack?
31 Validation Techniques Static techniques design reviews and program inspections mathematical arguments and proof Dynamic techniques statistical testing scenario-based testing run-time checking Process validation SE processes should minimize the chances of introducing system defects
32 Static Validation Techniques Concerned with analysis of documentation Focus is on finding system errors and identifying potential problems that may arise during system operation Documents may be prepared to support static validation structured arguments mathematical proofs
33 Poka-Yoke Devices mechanisms that lead to the prevention of a potential quality/function problem before it occurs or to the quick detection of a quality/function problem if one is introduced a simple, cheap, part of the engineering process, and are located near the process task where the mistakes are likely to occur
34 ISO/IEC 25010:2011 ISO/IEC 9126 Software engineering Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011 The standard is divided into four parts: quality model external metrics internal metrics quality in use metrics
35 ISO/IEC 25010:2011 Quality Model - classifies software quality in a structured set of characteristics and sub-characteristics Functionality - A set of attributes that bear on the existence of a set of functions and their specified properties Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions Maintainability - A set of attributes that bear on the effort needed to make specified modifications Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another
36 References Software Assurance Definitions, Daniel Galin, Software Quality Assurance - From theory to implementation, Pearson Addison Wesley, 2004 Software quality management, Verification and validation,
Software Quality Software Quality Assurance and Software Reuse Peter Lo Conformance to explicitly-stated functional and performance requirements, explicitly-documented development standards, and implicit
Evaluation of the Iceland State Financial and Human Resource System REPORT OF THE INDIVIDUAL EVALUATOR Annex 2 SYSTEM AND SOFTWARE QUALITY This paper lists the properties used in the two main models in
1) Explain quality control and also explain cost of quality. Quality Control Quality control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work
U.S. Department of Energy Washington, D.C. NOTICE DOE N 203.1 Approved: Expires: 06-02-01 SUBJECT: SOFTWARE QUALITY ASSURANCE 1. OBJECTIVES. To define requirements and responsibilities for software quality
Software Lecture 9 Software Engineering CUGS Spring 2011 Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden A Software Life-cycle Model Which part will we talk
Volume 2, Issue 12, December 2014 ISSN: 2321 7782 (Online) International Journal of Advance Research in Computer Science and Management Studies Research Article / Survey Paper / Case Study Available online
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
Chap 1. Software Quality Management Part 1.1 Quality Assurance and Standards Part 1.2 Software Review and Inspection Part 1.3 Software Measurement and Metrics 1 Part 1.1 Quality Assurance and Standards
CMMI STANDARDS IN SOFTWARE DEVELOPING PROCESS 1 2 C. SenthilMurugan, Dr. S. Prakasam. PhD Scholar Asst., Professor 1,2 Dept of Computer Science & Application, SCSVMV University, Kanchipuram 1 Dept of MCA,
Software Quality Assurance: VI Standards Room E 3.165 Tel. 60-3321 Email: email@example.com Outline I Introduction II Software Life Cycle III Quality Control IV Infrastructure V Management VI Standards VII Conclusion
Unit 7: Metric for Process and Product 7.1 Software Measurement Measurement is the process by which numbers or symbols are assigned to the attributes of entities in the real world in such a way as to define
IEEE ComputerSociety 1 Software and Systems software. (1) computer programs, procedures and possibly associated documentation and data pertaining to the operation of a computer system (IEEE 828-2012 IEEE
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
s Manual Software Quality Assurance From Theory to Implementation Daniel Galin For further instructor material please visit: www.booksites.net/galin ISBN 0273705660 Lecturers adopting the main text are
SOFTWARE ENGINEERING Chapter 26 Quality Management ETAM MEMBERS RN N 3521010116 Murali T 3521010117 Muralitharan S 3521010118 Narasimhan K 3521010119 Navaneethakrishnan D Areas Covered What is software
Software Quality Assurance in CMM and XP- A Comparative Study CH.V. Phani Krishna and Dr. K.Rajasekhara Rao CSE Department, KL University, Guntur dt., India. Abstract Software Quality Assurance is a planned
The Role of Information Technology Studies in Software Product Quality Improvement RUDITE CEVERE, Dr.sc.comp., Professor Faculty of Information Technologies SANDRA SPROGE, Dr.sc.ing., Head of Department
Chapter 5 29 Verification and Validation of Software Components and Component Based Christina Wallin Industrial Information Technology Software Engineering Processes ABB Corporate Research firstname.lastname@example.org
So#ware quality assurance - introduc4on Dr Ana Magazinius 1 What is quality? 2 What is a good quality car? 2 and 2 2 minutes 3 characteris4cs 3 What is quality? 4 What is quality? How good or bad something
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
Configuration Management for Reusable Software William B. Frakes Computer Science Department Virginia Tech email@example.com Abstract This paper discusses the configuration management of reusable software,
Failure Mode and Effect Analysis Lecture 4-3 Software Failure Mode and Effects Analysis in Software Software Development, Pries, SAE Technical Paper 982816 Software Development is Different Process variation
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
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
CSC 408F/CSC2105F Lecture Notes These lecture notes are provided for the personal use of students taking CSC 408H/CSC 2105H in the Fall term 2004/2005 at the University of Toronto. Copying for purposes
NOT MEASUREMENT SENSITIVE National Aeronautics and NASA-STD-8739.8 w/change 1 Space Administration July 28, 2004 SOFTWARE ASSURANCE STANDARD NASA TECHNICAL STANDARD REPLACES NASA-STD-2201-93 DATED NOVEMBER
Information Technology Engineers Examination Information Security Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination
Doc. No: STQC IT/ Assessment/ 01, Version 1.0 Procedure for Assessment of System and Software May, 2014 STQC - IT Services STQC Directorate, Department of Electronics and Information Technology, Ministry
Software Testing Rajat Kumar Bal Introduction In India itself, Software industry growth has been phenomenal. IT field has enormously grown in the past 50 years. IT industry in India is expected to touch
(STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This
PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name
MEASURING USABILITY OF ICONIC BASED GUIs OF MOBILE EMERGENCY SERVICE SOFTWARE BY USING HCI Y.Batu Salman, Adem Karahoca Bahcesehir University, Engineering Faculty, Computer Engineering Department Bahcesehir,
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
SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original
Testing Introduction IEEE Definitions Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
Curriculum Certified Software Tester (CST) Common Body of Knowledge Control Procedures Problem Resolution Reports Requirements Test Builds Test Cases Test Execution Test Plans Test Planning Testing Concepts
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
CAPACITY AND AVAILABILITY MANAGEMENT A Project Management Process Area at Maturity Level 3 Purpose The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision
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
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
1 Variation control in the context of software engineering involves controlling variation in the A) process applied B) resources expended C) product quality attributes D) all of the above 2 There is no
Central Page 284 of 296 Application of software product quality international standards through software development life cycle Mladen Hosni, Valentina Kirinić Faculty of Organization and Informatics University
Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers
COMMONWEALTH OF PENNSYLVANIA DEPARTMENT S OF PUBLIC WELFARE, INSURANCE, AND AGING INFORMATION TECHNOLOGY STANDARD Name Of Standard: Defect Management and Reporting Domain: Application Domain Date Issued:
THE ONLY BOOK CAN SIMPLY LEARN SOFTWARE TESTING! Page 1 Contents ABOUT THE AUTHOR... 3 1. Introduction To Software Testing... 4 2. What is Software Quality Assurance?... 7 3. What Is Software Testing?...
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
Oracle Insurance Policy Administration System Quality Assurance Testing Methodology An Oracle White Paper August 2008 Oracle Insurance Policy Administration System Quality Assurance Testing Methodology
Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes.. www.pharmout.net Page 1 of 15 Version-02 1. Scope 1.1. Purpose This paper reviews the implementation of the ANSI/AAMI/IEC
Günter Böckle Klaus Pohl Frank van der Linden 2 A Framework for Software Product Line Engineering In this chapter you will learn: o The principles of software product line subsumed by our software product
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand
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
Risk Analysis VI 513 Design of automatic testing tool for railway signalling systems software safety assessment J.-G. Hwang 1, H.-J. Jo 1 & H.-S. Kim 2 1 Train Control Research Team, Korea Railroad Research
Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role
Microsoft s Compliance Framework for Online Services Online Services Security and Compliance Executive summary Contents Executive summary 1 The changing landscape for online services compliance 4 How Microsoft
Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost
2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.
Overview of Software Engineering Principles 1 Software Engineering in a Nutshell Development of software systems whose size/ complexity warrants a team or teams of engineers multi-person construction of
SENG480A/CSC576A Topics in Software Engineering Software Development, Architecture & Evolution Lectures, Sep 17, 20, 2001 Hausi A. Müller University of Victoria Outline Assignment 1 due Sep 27 Last week
Role of Software Quality Assurance in Capability Maturity Model Integration Rekha Chouhan 1 Dr.Rajeev Mathur 2 1 Research Scholar, Jodhpur National University, JODHPUR 2 Director, CS, Lachoo Memorial College
9 March, 2010 ISSN 1866-5705 www.testingexperience.com free digital version print version 8,00 printed in Germany Advanced Testing Techniques Conferences Special istockphoto.com/nwphotoguy istockphoto.com/esemelwe
IAEA-TECDOC-1328 Solutions for cost effective assessment of software based instrumentation and control systems in nuclear power plants Report prepared within the framework of the Technical Working Group
Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP174 Table of Contents INTRODUCTION... 1 LEVEL-2, REPEATABLE... 3 Requirements Management... 3 Software Project
PESIT Bangalore South Campus Department of MCA SOFTWARE ENGINEERING 1. GENERAL INFORMATION Academic Year: JULY-NOV 2015 Semester(s):III Title Code Duration (hrs) SOFTWARE ENGINEERING 13MCA33 Lectures 52Hrs
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
Annex 7 Software Project Audit Process 1. Introduction 1.1 Purpose Purpose of this document is to describe the Software Project Audit Process which capable of capturing different different activities take
Effective Software Security Management choosing the right drivers for applying application security Author: Dharmesh M Mehta firstname.lastname@example.org / email@example.com Table of Contents Abstract... 1
Using TechExcel s DevSuite to Achieve FDA Software Validation Compliance For Medical Software Device Development The FDA requires medical software development teams to comply with its standards for software
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
Software Project Quality Management Kunal Jamsutkar 1, Viki Patil 2, P. M. Chawan 3 (Department of Computer Science, VJTI, MUMBAI, INDIA) ABSTRACT Quality Management is very important in Software Projects.
Quality Management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 1 Objectives To introduce the quality management process and key quality management activities To explain the
Quality Management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 27 Slide 1 Objectives To introduce the quality management process and key quality management activities To explain the
Document Purpose The purpose of this document is to provide guidance on the practice of Quality Management and to describe the practice overview, requirements, best practices, activities, and key terms
Chapter 8 Software Testing Summary 1 Topics covered Development testing Test-driven development Release testing User testing 2 Program testing Testing is intended to show that a program does what it is
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
Quality Management Managing the quality of the software process and products Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 1 Objectives To introduce the quality management process