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

2. Course Outline
Overview of Software Quality: Quality Assurance, Quality Aspects and factors, Quality Principles.
Software Models for testing and quality analysis: Control and Data flow graphs.
Inspection and review, principle of Software validation & verification
Software Testing: Phases of Testing, Test Coverage, Verification and Validation Techniques, Black box, white-box testing techniques, Testing using Fault Models, Test Execution.
Quality Processes: Planning and Documentation, Risk Analysis, Metrics.
Software Quality Standards: CMMI.

3. Books
TextBook:
“Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement” by Jeff Tian.
Reference:
Software testng in Rel World: imprving the process by kit, Edward
CMM in practise: Processes for executing softwre project at infosys by Jalote, Pamkaj.

4. Grading Assignments/Project– 6% Quizzes – 14% OHTs– 15% + 15%
Final Exam – 50%

5. Class Rules Let me do the talking No cell phones allowed (sms or call)
Be here & more important Be here on time
Announced/ Unannounced quiz! So don’t be surprised

6. Course Objective
To understand the state of the art software quality engineering activities and techniques

8. Introduction Traditional definition of quality: fitness of purpose,
a quality product does exactly what the users want it to do.

9. For software products, Fitness of Purpose fitness of purpose:
satisfaction of the requirements specified in SRS document.

10. Introduction Consider a software product: functionally correct,
i.e. performs all functions as specified in the SRS document,
but has an almost unusable user interface.
cannot be considered as a quality product.

11. Introduction Another example:
a product which does everything that users want.
but has an almost incomprehensible and unmaintainable code.

12. Modern view of Quality
Software quality is normally spoken of in terms of several different dimensions often called quality parameters
These can be split (roughly) into two groups
Technical Quality Parameters
correctness, reliability, capability, performance, maintainability
these are open to objective measures and technical solutions
User Quality Parameters
usability, installability, documentation, availability
these often require subjective analysis and nontechnical solutions

