Chapter 5 Software Quality Assurance-Finalised_BW.ppt
- 1. Slides by Roger Pressman. 1 Chapter 5 Software Quality Assurance
- 2. Slides by Roger Pressman. 2 software quality assurance The IEEE definition for software quality assurance is as follows − "A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. A set of activities designed to evaluate the process by which the products are developed or manufactured."
- 3. Slides by Roger Pressman. 3 What is Quality Assurance? • Software Quality Assurance (SQA) is a set of activities for ensuring quality in software engineering processes. • It ensures that developed software meets and complies with the defined or standardized quality specifications. • SQA is an ongoing process within the Software Development Life Cycle (SDLC) that routinely checks the developed software to ensure it meets the desired quality measures. • SQA practices are implemented in most types of software development, regardless of the underlying software development model being used
- 4. Slides by Roger Pressman. 4 Elements of SQA • Standards • Reviews and Audits • Testing • Error/defect collection and analysis • Change management • Education • Vendor management • Security management • Safety • Risk management
- 5. Slides by Roger Pressman. 5 McCall’s Factor Model • This model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories – product operation, product revision, and product transition factors. 1. Product operation factors − Correctness, Reliability, Efficiency, Integrity, Usability. 2. Product revision factors − Maintainability, Flexibility, Testability. 3. Product transition factors − Portability, Reusability, Interoperability.
- 6. Slides by Roger Pressman. 6 Software quality metrics • Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project. Software quality metrics can be further divided into three categories − 1. Product quality metrics 2. In-process quality metrics 3. Maintenance quality metrics
- 7. Slides by Roger Pressman. 7 Product Quality Metrics 1. Mean Time to Failure 2. Defect Density 3. Customer Problems 4. Customer Satisfaction Mean Time to Failure • It is the time between failures. This metric is mostly used with safety critical systems such as the airline traffic control systems, avionics, and weapons. Defect Density • It measures the defects relative to the software size expressed as lines of code or function point, etc. i.e., it measures code quality per unit. This metric is used in many commercial software systems. Customer Problems • It measures the problems that customers encounter when using the product. It contains the customer’s perspective towards the problem space of the software, which includes the non-defect oriented problems together with the defect problems.
- 8. Slides by Roger Pressman. 8 In-process Quality Metrics • In-process quality metrics deals with the tracking of defect arrival This metric includes − 1. Defect density during machine testing 2. Defect arrival pattern during machine testing 3. Phase-based defect removal pattern 4. Defect removal effectiveness
- 9. Slides by Roger Pressman. 9 Maintenance Quality Metrics • Although much cannot be done to alter the quality of the product during this phase, following are the fixes that can be carried out to eliminate the defects as soon as possible with excellent fix quality. 1.Fix backlog and backlog management index 2.Fix response time and fix responsiveness 3.Percent delinquent fixes 4.Fix quality
- 10. Slides by Roger Pressman. 10 SQA Activities 1. Process definition and implementation 2. Auditing 3. Training Processes could be − • Software Development Methodology • Project Management • Configuration Management • Requirements Development/Management • Estimation • Software Design • Testing, etc. • Once the processes have been defined and implemented, Quality Assurance has the following responsibilities − 1. Identify the weaknesses in the processes 2. Correct those weaknesses to continually improve the process
- 11. Components of SQA System • An SQA system always combines a wide range of SQA components. These components can be classified into the following six classes − 1. Pre-project components • This assures that the project commitments have been clearly defined considering the resources required, the schedule and budget; and the development and quality plans have been correctly determined. 2.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, and Software testing. • The SQA components used during the operation–maintenance phase include specialized maintenance components as well as development life cycle components, which are applied mainly for functionality to improve the maintenance tasks. 11 Slides by Roger Pressman.
- 12. Components of SQA System 3.Components of infrastructure error prevention and improvement • The main objective of these components, which is applied throughout the entire organization, is to eliminate or at least reduce the rate of errors, based on the organization’s accumulated SQA experience. 4.Components of software quality management • This class of components deal with several goals, such as the 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. 5.Components of standardization, certification, and SQA system assessment • These components implement international professional and managerial standards within the organization. The main objectives of this class are utilization of international professional knowledge, improvement of coordination of the organizational quality systems with other organizations, and assessment of the achievements of quality systems according to a common scale. The various standards may be classified into two main groups: quality management standards and project process standards. 6.Organizing for SQA – the human components • The SQA organizational base includes managers, testing personnel, the SQA unit and the persons interested in software quality such as SQA trustees, SQA committee members, and SQA forum members. Their main objectives are to initiate and support the implementation of SQA components, detect deviations from SQA procedures and methodology, and suggest improvements. 12 Slides by Roger Pressman.
- 13. Components of SQA System Pre-project Software Quality Components • These components help to improve the preliminary steps taken before starting a project. It includes − 1. Contract Review 2. Development and Quality Plans Contract Review • Normally, a software is developed for a contract negotiated with a customer or for an internal order to develop a firmware to be embedded within a hardware product. In all these cases, the development unit is committed to an agreed-upon functional specification, budget and schedule. Hence, contract review activities must include a detailed examination of the project proposal draft and the contract drafts. Specifically, contract review activities include − 1. Clarification of the customer’s requirements 2. Review of the project’s schedule and resource requirement estimates 3. Evaluation of the professional staff’s capacity to carry out the proposed project 4. Evaluation of the customer’s capacity to fulfil his obligations 5. Evaluation of development risks 13 Slides by Roger Pressman.
- 14. Components of SQA System Pre-project Software Quality Components Development and Quality Plans • After signing the software development contract with an organization or an internal department of the same organization, a development plan of the project and its integrated quality assurance activities are prepared. These plans include additional details and needed revisions based on prior plans that provided the basis for the current proposal and contract. • Most of the time, it takes several months between the tender submission and the signing of the contract. During these period, resources such as staff availability, professional capabilities may get changed. The plans are then revised to reflect the changes that occurred in the interim. The main issues treated in the project development plan are − 1. Schedules 2. Required manpower and hardware resources 3. Risk evaluations 4. Organizational issues: team members, subcontractors and partnerships 5. Project methodology, development tools, etc. 6. Software reuse plans The main issues treated in the project’s quality plan are − Quality goals, expressed in the appropriate measurable terms 1. Criteria for starting and ending each project stage 2. Lists of reviews, tests, and other scheduled verification and validation activities 14 Slides by Roger Pressman.
- 15. Slides by Roger Pressman. 15 SQA Goals • Requirements quality. The correctness, completeness, and consistency of the requirements model will have a strong influence on the quality of all work products that follow. • Design quality. Every element of the design model should be assessed by the software team to ensure that it exhibits high quality and that the design itself conforms to requirements. • Code quality. Source code and related work products (e.g., other descriptive information) must conform to local coding standards and exhibit characteristics that will facilitate maintainability. • Quality control effectiveness. A software team should apply limited resources in a way that has the highest likelihood of achieving a high quality result.
- 16. Slides by Roger Pressman. 16 Statistical SQA Product & Process measurement ... an understanding of how to improve quality ... Collect information on all defects Find the causes of the defects Move to provide fixes for the process
- 17. Slides by Roger Pressman. 17 Statistical SQA • Information about software errors and defects is collected and categorized. • An attempt is made to trace each error and defect to its underlying cause (e.g., non-conformance to specifications, design error, violation of standards, poor communication with the customer). • Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate the 20 percent (the vital few). • Once the vital few causes have been identified, move to correct the problems that have caused the errors and defects.
- 18. Slides by Roger Pressman. 18 Six-Sigma for Software Engineering • The term “six sigma” is derived from six standard deviations—3.4 instances (defects) per million occurrences—implying an extremely high quality standard. • The Six Sigma methodology defines these core steps: 1. Define customer requirements and deliverables and project goals via well-defined methods of customer communication 2. Measure the existing process and its output to determine current quality performance (collect defect metrics) 3. Analyze defect metrics and determine the vital few causes. 4. Improve the process by eliminating the root causes of defects. 5. Control the process to ensure that future work does not reintroduce the causes of defects.
- 19. Slides by Roger Pressman. 19 ISO 9001:2000 Standard • ISO 9001:2000 is the quality assurance standard that applies to software engineering. • The standard contains 20 requirements that must be present for an effective quality assurance system. • The requirements delineated by ISO 9001:2000 address topics such as – management responsibility, quality system, contract review, design control, document and data control, product identification and traceability, process control, inspection and testing, corrective and preventive action, control of quality records, internal quality audits, training, servicing, and statistical techniques.
- 20. What is Reliability Testing? • Software reliability testing a testing technique that relates to testing a software's ability to function given environmental conditions consistently that helps uncover issues in the software design and functionality. Parameters involved in Reliability Testing: 1. Dependent elements of reliability Testing: 2. Probability of failure-free operation 3. Length of time of failure-free operation 4. The environment in which it is executed Key Parameters that are measured as part of reliability are given below: 1. MTTF: Mean Time To Failure 2. MTTR: Mean Time To Repair 3. MTBF: Mean Time Between Failures (= MTTF + MTTR) 20 Slides by Roger Pressman.
- 21. Software Maintenance • Software maintenance is widely accepted part of SDLC now a days. It stands for all the modifications and updations done after the delivery of software product. There are number of reasons, why modifications are required, some of them are briefly mentioned below: 1. Market Conditions - Policies, which changes over the time, such as taxation and newly introduced constraints like, how to maintain bookkeeping, may trigger need for modification. 2. Client Requirements - Over the time, customer may ask for new features or functions in the software. 3. Host Modifications - If any of the hardware and/or platform (such as operating system) of the target host changes, software changes are needed to keep adaptability. 4. Organization Changes - If there is any business level change at client end, such as reduction of organization strength, acquiring another company, organization venturing into new business, need to modify in the original software may arise 21 Slides by Roger Pressman.
- 22. Types of maintenance • In a software lifetime, type of maintenance may vary based on its nature. 1. Corrective Maintenance - This includes modifications and updations done in order to correct or fix problems, which are either discovered by user or concluded by user error reports. 2. Adaptive Maintenance - This includes modifications and updations applied to keep the software product up-to date and tuned to the ever changing world of technology and business environment. 3. Perfective Maintenance - This includes modifications and updates done in order to keep the software usable over long period of time. It includes new features, new user requirements for refining the software and improve its reliability and performance. 4. Preventive Maintenance - This includes modifications and updations to prevent future problems of the software. It aims to attend problems, which are not significant at this moment but may cause serious issues in future. 22 Slides by Roger Pressman.
- 23. Maintanence Activities 23 Slides by Roger Pressman.
- 24. Software Configuration Management • Software Configuration Management(SCM) is a process to systematically manage, organize, and control the changes in the documents, codes, and other entities during the Software Development Life Cycle. • The primary goal is to increase productivity with minimal mistakes. SCM is part of cross- disciplinary field of configuration management and it can accurately determine who made which revision. 24 Slides by Roger Pressman.
- 25. Tasks in SCM process • Configuration Identification • Baselines • Change Control • Configuration Status Accounting • Configuration Audits and Reviews 25 Slides by Roger Pressman.
- 26. Tasks in SCM process • Configuration Identification: • Configuration identification is a method of determining the scope of the software system. With the help of this step, you can manage or control something even if you don't know what it is. It is a description that contains the CSCI type (Computer Software Configuration Item), a project identifier and version information. • Baseline: • A baseline is a formally accepted version of a software configuration item. It is designated and fixed at a specific time while conducting the SCM process. It can only be changed through formal change control procedures. • Change Control: • Change control is a procedural method which ensures quality and consistency when changes are made in the configuration object. In this step, the change request is submitted to software configuration manager. • Configuration Status Accounting: • Configuration status accounting tracks each release during the SCM process. This stage involves tracking what each version has and the changes that lead to this version • Configuration Audits and Reviews: • Software Configuration audits verify that all the software product satisfies the baseline needs. It ensures that what is built is what is delivered. 26 Slides by Roger Pressman.
- 27. Software Re-engineering • When we need to update the software to keep it to the current market, without impacting its functionality, it is called software re- engineering. It is a thorough process where the design of software is changed and programs are re-written. • Legacy software cannot keep tuning with the latest technology available in the market. As the hardware become obsolete, updating of software becomes a headache. Even if software grows old with time, its functionality does not. • For example, initially Unix was developed in assembly language. When language C came into existence, Unix was re-engineered in C, because working in assembly language was difficult. • Other than this, sometimes programmers notice that few parts of software need more maintenance than others and they also need re- engineering. 27 Slides by Roger Pressman.
- 28. Re-Engineering Process • Decide what to re-engineer. Is it whole software or a part of it? • Perform Reverse Engineering, in order to obtain specifications of existing software. • Restructure Program if required. For example, changing function- oriented programs into object-oriented programs. • Re-structure data as required. • Apply Forward engineering concepts in order to get re-engineered software. 28 Slides by Roger Pressman.
- 29. Reverse Engineering • It is a process to achieve system specification by thoroughly analyzing, understanding the existing system. This process can be seen as reverse SDLC model, i.e. we try to get higher abstraction level by analyzing lower abstraction levels. • An existing system is previously implemented design, about which we know nothing. Designers then do reverse engineering by looking at the code and try to get the design. With design in hand, they try to conclude the specifications. Thus, going in reverse from code to system specification. 29 Slides by Roger Pressman.
- 30. 30 Slides by Roger Pressman. Forward Engineering 1. The cost to maintain one line of source code may be 20 to 40 times the cost of initial development of that line. 2. Redesign of the software architecture (program and/or data structure), using modern design concepts, can greatly facilitate future maintenance. 3. Because a prototype of the software already exists, development productivity should be much higher than average. 4.The user now has experience with the software. Therefore, new requirements and the direction of change can be ascertained with greater ease. 5.CASE tools for reengineering will automate some parts of the job. 6. A complete software configuration (documents, programs and data) will exist upon completion of preventive maintenance.
- 31. 31 Slides by Roger Pressman. Computer Aided Software Engineering TOOLS • CASE stands for Computer Aided Software Engineering. It means, development and maintenance of software projects with help of various automated software tools. • CASE Tools • CASE tools are set of software application programs, which are used to automate SDLC activities. CASE tools are used by software project managers, analysts and engineers to develop software system. • There are number of CASE tools available to simplify various stages of Software Development Life Cycle such as Analysis tools, Design tools, Project management tools, Database Management tools, Documentation tools are to name a few. • Use of CASE tools accelerates the development of project to produce desired result and helps to uncover flaws before moving ahead with next stage in software development.
- 32. Categories of CASE Tools • CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage: Case Tools • Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of SDLC. • Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance. • Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from Requirement gathering to Testing and documentation. • CASE tools can be grouped together if they have similar functionality, process activities and capability of getting integrated with other tools. 32 Slides by Roger Pressman.
- 33. Enf of Chapter 5 • Good Luck..Dear Students 33 Slides by Roger Pressman.