unit 1
TRANSCRIPT
Software Quality Management
July 27, 2011
Author name : Selvapriyavadhana
1
P.Selvapriyavadhana,Asst.Prof,ACT
Syllabus
MC9277 : SOFTWARE QUALITY MANAGEMENT
UNIT I : FUNDAMENTALS OF SOFTWARE QUALITY ENGINEERING
Concepts Of Quality - Hierarchical Modeling - Quality Models - Quality Cri-
teria And Its Interrelation - Fundamentals Of Software Quality Improvement -
Concepts Of Quality Improvement - Concepts Of Process Maturity - Improving
Process Maturity.
UNIT II:DEVELOPMENTS IN MEASURING QUALITY
Selecting Quality Goals And Measures - Principles Of Measurement - Measures
And Metrics - Quality Function Deployment - Goal/Question/Measure Paradigm
- Quality Characteristics Tree - The FURPS Model And FURPS+ - Gilb Ap-
proach -Quality Prompts.
UNIT III:QUALITY MANAGEMENT SYSTEM
Elements Of A Quality Engineering Program - Quality Control, Assurance And
Engineering - Reliability, Maintainability, Verifiability, Testability, Safety And
Supportability - Historical Perspective Elements Of QMS - Human Factors -
Time Management - QMS For Software-Quality Assurance - ISO9000 Series-A
Generic Quality Management Standard - Tools For Quality.
UNIT IV:PRINCIPLES AND PRACTICES IN QMS
Process-Product-Project-People In Software Development And Management Spec-
trum - Principle And Critical Practices In QMS - ISO 9001 And Capability Ma-
turity Models -Six Sigma, Zero Defects And Statistical Quality Control.
UNIT V MEASURES AND METRICS IN PROCESS AND PROJECT DO-
MAINS
Key Measures For Software Engineers - Defects - Productivity And Quality -
Measuring And Improving The Development Process - Assigning Measures To
Process Elements And Events - Isikawa Diagrams - Metrics For Software Quality
- Integrating Metrics Within Software Engineering Process - Metrics For Small
Organizations.
SQM 2
P.Selvapriyavadhana,Asst.Prof,ACT
Fundamentals of software quality engineering
1 Quality
Software quality In the context of software engi-neering, software quality measures how well soft-ware is designed (quality of design), and how wellthe software conforms to that design (quality ofconformance), although there are several differ-ent definitions.
Definition:
1. Conformance to specification: Quality thatis defined as a matter of products and ser-vices whose measurable characteristics satisfya fixed specification that is conformance to anin beforehand defined specification.
2. Meeting customer needs: Quality that is iden-tified independent of any measurable charac-teristics. That is quality is defined as theproducts or services capability to meet cus-tomer expectations explicit or not.
3. Quality is the degree of goodness of a productor service or perceived by the customer.
The Department of Defense (DOD, 1985) in theUSA defines software quality as “ the degree towhich the attributes of the software enable it toperform its intended end use” .
SQM 3
P.Selvapriyavadhana,Asst.Prof,ACT
Characteristics of Quality:
Quality is a multidimensional construct. It may therefore be consid-
ered using a polyhedron metaphor. Within this metaphor, a three-
dimensional solid represents quality. Each face represents a different
aspect of quality such as correctness, reliability, and efficiency.
• Quality is not absolute.
• Quality is multidimensional.
• Quality is subject to constraints
• Quality is about acceptable compromises.
• Quality criteria are not independent, but in-teract with each other causing conflicts.
Views of Quality
In an attempt to classify different and conflictingviews of quality,Garvin(1984) has suggested fivedifferent views of quality:
1. The transcendent view
• Innate excellence
• Classical definition
2. The product-based view
• Higher the quality higher the cost
• Greater functionality
• Greater care in development
3. The user-based view
• Fitness for purpose
• Very hard to quantify
SQM 4
P.Selvapriyavadhana,Asst.Prof,ACT
4. The manufacturing view
• Measures quality in terms of conformance
• Zero defects
5. The value-based view
• Provides the data with what the customerrequires at a price.
2 HIERARCHICAL MODEL OF QUALITY
To compare quality in different situations, bothqualitatively and quantitatively, it is necessary toestablish a model of quality.
Many model suggested for quality.
Most are hierarchical in nature.
A quantitative assessment is generally made, alongwith a more quantified assessment.
Two principal models of this type, one by Boehm(1978)and one byMcCall in 1977. A hierarchical modelof software quality is based upon a set of qualitycriteria, each of which has a set of measures ormetrics associated with it.The issues relating to the criteria of quality are:
• What criteria of quality should be employed?
• How do they inter-relate?
• How may the associated metrics be combinedinto a meaningful overall measure of Quality?
SQM 5
P.Selvapriyavadhana,Asst.Prof,ACT
THE HIERARCHICAL MODELS OF BOEHMAND MCCALL THE GE MODEL
• This model was first proposed byMcCall in1977.
• It was later revised as theMQmodel, and it isaimed by system developers to be used duringthe development process.
• In early attempt to bridge the gap betweenusers and developers, the criteria were chosenin an attempt to reflect user? s views as wellas developer? s priorities.
• The criteria appear to be technically oriented,but they are described by a series of questionswhich define them in terms to non specialistmanagers.
SQM 6
P.Selvapriyavadhana,Asst.Prof,ACT
The three areas addressed by McCall’s model(1977)
Product operation : (basic operational characteristics)requires that it can be learnt easily, operated ef-ficiently And it results are those required by theusers.The product operations perspective identifies qual-ity factors that influence the extent to which thesoftware fulfils its specification:-
• Correctness, the functionality matches the spec-ification.
• Reliability, the extent to which the systemfails.
• Efficiency, system resource (including cpu, disk,memory, network) usage.
• Integrity, protection from unauthorized ac-cess.
• Usability, ease of use.
Product revision : (ability to change) it is concernedwith error correction and adaptation Of the sys-tem and it is most costly part of software devel-opment.The product revision perspective identifies qual-ity factors that influence the ability to change thesoftware product, these factors are:-
• Maintainability, the ability to find and fix adefect.
• Flexibility, the ability to make changes re-quired as dictated by the business.
SQM 7
P.Selvapriyavadhana,Asst.Prof,ACT
• Testability, the ability to Validate the soft-ware requirements.
Product transition : (adaptability to new environments)it is an important application and it is distributedprocessing and the rapid rate of change in hard-ware is Likely to increase.The product transition perspective identifies qual-ity factors that influence the ability to adapt thesoftware to new environments:-
• Portability, the ability to transfer the softwarefrom one environment to another.
• Reusability, the ease of using existing softwarecomponents in a different context.
• Interoperability, the extent, or ease, to whichsoftware components work together.
McCall’s criteria of quality defined
1. Efficiency is concerned with the use of re-sources e.g. processor time, storage. It fallsinto two categories: execution efficiency andstorage efficiency.
2. Usability is the ease of use of the software.
3. Integrity is the protection of the program fromunauthorized access.
4. Correctness is the extent to which a programfulfils its specification.
5. Reliability is its ability not to fail.
6. Maintainability is the effort required to locateand fix a fault in the program within its op-erating environment.
SQM 8
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 1: The GE model after McCall
7. Flexibility is the ease of making changes re-quired by changes in the operating environ-ment.
8. Testability is the ease of testing the programs,to ensure that it is error-free and meet itsspecification.
9. Portability is the effort required to transfer aprogram from one environment to another.
10. Reusability is the ease of refusing software ina different context.
11. Interoperability is the effort required to cou-ple the system to another system.
SQM 9
P.Selvapriyavadhana,Asst.Prof,ACT
The Boehm model (1978)
• It is to provide a set of well-defined, well-differentiated characteristics of software qual-ity.
• It is hierarchical in nature but the hierarchyis extended, so that quality criteria are sub-divided.
• According to the uses made of the system andthey are classed into general or as is and theutilities are a subtype of the general utilities,to the product operation.
• There are two levels of actual quality criteria,the intermediate level being further split intoprimitive characteristics which are amenableto measurement.
• This model is based upon a much larger setof criteria than McCall s model, but retainsthe same emphasis on technical criteria.
• The two models share a number of commoncharacteristics are,
1. The quality criteria are supposedly basedupon the user s view.
2. The models focus on the parts that design-ers can more readily analyze.
3. Hierarchical models cannot be tested orvalidated. It cannot be shown that themetrics accurately reflect the criteria.
4. The measurement of overall quality is achievedby a weighted summation of the character-istics.
SQM 10
P.Selvapriyavadhana,Asst.Prof,ACT
Boehm talks of modifiability where McCall dis-tinguishes expandability from adaptability anddocumentation, understandability and clarity.
3 Quality Models
In the previous section we presented some quality management gurus
as well as their ideas and views on quality primarily because this is
a used and appreciated approach for dealing with quality issues in
software developing organizations. Whereas the quality management
philosophies presented represent a more flexible and qualitative view
on quality, this section will present a more fixed and quantitative
quality structure view
McCalls Quality Model (1977)
One of the more renown predecessors of todays quality models is the
quality model presented by Jim McCall (also known as the General
Electrics Model of 1977). This model, as well as other contemporary
models, originates from the US military (it was developed for the
US Air Force, promoted within DoD) and is primarily aimed towards
the system developers and the system development process. It his
quality model McCall attempts to bridge the gap between users and
developers by focusing on a number of software quality factor that
reflect both the users views and the developers priorities.
Three major perspectives for defining and identifying the quality of
a software product:
• product revision (ability to undergo changes),
• product transition (adaptability to new envi-ronments) and
• product operations (its operation characteris-tics).
SQM 11
P.Selvapriyavadhana,Asst.Prof,ACT
• Product revision includes
1. Maintainability (the effort required to lo-cate and fix a fault in the program withinits operating environment),
2. Flexibility (the ease of making changes re-quired by changes in the operating envi-ronment) and
3. Testability (the ease of testing the pro-gram, to ensure that it is error-free andmeets its specification).
• Product transition is all about portability (theeffort required to transfer a program from oneenvironment to another),
1. Reusability (the ease of reusing software ina different context) and
2. Interoperability (the effort required to cou-ple the system to another system).
• Quality of product operations depends on
1. Correctness (the extent to which a pro-gram fulfils its specification),
2. Reliability (the systems ability not to fail),
3. Efficiency (further categorized into execu-tion efficiency and storage efficiency andgenerally meaning the use of resources, e.g.processor time, storage),
4. Integrity (the protection of the programfrom unauthorized access) and
5. Usability (the ease of the software).
SQM 12
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 2: McCalls Quality Model
Boehms Quality Model (1978)
The second of the basic and founding predeces-sors of todays quality models is the quality modelpresented by Barry W. Boehm . Boehm addressesthe contemporary shortcomings of models thatautomatically and quantitatively evaluate the qual-ity of software. In essence his models attemptsto qualitatively define software quality by a givenset of attributes and metrics. Boehm’s model issimilar to the McCall Quality Model in that italso presents a hierarchical quality model struc-tured around high-level characteristics, interme-diate level characteristics, primitive characteris-tics - each of which contributes to the overallquality level.
SQM 13
P.Selvapriyavadhana,Asst.Prof,ACT
The high-level characteristics represent basic high-level requirements
of actual use to which evaluation of software quality could be put
the general utility of software. The high-level characteristics address
three main questions that a buyer of software has:
• As-is utility: How well (easily, reliably, effi-ciently) can I use it as-is?
• Maintainability: How easy is it to understand,modify and retest?
• Portability: Can I still use it if I change myenvironment?
The intermediate level characteristic representsBoehms 7 quality factors that together representthe qualities expected from a software system:
• Portability (General utility characteristics): Codepossesses the characteristic portability to theextent that it can be operated easily and wellon computer configurations other than its cur-rent one.
• Reliability (As-is utility characteristics): Codepossesses the characteristic reliability to theextent that it can be expected to perform itsintended functions satisfactorily.
• Efficiency (As-is utility characteristics): Codepossesses the characteristic efficiency to theextent that it fulfills its purpose without wasteof resources.
• Usability (As-is utility characteristics, HumanEngineering): Code possesses the characteris-tic usability to the extent that it is reliable,efficient and human-engineered.
• Testability (Maintainability characteristics): Codepossesses the characteristic testability to the
SQM 14
P.Selvapriyavadhana,Asst.Prof,ACT
extent that it facilitates the establishment ofverification criteria and supports evaluationof its performance.
• Understandability (Maintainability character-istics): Code possesses the characteristic un-derstandability to the extent that its purposeis clear to the inspector.
• Flexibility (Maintainability characteristics, Mod-ifiability): Code possesses the characteristicmodifiability to the extent that it facilitatesthe incorporation of changes, once the natureof the desired change has been determined.
The lowest level structure of the characteristicshierarchy in Boehms model is the primitive char-acteristics metrics hierarchy. The primitive char-acteristics provide the foundation for defining qual-ities metrics which was one of the goals whenBoehm constructed his quality model. Conse-quently, the model presents one ore more met-rics2 supposedly measuring a given primitive char-acteristic.
SQM 15
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 3: Boehm’s Software Quality Characteristics Tree
SQM 16
P.Selvapriyavadhana,Asst.Prof,ACT
4 QUALITY CRITERIA and INTERRELATION
The individual measure of software quality pro-vided do not provide an over all measure of soft-ware quality. The individual measures must becombined. The individual measures of qualitymay conflict with each other.Some of these relationships are described below;
• Integrity vs. efficiency (inverse) the controlof access to data or software requires addi-tional code and processing leading to a longerruntime and additional storage requirement.
• Usability vs. efficiency (inverse) Improvementsin the human / computer interface may signif-icantly increase the amount of code and powerrequired.
• Maintainability and testability vs. efficiency(inverse) Optimized and compact code is noteasy to maintain.
• Portability vs. efficiency (inverse) the useof optimized software or system utilities willlead to decrease in probability.
• Flexibility, reusability and interoperability vs.efficiency (inverse) the generally required fora flexible system, the use if interface routinesand the modularity desirable for reusabilitywill all decrease efficiency.
• Flexibility and reusability vs. integrity (in-verse) the general flexible data structures re-quired for flexible and reusable software in-crease the security and protection problem.
• Interoperability vs. integrity (inverse) Cou-pled system allow more avenues of access tomore and different users.
SQM 17
P.Selvapriyavadhana,Asst.Prof,ACT
• Reusability vs. reliability (inverse) reusablesoftware is required to be general: maintain-ing accuracy and error tolerance across allcases is difficult.
• Maintainability vs. flexibility (direct) main-tainable code arises from code that is wellstructured.
• Maintainability vs. reusability (direct) wellstructured easily maintainable code is easierto reuse in other programs either as a libraryof routines or as code placed directly withinanother program.
• Portability vs. reusability (direct) portablecode is likely to be free of environment-specificfeatures.
• Correctness vs. efficiency (neutral) the cor-rectness of code, i.e. its conformance to spec-ification does not influence its efficiency.
SQM 18
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 4: Quality criteria inter-relation
SQM 19
P.Selvapriyavadhana,Asst.Prof,ACT
Process Improvement Strategy
Study an existing process to understand its activ-ities.Produce an abstract model of the process.Analyse the model to discover process problems.This involves discussing process activities withstakeholders and discovering problems and pos-sible process changes.
5 Quality Improvement Model
• Set the Goal
• Constitute the Software Engineering ProcessGroup (SEPG)
• Flow Chart the current Processes
• Organize the process champions
• Simplify the process and make changes
• Get feedback from practitioner
• Remove bottlenecks and weak processes afterreview
• Baseline the process
• Train the practitioners
SQM 20
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 5: Improvement Model
SQM 21
P.Selvapriyavadhana,Asst.Prof,ACT
Quality Improvement
Process quality and product quality are closelyrelated and process improvement benefits arisebecause the quality of the product depends onits development process.A good process is usually required to produce agood product.For manufactured goods, process is the principalquality determinant.
Understanding existing processes and introducing process changes to
improve product quality, reduce costs or accelerate schedules.Most
process improvement work so far has focused on defect reduction.
This reflects the increasing attention paid by industry to quality.
However, other process attributes can also be the focus of improve-
ment.
For large projects with average capabilities, thedevelopment process determines product quality.For small projects, the capabilities of the devel-opers is the main determinant. The developmenttechnology is particularly significant for small projects.
Quality Improvement
Both product and process assessment are requiredfor quality improvement.
• Performing Testing activities, conducting au-dits and SQA assessments help to improve theprocess throughout the organization
• Review of all the processes and documentsare done rigorously by the audit team so that
SQM 22
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 6: product quality factors
margin of error is very less.
• Project Leaders were helped to close the NonCompliance of quality standards and improvethe process compliance.
Quality products and services result from qualitysystems, processes and methods.Quality is all-consuming focus of the organiza-tion.
SQM 23
P.Selvapriyavadhana,Asst.Prof,ACT
6 Process Maturity Levels
As organizations move up the maturity ladder,they are more likely to produce higher qualityproducts with more predictable costs and cycletimes. The higher levels are more likely to cor-relate with higher productivity and shorter cycletimes as well.
The idea of model based software improvementis very simple. First pick the applicable ProcessAreas. Next perform an assessment of organiza-tional practices relative to the model. The or-ganization practices do not have to conform ex-actly to the representative practices included inthe model. They just have to meet the statedgoals of each PA. Based on this comparison, as-sign a maturity level to the organization and pro-duce a list of strengths and weakness relative tothe model.
The output of the assessment is used to priori-tize areas for improvement. The idea is to im-prove deficient practices at the lower maturitylevels first and systematically move up in matu-rity level over time using additional assessmentsto measure progress.
Focusing on the lowest level practices puts a firmfoundation in place before tacking the higher levelprocesses and it give the organization time to in-ternalize the changes. This approach nicely avoidsthe twin problems of putting practices in placebefore required supporting practices are availableand trying to do too much too soon.
SQM 24
P.Selvapriyavadhana,Asst.Prof,ACT
So model based improvement has a lot of veryattractive features. One of the most attractiveones is the level goal itself. The numerical levelgives organizations a metric that that can be eas-ily understood, can used to measure progress,and can used to benchmark against other organi-zations.
SEI has defined a formal appraisal methodologyand provided a lead assessor training and certi-fication program. This means that assessmentresults, particular those obtained using a thirdparty assessor, will be reasonably consistent andcan be used to benchmark against other organiza-tions. In fact SEI maintains a publicly accessibledatabase of assessment results giving the numberof organizations at each level by industry and theaverage time for an organization to improve fromone level to the next.
Process Maturity Levels
• Level 1 - Initial
• Level 2 - Repeatable
• Level 3 - Defined
• Level 4 - Managed
• Level 5 - Optimizing
SQM 25
P.Selvapriyavadhana,Asst.Prof,ACT
Level 1 - Initial
1. Characteristics
• Chaotic planning, performance, and results
• Lost (i.e., forgotten) or misunderstood re-quirements
• Unpredictable cost, schedule, and qualityperformance
2. Needed Actions
• Planning (size and cost estimates, sched-ules)
• Requirements and performance tracking
• Change control
• Management Oversite
• Quality assurance
SQM 26
P.Selvapriyavadhana,Asst.Prof,ACT
Level 2 - Repeatable
1. Characteristics
• Intuitive
• Requirements and performance are tracked
• Cost and quality are highly variable
• Reasonable control of schedules
• Informal and ad hoc process methods andprocedures
- Introduce with great care ( new tools andmethods).- To develop a new kind of project leads tonew problem.- Organization changes can also be disruptive(new manager).
2. Needed Actions
• Develop process standards and definitions
• Establish a process group.
• Establish methods for requirements analy-sis, design, coding, inspection, and testing
Level 3 - Defined
1. Characteristics
• Qualitative(little).
• Requirements are logged, tracked, and closedout
• Reliable costs and schedules
• Improving but still unpredictable qualityperformance
SQM 27
P.Selvapriyavadhana,Asst.Prof,ACT
2. Needed Actions
• Establish process measurements
• Establish quantitative quality goals, plans,measurements, and tracking
Level 4 - Managed
1. Characteristics
• Quantity improvement.
• Reasonable statistical control over productquality.
• Cost of gathering data is the problem.
2. Needed Actions
• Quantitative productivity plans and track-ing
• Automatic gathering of process data , Ac-curacy in manual is poor.
• Economically justified technology invest-ments
Level 5 - Optimizing
1. Characteristics
• Quantitative basis for continued capital in-vestment in process automation and im-provement.
• Data relates directly to product improve-ment.
• Error prevention through inspection thatfind and fixes the bugs.
SQM 28
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 7: Software Process Maturity Levels
• Removal of defects by assessment of projectquality.
2. Needed Actions
• Continued emphasis on process measure-ment and process methods for error pre-vention
SQM 29
P.Selvapriyavadhana,Asst.Prof,ACT
7 Capability Maturity Model
The CMM defines the characteristics of a ma-ture, capable process in a way that can be mea-sured and compared to processes at other orga-nizations.
• The CMM consists of areas of improvement,goals that must be met for each area, and spe-cific practices to be implemented.
• A software engineering process group withinthe organization identifies problems and in-efficiencies and defines practices to addressthem.
• Independent assessors verify that an organi-zation is in compliance with CMM practices.
Six Sigma
Six Sigma is an approach to improving quality in manufacturing and
business processes.The term ”six sigma process” comes from the no-
tion that if one has six standard deviations between the mean of a
process and the nearest specification limit, there will be practically
no items that fail to meet the specifications. This is the basis of the
Process Capability Study, often used by quality professionals. The
term ”Six Sigma” has its roots in this tool, rather than in simple
process standard deviation, which is also measured in sigmas.
The Greek letter sigma refers to standard deviationSix Sigma
means six standard deviations from the mean.
DMAIC is a five-phase approach to Six Sigma improvement
SQM 30
P.Selvapriyavadhana,Asst.Prof,ACT
Define opportunities, Measure performance, Analyze opportunity,
Improve performance, Control performance
The fundamental objective of the Six Sigma method-ology is the implementation of a measurement-based strategy that focuses on process improve-ment and variation reduction through the appli-cation of Six Sigma improvement projects. Thisis accomplished through the use of two Six Sigmasub-methodologies: DMAIC and DMADV.
The Six Sigma DMAIC process (define, measure,analyze, improve, control) is an improvement sys-tem for existing processes falling below specifica-tion and looking for incremental improvement.
The Six Sigma DMADV process (define, mea-sure, analyze, design, verify) is an improvementsystem used to develop new processes or prod-ucts at Six Sigma quality levels. It can also beemployed if a current process requires more thanjust incremental improvement.
SQM 31
P.Selvapriyavadhana,Asst.Prof,ACT
There are five maturity levels in the CMM model.
• Commitment to perform
• Ability to perform
• Activities performed
• Measurement and analysis
• Verifying implementation
SQM 32
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 8: SW-CMM maturity levels
SQM 33
P.Selvapriyavadhana,Asst.Prof,ACT
In the CMM model, the maturity level of an or-ganization tells us to what extent an organizationcan produce low cost, high quality software. Hav-ing known the current maturity level, an organi-zation can work to reach the next higher level.
SQM 34
P.Selvapriyavadhana,Asst.Prof,ACT
Figure 9: The CMM structure
SQM 35