Unit 1

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


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


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


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


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


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


• 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


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


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


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


• 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


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


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


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


Figure 3: Boehm’s Software Quality Characteristics Tree

SQM 16


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


• 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


Figure 4: Quality criteria inter-relation

SQM 19


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


Figure 5: Improvement Model

SQM 21


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


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


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


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


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


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


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


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


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


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


There are five maturity levels in the CMM model.

• Commitment to perform

• Ability to perform

• Activities performed

• Measurement and analysis

• Verifying implementation

SQM 32


Figure 8: SW-CMM maturity levels

SQM 33


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


Figure 9: The CMM structure

SQM 35

Documents

Unit 1