Software Quality Chapter 3 PDF

CHAPTER 3 SOFTWARE QUALITY Associate. Prof. Dr. Mohamed Marie 12/22/24 1 Chapter 3 Contents  Chapter 3: Software Quality 1. Software Quality Fundamentals 1.1. Software Engineering Culture and Ethics...

CHAPTER 3 SOFTWARE QUALITY Associate. Prof. Dr. Mohamed Marie 12/22/24 1 Chapter 3 Contents  Chapter 3: Software Quality 1. Software Quality Fundamentals 1.1. Software Engineering Culture and Ethics 1.2. Value and Costs of Quality 1.3. Models and Quality Characteristics 1.4. Software Quality Improvement 1.5. Software Safety 2. Software Quality Management Processes 2.1. Software Quality Assurance 2.2. Verification & Validation 2.3. Reviews and Audits 3. Practical Considerations 3.1. Software Quality Requirements 3.2. Defect Characterization 3.3. Software Quality Management Techniques 3.4. Software Quality Measurement 4. Software Quality Tools 12/22/24 2 ACRONYMS  CMMI Capability Maturity Model Integration  CoSQ Cost of Software Quality  COTS Commercial Off-the-Shelf Software  FMEA Failure Mode and Effects Analysis  FTA Fault Tree Analysis  PDCA Plan-Do-Check-Act  PDSA Plan-Do-Study-Act  QFD Quality Function Deployment  SPI Software Process Improvement  SQA Software Quality Assurance  SQC Software Quality Control  SQM Software Quality Management  TQM Total Quality Management  V&V Verification and Validation 12/22/24 3 INTRODUCTION  What is software quality, and why is it so important that it is included in many knowledge areas (KAs) of the SWEBOK Guide?  One reason is that the term software quality is overloaded. Software quality may refer: to desirable characteristics of software products, to the extent to which a particular software product possess those characteristics, and to processes, tools, and techniques used to achieve those characteristics. Over the years, authors and organizations have defined the term quality differently 12/22/24 4 BREAKDOWN OF TOPICS FOR SOFTWARE QUALITY 12/22/24 5 1. Software Quality Fundamentals  Reaching agreement on what constitutes quality for all stakeholders and clearly communicating that agreement to software engineers require that the many aspects of quality be formally defined and discussed.  A software engineer should understand quality concepts, characteristics, values, and their application to the software under development or maintenance. The important concept is that the software requirements define the required quality attributes of the software. Software requirements influence the measurement methods and acceptance criteria for assessing the degree to which the software and related documentation achieve the desired quality levels. 12/22/24 6 1.1. Software Engineering Culture and Ethics  Software engineers are expected to share a commitment to software quality as part of their culture. A healthy software engineering culture includes many characteristics, including the understanding that tradeoffs among cost, schedule, and quality are a basic tenant of the engineering of any product.  A strong software engineering ethic assumes that engineers accurately report information, conditions, and outcomes related to quality.  Ethics also play a significant role in software quality, the culture, and the attitudes of software engineers. The IEEE Computer Society and the ACM have developed a code of ethics and professional practice (see Codes of Ethics and Professional Conduct in the Software Engineering Professional Practice KA). 12/22/24 7 1.2. Value and Costs of Quality  This section presents cost of software quality (CoSQ): a set of measurements derived from the economic assessment of software quality development and maintenance processes.  The premise underlying the CoSQ is that the level of quality in a software product can be inferred from the cost of activities related to dealing with the consequences of poor quality. Poor quality means that the software product does not fully “satisfy stated and implied needs” or “established requirements.” There are four cost of quality categories: prevention, appraisal, internal failure, and external failure.  Prevention costs: include investments in software process improvement efforts, quality infrastructure, quality tools, training, audits, and management reviews.  Appraisal costs: arise from project activities that find defects. These appraisal activities can be categorized into costs of reviews (design, peer) and costs of testing (software unit testing, software integration, system level testing, acceptance testing); appraisal costs would be extended to subcontracted software suppliers.  Costs of internal failures: are those that are incurred to fix defects found during appraisal activities and discovered prior to delivery of the software product to the customer.  External failure costs: include activities to respond to software problems discovered after delivery to the customer.  Software engineers should be able to use CoSQ methods to ascertain levels of software quality and should also be able to present quality alternatives and their costs so that tradeoffs between cost, schedule, and delivery of stakeholder value can be made. 12/22/24 8 1.3. Models and Quality Characteristics 1.3.1. Software Process Quality  Software quality management and software engineering process quality have a direct bearing on the quality of the software product.  It is not possible to completely distinguish process quality from product quality because process outcomes include products. Determining whether a process has the capability to consistently produce products of desired quality is not simple.  The software engineering process, discussed in the Software Engineering Process KA, influences the quality characteristics of software products, which in turn affect quality as perceived by stakeholders. 12/22/24 9 1.3. Models and Quality Characteristics 1.3.2. Software Product Quality  The software engineer, first of all, must determine the real purpose of the software. In this regard, stakeholder requirements are paramount, and they include quality requirements in addition to functional requirements. Thus, software engineers have a responsibility to elicit quality requirements that may not be explicit at the outset and to understand their importance as well as the level of difficulty in attaining them. All software development processes (e.g., eliciting requirements, designing, constructing, building, checking, improving quality) are designed with these quality requirements in mind and may carry additional development costs if attributes such as safety, security, and dependability are important. The additional development costs help ensure that quality obtained can be traded off against the anticipated benefits. 12/22/24 10 1.4. Software Quality Improvement  The quality of software products can be improved through preventative processes or an iterative process of continual improvement, which requires management control, coordination, and feedback from many concurrent processes: (1) the software life cycle processes, (2) the process of fault/defect detection, removal, and prevention, and (3) the quality improvement process.  The theory and concepts behind quality improvement—such as building in quality through the prevention and early detection of defects, continual improvement, and stakeholder focus—are pertinent to software engineering. These concepts are based on the work of experts in quality who have stated that the quality of a product is directly linked to the quality of the process used to create it. Approaches such as the Deming improvement cycle of Plan-Do-Check-Act (PDCA), evolutionary delivery, kaizen, and quality function deployment (QFD) offer techniques to specify quality objectives and determine whether they are met. The Software Engineering Institute’s IDEAL is another method [7*]. Quality management is now recognized by the SWEBOK Guide as an important discipline.  Management sponsorship supports process and product evaluations and the resulting findings. Then an improvement program is developed identifying detailed actions and improvement projects to be addressed in a feasible time frame. Management support implies that each improvement project has enough resources to achieve the goal defined for it. Management sponsorship is solicited frequently by implementing proactive communication activities. 12/22/24 11 1.5. Software Safety  Safety-critical systems are those in which a system failure could harm human life, other living things, physical structures, or the environment. The software in these systems is safety-critical. There are increasing numbers of applications of safety-critical software in a growing number of industries. Examples of systems with safety-critical software include mass transit systems, chemical manufacturing plants, and medical devices. The failure of software in these systems could have catastrophic effects. There are industry standards, such as DO-178C , and emerging processes, tools, and techniques for developing safety-critical software. The intent of these standards, tools, and techniques is to reduce the risk of injecting faults into the software and thus improve software reliability.  Safety-critical software can be categorized as direct or indirect.  Direct is that software embedded in a safety-critical system, such as the flight control computer of an aircraft.  Indirect includes software applications used to develop safety-critical software. Indirect software is included in software engineering environments and software test environments.  Three complementary techniques for reducing the risk of failure are avoidance, detection and removal, and damage limitation. These techniques impact software functional requirements, software performance requirements, and development processes.  Increasing levels of risk imply increasing levels of software quality assurance and control techniques such as inspections. Higher risk levels may necessitate more thorough inspections of requirements, design, and code or the use of more formal analytical techniques.  Another technique for managing and controlling software risk is building assurance cases. An assurance case is a reasoned, auditable artifact created to support the contention that its claim or claims are satisfied. It contains the following and their relationships: one or more claims about properties; arguments that logically link the evidence and any assumptions to the claims; and a body of evidence and assumptions supporting these arguments. 12/22/24 12 2. Software Quality Management Processes  Software quality management is the collection of all processes that ensure that software products, services, and life cycle process implementations meet organizational software quality objectives and achieve stakeholder satisfaction [13, 14]. SQM defines processes, process owners, requirements for the processes, measurements of the processes and their outputs, and feedback channels throughout the whole software life cycle.  SQM comprises four subcategories: software quality planning, software quality assurance (SQA), software quality control (SQC), and software process improvement (SPI).  Software quality planning includes determining which quality standards are to be used, defining specific quality goals, and estimating the effort and schedule of software quality activities. In some cases, software quality planning also includes defining the software quality processes to be used.  SQA activities define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes.  SQC activities examine specific project artifacts (documents and executables) to determine whether they comply with standards established for the project (including requirements, constraints, designs, contracts, and plans). SQC evaluates intermediate products as well as the final products.  SPI activities seek to improve process effectiveness, efficiency, and other characteristics with the ultimate goal of improving software quality.  Software quality processes consist of tasks and techniques to indicate how software plans (e.g., software management, development, quality management, or configuration management plans) are being implemented and how well the intermediate and final products are meeting their specified requirements.  Risk management can also play an important role in delivering quality software. Incorporating disciplined risk analysis and management techniques into the software life cycle processes can help improve product quality. 12/22/24 13 2. Software Quality Management Processes 2.1. Software Quality Assurance  To quell a widespread misunderstanding, software quality assurance is not testing. SQA has two aspects: product assurance and process assurance, which are explained in section 2.3.  The software quality plan (in some industry sectors it is termed the software quality assurance plan) defines the activities and tasks employed to ensure that software developed for a specific product satisfies the project’s established requirements and user needs within project cost and schedule constraints and is commensurate with project risks. The SQAP first ensures that quality targets are clearly defined and understood.  The SQA plan’s quality activities and tasks are specified with their costs, resource requirements, objectives, and schedule in relation to related objectives in the software engineering management, software development, and software maintenance plans.  The SQA plan also identifies measures; statistical techniques; procedures for problem reporting and corrective action; resources such as tools, techniques, and methodologies; security for physical media; training; and SQA reporting and documentation. It can also contain acceptance criteria as well as reporting and management activities that are critical to software quality. 12/22/24 14 2. Software Quality Management Processes 2.2. Verification & Validation  The purpose of V&V is to help the development organization build quality into the system during the life cycle. V&V processes provide an objective assessment of products and processes throughout the life cycle. This assessment demonstrates whether the requirements are correct, complete, accurate, consistent, and testable.  Verification is an attempt to ensure that the product is built correctly, in the sense that the output products of an activity meet the specifications imposed on them in previous activities.  Validation is an attempt to ensure that the right product is built— that is, the product fulfills its specific intended purpose.  Both the verification process and the validation process begin early in the development or maintenance phase.  The purpose of planning V&V is to ensure that each resource, role, and responsibility is clearly assigned. The resulting V&V plan documents describe the various resources and their roles and activities, as well as the techniques and tools to be used. 12/22/24 15 2. Software Quality Management Processes 2.3. Reviews and Audits  Reviews and audit processes are broadly defined as static—meaning that no software programs or models are executed—examination of software engineering artifacts with respect to standards that have been established by the organization or project for those artifacts.  Different types of reviews and audits are distinguished by their purpose, levels of independence, tools and techniques, roles, and by the subject of the activity. Product assurance and process assurance audits are typically conducted by software quality assurance (SQA) personnel who are independent of development teams. Management reviews are conducted by organizational or project management. The engineering staff conducts technical reviews.  Management reviews evaluate actual project results with respect to plans.  Technical reviews (including inspections, walkthrough, and desk checking) examine engineering work-products.  Process assurance audits. SQA process assurance activities make certain that the processes used to develop, install, operate, and maintain software conform to contracts, comply with any imposed laws, rules, and regulations and are adequate, efficient and effective for their intended purpose.  Product assurance audits. SQA product assurance activities make certain to provide evidence that software products and related documentation are identified in and comply with contracts; and ensure that nonconformances are identified and addressed. 12/22/24 16 2. Software Quality Management Processes 2.3. Reviews and Audits 2.3.1. Management Reviews  The purpose of a management review is to monitor progress, determine the status of plans and schedules, and evaluate the effectiveness of management processes, tools and techniques.  Management reviews compare actual project results against plans to determine the status of projects or maintenance efforts.  The main parameters of management reviews are project cost, schedule, scope, and quality. Management reviews evaluate decisions about corrective actions, changes in the allocation of resources, or changes to the scope of the project. 12/22/24 17 2. Software Quality Management Processes 2.3. Reviews and Audits 2.3.2. Technical Reviews  The purpose of a technical review is to evaluate a software product by a team of qualified personnel to determine its suitability for its intended use and identify discrepancies from specifications and standards. It provides management with evidence to confirm the technical status of the project. 12/22/24 18 2. Software Quality Management Processes 2.3. Reviews and Audits 2.3.3. Inspections  “The purpose of an inspection is to detect and identify software product anomalies” [16*]. Some important differentiators of inspections as compared to other types of technical reviews are these:  1. Rules. Inspections are based upon examining a work-product with respect to a defined set of criteria specified by the organization. Sets of rules can be defined for different types of workproducts (e.g., rules for requirements, architecture descriptions, source code).  2. Sampling. Rather that attempt to examine every word and figure in a document, the inspection process allows checkers to evaluate defined subsets (samples) of the documents under review.  3. Peer. Individuals holding management positions over members of the inspection team do not participate in the inspection. This is a key distinction between peer review and management review.  4. Led. An impartial moderator who is trained in inspection techniques leads inspection meetings.  5. Meeting. The inspection process includes meetings (face to face or electronic) conducted by a moderator according to a formal procedure in which inspection team members report the anomalies they have found and other issues. 12/22/24 19 2. Software Quality Management Processes 2.3. Reviews and Audits  2.3.4. Walkthroughs  The purpose of a systematic walk-through is to evaluate a software product. A walkthrough may be conducted for the purpose of educating an audience regarding a software product.  Walkthroughs are distinguished from inspections. The main difference is that the author presents the work-product to the other participants in a meeting (face to face or electronic).  Unlike an inspection, the meeting participants may not have necessarily seen the material prior to the meeting.  The meetings may be conducted less formally. The author takes the role of explaining and showing the material to participants and solicits feedback.  Like inspections, walkthroughs may be conducted on any type of work-product including project plan, requirements, design, source code, and test reports. 12/22/24 20 2. Software Quality Management Processes 2.3. Reviews and Audits 2.3.5. Process Assurance and Product Assurance Audits  The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures.  Process assurance audits determine the adequacy of plans, schedules, and requirements to achieve project objectives. The audit is a formally organized activity with participants having specific roles—such as lead auditor, another auditor, a recorder, or an initiator—and including a representative of the audited organization. Audits identify instances of nonconformance and produce a report requiring the team to take corrective action. 12/22/24 21 3. Practical Considerations 3.2. Defect Characterization  The variety of terms prompts this section to provide a widely used set of definitions :  Computational Error: “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.”  Error: “A human action that produces an incorrect result.” A slip or mistake that a person makes. Also called human error.  Defect: An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced.” A defect is caused by a person committing an error.  Fault: A defect in source code. An “incorrect step, process, or data definition in computer program.” The encoding of a human error in source code. Fault is the formal name of a bug.  Failure: An “event in which a system or system component does not perform a required function within specified limits.” A failure is produced when a fault is encountered by the processor under specified conditions. 12/22/24 22