Syllabus

SOFTWARE QUALITY MANAGEMENT 18MCA4053E

UNIT IFUNDAMENTALSOFSOFTWAREQUALITY 9Software quality− Hierarchical models of Boehm and McCall−Quality measurement −Metrics measurement and analysis−Gilb’s approach−GQM Model.

UNITIISOFTWARE QUALITY ASSURANCE 9Quality tasks− SQA plan−Teams−Characteristics−Implementation−Documentation−Reviews and audits.

UNITIIIQUALITY CONTROL AND RELIABILITY 9Tools for quality−Ishikawa’s basic tools−CASE tools−Defect prevention andRemoval –Reliability models−Rayleigh model−Reliability growth models for quality assessment.

UNITIVQUALITYMANAGEMENTSYSTEM 9Elements of QMS−Rayleigh model framework−Reliability growth models for QMS−Complexity metrics and models−Customer satisfaction analysis.

UNITV QUALITY STANDARDS 9Need for standards−ISO9000 Series−ISO9000-3 for software development−CMM and CMMI− Six sigma concepts.

Total:45TEXTBOOKS1.AllanC.Gillies,“SoftwareQuality:TheoryandManagement”,ThomsonLearning,2003.2.StephenH.Kan,“MetricsandModelsinSoftwareQualityEngineering”, Pearson Education(Singapore)Pvt.Ltd.,2002.REFERENCES1.NormanE.FentonandShariLawrencePfleeger,“SoftwareMetrics”, Thomson,2003.2.MordechaiBen,MenachemandGarryS.Marliss,“SoftwareQuality” ThomsonAsiaPvt.Ltd.,2003.3. ISO9000-3,“NotesfortheApplicationofthe ISO9001Standardtosoftwaredevelopment”.4.KamnaMalikandPraveenChoudry,“SoftwareQuality: APractitionerApproach”,PHI,2000

1

UNIT1 FUNDAMENTALS OF SOFTWARE QUALITYSoftware Quality - Hierarchical models of Boehm and McCall – measurement – Metrics measurement – Metrics measurement and analysis – Gilb’s approach – GQM Model

Content: Views of Quality Hierarchical Modeling Boehm and McCall’s Models Quality Criteria Inter-relation Measuring Quality Quality Metrics Overall Measures of Quality GQM

2

Quality:Ability of the product/service to fulfill its functionHard to defineImpossible to measureEasy to recognize in its absenceTransparent when present

Definition of Quality:

Ch aracte ristics of Qu ality:

Quality is not absoluteQuality is multidimensionalQuality is subject to constraintsQuality is about acceptable compromisesQuality criteria are not independent, but interact with each other causing

conflicts.

S o f t w a r e Qu ality: Kitchenham(1989b) refers to software quality “fitness for needs” and claims qualityInvolves matching expectations.

Two features of a piece of quality software: Conformance to its specification Fitness for its intended purpose.

The Department of Defense(DOD,1985) in the USA defines software quality as

3

“the degree to which the attributes of the software enable it to perform its intended end use”.

Software product quality Product quality conformance to requirements or program specification;

related to Reliability , Scalability Correctness Completeness absence of bugs Fault-tolerance Extensibility Maintainability Documentation

Software was particularly problematical for the following reasons:

Software has no physical existenceThe lack of knowledge of client needs at the startThe change of client needs overtimeThe rapid rate of change on both hardware and software

The high expectations of customers, particularly with respect to adaptability.Within the software quality area, the need to provide as solution that matches user needs is oft considered as “design quality”, whilst ensuring a match to the specification is considered as “manufacturing quality”.

Software Quality FactorsA software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program.

Understandability Completeness Maintainability Conciseness Portability Consistency Testability Usability Reliability Structuredness Efficiency

4

Security

View s of Qu ality:Quality is a multidimensional construct. It may therefore be considered 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.

It has been classified according to a number of ‘views’ or perspective. These views are often diverse and may conflict with each other. Each view comes from a particular context.The views are generally presented in adversarial pairs such as users versus designers.The software project has the following roles

Project manager Business analyst Implementation programmer Quality auditor End user Line manager Project sponsor

5

In an attempt to classify different and conflicting views of quality, Garvin(1984) has suggested five different 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

6

3.The user-based view· Fitness for purpose·Very hard to quantify

4.The manufacturing view·Measures quality in terms of conformance·Zero defects

5.The value-based view·Provides the data with what the customer requires at a price.

Quality is determined by people because· It is people and human organizations who have problems to be solved by computer software·It is people who define the problems and specify the solutions·It is still currently people who implement designs and produce code.·It is people who test code

H IE RARCH ICAL MO DE L O F Q UAL IT Y:To compare quality in different situations, both qualitatively and quantitatively, it is necessary to establish a mode of quality.Many model suggested for quality. Most are hierarchical in nature.A quantitative assessment is generally made, along with a more quantified assessment.Two principal models of this type,One by Boehm(1978) and one by McCallin 1977. A hierarchical model of software quality is based upon a set of quality criteria, each of which has a set of measures or metrics 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 combined into a meaningful overall

measure of Quality?

THE GE MODEL(MCCALL, 1977 AND1980)/(McCallModel)

This model was first proposed by McCall in 1977.

It was later revised as the MQ model, and it is aimed by system developers to be used during the development process.

7

In early attempt to bridge the gap between users and developers, the criteria were chosen in an attempt to reflect user’s views as well as developer’s priorities.

The criteria appear to be technically oriented, but they are described by a series of questions which define them in terms to non-specialist managers.

Th e th ree ar eas add ressed b y McCall’s mod el(1977) :Product operation: requires that it can be learnt easily, operated efficiently And it results are those required by the users.Product revision: it is concerned with error correction andAdaptation Of the system and it is most costly part of software development.Product transition: it is an important application and it isDistributed processing and the rapid rate of change in hardware is Likely to increase.

M c Call’s c r it er ia of qu ality d e f i n e d Efficiency is concerned with the use of resources e.g.Process or time, storage. It falls into two categories:Execution efficiency and storage efficiency.Usability Is the ease of use of the software.Integrity is the protection of the program from unauthorized access. Correctness is the extent to which a program fulfils its specification. Reliability is its ability not to fail.Maintainability is the effort required to locate and fix a fault in the program within its operating environment.Flexibility is the ease of making changes required by changes in the operating environment.Testability is the ease of testing the programs, to ensure that it is error-free and meet its specification.Portability is the effort required to transfer a program from one environment to another.

8

Reusability is the ease of reusing software in a different context.Interoperability is the effort required to couple the system to another system.

9

Th e B oeh m mod el(197 8)It is to provide a set of well-defined, well-differentiated characteristics of software quality.It is hierarchical in nature but the hierarchy is extended, so that quality criteria are subdivided.According to the uses made of the system and they are classed into ‘general’ or ‘as is’ and the utilities 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 into primitive characteristics which are amenable to measurement.This model is based upon a much larger set of criteria than McCall’s model, but retains the same emphasis on technical criteria.

Th e t w o m o d e ls s h a r e a nu m b e r of c o m m on c h a r a c t e r isti c sa r e , The quality criteria are supposedly based upon the

user’s view. The models focus on the parts that designer can more

readily analyze. Hierarchical models cannot be tested or validated. It

cannot be shown that the metrics accurately reflect the criteria.

The measurement of overall quality is achieved by a weighted summation of the characteristics.

Boehm talks of modifiability where McCall distinguishes expandability from adaptability and documentation, understandability and clarity.

10

HO WTH EQ UAL IT YCRITE RIAINTE RREL AT EThe individual measure of software quality provided do not provide an overall measure of software quality.The individual measures must be combined.The individual measures of quality may conflict with each other.Some of these relationships are described below;Integrity vs. efficiency (inverse) the control of access to data or software requires additional code and processing leading to a long err in time and additional storage requirement.Usability vs. efficiency (inverse) Improvements in the human/computer interface may significantly increase the amount of code and power required.Maintainability and testability vs. efficiency(inverse) Optimized and compact code is not easy to maintain.

11

Portability vs. efficiency(inverse) the use of optimized software or system utilities will lead to decrease in probability.Flexibility and reusability vs. integrity (inverse) the general flexible data structures required for flexible and reusable software increase the security and protection problem.Interoperability vs. integrity (inverse) Coupled system allow more avenues of access to more and different users.Reusability vs. reliability (inverse) reusable software is required to be general:Maintaining accuracy and error tolerance across all cases is difficult.Maintainability vs. flexibility (direct) maintainable code arises from code that is well structured. Maintainability vs. reusability (direct) well structured easily maintainable code is easier to reuse in other programs either as a library of routines or as code placed directly within another program.Portability vs .reusability (direct) portable code is likely to be free of environment- specific features.Correctness vs. efficiency (neutral)the correctness of code, i.e. its conformance to specification does not influence its efficiency.

ME AS URING S O FT W ARE Q UAL IT YME AS URING Q U AL IT YQuality measurement, where it is considered at all, is usually expressed in terms of metrics.Software metric is a measurable property which is an indicator of one or more of the quality criteria that we are seeking to measure. As such, there are a number of conditions that a quality metric must meet. It must:

1. Be clearly linked to the quality criterion that it seeks to measure2. Be sensitive to the different degrees of the criterion3. Provide objective determination of the criterion that can be mapped onto a

suitable scale.Metrics are not same as direct measures.

Measurement techniques applied to software are more akin to the social sciences, where properties are similarly complex and ambiguous.A typically measurable property on which a metric maybe based is structuredness.Structuredness as it simplest may be calculated in terms of the average length of code modules within the programs.

12

SOFTWARE METRICSMetrics are classified into two types according to whether they are predictive or descriptive.A predictive metric is used to make predictions about the software later in the lifecycle. Structuredness is used to predict the maintainability of the software product in use.A descriptive metric describes the state of the software at the time of measurement.Different authors have taken different approaches to metrics. Structuredness is measured by questions such as:

Have the rules for transfer of control between modules been followed?(y/n)Are modules limited in size?(y/n)Do all modules have only one exit point?(y/n)Do all modules have only one entry point?(y/n)A well-structured program will produce positive answers to such

questions. McCall’sapproach is more quantities, using scores derived from equations such as

Where: n01=no of modules containing one or zero exit points only ntot=total number of modulesGenerally, in this approach, scores are normalized to a range between 0 and 1, to allow for easier combination and comparison.This appears attractive, to give unjustified credibility to the results obtained. To validate this relationship and determine whether it is a linear relationship or more complex in nature.It is also possible to validate whether the dependence of maintainability structuredness in identical to that of adaptability or reusability.

Wh at mak es a good me tric?Seven criteria for a good metric, afterWatts(1987)

Objectivity the results should be free from subjective influences. It must not matter who the measurer is.

13

Reliability the results should be precise and repeatable. Validity the metric must measure the correct characteristic. Standardization the metric must be unambiguous and allow for comparison. Comparability the metric must be comparable with other measures of the

same Criterion. Economy the simpler and therefore, the cheaper the measure is to use, the

Better. Usefulness the measure must address a need, not simply measure a property

for its own sake.A further important feature is consistency.Automation is also desirable. Metrics cited in the literature:Metrics available for each criterion (afterWatts,1987)\

The metrics cited depends to a very large extent upon just seven distinct measurable properties: readability, error prediction, error detection, complexity, and mean time to failure(MTTF), modularity, testability.1.Readability as a measure of usability maybe applied to documentation in order to assess how such documentation may assist in the usability of a piece of software.2. Error prediction as a measure of correctness this measure is depends upon the stable software development environment.3. Error detection as measure of correctness4.Mean time to failure (MTTF) as a measure of reliability

14

5.Complexity as a measure of reliability the assumption under pinning these measures is that as complexity increases, so reliability decrease.6. Complexity as a measure of maintainability is also indicative of maintainability.7. Readability of code as a measure of maintainability has also been suggested as a measure of maintainability.

8. Modularity as a measure of maintainability increased modularity is generally assumed to increase maintainability. Four measures have been suggested. Yau and Collofello (1979) measured “ stability” as the number of modules affected by program modification. Kentger (1981) defined a four-level hierarchy of module types:

Control modules.Problem-oriented modules.Management modules for abstract data.Realization modules for abstract data.

9. Testability as a measure of maintainability the ease and effectiveness of testing will have an impact upon the maintainability of a product. An overall measu re of qu alityMuch of the work in this area has been concerned with simple reduction of a set of scores to a single ‘figure-of-merit’.Five such methods are detailed by Watts(1987)as part of the MQ approach.1. Simple scoring: In this method, each criterion is allocated a score. The overall quality is given by the mean of the individuals cores.2. Weighted scoring: This scheme allows the user to weight each criterion according to how important they consider them to be. Each criterion is evaluated to produce a score between 0 and 1 .Each score is weighted before summation and the resulting figure reflects the relative importance if the different factors.3. Phased weighting factor method: This is an extension of weighted scoring. A weighting is assigned to a group characteristics before each individual weighting is considered.

15

The phased weighting factor methodProduct operation weighted mean = 0.660Product transition weighted mean=0.633Overall measure by PWF method= ((2/3)x0.660) +((1/3)x0.633) =0.654. The Kepner-Tregoe method(1981): The criteria are divided into ‘essential ’and‘ desirable’. A minimum value is specified for each essential criterion and any software failing to reach these scores is designated unsuitable.‘Suitable’ software is then judged by use of the weighting factor method.5. The Cologne combination method (Schmitz,1975): This method is designed with comparative evaluation in mind. Using the chosen criteria, each product is ranked in order.

POLARITY PROFILING:In this scheme, quality is represented by series of ranges from -3to+3.The required quality maybe represented and compared to the actual quality achieved.It is a common problem amongst software developers that they focus upon particular aspects of quality.When a user complains of poor quality, they tend to improve the product further in these areas.Often the product has already exceeded the user’s expectations in these areas, and a further improvement does not improve their overall view of the quality of the product.

16

This is effort wasted.Worse, the user’s needs still have not been met in other critical areas, leading to tensions between the developers and users.Two different outcomes result.In the first case, usability is improved. Unfortunately, reliability and efficiency are still not up to the required standard, and usability was already considered satisfactory.In the second case, improvements in reliability and efficiency are traded for a reduction in adaptability and maintainability, perhaps by ‘tweaking’ the code.The consequence is that all criteria are no where the required level, resulting in an overall perception of quality and satisfied users.The purpose of standardStandards are generally defined in terms of a model of a best practice against which all others are compared. It is used to build better products Also used to ensure whether the products are conformance to a standard

GILB’S APPROACHGilb’s ApproachIt is an iterative approach aiming to converge towards clear & measurablemultidimensional objectivesThis approach makes use the concept of McCall & Boehm modelsFor each stage, a partial product can be viewed with user where a product will beevaluated to identify whether it meets the needs of user. If it does not satisfy errors has tobe identified & cleared out during the next iteration until a product gets satisfied by theuser.5 problem areas highlighted

Simple fact that the method is different Need of training & re-training and associated costs Need of effective management Need to measure progress towards the ultimate goal Picking up errors

With reference to Gilb’s approach, product quality can be measured in terms of “QualityTemplate”It models quality in terms of Quality attributes & Resource attributes. This is becausequality of a product can be constrained by the available resources

17

Resource AttributesTime Resource 2 types

Calendar time to delivery Time taken by the system to carry out the task

People ResourceMeasured in terms of “Man-years”

18

But the availability of People for the particular development is criticalEx: cannot utilize PASCAL programmers for C programmingMoney ResourcesConcerned with both development & maintenance costsIn general, 80% of cost would be spent to maintenance for quality improvementTool ResourcesIt comprises all physical resourcesFor continuous improvements, these resources will be considered as constraints to aproduct

