Upload
seema-shah
View
177
Download
1
Tags:
Embed Size (px)
DESCRIPTION
SQA slides are consolidated from resources available on Internet. Slides relevant for MU MCA TY elective.
Citation preview
04
/12
/20
23
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
04
/12
/20
23
2
LEARNING ABOUT EACH OTHER
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
04
/12
/20
23
3
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
04
/12
/20
23
4
BEFORE WE BEGIN……..
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
04
/12
/20
23
5
DID YOU KNOW?
..\BVIT\Did You Know 3.0 (Officially updated for 2012) HD.mp4
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 errorstext section 2.3
04
/12
/20
23
12
CONCEPTS OF QUALITY
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’s2. 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 BETWEENQUALITY 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
SOFTWARE QUALITY – GATES & 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
SOFTWARE QUALITY – GATES & 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
04
/12
/20
23
28
HIERARCHICAL MODELING
04
/12
/20
23
29
QUALITY MODELS
View model• Transcendental view• User view• Manufacturing view• Product view• Value-based view
04
/12
/20
23
30
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.
04
/12
/20
23
31
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
04
/12
/20
23
32
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.
04
/12
/20
23
33
QUALITY CRITERIA AND ITS INTERRELATION
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
Q
uality Factors
McC
all, Richards, and W
alters studied the concept of softw
are quality in terms of tw
o key concepts as follow
s:quality factors, and
quality criteria.
A quality factor represents the behavioral
characteristic of a system.
Exam
ples: correctness, reliability, efficiency, testability, portability, …
A quality criterion is an attribute of a quality
factor that is related to software
development.
Exam
ple:
Modularity is an attribute of the architecture
of a software system
.
A highly m
odular software allow
s designers to put cohesive com
ponents in one module,
thereby increasing the maintainability of the
system.
McC
all et al. identified 11 quality factors (Table 17.1.)
37
MCCALL’S QUALITY FACTORS AND CRITERIA
38
MCCALL’S QUALITY FACTORS AND CRITERIA
The 11 quality factors defined in
Table 17.1 have been grouped into three broad categories (S
ee Table 17.2.)
Product operation
Product revision
Product transition
Table 17.2: Categorization of M
cCall’s
quality factors [10].
39
MCCALL’S QUALITY FACTORS AND CRITERIA
Quality C
riteria
A quality criterion is an attribute of a
quality factor that is related to softw
are development.
Exam
ple:
Modularity is an attribute of the
architecture of a software system
.
A highly m
odular software allow
s designers to put cohesive com
ponents in one m
odule, thereby increasing the m
aintainability 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
MCCALL’S QUALITY FACTORS AND CRITERIA
Table 17.3: McC
all’s quality criteria [10].
42
MCCALL’S QUALITY FACTORS AND CRITERIA
Relationship B
etween Q
uality F
actors and Quality C
riteriaE
ach quality factor is positively influenced by a set of quality criteria, and the sam
e quality criterion im
pacts a number of quality factors.
Exam
ple: Simplicity im
pacts reliability, usability, and testability.
If an effort is made to im
prove one quality factor, another quality factor m
ay be degraded.
Portable code may be less efficient.
Som
e quality factors positively im
pact others.
An effort to im
prove the correctness of a system
will increase its reliability.
See F
igure 17.1.
43
MCCALL’S QUALITY FACTORS AND CRITERIA
44
THE ISO 9126 QUALITY CHARACTERISTICS
The IS
O 9126 docum
ent is the product of an international effort.
ISO: International O
rganization for S
tandardization
The docum
ent defines six broad quality characteristics as show
n in Table 17.4.
The docum
ent includes an example
quality model (F
igure 17.2) that further decom
poses the quality characteristics.
Figure 17.2 is just an exam
ple, and not a universal one.
The 20 subcharacteristics of F
igure 17.2 have been defined in Table 17.5.
45
THE ISO 9126 QUALITY CHARACTERISTICS
Table 17.4: ISO
9126 quality characteristics.
46
THE ISO 9126 QUALITY CHARACTERISTICS
47
THE ISO 9126 QUALITY CHARACTERISTICS
48
THE ISO 9126 QUALITY CHARACTERISTICS
McC
all’s quality model vs. IS
O 9126 m
odel
What is called quality factor in M
cCall’s m
odel is called a quality subcharacteristic in the IS
O
9126 model.
T
he following quality factors/characteristics are
found in both the models.
reliability, usability, efficiency, maintainability, and
portability
Differences betw
een the two m
odels
The IS
O 9126 m
odel emphasizes on characteristics
visible to the users, whereas the M
cCall m
odel considers internal qualities as w
ell.
In McC
all’s model, one quality criterion can im
pact m
any quality factors, whereas in the IS
O 9126
model, one subcharacteristic im
pacts exactly one quality characteristic.
A high-level quality factor, such as testability, in the
McC
all’s model is a low
-level subcharacteristic of m
aintainability in the ISO
9126 model.
Concerns
There is no consensus about w
hat high-level quality factors are m
ost important at the top
level. McC
all, et al. define 11 high-level quality factors, w
hereas there are only six in the ISO
9126 docum
ent.
There is no consensus regarding w
hat is a top-level quality factor/ characteristic and w
hat is a m
ore concrete quality criterion/ subcharacteristic.
49
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
T
he international organization ISO
has developed a series of standards for quality assurance and quality m
anagement, collectively know
n as the IS
O 9000.
The IS
O 9000 standards are
reviewed and updated once every 5-
8 years. The standards released in
the year 2000 are known as IS
O
9000:2000.
There are three com
ponents of the IS
O 9000:2000 standard.
ISO
9000: Fundam
entals and vocabulary
ISO
9001: Requirem
ents
ISO
9004: Guidelines for perform
ance im
provements
Note: IS
O 9002 and IS
O 9003 w
ere parts of IS
O 9000:1994, but these
are no more parts of IS
O 9000:2000.
50
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
ISO
9000:2000 Fundam
entals:
This is based on eight principles.
Principle 1: Custom
er focusPrinciple 2: L
eadershipPrinciple 3: Involvem
ent of people
Principle 4: Process approach
Principle 5: System approach to
managem
ent
Principle 6: Continual im
provement
Principle 7: Factual approach to decision m
aking
Principle 8: Mutually beneficial supplier
relationships
51
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
ISO
9001:2000 Requirem
ents
The five m
ajor parts of this document
are as follows.
Part 4. Systemic requirem
entsPart 5. M
anagement requirem
ents
Part 6. Resource requirem
ents
Part 7. Realization requirem
ents
Part 8. Rem
edial requirements
52
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
ISO
9001:2000 Requirem
ents
Part 4. S
ystemic requirem
ents (partial)
Docum
ent the organizational policies and goals. P
ublish a vision document.
Docum
ent all quality processes and their interrelationship.
Implem
ent a mechanism
to approve docum
ents before those are distributed.
Part 5: M
anagement requirem
ents (partial)
Generate an aw
areness for quality to m
eet a variety of requirements, such as
customer, regulatory, and statutory.
Focus on customers by identifying and
meeting their requirem
ents in order to satisfy them
.
Develop a quality policy to m
eet the custom
er’s needs.
Clearly define individual responsibilities
and authorities concerning the im
plementation of quality policies.
53
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
ISO
9001:2000 Requirem
ents
Part 6. R
esource 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: R
ealization requirements
(partial)
Develop a plan to realize a product from
its requirem
ents.
Interact with custom
ers to gather their requirem
ents. Classify those
requirements.
Review
the requirements.
Follow a defined purchasing process by
evaluating potential suppliers based on a num
ber of factors, such as ability to m
eet requirements and price.
54
THE ISO 9000:2000 SOFTWARE QUALITY STANDARD
ISO
9001:2000 Requirem
ents
Part 8. R
emedial requirem
ents (partial)
Measure and track the custom
er’s satisfaction level.
Perform internal audit.
Exam
ple: 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.
04
/12
/20
23
55
THANK YOU
For your time
For participation in the session
For being a learner
For the work you do everyday!!!!!!!
Contact: