Vous êtes sur la page 1sur 51

Unit 2

July 27, 2011

DEVELOPMENTS IN MEASURING QUALITY

Quality goals: It is largely accepted that quality is the most important objective in software development. A software product of poor quality does not provide any benet for its producer, but requires continuous correction, which entails a wasteful use of resources. GRCM (goal-rule-checklist-metric) model to provide the structure for organizing quality information. The GRCM model has three links with the SQM synthesis, the goals correspond to factors (e.g. usability) and the rules to criteria (e.g. ease of use), and the metrics support quality measurement in both models. The goals are broken down into rules and further into checklists. The aim of the rules is to guide software engineers in software design, while checklists are generated from specic rules and used as guidelines by inspectors, to help of them check that these rules have been followed.

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 1: The quality-intensive approach based on the GRCM model

We rst prioritize the most important of the 11 alternative goals (presented in the GRCM model) for the user interface of the beer pump. We may choose to place our focus on usability aspects, e.g. striving for understandable instructions, or we can emphasize reliability, e.g. ensuring that the beer ows into the glass, for example. In addition we choose the portability goal, because this kind of system could have potential clients worldwide.

Reasons for the choice of quality goals A goal (or objective) is a statement of the desired result to be achieved within a specied period which is aimed-at target. These goals then become basis for detailed planning of activities.
SQM 2

P.Selvapriyavadhana,Asst.Prof,ACT

Tactical goals are short range (up to 1 year), whereas strategic goals are long range (say, 5 years). Examples of corporate quality goals.For a health product company, the quality goals over the next year could be: The average leakage rate for . product shall be reduced to Note that quality goal statements include quantied data. Typically Pareto analysis is used to develop the quality goals . Pareto analysis is a statistical technique in decision making that is used for selection of a limited number of tasks that produce signicant overall eect. It uses the Pareto principle the idea that by doing 20% of work, 80% of the advantage of doing the entire job can be generated. Or in terms of quality improvement, a large majority of problems (80% ) are produced by a few key causes (20% ). A quality measure is in eect a rule (or the result of a rule) that assigns numeric values to a specic quality indicator. The essential distinction between quality indicators and quality measures is that quality measures take on numeric values, while quality indicators refer only to unquantied attributes of care related to quality. Measure - quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. E.g., Number of errors

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 2: Reasons for the choice of quality goals

Principles Of Measurement

The objectives of measurement should be established before data collection begins. 1. Formulation - The derivation of software measures and metrics appropriate for the representation of the software that is being considered. 2. Collect information - The mechanism used to accumulate data required to derive the formulated metrics. 3. Analysis information - The computation of metrics and the application of mathematical tools. 4. Interpretation -The evaluation of metrics results in an eort to gain insight into the quality of the representation.

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 3: Annual quality goals

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 4: Approaches to Measuring Quality

5. Feedback - Recommendations derived from the interpretation of product metrics transmitted to the software team. Types of Measures Direct Measures (internal attributes) Cost, eort, LOC, speed, memory Indirect (external attributes) Functionality, quality, complexity, eciency, reliability, maintainability

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Why Measure Software? Determine the quality of the current product or process Predict qualities of a product/process Improve quality of a product/process Measures of Software Quality Correctness degree to which a program operates according to specication Defects/KLOC Defect is a veried lack of conformance to requirements Failures/hours of operation Maintainability degree to which a program is open to change Mean time to change Change request to new version (Analyze, design etc) Cost to correct Integrity - degree to which a program is resistant to outside attack Fault tolerance, security and threats Usability easiness to use Training time, skill level necessary to use, Increase in productivity, subjective questionnaire or controlled experiment

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Metric

Quantitative measure of degree to which a system, component or process possesses a given attribute. A handle or guess about a given attribute. E.g., Number of errors found per person hours expended. Motivation for Metrics Estimate the cost and schedule of future projects. Evaluate the productivity impacts of new tools and techniques. Establish productivity trends over time. Improve software quality. Forecast future stang needs. Anticipate and reduce future maintenance needs. Example Metrics Defect rates Error rates

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Product Quality Metrics The denition of software quality consists of two levels: intrinsic product quality and customer satisfaction. The metrics we discuss here cover both levels: Mean time to failure Defect density Customer problems Customer satisfaction. Intrinsic product quality is usually measured by the number of bugs (functional defects) in the software or by how long the software can run before encountering a crash. In operational denitions, the two metrics are defect density (rate) and mean time to failure (MTTF). The MTTF metric is most often used with safetycritical systems such as the airline trac control systems, avionics, and weapons. For instance, the U.S. government mandates that its air trac control system cannot be unavailable for more than three seconds per year. In civilian airliners, the probability of certain catastrophic failures must be no worse than 10-9 per hour (Littlewood and Strigini, 1992). The defect density metric, in contrast, is used in many commercial software systems. Customer Satisfaction Metrics Customer satisfaction is often measured by customer survey data via the ve-point scale: Very satised Satised Neutral Dissatised
SQM 9

