Sqa l01 1

SQA UNIT I
FUNDAMENTALS OF SOFTWARE QUALITY
ENGINEERING
Concepts of Quality-Hierarchical Modeling-
Quality Models- Quality Criteria And its Interrelation –
Fundamentals of Software Quality Improvement-
Concepts of Process Maturity- Improving Process
Maturity
8/23/2014
1

LEARNING ABOUT EACH OTHER
8/23/2014
2
Who am I?
 This talk is based on
 Workshops and
sessions in STTPs,
college,
 Publication in
conferences and
journals
 discussions with
academicians
 some experimentation.
 Who are You?
 Background
 Qualification
 Experience
 Pre requisite
 Mapping expectations

SYLLABUS
Term work
 Two tests,
 One Presentation/Case Study
 Six assignments based on the recommended
syllabus:
 Unit I: 1
 Unit II: 1
 Unit III: 2
 Unit IV: 1
 Unit V: 1
 Submission: Every next week after unit is complete
8/23/2014
3

BEFORE WE BEGIN……..
8/23/2014
4
Agenda
 Concepts of Quality
 Hierarchical Modeling-
 Quality Models
 Quality Criteria And its
Interrelation
 Fundamentals of Software
Quality Improvement-
 Concepts of Process
Maturity- Improving
Process Maturity
You can at any time in the
session:
 Interrupt
 Comment
 Share experience

DID YOU KNOW?
..BVITDid You Know 3.0 (Officially updated for 2012)
HD.mp4
8/23/2014
5

SOME FAMOUS SOFTWARE ERRORS
Patriot Missile System
NASA's Mars Polar Lander
ESA's Ariane 5 Launch System

PATRIOT MISSILE SYSTEM
 On February 25, 1991, the Patriot missile battery at Dharan,
Saudi Arabia had been in operation for 100 hours, by which
time the system's internal clock had drifted by one third of a
second. For a target moving as fast as an inbound TBM, this
was equivalent to a position error of 600 meters.
 The radar system had successfully detected the Scud and
predicted where to look for it next, but because of the time
error, looked in the wrong part of the sky and found no
missile. With no missile, the initial detection was assumed to
be a spurious track and the missile was removed from the
system. No interception was attempted, and the missile
impacted on a barracks killing 28 soldiers.

MARS POLAR LANDER
 The last telemetry from Mars Polar Lander was sent just prior to
atmospheric entry on December 3, 1999. No further signals have
been received from the lander. The cause of this loss of
communication is unknown.
 According to the investigation that followed, the most likely cause of
the failure of the mission was a software error that mistakenly
identified the vibration caused by the deployment of the lander's legs
as being caused by the vehicle touching down on the Martian surface,
resulting in the vehicle's descent engines being cut off whilst it was
still 40 meters above the surface, rather than on touchdown as
planned.
 Another possible reason for failure was inadequate preheating of
catalysis beds for the pulsing rocket thrusters

ARIANE 5 ROCKET
 June 4, 1996 was the first test flight of the Ariane 5 launch system. The
rocket tore itself apart 37 seconds after launch, making the fault one of
the most expensive computer bugs in history.
 The Ariane 5 software reused the specifications from the Ariane 4, but
the Ariane 5's flight path was considerably different and beyond the
range for which the reused code had been designed. Specifically, the
Ariane 5's greater acceleration caused the back-up and primary inertial
guidance computers to crash, after which the launcher's nozzles were
directed by spurious data. Pre-flight tests had never been performed on
the re-alignment code under simulated Ariane 5 flight conditions, so the
error was not discovered before launch.
 Because of the different flight path, a data conversion from a 64-bit
floating point to 16-bit signed integer caused a hardware exception
(more specifically, an arithmetic overflow, as the floating point number
had a value too large to be represented by a 16-bit signed integer).
Efficiency considerations had led to the disabling of the exception
handler for this error. This led to a cascade of problems, culminating in
destruction of the entire flight.

