Lecture#1 Introduction….Cont Software Quality Engineering Subject : 19(A/B) – {Assignment /Query}

Evolution of Quality Systems 2 Quality systems have evolved: over the last five decades Previously way to produce quality products: inspect the finished products eliminate defective products

Evolution of Quality Systems 3 Since that time, – quality systems of organizations have undergone four stages of evolution.

Evolution of Quality Systems 4 Inspection Quality Control (QC) Quality Assurance (QA) Total Quality Management (TQM)

Quality Assurance vs. Quality Control Quality Assurance It is fault prevention through process design and Auditing Creating processes, procedures, tools etc. to prevent faults from occurring Prevent defect injection as much as possible Quality Control It is fault/failure detection through static and/or dynamic testing of artifacts It is examining of artifacts against pre-determined criteria to measure conformance

Quality Control Methods Reviews – Personal, peer, pair, management, QA, independent Testing – Structural, functional, integration, stress/performance, regression, field, acceptance Simulations – Prototypes, models Field Trials – Prototypes, beta testing Mathematical – Proofs of correctness

Quality Assurance (on the other hand) Software quality is the conformance to explicitly stated functional and performance requirements, documented development standards, and implicit characteristics Product Improvement through Process Improvement Main Focus – Processes how maintained – Handling of product how done Focus on the process by which the product is getting developed

What is Software Quality? 11 In the context of software engineering, software quality measures: – how well software is designed (quality of design), and – how well the software conforms to that design (quality of conformance) The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126] explicitly documented development standards

What is Software Quality ? Narrowest sense of software quality – Lack of bugs. – Low defect rate (# of defects/size unit) – High reliability (number of failures per n hours of operation). Mean Time To Failure (MTTF): probability of failure-free operation in a specified time. 12

Software Quality Challenges Complex Software requires different monitoring procedures than trivial applications. Quality criteria vary dramatically depending on the phase of the project at which the evaluation takes place The measures of the quality must be specific to the project being evaluated and must assess the effectiveness of the entire development process, not just individual segments. 13

Software Quality Challenges Quality cannot be directly checked in the product; it must planned right from the beginning. Quality goals must be clearly defined, effectively monitored, and rigorously enforced. The project must focus on the quality issues of the project from the beginning, ensuring that quality criteria are consistent with defined requirements. Quality must be planed into the project structure, constantly evaluated, and corrections applied when deficiencies are identified. 14

Changing View of Quality PastPresent Quality is the responsibility of blue collar workers and direct labor employees working on the product Quality is everyone’s responsibility, including, white- collar workers, the indirect labor force and the overhead staff Quality defects should be hidden from the customers and management Defects should be highlighted and brought to the surface for corrective actions Quality problems lead to blame, faulty justification and excuses Quality problems lead to cooperative solutions 15

PastPresent Increased quality will increase project costs Improved quality saves money and increase business People want to produce quality products Quality occurs during project execution Quality occurs at project initiation and must be planned for within the project 16

QUALITY: PERSPECTIVES AND EXPECTATIONS Five major views : transcendental, user, manufacturing, product, and value-based views

In the transcendental view, quality is hard to define or describe in abstract terms, but can be recognized if it is present. It is generally associated with some intangible properties that delight users. In the user view, quality is fitness for purpose or meeting user’s needs. In the manufacturing view, quality means conformance to process standards. In the product view, the focus is on inherent characteristics in the product itself in the hope that controlling these internal quality indicators (or the so-called product-internal metrics) will result in improved external product behavior. In the value-based view, quality is the customers’ willingness to pay for a software.

Quality Control v/s Quality Assurance Quality means meeting requirements and meeting customer needs, which means a defect-free product from both the producer’s and the customer’s viewpoint. Both quality control and quality assurance are used to make quality happen. Quality is an attribute of a product. A product is something produced, such as a requirement document, test data, source code etc. 20

QA vs QC QAQC Quality Assurance (QA) is the set of activities (including facilitation, training, measurement and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products or services that conform to requirements and are fit for use. Quality Control (QC) is defined as the processes and methods used to compare product quality to requirements and applicable standards, and the action taken when a nonconformance is detected. 21

QAQC Quality Control QA is an activity that establishes and evaluates the processes that produce the products. If there is no process, there is no role for QA. QC is an activity that verifies whether or not the product produced meets standards. Defining Processes Walkthrough Quality Audit Selection of Tools Inspection Checkpoint Review QA vs QC 22

Scope and Content Hierarchy 23 Software Testing, Software Quality Assurance (SQA), Software Quality Control (SQC) & Software Quality Engineering (SQE) Software Quality Engineering Software Quality Assurance Software Quality Control Software Testing

Nine Causes of Software Errors 1. Faulty definition of requirements – Erroneous requirement definitions – Absence of important requirements – Incomplete requirements – Unnecessary requirements included 2. Client-developer communication failures – Misunderstanding of client requirements presented in writing, orally, etc. – Misunderstanding of client responses to design problems 24

Nine Causes of Software Errors 3. Deliberate deviations from software requirements – Reuse of existing software components from previous projects without complete analysis – Functionality omitted due to budge or time constraints “Improvements” to software that are not in requirements 4. Logical design errors – Errors in interpreting the requirements into a design (e.g. errors in definitions of boundary conditions, algorithms, reactions to illegal operations,...) 5. Coding errors – Errors in interpreting the design document, errors related to incorrect use of programming language constructs, etc. 25

Nine Causes of Software Errors 6. Non-compliance with documentation and coding instructions – Errors resulting from other team members coordinating with non- complying member’s code – Errors resulting from individuals trying to understand/maintain/test non-complying member’s code 7. Shortcomings of the testing process – incomplete test plan – Failure to report all errors/faults resulting from testing – Incorrect reporting of errors/faults – Incomplete correction of detected errors 26

Nine Causes of Software Errors 8. Procedural errors – Incorrect procedures related to user activities that occur in the software 9. Documentation errors – Errors in the design documents or code comments – Errors in user manuals for software 27

When are defects introduced? The majority of defects are introduced in earlier phases. – Requirements are the top factor in a project’s success or failure. Phase% of defects % effort to fix Requirements5682 Design2713 Code71 Other104 28

Cost of Fixing Defects Relative cost of fixing defects – benchmark: cost at requirements phase = 1 Phase foundCost ratio Requirements1 Design3 – 5 Coding10 Unit / integration testing System / acceptance testing30 – 70 Production

30