13. Technical Quality Parameters
Correctness- lack of bugs and defects
measured in terms of defect rate (# bugs per line of code)
Reliability- does not fail or crash often
measured in terms of failure rate (#failures per hour)
Capability- does all that is required
measured in terms of requirements coverage (% of required operations implemented)

14. Technical Quality Parameters
Maintainability- is ease to change and adapt to new requirements
measured in terms of change logs (time and effort required to add a new feature) and impact analysis (#lines affected by a new feature)
Performance- is fast and small enough
measured in terms of speed and space usage (seconds of CPU time, Mb of memory, etc.)

15. User Quality Parameters
Usability- is sufficiently convenient for the intended users
measured in terms of user satisfaction (% of users happy with interface and ease of use)
Installability - is convenient and fast to install
measured in terms of user satisfaction (#install problems reported per installation)
Documentation- is well documented
measured in terms of user satisfaction (% of users happy with documentation)
Availability- is easy to access and available when needed
measured in terms of user satisfaction (% of users reporting access problems)

16. McCall’s Factor Model
Classifies all software requirements into 11 factors.
The factors are grouped in 3 categories:
1.  Product operation factors
Factors that deal with requirements that directly affect the daily operation of the software.
2.  Product revision factors
Factors that deal with requirements that affect software maintenance.
3.  Product transition factors
Factors that deal with requirements that affect the adaptation of software to other platforms, environments, interaction with other software.

21. Why Software Quality Assurance?
Software errors cost the U.S. economy $60 billion annually in rework, lost productivity and actual damages.  We all know software bugs can be annoying, but faulty software can also be expensive, embarrassing, destructive and deadly. Following are some of the famous software “disasters”:

23. 1.  Mariner Bugs Out (1962)
Disaster:  The Mariner 1 rocket with a space probe headed for Venus diverted from its intended flight path shortly after launch.  Mission Control destroyed the rocket 293 seconds after liftoff.
Cost:  $18.5 million
Cause:  A programmer incorrectly transcribed a handwritten formula into computer code, missing a single superscript bar.  Without the smoothing function indicated by the bar, the software treated normal variations of velocity as if they were serious, causing faulty corrections that sent the rocket off course.

24. 2. Medical Machine Kills (1985)
Cost: Three people dead, three people critically injured
Disaster: Canada’s Therac-25 radiation therapy machine malfunctioned and delivered lethal radiation doses to patients.
Cause: Because of a subtle bug called a race condition, a technician could accidentally configure Therac-25 so the electron beam would fire in high-power mode without the proper patient shielding. 

25. 3. CIA Gives the Soviets Gas (1982)
Disaster:  Control software went haywire and produced intense pressure in the Trans-Siberian gas pipeline, resulting in the largest man-made non-nuclear explosion in Earth’s history.
Cost:  Millions of dollars, significant damage to Soviet economy
Cause:  CIA operatives allegedly planted a bug in a Canadian computer system purchased by the Soviets to control their gas pipelines.  The purchase was part of a strategic Soviet plan to steal or secretly obtain sensitive U.S. technology.  When the CIA discovered the purchase, they sabotaged the software so that it would pass Soviet inspection but fail in operation. 

26. 4. World War III… Almost (1983)
Disaster:  The Soviet early warning system falsely indicated the United States had launched five ballistic missiles. Fortunately the Soviet duty officer had a “funny feeling in my gut” and reasoned if the U.S. was really attacking they would launch more than five missiles, so he reported the apparent attack as a false alarm.
Cost:  Nearly all of humanity
Cause:  A bug in the Soviet software failed to
filter out false missile detections caused by
sunlight reflecting off cloud-tops. 26

27. 5. Pentium Fails Long Division (1993)
Cost: $475 million, corporate credibility
Disaster: Intel’s highly-promoted Pentium chip occasionally made mistakes when dividing floating-point numbers within a specific range. For example, dividing / yielded instead of , an error of 0.006%.  Although the bug affected few users, it become a public relations nightmare.  With an estimated 5 million defective chips in circulation, Intel offered to replace Pentium chips only for consumers who could prove they needed high accuracy.  Eventually Intel replaced the chips for anyone who complained.
Cause: The divider in the Pentium floating point unit had a flawed division table, missing about five of a thousand entries and resulting in these rounding errors

28. 6. Mars Climate Crasher (1998)
Disaster:  After a 286-day journey from Earth, the Mars Climate Orbiter fired its engines to push into orbit around Mars.  The engines fired, but the spacecraft fell too far into the planet’s atmosphere, likely causing it to crash on Mars.
Cost:  $125 million
Cause:  The  software that
controlled the Orbiter thrusters
used imperial units (pounds of force),
rather than metric units (Newtons)
as specified by NASA. 

29. Evolution of Quality Systems
Quality systems have evolved:
over the last five decades.
Prior to World War II,
way to produce quality products:
inspect the finished products
eliminate defective products.

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

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

32. Evolution of Quality Systems
Initial product inspection method :
gave way to quality control (QC).
Quality control:
not only detect the defective products and eliminate them
but also determine the causes behind the defects.

33. Quality Control (QC)
Quality control aims at correcting the causes of errors:
not just rejecting defective products.
Statistical quality control
quality of the output of the process is inferred using statistical methods
in stead of inspection or testing of all products

34. Quality Control (QC) The next breakthrough,
development of quality assurance principles

35. Quality Assurance (QA)
Basic premise of modern quality assurance:
if an organization's processes are good and are followed rigorously,
the products are bound to be of good quality.

36. Quality Assurance (QA)
All modern quality paradigms include:
guidance for recognizing, defining, analyzing, and improving the production process.

37. Project # 1 : Pair Assign Date: 15th Feb 2016 Due Date : 28th March 2016
Task 1 : Choose a partner
Task2 : Choose a topic (from the avail list)
Task 3: study the assign topic from various available resources
Task 4: Submit a comprehensive presentation
Task 5: Deliver the presentation 28th Mar – 2nd April

38. Assignment # 1 : Individual Assign Date: 10th Feb 2016 Due Date : 2nd March 2016
Choose a system of your own choice
Provide a detailed description of the system under consideration
Define Quality Parameter for the system covering both ;
Technical Quality Parameters
User Quality Parameters

39. What is Software Quality?
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,

40. 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.

41. 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.

42. 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.

43. Changing View of Quality
Past
Present
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

44. Past
Present
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

45. 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.

46. QA vs QC QA QC
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.

47. QA vs QC QA QC
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

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

49. 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

50. 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.

51. 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

52. 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

53. 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
Requirements 56 82
Design 27 13
Code 7 1
Other 10 4

54. Cost of Fixing Defects Relative cost of fixing defects
benchmark: cost at requirements phase = 1
Phase found
Cost ratio
Requirements 1
Design
3 – 5
Coding 10
Unit / integration testing
System / acceptance testing
30 – 70
Production