2003 NORTH AMERICA BLACKOUT
August 14, 2003
 12:15 p.m. Inaccurate data input renders a system monitoring tool in Ohio ineffective.
 1:31 p.m. The Eastlake, Ohio, generating plant shuts down.
 2:02 p.m. First 345-kV line in Ohio fails due to contact with a tree in Walton Hills, Ohio.
 2:14 p.m. An alarm system fails at FirstEnergy's control room and is not repaired.
 2:27 p.m. Second 345-kV line fails due to tree.
 3:05 p.m. A 345-kV transmission line fails in Parma, south of Cleveland due to a tree.
 3:17 p.m. Voltage dips temporarily on the Ohio portion of the grid. Controllers take no action, but power shifted by the first failure
onto another 345-kV power line causes it to sag into a tree. While Mid West ISO and FirstEnergy controllers try to understand the
failures, they fail to inform system controllers in nearby states.
 3:39 p.m. A First Energy 138-kV line fails.
 3:41 and 3:46 p.m. Two breakers connecting FirstEnergy’s grid with American Electric Power are tripped as a 345-kV power line
and 15 138-kV lines fail in northern Ohio. Later analysis suggests that this could have been the last possible chance to save the
grid if controllers had cut off power to Cleveland at this time.
 4:06 p.m. A sustained power surge on some Ohio lines begins uncontrollable cascade after another 345-kV line fails.
 4:09:02 p.m. Voltage sags deeply as Ohio draws 2 GW of power from Michigan.
 4:10:34 p.m. Many transmission lines trip out, first in Michigan and then in Ohio, blocking the eastward flow of power. Generators
go down, creating a huge power deficit. In seconds, power surges out of the East, tripping East coast generators to protect them,
and the blackout is on.
 4:10:37 p.m. Eastern Michigan grid disconnects from western part of state.
 4:10:38 p.m. Cleveland separates from Pennsylvania grid.
 4:10:39 p.m. 3.7 GW power flow from East through Ontario to southern Michigan and northern Ohio, more than ten times larger
than the condition 30 seconds earlier, causing voltage drop across system.
 4:10:40 p.m. Flow flips to 2 GW eastward from Michigan through Ontario, then flip westward again in a half second.
 4:10:43 p.m. International connections begin failing.
 4:10:45 p.m. Western Ontario separates from east when power line north of Lake Superior disconnects. First Ontario plants go
offline in response to unstable system. Quebec is protected because its lines are DC, not AC.
 4:10:46 p.m. New York separates from New England grid. 4:10:50 p.m. Ontario separates from Western New York grid.
 4:11:57 p.m. Last lines between Michigan and Ontario fail.
 4:13 p.m. End of cascade. 256 power plants are off-line. 85% went offline after the grid separations occurred,
most of them on automatic controls. 50 million people without power.

CAUSES OF SOFTWARE ERRORS
1. faulty requirements definition
2. client-developer communication failures
3. deliberate deviations from software requirements
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
text section 2.3

CONCEPTS OF QUALITY
8/23/2014
12

WHAT IS QUALITY?
 Quality is conformance to specifications (British Defense Industries
Quality Assurance Panel)
 Quality is conformance to requirements: Phil Crosby
 Quality is fitness for purpose or use: Juran
 Quality is a predictable degree of uniformity and dependability, at low
cost and suited to the market: Edward Deming
 Quality is synonymous with customer needs and expectations: R J
Mortimoys
 Quality is meeting the (stated) requirements of the customer- now and in
the future: Mike Robinson
 Quality is the total composite product and service characteristics of
marketing, engineering, manufacturing and maintenance through which
the product and service in use will meet the expectations by the
customer: Arman Feiganbaum
 Totality of characteristics of an entity that bear on its ability to satisfy
stated and implied needs: ISO 8402: 1994

DEFINITION OF
"SOFTWARE QUALITY"
Pressman's
Conformance to explicitly
stated functional and
performance requirements,
explicitly documented
development standards,
and implicit characteristics
that are expected of all
professionally developed
software.
1. IEEE’s
2. The degree to which a
system, component, or
process meets
specified
requirements.
3. The degree to which a
system, component, or
process meets
customer or user
needs or expectations.

IEEE DEFINITION OF
"SOFTWARE QUALITY ASSURANCE"
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.

CMM
"The Capability Maturity Model for Software developed by the SEI is
a framework that describes the key elements of an effective software
process. The CMM describes an evolutionary improvement path for
software organizations from an ad hoc, immature process to a
mature, disciplined one.“
"The CMM covers practices for planning, engineering, and managing
software development and maintenance. When followed, these
practices improve the ability of organizations to meet goals for cost,
schedule, functionality, and product quality."

WHAT IS A PRODUCT?
 A generic term that refers to
 Goods
 Services
 Failure to meet quality requirements in either
dimension can have serious negative
consequences
 Product characteristics:
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability

DIFFERENCE BETWEEN
QUALITY AND GRADE
 Software Scenario 1
 High quality (no bugs, readable manual)
 Low grade (limited number of features)
 Software Scenario 2
 Low quality (many bugs, poorly organized user
documentation)
 High grade (numerous features)
Quality Management Issues
 Customer satisfaction
 Conformance to requirements
 Fitness for use
 Prevention over inspection
 Management responsibility

QUALITY MANAGEMENT PROCESSES
 Quality Planning involves identifying which quality
standards are relevant to the project and determining
how to satisfy them
 Quality Assurance is all the planned and systematic
activities implemented within the quality system to
provide confidence that the project will satisfy the
relevant quality standards.
 Quality Control involves monitoring specific project
results to determine if they comply with relevant quality
standards, and identifying ways to eliminate causes of
unsatisfactory results

PREVENTION AND INSPECTION
 Prevention
 Keeping errors out of the process
 Inspection
 Keeping errors put of the hands of the customer.

SOFTWARE QUALITY – GATES &
GM
 At a COMDEX exposition, Bill Gates stated, “If General
Motors had kept up with technology like the computer industry
has, we would all be driving twenty-five dollar cars that got
1000 miles to the gallon.”
 In response to Gates’ comments, General Motors issued a
press release stating, “If GM had developed technology like
Microsoft, we would all be driving cars with the following
characteristics:
22

GM
 For no reason whatsoever your car would crash
twice a day.
 Every time they repainted the lines on the road
you would have to buy a new car.
 Occasionally your car would die on the freeway
for no reason, and you would just accept this,
restart, and drive on.
 Occasionally, executing a maneuver such as a
left turn, would cause your car to shut down and
refuse to restart, in which case you would have to
reinstall the engine.
 The airbag system would say ‘Are you sure?’
before going off. 23

GM
 Occasionally, for no reason whatsoever, your car
would lock you out and refuse to let you in until
you simultaneously lifted the door handle, turned
the key, and grabbed hold of the radio antenna.
 Every time GM introduced a new model car,
buyers would have to learn how to drive all over
again because none of the controls would operate
in the same manner as the old car.
 You would press the Start button to shut off the
engine.
24

QUALITY MATTERS
 Software quality is a critical success factor.
 Software quality must:
 Have the support of the management
 Be planned early in the design phase
 Be understood and followed by everyone on the team
 Be monitored continuously
 Be documented for accountability and reference
25

QUALITY MATTERS
 Several factors influenced system developers to
consider system quality:
 End user computing environment
 User friendly tools
 User satisfaction as surrogate for system success
 Fourth generation languages/products
26

QUALITY ADVANTAGE
 Emphasis on quality has several advantages:
 Financial – maintenance, time
 Operational – rework, bugs
 Legal – privacy, security
 Contractual – compliance
 Customer relation – CRM
 Reputation – image
 Moral – being part of a winning team
 Appraisal – performance evaluation
27

HIERARCHICAL MODELING
8/23/2014
28

QUALITY MODELS
View model
• Transcendental view
• User view
• Manufacturing view
• Product view
• Value-based view
8/23/2014
29

 Transcendental view
 Quality is something that can be recognized through
experience, but not defined in some tractable form.
 A good quality object stands out, and it is easily recognized.
 User view
 Quality concerns the extent to which a product meets user
needs and expectations.
 Is a product fit for use?
 This view is highly personalized.
 A product is of good quality if it satisfies a large number of users.
 It is useful to identify the product attributes which the users consider
to be important.
 This view may encompass many subject elements, such as
usability, reliability, and efficiency.
8/23/2014
30

 Manufacturing view
 This view has its genesis in the manufacturing industry – auto and
electronics.
 Key idea: Does a product satisfy the requirements?
 Any deviation from the requirements is seen as reducing the quality of
