Unit 1

Software Quality Management
July 27, 2011

Author name : Selvapriyavadhana
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 Criteria 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 Approach -Quality Prompts.
UNIT III:QUALITY MANAGEMENT SYSTEM

Elements Of A Quality Engineering Program - Quality Control, Assurance And Engineering - Reliability, Maintainability, Veriability, 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 Spectrum - Principle And Critical Practices In QMS - ISO 9001 And Capability Maturity Models -Six Sigma, Zero Defects And Statistical Quality Control.
UNIT V MEASURES AND METRICS IN PROCESS AND PROJECT DOMAINS 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
Fundamentals of software quality engineering 1 Quality
Software quality In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several dierent denitions.
Denition:
1. Conformance to specication: Quality that is dened as a matter of products and services whose measurable characteristics satisfy a xed specication that is conformance to an in beforehand dened specication. 2. Meeting customer needs: Quality that is identied independent of any measurable characteristics. That is quality is dened as the products or services capability to meet customer expectations explicit or not. 3. Quality is the degree of goodness of a product or service or perceived by the customer. The Department of Defense (DOD, 1985) in the USA denes software quality as the degree to which the attributes of the software enable it to perform its intended end use .
SQM
Characteristics of Quality:
Quality is a multidimensional construct. It may therefore be considered using a polyhedron metaphor. Within this metaphor, a threedimensional solid represents quality. Each face represents a dierent aspect of quality such as correctness, reliability, and eciency.
Quality is not absolute. Quality is multidimensional. Quality is subject to constraints Quality is about acceptable compromises. Quality criteria are not independent, but interact with each other causing conicts. Views of Quality In an attempt to classify dierent and conicting views of quality,Garvin(1984) has suggested ve dierent views of quality: 1. The transcendent view Innate excellence Classical denition 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. 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. 2 HIERARCHICAL MODEL OF QUALITY
To compare quality in dierent situations, both qualitatively and quantitatively, it is necessary to establish a model of quality. Many model suggested for quality. Most are hierarchical in nature. A quantitative assessment is generally made, along with a more quantied assessment. Two principal models of this type, one by Boehm(1978) and one byMcCall in 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?
SQM
THE HIERARCHICAL MODELS OF BOEHM AND MCCALL THE GE MODEL This model was rst proposed byMcCall in 1977. It was later revised as theMQmodel, and it is aimed by system developers to be used during the development process. In early attempt to bridge the gap between users and developers, the criteria were chosen in an attempt to reect 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 dene them in terms to non specialist managers.
SQM
The three areas addressed by McCalls model (1977)
(basic operational characteristics) requires that it can be learnt easily, operated efciently And it results are those required by the users. The product operations perspective identies quality factors that inuence the extent to which the software fulls its specication:Product operation :
Correctness, the functionality matches the specication. Reliability, the extent to which the system fails. Eciency, system resource (including cpu, disk, memory, network) usage. Integrity, protection from unauthorized access. Usability, ease of use. (ability to change) it is concerned with error correction and adaptation Of the system and it is most costly part of software development. The product revision perspective identies quality factors that inuence the ability to change the software product, these factors are: Maintainability, the ability to nd and x a defect.
Product revision :
Flexibility, the ability to make changes required as dictated by the business.

SQM 7
Testability, the ability to Validate the software requirements. (adaptability to new environments) it is an important application and it is distributed processing and the rapid rate of change in hardware is Likely to increase. The product transition perspective identies quality factors that inuence the ability to adapt the software to new environments:Product transition :
Portability, the ability to transfer the software from one environment to another. Reusability, the ease of using existing software components in a dierent context. Interoperability, the extent, or ease, to which software components work together. McCalls criteria of quality dened 1. Eciency is concerned with the use of resources e.g. processor time, storage. It falls into two categories: execution eciency and storage eciency. 2. Usability is the ease of use of the software. 3. Integrity is the protection of the program from unauthorized access. 4. Correctness is the extent to which a program fulls its specication. 5. Reliability is its ability not to fail. 6. Maintainability is the eort required to locate and x a fault in the program within its operating environment.
SQM 8
Figure 1: The GE model after McCall
7. Flexibility is the ease of making changes required by changes in the operating environment. 8. Testability is the ease of testing the programs, to ensure that it is error-free and meet its specication. 9. Portability is the eort required to transfer a program from one environment to another. 10. Reusability is the ease of refusing software in a dierent context. 11. Interoperability is the eort required to couple the system to another system.
SQM
The Boehm model (1978) It is to provide a set of well-dened, welldierentiated 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. The two models share a number of common characteristics are, 1. The quality criteria are supposedly based upon the user s view. 2. The models focus on the parts that designers can more readily analyze. 3. Hierarchical models cannot be tested or validated. It cannot be shown that the metrics accurately reect the criteria. 4. The measurement of overall quality is achieved by a weighted summation of the characteristics.
SQM
10
Boehm talks of modiability where McCall distinguishes expandability from adaptability and documentation, 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 exible and qualitative view on quality, this section will present a more xed 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 reect both the users views and the developers priorities.
Three major perspectives for dening and identifying the quality of a software product:
product revision (ability to undergo changes), product transition (adaptability to new environments) and product operations (its operation characteristics).
SQM 11
Product revision includes 1. Maintainability (the eort required to locate and x a fault in the program within its operating environment), 2. Flexibility (the ease of making changes required by changes in the operating environment) and 3. Testability (the ease of testing the program, to ensure that it is error-free and meets its specication). Product transition is all about portability (the eort required to transfer a program from one environment to another), 1. Reusability (the ease of reusing software in a dierent context) and 2. Interoperability (the eort required to couple the system to another system). Quality of product operations depends on 1. Correctness (the extent to which a program fulls its specication), 2. Reliability (the systems ability not to fail), 3. Eciency (further categorized into execution eciency and storage eciency and generally meaning the use of resources, e.g. processor time, storage), 4. Integrity (the protection of the program from 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 predecessors of todays quality models is the quality model presented by Barry W. Boehm . Boehm addresses the contemporary shortcomings of models that automatically and quantitatively evaluate the quality of software. In essence his models attempts to qualitatively dene software quality by a given set of attributes and metrics. Boehms model is similar to the McCall Quality Model in that it also presents a hierarchical quality model structured around high-level characteristics, intermediate level characteristics, primitive characteristics - each of which contributes to the overall quality 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, eciently) 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 my environment? The intermediate level characteristic represents Boehms 7 quality factors that together represent the qualities expected from a software system: Portability (General utility characteristics): Code possesses the characteristic portability to the extent that it can be operated easily and well on computer congurations other than its current one. Reliability (As-is utility characteristics): Code possesses the characteristic reliability to the extent that it can be expected to perform its intended functions satisfactorily. Eciency (As-is utility characteristics): Code possesses the characteristic eciency to the extent that it fullls its purpose without waste of resources. Usability (As-is utility characteristics, Human Engineering): Code possesses the characteristic usability to the extent that it is reliable, ecient and human-engineered. Testability (Maintainability characteristics): Code possesses the characteristic testability to the
SQM 14
extent that it facilitates the establishment of verication criteria and supports evaluation of its performance. Understandability (Maintainability characteristics): Code possesses the characteristic understandability to the extent that its purpose is clear to the inspector. Flexibility (Maintainability characteristics, Modiability): Code possesses the characteristic modiability to the extent that it facilitates the incorporation of changes, once the nature of the desired change has been determined. The lowest level structure of the characteristics hierarchy in Boehms model is the primitive characteristics metrics hierarchy. The primitive characteristics provide the foundation for dening qualities metrics which was one of the goals when Boehm constructed his quality model. Consequently, the model presents one ore more metrics2 supposedly measuring a given primitive characteristic.
SQM
15
Figure 3: Boehms Software Quality Characteristics Tree
SQM
16
QUALITY CRITERIA and INTERRELATION
The individual measure of software quality provided do not provide an over all measure of software quality. The individual measures must be combined. The individual measures of quality may conict with each other. Some of these relationships are described below; Integrity vs. eciency (inverse) the control of access to data or software requires additional code and processing leading to a longer runtime and additional storage requirement. Usability vs. eciency (inverse) Improvements in the human / computer interface may significantly increase the amount of code and power required. Maintainability and testability vs. eciency (inverse) Optimized and compact code is not easy to maintain. Portability vs. eciency (inverse) the use of optimized software or system utilities will lead to decrease in probability. Flexibility, reusability and interoperability vs. eciency (inverse) the generally required for a exible system, the use if interface routines and the modularity desirable for reusability will all decrease eciency. Flexibility and reusability vs. integrity (inverse) the general exible data structures required for exible and reusable software increase the security and protection problem. Interoperability vs. integrity (inverse) Coupled system allow more avenues of access to more and dierent users.
SQM 17
Reusability vs. reliability (inverse) reusable software is required to be general: maintaining accuracy and error tolerance across all cases is dicult. Maintainability vs. exibility (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-specic features. Correctness vs. eciency (neutral) the correctness of code, i.e. its conformance to specication does not inuence its eciency.
SQM
18
Figure 4: Quality criteria inter-relation
SQM
19
Process Improvement Strategy Study an existing process to understand its activities.Produce an abstract model of the process. Analyse the model to discover process problems. This involves discussing process activities with stakeholders and discovering problems and possible process changes. 5 Quality Improvement Model Set the Goal Constitute the Software Engineering Process Group (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 after review Baseline the process Train the practitioners
SQM
20
Figure 5: Improvement Model
SQM
21
Quality Improvement Process quality and product quality are closely related and process improvement benets arise because the quality of the product depends on its development process. A good process is usually required to produce a good product. For manufactured goods, process is the principal quality 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 reects the increasing attention paid by industry to quality. However, other process attributes can also be the focus of improvement.
For large projects with average capabilities, the development process determines product quality. For small projects, the capabilities of the developers is the main determinant. The development technology is particularly signicant for small projects.
Quality Improvement Both product and process assessment are required for quality improvement. Performing Testing activities, conducting audits and SQA assessments help to improve the process throughout the organization Review of all the processes and documents are 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 Non Compliance of quality standards and improve the process compliance. Quality products and services result from quality systems, processes and methods. Quality is all-consuming focus of the organization.
SQM
23
Process Maturity Levels
As organizations move up the maturity ladder, they are more likely to produce higher quality products with more predictable costs and cycle times. The higher levels are more likely to correlate with higher productivity and shorter cycle times as well. The idea of model based software improvement is very simple. First pick the applicable Process Areas. Next perform an assessment of organizational practices relative to the model. The organization practices do not have to conform exactly to the representative practices included in the model. They just have to meet the stated goals of each PA. Based on this comparison, assign a maturity level to the organization and produce a list of strengths and weakness relative to the model. The output of the assessment is used to prioritize areas for improvement. The idea is to improve decient practices at the lower maturity levels rst and systematically move up in maturity level over time using additional assessments to measure progress. Focusing on the lowest level practices puts a rm foundation in place before tacking the higher level processes and it give the organization time to internalize the changes. This approach nicely avoids the twin problems of putting practices in place before required supporting practices are available and trying to do too much too soon.
SQM
24
So model based improvement has a lot of very attractive features. One of the most attractive ones is the level goal itself. The numerical level gives organizations a metric that that can be easily understood, can used to measure progress, and can used to benchmark against other organizations. SEI has dened a formal appraisal methodology and provided a lead assessor training and certication program. This means that assessment results, particular those obtained using a third party assessor, will be reasonably consistent and can be used to benchmark against other organizations. In fact SEI maintains a publicly accessible database of assessment results giving the number of organizations at each level by industry and the average time for an organization to improve from one level to the next.
Process Maturity Levels Level 1 - Initial Level 2 - Repeatable Level 3 - Dened Level 4 - Managed Level 5 - Optimizing
SQM
25
Level 1 - Initial 1. Characteristics Chaotic planning, performance, and results Lost (i.e., forgotten) or misunderstood requirements Unpredictable cost, schedule, and quality performance 2. Needed Actions Planning (size and cost estimates, schedules) 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 and procedures
- Introduce with great care ( new tools and methods). - To develop a new kind of project leads to new problem. - Organization changes can also be disruptive( new manager). 2. Needed Actions Develop process standards and denitions Establish a process group. Establish methods for requirements analysis, design, coding, inspection, and testing Level 3 - Dened 1. Characteristics Qualitative(little). Requirements are logged, tracked, and closed out Reliable costs and schedules Improving but still unpredictable quality performance
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 product quality. Cost of gathering data is the problem. 2. Needed Actions Quantitative productivity plans and tracking Automatic gathering of process data , Accuracy in manual is poor. Economically justied technology investments Level 5 - Optimizing 1. Characteristics Quantitative basis for continued capital investment in process automation and improvement. Data relates directly to product improvement. Error prevention through inspection that nd and xes the bugs.
SQM
28
Figure 7: Software Process Maturity Levels
Removal of defects by assessment of project quality. 2. Needed Actions Continued emphasis on process measurement and process methods for error prevention
SQM
29
Capability Maturity Model
The CMM denes the characteristics of a mature, capable process in a way that can be measured and compared to processes at other organizations. The CMM consists of areas of improvement, goals that must be met for each area, and specic practices to be implemented. A software engineering process group within the organization identies problems and ineciencies and denes practices to address them. Independent assessors verify that an organization 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 notion that if one has six standard deviations between the mean of a process and the nearest specication limit, there will be practically no items that fail to meet the specications. 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 ve-phase approach to Six Sigma improvement
SQM
30
Dene opportunities, Measure performance, Analyze opportunity, Improve performance, Control performance
The fundamental objective of the Six Sigma methodology is the implementation of a measurementbased strategy that focuses on process improvement and variation reduction through the application of Six Sigma improvement projects. This is accomplished through the use of two Six Sigma sub-methodologies: DMAIC and DMADV. The Six Sigma DMAIC process (dene, measure, analyze, improve, control) is an improvement system for existing processes falling below specication and looking for incremental improvement. The Six Sigma DMADV process (dene, measure, analyze, design, verify) is an improvement system used to develop new processes or products at Six Sigma quality levels. It can also be employed if a current process requires more than just incremental improvement.
SQM
31
There are ve 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 organization tells us to what extent an organization can produce low cost, high quality software. Having known the current maturity level, an organization can work to reach the next higher level.
SQM
34
Figure 9: The CMM structure
SQM
35

Unit 1

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Unit 1

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Quality Management

July 27, 2011

UNIT I : FUNDAMENTALS OF SOFTWARE QUALITY ENGINEERING

UNIT II:DEVELOPMENTS IN MEASURING QUALITY

UNIT III:QUALITY MANAGEMENT SYSTEM

UNIT IV:PRINCIPLES AND PRACTICES IN QMS

Fundamentals of software quality engineering 1 Quality

The three areas addressed by McCalls model (1977)

Flexibility, the ability to make changes required as dictated by the business.

Figure 1: The GE model after McCall

McCalls Quality Model (1977)

Figure 2: McCalls Quality Model

Figure 3: Boehms Software Quality Characteristics Tree

QUALITY CRITERIA and INTERRELATION

Figure 4: Quality criteria inter-relation

Figure 5: Improvement Model

Figure 6: product quality factors

Process Maturity Levels

Figure 7: Software Process Maturity Levels

Capability Maturity Model

DMAIC is a ve-phase approach to Six Sigma improvement

Figure 8: SW-CMM maturity levels

Figure 9: The CMM structure

Anda mungkin juga menyukai