THE GOAL QUESTION METRIC APPROACHThe Goal Question Metric (GQM) approach is based upon the assumption that for an organization to measure in a purposeful way it must first specify the goals for itself and its projects, then it must trace those goals to the data that are intended to define those goals operationally, and finally provide a framework for interpreting the data with respect to the stated goals. Thus it is important to make clear, at least in general terms, what informational needs the organization has, so that these needs for information can be quantified whenever possible, and the quantified information can be analyzed a to whether or not the goals are achieved. The approach was originally defined for evaluating defects for a set of projects in the NASA Goddard Space Flight Center environment.The result of the application of the Goal Question Metric approach application is the specification of a measurement system targeting a particular set of issues and a set of rules for the interpretation of the measurement data. The resulting measurement model has three levels:1. Conceptual level (GOAL): A goal is defined for an object, for a variety of reasons,with respect to various models of quality, from various points of view, relative to aparticular environment. Objects of measurement areProducts: Artifacts, deliverables and documents that are produced duringthe system life cycle; E.g., specifications, designs, programs, test suites.Processes: Software related activities normally associated with time; E.g.,specifying, designing, testing, interviewing.Resources: Items used by processes in order to produce their outputs; E.g., personnel, hardware, software, office space.

2. Operational level (QUESTION): A set of questions is used to characterize the way the assessment/achievement of a specific goal is going to be performed based on some characterizing model. Questions try to characterize the object ofmeasurement (product, process, resource) with respect to a selected quality issueand to determine its quality from the selected viewpoint.

19

3. Quantitative level (METRIC): A set of data is associated with every question in order to answer it in a quantitative way. The data can beObjective: If they depend only on the object that is being measured and not on the viewpoint from which they are taken; E.g., number of versions of a document, staff hours spent on a task, size of a program.Subjective: If they depend on both the object that is being measured and the viewpoint from which they are taken; E.g., readability of a text, level of user satisfaction.

20

The complete Goal Question Metric model is as follows:

THE GOAL QUESTION METRIC PROCESSA GQM model is developed by identifying a set of quality and/or productivity goals, at corporate, division or project level; e.g., customer satisfaction, on-time delivery, improved performance. From those goals and based upon models of the object of measurement, we derive questions that define those goals as completely as possible. For example, if it is to characterize a software system (e.g., an electronic mail package, a word processor) with respect to a certain set of quality issues (e.g., portability across architectures), then a quality model of the product

21

must be chosen that deals with those issues (e.g., list of functional features that can be implemented in different architectures). The next step consists in specifying the measures that need to be collected in order to answer those questions, and to track the conformance of products and processes to the goals. After the measures have been specified, we need to develop the data collection mechanisms, including validation and analysis mechanisms.

22

CONCLUSIONIn summary, the Goal Question Metric approach is a mechanism for defining and interpreting operational and measurable software. It can be used in isolation or, better, within the context of a more general approach to software quality improvement. Figure below outlines the basic roles and flows of information for this model.

23

24

Questions for Assignment 1

1. Discuss quality and its characteristics. Give the definitions of quality2. Define software quality3. Explain GARVIN’S views of quality4. What is quality as per ISO?5. Discuss the reasons for software quality becomes problematical6. Give the schematic hierarchical view of software quality and list the

hierarchical models of Quality7. Discuss the areas addressed by McCall’s model with a neat diagram8. Enlist the criteria of quality defined by McCall’s model?9. Discuss how the quality criteria interrelate?10.Explain Boehm’s hierarchical model showing the different levels of hierarchy11.What are software metrics and list the conditions that a quality metric must

meet12.What are the types of software metrics?13.Discuss the seven criteria for good metrics14.Define MTTF as a measure of reliability15.What re the problems with metrics?16.Explain how the overall software quality can be measured and the problems

associated17.with them18.Explain Gilb’s approach to quality discussing the attributes with its sub

attribute19.Explain in detail the GQM model

25