the product.
 The concept of process plays a key role.
 Products are manufactured “right the first time” so that the cost is
reduced
 Development cost
 Maintenance cost
 Conformance to requirements leads to uniformity in products.
 Some argue that such uniformity does not guarantee quality.
 Product quality can be incrementally improved by improving the
process.
 The CMM and ISO 9001 models are based on the manufacturing view
8/23/2014
31

 Product view
 Hypothesis: If a product is manufactured with good internal
properties, then it will have good external properties.
 One can explore the causal relationship between internal properties
and external qualities.
 Example: Modularity enables testability.
 Value-based view
 This represents the merger of two concepts: excellence and worth.
 Quality is a measure of excellence, and value is a measure of worth.
 Central idea
 How much a customer is willing to pay for a certain level of quality.
 Quality is meaningless if a product does not make economic sense.
 The value-based view makes a trade-off between cost and quality.
8/23/2014
32

QUALITY CRITERIA AND ITS
INTERRELATION
8/23/2014
33

SOFTWARE QUALITY ASSURANCE
 An alternate view of Quality:
 is not absolute
 is multidimensional, can be difficult to quantify
 has aspects that are not easy to measure
 assessment is subject to constraints (e.g., cost)
 is about acceptable compromises
 criteria are not independent, can conflict

SOFTWARE QUALITY ASSURANCE
 Quality Criteria include:
 correctness
 efficiency
 flexibility
 integrity
 interoperability
 maintainability
 portability
 reliability
 reusability
 testability
 usability

36
MCCALL’S QUALITY FACTORS AND CRITERIA
 Quality Factors
 McCall, Richards, and Walters studied the concept of software
quality in terms of two key concepts as follows:
 quality factors, and
 quality criteria.
 A quality factor represents the behavioral characteristic of a system.
 Examples: correctness, reliability, efficiency, testability, portability, …
 A quality criterion is an attribute of a quality factor that is related to
software development.
 Example:
 Modularity is an attribute of the architecture of a software system.
 A highly modular software allows designers to put cohesive
components in one module, thereby increasing the maintainability of
the system.
 McCall et al. identified 11 quality factors (Table 17.1.)

37

38
 The 11 quality factors defined in Table 17.1 have been
grouped into three broad categories (See Table 17.2.)
 Product operation
 Product revision
 Product transition
Table 17.2: Categorization of McCall’s quality factors [10].

39
 Quality Criteria
 A quality criterion is an attribute of a quality factor that is
related to software development.
 Example:
 Modularity is an attribute of the architecture of a software system.
 A highly modular software allows designers to put cohesive
components in one module, thereby increasing the maintainability of
the system.
 In Table 17.3, we have listed 23 quality criteria.

SE, Quality, Hans van Vliet, ©2008 40
QUALITY ATTRIBUTES (MCCALL)
 Product operation
 Correctness does it do what I want?
 Reliability does it do it accurately all of the
time?
 Efficiency will it run on my hardware as well
as it can?
 Integrity is it secure?
 Usability can I use it?
 Product revision
 Maintainability can I fix it?
 Testability can I test it?
 Flexibility can I change it?
 Product transition
 Portability will I be able to use it on another
machine?
 Reusability will I be able to reuse some of the
software?
 Interoperability will I be able to interface it with another
system?

41
Table 17.3: McCall’s quality criteria [10].

42
 Relationship Between Quality Factors and Quality
Criteria
 Each quality factor is positively influenced by a set of quality
criteria, and the same quality criterion impacts a number of
quality factors.
 Example: Simplicity impacts reliability, usability, and testability.
 If an effort is made to improve one quality factor, another
quality factor may be degraded.
 Portable code may be less efficient.
 Some quality factors positively impact others.
 An effort to improve the correctness of a system will increase its
reliability.
 See Figure 17.1.

43

44
THE ISO 9126 QUALITY CHARACTERISTICS
 The ISO 9126 document is the product of an
international effort.
 ISO: International Organization for Standardization
 The document defines six broad quality characteristics as
shown in Table 17.4.
 The document includes an example quality model
(Figure 17.2) that further decomposes the quality
characteristics.
 Figure 17.2 is just an example, and not a universal one.
 The 20 subcharacteristics of Figure 17.2 have been defined in
Table 17.5.

45
Table 17.4: ISO 9126 quality characteristics.

46

47

48
 McCall’s quality model vs. ISO 9126 model
 What is called quality factor in McCall’s model is called a quality
subcharacteristic in the ISO 9126 model.
 The following quality factors/characteristics are found in both the
models.
 reliability, usability, efficiency, maintainability, and portability
 Differences between the two models
 The ISO 9126 model emphasizes on characteristics visible to the users,
whereas the McCall model considers internal qualities as well.
 In McCall’s model, one quality criterion can impact many quality factors,
whereas in the ISO 9126 model, one subcharacteristic impacts exactly
one quality characteristic.
 A high-level quality factor, such as testability, in the McCall’s model is a
low-level subcharacteristic of maintainability in the ISO 9126 model.
 Concerns
 There is no consensus about what high-level quality factors are most
important at the top level. McCall, et al. define 11 high-level quality
factors, whereas there are only six in the ISO 9126 document.
 There is no consensus regarding what is a top-level quality factor/
characteristic and what is a more concrete quality criterion/
subcharacteristic.

49
THE ISO 9000:2000 SOFTWARE QUALITY
STANDARD
 The international organization ISO has developed a series of
standards for quality assurance and quality management,
collectively known as the ISO 9000.
 The ISO 9000 standards are reviewed and updated once every
5-8 years. The standards released in the year 2000 are known
as ISO 9000:2000.
 There are three components of the ISO 9000:2000 standard.
 ISO 9000: Fundamentals and vocabulary
 ISO 9001: Requirements
 ISO 9004: Guidelines for performance improvements
 Note: ISO 9002 and ISO 9003 were parts of ISO 9000:1994,
but these are no more parts of ISO 9000:2000.

50
STANDARD
 ISO 9000:2000 Fundamentals:
 This is based on eight principles.
 Principle 1: Customer focus
 Principle 2: Leadership
 Principle 3: Involvement of people
 Principle 4: Process approach
 Principle 5: System approach to management
 Principle 6: Continual improvement
 Principle 7: Factual approach to decision making
 Principle 8: Mutually beneficial supplier relationships

51
STANDARD
 ISO 9001:2000 Requirements
 The five major parts of this document are as follows.
 Part 4. Systemic requirements
 Part 5. Management requirements
 Part 6. Resource requirements
 Part 7. Realization requirements
 Part 8. Remedial requirements

52
STANDARD
 Part 4. Systemic requirements (partial)
 Document the organizational policies and goals. Publish a vision
document.
 Document all quality processes and their interrelationship.
 Implement a mechanism to approve documents before those are
distributed.
 Part 5: Management requirements (partial)
 Generate an awareness for quality to meet a variety of requirements,
such as customer, regulatory, and statutory.
 Focus on customers by identifying and meeting their requirements in
order to satisfy them.
 Develop a quality policy to meet the customer’s needs.
 Clearly define individual responsibilities and authorities concerning
the implementation of quality policies.

53
STANDARD
 Part 6. Resource requirements (partial)
 Identify and provide resources required to support the organizational
quality policy in order to realize the quality objectives.
 Allocate quality personnel resource to projects.
 Put in place a mechanism to enhance the quality level of personnel.
 Part 7: Realization requirements (partial)
 Develop a plan to realize a product from its requirements.
 Interact with customers to gather their requirements. Classify those
requirements.
 Review the requirements.
 Follow a defined purchasing process by evaluating potential
suppliers based on a number of factors, such as ability to meet
requirements and price.

54
STANDARD
 Part 8. Remedial requirements (partial)
 Measure and track the customer’s satisfaction level.
 Perform internal audit.
 Example: Find out whether or not personnel with adequate
education, experience, and skill have been assigned to a project.
 Monitor processes by using a set of key performance indicators.

THANK YOU
For your time
For participation in the session
For being a learner
For the work you do everyday!!!!!!!
8/23/2014
55
Contact:
4.seema@gmail.com

Sqa l01 1

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (9)

Similar a Sqa l01 1

Similar a Sqa l01 1 (20)

Más de Seema Shah

Más de Seema Shah (10)

Último

Último (20)

Sqa l01 1