P.Selvapriyavadhana,Asst.Prof,ACT

Very dissatised. Satisfaction with the overall quality of the product and its specic dimensions is usually obtained through various methods of customer surveys. For example, the specic parameters of customer satisfaction in software monitored by IBM include the CFUPRIMDSO categories (capability, functionality, usability, performance, reliability, installability, maintainability, documentation/information, service, and overall); for Hewlett-Packard they are FURPS (functionality, usability, reliability, performance, and service). Based on the ve-point-scale data, several metrics with slight variations can be constructed and used, depending on the purpose of analysis. For example: 1. Percent of completely satised customers 2. Percent of satised customers (satised and completely satised) 3. Percent of dissatised customers (dissatised and completely dissatised) 4. Percent of nonsatised (neutral, dissatised, and completely dissatised)

SQM

10

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 5: Scopes of Three Quality Metrics

SQM

11

P.Selvapriyavadhana,Asst.Prof,ACT

Usually the second metric, percent satisfaction, is used. In practices that focus on reducing the percentage of nonsatisfaction, much like reducing product defects, metric (4) is used. 4 Quality Function Deployment

Denition Quality Function Deployment, QFD, is a quality technique which evaluates the ideas of key stakeholders to produce a product which better addresses the customers needs. Integrating customer requirements into product design Quality: Meeting the specications Function: Function that forms quality Deployment: Step-by-step deployment of that function

A structured method for translating the Voice of the Customer into design requirements A method to keep the organization focused on what is important to the customer A standard approach to present, document, track and create consensus on customer needs A technique to balance the voice of the executives.

QFD is the guiding design process for rapid, low cost development of products that delight the customers. This versatile tool can be tailored to t the needs of a very diverse collection of projects. A common barrier to using QFD is the perceived complexity and subsequently large time commitment required for implementation. However, project leadership and good facilitation can clarify the mechanics of QFD and
SQM 12

P.Selvapriyavadhana,Asst.Prof,ACT

signicantly shorten the time required to complete the matrices of QFD. QFD should not be: A method to justify your own agenda A method to build cool looking charts to impress the boss A way to get out of the oce and hang around with your buddies An exercise in futility, confusion, and aggravation A way to produce reports that are shelved

Why use QFD? Poor understanding of customer needs. Failure to strategically prioritize eorts. Willingness to take on unmanageable risks. Tendency toward unbuildable designs. Overreliance on formal specications. Testing scenarios that fail to nd key defects. Benets of QFD 1. Fewer, less expensive changes. 2. Less time, less cost of development. 3. Fewer start-up problems. 4. Lower warranty costs. 5. Delighted customers.
SQM 13

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 6: QFD

SQM

14

P.Selvapriyavadhana,Asst.Prof,ACT

Characteristics of QFD The 4 Main Phases to QFD 1.Product Planning including the House of Quality (Requirements Engineering Life Cycle) 2.Product Design (Design Life Cycle) 3.Process Planning -Design (Implementation Life Cycle) 4.Process Control - Planning Production(Testing Life Cycle)

Phases of QFD Phase 1-Led by the marketing department, Phase 1, or product planning, is also called The House of Quality. Many organizations only get through this phase of a QFD process. Phase 1 documents customer requirements, warranty data, competitive opportunities, product measurements, competing product measures, and the technical ability of the organization to meet each customer requirement. Getting good data from the customer in Phase 1 is critical to the success of the entire QFD process. Phase 2-Phase 2 is led by the engineering department. Product design requires creativity and innovative team ideas. Product concepts are created during this phase and part specications are documented. Parts that are determined to be most important to meeting customer needs are then deployed into process planning, or Phase 3. Phase 3-Process planning comes next and is led by manufacturing engineering. During process planning, manufacturing processes are owcharted and process parameters (or target values) are documented. Phase 4-And nally, in the production planning, perforSQM 15

P.Selvapriyavadhana,Asst.Prof,ACT

mance indicators are created to monitor the production process, maintenance schedules, and skills training for operators. Also, in this phase decisions are made as to which process poses the most risk and controls are put in place to prevent failures. The quality assurance department in concert with manufacturing leads Phase 4. QFD is a systematic means of ensuring that customer requirements are accurately translated into relevant technical descriptors throughout each stage of product development. Meeting or exceeding customer demands means more than just maintaining or improving product performance. It means building products that delight customers and fulll their unarticulated desires.

Advantages of QFD 1. Customer / User involvement 2. Focus on customer needs 3. Team builder 4. Improve product or service quality 5. Shorter development cycles 6. Lower costs and greater productivity

SQM

16

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 7: QFD Planning Process

SQM

17

P.Selvapriyavadhana,Asst.Prof,ACT

THE GOAL QUESTION METRIC

The Goal Question Metric (GQM) approach is based upon the assumption that for an organization to measure in a purposeful way it must rst specify the goals for itself and its projects, then it must trace those goals to the data that are intended to dene those goals operationally, and nally 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 quantied whenever possible, and the quantied information can be analyzed a to whether or not the goals are achieved. The result of the application of the Goal Question Metric approach application is the specication 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 dened for an object, for a variety of reasons, with respect to various models of quality, from various points of view, relative to a particular environment. Objects of measurement are Products: Artifacts, deliverables and documents that are produced during the system life cycle; E.g., specications, 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, oce space.
SQM 18

P.Selvapriyavadhana,Asst.Prof,ACT

2. Operational level (QUESTION): A set of questions is used to characterize the way the assessment/achievement of a specic goal is going to be performed based on some characterizing model. Questions try to characterize the object of measurement (product, process, resource) with respect to a selected quality issue and to determine its quality from the selected viewpoint. 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 be Objective: 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, sta 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.

SQM

19

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 8: GQM Hierarchical structure

SQM

20

P.Selvapriyavadhana,Asst.Prof,ACT

A GQM model is a hierarchical structure starting with a goal (specifying purpose of measurement, object to be measured, issue to be measured, and viewpoint from which the measure is taken). The goal is rened into several questions, such as the one in the example, that usually break down the issue into its major components. Each question is then rened into metrics, some of them objective such as the one in the example, some of them subjective. The same metric can be used in order to answer dierent questions under the same goal. Several GQM models can also have questions and metrics in common, making sure that, when the measure is actually taken, the dierent viewpoints are taken into account correctly (i.e., the metric might have dierent values when taken from dierent viewpoints).

THE GOAL QUESTION METRIC PROCESS A 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 dene 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 must be chosen that deals with those issues (e.g., list of functional features that can be implemented in dierent 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 specied, we need to develop the data collection mechanisms, including validation and analysis mechanisms. The process of setting goals is critical by GQM approach and it is supported by specic methodological steps.
SQM 21

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 9: GQM Process

SQM

22

P.Selvapriyavadhana,Asst.Prof,ACT

Quality Characteristics Tree

The quality characteristics are used as the targets for validation (external quality) and verication (internal quality) at the various stages of development. They are rened into sub-characteristics, until the attributes or measurable properties are obtained. In this context, metric or measure is a dened as a measurement method and measurement means to use a metric or measure to assign a value. In order to monitor and control software quality during the development process, the external quality requirements are translated or transferred into the requirements of intermediate products, obtained from development activities. The translation and selection of the attributes is a non-trivial activity, depending on the stakeholder personal experience, unless the organization provides an infrastructure to collect and to analyze previous experience on completed projects.

SQM

23

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

24

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

25

P.Selvapriyavadhana,Asst.Prof,ACT

Quality factors Each quality factors and its corresponding sub-factors are dened as follows: Functionality: A set of attributes that relate to the existence of a set of functions and their specied properties. The functions are those that satisfy stated or implied needs. Suitability: Attribute of software that relates to the presence and appropriateness of a set of functions for specied tasks. Accuracy: Attributes of software that bare on the provision of right or agreed results or eects. Security: Attributes of software that relate to its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data. Interoperability: Attributes of software that relate to its ability to interact with specied systems. Compliance: Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. Reliability: A set of attributes that relate to the capability of software to maintain its level of performance under stated conditions for a stated period of time. Maturity: Attributes of software that relate to the frequency of failure by faults in the software. Fault tolerance: Attributes of software that relate to its ability to maintain a specied level of performance in cases of software faults or of infringement of its specied interface.
SQM 26

P.Selvapriyavadhana,Asst.Prof,ACT

Recoverability: Attributes of software that relate to the capability to re-establish its level of performance and recover the data directly aected in case of a failure and on the time and eort needed for it. Compliance: Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. Usability: A set of attributes that relate to the effort needed for use, and on the individual assessment of such use,by a stated or implied set of users. Understandability: Attributes of software that relate to the users eort for recognizing the logical concept and its applicability. Learnability: Attributes of software that relate to the users eort for learning its application (for example,operation control, input, output). Operability: Attributes of software that relate to the users eort for operation and operation control. Compliance: Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. Eciency: A set of attributes that relate to the relationship between the level of performance of the software and the amount of resources used, under stated conditions. Time behavior: Attributes of software that relate to response and processing times and on throughput rates in performing its function.

SQM

27

P.Selvapriyavadhana,Asst.Prof,ACT

Resource behavior: Attributes of software that relate to the amount of resources used and the duration of such use in performing its function. Compliance: Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. Maintainability: A set of attributes that relate to the eort needed to make specied modications. Analyzability: Attributes of software that relate to the eort needed for diagnosis of deciencies or causes of failures, or for identication of parts to be modied. Changeability: Attributes of software that relate to the eort needed for modication, fault removal or for environmental change. Stability: Attributes of software that relate to the risk of unexpected eect of modications. Testability: Attributes of software that relate to the eort needed for validating the modied software. Portability: A set of attributes that relate to the ability of software to be transferred from one environment to another. Adaptability: Attributes of software that relate to on the opportunity for its adaptation to dierent specied environments without applying other actions or means than those provided for this purpose for the software considered. Installability: Attributes of software that relate to the eort needed to install the software in a specied environment.

SQM

28

P.Selvapriyavadhana,Asst.Prof,ACT

Conformance: Attributes of software that make the software adhere to standards or conventions relating to portability. Replaceability: Attributes of software that relate to the opportunity and eort of using it in the place of specied other software in the environment of that software.

SQM

29

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 10: Characteristics and sub Characteristics of quality

SQM

30

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 11: Quality Characteristics and Guidelines for their Use

SQM

31

P.Selvapriyavadhana,Asst.Prof,ACT

The FURPS Model

The FURPS model originally presented by Robert Grady. FURPS stands for: Functionality which may include feature sets, capabilities and security Usability - which may include human factors, aesthetics, consistency in the user interface, online and contextsensitive help, wizards and agents, user documentation, and training materials Reliability - which may include frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failure (MTBF) Performance - imposes conditions on functional requirements such as speed, eciency, availability, accuracy, throughput, response time, recovery time, and resource usage Supportability - which may include testability, extensibility, adaptability, maintainability, compatibility, congurability, serviceability, installability, localizability (internationalization) The FURPS-categories are of two dierent types: Functional (F) and Non-functional (URPS). These categories can be used as both product requirements as well as in the assessment of product quality. Functional (what behaviors it does) and non-functional (how it does them) Functional requirements describe system behaviors 1. Priority: rank order the features wanted in importance
SQM 32

P.Selvapriyavadhana,Asst.Prof,ACT

2. Criticality: how essential is each requirement to the overall system? 3. Risks: when might a requirement not be satised? What can be done to reduce this risk? Non-functional requirements describe other desired attributes of overall system 1. Product cost (how do measure cost?) 2. Performance (eciency, response time? startup time?) 3. Portability (target platforms?), binary or bytecode compatibility? 4. Availability (how much down time is acceptable?) 5. Security (can it prevent intrusion?) 6. Safety (can it avoid damage to people or environment?) 7. Maintainability (in OO context: extensibility, reusability)

SQM

33

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 12: FURPS classication

SQM

34

P.Selvapriyavadhana,Asst.Prof,ACT

FURPS+ - Functionality All functional requirements Usually represent main product features. E.g. Order Processing requirements. Can also be architecturally signicant. Auditing, Licensing, Localization, Mail, Online help, Printing, Reporting,Security, System management, Workow.

FURPS+ Usability User interface issues such as accessibility, aesthetics and consistency. Reliability Availability, accuracy, recoverability. Performance Throughput, response time, recovery time, startup time. Supportability Testability, adaptability, maintainability, compatibility, congurability,installability, scalability and localizability.

SQM

35

P.Selvapriyavadhana,Asst.Prof,ACT

FURPS+ Design requirement Constrains the design. E.g. a relational database is required. Implementation requirement Constrains the coding or construction. E.g. required standards, platform or implementation language. Interface requirement A requirement to interact with an external item. Physical requirement A physical constraint imposed on the hardware used to house the system; for example, shape, size and weight. 9 GILB S Approach

Glib proposes four qualities attributes: workability, availability, adaptability and usability, accompanied by the resource attributes of time, money, people and tools. Workability Is dened as the raw ability of the system to do work, i.e. transact sign processing. Just as the quality and resource attributes are subdivided, sc each attribute may be further subdivided. Workability may be considered in terms of process capacity, storage capacity and responsiveness, amongst other things.
SQM 36

P.Selvapriyavadhana,Asst.Prof,ACT

Glib denes these terms in the following manner: Process capacity is the ability to process transactions within a given unit of time. storage capacity is the ability of the system to store things such as information. Responsiveness is a measure of the response to a single event.

SQM

37

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 13: Glibs Attributes

SQM

38

P.Selvapriyavadhana,Asst.Prof,ACT

Availability Availability is concerned with the proportion of elapsed time that a system is able to be used. The subattributes highlighted here are reliability, maintainability and integrity. Reliability Reliability is the degree to which the system does what it is supposed to do. Because the purpose of each system is dierent, and the purpose of dierent parts of the system is dierent, the way in which reliability is assessed may also vary. Glib suggests that reliability may be assessed in terms of delity, veracity and viability for both logic ware (code) and data ware (data les), based upon an analysis by Dickson (1972). Maintainability Maintainability refers to the process of fault handling. Some of the principal sub-attributes are: 1. Problem recognition time is the time required to recognize that a fault exists. 2. Administrative delay is the time between recognition of a problem and activity designed to rectify it. 3. Tool collection is the time required to gather all relevant information, e.g. program analysis and documentation. 4. Problem analysis is the time needed to trace the source of the problem.
SQM 39

P.Selvapriyavadhana,Asst.Prof,ACT

5. Correction hypothesis time is the time required to come up with a possible solution. 6. Inspection time is the time taken to evaluate said solution. 7. Active correction is the time to implement a hypothesized correction. 8. Testing is the time taken to adequately test cases to validate the change. 9. Test evaluation is the time needed to evaluate the test results. 10. Recovery is the time required to recover and restore the system.

SQM

40

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 14: Reliability criteria

SQM

41

P.Selvapriyavadhana,Asst.Prof,ACT

Integrity The integrity of a system is a measure of its ability to remain intact whilst under threat. It may be regarded as the ability of in-built security functions to cope with threats. Threats may come from human action (deliberate or otherwise) or machine action, either hardware or software driven. Integrity aects availability. A system with poor integrity is likely to be unavailable for much of the time. Adaptability Adaptability may be considered in terms of improvability, extendibility and portability. Improvability is the time taken to make minor changes to the system where the term system is taken to include items such as documentation. Extendibility is the ease of adding new functionality to a system. Portability is the ease of moving a system from one environment to another. Usability Usability may be considered as the ease of use and eectiveness of use of a system. This may be considered in terms of handling ability, entry requirements, learning requirements and likeability:
SQM 42

P.Selvapriyavadhana,Asst.Prof,ACT

Entry requirements are the basic human abilities such as intelligence level, language prociency or culture that are required to operate the system. Learning requirements are the resources, particularly time, needed to attain a measurable level of performance with the system. Handling ability is a measure of productivity after error time is deducted. Likeability is a measure of how well people like the system. The resource attributes The resource attributes highlighted by Glib include time, people, money and tools: Time resource is of two types: calendar time to delivery and the time taken by the system once developed to carry out a task. People resources may be measured in terms of man-years. However, this is a relatively crude broadbrush approach since people resources are often governed by scarce skills. In such cases, the availability of a particular person becomes a critical attribute. If you require a C programmer, all the COBOL programmers in the world will not help you. Money resources concern both development and maintenance costs. Since budgets are always a constraint and many authors quote gures as high as 80% for the proportion of software cost spent on maintenance, this area is a favorite target for quality improvement programs. Tool resources encompass all physical resources from air- conditioning capacity to debuggers, a much
SQM 43

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 15: Constraints upon quality improvement

wider range of tools than is conventionally considered. Those tools which impose critical constraints are those which should be carefully considered.

SQM

44

P.Selvapriyavadhana,Asst.Prof,ACT

10

Quality Prompts - The COQUAMO project

Some of the most inuential work in the UK in recent years has been carried out by Kitchen ham and co-workers, resulting in the COQUAMO toolset. Their view of quality is based upon the ve views of quality setout by Garvin (1984) and described in detail in the rst chapter of this book. Many of the ideas on measurement are based upon the work of Gilb. Garvin describes quality in terms of ve views: transcendent, product-based, user-based, manufacturing-based and value- based. In order to accommodate these diering views Kitchen ham (1989b) introduces the concept of a quality prole , making a distinction between subjective and objective measures of quality. The quality prole is the view of the overall quality of the system, and is split into the following components: Transcendent Properties. These are qualitative factors which are hard to measure, and about which people have dierent views and denitions, for example, usability. Quality Factors. These are characteristics of the system which are made up of measurable factors called quality metrics and quality attributes. The quality factors themselves are either subjective or objective characteristics, for example, reliability and exibility. Merit Indices. These subjectively dene functions of the system.They are measured by quality ratings, which are subjective value ratings.

SQM

45

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 16: Quality prole,after Kitchenham

SQM

46

P.Selvapriyavadhana,Asst.Prof,ACT

The work has led to a constructive quality model known as COQUAMO (Constructive Quality Model), named after the earlier COCOMO model (Constructive Cost Model) of software economics, due to Boehm. This model forms the basis of tools developed to assist software developers in their objective of supplying a high quality system. The aim of this model is threefold: To predict nal product quality To monitor progress towards a quality product To feed back the results to improve predictions for the next project. The model uses a similar approach to the earlier COCOMO model (Boehm, 1981) and is delivered as three tools, -one to predict quality at the start (COQUAMO-1) -one to monitor quality during development (COQUAMO-2) and -one to measure the quality of the nal product (COQUAMO3). The predictive and measuring tools are said to reect the user s view of quality; The monitoring tool is said to reect a manufacturing or developer s view of quality.

SQM

47

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 17: The COQUAMO toolset

SQM

48

P.Selvapriyavadhana,Asst.Prof,ACT

COQUAMO makes use of ve types of quality drivers: Product attributes such as quality requirements, success criticality and diculty of developing the product in question. Process attributes such as process maturity, tool use and method maturity. Personnel attributes such as sta experience and motivation. Project attributes such as the, quality norms and leadership style Organizational attributes such as quality management and physical environment. COQUAMO-1:Prediction COQUAMO-1 can only consider those quality factors which are common to most applications and applicationindependent in nature. Thus it considers reliability, maintainability, extensibility, usability and reusability as dened below. Reliability is dened as the expected time to next failure at the release date. Maintainabilit y is dened as the average elapsed time to identify the cause of a fault once reported. Extensibility is dened as the average productivity achieved for code changes. Usability is dened as the expected time to next nonfault problem report. Reusability is dened as the eort used in creating modules (code and design) intended for reuse (a potential cost saving).
SQM 49

P.Selvapriyavadhana,Asst.Prof,ACT

COQUAMO-2: Monitoring COQUAMO-2 is based upon a set of guidelines to carry out a number of tasks to assist in the monitoring of quality during a project. The guidelines set out to: identify appropriate metrics for each stage of the development process indicate methods for setting targets for project-level metrics suggest methods of analysis to identify unusual components indicate possible causes of unusual components and deviations in performance, and indicate possible corrective action. The automation of COQUAMO-2 is a complex task and at the time of writing is still a matter of research. The manual guidelines have been tested and have proved worthwhile in trials. COQUAMO-3: Testing COQUAMO-3 is intended to provide data about the quality of the end product. This is done both to validate the predictions made by COQUAMO-1, and also to provide data for the use of COQUAMO-1 in future projects. The current deliverables from this project show a number of remaining limitations: They require a record of past performance, upon which predictions are based. This may not be available or may be inapplicable if working practices are changed to increase productivity, e.g. if CASE tools are introduced.
SQM 50

P.Selvapriyavadhana,Asst.Prof,ACT

They are still dependent upon subjective assessment, although as the tools are used, these assessments are modied in the light of experience. They exclude a number of common quality criteria, notably performance and portability. Some common criteria, e.g. usability, that are included are dened in an idiosyncratic way. The tools eectiveness cannot be empirically veried.

SQM

51

Vous aimerez peut-être aussi