Software Quality and Assurance

Software
Quality and
Assurance
Code
ACeL
Software quality is a complex and multifaceted concept that can be

described from different perspectives depending on the context
peculiarities and stakeholders.
AMITY
UNIVERSITY
PREFACE
Software quality is a complex and multifaceted concept that can be described from different
perspectives depending on the context peculiarities and stakeholders. Though measuring quality
is not a new theme, asking a developer to measure the quality of a product may generally sound
like an unknown or even a new aspect to the software activities. In this book an attempt has been
made to describe various pertinent aspects of software quality from different points of view.
Quality is a dynamic attribute which keeps on changing over the life cycle time of the product,
product line and product family. Quality attributes must be sustained, preserved and improved.
Therefore, it appears high time to introduce software quality aspects to software engineers of
today rather than wait for them to learn through experience at a high cost.
Software quality assurance is now such a huge area that it is impossible to cover the whole
subject in one book. In addition I emphasize the importance of software quality assurance life
cycle, visualize the software quality assurance planning, monitoring, testing, understand and
establish the standards and procedures. I investigate the need of software quality metrics and
models, basic software quality assurance activities. It also includes the descriptions on the
benefits of software quality assurance for projects and software quality assurance planning,
established standards and evolution of standards. It also focuses on software measurements and
metrics together with needs, importance and significance of software metrics. Good testing
involves much more than just running the program a few times to see whether it works.
Thorough analysis of program helps us to test more systematically and more effectively. My
focus, therefore, is on key topics that are fundamental to all software development processes and
topics concerned with the software development process, Software requirements and
specifications, Software design techniques, Techniques for developing large software systems,
CASE tools and software development environments, Software testing, documentation and
maintenance. I need to combine the best of these approaches to build better software systems.
Time is compelling us to improve software development processes in order to provide good
quality maintainable software within reasonable cost and development time. As we know, quality
is easy to feel but difficult to define and impossible to measure. As a result, this book delivers a
comprehensive state-of-the-art overview and empirical results for researchers in academia and
industry in areas like software process management, empirical software engineering, and global
software development. Practitioners working in this area will also appreciate the detailed
descriptions and reports which can often be used as guidelines to improve their daily work.
The book is primarily intended as a student text for senior undergraduate and graduate students
studying computer science, software engineering or systems engineering.
In this course, chapters 1 and 2 may be used to provide an overview of software quality and
quality models.
A more extensive course, lasting a semester, might either develop this material with either a
process or a techniques focus. If the orientation of the course is towards processes, then chapters
3, 4, 5 and 6 which cover software quality assurance, software quality control, metrics and
measurement of quality and quality standards might be covered in addition to the introductory
material.
Nevertheless, I hope that all software engineers and software engineering students can find best
from here. Following is the syllabus provided for your reference:
SYLLABUS
Module I: Quality Concepts and Practices
Why Quality?, Cost of Quality, TQM concept, Quality Pioneers Approaches to Quality.
Module II: Software Quality
Software Development Process, S/w quality Attributes (Product Specific and Organization
Specific, Hierarchical Models of quality. Concept of Quality Assurance and Quality Control
Module III: Software Quality Assurance
Implementing an IT Quality function, Content of SQA Plan, Quality Tools, Quality baselines,
Model and assessment fundamentals, Internal Auditing and Quality assurance.
Module IV: Software Quality Control
Testing Concepts - ad hoc, white box, black box and integration, Cost Effectiveness of Software
Testing credibility & ROI, right methods, Developing Testing Methodologies- Acquire and
study the test strategy, building the system test plan and unit plan , Verification and Validation
methods, Software Change Control- SCM, change control procedure, Defect Management
causes, detection, removal and tracking,
Module V: Metrics and Measurement of Software Quality
Measuring Quality, measurement concepts- Standard unit of measure, software metrics, Metrics
Bucket, Problems with Metrics, Objective and subjective measurement, measure of central
tendency, attributes of good measurement, Installing measurement program, Risk Managementdefining, characterizing risk, managing risk, software risk management
Module VI: Quality Standards
Introduction to various Quality standards: ISO-9000 Series, Six Sigma, SEI CMMi Model.
Table of Contents
PREFACE ...................................................................................................................................... 2
SYLLABUS ................................................................................................................................... 4
CHAPTER 1 : QUALITY CONCEPTS AND PRACTICES ................................................. 13
1.1 INTRODUCTION ............................................................................................................... 13
1.1.1 Definition of Quality .................................................................................................... 14
1.2 COST OF QUALITY .......................................................................................................... 15
1.3 TOTAL QUALITY MANAGEMENT ............................................................................... 17
1.3.1 TQM Definition ............................................................................................................ 17
1.3.2 Principles of TQM ........................................................................................................ 19
1.3.3 The Concept of Continuous Improvement by TQM .................................................... 20
1.3.4 Implementation Principles and Processes of TQM ...................................................... 22
1.3.5 The building blocks of TQM ........................................................................................ 23
1.4 APPROACHES TO QUALITY .......................................................................................... 25
1.4.1 TQM Approach............................................................................................................. 25
1.4.2 Six Sigma ..................................................................................................................... 26
1.5 SUMMARY ........................................................................................................................ 27
Assignment-Module 1 ............................................................................................................... 28
Key - Module 1 ......................................................................................................................... 31
CHAPTER 2 : SOFTWARE QUALITY .................................................................................. 32
2.1 SOFTWARE DEVELOPMENT PROCESS ...................................................................... 32
2.1.1 System/Information Engineering and Modeling .......................................................... 32
2.1.2 Software Development Life Cycle ............................................................................... 33
2.1.3 Processes ....................................................................................................................... 33
2.1.4 Software development activities ................................................................................... 33
2.1.5 Process Activities/Steps ................................................................................................ 34
2.2 SOFTWARE DEVELOPMENT MODELS OR PROCESS MODEL ............................... 37
2.2.1 Waterfall Model ............................................................................................................ 37
2.2.2 Prototyping Model ........................................................................................................ 38
2.2.3 Spiral model .................................................................................................................. 38
2.2.4 Strength and Weakness of Waterfall, Prototype and Spiral Model .............................. 40
2.2.5 Iterative processes......................................................................................................... 41

2.2.6 Rapid Application Development (RAD) Model ........................................................... 43
2.2.7 Component Assembly Model ....................................................................................... 44
2.2.8 Process improvement models ....................................................................................... 45
2.3 SOFTWARE QUALITY ATTRIBUTES ........................................................................... 46
2.3.1 Introduction .................................................................................................................. 46
2.3.2 Common Quality Attributes ......................................................................................... 47
2.4 HIERARCHICAL MODELS OF QUALITY ..................................................................... 61
2.4.1 What is hierarchical model? ......................................................................................... 61
2.4.2 THE McCALL AND BOEHM MODELS ................................................................... 65
2.5 PRACTICAL EVALUATION ............................................................................................ 70
2.5.1 Quality Assurance......................................................................................................... 73
2.5.2 Quality Assurance Plan ................................................................................................ 73
2.5.3 Quality control .............................................................................................................. 75
2.5.4 Quality Assurance (QA) ............................................................................................... 76
2.5.5 Quality Control (QC): ................................................................................................... 77
2.5.6The Following Statements help differentiate Quality Control from Quality Assurance 77
2.6 SUMMARY ........................................................................................................................ 78
Assignment-Module 2 ............................................................................................................... 80
Key - Module 2 ...................................................................................................................... 82
CHAPTER 3 : SOFTWARE QUALITY ASSURANCE ......................................................... 83
3.1 IMPLEMENTING IT QUALITY FUNCTION ................................................................. 83
3.1.1 Past experience ............................................................................................................. 83
3.1.2 Create a clear mission ................................................................................................... 84
3.1.3 Set specific objectives .................................................................................................. 85
3.1.4 Develop simple strategies ............................................................................................. 85
3.1.5 Design a small, focused quality function...................................................................... 85
3.2 QUALITY FUNCTION DEPLOYMENT .......................................................................... 87
3.2.1 The QFD Team ............................................................................................................. 90
3.2.2 Benefits of QFD............................................................................................................ 91
3.3 ORGANIZATION OF INFORMATION ........................................................................... 96
3.3.1 Affinity Diagram .......................................................................................................... 97

3.4 HOUSE OF QUALITY ....................................................................................................... 98
3.5 SQA PLANNING ............................................................................................................... 99
3.5.1 SQA Plan Content ...................................................................................................... 100
3.6 QUALITY TOOLS ........................................................................................................... 101
3.7 QUALITY BASELINES................................................................................................... 119
3.7.1 Quality Baseline Concepts.......................................................................................... 119
3.7.2 Methods Used for Establishing Baselines .................................................................. 119
3.7.3 Model and Assessment Fundamentals ........................................................................ 119
3.7.4 Industry Quality Models ............................................................................................. 120
3.8 INTERNAL AUDITING AND QUALITY ASSURANCE ............................................. 120
3.8.1 Internal Audit Quality Assurance Reviews ................................................................ 121
3.8.2 Quality assurance services include: ............................................................................ 121
3.8.3 Scope of QAR:............................................................................................................ 121
3.8.4 Benefits of QAR: ........................................................................................................ 122
3.9 SUMMARY ...................................................................................................................... 122
Assignment-Module 3 ............................................................................................................. 124
Key - Module 3 .................................................................................................................... 126
CHAPTER 4 : SOFTWARE QUALITY CONTROL ........................................................... 127
4.1 SOFTWARE TESTING .................................................................................................... 127
4.1.1 Cost Effectiveness of Testing ..................................................................................... 128
4.2 SOME FUNDAMENTAL CONCEPTS ........................................................................... 129
4.2.1 Defects and failures .................................................................................................... 129
4.2.2 Input combinations and preconditions ........................................................................ 129
4.2.3 Economics .................................................................................................................. 130
4.2.4 Roles ........................................................................................................................... 130
4.3. KEY ISSUES ................................................................................................................. 130
4.3.1 Test selection criteria/Test adequacy criteria ............................................................. 130
4.3.2 Testing effectiveness/Objectives for testing ............................................................... 130
4.3.3 Testing for defect identification ................................................................................. 131
4.3.4 The oracle problem ..................................................................................................... 131
4.3.5 Theoretical and practical limitations of testing .......................................................... 131

4.3.6 The problem of infeasible paths ................................................................................. 131
4.3.7 Testability ................................................................................................................... 132
4.4 TESTING METHODS ...................................................................................................... 132
4.4.1 Static vs. dynamic testing ........................................................................................... 132
4.4.2 The box approach ....................................................................................................... 132
4.4.3 White-Box testing ....................................................................................................... 133
4.4.4 Black-box testing ........................................................................................................ 134
4.4.5 Grey-box testing ......................................................................................................... 135
4.4.6 Visual testing .............................................................................................................. 136
4.5 TESTING LEVELS .......................................................................................................... 137
4.5.1 Unit testing ................................................................................................................. 137
4.5.2 Integration testing ....................................................................................................... 137
4.5.3 System testing ............................................................................................................. 138
4.5.4 System integration testing .......................................................................................... 138
4.5.5 Top-down and bottom-up ........................................................................................... 138
4.6. OBJECTIVES OF TESTING .......................................................................................... 138
4.6.1 Installation testing....................................................................................................... 138
4.6.2 Compatibility testing .................................................................................................. 139
4.6.3 Smoke and sanity testing ............................................................................................ 139
4.6.4 Regression testing ....................................................................................................... 139
4.6.5 Acceptance testing ...................................................................................................... 140
4.6.6 Alpha testing ............................................................................................................... 140
4.6.7 Beta testing ................................................................................................................. 140
4.6.8 Functional vs non-functional testing .......................................................................... 140
4.6.9 Destructive testing ...................................................................................................... 141
4.6.10 Software performance testing ................................................................................... 141
4.6.11 Usability testing ........................................................................................................ 142
4.6.12 Accessibility ............................................................................................................. 142
4.6.13 Security testing ......................................................................................................... 142
4.6.14 Internationalization and localization ........................................................................ 142
4.7 THE TESTING PROCESS ............................................................................................... 144

4.7.1 Practical considerations .............................................................................................. 144
4.7. 2 Test Activities ............................................................................................................ 146
4.8 SOFTWARE TESTING LIFE CYCLE ............................................................................ 148
4.8.1 Measurement in software testing ................................................................................ 150
4.8.2 Testing artifacts .......................................................................................................... 150
4.8.3 Test Case Development .............................................................................................. 152
4.8.4 General Guidelines ..................................................................................................... 152
4.8.5 Test Case Sample Structure ..................................................................................... 153
4.8.6 Most common software errors .................................................................................... 153
4.8.7 Guidelines for good tester? ......................................................................................... 155
4.9 SOFTWARE VERIFICATION AND VALIDATION ..................................................... 156
4.9.1 Software Verification and Validation Methods .......................................................... 158
4.10 SOFTWARE CHANGE CONTROL .............................................................................. 166
4.10.1 Software Change Requirements ............................................................................... 166
4.11 SOFTWARE CHANGE MANAGEMENT .................................................................... 169
4.11.1 Change Management and Configuration Management ............................................ 169
4.11.2 Where Changes Originate ......................................................................................... 170
4.11.5 Change Management Tools ...................................................................................... 174
4.11.6 SCM Tools................................................................................................................ 175
4.11.7 Problem-Report and Change-Request Tracking ....................................................... 176
4.11.8 Key to Change Management .................................................................................... 176
4.12 SOFTWARE CHANGE CONTROL PROCEDURES ................................................... 177
4.12.1 Initiating the Change ................................................................................................ 177
4.12.2 Working on the Change Request .............................................................................. 177
4.12.3 Testing the Change Request ..................................................................................... 178
4.13 DEFECT MANAGEMENT ............................................................................................ 178
4.13.1 What is a defect?....................................................................................................... 178
4.13.2 What are the defect categories? ................................................................................ 178
4.13.3 Defect Management Process .................................................................................... 180
4.13.3 Steps in Defect Management Process ....................................................................... 180
4.15 SUMMARY .................................................................................................................... 183

Key - Module 4 .................................................................................................................... 187
CHAPTER 5 METRICS AND MEASUREMENT OF SOFTWARE QUALITY.............. 188
5.1 MEASURING SOFTWARE QUALITY .......................................................................... 188
5.1.1 Measuring quality automatically ................................................................................ 188
5.2 SOFTWARE METRICS ................................................................................................... 189
5.3 TYPE OF SOFTWARE METRICS: ................................................................................. 190
5.4 ADVANTAGE OF SOFTWARE METRICS: .................................................................. 191
5.5 LIMITATION OF SOFTWARE METRICS: ................................................................... 191
5.6 SIZE METRICS ................................................................................................................ 192
5.7 SCIENCE METRICS ........................................................................................................ 193
5.8 FLOW METRICS ............................................................................................................. 195
5.9 INFORMATION FLOW METRICS ................................................................................ 196
5.10 PROBLEM WITH METRICS ........................................................................................ 198
5.10.1 Common mistakes include: ...................................................................................... 199
5.10.2 The main points with metrics are: ............................................................................ 199
5.10.3 Characteristics of Good Metrics ............................................................................... 200
5.11 OBJECTIVE AND SUBJECTIVE MEASUREMENT .................................................. 201
5.11.1 Objective Quality Assessment .................................................................................. 202
5.11.2 Subjective Quality Assessment ................................................................................ 203
5.12 MEASURES OF CENTRAL TENDENCY ................................................................... 203
5.12.1 Definition of Measures of Central Tendency ........................................................... 203
5.12.2 More about Measures of Central Tendency ............................................................. 203
5.12.3 Examples of Measures of Central Tendency ............................................................ 204
5.12.4 Example on Measures of Central Tendency ............................................................. 204
5.12.5 Properties of a good measure of central tendency are:-............................................ 204
5.12.6 Characteristics of Good Measurement ..................................................................... 205
5.13 INSTALLING THE MEASUREMENT PROGRAM .................................................... 205
5.13.1 Build the Measurement base..................................................................................... 206
5.13.2 Manage towards results. ........................................................................................... 206
5.13.3 Manage by process. .................................................................................................. 208

5.13.4 Management by fact. ................................................................................................ 209
5.14 RISK MANAGEMENT .................................................................................................. 209
5.14.1 Types of Risk ............................................................................................................ 210
5.14.2 Categories of risks: ................................................................................................... 210
5.14.3 Goals of Risk Management ...................................................................................... 212
5.14.4 Process for Identifying and Managing Risk ............................................................. 213
5.14.5 Strategies for Managing Risk ................................................................................... 213
5.15 RISK MANAGEMENT PROCESS ............................................................................... 214
5.16 RISK IDENTIFICATION ............................................................................................... 215
5.17 RISK ANALYSIS ........................................................................................................... 216
5.18 RISK MANAGEMENT PLANNING ............................................................................ 217
5.19 SOFTWARE RISK MANAGEMENT PROCESS ......................................................... 218
5.19.1 Risk Assessment ....................................................................................................... 219
5.19.2 Review based Risk Assessment Process .................................................................. 220
5.19.3 Data Model of Risk Management ............................................................................. 221
5.19.4 Risk Mitigation ......................................................................................................... 222
5.20 SUMMARY .................................................................................................................... 222
Key - Module 5 .................................................................................................................... 226
CHAPTER 6 : QUALITY STANDARDS............................................................................... 227
6.1 ISO 9000 series ................................................................................................................. 227
6.1.1 Benefits of ISO 9000 .................................................................................................. 227
6.1.2 Advantages And Disadvantages Of ISO? ................................................................... 228
6.1.3 ISO 9000 Series .......................................................................................................... 229
6.2 SIX SIGMA....................................................................................................................... 230
6.2.1 Methods .......................................................................................................................... 232
6.2.1.2 DMADV or DFSS Method ...................................................................................... 233
6.2.2 Quality management tools and methods used in Six Sigma ....................................... 233
6.2.3 Implementation roles .................................................................................................. 234
6.2.4 Certification .................................................................................................................... 235
6.2.5 Origin and meaning of the term "six sigma process" ..................................................... 236
6.2.6 Role of the 1.5 sigma shift .......................................................................................... 237
6.2.7 Sigma levels ................................................................................................................ 237
6.2.8 Software used for Six Sigma ...................................................................................... 239
6.2.9 Application ................................................................................................................. 240
6.2.10 Criticism ................................................................................................................... 241
6.3 CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ................................... 244
6.3.1 CMMI representation ................................................................................................. 246
6.3.2 Appraisal ..................................................................................................................... 248
6.4 SUMMARY ...................................................................................................................... 249
Key - Module 6 .................................................................................................................... 252
REFERENCES .......................................................................................................................... 253
CHAPTER 1 : QUALITY CONCEPTS AND PRACTICES

1.1 INTRODUCTION
The concept of software quality is more complex than what common people tend to believe.
However, it is very popular both for common people and IT professionals. If we look at the
definition of quality in a dictionary, it is usual to find something like the following: set of
characteristics that allows us to rank things as better or worse than other similar ones. In many
cases, dictionaries mention the idea of excellence together with this type of definitions.
Certainly, this idea of quality does not help engineers to improve results in the different fields of
activity. In the world of industrial quality in general, a transition from a rigid concept to an
adaptive one was performed many years ago. The concept view tend to be more close to the
traditional idea of beauty: it is in the eyes of the observer. So, we reject absolute concepts and
tend to use customer satisfaction as main inspiration. For example, what characteristics are used
by customers as indicators of quality (i.e. excellence):
Product nature
Reputation of raw materials
Manufacturing location
Manufacturing method
Point-of-sale standing
Sophisticated restaurant than at the usual pub.
Price
Results
To understand the landscape of software quality it is central to answer the so often asked
question: what is quality? Once the concept of quality is understood it is easier to understand the
different structures of quality available on the market. As many prominent authors and
researchers have provided an answer to that question, we do not have the ambition of introducing
yet another answer but we will rather answer the question by studying the answers that some of
the more prominent gurus of the quality management community have provided. By learning
from those gone down this path before us we can identify that there are two major camps when
discussing the meaning and definition of (software) quality:
i) Conformance to specification: Quality that is defined as a matter of products and services
whose measurable characteristics satisfy a fixed specification that is, conformance to an in
beforehand defined specification.
ii) Meeting customer needs: Quality that is identified independent of any measurable
characteristics. That is, quality is defined as the products or services capability to meet customer
expectations explicit or not.
Quality software saves good amount of time and money. Because software will have fewer
defects, this saves time during testing and maintenance phases. Greater reliability contributes to
an immeasurable increase in customer satisfaction as well as lower maintenance costs. Because
maintenance represents a large portion of all software costs, the overall cost of the project will
most likely be lower than similar projects.
1.1.1 Definition of Quality

Quality is defined by International organizations as follows:
Quality comprises all characteristics and significant features of a product or an activity which
relate to the satisfying of given requirements. (German Industry Standard DIN 55350 Part 11)
Quality is the totality of features and characteristics of a product or a service that bears on its
ability to satisfy the given needs (ANSI Standard (ANSI/ASQC A3/1978).
High quality software usually conforms to the user requirements. A customers idea of quality
may cover a breadth of features - conformance to specifications, good performance on
platform(s)/configurations, completely meets operational requirements (even if not specified!),
compatibility to all the end-user equipment, no negative impact on existing end-user base at
introduction time etc.
1.2 COST OF QUALITY

In recent years organizations have been focusing much attention on quality management. There
are many different aspects of quality management but this tutorial focuses on the cost of quality.
The costs associated with quality are divided into two categories: costs due to poor quality and
costs associated with improving quality. Prevention costs and appraisal costs are costs associated
with improving quality, while failure costs result from poor quality.
Management must
understand these costs to create quality improvement strategy. An organizations main goal is to
survive and maintain high quality goods or services, with a comprehensive understanding of the
costs related to quality this goal can be achieved.
Costs are defined as the summation of costs over the life of a product. Customers prefer products
or services with a high quality and reasonable price. To ensure that customers will receive a
product or service that is worth the money they will spend firms should spend on prevention and
appraisal costs. Prevention costs are associated with preventing defects and imperfections from
occurring. Consider the Johnson and Johnson (J&J) safety seals that appear on all of their
products with the message, if this safety seal is open do not use. This is a preventive measure
because in the overall analysis it is least costly to purchase the safety seals in production than
undergo a possible cyanide scare. The focus of a prevention cost is to assure quality and
minimize or avoid the likelihood of an event with an adverse impact on the company goods,
services or daily operations. This also includes the cost of establishing a quality system. A
quality system should include the following three elements: training, process engineering, and
quality planning. Quality planning is establishing a production process in conformance with
design specification procedures, and designing of the proper test procedures and equipment.
Consider establishing training programs for employees to keep them efficient on emerging
technologies, such as updated computer languages and programs.
Appraisal costs are direct costs of measuring quality. In this case, quality is defined as the
conformance to customer expectations. This includes: lab testing, inspection, test equipment and
materials, costs associated with assessment for ISO 9000 or other quality award assessments. A
common example of appraisal costs is the expenses from inspections. An organization should
establish an inspection of their products and incoming goods from a supplier before they reach
the customer. This is also known as acceptance sampling, a technique used to verify that
products meet quality standards.
Failure Costs are separated into two different categories: internal and external. Internal failure
costs are expenses incurred from online failure. This includes cost of troubleshooting, loss of
production resulting from idle time either from manpower or during the production process.
External failure costs are associated with product failure after the completion of the production
process. An excellent example of external failure costs is the J&J cyanide scare. The company
incurred expenses in response to the customer fears of tampering with a purchased J&J product.
However, J&J managed to survive the incident, in part because of their method of corrective
action.
Understanding the cost of quality is extremely important in establishing a quality management
strategy. After defining the three major costs of quality and discussing their application we can
examine how they affect an organization. The more an organization invests in preventive
measures the more they are able to reduce failure costs. Furthermore, an investment in quality
improvement benefits the company image, performance and growth. This is basically summed
up by the Ludvall-Juran quality cost model, which applies the law of diminishing returns to these
costs. The model shows that prevention and appraisal costs have a direct relationship with
quality conformance, meaning they increase as quality conformance increases. Thus, quality
conformance should have an inverse relationship with failure costs - meaning as quality
conformance increases failure costs should decrease. Understanding these relationships and
applying the cost of quality process enables an organization to decrease failure costs and assure
that their products and services continue to meet customer expectations. Some companies that
have achieved this goal include Neiman-Marcus, Rolex, and Lexus.
Phillip Crosby states that quality is free. As discussed, the costs related to achieving quality are
traded off between the prevention and appraisal costs and the failure costs. Therefore, the
prevention and appraisal costs resulting from improved quality, allow an organization to
minimize or be free of the failure costs resulting from poor quality. In summation, understanding
cost of quality helps companies to develop quality conformance as a useful strategic business
tool that improves their products, services and image. This leverage is vital in achieving the
goals and mission of a successful organization.
1.3 TOTAL QUALITY MANAGEMENT

Total Quality Management is a management approach that originated in the 1950's and has
steadily become more popular since the early 1980's. Total Quality is a description of the culture,
attitude and organization of a company that strives to provide customers with products and
services that satisfy their needs. The culture requires quality in all aspects of the company's
operations, with processes being done right the first time and defects and waste eradicated from
operations.
Total Quality Management, TQM, is a method by which management and employees can
become involved in the continuous improvement of the production of goods and services. It is a
combination of quality and management tools aimed at increasing business and reducing losses
due to wasteful practices.
Some of the companies who have implemented TQM include Ford Motor Company, Phillips
Semiconductor, SGL Carbon, Motorola and Toyota Motor Company.
1.3.1 TQM Definition

TQM is a management philosophy that seeks to integrate all organizational functions
(marketing, finance, design, engineering, and production, customer service, etc.) to focus on
meeting customer needs and organizational objectives.
TQM views an organization as a collection of processes. It maintains that organizations must
strive to continuously improve these processes by incorporating the knowledge and experiences
of workers. The simple objective of TQM is "Do the right things, right the first time, every
time". TQM is infinitely variable and adaptable. Although originally applied to manufacturing
operations, and for a number of years only used in that area, TQM is now becoming recognized
as a generic management tool, just as applicable in service and public sector organizations. There
are a number of evolutionary strands, with different sectors creating their own versions from the
common ancestor. TQM is the foundation for activities, which include:
Commitment by senior management and all employees
Meeting customer requirements
Reducing development cycle times

Just In Time/Demand Flow Manufacturing
Improvement teams
Reducing product and service costs
Systems to facilitate improvement
Line Management ownership
Employee involvement and empowerment
Recognition and celebration
Challenging quantified goals and benchmarking
Focus on processes / improvement plans
Specific incorporation in strategic planning
This shows that TQM must be practiced in all activities, by all personnel, in Manufacturing,
Marketing, Engineering, R&D, Sales, Purchasing, HR, etc.
Figure 1.1 : TQM Interface
The core of TQM is the customer-supplier interfaces, both externally and internally, and at each
interface lie a number of processes. This core must be surrounded by commitment to quality,
communication of the quality message, and recognition of the need to change the culture of the
organization to create total quality. These are the foundations of TQM, and they are supported by
the key management functions of people, processes and systems in the organization.
1.3.2 Principles of TQM

The key principles of TQM are as following:
Management Commitment
Plan (drive, direct)
Do (deploy, support, participate)
Check (review)
Act (recognizes, communicate, revise)
Employee Empowerment
Training
Suggestion scheme
Measurement and recognition
Excellence teams
Fact Based Decision Making
SPC (statistical process control)
DOE, FMEA
The 7 statistical tools
TOPS (FORD 8D - Team Oriented Problem Solving)
Continuous Improvement
Systematic measurement and focus on CONQ

Excellence teams
Cross-functional process management
Attain, maintain, improve standards
Customer Focus
Supplier partnership
Service relationship with internal customers
Never compromise quality
Customer driven standards
1.3.3 The Concept of Continuous Improvement by TQM

TQM is mainly concerned with continuous improvement in all work, from high level strategic
planning and decision-making, to detailed execution of work elements on the shop floor. It stems
from the belief that mistakes can be avoided and defects can be prevented. It leads to
continuously improving results, in all aspects of work, as a result of continuously improving
capabilities, people, processes, and technology and machine capabilities.
Continuous improvement must deal not only with improving results, but more importantly with
improving capabilities to produce better results in the future. The five major areas of focus for
capability improvement are demand generation, supply generation, technology, operations and
people capability.
A central principle of TQM is that mistakes may be made by people, but most of them are
caused, or at least permitted, by faulty systems and processes. This means that the root cause of
such mistakes can be identified and eliminated, and repetition can be prevented by changing the
process.
There are three major mechanisms of prevention:

i.
Preventing mistakes (defects) from occurring (Mistake - proofing or Poka-Yoke).
ii.
Where mistakes can't be absolutely prevented, detecting them early to prevent them being
passed down the value added chain (Inspection at source or by the next operation).
iii.
Where mistakes recur, stopping production until the process can be corrected, to prevent
the production of more defects. (Stop in time).
The basis for TQM implementation is the establishment of a quality management system which
involves the organizational structure, responsibilities, procedures and processes. The most
frequently used guidelines for quality management systems are the ISO 9000 international
standards, which emphasize the establishment of a well- documented, standardized quality
system. The role of the ISO 9000 standards within the TQM circle of continuous improvement is
presented in the following figure.
Figure 1.1: Role if ISO 9000

Continuous improvement is a circular process that links the diagnostic, planning, implementation
and evaluation phases. Within this circular process, the ISO 9000 standards are commonly
applied in the implementation phase. An ISO 9000 quality system also requires the establishment
of procedures that standardize the way an organization handles the diagnostic and evaluation
phases. However, the ISO 9000 standards do not prescribe particular quality management
techniques or quality-control methods. Because it is a generic organizational standard, ISO 9000
does not define quality or provide any specifications of products or processes. ISO 9000
certification only assures that the organization has in place a well-operated quality system that
conforms to the ISO 9000 standards. Consequently, an organization may be certified but still
manufacture poor-quality products.
1.3.4 Implementation Principles and Processes of TQM

A preliminary step in TQM implementation is to assess the organization's current reality.
Relevant preconditions have to do with the organization's history, its current needs, precipitating
events leading to TQM, and the existing employee quality of working life. If the current reality
does not include important preconditions, TQM implementation should be delayed until the
organization is in a state in which TQM is likely to succeed.
If an organization has a track record of effective responsiveness to the environment, and if it has
been able to successfully change the way it operates when needed, TQM will be easier to
implement. If an organization has been historically reactive and has no skill at improving its
operating systems, there will be both employee skepticism and a lack of skilled change agents. If
this condition prevails, a comprehensive program of management and leadership development
may be instituted. A management audit is a good assessment tool to identify current levels of
organizational functioning and areas in need of change. An organization should be basically
healthy before beginning TQM. If it has significant problems such as a very unstable funding
base, weak administrative systems, lack of managerial skill, or poor employee morale, TQM
would not be appropriate.
However, a certain level of stress is probably desirable to initiate TQM. People need to feel a
need for a change. Kanter (1983) addresses this phenomenon as describing building blocks
which are present in effective organizational change. These forces include departures from
tradition, a crisis or galvanizing event, strategic decisions, individual "prime movers," and action
vehicles. Departures from tradition are activities, usually at lower levels of the organization,
which occur when entrepreneurs move outside the normal ways of operating to solve a problem.
A crisis, if it is not too disabling, can also help create a sense of urgency which can mobilize
people to act. In the case of TQM, this may be a funding cut or threat, or demands from
consumers or other stakeholders for improved quality of service. After a crisis, a leader may
intervene strategically by articulating a new vision of the future to help the organization deal
with it.
A plan to implement TQM may be such a strategic decision. Such a leader may then become a
prime mover, who takes charge in championing the new idea and showing others how it will help
them get where they want to go. Finally, action vehicles are needed and mechanisms or
structures to enable the change to occur and become institutionalized.
1.3.5 The building blocks of TQM

Everything we do is a Process, which is the transformation of a set of inputs, which can include
action, methods and operations, into the desired outputs, which satisfy the customers needs and
expectations. In each area or function within an organization there will be many processes taking
place, and each can be analyzed by an examination of the inputs and outputs to determine the
action necessary to improve quality. In every organization there are some very large processes,
which are groups of smaller processes, called key or core business processes. These must be
carried out well if an organization is to achieve its mission and objectives. The section on
Processes discusses processes and how to improve them, and Implementation covers how to
prioritize and select the right process for improvement.
Figure 1.2 : The TQM blocks
The only point at which true responsibility for performance and quality can lie is with the people
who actually do the job or carry out the process, each of which has one or several suppliers and
customers.
An efficient and effective way to tackle process or quality improvement is through teamwork.
However, people will not engage in improvement activities without commitment and recognition
from the organizations leaders, a climate for improvement and a strategy that is implemented
thoughtfully and effectively. The section on People expands on these issues, covering roles
within teams, team selection and development and models for successful teamwork.
An appropriate documented Quality Management System will help an organization not only
achieve the objectives set out in its policy and strategy, but also, and equally importantly, sustain
and build upon them. It is imperative that the leaders take responsibility for the adoption and
documentation of an appropriate management system in their organization if they are serious
about the quality journey. The Systems section discusses the benefits of having such a system,
how to set one up and successfully implement it.
Once the strategic direction for the organizations quality journey has been set, it needs
Performance Measures to monitor and control the journey, and to ensure the desired level of
performance is being achieved and sustained. They can, and should be, established at all levels in
the organization, ideally being cascaded down and most effectively undertaken as team activities
and this is discussed in the section on Performance.
1.4 APPROACHES TO QUALITY

Organizations have continually looked for new ways to improve consistency and quality in their
products and services. Management fads may come and go but many of the underlying ideas
around quality remain the same. Here's how the works of Deming, Juran and Crosby remain at
the heart of quality approaches like TQM and Six Sigma.
1.4.1 TQM Approach

Detail about TQM is described in section 1.4 but here this sub-section is giving TQMs view in
context of approaches to quality. Deming's views on quality are believed by many to have laid
the foundations for Total Quality Management (TQM), however, the works of Feigenbaum,
Ishikawa and Imai have also had an impact.
TQM focuses on achieving quality through engraining the philosophy within an organization,
although it does not form a system or a set of tools through which to achieve this. Companies
adopting a TQM philosophy should see their competitiveness increase, establish a culture of
growth, offer a productive and successful working environment, cut stress and waste and build
teams and partnerships.
The principles of TQM have been laid out in the ISO 9000 family of standards from the
International Organization for Standardization. Adopted by over one million companies in 176
countries worldwide, the standards lay down the requirements of a quality management system,
but not how these should be met.
Eight principles make up the ISO 9000 standards. These are:
i.
Organizations should be consumer focused by understanding their needs and meeting

their requirements
ii.
Strong leadership should ensure the organization understands its purpose and direction
iii.
People at all levels should be involved in the quality process for the organization to reap
the greatest benefit
iv.
A process approach should be taken to activities and any related resources
v.
Interrelated processes should be identified as a system to boost efficiency in meeting

objectives
vi.
Organizations should strive for continual improvement
vii.
Decisions should be based on factual information
viii.
A mutually beneficial relationship should be created between organizations and suppliers
But standards alone are not often not enough for companies to reach their quality goals, hence
the development of more structured processes like six sigma.
1.4.2 Six Sigma

Whereas TQM is a philosophy of quality, Six Sigma is a definitive measurement of quality or at
least that's how it started. Motorola pioneered six sigma over two decades ago and in this time it
has evolved from a simple metric 3.4 defects per one million opportunities, which was often
applied to manufacturing, to a methodology and management system adopted by numerous
business sectors. By aiming for 3.4 defects it diverges from the zero-deficits model proposed by
Crosby, which many see as unattainable and in some cases demotivating.
As Deming said in his 14 principles of quality management, companies should "eliminate
slogans, exhortations, and targets for the workforce asking for zero defects and new levels of
productivity. "Such exhortations only create adversarial relationships, as the bulk of the causes of
low quality and low productivity belong to the system and thus lie beyond the power of the work
force." Sitting at the heart of the Six Sigma philosophy is the DMAIC model for process
improvement; define opportunity, measure performance, analyse opportunity, improve
performance, control performance.
Alternatively the DMADV (define, measure, analyse, design, verify) system is used for the
creation of new processes which fit with the six sigma principles. Motorola believes that even
combining the methodology and the metric is "still not enough to drive desired breakthrough
improvements and results that are sustainable over time", and therefore advocates the use of the
six sigma management systems, which aligns management strategy with improvement efforts.
Companies which have successfully implemented six sigma, such as GE, have reported savings
running into millions of dollars and six sigma is now being combined with lean manufacturing
processes to great effect.
But it is highly unlikely any of these interpretations present the end goal for quality management,
which as the methodologies teach, must always strive for continuous improvement
1.5 SUMMARY
Quality plays very important role in every aspect of software development. It plays key role in
the successful implementation of software. As an attribute of an item, quality refers to
measurable characteristics - things we are able to compare to known standards such as length,
color, electrical properties, and malleability. However, software, largely an intellectual entity, is
more challenging to characterize than physical objects. Nevertheless, measures of a programs
characteristics do exist. These properties include cyclomatic complexity, cohesion, number of
function points, lines of code, and many others. When we examine an item based on its
measurable characteristics, two kinds of quality may be encountered: quality of design and
quality of conformance. TQM encourages participation amongst shop floor workers and
managers. TQM is an approach to improving the competitiveness, effectiveness and flexibility of
an organization for the benefit of all stakeholders. It is a way of planning, organizing and
understanding each activity, and of removing all the wasted effort and energy that is routinely
spent in organizations. It ensures the leaders adopt a strategic overview of quality and focus on
prevention not detection of problems. All senior managers must demonstrate their seriousness
and commitment to quality, and middle managers must, as well as demonstrating their
commitment, ensure they communicate the principles, strategies and benefits to the people for
whom they have responsibility. Only then will the right attitudes spread throughout the
organization.
Assignment-Module 1
1. Quality is __________
a. Conformance to specification
b. Meeting customer needs
c. Both of them
d. None of them
2. Which__________ model shows the direct relationship with quality conformance.

a. Waterfall
b. Spiral
c. Ludvall-Juran
d. None of the above
3. __________ states that quality is __________.

a. Phillip Crosby, free
b. Stalling, expensive
c. Dromey, conformance
d. Lexus, failure
4. The objective of TQM is __________.

a. Do the right things, right the first time, every time
b. Do the right time, right the first things, every things
c. Do the right time, right the first things, every right
5. __________ quality system also requires the establishment of procedures that

standardize the way an organization handles the diagnostic and evaluation phases.
a. ISO/IEC 9126
b. ISO 9001
c. IEEE
d. ISO 9000
6. Mistakes may be made by people, but most of them are caused, or at least permitted, by
faulty systems and processes is the principle of __________ .
a. Quality
b. TQM
c. Six Sigma
d. ISO 9000
7.
The principles of TQM have been laid out to __________ principles made up
__________ standards.
a. Six, ISO 9000
b. Two, ISO 9126
c. Eight, ISO 9001
d. Eight, ISO 9000
8. TQM__________ of quality and Six sigma __________ of quality.

a. Philosophy, definitive measurement
b. Conformance, requirements
c. Measurement, performance
d. None of them
9. Deming suggested ___________ principles of quality management.

a. Ten
b. Six
c. Three
d. Fourteen
10. Six Sigma philosophy is the ___________ model for process improvement.
a. DMAIC
b. ISO 9126
c. Mc call
d. ISO 9000
Key - Module 1
1. c
2. c
3. a
4. a
5. d
6. b
7. d
8. a
9. d
10. a
CHAPTER 2 : SOFTWARE QUALITY

2.1 SOFTWARE DEVELOPMENT PROCESS
The large and growing body of software development organizations implements process
methodologies. Many of them are in the defense industry, which in the U.S. requires a rating
based on 'process models' to obtain contracts. The international standard for describing the
method of selecting, implementing and monitoring the life cycle for software is ISO/IEC 12207.
A decades-long goal has been to find repeatable, predictable processes that improve productivity
and quality. Some try to systematize or formalize the seemingly unruly task of writing software.
Others apply project management techniques to writing software. Without project management,
software projects can easily be delivered late or over budget. With large numbers of software
projects not meeting their expectations in terms of functionality, cost, or delivery schedule,
effective project management appears to be lacking. Organizations may create a Software
Engineering Process Group (SEPG), which is the focal point for process improvement.
Composed of line practitioners who have varied skills, the group is at the center of the
collaborative effort of everyone in the organization who is involved with software engineering
process improvement.
2.1.1 System/Information Engineering and Modeling

As software is always of a large system (or business), work begins by establishing the
requirements for all system elements and then allocating some subset of these requirements to
software. This system view is essential when the software must interface with other elements
such as hardware, people and other resources. System is the basic and very critical requirement
for the existence of software in any entity. So if the system is not in place, the system should be
engineered and put in place. In some cases, to extract the maximum output, the system should be
re-engineered and spruced up. Once the ideal system is engineered or tuned, the development
team studies the software requirement for the system.
2.1.2 Software Development Life Cycle

A software development process, also known as a software development life cycle (SDLC), is a
structure imposed on the development of a software product. A software development process or
life cycle is a structure imposed on the development of a software product. Similar terms include
software life cycle and software process. There are several models for such processes, each
describing approaches to a variety of tasks or activities that take place during the process. Some
people consider a life-cycle model a more general term and a software development process a
more specific term. For example, there are many specific software development processes that
'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle
processes. It aims to be the standard that defines all the tasks required for developing and
maintaining software.
2.1.3 Processes
More and more software development organizations implement process methodologies. The
Capability Maturity Model (CMM) is one of the leading models. Independent assessments can be
used to grade organizations on how well they create software according to how they define and
execute their processes. There are dozens of others, with other popular ones being ISO 9000, ISO
15504, and Six Sigma.There are several models for such processes, each describing approaches
to a variety of tasks or activities that take place during the process.
2.1.4 Software development activities
The activities of the software development process are represented in the form of waterfall model
in above figure. There are several other models to represent this process.
2.1.5 Process Activities/Steps

Software Engineering processes are composed of many activities, notably the following:
2.1.5.1 System/Information Engineering and Modeling

As software is always of a large system (or business), work begins by establishing the
requirements for all system elements and then allocating some subset of these requirements to
software. This system view is essential when the software must interface with other elements
such as hardware, people and other resources. System is the basic and very critical requirement
for the existence of software in any entity. So if the system is not in place, the system should be
engineered and put in place. In some cases, to extract the maximum output, the system should be
re-engineered and spruced up. Once the ideal system is engineered or tuned, the development
team studies the software requirement for the system.
2.1.5.2 Requirements Analysis

Extracting the requirements of a desired software product is the first task in creating it. While
customers probably believe they know what the software is to do, it may require skill and
experience in software engineering to recognize incomplete, ambiguous or contradictory
requirements. Customers typically have an abstract idea of what they want as an end result, but
not what software should do. Skilled and experienced software engineers recognize incomplete,
ambiguous, or even contradictory requirements at this point. Frequently demonstrating live code
may help reduce the risk that the requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of
unclear requirements at the start of development. If the development is done externally, this
document can be considered a legal document so that if there are ever disputes, any ambiguity of
what was promised to the client can be clarified.
2.1.5.3 Specification
Specification is the task of precisely describing the software to be written, in a mathematically
rigorous way. In practice, most successful specifications are written to understand and fine-tune
applications that were already well-developed, although safety-critical software systems are
often carefully specified prior to application development. Specifications are most important for
external interfaces that must remain stable.
2.1.5.4 Software architecture

The architecture of a software system refers to an abstract representation of that system.
Architecture is concerned with making sure the software system will meet the requirements of
the product, as well as ensuring that future requirements can be addressed.
2.1.5.5 Implementation
Reducing a design to code may be the most obvious part of the software engineering ob, but it is
not necessarily the largest portion.
2.1.5.6 Testing
Testing of parts of software, especially where code by two different engineers must work
together, falls to the software engineer. Different testing methodologies are available to unravel
the bugs that were committed during the previous phases. Different testing tools and
methodologies are already available. Some companies build their own testing tools that are tailor
made for their own development operations.
2.1.5.7 Documentation
An important task is documenting the internal design of software for the purpose of future
maintenance and enhancement. This may also include the writing of an API, be it external or
internal. The software engineering process chosen by the developing team will determine how
much internal documentation (if any) is necessary. Plan-driven models (e.g., Waterfall) generally
produce more documentation than agile models.
2.1.5.8 Training and Support

A large percentage of software projects fail because the developers fail to realize that it doesn't
matter how much time and planning a development team puts into creating software if nobody in
an organization ends up using it. People are occasionally resistant to change and avoid venturing
into an unfamiliar area, so as a part of the deployment phase, its very important to have training
classes for the most enthusiastic software users (build excitement and confidence), shifting the
training towards the neutral users intermixed with the avid supporters, and finally incorporate the
rest of the organization into adopting the new software. Users will have lots of questions and
software problems which lead to the next phase of software.
2.1.5.9 Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new
requirements can take far more time than the initial development of the software. The software
will definitely undergo change once it is delivered to the customer. There can be many reasons
for this change to occur. Change could happen because of some unexpected input values into the
system. In addition, the changes in the system could directly affect the software operations. The
software should be developed to accommodate changes that could happen during the post
implementation period.
Not only may it be necessary to add code that does not fit the original design but just determining
how software works at some point after it is completed may require significant effort by a
software engineer. About 60% of all software engineering work is maintenance, but this statistic
can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to
do new things, which in many ways can be considered new work.
2.2 SOFTWARE DEVELOPMENT MODELS OR PROCESS

MODEL
A decades-long goal has been to find repeatable, predictable processes or methodologies that
improve productivity and quality. Some try to systematize or formalize the seemingly unruly task
of writing software. Others apply project management techniques to writing software. Without
project management, software projects can easily be delivered late or over budget. With large
numbers of software projects not meeting their expectations in terms of functionality, cost, or
delivery schedule, effective project management is proving difficult. Several models exist to
streamline the development process. Each one has its pros and cons, and it's up to the
development team to adopt the most appropriate one for the project. Sometimes a combination of
the models may be more suitable.
2.2.1 Waterfall Model

The best-known and oldest process is the waterfall model, where developers follow these steps in
order. They state requirements, analyze them, design a solution approach, architect a software
framework for that solution, develop code, test, deploy, and maintain. These steps are described
in detail in section 2.1. After each step is finished, the process proceeds to the next step. The
waterfall model shows a process, where developers are to follow these phases in order:
i.
Requirements specification (Requirements analysis)
ii.
Software design
iii.
Implementation and Integration
iv.
Testing (or Validation)
v.
Deployment (or Installation)
vi.
Maintenance
In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may
occur before moving to the next phase which allows for the possibility of changes (which may
involve a formal change control process). Reviews may also be employed to ensure that the
phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the
project must pass through to move to the next phase. Waterfall discourages revisiting and
revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has
been a source of criticism by supporters of other more "flexible" models.
2.2.2 Prototyping Model

This is a cyclic version of the linear model. In this model, once the requirement analysis is done
and the design for a prototype is made, the development process gets started. Once the prototype
is created, it is given to the customer for evaluation. The customer tests the package and gives
his/her feed back to the developer who refines the product according to the customers exact
expectation. After a finite number of iterations, the final software package is given to the
customer. In this methodology, the software is evolved as a result of periodic shuttling of
information between the customer and developer. This is the most popular development model in
the contemporary IT industry. Most of the successful software products have been developed
using this model as it is very difficult (even for a whiz kid!) to comprehend all the
requirements of a customer in one shot. There are many variations of this model skewed with
respect to the project management styles of the companies. New versions of a software product
evolve as a result of prototyping.
2.2.3 Spiral model

The key characteristic of a Spiral model is risk management at regular stages in the development
cycle. In 1988, Barry Boehm published a formal software system development "spiral model,"
which combines some key aspect of the waterfall model and rapid prototyping methodologies,
but provided emphasis in a key area many felt had been neglected by other methodologies:
deliberate iterative risk analysis, particularly suited to large-scale complex systems.
The Spiral is visualized as a process passing through some number of iterations, with the four
quadrant diagram representative of the following activities:
i.
formulate plans to: identify software targets, selected to implement the program, clarify
the project development restrictions;
ii.
Risk analysis: an analytical assessment of selected programs, to consider how to identify

and eliminate risk;
iii.
the implementation of the project: the implementation of software development and

verification;
Risk-driven spiral model, emphasizing the conditions of options and constraints in order to
support software reuse, software quality can help as a special goal of integration into the product
development. However, the spiral model has some restrictive conditions, as follows:
i.
The spiral model emphasizes risk analysis, and thus requires customers to accept this
analysis and act on it. This requires both trust in the developer as well as the willingness
to spend more to fix the issues, which is the reason why this model is often used for
large-scale internal software development.
ii.
If the implementation of risk analysis will greatly affect the profits of the project, the
spiral model should not be used.
iii.
Software developers have to actively look for possible risks, and analyze it accurately for
the spiral model to work.
The first stage is to formulate a plan to achieve the objectives with these constraints, and then
strive to find and remove all potential risks through careful analysis and, if necessary, by
constructing a prototype. If some risks can not be ruled out, the customer has to decide whether
to terminate the project or to ignore the risks and continue anyway. Finally, the results are
evaluated and the design of the next phase begins.
2.2.4 Strength and Weakness of Waterfall, Prototype and Spiral Model

(i) Waterfall Model
Strengths
Emphasizes completion of one phase before moving on
Emphasises early planning, customer input, and design
Emphasises testing as an integral part of the life cycle Provides quality gates at each life cycle
phase
Weakness:
Depends on capturing and freezing requirements early in the life cycle
Depends on separating requirements from design
Feedback is only from testing phase to any previous stage
Not feasible in some organizations
Emphasises products rather than processes
(ii) Prototyping Model

Strengths
Requirements can be set earlier and more reliably
Requirements can be communicated more clearly and completely between developers and
clients
Requirements and design options can be investigated quickly and with low cost
More requirements and design faults are caught early
Weakness
Requires a prototyping tool and expertise in using it a cost for the development organization
The prototype may become the production system
(iii) Spiral Model

Strengths
It promotes reuse of existing software in early stages of development
Allows quality objectives to be formulated during development
Provides preparation for eventual evolution of the software product
Eliminates errors and unattractive alternatives early.
It balances resource expenditure.
Doesnt involve separate approaches for software development and software maintenance.
Provides a viable framework for integrated Hardware-software system development.
Weakness
This process needs or usually associated with Rapid Application Development, which is very
difficult practically.
The process is more difficult to manage and needs a very different approach as opposed to the
waterfall model (Waterfall model has management techniques like GANTT charts to assess)
2.2.5 Iterative processes

Iterative development prescribes the construction of initially small but ever larger portions of a
software project to help all those involved to uncover important issues early before problems or
faulty assumptions can lead to disaster. Iterative processes are preferred by commercial
developers because it allows a potential of reaching the design goals of a customer who does not
know how to define what he wants.
Agile software development processes are built on the foundation of iterative development. To
that foundation they add a lighter, more people-centric viewpoint than traditional approaches.
Agile processes use feedback, rather than planning, as their primary control mechanism. The
feedback is driven by regular tests and releases of the evolving software.
Agile processes seem to be more efficient than older methodologies, using less programmer time
to produce more functional, higher quality software, but have the drawback from a business
perspective that they do not provide long-term planning capability. In essence, they say that they
will provide the most bang for the buck, but won't say exactly when that bang will be.
Extreme Programming, XP, is the best-known agile process. In XP, the phases are carried out in
extremely small (or "continuous") steps compared to the older, "batch" processes. The
(intentionally incomplete) first pass through the steps might take a day or a week, rather than the
months or years of each complete step in the Waterfall model. First, one writes automated tests,
to provide concrete goals for development. Next is coding (by a pair of programmers), which is
complete when all the tests pass, and the programmers can't think of any more tests that are
needed. Design and architecture emerge out of refactoring, and come after coding. Design is
done by the same people who do the coding. The incomplete but functional system is deployed
or demonstrated for the users (at least one of which is on the development team). At this point,
the practitioners start again on writing tests for the next most important part of the system.
While Iterative development approaches have their advantages, software architects are still faced
with the challenge of creating a reliable foundation upon which to develop. Such a foundation
often requires a fair amount of upfront analysis and prototyping to build a development model.
The development model often relies upon specific design patterns and entity relationship
diagrams (ERD). Without this upfront foundation, Iterative development can create long term
challenges that are significant in terms of cost and quality.
Critics of iterative development approaches point out that these processes place what may be an
unreasonable expectation upon the recipient of the software: that they must possess the skills and
experience of a seasoned software developer. The approach can also be very expensive, akin to...
"If you don't know what kind of house you want, let me build you one and see if you like it. If
you don't, we'll tear it all down and start over." A large pile of building-materials, which are now
scrap, can be the final result of such a lack of up-front discipline. The problem with this criticism
is that the whole point of iterative programming is that you don't have to build the whole house
before you get feedback from the recipient. Indeed, in a sense conventional programming places
more of this burden on the recipient, as the requirements and planning phases take place entirely
before the development begins, and testing only occurs after development is officially over.
2.2.6 Rapid Application Development (RAD) Model

The RAD model is a linear sequential software development process that emphasizes an
extremely short development cycle. The RAD model is a high speed adaptation of the linear
sequential model in which rapid development is achieved by using a component-based
construction approach. Used primarily for information systems applications, the RAD approach
encompasses the following phases:
(i) Business modeling

The information flow among business functions is modeled in a way that answers the following
questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?
(ii) Data modeling

The information flow defined as part of the business modeling phase is refined into a set of data
objects that are needed to support the business. The characteristic (called attributes) of each
object is identified and the relationships between these objects are defined.
(iii) Process modeling

The data objects defined in the data-modeling phase are transformed to achieve the information
flow necessary to implement a business function. Processing the descriptions are created for
adding, modifying, deleting, or retrieving a data object.
(iv) Application generation

The RAD model assumes the use of the RAD tools like VB, VC++, Delphi etc rather than
creating software using conventional third generation programming languages. The RAD model
works to reuse existing program components (when possible) or create reusable components
(when necessary). In all cases, automated tools are used to facilitate construction of the software.
(v) Testing and turnover

Since the RAD process emphasizes reuse, many of the program components have already been
tested. This minimizes the testing and development time.
2.2.7 Component Assembly Model

Object technologies provide the technical framework for a component-based process model for
software engineering. The object oriented paradigm emphasizes the creation of classes that
encapsulate both data and the algorithm that are used to manipulate the data. If properly designed
and implemented, object oriented classes are reusable across different applications and computer
based system architectures. Component Assembly Model leads to software reusability. The
integration/assembly of the already existing software components accelerate the development
process. Nowadays many component libraries are available on the Internet. If the right
components are chosen, the integration aspect is made much simpler.
2.2.8 Process improvement models

2.2.8.1 Capability Maturity Model Integration
The Capability Maturity Model Integration (CMMI) is one of the leading models and based on
best practice. Independent assessments grade organizations on how well they follow their
defined processes, not on the quality of those processes or the software produced. CMMI has
replaced CMM.
2.2.8.2 ISO 9000

ISO 9000 describes standards for a formally organized process to manufacture a product and the
methods of managing and monitoring progress. Although the standard was originally created for
the manufacturing sector, ISO 9000 standards have been applied to software development as
well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result,
only that formalized business processes have been followed.
2.2.8.3 ISO/IEC 15504

ISO/IEC 15504 Information technology Process assessment also known as Software Process
Improvement Capability Determination (SPICE), is a "framework for the assessment of software
processes". This standard is aimed at setting out a clear model for process comparison. SPICE is
used much like CMMI. It models processes to manage, control, guide and monitor software
development. This model is then used to measure what a development organization or project
team actually does during software development. This information is analyzed to identify
weaknesses and drive improvement.
2.2.9 Formal methods

Formal methods are mathematical approaches to solving software (and hardware) problems at
the requirements, specification, and design levels. Formal methods are most likely to be applied
to safety-critical or security-critical software and systems, such as avionics software. Software
safety assurance standards, such as DO-178B, DO-178C, and Common Criteria demand formal
methods at the highest levels of categorization.
For sequential software, examples of formal methods include the B-Method, the specification
languages used in Automated theorem proving, RAISE, VDM, and the Z notation.
Another emerging trend in software development is to write a specification in some form of logic
(usually a variation of FOL), and then to directly execute the logic as though it were a program.
The OWL language, based on Description Logic, is an example. There is also work on mapping
some version of English (or another natural language) automatically to and from logic, and
executing the logic directly. Examples are Attemp to Controlled English, and Internet Business
Logic, which do not seek to control the vocabulary or syntax. A feature of systems that support
bidirectional English-logic mapping and direct execution of the logic is that they can be made to
explain their results, in English, at the business or scientific level.
2.3 SOFTWARE QUALITY ATTRIBUTES
2.3.1 Introduction
Quality attributes are the overall factors that affect run-time behavior, system design, and user
experience. They represent areas of concern that have the potential for application wide impact
across layers and tiers. Some of these attributes are related to the overall system design, while
others are specific to run time, design time, or user centric issues. The extent to which the
application possesses a desired combination of quality attributes such as usability, performance,
reliability, and security indicates the success of the design and the overall quality of the software
application.
When designing applications to meet any of the quality attributes requirements, it is necessary to
consider the potential impact on other requirements. You must analyze the tradeoffs between
multiple quality attributes. The importance or priority of each quality attribute differs from
system to system; for example, interoperability will often be less important in a single use
packaged retail application than in a line of business (LOB) system.
This chapter lists and describes the quality attributes that you should consider when designing
your application. To get the most out of this chapter, use the table below to gain an
understanding of how quality attributes map to system and application quality factors, and read
the description of each of the quality attributes. Then use the sections containing key guidelines
for each of the quality attributes to understand how that attribute has an impact on your design,
and to determine the decisions you must make to addresses these issues. Keep in mind that the
list of quality attributes in this chapter is not exhaustive, but provides a good starting point for
asking appropriate questions about your architecture.
2.3.2 Common Quality Attributes

The following table describes the quality attributes covered in this chapter. It categorizes the
attributes in four specific areas linked to design, runtime, system, and user qualities. Use this
table to understand what each of the quality attributes means in terms of your application design.
Category
Quality
attribute
Description
Conceptual integrity defines the consistency and coherence of the
Design
Conceptual
overall design. This includes the way that components or modules
Integrity
are designed, as well as factors such as coding style and variable

naming.
Qualities
Maintainability is the ability of the system to undergo changes
Maintainability with a degree of ease. These changes could impact components,
services, features, and interfaces when adding or changing the
functionality,
fixing
errors,
and
meeting
new
business
requirements.
Reusability defines the capability for components and subsystems
Reusability
to be suitable for use in other applications and in other scenarios.

Reusability minimizes the duplication of components and also the
implementation time.
Availability defines the proportion of time that the system is
functional and working. It can be measured as a percentage of the
Availability
total system downtime over a predefined period. Availability will

be affected by system errors, infrastructure problems, malicious
attacks, and system load.
Interoperability is the ability of a system or different systems to
operate
successfully
by
communicating
and
exchanging
Interoperability information with other external systems written and run by

external parties. An interoperable system makes it easier to
exchange and reuse information internally as well as externally.
Run-time
Qualities
Manageability
Manageability defines how easy it is for system administrators to

manage the application, usually through sufficient and useful
instrumentation exposed for use in monitoring systems and for
debugging and performance tuning.
Performance is an indication of the responsiveness of a system to
execute any action within a given time interval. It can be measured
Performance
in terms of latency or throughput. Latency is the time taken to

respond to any event. Throughput is the number of events that take
place within a given amount of time.
Reliability
Reliability is the ability of a system to remain operational over

time. Reliability is measured as the probability that a system will
not fail to perform its intended functions over a specified time

interval.
Scalability is ability of a system to either handle increases in load
Scalability
without impact on the performance of the system, or the ability to

be readily enlarged.
Security is the capability of a system to prevent malicious or
Security
accidental actions outside of the designed usage, and to prevent

disclosure or loss of information. A secure system aims to protect
assets and prevent unauthorized modification of information.
Supportability is the ability of the system to provide information
Supportability
helpful for identifying and resolving issues when it fails to work

correctly.
System
Testability is a measure of how easy it is to create test criteria for
Qualities
the system and its components, and to execute these tests in order
Testability
to determine if the criteria are met. Good testability makes it more

likely that faults in a system can be isolated in a timely and
effective manner.
Usability defines how well the application meets the requirements
User
Qualities
Usability
of the user and consumer by being intuitive, easy to localize and

globalize, providing good access for disabled users, and resulting
in a good overall user experience.
The following sections describe each of the quality attributes in more detail, and provide
guidance on the key issues and the decisions you must make for each one:
Availability
Conceptual Integrity
Interoperability
Maintainability
Manageability
Performance
Reliability
Reusability
Scalability
Security
Supportability
Testability
User Experience / Usability
Availability
Availability defines the proportion of time that the system is functional and working. It can be
measured as a percentage of the total system downtime over a predefined period. Availability
will be affected by system errors, infrastructure problems, malicious attacks, and system load.
The key issues for availability are:
A physical tier such as the database server or application server can fail or become
unresponsive, causing the entire system to fail. Consider how to design failover support for
the tiers in the system. For example, use Network Load Balancing for Web servers to
distribute the load and prevent requests being directed to a server that is down. Also, consider
using a RAID mechanism to mitigate system failure in the event of a disk failure. Consider if
there is a need for a geographically separate redundant site to failover to in case of natural
disasters such as earthquakes or tornados.
Denial of Service (DoS) attacks, which prevent authorized users from accessing the system,
can interrupt operations if the system cannot handle massive loads in a timely manner, often
due to the processing time required, or network configuration and congestion. To minimize
interruption from DoS attacks, reduce the attack surface area, identify malicious behavior,
use application instrumentation
to
expose unintended behavior,
and implement
comprehensive data validation. Consider using the Circuit Breaker or Bulkhead patterns to
increase system resiliency.
Inappropriate use of resources can reduce availability. For example, resources acquired too
early and held for too long cause resource starvation and an inability to handle additional
concurrent user requests.
Bugs or faults in the application can cause a system wide failure. Design for proper exception
handling in order to reduce application failures from which it is difficult to recover.
Frequent updates, such as security patches and user application upgrades, can reduce the
availability of the system. Identify how you will design for run-time upgrades.
A network fault can cause the application to be unavailable. Consider how you will handle
unreliable network connections; for example, by designing clients with occasionallyconnected capabilities.
Consider the trust boundaries within your application and ensure that subsystems employ
some form of access control or firewall, as well as extensive data validation, to increase
resiliency and availability.
Conceptual Integrity
Conceptual integrity defines the consistency and coherence of the overall design. This includes
the way that components or modules are designed, as well as factors such as coding style and
variable naming. A coherent system is easier to maintain because you will know what is
consistent with the overall design. Conversely, a system without conceptual integrity will
constantly be affected by changing interfaces, frequently deprecating modules, and lack of
consistency in how tasks are performed. The key issues for conceptual integrity are:
Mixing different areas of concern within your design. Consider identifying areas of
concern and grouping them into logical presentation, business, data, and service layers as
appropriate.
Inconsistent or poorly managed development processes. Consider performing an
Application Lifecycle Management (ALM) assessment, and make use of tried and tested
development tools and methodologies.
Lack of collaboration and communication between different groups involved in the
application lifecycle. Consider establishing a development process integrated with tools
to facilitate process workflow, communication, and collaboration.
Lack of design and coding standards. Consider establishing published guidelines for
design and coding standards, and incorporating code reviews into your development
process to ensure guidelines are followed.
Existing (legacy) system demands can prevent both refactoring and progression toward a
new platform or paradigm. Consider how you can create a migration path away from
legacy technologies, and how to isolate applications from external dependencies. For
example, implement the Gateway design pattern for integration with legacy systems.
Interoperability
Interoperability is the ability of a system or different systems to operate successfully by
communicating and exchanging information with other external systems written and run by
external parties. An interoperable system makes it easier to exchange and reuse information
internally as well as externally. Communication protocols, interfaces, and data formats are the
key considerations for interoperability. Standardization is also an important aspect to be
considered when designing an interoperable system. The key issues for interoperability are:
Interaction with external or legacy systems that use different data formats. Consider how you
can enable systems to interoperate, while evolving separately or even being replaced. For
example, use orchestration with adaptors to connect with external or legacy systems and
translate data between systems; or use a canonical data model to handle interaction with a
large number of different data formats.
Boundary blurring, which allows artifacts from one system to defuse into another. Consider
how you can isolate systems by using service interfaces and/or mapping layers. For example,
expose services using interfaces based on XML or standard types in order to support
interoperability with other systems. Design components to be cohesive and have low
coupling in order to maximize flexibility and facilitate replacement and reusability.
Lack of adherence to standards. Be aware of the formal and de facto standards for the domain
you are working within, and consider using one of them rather than creating something new
and proprietary.
Maintainability
Maintainability is the ability of the system to undergo changes with a degree of ease. These
changes could impact components, services, features, and interfaces when adding or changing
the applications functionality in order to fix errors, or to meet new business requirements.
Maintainability can also affect the time it takes to restore the system to its operational status
following a failure or removal from operation for an upgrade. Improving system maintainability
can increase availability and reduce the effects of run-time defects. An applications
maintainability is often a function of its overall quality attributes but there a number of key
issues that can directly affect maintainability:
Excessive dependencies between components and layers, and inappropriate coupling to
concrete classes, prevents easy replacement, updates, and changes; and can cause changes to
concrete classes to ripple through the entire system. Consider designing systems as welldefined layers, or areas of concern, that clearly delineate the systems UI, business processes,
and data access functionality. Consider implementing cross-layer dependencies by using
abstractions (such as abstract classes or interfaces) rather than concrete classes, and minimize
dependencies between components and layers.
The use of direct communication prevents changes to the physical deployment of
components and layers. Choose an appropriate communication model, format, and protocol.
Consider designing a pluggable architecture that allows easy upgrades and maintenance, and
improves testing opportunities, by designing interfaces that allow the use of plug-in modules
or adapters to maximize flexibility and extensibility.
Reliance on custom implementations of features such as authentication and authorization

prevents reuse and hampers maintenance. To avoid this, use the built-in platform functions
and features wherever possible.
The logic code of components and segments is not cohesive, which makes them difficult to
maintain and replace, and causes unnecessary dependencies on other components. Design
components to be cohesive and have low coupling in order to maximize flexibility and
facilitate replacement and reusability.
The code base is large, unmanageable, fragile, or over complex; and refactoring is
burdensome due to regression requirements. Consider designing systems as well defined
layers, or areas of concern, that clearly delineate the systems UI, business processes, and
data access functionality. Consider how you will manage changes to business processes and
dynamic business rules, perhaps by using a business workflow engine if the business process
tends to change. Consider using business components to implement the rules if only the
business rule values tend to change; or an external source such as a business rules engine if
the business decision rules do tend to change.
The existing code does not have an automated regression test suite. Invest in test automation
as you build the system. This will pay off as a validation of the systems functionality, and as
documentation on what the various parts of the system do and how they work together.
Lack of documentation may hinder usage, management, and future upgrades. Ensure that you
provide documentation that, at minimum, explains the overall structure of the application.
Manageability
Manageability defines how easy it is for system administrators to manage the application, usually
through sufficient and useful instrumentation exposed for use in monitoring systems and for
debugging and performance tuning. Design your application to be easy to manage, by exposing
sufficient and useful instrumentation for use in monitoring systems and for debugging and
performance tuning. The key issues for manageability are:
Lack of health monitoring, tracing, and diagnostic information. Consider creating a health
model that defines the significant state changes that can affect application performance, and
use this model to specify management instrumentation requirements. Implement

instrumentation, such as events and performance counters, that detects state changes, and
expose these changes through standard systems such as Event Logs, Trace files, or Windows
Management Instrumentation (WMI). Capture and report sufficient information about errors
and state changes in order to enable accurate monitoring, debugging, and management. Also,
consider creating management packs that administrators can use in their monitoring
environments to manage the application.
Lack of runtime configurability. Consider how you can enable the system behavior to change
based on operational environment requirements, such as infrastructure or deployment
changes.
Lack of troubleshooting tools. Consider including code to create a snapshot of the systems
state to use for troubleshooting, and including custom instrumentation that can be enabled to
provide detailed operational and functional reports. Consider logging and auditing
information that may be useful for maintenance and debugging, such as request details or
module outputs and calls to other systems and services.
Performance
Performance is an indication of the responsiveness of a system to execute specific actions in a
given time interval. It can be measured in terms of latency or throughput. Latency is the time
taken to respond to any event. Throughput is the number of events that take place in a given
amount of time. An applications performance can directly affect its scalability, and lack of
scalability can affect performance. Improving an applications performance often improves its
scalability by reducing the likelihood of contention for shared resources. Factors affecting
system performance include the demand for a specific action and the systems response to the
demand. The key issues for performance are:
Increased client response time, reduced throughput, and server resource over utilization.
Ensure that you structure the application in an appropriate way and deploy it onto a system or
systems that provide sufficient resources. When communication must cross process or tier
boundaries, consider using coarse-grained interfaces that require the minimum number of
calls (preferably just one) to execute a specific task, and consider using asynchronous
communication.
Increased memory consumption, resulting in reduced performance, excessive cache misses
(the inability to find the required data in the cache), and increased data store access. Ensure
that you design an efficient and appropriate caching strategy.
Increased database server processing, resulting in reduced throughput. Ensure that you
choose effective types of transactions, locks, threading, and queuing approaches. Use
efficient queries to minimize performance impact, and avoid fetching all of the data when
only a portion is displayed. Failure to design for efficient database processing may incur
unnecessary load on the database server, failure to meet performance objectives, and costs in
excess of budget allocations.
Increased network bandwidth consumption, resulting in delayed response times and
increased load for client and server systems. Design high performance communication
between tiers using the appropriate remote communication mechanism. Try to reduce the
number of transitions across boundaries, and minimize the amount of data sent over the
network. Batch work to reduce calls over the network.
Reliability
Reliability is the ability of a system to continue operating in the expected way over time.
Reliability is measured as the probability that a system will not fail and that it will perform its
intended function for a specified time interval. The key issues for reliability are:
The system crashes or becomes unresponsive. Identify ways to detect failures and
automatically initiate a failover, or redirect load to a spare or backup system. Also, consider
implementing code that uses alternative systems when it detects a specific number of failed
requests to an existing system.
Output is inconsistent. Implement instrumentation, such as events and performance counters,
that detects poor performance or failures of requests sent to external systems, and expose
information through standard systems such as Event Logs, Trace files, or WMI. Log
performance and auditing information about calls made to other systems and services.
The system fails due to unavailability of other externalities such as systems, networks, and
databases. Identify ways to handle unreliable external systems, failed communications, and
failed transactions. Consider how you can take the system offline but still queue pending
requests. Implement store and forward or cached message-based communication systems that
allow requests to be stored when the target system is unavailable, and replayed when it is
online. Consider using Windows Message Queuing or BizTalk Server to provide a reliable
once-only delivery mechanism for asynchronous requests.
Reusability
Reusability is the probability that a component will be used in other components or scenarios to
add new functionality with little or no change. Reusability minimizes the duplication of
components and the implementation time. Identifying the common attributes between various
components is the first step in building small reusable components for use in a larger system.
The key issues for reusability are:
The use of different code or components to achieve the same result in different places; for
example, duplication of similar logic in multiple components, and duplication of similar logic
in multiple layers or subsystems. Examine the application design to identify common
functionality, and implement this functionality in separate components that you can reuse.
Examine the application design to identify crosscutting concerns such as validation, logging,
and authentication, and implement these functions as separate components.
The use of multiple similar methods to implement tasks that have only slight variation.
Instead, use parameters to vary the behavior of a single method.
Using several systems to implement the same feature or function instead of sharing or
reusing functionality in another system, across multiple systems, or across different
subsystems within an application. Consider exposing functionality from components, layers,
and subsystems through service interfaces that other layers and systems can use. Use
platform agnostic data types and structures that can be accessed and understood on different
platforms.
Scalability
Scalability is ability of a system to either handle increases in load without impact on the
performance of the system, or the ability to be readily enlarged. There are two methods for
improving scalability: scaling vertically (scale up), and scaling horizontally (scale out). To scale
vertically, you add more resources such as CPU, memory, and disk to a single system. To scale
horizontally, you add more machines to a farm that runs the application and shares the load. The
key issues for scalability are:
Applications cannot handle increasing load. Consider how you can design layers and tiers for
scalability, and how this affects the capability to scale up or scale out the application and the
database when required. You may decide to locate logical layers on the same physical tier to
reduce the number of servers required while maximizing load sharing and failover
capabilities. Consider partitioning data across more than one database server to maximize
scale-up opportunities and allow flexible location of data subsets. Avoid stateful components
and subsystems where possible to reduce server affinity.
Users incur delays in response and longer completion times. Consider how you will handle
spikes in traffic and load. Consider implementing code that uses additional or alternative
systems when it detects a predefined service load or a number of pending requests to an
existing system.
The system cannot queue excess work and process it during periods of reduced load.
Implement store-and-forward or cached message-based communication systems that allow
requests to be stored when the target system is unavailable, and replayed when it is online.
Security
Security is the capability of a system to reduce the chance of malicious or accidental actions
outside of the designed usage affecting the system, and prevent disclosure or loss of information.
Improving security can also increase the reliability of the system by reducing the chances of an
attack succeeding and impairing system operation. Securing a system should protect assets and
prevent unauthorized access to or modification of information. The factors affecting system
security are confidentiality, integrity, and availability. The features used to secure systems are
authentication, encryption, auditing, and logging. The key issues for security are:
Spoofing of user identity. Use authentication and authorization to prevent spoofing of user
identity. Identify trust boundaries, and authenticate and authorize users crossing a trust
boundary.
Damage caused by malicious input such as SQL injection and cross-site scripting. Protect
against such damage by ensuring that you validate all input for length, range, format, and
type using the constrain, reject, and sanitize principles. Encode all output you display to
users.
Data tampering. Partition the site into anonymous, identified, and authenticated users and use
application instrumentation to log and expose behavior that can be monitored. Also use
secured transport channels, and encrypt and sign sensitive data sent across the network
Repudiation of user actions. Use instrumentation to audit and log all user interaction for
application critical operations.
Information disclosure and loss of sensitive data. Design all aspects of the application to
prevent access to or exposure of sensitive system and application information.
Interruption of service due to Denial of service (DoS) attacks. Consider reducing session
timeouts and implementing code or hardware to detect and mitigate such attacks.
Supportability
Supportability is the ability of the system to provide information helpful for identifying and
resolving issues when it fails to work correctly. The key issues for supportability are:
Lack of diagnostic information. Identify how you will monitor system activity and
performance. Consider a system monitoring application, such as Microsoft System Center.
Lack of troubleshooting tools. Consider including code to create a snapshot of the systems
state to use for troubleshooting, and including custom instrumentation that can be enabled to
provide detailed operational and functional reports.
Lack of tracing ability. Use common components to provide tracing support in code, perhaps
though Aspect Oriented Programming (AOP) techniques or dependency injection. Enable
tracing in Web applications in order to troubleshoot errors.
Lack of health monitoring. Consider creating a health model that defines the significant state
changes that can affect application performance, and use this model to specify management
instrumentation requirements. Implement instrumentation, such as events and performance
counters, that detects state changes, and expose these changes through standard systems such
as Event Logs, Trace files, or Windows Management Instrumentation (WMI). Capture and
report sufficient information about errors and state changes in order to enable accurate
monitoring, debugging, and management.
Testability
Testability is a measure of how well system or components allow you to create test criteria and
execute tests to determine if the criteria are met. Testability allows faults in a system to be
isolated in a timely and effective manner. The key issues for testability are:
Complex applications with many processing permutations are not tested consistently, perhaps
because automated or granular testing cannot be performed if the application has a
monolithic design. Design systems to be modular to support testing. Provide instrumentation
or implement probes for testing, mechanisms to debug output, and ways to specify inputs
easily. Design components that have high cohesion and low coupling to allow testability of
components in isolation from the rest of the system.
Lack of test planning. Start testing early during the development life cycle. Use mock objects
during testing, and construct simple, structured test solutions.
Poor test coverage, for both manual and automated tests. Consider how you can automate
user interaction tests, and how you can maximize test and code coverage.
Input and output inconsistencies; for the same input, the output is not the same and the output
does not fully cover the output domain even when all known variations of input are provided.
Consider how to make it easy to specify and understand system inputs and outputs to
facilitate the construction of test cases.
User Experience / Usability

The application interfaces must be designed with the user and consumer in mind so that they are
intuitive to use, can be localized and globalized, provide access for disabled users, and provide a
good overall user experience. The key issues for user experience and usability are:
Too much interaction (an excessive number of clicks) required for a task. Ensure you design
the screen and input flows and user interaction patterns to maximize ease of use.
Incorrect flow of steps in multi-step interfaces. Consider incorporating workflows where
appropriate to simplify multi-step operations.
Data elements and controls are poorly grouped. Choose appropriate control types (such as
option groups and check boxes) and lay out controls and content using the accepted UI
design patterns.
Feedback to the user is poor, especially for errors and exceptions, and the application is
unresponsive. Consider implementing technologies and techniques that provide maximum
user interactivity, such as Asynchronous JavaScript and XML (AJAX) in Web pages and
client-side input validation. Use asynchronous techniques for background tasks, and tasks
such as populating controls or performing long-running tasks.
2.4 HIERARCHICAL MODELS OF QUALITY

This section discusses the classical hierarchical models of quality provided by McCall and
Boehm. These models form the basis of most subsequent work in software quality.
2.4.1 What is hierarchical model?

In order to compare quality in different situations, both qualitatively and quantitatively, it is
necessary to establish a model of quality. There have been many models suggested for quality.
Most are hierarchical in nature. In order to examine the nature of hierarchical models, consider
the methods of assessment and reporting used in schools. The progress of a particular student
has generally been recorded under a series of headings, usually subject areas such as Science,
English, Maths and Humanities.
A qualitative assessment is generally made, along with a more quantified assessment. These
measures may be derived from a formal test of examination, continuous assessment of
coursework or a quantified teacher assessment. In practice, the resulting scores are derived from
a whole spectrum of techniques. They range from those which may be regarded as objective and
transferable to those which are simply a more convenient representation of qualitative
judgements. In the past, these have been gathered together to form a traditional school report.
(Table 2.1)
The traditional school report often had an overall mark and grade, a single figure, generally
derived from the mean of the component figures, intended to provide a single measure of
success. In recent years, the assessment of pupils has become considerably more sophisticated
and the model on which the assessment is based has become more complicated. Subjects are
now broken down into skills, each of which is measured and the collective results used to give a
more detailed overall picture. For example, in English, pupils oral skills are considered
alongside their ability to read; written English is further subdivided into an assessment of style,
content and presentation. The hierarchical model requires another level of sophistication in order
to accommodate the changes (Figure 2.1). Much effort is currently being devoted to producing a
broader-based assessment, and in ensuring that qualitative judgements are as accurate and
consistent as possible. The aim is for every pupil to emerge with a broad-based Record of
Achievement alongside their more traditional examination results.
Table 2.1 A traditional school report

Subject
Teachers comments
Term grade Exam mark

(A-E)
(%)
English
Maths
Science
Humanities
Languages
Technology
OVERALL
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. This type of model is illustrated schematically in
Figure 2.2.
Examples of quality criteria typically employed include reliability, security and adaptability.
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?
2.4.2 THE McCALL AND BOEHM MODELS
2.4.2.1 The McCall Model

This model was first proposed by McCall in 1977. It was later adapted and revised as the
MQ model (Watts, 1987). Jim McCall produced this model (Figure 2.3) for the US Air Force
and the intention was to bridge the gap between users and developers. He tried to map the user
view with the developer's priority. The model is aimed at system developers, to be used during
the development process. However, in an early attempt to bridge the gap between users and
developers, the criteria were chosen in an attempt to reflect users view as well as developers
priorities.
Figure 2.3 : Decomposition tree of McCall software quality model

With the perspective of hindsight, the criteria appear to be technically oriented, but they are
described by a series of questions which define them in terms acceptable to non-specialist
managers. The three perspective of model are described as:
Product revision
The product revision perspective identifies quality factors that influence the ability to change the
software product, these factors are:Maintainability, the ability to find and fix a defect.
Flexibility, the ability to make changes required as dictated by the business.
Testability, the ability to Validate the software requirements
Product transition
The product transition perspective identifies quality factors that influence the ability to adapt the
software to new environments:Portability, the ability to transfer the software from one environment to another.
Reusability, the ease of using existing software components in a different context.
Interoperability, the extent, or ease, to which software components work together.
Product operations
The product operations perspective identifies quality factors that influence the extent to which
the software fulfils its specification:Correctness, the functionality matches the specification.
Reliability, the extent to which the system fails.
Efficiency, system resource (including cpu, disk, memory, network) usage.
Integrity, protection from unauthorized access.
Usability, ease of use.
The McCall model, illustrated in Figure 2.4, identifies three areas of software work: product
operation, product revision and product transition. These are summarized in Table 2.2
Table 2.2 The three areas as addressed by McCalls model (1977)

Product operation
requires that it can be learned easily, operated

efficiently and that the results are those required by the
user.
Product revision
is concerned with error correction and adaptation of

the system. This is important because it is generally
considered to be the most costly part of software
development.
Product transition
may not be so important in all applications. However,

the move towards distributed processing and the rapid
rate of change in hardware is likely to increase its
importance.
McCalls model forms the basis for much quality work even today. For example, the MQ model
published by Watts (1987) is heavily based upon the McCall model. The quality characteristics
in this model are described as follows:
Utility is the ease of use of the software.
Integrity is the protection of the program from unauthorized access.
Efficiency is concerned with the use of resources, e.g. processor time, storage.
It falls into two categories: execution efficiency and storage efficiency.
Correctness is the extent to which a program fulfills 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 program, to ensure that it is error-free and meets its
specification.
Portability is the effort required to transfer a program from one environment to another.
Reusability is the ease of reusing software in a different context.
Interoperability is the effort required to complete the system to another system.
This study carried out by the National Computer Centre (NCC). The characteristics and subcharacteristics of McCall model is shown in following figure.
The idea behind McCalls Quality Model is that the quality factors synthesized should provide a
complete software quality picture. The actual quality metric is achieved by answering yes and no
questions that then are put in relation to each other. That is, if answering equally amount of yes
and no on the questions measuring a quality criteria you will achieve 50% on that quality
criteria1. The metrics can then be synthesized per quality criteria, per quality factor, or if relevant
per product or service
2.4.2.2 The Boehm Model

Barry W. Boehm (1978) also defined a hierarchical model of software quality characteristics, in
trying to qualitatively define software quality as a set of attributes and metrics (measurements).
Boehms model was defined to provide a set of well-defined, well-differentiated characteristics
of software quality. The model is hierarchical in nature but the hierarchy is extended, so that
quality criteria are subdivided. The first division is made according to the uses made of the
system. These are classed as general or as is utility, where the as is utilities are a subtype of
the general utilities, roughly equating to the product operation criteria of McCalls model. There
are two levels of actual quality criteria, the intermediate level being further split into primitive
characteristics, which are amenable to measurement. The model is summarized in Figure 2.5
At the highest level of his model, Boehm defined three primary uses (or basic software
requirements), these three primary uses are:As-is utility, the extent to which the as-is software can be used (i.e. ease of use, reliability and
efficiency).
Maintainability, ease of identifying what needs to be changed as well as ease of modification
and retesting.
Portability,
ease
of
changing
software
to
accommodate
new
environment.
These three primary uses had quality factors associated with them , representing the next level of
Boehm's hierarchical model. These quality factors are further broken down into Primitive
constructs that can be measured, for example Testability is broken down into:- accessibility,
communicativeness, structure and self descriptiveness. As with McCall's Quality Model, the
intention is to be able to measure the lowest level of the model.
2.5 PRACTICAL EVALUATION
Correctness was seen as an umbrella property encompassing other attributes. Two types of
correctness were consistently identified. Developers talked in terms of technical correctness,
which included factors such as reliability, maintainability and the traditional software virtues.
Computer users, however, talked of business correctness, of meeting business needs and criteria
such as timeliness, value for money and ease of transition.
This reinforced the existence of different views of quality. It suggests that these developers
emphasized conformance to specification, while users sought fitness for purpose. There was
remarkable agreement between the different organizations as to some of the basic findings.
In particular:
A basic distinction between business and technical correctness.
A recognition that different aspect of quality would influence each other.
The study confirmed that the relationships were often context and even project dependent.
The studies demonstrated that the relationships were often not commutative. Thus although
property A may reinforce property B, property B may not reinforce property A.
Table 2.4 Software quality criteria elicited from a large manufacture in company
Criteria
Definition
Technical
The extent to which a system satisfies its technical specification.
correctness
User correctness
The extent to which a system fulfills a set of objectives agreed

with the user.
Reliability
The extent to which a system performs its intended function
without failure.
Efficiency
The computing resources required by a system to perform a

function.
Integrity
The extent to which data and software are consistent and

accurate across systems.
Security
The extent to which unauthorized access to a system can be

controlled.
Understandability
The ease of understanding code for maintaining and adapting

systems.
Flexibility
The effort required to modify a system.
Ease of interfacing
The effort required to interface one system to another.
Portability
The effort required to transfer a program from one hardware

configuration and/or software environment to another or to
extend the user base.
User consultation
The effectiveness of consultation with users.
Accuracy
The accuracy of the actual output produced, i.e., is it the right

answer?
Timeliness
The extent to which delivery fits with the deadlines and practices
of users.
Time to use
The time for the user to achieve a result.
Appeal
The extent to which a user likes the system.
User flexibility
The extent to which the system can be adapted both to changes

in user requirements and individual taste.
Cost/benefit
The extent to which the system fulfils its cost/benefit

specification both with regard to development costs and business
benefits.
User friendliness
The time to learn how to use the system and ease of use once
learned.
2.5.1 Quality Assurance

Quality assurance (QA) refers to the planned and systematic activities implemented in a quality
system so that quality requirements for a product or service will be fulfilled. It is the systematic
measurement, comparison with a standard, monitoring of processes and an associated feedback
loop that confers error prevention. This can be contrasted with quality control, which is focused
on process outputs.
Two principles included in QA are: Fit for purpose, the product should be suitable for the
intended purpose; and Right first time, mistakes should be eliminated. QA includes
management of the quality of raw materials, assemblies, products and components, services
related to production, and management, production and inspection processes.
Suitable quality is determined by product users, clients or customers, not by society in general. It
is not related to cost and adjectives or descriptors such high and poor are not applicable. For
example, a low priced product may be viewed as having high quality because it is disposable
where another may be viewed as having poor quality because it is not disposable.
2.5.2 Quality Assurance Plan

The objective of quality assurance plan is to develop and design the activities related to quality
control project for the organization. It is a composite document containing all the information
related to the quality control activities. It is used to schedule the reviews and audits for checking
different business components and also to check the correctness of these testing procedures as
defined in the plan. The quality management team is totally responsible to build up the primary
design of the plan. To develop this plan, certain steps are followed, which are described below.
Step 1: To define the quality goals for the processes. These goals will be accepted
unconditionally by the developer and the customer, both. These objectives are to be clearly
described in the plan, so that both the parties can understand easily the scope of the processes.
The developers might also set a standard to define the goals. If possible, the plan can also
describe the quality goals in terms of measurement. This will ultimately help to measure the
performance of the processes in terms of gradation.
Step 2: To define the organization and the roles and responsibilities of the participant activities.
It should include the reporting system for the outcome of the quality reviews. The quality team
should know where to submit the reports, directly to the developers or somebody else. In many
cases, the reports are submitted to the project review team, who in turn delivers the report to the
subsequent departments and keeps it in storage for records. Whatever is the process of reporting,
it should be well defined in the plan to avoid disputes or complications in the submission process
for reviews and audits.
Step 3: The subsidiary quality assurance plan: It includes the list of other related plans
describing project standards, which have references in any of the process. These subsidiary plans
are related to the quality standards of several business components and how they are related to
each other in achieving the collective qualitative objective. This information also helps to
determine the different types of reviews to be done and how often they will be performed.
Normally, the included referenced plans are identified below.
a. Documentation Plan
b. Measurement Plan
c. Risk Measurement Plan
d. Problem Resolution Plan
e. Configuration Management Plan
f. Product Development Plan
g. Test Plan
h. Subcontractor Management Plan etc.
Step 4: To identify the task and activities of the quality control team. Generally, this will include
following reviews:
a. Reviewing project plans to ensure that the project abide by the defined process.
b. Reviewing project to ensure the performance according to the plans.
c. Endorsement of variation from the standard process.
d. Assessing the improvement of the processes.
It is the responsibility of the quality manager, to fix the schedule for the reviews and audits to
conduct quality control. This schedule is also documented within the plan, so that task control
can be done at an individual level. Thus, the entire process of quality control is documented
within the plan. This helps as a guideline for the reviewers and developers, simultaneously.
2.5.3 Quality control

Quality control, or QC for short, is a process by which entities review the quality of all factors
involved in production. This approach places an emphasis on three aspects:
a. Elements such as controls, job management, defined and well managed processes,
performance and integrity criteria, and identification of records
b. Competence, such as knowledge, skills, experience, and qualifications
c. Soft elements, such as personnel integrity, confidence, organizational culture, motivation,
team spirit, and quality relationships.
Controls include product inspection, where every product is examined visually, and often using a
stereo microscope for fine detail before the product is sold into the external market. Inspectors
will be provided with lists and descriptions of unacceptable product defects such as cracks or
surface blemishes for example. Quality control emphasizes testing of products to uncover defects
and reporting to management who make the decision to allow or deny product release, whereas
quality assurance attempts to improve and stabilize production (and associated processes) to
avoid, or at least minimize, issues which led to the defect(s) in the first place.
Figure 2.7: Quality Management, Quality Assurance and Quality Control
2.5.4 Quality Assurance (QA)

The Monitoring and measuring the strength of development process is SQA. QA is the set of
support activities (including facilitation, training, measurement, and analysis) needed to provide
adequate confidence that processes are established and continuously improved to produce
products that meet specifications and are fit for use.
Following are some of the QA activities:
a. System development methodologies
b. Establish and Estimation Process
c. Sets up measurement Programs to evaluate process.
d. System maintenance process
e. Requirements definition process
f. Testing Process and standards
g. Identifies weaknesses in programs and improves them.
h. Management responsibility, frequently performed by staff function.
i. Concerned with all products produced by the process.
2.5.5 Quality Control (QC):

Quality Control is the process by which product quality is compared with applicable standards,
and the action taken when non-conformance is detected. Its main focus is defect detection and
removal. Quality Control is the validation of the Software product with respect to Customer
Requirements and Expectations. It is a process by which product quality is compared with
applicable
standards,
and
the
action
taken
when
non-conformance
is
detected.
These activities begin at the start of the software development process with reviews of
requirements, and continue until all application testing is complete.
It is possible to have quality control without quality assurance. A testing team may be in a place
to conduct system testing at the end of development.
Following are some of the QC activities:
a. Relates to specific product or service.
b. Implements the process
c. Verifies Specific attributes are there or not in product/service.
d. Identifies for correcting defects.
e. Detects, Reports and corrects defects
f. Concerned with specific product.
2.5.6The Following Statements help differentiate Quality Control from Quality

Assurance
Quality Control is concerned with specific Product or Service. And Quality Assurance is
concerned with all of the products that will ever be produced by a process.
QA does not assure quality, rather it creates and ensures the processes are being followed
to assure quality. QC does not control quality, rather it measures quality.
Quality control activities are focused on the deliverable itself. Quality assurance activities
are focused on the processes used to create the deliverable.
Quality Control identifies defects for the primary purpose of correcting defects and also
verifies weather specific attribute(s) are in, or are not in, a specific product or service.
While Quality Assurance identifies weaknesses in processes and improves them. Quality
Assurance sets up measurement programs to evaluate processes.
Quality Control is the responsibility of the Tester. Quality Assurance is a management
responsibility, frequently performed by a staff function.
Quality Assurance is sometimes called quality control because it evaluates whether
quality control is working. While Quality Assurance personnel should never perform
quality control unless it is to validate Quality Control.
Quality Assurance is preventing in Nature while Quality Control is detective in nature.
2.6 SUMMARY
All the different software development models have their own advantages and disadvantages.
Nevertheless, in the contemporary commercial software development world, the fusion of all
these methodologies is incorporated. Timing is very crucial in software development. If a delay
happens in the development phase, the market could be taken over by the competitor. Also if a
bug filled product is launched in a short period of time (quicker than the competitors), it may
affect the reputation of the company. So, there should be a tradeoff between the development
time and the quality of the product. Customers dont expect a bug free product but they expect a
user-friendly product that they can give a thumbs-up to.
The better understanding about quality can be achieved by study of quality models. The initial
quality models were in hierarchical order. These hierarchies provide better perspective about
quality characteristics. The model proposed by McCall and Bohem fall in above category. The
perspectives in McCall model are- Product revision (ability to change), Product transition
(adaptability to new environments) and Product operations (basic operational characteristics). In
total McCall identified the 11 quality factors broken down by the 3 perspectives, as listed above.
For each quality factor McCall defined one or more quality criteria (a way of measurement), in
this way an overall quality assessment could be made of a given software product by evaluating
the criteria for each factor. Boehms model was defined to provide a set of well-defined, welldifferentiated characteristics of software quality.
The model is hierarchical in nature but the
hierarchy is extended, so that quality criteria are subdivided. There are two levels of quality
criteria, the intermediate level being further split into primitive characteristics, which are
amenable to measurement in this model.
Assignment-Module 2
1.
The ___________describing the method of selecting, implementing and monitoring
the life cycle for software.

a. ISO/IEC 12207
b.
ISO/IEC 9126
c. IEEE
d. ISO 9000
2.
SEPG stands for ___________

a. Software Engineering Process Group
b. Software Engineering Product Groups
c. Six sigma Engineering Production Group
d. Software Experienced Product Group
3.
SDLC stands for ___________

a. Software design life cycle
b. Software development life cycle
c. System development life cycle
d. System design life cycle
4.
CMM stands for ___________

a. Capability Maturity Model
b. Capable Maturity Model
c. Complexity Mature Model
d. Capability Maintainable Model
5.
Waterfall model is not suitable for___________

a. Small projects
b. Accommodating changes
c. Complex projects
6.
Which is not a software life cycle model

a. Waterfall model
b. Spiral model
c. Prototyping model
d. Capability Maturity Model
7.
Which model is cyclic version of linear model

a. Waterfall model
b. Spiral Model
c. Prototyping model
d. None of them
8.
Which is the most important feature of spiral model

a. Quality management
b. Risk management
c. Performance management
d. Evolutionary management
9.
Which phase is not available in waterfall model

a. Coding
b. Testing
c. Maintenance
d. Abstraction
10.
What are the hierarchical models

a. Mc call model
b. Boehm model
c. None of them
d. Both of them
Key - Module 2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CHAPTER 3 : SOFTWARE QUALITY ASSURANCE

3.1 IMPLEMENTING IT QUALITY FUNCTION
Effective integration of information technology into an organization's business processes has
become increasingly crucial to prosperity. IT includes such items as the systems software,
application software, computer hardware, networks and databases associated with managing an
organization's information. The chief information officer leads the department that manages most
aspects of an organization's IT. However, when it comes to implementing quality standards in
the IT realm, most CIOs face so many pressures to deliver systems and technologies which meet
the organization's ever-changing needs that quality falls by the wayside. The industry as a whole
has fallen short of delivering technology that people understand and can use. Many of the
problems occur because of the complexity of technology and the rapid pace of change. Neither of
these conditions are likely to abate; in fact, they're accelerating at an alarming rate. If flawless
execution was an elusive goal in the past, it is even more so today. Nevertheless, performance
can be substantially improved by ensuring that tactical decisions to develop and support IT
emphasize quality. Experience tells us that quality improvements in IT delivery and service
support can be achieved by introducing such considerations as user satisfaction, integration and
flexibility early on in the decision process and reinforcing them throughout the review process.
Although there are no perfect solutions, there are standards in these areas below which an
application and its support cannot be allowed to fall.
3.1.1 Past experience

Despite the fact that as an organizational rallying point, total quality management has been
eclipsed by other quality processes, those organizations that embraced the concept surely
benefited from it. Most have made good use of TQM's basic concepts, resulting in greater
customer satisfaction and improved product quality. The challenge for IT is to mine from these
experiences valuable lessons. Some sound TQM concepts include:
Set quality measures and standards on customer or user wants and needs.
Place ultimate responsibility for quality with line organizations, and mobilize quality
networks or communities within these organizations.
Make quality a shared responsibility.
Create clear standards and measurements, e.g., "dashboard measurements," which
provide quality status information clearly and quickly.
Make use of existing process measures and checkpoints wherever possible rather than
introduce new measures.
Incorporate and align quality measures and business objectives.
Do not limit interventions to identifying failures to meet standards; require corrective
action plans based on root cause analysis.
Focus on correcting the process that contributed to failure rather than installing shortterm fixes to problems.
The main challenge lies in leveraging and incorporating these concepts into the critical
components of an IT quality function. The following approach helps define an IT quality
function.
3.1.2 Create a clear mission

The ultimate mission of the IT quality function must be to add value to the organization as a
whole and, in particular, to improve IT quality in every aspect, including applications, the
infrastructure, even the help desk. However, the IT quality function cannot serve as the sole
owner of quality; it must not try to resolve all quality issues alone. Further, it shouldn't operate in
an after-the-fact quality assurance mode. Instead, it should identify issues that impede quality
and facilitate their rapid resolution.
Taking a broad cross-functional perspective of IT quality issues, the mission of the quality
function must:
Provide discipline and rigor to address quality improvements.
Define top quality goals and measures.
Drive consistent, agreed-to quality measures and corresponding management systems.
Identify and prioritize IT quality issues from an end-to-end perspective.

Serve as a focal point for an extended IT quality network comprised of end users and
providers.
Assign issues to owners for resolution, drive root cause analysis, and track results.
Promote knowledge sharing of best practices relative to quality management in IT.
Drive preventive defect activities so that quality does not become an afterthought.
3.1.3 Set specific objectives

Quality objectives need to focus, ultimately, on user satisfaction and key areas problematic to the
IT area. They should answer the question, "What does the IT quality function want to
accomplish?" Sample objectives include: improve user satisfaction, control IT costs, reduce
defects, improve IT infrastructure and application stability, and improve user perception of IT
quality.
3.1.4 Develop simple strategies

Quality strategies should answer the question, "How will we achieve our objectives?" A simple
strategy would be to address only broad, high-priority quality issues that affect the objectives.
Or, the quality function could focus on customer issues rather than internal issues. Another
strategy would be to use a small quality team and an extended quality community rather than
build a large quality organization within the information systems department. To be effective, the
quality function must avoid the tendency to grow a new bureaucracy.
3.1.5 Design a small, focused quality function

The IT quality function must be created with certain design points, which need to include key
aspects, such as:
Size: How large should the quality function be?
Structure: How should the function be organized?

Scope: What should be the focus?
Roles and responsibilities: Who should be responsible for what?
Skills: What kind of talent and capabilities are needed?
Measures: How should performance be tracked?
The quality function should be comprised of a small, focused team within the IT community.
The key is to avoid creating a large, bureaucratic entity, but rather employ a small team that
represents an extended community in the business functions.
The IT quality function should be led by an influential executive reporting directly to the CIO or
the chief financial officer. This will ensure that the new function has the required influence and
can manage across the organization effectively. The small team of quality advocates will report
directly to the quality executive.
The IT quality function should focus on broad, cross-functional quality issues that are high
priority and critical in nature to resolve. From an IT perspective, the scope should include such
areas as application development, networking, databases, data centers and end-user support (help
desk). From a business perspective, the function's responsibilities should include virtually the
entire organization because most business areas will likely have some sort of IT infrastructure or
application.
The IT quality leader will work with business executives and the CIO, while the quality
advocates will work with the extended quality community. The leader's key responsibilities are:
Provide overall leadership in achieving IT quality objectives.
Represent an end-to-end perspective of IT quality issues.
Ensure linkage of IT quality and process improvement activities across the organization.
Communicate clearly the function's mission, objectives, issues, measures, etc.
Include IT quality objectives and initiatives in the IT strategy.
Quality advocates' responsibilities include:

Identify and prioritize IT quality issues.
Drive root cause analysis of IT quality issues.
Assist in creating action plans pursuant to root cause analysis.
Drive preventive actions to eliminate defect replication.
Anticipate and address quality issues in their specific areas.
The IT quality function calls for a high-powered, extremely talented team of "A" players.
Therefore, the quality leader must be able to build and sustain an excellent executive network.
The leader should consistently demonstrate a high sense of urgency and motivate people to
address issues that concern the entire organization. For their part, quality advocates should be
adept at communicating with superiors and peers, analyzing issues and working in crossfunctional teams. The business executives, the CIO and the IT quality leader must agree to a set
of measurements that will track the progress of IT quality initiatives and issues. While
consistency between groups is desirable, it is more important to relate the measures logically to
the activities involved. The quality measures should reflect the items that remain important to
users and those that drive user satisfaction. Each measure should include a target and time frame.
An example of a user-focused measure: User's perception of IT performance (measure), increase
to 75 percent (target), by second quarter 1999 (time frame). User-focused measures should be
based on the user's view of IT quality. However, the IT quality function must also measure the
internal drivers affecting user measures. For example: Number of defects per user (measure),
reduce by 10 percent (target), by fourth quarter 1999 (time frame).
3.2 QUALITY FUNCTION DEPLOYMENT

Quality Function Deployment (QFD) QFD is a planning tool used to fulfill customer expectations.
It is a disciplined approach to product design, engineering, and production and provides in-depth
evaluation of a product. An organization that correctly implements QFD can improve engineering
knowledge, productivity, and quality and reduce costs, product development time, and engineering
changes.
Quality Function Deployment was developed by Yoji Akao in Japan in 1966. By 1972 the power
of the approach had been well demonstrated at the Mitsubishi Heavy Industries Kobe Shipyard
and in 1978 the first book on the subject was published in Japanese and then later translated into
English in 1994. In Akaos words, QFD "is a method for developing a design quality aimed at
satisfying the consumer and then translating the consumer's demand into design targets and
major quality assurance points to be used throughout the production phase. [QFD] is a way to
assure the design quality while the product is still in the design stage." As a very important side
benefit he points out that, when appropriately applied, QFD has demonstrated the reduction of
development time by one-half to one-third.
The 3 main goals in implementing QFD are:
i.
Prioritize spoken and unspoken customer wants and needs.
ii.
Translate these needs into technical characteristics and specifications
iii.
Build and deliver a quality product or service by focusing everybody toward customer
satisfaction.
Since its introduction, Quality Function Deployment has helped to transform the way many
companies:
Plan new products
Design product requirements
Determine process characteristics
Control the manufacturing process
Document already existing product specifications
Quality function deployment focuses on customer expectations or requirements, often referred to

as the voice of the customer. It is employed to translate customer expectations, in terms of specific
requirements, into directions and actions, in terms of engineering characteristics, that can be
deployed through
Product planning
Part development
Process planning
Production planning
Service
Quality function deployment is a team-based management tool in which the customer expectations
are used to drive the product development process. Conflicting characteristics or requirements are
identified early in the QFD process and can be resolved before production. Ultimately the goal of
QFD is to translate often subjective quality criteria into objective ones that can be quantified and
measured and which can then be used to design and manufacture the product. It is a
complimentary method for determining how and where priorities are to be assigned in product
development. The intent is to employ objective procedures in increasing detail throughout the
development of the product.
Organizations today use market research to decide on what to produce to satisfy customer
requirements. Some customer requirements adversely affect others, and customers often cannot
explain their expectations. Confusion and misinterpretation are also a problem while a product
moves from marketing to design to engineering to manufacturing. This activity is where the voice
of the customer becomes lost and the voice of the organization adversely enters the product design.
Instead of working on what the customer expects, work is concentrated on fixing what the
customer does not want. In other words, it is not productive to improve something the customer did
not want initially. By implementing QFD, an organization is guaranteed to implement the voice of
the customer in the final product.
Quality function deployment helps identify new quality technology and job functions to carry out
operations. This tool provides a historic reference to enhance future technology and prevent design
errors. QFD is primarily a set of graphically oriented planning matrices that are used as the basis
for decisions affecting any phase of the product development cycle. Results of QFD are measured
based on the number of design and engineering changes, time to market, cost, and quality. It is
considered by many experts to be a perfect blueprint for concurrent engineering. Quality function
deployment enables the design phase to concentrate on the customer requirements, thereby
spending less time on redesign and modifications. The saved time has been estimated at onethird to one-half of the time taken for redesign and modification using traditional means. This
saving means reduced development cost and also additional income because the product enters
the market sooner.
3.2.1 The QFD Team

When an organization decides to implement QFD, the project manager and team members need
to be able to commit a significant amount of time to it, especially in the early stages. The
priorities, of the projects need to be defined and told to all departments within the organization
so team members can budget their time accordingly. Also, the scope of the project must also be
clearly defined so questions about why the team was formed do not arise. One of the most
important tools in the QFD process is communication.
There are two types of teams - new product or improving an existing product. Teams are
composed of members from marketing, design, quality, finance, and production. The existing
product team usually has fewer members, because the QFD process will only need to be
modified. Time and inter-team communication are two very important things that each team
must utilize to their fullest potential. Using time effectively is the essential resource in getting the
project done on schedule. Using inter-team communication to its fullest extent will alleviate
unforeseen problems and make the project run smoothly.
Team meetings are very important in the QFD process. The team leader needs to ensure that the
meetings are run in the most efficient manner and that the members are kept informed. The
format needs to have some way of measuring how well the QFD process is working at each
meeting and should be flexible, depending on certain situations. The duration of the meeting will
rely on where the teams members are coming from and what needs to be accomplished. These
workshops may have to last for days if people are coming from around the world or for only
hours if everyone is local. There are advantages to shorter meetings, and sometimes a lot more
can be accomplished in a shorter meeting. Shorter meetings allow information to be collected
between times that will ensure that the right information is being entered into the QFD matrix.
Also, they help keep the team focused on a quality improvement goal.
QFD uses some principles from Concurrent Engineering in that cross-functional teams are
involved in all phases of product development. Each of the four phases in a QFD process uses a
matrix to translate customer requirements from initial planning stages through production
control. Each phase, or matrix, represents a more specific aspect of the product's requirements.
Relationships between elements are evaluated for each phase. Only the most important aspects
from each phase are deployed into the next matrix.
Phase 1: Product Planning: Building the House of Quality. 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: Product Design: This 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 specifications 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: Process planning comes next and is led by manufacturing
engineering. During process planning, manufacturing processes are flowcharted and process
parameters (or target values) are documented.
Phase 4: Process Control: And finally, in production planning, performance 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.
3.2.2 Benefits of QFD

Quality function deployment was originally implemented to reduce start-up costs. Organizations
using QFD have reported a reduced product development time. For example, U.S. car
manufacturers of the late 1980s to early 1990s need an average of five years to put a product on the
market, from drawing board to showroom, whereas Honda can put a new product on the market in
two and a half years and Toyota does it in three years. Both organizations credit this reduced time
to the use of QFD. Product quality and, consequently, customer satisfaction improves with QFD
due to numerous factors depicted in Figure 111.
3.2.2.1 Customer Driven

Quality function deployment looks past the usual customer response and attempts to define the
requirements in a set of basic needs, which are compared to all competitive information. All
competitors are evaluated equally from customer and technical perspectives. This information
can then be prioritized using a Pareto diagram. Management can then place resources where they
will be the most beneficial in improving quality. Also, QFD takes the experience and information
that are available within an organization and puts them together as a structured format that is
easy to assimilate. This is important when an organization employee leaves a particular project
and a new employee is hired.
3.2.2.2 Reduces Implementation Time

Fewer engineering changes are needed when using QFD, and, when used properly, all conflicting
design requirements can be identified and addressed prior to production. This results in a reduction
in retooling, operator training, and changes in traditional quality control measures. By using QFD,
critical items are identified and can be monitored from product inception to production. Toyota
reports that the quality of their product has improved by one third since the implementation of
QFD.
CUSTOMER
DRIVEN
Creates focus on customer requirements

Uses competitive information effectively
Prioritizes resources
Identifies items that can be acted upon
Structures resident experience/information
REDUCES
IMPLEMENTATION
TIME
Decreases midstream design change

Limits post introduction problems
Avoids future development redundancies
Identifies future application opportunities
Surfaces missing assumptions
Based on concensus
Creates communication at interfaces
Identifies actions at interfaces
Creates global view out of details
PROMOTES
TEAMWORK
Documents rationale for design

Is easy to assimilate
Adds structure to the information
Adapts to changes (a living document)
Provides framework for sensitivity analysis
PROVIDES
DOCUMENTATION
Figure 3.1: Benefits of QFD
3.2.2.3 Promotes Teamwork

Quality function deployment forces a horizontal deployment of communication channels. Inputs
are required from all facets of an organization from marketing to production to sales, thus ensuring
that the voice of the customer is being met and that each department knows what the other is
doing. This activity avoids misinterpretation, opinions, and miscues. In other words, the left hand
always knows what the right hand is doing. Efficiency and productivity always increase with
enhanced teamwork.
3.2.2.4 Provides Documentation

A data base for future design or process improvements is created. Data that are historically
scattered within operations, frequently lost and often referenced out of context, are now saved in an
orderly manner to serve future needs. This data base also serves as a training tool for new
engineers. Quality function deployment is also very flexible when new information is introduced
or things have to be changed on the QFD matrix.
3.2.3 The Voice of the Customer

Because QFD concentrates on customer expectations and needs, a considerable amount of effort
is put into research to determine customer expectations. This process increases the initial
planning stage of the project definition phase in the development cycle. But the result is a total
reduction of the overall cycle time in bringing to the market a product that satisfies the customer.
The driving force behind QFD is that the customer dictates the attributes of a product. Customer
satisfaction, like quality, is defined as meeting or exceeding customer expectations. Words used by
the customers to describe their expectations are often referred to as the voice of the customer.
Sources for determining customer expectations are focus groups, surveys, complaints, consultants,
standards, and federal regulations. Frequently, customer expectations are vague and general in
nature. It is the job of the QFD team to break down these customer expectations into more specific
customer requirements. Customer requirements must be taken literally and not incorrectly
translated into what organization officials desire.
Quality function deployment begins with marketing to determine what exactly the customer
desires from a product. During the collection of information, the QFD team must continually ask
and answer numerous questions, such as:
What does the customer really want?
What are the customers expectations?
Are the customers expectations used to drive the design process?
What can the design team do to achieve customer satisfaction?
There are many different types of customer information and ways that an organization can
collect data, as shown in Figure 32. The organization can search (solicited) for the information,
or the information can be volunteered (unsolicited) to the organization. Solicited and unsolicited
information can be further categorized into measurable (quantitative) or subjective (qualitative)
data. Furthermore, qualitative information can be found in a routine (structured) manner or
haphazard (random) manner.
Solicited
Unsolicited
Quantitative
Qualitative
Structured
Random
Focus Groups
Complaint Reports
Organizations Standards
Government Regulations
Lawsuits
Trade Visits
Customer Visits
Consultants
Hot Lines
Surveys
Customer Tests
Trade Trials
Preferred Customers
OM Testing
Product Purchase Survey
Customer Audits
Lagging
Sales Force
Training Programs
Conventions
Trade Journals
Trade Shows
Vendors
Suppliers
Academic
Employees
Leading
Figure 3.2: Types of customer information and how to collect it
Customer information, sources, and ways an organization can collect data can be briefly stated as
follows:
Solicited, measurable, and routine data are typically found by customer surveys, market
surveys, and trade trials, working with preferred customers, analyzing products from other
manufacturers, and buying back products from the field. This information tells an
organization how it is performing in the current market.
Unsolicited, measurable, and routine data tend to take the form of customer complaints or
lawsuits. This information is generally disliked; however, it provides valuable learning
information.
Solicited, subjective, and routine data are usually gathered from focus groups. The object of
these focus groups is to find out the likes, dislikes, trends, and opinions about current and
future products.
Solicited, subjective, and haphazard data are usually gathered from trade visits, customers
visits, and independent consultants. These types of data can be very useful; however, they
can also be misleading, depending on the quantity and frequency of information.
Unsolicited, subjective, and haphazard data are typically obtained from conventions, vendors,
suppliers, and employees. This information is very valuable and often relates the true voice
of the customer.
The goal of QFD is not only to meet as many customer expectations and needs as possible, but
also to exceed customer expectations. Each QFD team must make its product either more
appealing than the existing product or more appealing than the product of a competitor. This
situation implies that the team has to introduce an expectation or need in its product that the
customer is not expecting but would appreciate. For example, cup holders were put into
automobiles as an extra bonus, but customers liked them so well that they are now expected in all
new automobiles.
3.3 ORGANIZATION OF INFORMATION

Now that the customer expectations and needs have been identified and researched, the QFD
team needs to process the information. Numerous methods include affinity diagrams,
interrelationship diagrams, tree diagrams, and cause-and-effect diagrams. These methods are
ideal for sorting large amounts of information. The affinity diagram, which is ideally suited for
most QFD applications, is discussed next.
3.3.1 Affinity Diagram
The affinity diagram is a tool that gathers a large amount of data and subsequently organizes the
data into groupings based on their natural interrelationships. An affinity diagram should be
implemented when
Thoughts are too widely dispersed or numerous to organize.
New solutions are needed to circumvent the more traditional ways of problem solving.
Support for a solution is essential for successful implementation.
This method should not be used when the problem is simple or a quick solution is needed. The
team needed to accomplish this goal effectively should be a multidisciplinary one that has the
needed knowledge to delve into the various areas of the problem. A team of six to eight members
should be adequate to assimilate all of the thoughts. Constructing an affinity diagram requires
four simple steps:
Phrase the objective.
Record all responses.
Group the responses.
Organize groups in an affinity diagram.
The first step is to phrase the objective in a short and concise statement. It is imperative that the
statement be as generalized and vague as possible.
The second step is to organize a brainstorming session, in which responses to this statement are
individually recorded on cards and listed on a pad. It is sometimes helpful to write down a
summary of the discussion on the back of cards so that, in the future when the cards are
reviewed, the session can be briefly explained.
Next, all the cards should be sorted by placing the cards that seem to be related into groups.
Then, a card or word is chosen that best describes each related group, which becomes the
heading for each group of responses. Finally, lines are placed around each group of responses
and related clusters are placed near each other with a connecting line.
3.4 HOUSE OF QUALITY

The primary planning tool used in QFD is the house of quality. The house of quality translates the
voice of the customer into design requirements that meet specific target values and matches that
against how an organization will meet those requirements. Many managers and engineers consider
the house of quality to be the primary chart in quality planning. The structure of QFD can be
thought of as a framework of a house, as shown in Figure 3.3.
Interrelationship
between
Technical Descriptors
Relationship between
Requirements and Descriptors
Prioritized Technical
Descriptors
Figure 3.3: House of quality
Prioritized Customer
Requirements
Customer Requirements
(Voice of the Customer)
Technical Descriptors
(Voice of the organization)
The parts of the house of quality are described as follows:

The exterior walls of the house are the customer requirements. On the left side is a listing of
the voice of the customer, or what the customer expects in the product. On the right side are
the prioritized customer requirements, or planning matrix. Listed are items such as customer
benchmarking, customer importance rating, target value, scale-up factor, and sales point.
The ceiling, or second floor, of the house contains the technical descriptors. Consistency of
the product is provided through engineering characteristics, design constraints, and
parameters.
The interior walls of the house are the relationships between customer requirements and
technical descriptors. Customer expectations (customer requirements) are translated into
engineering characteristics (technical descriptors).
The roof of the house is the interrelationship between technical descriptors. Tradeoffs
between similar and/or conflicting technical descriptors are identified.
The foundation of the house is the prioritized technical descriptors. Items such as the
technical benchmarking, degree of technical difficulty, and target value are listed.
This is the basic structure for the house of quality; once this format is understood, any other
QFD matrices are fairly straightforward.
3.5 SQA PLANNING

Planning is one of the most important aspects of Software
Quality Assurance. The entire
operation of the SQA team depends on how well their planning is done. In smaller businesses ,
planning might not really dictate the flow of SQA but in larger businesses, SQA Planning takes
on center stage. Without it, each component or department that works on the application will be
affected and will never function.
SQA Planning tackles almost every aspect of SQAs operation. Through planning, each member
and even non-member of the SQA team is clearly defined. The reason for this is very simple:
when everyone knows their role and boundaries, there is no overlapping of responsibilities and
everyone could concentrate on their roles.
But SQA Planning is not only a document that tells who gets to do the specific task. The stages
in are also detailed. The whole SQA team will be very busy once the actual testing starts but with
SQA, everyones work is clearly laid out. Through planning, the actual state of the application
testing is known.
Again in smaller businesses, the planning maybe limited to the phase of the application testing
but when outlined for corporations, the scenario changes and only through planning that
everyone will know where they are and where they are going in terms of SQA.
SQA Planning is not just a simple document where objectives are written and stages are clearly
stated. Because of the need to standardize software development ensuring the limitation of error,
a scientific approach is recommended in developing an SQA plan. Certain standards such as
IEEE Std 730 or 983.
3.5.1 SQA Plan Content

An SQA Plan is detailed description of the project and its approach for testing. Going with the
standards, an SQA Plan is divided into four sections:
Software Quality Assurance Plan for Software Requirements;
Software Quality Assurance Plan for Architectural Design;
Software Quality Assurance Plan for Detailed Design and Production and;
Software Quality Assurance Plan for Transfer
In the first phase, the SQA team should write in detail the activities related for software
requirements. In this stage, the team will be creating steps and stages on how they will analyze
the software requirements. They could refer to additional documents to ensure the plan works
out.
The second stage of SQA Plan or the SQAP for AD (Architectural Design) the team should
analyze in detail the preparation of the development team for detailed build-up. This stage is a
rough representation of the program but it still has to go through rigorous scrutiny before it
reaches the next stage.
The third phase which tackles the quality assurance plan for detailed design and actual product is
probably the longest among phases. The SQA team should write in detail the tools and approach
they will be using to ensure that the produced application is written according to plan. The team
should also start planning on the transfer phase as well.
The last stage is the QA plan for transfer of technology to the operations. The SQA team should
write their plan on how they will monitor the transfer of technology such as training and support.
3.6 QUALITY TOOLS

Quality pros have many names for these seven basic tools of quality, first emphasized by Kaoru
Ishikawa, a professor of engineering at Tokyo University and the father of quality circles.
Start your quality journey by mastering these tools, and you'll have a name for them too:
"indispensable."
i.
Cause-and-effect diagram (also called Ishikawa or fishbone chart): Identifies many

possible causes for an effect or problem and sorts ideas into useful categories.
ii.
Check sheet: A structured, prepared form for collecting and analyzing data; a generic
tool that can be adapted for a wide variety of purposes.
iii.
Control charts: Graphs used to study how a process changes over time.
iv.
Histogram: The most commonly used graph for showing frequency distributions, or how
often each different value in a set of data occurs.
v.
Pareto chart: Shows on a bar graph which factors are more significant.
vi.
Scatter diagram: Graphs pairs of numerical data, one variable on each axis, to look for a
relationship.
vii.
Stratification: A technique that separates data gathered from a variety of sources so that
patterns can be seen (some lists replace stratification with flowchart or run chart).
i. CauseandEffect Diagram
Also Called:, Fishbone Diagram, Ishikawa Diagram
Variations: cause enumeration diagram, process fishbone, timedelay fishbone, CEDAC (cause
andeffect diagram with the addition of cards), desiredresult fishbone, reverse fishbone diagram
The fishbone diagram identifies many possible causes for an effect or problem. It can be used to
structure a brainstorming session. It immediately sorts ideas into useful categories.
When to Use a Fishbone Diagram
When identifying possible causes for a problem.
Especially when a teams thinking tends to fall into ruts.
Fishbone Diagram Procedure
Materials needed: flipchart or whiteboard, marking pens.
Agree on a problem statement (effect). Write it at the center right of the flipchart or whiteboard.
Draw a box around it and draw a horizontal arrow running to it.
Brainstorm the major categories of causes of the problem. If this is difficult use generic
headings:
Methods
Machines (equipment)
People (manpower)
Materials
Measurement
Environment
Write the categories of causes as branches from the main arrow.
Brainstorm all the possible causes of the problem. Ask: Why does this happen? As each idea is
given, the facilitator writes it as a branch from the appropriate category. Causes can be written in
several places if they relate to several categories.
Again ask why does this happen? about each cause. Write subcauses branching off the
causes. Continue to ask Why? and generate deeper levels of causes. Layers of branches
indicate causal relationships. When the group runs out of ideas, focus attention to places on the
chart where ideas are few.
Fishbone Diagram Example
This fishbone diagram was drawn by a manufacturing team to try to understand the source of
periodic iron contamination. The team used the six generic headings to prompt ideas. Layers of
branches show thorough thinking about the causes of the problem.
Figure 3.4: Fishbone Diagram Example
For example, under the heading Machines, the idea materials of construction shows four
kinds of equipment and then several specific machine numbers.
Note that some ideas appear in two different places. Calibration shows up under Methods as
a factor in the analytical procedure, and also under Measurement as a cause of lab error. Iron
tools can be considered a Methods problem when taking samples or a Manpower problem
with maintenance personnel.
ii. Check Sheet

Also called: defect concentration diagram
A check sheet is a structured, prepared form for collecting and analyzing data. This is a generic
tool that can be adapted for a wide variety of purposes.
When to Use a Check Sheet

When data can be observed and collected repeatedly by the same person or at the same location.
When collecting data on the frequency or patterns of events, problems, defects, defect location,
defect causes, etc.
When collecting data from a production process.
Check Sheet Procedure

Decide what event or problem will be observed. Develop operational definitions.
Decide when data will be collected and for how long.
Design the form. Set it up so that data can be recorded simply by making check marks or Xs or
similar symbols and so that data do not have to be recopied for analysis.
Label all spaces on the form.

Test the check sheet for a short trial period to be sure it collects the appropriate data and is easy
to use.
Each time the targeted event or problem occurs, record data on the check sheet.
Check Sheet Example

The figure below shows a check sheet used to collect data on telephone interruptions. The tick
marks were added as data was collected over several weeks.
Figure 3.5: Check sheet
iii. Control Chart

Also called: statistical process control
The control chart is a graph used to study how a process changes over time. Data are plotted in
time order. A control chart always has a central line for the average, an upper line for the upper
control limit and a lower line for the lower control limit. These lines are determined from
historical data. By comparing current data to these lines, you can draw conclusions about
whether the process variation is consistent (in control) or is unpredictable (out of control,
affected by special causes of variation).
Control charts for variable data are used in pairs. The top chart monitors the average, or the
centering of the distribution of data from the process. The bottom chart monitors the range, or the
width of the distribution. If your data were shots in target practice, the average is where the shots
are clustering, and the range is how tightly they are clustered. Control charts for attribute data are
used singly.
When to Use a Control Chart

When controlling ongoing processes by finding and correcting problems as they occur.
When predicting the expected range of outcomes from a process.
When determining whether a process is stable (in statistical control).
When analyzing patterns of process variation from special causes (non-routine events) or
common causes (built into the process).
When determining whether your quality improvement project should aim to prevent specific
problems or to make fundamental changes to the process.
Control Chart Basic Procedure

Choose the appropriate control chart for your data.
Determine the appropriate time period for collecting and plotting data.
Collect data, construct your chart and analyze the data.
Look for out-of-control signals on the control chart. When one is identified, mark it on the
chart and investigate the cause. Document how you investigated, what you learned, the cause and
how it was corrected.
Out-of-control signals
A single point outside the control limits. In Figure 3-4, point sixteen is above the UCL (upper
control limit).
Two out of three successive points are on the same side of the centerline and farther than 2
from it. In Figure 3-4, point 4 sends that signal.
Four out of five successive points are on the same side of the centerline and farther than 1 from
it. In Figure 3-4, point 11 sends that signal.
A run of eight in a row are on the same side of the centerline. Or 10 out of 11, 12 out of 14 or 16
out of 20. In Figure 3-4, point 21 is eighth in a row above the centerline.
Obvious consistent or persistent patterns that suggest something unusual about your data and
your process.
Figure 3.6: Control Chart: Out-of-Control Signals

Continue to plot data as they are generated. As each new data point is plotted, check for new outof-control signals.
When you start a new control chart, the process may be out of control. If so, the control limits
calculated from the first 20 points are conditional limits. When you have at least 20 sequential
points from a period when the process is operating in control, recalculate control limits.
iv Histogram
A frequency distribution shows how often each different value in a set of data occurs. A
histogram is the most commonly used graph to show frequency distributions. It looks very much
like a bar chart, but there are important differences between them.
When to Use a Histogram
When the data are numerical.
When you want to see the shape of the datas distribution, especially when determining whether
the output of a process is distributed approximately normally.
When analyzing whether a process can meet the customers requirements.
When analyzing what the output from a suppliers process looks like.
When seeing whether a process change has occurred from one time period to another.
When determining whether the outputs of two or more processes are different.
When you wish to communicate the distribution of data quickly and easily to others.
Histogram Construction
Collect at least 50 consecutive data points from a process.
Use the histogram worksheet to set up the histogram. It will help you determine the number of
bars, the range of numbers that go into each bar and the labels for the bar edges. After calculating
W in step 2 of the worksheet, use your judgment to adjust it to a convenient number. For
example, you might decide to round 0.9 to an even 1.0. The value for W must not have more
decimal places than the numbers you will be graphing.
Draw x- and y-axes on graph paper. Mark and label the y-axis for counting data values. Mark
and label the x-axis with the L values from the worksheet. The spaces between these numbers
will be the bars of the histogram. Do not allow for spaces between bars.
For each data point, mark off one count above the appropriate bar with an X or by shading that
portion of the bar.
Histogram Analysis
Before drawing any conclusions from your histogram, satisfy yourself that the process was
operating normally during the time period being studied. If any unusual events affected the
process during the time period of the histogram, your analysis of the histogram shape probably
cannot be generalized to all time periods.
Analyze the meaning of your histograms shape.
v Pareto Chart
Also called: Pareto diagram, Pareto analysis
Variations: weighted Pareto chart, comparative Pareto charts
A Pareto chart is a bar graph. The lengths of the bars represent frequency or cost (time or
money), and are arranged with longest bars on the left and the shortest to the right. In this way
the chart visually depicts which situations are more significant.
When to Use a Pareto Chart

When analyzing data about the frequency of problems or causes in a process.
When there are many problems or causes and you want to focus on the most significant.
When analyzing broad causes by looking at their specific components.
When communicating with others about your data.
Pareto Chart Procedure

Decide what categories you will use to group items.
Decide what measurement is appropriate. Common measurements are frequency, quantity, cost
and time.
Decide what period of time the Pareto chart will cover: One work cycle? One full day? A week?
Collect the data, recording the category each time. (Or assemble data that already exist.)
Subtotal the measurements for each category.
Determine the appropriate scale for the measurements you have collected. The maximum value
will be the largest subtotal from step 5. (If you will do optional steps 8 and 9 below, the
maximum value will be the sum of all subtotals from step 5.) Mark the scale on the left side of
the chart.
Construct and label bars for each category. Place the tallest at the far left, then the next tallest to
its right and so on. If there are many categories with small measurements, they can be grouped as
other.
Steps 8 and 9 are optional but are useful for analysis and communication.
Calculate the percentage for each category: the subtotal for that category divided by the total for
all categories. Draw a right vertical axis and label it with percentages. Be sure the two scales
match: For example, the left measurement that corresponds to one-half should be exactly
opposite 50% on the right scale.
Calculate and draw cumulative sums: Add the subtotals for the first and second categories, and
place a dot above the second bar indicating that sum. To that sum add the subtotal for the third
category, and place a dot above the third bar for that new sum. Continue the process for all the
bars. Connect the dots, starting at the top of the first bar. The last dot should reach 100 percent
on the right scale.
Pareto Chart Examples

Example #1 shows how many customer complaints were received in each of five categories.
Example #2 takes the largest category, documents, from Example #1, breaks it down into six
categories of document-related complaints, and shows cumulative values.
If all complaints cause equal distress to the customer, working on eliminating document-related
complaints would have the most impact, and of those, working on quality certificates should be
most fruitful.
Figure 3.7: Example #1
Figure 3.8: Example #2
vi. Scatter Diagram

Also called: scatter plot, XY graph
The scatter diagram graphs pairs of numerical data, with one variable on each axis, to look for a
relationship between them. If the variables are correlated, the points will fall along a line or
curve. The better the correlation, the tighter the points will hug the line.
When to Use a Scatter Diagram

When you have paired numerical data.
When your dependent variable may have multiple values for each value of your independent
variable.
When trying to determine whether the two variables are related, such as
When trying to identify potential root causes of problems.
After brainstorming causes and effects using a fishbone diagram, to determine objectively
whether a particular cause and effect are related.
When determining whether two effects that appear to be related both occur with the same cause.
When testing for autocorrelation before constructing a control chart.
Scatter Diagram Procedure

Collect pairs of data where a relationship is suspected.
Draw a graph with the independent variable on the horizontal axis and the dependent variable on
the vertical axis. For each pair of data, put a dot or a symbol where the x-axis value intersects the
y-axis value. (If two dots fall together, put them side by side, touching, so that you can see both.)
Look at the pattern of points to see if a relationship is obvious. If the data clearly form a line or a
curve, you may stop. The variables are correlated. You may wish to use regression or correlation
analysis now. Otherwise, complete steps 4 through 7.
Divide points on the graph into four quadrants. If there are X points on the graph,
Count X/2 points from top to bottom and draw a horizontal line.
Count X/2 points from left to right and draw a vertical line.
If number of points is odd, draw the line through the middle point.
Count the points in each quadrant. Do not count points on a line.
Add the diagonally opposite quadrants. Find the smaller sum and the total of points in all
quadrants.
A = points in upper left + points in lower right
B = points in upper right + points in lower left
Q = the smaller of A and B
N=A+B
Look up the limit for N on the trend test table.
If Q is less than the limit, the two variables are related.
If Q is greater than or equal to the limit, the pattern could have occurred from random chance.
Figure 3.9: Scatter Diagram Example

The ZZ-400 manufacturing team suspects a relationship between product purity (percent purity)
and the amount of iron (measured in parts per million or ppm). Purity and iron are plotted against
each other as a scatter diagram, as shown in the figure below.
There are 24 data points. Median lines are drawn so that 12 points fall on each side for both
percent purity and ppm iron.
To test for a relationship, they calculate:
A = points in upper left + points in lower right = 9 + 9 = 18
B = points in upper right + points in lower left = 3 + 3 = 6
Q = the smaller of A and B = the smaller of 18 and 6 = 6
N = A + B = 18 + 6 = 24
Then they look up the limit for N on the trend test table. For N = 24, the limit is 6.
Q is equal to the limit. Therefore, the pattern could have occurred from random chance, and no
relationship is demonstrated.
Figure 3.10 Scatter Diagram Example
Scatter Diagram Considerations

Here are some examples of situations in which might you use a scatter diagram:
Variable A is the temperature of a reaction after 15 minutes. Variable B measures the color of the
product. You suspect higher temperature makes the product darker. Plot temperature and color
on a scatter diagram.
Variable A is the number of employees trained on new software, and variable B is the number of
calls to the computer help line. You suspect that more training reduces the number of calls. Plot
number of people trained versus number of calls.
To test for autocorrelation of a measurement being monitored on a control chart, plot this pair of
variables: Variable A is the measurement at a given time. Variable B is the same measurement,
but at the previous time. If the scatter diagram shows correlation, do another diagram where
variable B is the measurement two times previously. Keep increasing the separation between the
two times until the scatter diagram shows no correlation.
Even if the scatter diagram shows a relationship, do not assume that one variable caused the
other. Both may be influenced by a third variable.
When the data are plotted, the more the diagram resembles a straight line, the stronger the
relationship.
If a line is not clear, statistics (N and Q) determine whether there is reasonable certainty that a
relationship exists. If the statistics say that no relationship exists, the pattern could have occurred
by random chance.
If the scatter diagram shows no relationship between the variables, consider whether the data
might be stratified.
If the diagram shows no relationship, consider whether the independent (x-axis) variable has
been varied widely. Sometimes a relationship is not apparent because the data dont cover a wide
enough range.
Think creatively about how to use scatter diagrams to discover a root cause.
Drawing a scatter diagram is the first step in looking for a relationship between variables.
vii. Stratification
Stratification is a technique used in combination with other data analysis tools. When data from a
variety of sources or categories have been lumped together, the meaning of the data can be
impossible to see. This technique separates the data so that patterns can be seen.
When to Use Stratification
Before collecting data.
When data come from several sources or conditions, such as shifts, days of the week, suppliers
or population groups.
When data analysis may require separating different sources or conditions.
Stratification Procedure
Before collecting data, consider which information about the sources of the data might have an
effect on the results. Set up the data collection so that you collect that information as well.
When plotting or graphing the collected data on a scatter diagram, control chart, histogram or
other analysis tool, use different marks or colors to distinguish data from various sources. Data
that are distinguished in this way are said to be stratified.
Analyze the subsets of stratified data separately. For example, on a scatter diagram where data
are stratified into data from source 1 and data from source 2, draw quadrants, count points and
determine the critical value only for the data from source 1, then only for the data from source 2.
Stratification Example
The ZZ400 manufacturing team drew a scatter diagram to test whether product purity and iron
contamination were related, but the plot did not demonstrate a relationship. Then a team member
realized that the data came from three different reactors. The team member redrew the diagram,
using a different symbol for each reactors data:
Figure 3.11: Stratification Example
Now patterns can be seen. The data from reactor 2 and reactor 3 are circled. Even without doing
any calculations, it is clear that for those two reactors, purity decreases as iron increases.
However, the data from reactor 1, the solid dots that are not circled, do not show that
relationship. Something is different about reactor 1.
Stratification Considerations
Here are examples of different sources that might require data to be stratified:
Equipment
Shifts
Departments
Materials
Suppliers
Day of the week
Time of day
Products
Survey data usually benefit from stratification.
Always consider before collecting data whether stratification might be needed during analysis.
Plan to collect stratification information. After the data are collected it might be too late.
On your graph or chart, include a legend that identifies the marks or colors used.
3.7 QUALITY BASELINES

Quality Baselines (Assessments and Models) Organizations need to establish baselines of
performance for quality, productivity and customer satisfaction. These baselines are used to
document current performance and document improvements by showing changes from a
baseline. In order to establish a baseline, a model and/or goal must be established for use in
measuring against to determine the baseline.
3.7.1 Quality Baseline Concepts

Baselines Defined
Types of Baselines
Conducting Baseline Studies
3.7.2 Methods Used for Establishing Baselines

Customer Surveys
Benchmarking to Establish a Baseline Goal
Assessments against Management Established Criteria (e.g. software requirements and user
acceptance criteria)Assessments against Industry Models
3.7.3 Model and Assessment Fundamentals

Purpose of a Model
Types of Models (Staged and Continuous)
Model Selection Process
Using Models for Assessment and Baselines
3.7.4 Industry Quality Models

Software Engineering Institute Capability Maturity Model Integration/CMMI
Malcolm Baldrige National Quality Award (MBNQA)
ISO 9001:2000
ISO/IEC 12207: Information Technology Software Life Cycle Processes
ISO/IEC 15504: Process Assessment
Post-Implementation Audits
3.8 INTERNAL AUDITING AND QUALITY ASSURANCE

Internal auditing is an independent, objective assurance and consulting activity designed to add
value and improve an organization's operations. It helps an organization accomplish its
objectives by bringing a systematic, disciplined approach to evaluate and improve the
effectiveness of risk management, control, and governance processes. Internal auditing is a
catalyst for improving an organizations effectiveness and efficiency by providing insight and
recommendations based on analyses and assessments of data and business processes. With
commitment to integrity and accountability, internal auditing provides value to governing bodies
and senior management as an objective source of independent advice. Professionals called
internal auditors are employed by organizations to perform the internal auditing activity.
The scope of internal auditing within an organization is broad and may involve topics such as the
efficacy of operations, the reliability of financial reporting, deterring and investigating fraud,
safeguarding assets, and compliance with laws and regulations.
Internal auditing frequently involves measuring compliance with the entity's policies and
procedures. However, internal auditors are not responsible for the execution of company
activities; they advise management and the Board of Directors (or similar oversight body)
regarding how to better execute their responsibilities. As a result of their broad scope of
involvement, internal auditors may have a variety of higher educational and professional
backgrounds.
Publicly-traded corporations typically have an internal auditing department, led by a Chief Audit
Executive ("CAE") who generally reports to the Audit Committee of the Board of Directors,
with administrative reporting to the Chief Executive Officer.
3.8.1 Internal Audit Quality Assurance Reviews

A Quality Assurance Review (QAR) helps to provide senior management with an assessment of
how well their internal audit service is functioning, as well as helping to pinpoint areas for
improvement to help maximize the value it adds. As well as making good business sense, QARs
are also required by professional standards. The International Standards for the Professional
Practice of Internal Auditing, published by the Chartered Institute of Internal Auditors (CIIA),
require an independent QAR at least once every five years. Internal audit functions that do not
comply with this requirement are not permitted to state that their work is compliant with CIIA
Standards.
3.8.2 Quality assurance services include:

Creating reviews customized to each departments specific focus, capabilities and
resources
Ensuring that businesses are getting the most from their investment in internal audit
Comparing internal audit processes with best practice in other organizations
Providing advice about how to move internal audit forwards or reposition its role within
the business
Reporting findings against our QAR model, above, summarizing our findings by theme
and providing a clear opinion about compliance with CIIA standards
3.8.3 Scope of QAR:

Assess the efficiency and effectiveness of the department based on established standards.
Review of the audit universe and the method followed for annual risk assessment leading to the
audit plan.
Evaluate organizational structure, staffing, and internal audit approach of the department.
Determine how internal auditing is perceived through interviews and surveys with customers,
including governance personnel.
Examine techniques and methodology for testing controls. Identify ways to enhance the
department's policies and practices.
Evaluate whether the department conforms to The IIA's International Standards for the
Professional Practice of Internal Auditing (ISPPIA).
3.8.4 Benefits of QAR:

Clarify and validate management and shareholder expectations of the department.
Assess the department structure, methodologies, resources, and capabilities.
Assess compliance with the ISPPIA as promulgated by the Institute of Internal Auditors .
Identify opportunities to improve the department's structure and processes.
3.9 SUMMARY
The
scope
of Software Quality
Assurance
or
SQA
starts
from
the
planning
of
the application until it is being distributed for the actual operations. To successfully monitor the
application build up process, the SQA team also has their written plan. In a regular SQA plan,
the team will have enumerated all the possible functions, tools and metrics that will be expected
from the application. SQA planning will be the basis of everything once the actual SQA starts.
Without SQA planning, the team will never know what the scope of their function is. Through
planning, the clients expectations are detailed and from that point, the SQA team will know how
to build metrics and the development team could start working on the application.
Quality function deploymentspecifically, the house of qualityis an effective management tool
in which customer expectations are used to drive the design process. QFD forces the entire
organization to constantly be aware of the customer requirements. Every QFD chart is a result of
the original customer requirements which are not lost through misinterpretation or lack of
communication. Marketing benefits because specific sales points, that have been identified by the
customer, can be stressed. Most importantly, implementing QFD results in a satisfied customer.
Most of the organizations use quality tools for various purposes related to controlling and
assuring quality. Although there are a good number of quality tools specific to certain domains,
fields, and practices, some of the quality tools can be used across such domains. These quality
tools are quite generic and can be applied to any condition. There are various basic quality tools
used in organizations. These tools can provide much information about problems in the
organization assisting to derive solutions for the same. A brief training, mostly a self-training, is
sufficient for someone to start using the tools.
Auditing is an independent, objective assurance and consulting activity designed to add value
and improve an organization's operations. It helps an organization accomplish its objectives by
bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk
management, control, and governance processes. Internal auditing is a catalyst for improving an
organizations effectiveness and efficiency by providing insight and recommendations based on
analyses and assessments of data and business processes.
Assignment-Module 3
1.
QFD stands for
a.
Quality Function Development
b.
Quality Function Deployment
c.
Quality Finance Development
d.
Quality Finance Deployment
2.
QFD focuses on
a.
Product Transition
b.
Product operation
c.
Product and Process Planning
d.
Confusion and misinterpretation
3.
Benefits of QFD
a.
Customer satisfaction
b.
Conformance to specification
c.
Creates communication at interface
d.
None of them
4.
Grouping data on basis of natural interrelationships
a.
Tree diagram
b.
Cause and effect diagram
c.
Affinity diagram
d.
None of them
5.
Tool used in QFD
a.
House of Quality
b.
Quality assurance
c.
Customer satisfaction
d.
Quality planning
6.
Quality tools are
a.
Bar chart
b.
Ishikawa diagram
c.
None of them
d.
Both of them
7.
A ___________ always has a central line for the average, an upper line for the upper
control limit and a lower line for the lower control limit.
a.
Histogram
b.
Pareto chart
c.
Bar chart
d.
Control chart
8.
Types of Quality Model
a.
Staged
b.
Continuous
c.
Industry
d.
None of them
9.
CIIA stands for
a.
Chartered Institute of Internal Auditors
b.
Counsell Institute of Industrial Auditors
c.
Chartered Institute of Industrial Auditors
d.
None of them
10.
___________ perform the internal auditing activity in an organization.
a.
Internal auditors
b.
External auditors
c.
Both of them
d.
None of them
Key - Module 3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CHAPTER 4 : SOFTWARE QUALITY CONTROL

4.1 SOFTWARE TESTING
Testing is an activity performed for evaluating product quality, and for improving it, by
identifying defects and problems. Software testing can also provide an objective, independent
view of the software to allow the business to appreciate and understand the risks of software
implementation. Test techniques include, but are not limited to, the process of executing a
program or application with the intent of finding software bugs (errors or other defects).
Software testing consists of the dynamic verification of the behavior of a program on a finite set
of test cases, suitably selected from the usually infinite executions domain, against the expected
behavior.
Software testing can be stated as the process of validating and verifying that a software
program/application/product:
i.
meets the requirements that guided its design and development;
ii.
works as expected;
iii.
can be implemented with the same characteristics.
iv.
satisfies the needs of stakeholders
The view of software testing has evolved towards a more constructive one. Testing is no longer
seen as an activity which starts only after the coding phase is complete, with the limited purpose
of detecting failures. Software testing is now seen as an activity which should encompass the
whole development and maintenance process and is itself an important part of the actual product
construction. Indeed, planning for testing should start with the early stages of the requirement
process, and test plans and procedures must be systematically and continuously developed, and
possibly refined, as development proceeds. These test planning and designing activities
themselves constitute useful input for designers in highlighting potential weaknesses (like design
oversights or contradictions, and omissions or ambiguities in the documentation). Software
testing, depending on the testing method employed, can be implemented at any time in the
development process.
Different software development models will focus the test effort at different points in the
development process. Newer development models, such as Agile, often employ test-driven
development and place an increased portion of the testing in the hands of the developer, before it
reaches a formal team of testers. In a more traditional model, most of the test execution occurs
after the requirements have been defined and the coding process has been completed.
A primary purpose of testing is to detect software failures so that defects may be discovered and
corrected. Testing cannot establish that a product functions properly under all conditions but can
only establish that it does not function properly under specific conditions. The scope of software
testing often includes examination of code as well as execution of that code in various
environments and conditions as well as examining the aspects of code: does it do what it is
supposed to do and do what it needs to do. In the current culture of software development, a
testing organization may be separate from the development team. There are various roles for
testing team members. Information derived from software testing may be used to correct the
process by which software is developed.
4.1.1 Cost Effectiveness of Testing

Software testing is an expense that ultimately saves an organization a great deal of money. It has
a quantifiable return on investment (ROI) and testers can follow a simple series of steps to
calculate it. Testers emphasized the cost-effectiveness of creating quality software. According to
them, the money you spend to build it right the first time is always less than the money it costs to
fix it. The amount of money saved can be two times, four times or even 32 times the cost of
investment, he continued. Testers concerned about their budgets can cite a wealth of wellestablished references to justify upfront costs to management, Black said. He listed four ways
testing saves money: Finding bugs that get fixed, finding bugs that don't get fixed, running tests
that mitigate risks and guiding the project to success through timely, accurate, credible
information for project tracking. When figuring the ROI for finding bugs that are fixed, Black
instructed his audience to measure the cost of quality. The cost of quality combines the costs of
conformance and nonconformance, he said. Conformance costs are those accrued when an
organization creates and tests quality software and can be broken down into prevention and
protection costs.
4.2 SOME FUNDAMENTAL CONCEPTS

4.2.1 Defects and failures
Not all software defects are caused by coding errors. One common source of expensive defects is
caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by
the program designer. A common source of requirements gaps is non-functional requirements
such as testability, scalability, maintainability, usability, performance, and security. Software
faults occur through the following processes. A programmer makes an error (mistake), which
results in a defect (fault, bug) in the software source code. If this defect is executed, in certain
situations the system will produce wrong results, causing a failure. Not all defects will
necessarily result in failures. For example, defects in dead code will never result in failures. A
defect can turn into a failure when the environment is changed. Examples of these changes in
environment include the software being run on a new computer hardware platform, alterations in
source data or interacting with different software. A single defect may result in a wide range of
failure symptoms.
4.2.2 Input combinations and preconditions

A very fundamental problem with software testing is that testing under all combinations of
inputs and preconditions (initial state) is not feasible, even with a simple product. This means
that the number of defects in a software product can be very large and defects that occur
infrequently are difficult to find in testing. More significantly, non-functional dimensions of
quality (how it is supposed to be versus what it is supposed to do)usability, scalability,
performance, compatibility, reliabilitycan be highly subjective; something that constitutes
sufficient value to one person may be intolerable to another. Software developers can't test
everything, but they can use combinatorial test design to identify the minimum number of tests
needed to get the coverage they want. Combinatorial test design enables users to get greater test
coverage with fewer tests.
4.2.3 Economics
A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5
billion annually. More than a third of this cost could be avoided if better software testing was
performed. It is commonly believed that the earlier a defect is found the cheaper it is to fix it.
4.2.4 Roles
Software testing can be done by software testers. Until the 1980s the term "software tester" was
used generally, but later it was also seen as a separate profession. Regarding the periods and the
different goals in software testing, different roles have been established: manager, test lead, test
designer, tester, automation developer, and test administrator.
4.3. KEY ISSUES

4.3.1 Test selection criteria/Test adequacy criteria
A test selection criterion is a means of deciding what a suitable set of test cases should be. A
selection criterion can be used for selecting the test cases or for checking whether a selected test
suite is adequatethat is, to decide whether the testing can be stopped.
4.3.2 Testing effectiveness/Objectives for testing

Testing is the observation of a sample of program executions. Sample selection can be guided by
different objectives: it is only in light of the objective pursued that the effectiveness of the test
set can be evaluated.
4.3.3 Testing for defect identification

In testing for defect identification, a successful test is one which causes the system to fail. This is
quite different from testing to demonstrate that the software meets its specifications or other
desired properties, in which case testing is successful if no (significant) failures are observed.
4.3.4 The oracle problem

An oracle is any (human or mechanical) agent which decides whether a program behaved
correctly in a given test, and accordingly produces a verdict of pass or fail. There exist many
different kinds of oracles, and oracle automation can be very difficult and expensive.
4.3.5 Theoretical and practical limitations of testing

Testing theory warns against ascribing an unjustified level of confidence to a series of passed
tests. Unfortunately, most established results of testing theory are negative ones, in that they state
what testing can never achieve as opposed to what it actually achieved. The most famous
quotation in this regard is the Dijkstra aphorism that program testing can be used to show the
presence of bugs, but never to show their absence. The obvious reason is that complete testing
is not feasible in real software. Because of this, testing must be driven based on risk and can be
seen as a risk management strategy.
4.3.6 The problem of infeasible paths

Infeasible paths, the control flow paths that cannot be exercised by any input data, are a
significant problem in path-oriented testing, and particularly in the automated derivation of test
inputs for code-based testing techniques.
4.3.7 Testability
The term software testability has two related but different meanings: on the one hand, it refers
to the degree to which it is easy for software to fulfill a given test coverage criterion, as in
(Bac90); on the other hand, it is defined as the likelihood, possibly measured statistically, that the
software will expose a failure under testing, if it is faulty, as in (Voa95, Ber96a). Both meanings
are important.
4.4 TESTING METHODS

4.4.1 Static vs. dynamic testing
There are many approaches to software testing. Reviews, walkthroughs, or inspections are
considered as static testing, whereas actually executing programmed code with a given set of test
cases is referred to as dynamic testing. Static testing can be (and unfortunately in practice often
is) omitted. Dynamic testing takes place when the program itself is used for the first time (which
is generally considered the beginning of the testing stage). Dynamic testing may begin before the
program is 100% complete in order to test particular sections of code (modules or discrete
functions). Typical techniques for this are either using stubs/drivers or execution from a
debugger environment. For example, spreadsheet programs are, by their very nature, tested to a
large extent interactively (on the fly), with results displayed immediately after each calculation
or text manipulation.
4.4.2 The box approach

Software testing methods are traditionally divided into white- and black-box testing. These two
approaches are used to describe the point of view that a test engineer takes when designing test
cases.
4.4.3 White-Box testing

White-box testing (also known as clear box testing, glass box testing, transparent box
testing, and structural testing tests internal structures or workings of a program, as opposed to
the functionality exposed to the end-user. In white-box testing an internal perspective of the
system, as well as programming skills, are used to design test cases. The tester chooses inputs to
exercise paths through the code and determine the appropriate outputs. This is analogous to
testing nodes in a circuit, e.g. in-circuit testing (ICT).
While white-box testing can be applied at the unit, integration and system levels of the software
testing process, it is usually done at the unit level. It can test paths within a unit, paths between
units during integration, and between subsystems during a systemlevel test. Though this method
of test design can uncover many errors or problems, it might not detect unimplemented parts of
the specification or missing requirements.
Techniques used in white-box testing include:
API testing (application programming interface) - testing of the application using public
and private APIs
Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test
designer can create tests to cause all statements in the program to be executed at least
once)
Fault injection methods - intentionally introducing faults to gauge the efficacy of testing
strategies
Mutation testing methods
Static testing methods
Code coverage tools can evaluate the completeness of a test suite that was created with any
method, including black-box testing. This allows the software team to examine parts of a system
that are rarely tested and ensures that the most important function points have been tested. Code
coverage as a software metric can be reported as a percentage for:
Function coverage, which reports on functions executed
Statement coverage, which reports on the number of lines executed to complete the test
100% statement coverage ensures that all code paths, or branches (in terms of control flow) are
executed at least once. This is helpful in ensuring correct functionality, but not sufficient since
the same code may process different inputs correctly or incorrectly.
4.4.4 Black-box testing

Black-box testing treats the software as a "black box", examining functionality without any
knowledge of internal implementation. The tester is only aware of what the software is supposed
to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary
value analysis, all-pairs testing, state transition tables, decision table testing, fuzzy testing,
model-based testing, use case testing, exploratory testing and specification-based testing.
Figure 4.1: Black box diagram
Specification-based testing aims to test the functionality of software according to the applicable
requirements. This level of testing usually requires thorough test cases to be provided to the
tester, who then can simply verify that for a given input, the output value (or behavior), either
"is" or "is not" the same as the expected value specified in the test case. Test cases are built
around specifications and requirements, i.e., what the application is supposed to do. It uses
external descriptions of the software, including specifications, requirements, and designs to
derive test cases. These tests can be functional or non-functional, though usually functional.
Specification-based testing may be necessary to assure correct functionality, but it is insufficient
to guard against complex or high-risk situations. One advantage of the black box technique is
that no programming knowledge is required. Whatever biases the programmers may have had,
the tester likely has a different set and may emphasize different areas of functionality. On the
other hand, black-box testing has been said to be "like a walk in a dark labyrinth without a
flashlight." Because they do not examine the source code, there are situations when a tester
writes many test cases to check something that could have been tested by only one test case, or
leaves some parts of the program untested.
This method of test can be applied to all levels of software testing: unit, integration, system and
acceptance. It typically comprises most if not all testing at higher levels, but can also dominate
unit testing as well.
4.4.5 Grey-box testing

Grey-box testing involves having knowledge of internal data structures and algorithms for
purposes of designing tests, while executing those tests at the user, or black-box level. The tester
is not required to have full access to the software's source code. Manipulating input data and
formatting output do not qualify as grey-box, because the input and output are clearly outside of
the "black box" that we are calling the system under test. This distinction is particularly
important when conducting integration testing between two modules of code written by two
different developers, where only the interfaces are exposed for test. However, modifying a data
repository does qualify as grey-box, as the user would not normally be able to change the data
outside of the system under test. Grey-box testing may also include reverse engineering to
determine, for instance, boundary values or error messages.
By knowing the underlying concepts of how the software works, the tester makes betterinformed testing choices while testing the software from outside. Typically, a grey-box tester
will be permitted to set up his testing environment; for instance, seeding a database; and the
tester can observe the state of the product being tested after performing certain actions. Grey-box
testing implements intelligent test scenarios, based on limited information. This will particularly
apply to data type handling, exception handling, and so on.
4.4.6 Visual testing

The aim of visual testing is to provide developers with the ability to examine what was
happening at the point of software failure by presenting the data in such a way that the developer
can easily nd the information he requires, and the information is expressed clearly.
At the core of visual testing is the idea that showing someone a problem (or a test failure), rather
than just describing it, greatly increases clarity and understanding. Visual testing therefore
requires the recording of the entire test process capturing everything that occurs on the test
system in video format. Output videos are supplemented by real-time tester input via picture-ina-picture webcam and audio commentary from microphones.
Visual testing provides a number of advantages. The quality of communication is increased
dramatically because testers can show the problem (and the events leading up to it) to the
developer as opposed to just describing it and the need to replicate test failures will cease to exist
in many cases. The developer will have all the evidence he requires of a test failure and can
instead focus on the cause of the fault and how it should be fixed.
Visual testing is particularly well-suited for environments that deploy agile methods in their
development of software, since agile methods require greater communication between testers and
developers and collaboration within small teams.
Ad hoc testing and exploratory testing are important methodologies for checking software
integrity, because they require less preparation time to implement, whilst important bugs can be
found quickly. In ad hoc testing, where testing takes place in an improvised, impromptu way, the
ability of a test tool to visually record everything that occurs on a system becomes very
important.
Visual testing is gathering recognition in customer acceptance and usability testing, because the
test can be used by many individuals involved in the development process.
For the customer, it becomes easy to provide detailed bug reports and feedback, and for program
users, visual testing can record user actions on screen, as well as their voice and image, to
provide a complete picture at the time of software failure for the developer.
4.5 TESTING LEVELS

Tests are frequently grouped by where they are added in the software development process, or by
the level of specificity of the test. The main levels during the development process as defined by
the SWEBOK guide are unit-, integration-, and system testing that are distinguished by the test
target without implying a specific process model.
4.5.1 Unit testing

Unit testing, also known as component testing refers to tests that verify the functionality of a
specific section of code, usually at the function level. In an object-oriented environment, this is
usually at the class level, and the minimal unit tests include the constructors and destructors.
These types of tests are usually written by developers as they work on code (white-box style), to
ensure that the specific function is working as expected. One function might have multiple tests,
to catch corner cases or other branches in the code. Unit testing alone cannot verify the
functionality of a piece of software, but rather is used to assure that the building blocks the
software uses work independently of each other.
4.5.2 Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces between
components against a software design. Software components may be integrated in an iterative
way or all together ("big bang"). Normally the former is considered a better practice since it
allows interface issues to be localised more quickly and fixed. Integration testing works to
expose defects in the interfaces and interaction between integrated components (modules).
Progressively larger groups of tested software components corresponding to elements of the
architectural design are integrated and tested until the software works as a system.
4.5.3 System testing

System testing tests a completely integrated system to verify that it meets its requirements.
4.5.4 System integration testing

System integration testing verifies that a system is integrated to any external or third-party
systems defined in the system requirements.
4.5.5 Top-down and bottom-up

Bottom Up Testing is an approach to integrated testing where the lowest level components are
tested first, then used to facilitate the testing of higher level components. The process is repeated
until the component at the top of the hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated and then tested.
After the integration testing of lower level integrated modules, the next level of modules will be
formed and can be used for integration testing. This approach is helpful only when all or most of
the modules of the same development level are ready. This method also helps to determine the
levels of software developed and makes it easier to report testing progress in the form of a
percentage.
Top Down Testing is an approach to integrated testing where the top integrated modules are
tested and the branch of the module is tested step by step until the end of the related module.
4.6. OBJECTIVES OF TESTING

4.6.1 Installation testing
An installation test assures that the system is installed correctly and working at actual customer's
hardware.
4.6.2 Compatibility testing

A common cause of software failure (real or perceived) is a lack of its compatibility with other
application software, operating systems (or operating system versions, old or new), or target
environments that differ greatly from the original (such as a terminal or GUI application intended
to be run on the desktop now being required to become a web application, which must render in
a web browser). For example, in the case of a lack of backward compatibility, this can occur
because the programmers develop and test software only on the latest version of the target
environment, which not all users may be running. This results in the unintended consequence
that the latest work may not function on earlier versions of the target environment, or on older
hardware that earlier versions of the target environment was capable of using. Sometimes such
issues can be fixed by proactively abstracting operating system functionality into a separate
program module or library.
4.6.3 Smoke and sanity testing

Sanity testing determines whether it is reasonable to proceed with further testing.
Smoke testing is used to determine whether there are serious problems with a piece of software,
for example as a build verification test.
4.6.4 Regression testing

Regression testing focuses on finding defects after a major code change has occurred.
Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such
regressions occur whenever software functionality that was previously working correctly stops
working as intended. Typically, regressions occur as an unintended consequence of program
changes, when the newly developed part of the software collides with the previously existing
code. Common methods of regression testing include re-running previously run tests and
checking whether previously fixed faults have re-emerged. The depth of testing depends on the
phase in the release process and the risk of the added features. They can either be complete, for
changes added late in the release or deemed to be risky, to very shallow, consisting of positive
tests on each feature, if the changes are early in the release or deemed to be of low risk.
4.6.5 Acceptance testing

Acceptance testing can mean one of two things:
1.
A smoke test is used as an acceptance test prior to introducing a new build to the main
testing process, i.e. before integration or regression.

2.
Acceptance testing performed by the customer, often in their lab environment on their
own hardware, is known as user acceptance testing (UAT). Acceptance testing may be
performed as part of the hand-off process between any two phases of development.
4.6.6 Alpha testing

Alpha testing is simulated or actual operational testing by potential users/customers or an
independent test team at the developers' site. Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing, before the software goes to beta testing.
4.6.7 Beta testing

Beta testing comes after alpha testing and can be considered a form of external user acceptance
testing. Versions of the software, known as beta versions, are released to a limited audience
outside of the programming team. The software is released to groups of people so that further
testing can ensure the product has few faults or bugs. Sometimes, beta versions are made
available to the open public to increase the feedback field to a maximal number of future users.
4.6.8 Functional vs non-functional testing

Functional testing refers to activities that verify a specific action or function of the code. These
are usually found in the code requirements documentation, although some development
methodologies work from use cases or user stories. Functional tests tend to answer the question
of "can the user do this" or "does this particular feature work."
Non-functional testing refers to aspects of the software that may not be related to a specific
function or user action, such as scalability or other performance, behavior under certain
constraints, or security. Testing will determine the flake point, the point at which extremes of
scalability or performance leads to unstable execution. Non-functional requirements tend to be
those that reflect the quality of the product, particularly in the context of the suitability
perspective of its users.
4.6.9 Destructive testing

Destructive testing attempts to cause the software or a sub-system to fail. It verifies that the
software functions properly even when it receives invalid or unexpected inputs, thereby
establishing the robustness of input validation and error-management routines.
Software fault injection, in the form of fuzzing, is an example of failure testing. Various
commercial non-functional testing tools are linked from the software fault injection page; there
are also numerous open-source and free software tools available that perform destructive testing.
4.6.10 Software performance testing

Performance testing is in general executed to determine how a system or sub-system performs in
terms of responsiveness and stability under a particular workload. It can also serve to investigate
measure, validate or verify other quality attributes of the system, such as scalability, reliability
and resource usage.
Load testing is primarily concerned with testing that the system can continue to operate under a
specific load, whether that be large quantities of data or a large number of users. This is
generally referred to as software scalability. The related load testing activity of when performed
as a non-functional activity is often referred to as endurance testing. Volume testing is a way to
test software functions even when certain components (for example a file or database) increase
radically in size. Stress testing is a way to test reliability under unexpected or rare workloads.
Stability testing (often referred to as load or endurance testing) checks to see if the software can
continuously function well in or above an acceptable period.
There is little agreement on what the specific goals of performance testing are. The terms load
testing, performance testing, reliability testing, and volume testing, are often used
interchangeably.
4.6.11 Usability testing

Usability testing is needed to check if the user interface is easy to use and understand. It is
concerned mainly with the use of the application.
4.6.12 Accessibility
Accessibility testing might include compliance with:
Americans with Disabilities Act of 1990
Section 508 Amendment to the Rehabilitation Act of 1973
Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)
4.6.13 Security testing

Security testing is essential for software that processes confidential data to prevent system
intrusion by hackers.
4.6.14 Internationalization and localization

The general ability of software to be internationalized and localized can be automatically tested
without actual translation, by using pseudo localization. It will verify that the application still
works, even after it has been translated into a new language or adapted for a new culture (such as
different currencies or time zones).
Actual translation to human languages must be tested, too. Possible localization failures include:
Software is often localized by translating a list of strings out of context, and the translator
may choose the wrong translation for an ambiguous source string.
Technical terminology may become inconsistent if the project is translated by several
people without proper coordination or if the translator is imprudent.
Literal word-for-word translations may sound inappropriate, artificial or too technical in
the target language.
Untranslated messages in the original language may be left hard coded in the source
code.
Some messages may be created automatically at run time and the resulting string may be
ungrammatical, functionally incorrect, misleading or confusing.
Software may use a keyboard shortcut which has no function on the source language's
keyboard layout, but is used for typing characters in the layout of the target language.
Software may lack support for the character encoding of the target language.
Fonts and font sizes which are appropriate in the source language may be inappropriate in
the target language; for example, CJK characters may become unreadable if the font is
too small.
A string in the target language may be longer than the software can handle. This may
make the string partly invisible to the user or cause the software to crash or malfunction.
Software may lack proper support for reading or writing bi-directional text.
Software may display images with text that was not localized.
Localized operating systems may have differently-named system configuration files and
environment variables and different formats for date and currency.
To avoid these and other localization problems, a tester who knows the target language must run
the program with all the possible use cases for translation to see if the messages are readable,
translated correctly in context and do not cause failures.
4.7 THE TESTING PROCESS

Testing concepts, strategies, techniques, and measures need to be integrated into a defined and
controlled process which is run by people. The test process supports testing activities and
provides guidance to testing teams, from test planning to test output evaluation, in such a way as
to provide justified assurance that the test objectives will be met cost-effectively.
4.7.1 Practical considerations

Attitudes/Egoless programming
A very important component of successful testing is a collaborative attitude towards testing and
quality assurance activities. Managers have a key role in fostering a generally favorable
reception towards failure discovery during development and maintenance; for instance, by
preventing a mindset of code ownership among programmers, so that they will not feel
responsible for failures revealed by their code.
Test guides
The testing phases could be guided by various aims, for example: in risk-based testing, which
uses the product risks to prioritize and focus the test strategy; or in scenario-based testing, in
which test cases are defined based on specified software scenarios.
Test process management

Test activities conducted at different levels must be organized, together with people, tools,
policies, and measurements, into a well-defined process which is an integral part of the life cycle.
In IEEE/EIA Standard 12207.0, testing is not described as a stand-alone process, but principles
for testing activities are included along with both the five primary life cycle processes and the
supporting process. In IEEE Std 1074, testing is grouped with other evaluation activities as
integral to the entire life cycle.
Test documentation and work products

Documentation is an integral part of the formalization of the test process. The IEEE Standard for
Software Test Documentation (IEEE829-98) provides a good description of test documents and
of their relationship with one another and with the testing process. Test documents may include,
among others, Test Plan, Test Design Specification, Test Procedure Specification, Test Case
Specification, Test Log, and Test Incident or Problem Report. The software under test is
documented as the Test Item. Test documentation should be produced and continually updated,
to the same level of quality as other types of documentation in software engineering.
Internal vs. independent test team

Formalization of the test process may involve formalizing the test team organization as well. The
test team can be composed of internal members (that is, on the project team, involved or not in
software construction), of external members, in the hope of bringing in an unbiased, independent
perspective, or, finally, of both internal and external members. Considerations of costs, schedule,
maturity levels of the involved organizations, and criticality of the application may determine the
decision.
Cost/effort estimation and other process measures

Several measures related to the resources spent on testing, as well as to the relative fault-finding
effectiveness of the various test phases, are used by managers to control and improve the test
process. These test measures may cover such aspects as number of test cases specified, number
of test cases executed, number of test cases passed, and number of test cases failed, among
others.
Evaluation of test phase reports can be combined with root-cause analysis to evaluate test
process effectiveness in finding faults as early as possible. Such an evaluation could be
associated with the analysis of risks. Moreover, the resources that are worth spending on testing
should be commensurate with the use/criticality of the application: different techniques have
different costs and yield different levels of confidence in product reliability. Termination A
decision must be made as to how much testing is enough and when a test stage can be
terminated. Thoroughness measures, such as achieved code coverage or functional completeness,
as well as estimates of fault density or of operational reliability, provide useful support, but are
not sufficient in themselves.
Test reuse and test patterns

To carry out testing or maintenance in an organized and cost-effective way, the means used to
test each part of the software should be reused systematically. This repository of test materials
must be under the control of software configuration management, so that changes to software
requirements or design can be reflected in changes to the scope of the tests conducted. The test
solutions adopted for testing some application types under certain circumstances, with the
motivations behind the decisions taken, form a test pattern which can itself be documented for
later reuse in similar projects.
4.7. 2 Test Activities

Under this topic, a brief overview of test activities is given; as often implied by the following
description, successful management of test activities strongly depends on the Software
Configuration Management process.
Planning
Like any other aspect of project management, testing activities must be planned. Key aspects of
test planning include coordination of personnel, management of available test facilities and
equipment (which may include magnetic media, test plans and procedures), and planning for
possible undesirable outcomes. If more than one baseline of the software is being maintained,
then a major planning consideration is the time and effort needed to ensure that the test
environment is set to the proper configuration.
Test-case generation
Generation of test cases is based on the level of testing to be performed and the particular testing
techniques. Test cases should be under the control of software configuration management and
include the expected results for each test.
Test environment development

The environment used for testing should be compatible with the software engineering tools. It
should facilitate development and control of test cases, as well as logging and recovery of
expected results, scripts, and other testing materials.
Execution
Execution of tests should embody a basic principle of scientific experimentation: everything
done during testing should be performed and documented clearly enough that another person
could replicate the results. Hence, testing should be performed in accordance with documented
procedures using a clearly defined version of the software under test.
Test results evaluation

The results of testing must be evaluated to determine whether or not the test has been successful.
In most cases, successful means that the software performed as expected and did not have any
major unexpected outcomes. Not all unexpected outcomes are necessarily faults, however, but
could be judged to be simply noise. Before a failure can be removed, an analysis and debugging
effort is needed to isolate, identify, and describe it.
Problem reporting/Test log

Testing activities can be entered into a test log to identify when a test was conducted, who
performed the test, what software configuration was the basis for testing, and other relevant
identification information. Unexpected or incorrect test results can be recorded in a problemreporting system, the data of which form the basis for later debugging and for fixing the
problems that were observed as failures during testing. Also, anomalies not classified as faults
could be documented in case they later turn out to be more serious than first thought.
Defect tracking
Failures observed during testing are most often due to faults or defects in the software. Such
defects can be analyzed to determine when they were introduced into the software, what kind of
error caused them to be created (poorly defined requirements, incorrect variable declaration,
memory leak, programming syntax error, for example), and when they could have been first
observed in the software. Defect-tracking information is used to determine what aspects of
software engineering need improvement and how effective previous analyses and testing have
been.
4.8 SOFTWARE TESTING LIFE CYCLE

Software Testing Life Cycle consist of six (generic) phases: 1) Planning, 2) Analysis, 3) Design,
4) Construction, 5) Testing Cycles, 6) Final Testing and Implementation and 7) Post
Implementation. Each phase in the life cycle is described with the respective activities.
Planning. Planning High Level Test plan, QA plan (quality goals), identify reporting
procedures, problem classification, acceptance criteria, databases for testing, measurement
criteria (defect quantities/severity level and defect origin), project metrics and finally begin the
schedule for project testing. Also, plan to maintain all test cases (manual or automated) in a
database.
Analysis. Involves activities that develop functional validation based on Business

Requirements (writing test cases basing on these details), develop test case format (time
estimates and priority assignments), develop test cycles (matrices and timelines), identify test
cases to be automated (if applicable), define area of stress and performance testing, plan the test
cycles required for the project and regression testing, define procedures for data maintenance
(backup, restore, validation), review documentation.
Design. Activities in the design phase Revise test plan based on changes, revise test cycle
matrices and timelines, verify that test plan and cases are in a database or requisite, continue to
write test cases and add new ones based on changes, develop Risk Assessment Criteria,
formalize details for Stress and Performance testing, finalize test cycles (number of test case per
cycle based on time estimates per test case and priority), finalize the Test Plan, (estimate
resources to support development in unit testing).
Construction (Unit Testing Phase). Complete all plans, complete Test Cycle matrices and
timelines, complete all test cases (manual), begin Stress and Performance testing, test the
automated testing system and fix bugs, (support development in unit testing), run QA acceptance
test suite to certify software is ready to turn over to QA.
Test Cycle(s) / Bug Fixes (Re-Testing/System Testing Phase). Run the test cases (front and back
end), bug reporting, verification, revise/add test cases as required.
Final Testing and Implementation (Code Freeze Phase). Execution of all front end test cases
manual and automated, execution of all back end test cases manual and automated, execute all
Stress and Performance tests, provide on-going defect tracking metrics, provide on-going
complexity and design metrics, update estimates for test cases and test plans, document test
cycles, regression testing, and update accordingly.
Post Implementation. Post implementation evaluation meeting can be conducted to review

entire project. Activities in this phase Prepare final Defect Report and associated metrics,
identify strategies to prevent similar problems in future project, automation team 1) Review
test cases to evaluate other cases to be automated for regression testing, 2) Clean up automated
test cases and variables, and 3) Review process of integrating results from automated testing in
with results from manual testing.
4.8.1 Measurement in software testing

Usually, quality is constrained to such topics as correctness, completeness, security but can also
include more technical requirements as described under the ISO standard ISO/IEC 9126, such as
capability, reliability, efficiency, portability, maintainability, compatibility, and usability.
There are a number of frequently-used software metrics, or measures, which are used to assist in
determining the state of the software or the adequacy of the testing.
4.8.2 Testing artifacts

The software testing process can produce several artifacts.
Test plan
A test specification is called a test plan. The developers are well aware what test plans will be
executed and this information is made available to management and the developers. The idea is
to make them more cautious when developing their code or making additional changes. Some
companies have a higher-level document called a test strategy.
Traceability matrix
A traceability matrix is a table that correlates requirements or design documents to test
documents. It is used to change tests when related source documents are changed, to select test
cases for execution when planning for regression tests by considering requirement coverage.
Test case
A test case normally consists of a unique identifier, requirement references from a design
specification, preconditions, events, a series of steps (also known as actions) to follow, input,
output, expected result, and actual result. Clinically defined a test case is an input and an
expected result. This can be as pragmatic as 'for condition x your derived result is y', whereas
other test cases described in more detail the input scenario and what results might be expected. It
can occasionally be a series of steps (but often steps are contained in a separate test procedure
that can be exercised against multiple test cases, as a matter of economy) but with one expected
result or expected outcome. The optional fields are a test case ID, test step, or order of execution
number, related requirement(s), depth, test category, author, and check boxes for whether the test
is automatable and has been automated. Larger test cases may also contain prerequisite states or
steps, and descriptions. A test case should also contain a place for the actual result. These steps
can be stored in a word processor document, spreadsheet, database, or other common repository.
Test script
A test script is a procedure, or programming code that replicates user actions. Initially the term
was derived from the product of work created by automated regression test tools. Test Case will
be a baseline to create test scripts using a tool or a program.
Test suite
The most common term for a collection of test cases is a test suite. The test suite often also
contains more detailed instructions or goals for each collection of test cases. It definitely contains
a section where the tester identifies the system configuration used during testing. A group of test
cases may also contain prerequisite states or steps, and descriptions of the following tests.
Test fixture or test data

In most cases, multiple sets of values or data are used to test the same functionality of a
particular feature. All the test values and changeable environmental components are collected in
separate files and stored as test data. It is also useful to provide this data to the client and with the
product or a project.
Test harness
The software, tools, samples of data input and output, and configurations are all referred to
collectively as a test harness.
4.8.3 Test Case Development

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. While the
test plan describes what to test, a test case describes how to perform a particular test. You need to
develop test cases for each test listed in the test plan.
4.8.4 General Guidelines

As a tester, the best way to determine the compliance of the software to requirements is by
designing effective test cases that provide a thorough test of a unit. Various test case design
techniques enable the testers to develop effective test cases. Besides, implementing the design
techniques, every tester needs to keep in mind general guidelines that will aid in test case design:
a. The purpose of each test case is to run the test in the simplest way possible. [Suitable
techniques - Specification derived tests, Equivalence partitioning]
b. Concentrate initially on positive testing i.e. the test case should show that the software does
what it is intended to do. [Suitable techniques - Specification derived tests, Equivalence
partitioning, State-transition testing]
c. Existing test cases should be enhanced and further test cases should be designed to show that
the software does not do anything that it is not specified to do i.e. Negative Testing [Suitable
techniques - Error guessing, Boundary value analysis, Internal boundary value testing, Statetransition testing]
d. Where appropriate, test cases should be designed to address issues such as performance,
safety requirements and security requirements [Suitable techniques - Specification derived
tests]
e. Further test cases can then be added to the unit test specification to achieve specific test
coverage objectives. Once coverage tests have been designed, the test procedure can be
developed and the tests executed [Suitable techniques - Branch testing, Condition testing,
Data definition-use testing, State-transition testing]
4.8.5 Test Case Sample Structure

The manner in which a test case is depicted varies between organizations. Anyhow, many test
case templates are in the form of a table, for example, a 5-column table with fields:
Test Case ID
Test Case Description
Test Dependency/Setup
Input Data Requirements/Steps
Expected Results
Pass/Fail
4.8.6 Most common software errors

Following are the most common software errors that aid you in software testing. This helps you
to identify errors systematically and increases the efficiency and productivity of software testing.
Types of errors with examples
User Interface Errors: Missing/Wrong Functions, Doesnt do what the user expects, Missing
information, Misleading, Confusing information, Wrong content in Help text, Inappropriate error
messages. Performance issues Poor responsiveness, Cant redirect output, inappropriate use of
key board
Error Handling: Inadequate protection against corrupted data, tests of user input, version
control; Ignores overflow, data comparison, Error recovery aborting errors, recovery from
hardware problems.
Boundary related errors: Boundaries in loop, space, time, memory, mishandling of cases
outside boundary.
Calculation errors: Bad Logic, Bad Arithmetic, Outdated constants, Calculation errors,
Incorrect conversion from one data representation to another, Wrong formula, Incorrect
approximation.
Initial and Later states: Failure to set data item to zero, to initialize a loop-control variable, or
re-initialize a pointer, to clear a string or flag, Incorrect initialization.
Control flow errors: Wrong returning state assumed, Exception handling based exits, Stack
underflow/overflow, Failure to block or un-block interrupts, Comparison sometimes yields
wrong result, Missing/wrong default, Data Type errors.
Errors in Handling or Interpreting Data: Un-terminated null strings, Overwriting a file after
an error exit or user abort.
Race Conditions: Assumption that one event or task finished before another begins, Resource
races, Tasks starts before its prerequisites are met, Messages cross or dont arrive in the order
sent.
Load Conditions: Required resources are not available, No available large memory area, Low
priority tasks not put off, Doesnt erase old files from mass storage, Doesnt return unused
memory.
Hardware:
Wrong
Device,
Device
unavailable,
Underutilizing
Misunderstood status or return code, Wrong operation or instruction codes.
device
intelligence,
Source, Version and ID Control: No Title or version ID, Failure to update multiple copies of
data or program files.
Testing Errors: Failure to notice/report a problem, Failure to use the most promising test case,
Corrupted data files, Misinterpreted specifications or documentation, Failure to make it clear
how to reproduce the problem, Failure to check for unresolved problems just before release,
Failure to verify fixes, Failure to provide summary report.
4.8.7 Guidelines for good tester?

As software engineering is now being considered as a technical engineering profession, it is
important that the software test engineers posses certain traits with a relentless attitude to make
them stand out. Here are a few:
Know the technology. Knowledge of the technology in which the application is developed is an
added advantage to any tester. It helps design better and powerful test cases basing on the
weakness or flaws of the technology. Good testers know what it supports and what it doesnt, so
concentrating on these lines will help them break the application quickly.
Perfectionist and a realist. Being a perfectionist will help testers spot the problem and being a
realist helps know at the end of the day which problems are really important problems. You will
know which ones require a fix and which ones dont.
Tactful, diplomatic and persuasive. Good software testers are tactful and know how to break
the news to the developers. They are diplomatic while convincing the developers of the bugs and
persuade them when necessary and have their bug(s) fixed. It is important to be critical of the
issue and not let the person who developed the application be taken aback of the findings.
An explorer. A bit of creativity and an attitude to take risk helps the testers venture into
unknown situations and find bugs that otherwise will be looked over.
Troubleshoot. Troubleshooting and figuring out why something doesnt work helps testers be
confident and clear in communicating the defects to the developers.
Posses people skills and tenacity. Testers can face a lot of resistance from programmers. Being
socially smart and diplomatic doesnt mean being indecisive. The best testers are both-socially
adept and tenacious where it matters.
Organized. Best testers very well realize that they too can make mistakes and dont take
chances. They are very well organized and have checklists, use files, facts and figures to support
their findings that can be used as an evidence and double-check their findings.
Objective and accurate. They are very objective and know what they report and so convey
impartial and meaningful information that keeps politics and emotions out of message. Reporting
inaccurate information is losing a little credibility. Good testers make sure their findings are
accurate and reproducible.
Defects are valuable. Good testers learn from them. Each defect is an opportunity to learn and
improve. A defect found early substantially costs less when compared to the one found at a later
stage. Defects can cause serious problems if not managed properly. Learning from defects helps
prevention of future problems, track improvements, improve prediction and estimation.
4.9 SOFTWARE VERIFICATION AND VALIDATION

In software project management, software testing, and software engineering, verification and
validation (V&V) is the process of checking that a software system meets specifications and that
it fulfills its intended purpose. It may also be referred to as software quality control. It is
normally the responsibility of software testers as part of the software development lifecycle.
Software testing is used in association with verification and validation:
Verification: Have we built the software right? (i.e., does it implement the requirements).
Validation: Have we built the right software? (i.e., do the requirements satisfy the
customer).
The terms verification and validation are commonly used interchangeably in the industry; it is
also common to see these two terms incorrectly defined.
According to the IEEE Standard Glossary of Software Engineering Terminology:

Verification is the process of evaluating a system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start of that
phase.
Validation is the process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements.
According to the IS0 9000 standard:

Verification is confirmation by examination and through provision of objective evidence
that specified requirements have been fulfilled.
Validation is confirmation by examination and through provision of objective evidence
that the requirements for a specific intended use or application have been fulfilled.
According to the Capability Maturity Model (CMMI-SW v1.1),

Verification: The process of evaluating software to determine whether the products of a
given development phase satisfy the conditions imposed at the start of that phase.
Validation: The process of evaluating software during or at the end of the development
process to determine whether it satisfies specified requirements.
Within the modeling and simulation community, the definitions of verification and validation are
similar:
Verification is the process of determining that a computer model, simulation, or
federation of models and simulations implementations and their associated data
accurately represents the developer's conceptual description and specifications.
Validation is the process of determining the degree to which a model, simulation, or

federation of models and simulations, and their associated data are accurate
representations of the real world from the perspective of the intended use(s).
Differences between Verification and Validation

Verification is ensuring that the product has been built according to the requirements and
design specifications while validation ensures that the product actually meets the user's
needs, and that the specifications were correct in the first place.
Verification ensures that "you built it right". Validation confirms that the product, as
provided, will fulfill its intended use. Validation ensures that "you built the right thing".
Verification is Static while Validation is Dynamic. This means in Verification the s/w is
inspected by looking into the code going line by line or function by function. In
Validation, code is executed and s/w is run to find defects. Since in verification code is
reviewed, location of the defect can be found which is not possible in validation.
Verification is to determine the right thing, which involves the testing the implementation
of right process. Ex: Are we building the product right? Validation is to perform the
things in right direction, like checking the developed software adheres the requirements
of the client. Ex: right product was built
4.9.1 Software Verification and Validation Methods

This section discusses methods for software verification and validation. The methods are:
Software inspection
i.
Formal methods
ii.
Program verification technique
iii.
Cleanroom method
iv.
Structured testing
v.
Structured integration testing
4.9.1.1 Software Inspections

Software inspections can be used for the detection of defects in detailed designs before coding,
and in code before testing. They may also be used to verify test designs, test cases and test
procedures. More generally, inspections can be used for verifying the products of any
development process that is defined in terms of:
operations (e.g. 'code module');
exit criteria (e.g. 'module successfully compiles').
Software inspections are efficient. Projects can detect over 50% of the total number of defects
introduced in development by doing them Software inspections are economical because they
result in significant reductions in both the number of defects and the cost of their removal.
Detection of a defect as close as possible to the time of its introduction results in:
an increase in the developers' awareness of the reason for the defect's occurrence, so that the
likelihood that a similar defect will recur again is reduced;
reduced effort in locating the defect, since no effort is required to diagnose which
component, out of many possible components, contains the defect.
Software inspections are formal processes. They differ from walkthroughs by:
repeating the process until an acceptable defect rate (e.g. number of errors per thousand lines
of code) has been achieved;
analysing the results of the process and feeding them back to improve the production process,
and forward to give early measurements of software quality;
avoiding discussion of solutions;
including rework and follow-up activities.
The following subsections summarize the software inspection process.

(a) Objectives
The objective of a software inspection is to detect defects in documents or code.
(b) Organisation
There are five roles in a software inspection:
moderator;
secretary;
reader;
inspector;
author.
The moderator leads the inspection and chairs the inspection meeting. The person should have
implementation skills, but not necessarily be knowledgeable about the item under inspection. He
or she must be impartial and objective. For this reason moderators are often drawn from staff
outside the project. Ideally they should receive some training in inspection procedures.
The secretary is responsible for recording the minutes of inspection meetings, particularly the
details about each defect found.
The reader guides the inspection team through the review items during the inspection meetings.
Inspectors identify and describe defects in the review items under inspection. They should be
selected to represent a variety of viewpoints (e.g. designer, coder and tester).
The author is the person who has produced the items under inspection. The author is present to
answer questions about the items under inspection, and is responsible for all rework.
A person may have one or more of the roles above. In the interests of objectivity, no person may
share the author role with another role.
(c) Input
The inputs to an inspection are the:
review items;
specifications of the review items;
inspection checklist;
standards and guidelines that apply to the review items;
inspection reporting forms;
defect list from a previous inspection.
(d) Activities
A software inspection consists of the following activities:
i.
overview;
ii.
preparation;
iii.
review meeting;
iv.
rework;
v.
follow-up.
(i) Overview
The purpose of the overview is to introduce the review items to the inspection team. The
moderator describes the area being addressed and then the specific area that has been designed in
detail. For a re-inspection, the moderator should flag areas that have been subject to rework since
the previous inspection. The moderator then distributes the inputs to participants.
(ii) Preparation
Moderators, readers and inspectors then familiarize themselves with the inputs. They might
prepare for a code inspection by reading:
design specifications for the code under inspection;
coding standards;
checklists of common coding errors derived from previous inspections;
code to be inspected.
Any defects in the review items should be noted on RID forms and declared at the appropriate
point in the examination. Preparation should be done individually and not in a meeting.
(iii) Review meeting
The moderator checks that all the members have performed the preparatory activities. The
amount of time spent by each member should be reported and noted. The reader then leads the
meeting through the review items. For documents, the reader may summarize the contents of
some sections and cover others line-by-line, as appropriate. For code, the reader covers every
piece of logic, traversing every branch at least once. Data declarations should be summarized.
Inspectors use the checklist to find common errors. Defects discovered during the reading should
be immediately noted by the secretary. The defect list should cover the:
severity (e.g. major, minor);
technical area (e.g. logic error, logic omission, comment error);
location;
description.
Any solutions identified should be noted. The inspection team should avoid searching for
solutions and concentrate on finding defects. At the end of the meeting, the inspection team takes
one of the following decisions:
accept the item when the rework (if any) is completed;
make the moderator responsible for accepting the item when the rework is completed;
reinspect the whole item (usually necessary if more than 5% of the material requires rework).
The secretary should produce the minutes immediately after the review meeting, so that rework
can start without delay.
(iv) Rework
After examination, software authors correct the defects described in the defect list.
(v) Follow-up
After rework, follow-up activities verify that all the defects have been properly corrected and
that no secondary defects have been introduced. The moderator is responsible for follow-up.
Other follow-up activities are the:
updating of the checklist as the frequency of different types of errors change;
analysis of defect statistics, perhaps resulting in the redirection of SVV effort.
(e) Output
The outputs of an inspection are the:
defect list;
defect statistics;
inspection report.
The inspection report should give the:

names of the participants;
duration of the meeting;
amount of material inspected;
amount of preparation time spent;
review decision on acceptance;

estimates of rework effort and schedule.
4.9.1.2 Formal Methods

Formal Methods, such as LOTOS, Z and VDM, possess an agreed notation, with well-defined
semantics, and a calculus, which allow proofs to be constructed. The first property is shared with
other methods for software specification, but the second sets them apart. Formal Methods may be
used in the software requirements definition phase for the construction of specifications.
4.9.1.3 Program Verification Techniques

Program verification techniques may be used in the detailed design and production phase to
show that a program is consistent with its specification. These techniques require that the:
semantics of the programming language are formally defined;
program be formally specified in a notation that is consistent with the mathematical
verification techniques used.
If these conditions are not met, formal program verification cannot be attempted.
A common approach to formal program verification is to derive, by stepwise refinement of the
formal specification, 'assertions' (e.g. preconditions or post conditions) that must be true at each
stage in the processing. Formal proof of the program is achieved by demonstrating that program
statements separating assertions transform each assertion into its successor. In addition, it is
necessary to show that the program will always terminate (i.e. one or more of the post conditions
will always be met). Formal program verification is usually not possible because the
programming language has not been formally defined. Even so, a more pragmatic approach to
formal proof is to show that the:
program code is logically consistent with the program specification;
program will always terminate.
Assertions are placed in the code as comments. Verification is achieved by arguing that the code
complies with the requirements present in the assertions.
4.9.1.4 Clean-room method

The clean-room method replaces unit testing and integration testing with software inspections
and program verification techniques. System testing is carried out by an independent testing
team. The clean-room method is not fully compliant with ESA PSS-05-0 because:
full statement coverage is not achieved (DD06);
unit and integration testing are omitted (DD07, DD08).
4.9.1.5 Structured Testing

Structured Testing is a method for verifying software based upon the mathematical properties of
control graphs. The method:
improves testability by limiting complexity during detailed design;
guides the definition of test cases during unit testing.
Software with high complexity is hard to test. The Structured Testing method uses the
cyclomatic complexity metric for measuring complexity, and recommends that module designs
be simplified until they are within the complexity limits. Structured Testing provides a
technique, called the 'baseline method', for defining test cases. The objective is to cover every
branch of the program logic during unit testing. The minimum number of test cases is the
cyclomatic complexity value measured in the first step of the method.
4.9.1.6 Structured Integration Testing

Structured Integration Testing is a method based upon the Structured Testing Method that:
improves testability by limiting complexity during software architectural design;
guides the definition of test cases during integration testing.

The method can be applied at all levels of design above the module level. Therefore it may also
be applied in unit testing when units assembled from modules are tested.
4.10 SOFTWARE CHANGE CONTROL

Definitions
Codeline - Source code required to produce software. It could be a specific product or even a
basic set of code that many of your internet applications commonly use. A main codeline
should exist in your organization for each type of application that your organization creates.
Codelines can be used to help manage software version control and change control. Software
codelines should have specific purposes. One codeline of code may be a main codeline which
other projects use to provide base functions. Another may be a specific project to be
delivered to a customer. Other codelines may be used to enhance or add features to the main
codeline.
Codeline policy - Each codeline should have its own policy. One codeline may require more
stringent testing that another one. A codeline under development will require a policy that
does not require stringent testing when code is checked in. Production codeline should have a
policy requiring stringent testing.
Environment - When discussing code use, the environment is either test (development),
Quality Assurance (QA) test, or production. The test or development environment is used for
developers to test their code. The QA environment is used by customers to verify business
functionality. The production environment is where the software runs for the purpose of
customer use. Changes to the production environment must be the most stringent.
Branching - The creation of a new codeline based upon a current codeline. Branching should
only be done when absolutely necessary.
4.10.1 Software Change Requirements

There are several requirements to provide effective software change control.
A Software Version Control (SVC) system or Source Code Management (SCM) tool should
be used to control software changes and versions.
The ability to return to earlier states in the code should be built into the software change
control system.
Files should be locked while they are being worked on so only one developer may make
changes to specific files at a time. This will prevent overwriting of work.
All files associated with the code must be under version control including software
requirements files.
All developers should have home folders where they can place their own experimental code
outside the main project. This should only be used for building tools not directly required by
the project and will not be allowed to contain project code.
Each software change request should be assigned a unique tracking number.
Identify the person(s) who are essential for authorizing changes to software and have only
them approve the changes. This will prevent too much bureaucracy and cost.
Automate the change control process as much as possible and use a version control or code
management tool that includes change management if possible.
When the software change is comitted to the system, the description of the change and the
reason for it must be meaningful and useful.
Consider the environment and project phase in your change control process. If a project is
under development and has never gone to production, the change control process should be
simpler. But even in this case some change control is required so the program team is aware
of changes to other code which may impact what they are trying to do.
For production changes have someone with specific knowledge about the project and how
the application works review the changes before deployment.
Stakeholders must be aware of production changes and/or approve the change. The
stakeholder may approve the change before it is made and someone with detailed project
knowledge may approve the change (and communicate it to required management and staff)
when it is made.
Multiple changes to production software should be bundled into a single change when
possible.
When code is in the project development stage, programmers must check their change in
often. The team must be aware of all areas of code being changed and must meet at least
weekly.
Code change procedures should encourage frequent code check in. Code validation
procedures should not be an administrative nightmare. Code changes should be committed in
logical sections.
Create a process or tool with contact information about those who should be notified about
changes to each specific project. When projects have code changes applied, be sure those
people are contacted either manually or automatically using a tool.
Codelines should have policies specific to the reason for their existence. A production
codeline that has been released should have policy limiting changes to fixes to specific error
types.
Every codeline must have someone in charge of it to make decisions not covered by policies
or processes.
New codelines should be created only when necessary which includes when a different
codeline policy is required.
Track all changes and track all changes to each branch so code changes may be effectively
and efficiently propagated to code branches.
Implement the change control processes based on the Software change Management Policy
Many experts require a change control board to be used for change approval. However, a
change control board may or may not be neccessary or efficient. The need for one should
depend upon the purpose in having one, the environment (development,QA,production)
changes are being made in, the nature of your organization, considerations for efficiency, and
value added by the additional control. A change control board should be used when it adds
value to the change control process. The objectives of the change control process should be
kept in mind when setting up the process and deciding whether to use a change control board.
Objectives are:
Track changes
Ensure quality
Be sure changes are tested
Be sure a backout plan exists
Inform users
There should be many changes of similar type which allows for templates to be used during the
approval process. If a change control board improves the above objectives and it does not
significantly reduce efficiency, it should be used. The board, if structured correctly, could be
used to help users get ready or be aware of the change.
4.11 SOFTWARE CHANGE MANAGEMENT

Change is inevitable in all stages of a software project. Change management will help you direct
and coordinate those changes so they can enhance-not hinder-your software. The only constant in
software development is change. From the original concept through phases of completion to
maintenance updates, a software product is constantly changing. These changes determine
whether the software meets its requirements and the project completes on time and within
budget. One of your main goals as project manager is to manage software change.
4.11.1 Change Management and Configuration Management

Your project probably has software configuration management (SCM) in place. If designed well,
SCM is a major component of software change management. All too often, however, SCM is an
add-on process, focused primarily on capturing the softwares significant versions for future
reference. In the worst cases, SCM functions as a specialized backup procedure. If SCM is left at
this low level, the unfortunate project manager can only watch the changes as they happen,
preach against making bad changes, and hope the software evolves into what it should be. Of
course, evolution is difficult to predict and schedule.
Software change management is the process of selecting which changes to encourage, which to
allow, and which to prevent, according to project criteria such as schedule and cost. The process
identifies the changes origin, defines critical project decision points, and establishes project
roles and responsibilities. You need to define a change management process and policy within
your companys business structure and your teams development process. Change management
is not an isolated process. The project team must be clear on what, when, how, and why to carry
it out.
The relationship between change tracking and SCM is at the heart of change management. SCM
standards commonly define change control as a subordinated task after configuration
identification. This has led some developers to see SCM as a way to prevent changes rather than
facilitate them. By emphasizing the change tracking and SCM relationship, change management
focuses on selecting and making the correct changes as efficiently as possible. In this context,
SCM addresses versions, workspaces, builds, and releases.
A change data repository supports any change management process. When tracking changes,
developers, testers, and possibly users enter data on new change items and maintain their status.
SCM draws on the change data to document the versions and releases, also stored in a repository,
and updates the data store to link changes to their implementation. Software change management
is an integral part of project management. The only way for developers to accomplish their
project goals is to change their software.
4.11.2 Where Changes Originate

A variety of issues drive software changes. Understanding the origins of prospective changes is
the first step in prioritizing them. The sources of change can be classified as planned
development, unexpected problems, or enhancements.
4.11.2.1 Planned Software Development

Ideally, all software change would result from your required and planned development effort,
driven by requirements and specifications, and documented in your design. However, adding
new code is a change you must manage. Adding functions that were not requested (no matter
how useful and clever) consumes project resources and increases the risk of errors downstream.
Even requested features may range in priority from mandatory to nice to have. Monitoring
the cost to implement each request identifies features that adversely affect the projects cost-tobenefit ratio.
4.11.2.2 Unexpected Problems

You will undoubtedly discover problems during any development effort and spend resources to
resolve them. The effort expended and the efforts timing need to be proportional to the problem
- small bugs should not consume your project budget.
The team must determine whether the code fails to implement the design properly or whether the
design or requirements are flawed. In the latter case, you should be sure to correct design or
requirements errors. Integrated change management toolsets, which Ill discuss later in the
article, can make the process seamless: change to a code file can prompt the developer to update
the corresponding documentation files. The investment in documentation updates will be
recovered many times over when the software is maintained later.
4.11.2.3 Enhancements
All software projects are a research and development effort to some extent, so you will receive
enhancement ideas. Here is where project management is most significant: the idea could be a
brilliant shortcut to the project goal, or a wrong turn that threatens project success. As with
requirements or design errors, you need to document these types of changes. Adhere to your
development standards when implementing an enhancement to assure future maintainability.
4.11.3 Critical Decision Points in Change Progress

You should address changes when they are only potential changes, before theyve consumed
project resources. Like any project task, changes follow a life cycle, or change process, that you
must track. In fact, there are three critical decision points in drive any change process. These
decision points form the framework of change management.
4.11.3.1 Approve the Concept

Change requests come from testers or users identifying problems, and from customers adding or
changing requirements. You want to approve all changes before investing significant resources.
This is the first key decision point in any change management process. If you accept an idea,
assign a priority to ensure appropriate resources and urgency are applied.
4.11.3.2 Approve to Proceed

Once youve accepted a change request, evaluate it against your projects current requirements,
specifications, and designs, as well as how it will affect the projects schedule and budget. This
analysis may convince you to revise your priorities. Sometimes, the team will discover that a
complex problem has an elegant solution or that several bugs have a common resolution. The
analysis will also clarify the cost-to-benefit ratio, making the idea more or less desirable. Once
you clarify the facts, make sure the change is properly managed with a second formal review.
4.11.3.3 Approve the Resolution

A change request is completed when the change is folded into the planned development effort.
During requirements analysis and design phases, this may occur immediately after you approve
the request. During coding, however, you often must conduct separate implementation and
testing to verify the resolution for any unplanned changes, including both testing of the original
issue and a logically planned regression test to determine if the change created new problems.
After testing, you must still review the change to ensure it wont negatively affect other parts of
the application. If the testing indicates a risk of further problems, you might want to reject the
change request even at this point.
4.11.3.4 Rejected or Postponed Requests

At any of the decision points, you can decide whether to reject or postpone the change request. In
this case, retain the change request and all associated documentation. This is important because if
the idea comes up again, you need to know why you decided against it before. And, if
circumstances change, you may want to move ahead with the change with as little rework as
possible.
4.11.3.5 Emergency Processing

If a problem has shut down testingor worse, a production systemyou may not have time for
a full analysis and formal decision. Focus this process on an immediate resolution, whether a
code hack or a work-around, that eliminates the shutdown. You can update the change request
to document the quick fix and change it to a lower priority. By leaving the change request open,
you wont omit the full analysis and resolution, but you can properly schedule and manage these
activities. Alternately, you can close the emergency change request when the fix is in place, and
create a new change request to drive a complete resolution.
4.11.4 Roles and Responsibilities

The change management process requires several decision-makers at the various decision points.
Your change management process should address the following questions:
Who will make the decision? Ultimately, the project manager is responsible for these
decisions, but you can delegate some of them to other project leaders.
Who must give input for the decision? Who can give input?
Who will perform the analysis, implementation, and testing? This can be specified
generally, although each issue may require particular contributors.
Who must be notified once the decision is made? When, how, and in how much detail
will the notice be given?
Who will administer and enforce the procedures? Often this becomes a task for SCM or
the release manager, since it directly impacts their efforts.
You dont need to handle all issues at all project stages the same way. Think of the project as
consisting of concentric worlds starting with the development team, expanding to the test team,
the quality team, and finally the customer or user. As your team makes requirements, design, and
software available to wider circles, you need to include these circles in change decisions. For
example, accepting a change to a code module will require retesting the module. You must notify
the test team, who should at least have a say in the scheduling. The standard SCM baselines
represent an agreement between the customer and the project team about the product: initially the
requirements, then the design, and finally the product itself. The customer must approve any
change to the agreed-upon items. The change management process helps you maintain good faith
with the customer and good communication between project members.
4.11.5 Change Management Tools

Because of the volume of data involved, you often need tool support to manage software change.
As with any type of tool, you should get the right tool for your job. Your process should drive
the tool; dont expect the tool to solve the problems alone. Unfortunately, you often dont know
what process you want until youve tried using the wrong tool. Keep in mind that if youre
producing software now, you have at least one process already at work. Identifying the best
current process and the problems with it are the first steps to defining a better process.
A successful system coordinates people, process, and technology. Once you define the process
and tools, ensure that your team is trained and motivated to use them. The best tool is worthless
if it is not used properly, whether from lack of skill or resentment over being forced to use it.
Process and tool training should make the tools benefits clear to your team.
Change managements most important components are an SCM tool and a problem-report and
change-request tracking tool. Increasingly, change management toolsets integrate with one
another and with development tools such as requirements or test case tracing. For example, you
can link a new version directly to the change request it implements and to tests completed against
it.
At the simple and inexpensive end of the tool scale are SCCS (part of most UNIX systems) and
RCS, which define the basics of version control. Various systems build on these, including CVS
and Suns TeamWare, adding functions such as workspace management, graphical user
interface, and (nearly) automatic merging. In the midrange are products such as Microsofts
SourceSafe, Merants PVCS, MKS Source Integrity, and Continuus/CM, which generally
provide features to organize artifacts into sets and projects. Complete SCM environments are
represented by Platinums CCC/Harvest and Rationals ClearCase, giving full triggering and
integration capabilities.
4.11.6 SCM Tools

SCM tools range from simple version engines, like SCCS, to sophisticated environments, like
Rationals ClearCase, that provide for all SCM functions. Generally, the most significant
selection factor is the complexity of your development plan: how much parallel work the tool
must support and how many versions it must track. If your project involves changing the same
code in two different ways simultaneously (for example, maintaining the production version
while developing the next release), carefully review how the tool handles branches and merges.
Most tools lock files while they are being updated; if simultaneous change is your norm, look for
tools that provide either a change-and-merge or a change-set process model. Performance and
scalability are also issues for large projects. The larger the number of files in your project, the
more you need features like directory archival and logical links between artifacts. These links
that let code updates prompt the developer to update documentation. With a large project team,
you need triggers to automate notification and other coordinated actions.
You should go into demos with a sketch of how your development process works, especially if
youre considering a significant tool expenditure. This lets you ask specifically how the tool
could handle your needs. The tool budget will need to include the effort to define and document
procedures, write scripts and integration artifacts, and train the team. If the tool is new to your
organization, verify that the vendor can support your implementation or recommend a consultant
who can.
4.11.7 Problem-Report and Change-Request Tracking

The key to a good issue tracking system is the ability to tailor it to your process and standards.
Every project tends to want different report fields, called by different names, taking different
values. Too much variation from these expectations cause even a good tracking tool to seem
counterintuitive and frustrating. If your team doesnt like to use the tool, you wont get the
complete tracking that you need. If you currently have a tracking system (even paper-based), use
it as a pattern for what you want. If youre starting from scratch, think through the change
process and ask what information the participants need.
As with other tools, estimate the volume of data the tool needs to handle and verify that it will
perform at that level. Consider how many individuals need to use the tool at one time and
whether you need strict controls over who can change various parts of the data. If you conduct
your reviews in meetings, report generation will be a significant part of tool use. For an
electronic approval cycle, the e-mail interface is vital. Increasingly, tools are providing a web
interface to simplify distributed use.
4.11.8 Key to Change Management

Change management lets you control software evolution and provides the basis for metrics and
process improvement. Data collected under a consistent process supports estimating and
planning, reducing risk, and making development more predicable. In the long run, managed
change reduces the time to market, improves quality, and increases customer satisfaction. By
understanding the origins of change, the critical decision points, and the roles in the decision
process, you will gain enough control to manage, rather than just watch, software change.
4.12 SOFTWARE CHANGE CONTROL PROCEDURES

A software application goes through phases before it is finally released on the market. These
phases include design, development, testing, and implementation. Even though the software
application has gone through these phases, it is still never finished. This is because the client or
customer will want to make changes to it. It could be adding a new field, new group with
different access rights or upgrades. If a company is smart, it will have software change control
procedures in place. These procedures help to control the number of change requests so that they
don't get out of control.
4.12.1 Initiating the Change

The customer or client submits a change request. The software development process usually has
a change manager or change management team. Large companies tend to have a change
management team or board, while the small company might have a change manager. The change
manager or team will usually assess the request before making a decision. It will ask questions.
Will the change take a lot of work? How many resources will be needed to implement the
change? The change manager or team might also meet with stakeholders to go over the change
request. Stakeholders are people who have a stake in the project. These can be managers, such as
department managers, project managers, program managers or portfolio managers. If the person
or team approves the change, the software development team will start to work on the request.
4.12.2 Working on the Change Request

Before the software development team starts to work on the change request, it should use a
system or tool to track changes. According to Software Change Control, the methodology should
not only track changes, but should also have a backup plan if the request does not work.
Throughout the process, the team should be communicating with the stakeholders, such as giving
them progress reports.
4.12.3 Testing the Change Request

The software development team should not implement the change into the live environment until
it has been tested. The team should insert the change into a development session. No one should
have access to this except the developers. If the change is correct, then the team moves the
request over to the test session. The testing group or quality control tests the request. If it's
correct, the software development team meets with the change team or manager to report that the
change is correct and is ready to go into production. If everyone agrees, the software
development team moves the request over to production.
4.13 DEFECT MANAGEMENT

Software defects are expensive. Moreover, the cost of finding and correcting defects represents
one of the most expensive software development activities. For the foreseeable future, it will not
be possible to eliminate defects. While defects may be inevitable, we can minimize their number
and impact on our projects. To do this development teams need to implement a defect
management process that focuses on preventing defects, catching defects as early in the process
as possible, and minimizing the impact of defects.
4.13.1 What is a defect?

As discussed earlier, defect is the variance from a desired product attribute (it can be a wrong,
missing or extra data). It can be of two types Defect from the product or a variance from
customer/user expectations. It is a flaw in the software system and has no impact until it affects
the user/customer and operational system.
4.13.2 What are the defect categories?

With the knowledge of testing so far gained, you can now be able to categorize the defects you
have found. Defects can be categorized into different types basing on the core issues they
address. Some defects address security or database issues while others may refer to functionality
or UI issues.
Security Defects: Application security defects generally involve improper handling of data sent
from the user to the application. These defects are the most severe and given highest priority for
a fix.
Examples:
- Authentication: Accepting an invalid username/password
- Authorization: Accessibility to pages though permission not given
Data Quality/Database Defects: Deals with improper handling of data in the database.
Examples:
- Values not deleted/inserted into the database properly
- Improper/wrong/null values inserted in place of the actual values
Critical Functionality Defects: The occurrence of these bugs hampers the crucial functionality
of the application.
Examples:- Exceptions
Functionality Defects: These defects affect the functionality of the application.
Examples:
- All Javascript errors
- Buttons like Save, Delete, Cancel not performing their intended functions
- A missing functionality (or) a feature not functioning the way it is intended to
- Continuous execution of loops
User Interface Defects: As the name suggests, the bugs deal with problems related to UI are
usually considered less severe.
Examples:
- Improper error/warning/UI messages
- Spelling mistakes
- Alignment problems
4.13.3 Defect Management Process

The defect management process is based on the following general principles:
The primary goal is to prevent defects. Where this is not possible or practical, the goals
are to both find the defect as quickly as possible and minimize the impact of the defect.
The defect management process should be risk driven -- i.e., strategies, priorities, and
resources should be based on the extent to which risk can be reduced.
Defect measurement should be integrated into the software development process and be
used by the project team to improve the process. In other words, the project staff, by
doing their job, should capture information on defects at the source. It should not be
done after-the-fact by people unrelated to the project or system
As much as possible, the capture and analysis of the information should be automated.
Defect information should be used to improve the process. This, in fact, is the primary
reason for gathering defect information.
Most defects are caused by imperfect or flawed processes. Thus to prevent defects, the
process must be altered.
4.13.3 Steps in Defect Management Process

There are various steps in defect management process. The following figure represents the steps.
Figure 4.1: Steps in defect management process
4.13.3.1 Defect Prevention - Implementation of techniques, methodology and standard processes

to reduce the risk of defects.
4.13.3.2 Deliverable Baseline - Establishment of milestones where deliverables will be

considered complete and ready for further development work. When a deliverable is baselined,
any further changes are controlled. Errors in a deliverable are not considered defects until after
the deliverable is baselined.
4.13.3.3 Defect Discovery - Identification and reporting of defects for development team
acknowledgment. A defect is only termed discovered when it has been documented and
acknowledged as a valid defect by the development team member(s) responsible for the
component(s) in error.
4.13.3.4 Defect Resolution - Work by the development team to prioritize, schedule and fix a
defect, and document the resolution. This also includes notification back to the tester to ensure
that the resolution is verified.
4.13.3.5 Process Improvement - Identification and analysis of the process in which a defect
originated to identify ways to improve the process to prevent future occurrences of similar
defects. Also the validation process that should have identified the defect earlier is analyzed to
determine ways to strengthen that process.
4.13.3.6 Management Reporting - Analysis and reporting of defect information to assist

management with risk management, process improvement and project management.
4.14 The Elements of defect Management Process

The defect management process contains the following elements:
4.14.1 Defect Discovery Identification and reporting of potential defects. The defect tracking
software must be simple enough so that people will use it, but ensure that the minimum
necessary information is captured. The information captured here should be enough to reproduce
the defect and allow development to determine root cause and impact.
4.14.2 Defect Analysis & Prioritization The development team determines if the defect report
corresponds to an actual defect, if the defect has already been reported, and what the impact and
priority of the defect is. Prioritization and scheduling of the defect resolution is often part of the
overall change management process for the software development organization.
4.14.3 Defect Resolution Here the development team determines the root cause, implements
the changes needed to fix the defect, and documents the details of the resolution in the defect
management software, including suggestions on how to verify the defect is fixed. In
organizations using software product lines approaches, or other shared component approaches,
defect resolution may need to be coordinated across multiple branches of development.
4.14.4 Defect Verification The build containing the resolution to the defect is identified, and
testing of the build is performed to ensure the defect truly has been resolved, and that the
resolution has not introduced side effects or regressions. Once all affected branches of
development have been verified as resolved, the defect can be closed.
4.14.5 Communication This encompasses automatic generation of defect metrics for
management reporting and process improvement purposes, as well as visibility into the presence
and status of defects across all disciplines of the software development team.
4.15 SUMMARY
Software testing is the process of testing software product. Effectiveness software testing will
contribute to the delivery of higher quality software products, more satisfied users, lower
maintenance costs, more accurate and reliable results. However, ineffective testing will lead to
the opposite results; low quality products, unhappy users, increased maintenance costs,
unreliable and inaccurate results. Hence, software testing is necessary and important activity of
software development process. Good testing involves much more than just running the program a
few times to see whether it works. Through analysis of a program helps us to test more
systematically and more effectively. Change is inevitable in all stages of a software project.
Change management will help you direct and coordinate those changes so they can enhance
not hinderyour software. There is very much need to control software change. Software
change management provides much guidelines in this way. Software verification and validation
should show that the product conforms to all the requirements. Users will have more confidence
in a product that has been through a rigorous verification programme than one subjected to
minimal examination and testing before release.
Assignment-Module 4
1.
Software mistakes during coding is known as

a. Failures
b. Defects
c. Bugs
d. Errors
2.
Detect software failures so that defects may be discovered and corrected.

a. Software Testing
b. Software Engineering
c. Software Maintenance
d. Software Quality
3.
___________ tests internal structures or workings of a program, as opposed to the
functionality exposed to the end-user.

a. Transparent box testing
b. Black box testing
c. Static testing
d. Dynamic testing
4.
The tester is only aware of what the software is supposed to do, not how it does it.
a. White box testing
c. Static testing
d. Dynamic testing
5.
"Like a walk in a dark labyrinth without a flashlight.

a. White box testing
c. Static testing
d. Dynamic testing
6.
___________verify the functionality of a specific section of code, usually at the
function level.
a. Integration testing
b. System testing
c. Functional Testing
d. Component testing
7.
___________expose defects in the interfaces and interaction modules.

a. Unit testing
b. Module testing
c. Integration testing
d. Acceptance testing
8.
Alpha and Beta testing techniques are related to

a. System testing
b. Unit testing
c. Integration testing
d. Acceptance testing
9.
Artifacts include
a. Requirements documentation
b. Coding
c. Both of them
d. None of them
10.
Test suite is
a. Collection of test cases
b. Collection of inputs
c. Collection of outputs
d. None of them
11.
Cause effect graphing technique is one form of

a. Maintenance testing
b. Structural testing
c. Function testing
d. Regression testing
12.
During validation
a. Process is checked
b. Product is checked
c. Developers performance evaluated
d. Customer checks product
13.
Verification is
a. Checking product with respect to customers expectation.
b. Checking product with respect to specification.
c. Checking product with respect to constraints of the project.
d. All of the above
14.
Validation is
a. Checking product with respect to customers expectation.
b. Checking product with respect to specification.
c. Checking product with respect to constraints of the project.
d. All of the above
15.
Testing the software is basically

a. Verification
b. Validation
c. Verification and validation
d. None of them
Key - Module 4
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CHAPTER 5 METRICS AND MEASUREMENT OF

SOFTWARE QUALITY
5.1 MEASURING SOFTWARE QUALITY
In the past decade, the open source model of software development has gained tremendous
visibility and validation though popular projects like Linux, Apache, and MySQL. This new
model, based on the many eyes approach, has led to fast evolving, easy to configure software
that is being used in production environments by countless commercial enterprises. However,
how exactly (if at all) do consumers of open source measure the quality and security of any piece
of software to determine if it is a good fit for their stack? Few would disagree that many eyes
reviewing code is a very good way to reduce the number of defects. However, no effective
yardstick has been available to measure how good the quality really is. In this study, we propose
a new technique and framework to measure the quality of software. This technique leverages
technology that automatically analyzes 100% of the paths through a given code base, thus
allowing a consistent examination of every possible outcome when running the resulting
software. Using this new approach to measuring quality, we aim to give visibility into how
various open source projects compare to each other and suggest a new way to make software
better.
5.1.1 Measuring quality automatically

No metric is perfect. This report does not propose the results of source code analysis as an
absolute measure of quality, but rather as a new and effective way to assess code quality directly
in terms of the number of software defects. No automated analysis can detect all of the bugs in a
piece of software. However, many program level defects fall into the range of bugs that we can
detect, making our results not only a good measure of the overall quality, but also a standard and
repeatable metric with which to compare two code bases. Furthermore, the advances made
recently in terms of scalability, low false positive rate, and ease of integration allow us, for the
first time, to plug in dozens of open source packages to be analyzed with little human
intervention required.
Rather than using metrics such as cyclomatic complexity to indirectly tell us the quality of code,
we rely on actionable, easy to verify defect cases that pinpoint the root cause and exact path to a
software problem. Compare the two approaches here:
Cyclomatic complexity framework
(1) Function foo has too many paths through it.
Coverity framework
(2) Function foo has a memory leak on line 73 that is the result of an allocation on line 34 and
the following path decisions on lines 38, 54, and 65 ..
Our belief is that a metric based on the latter is much more valuable in measuring source code
quality. Today, many open source packages rely on our static source code analysis as a key
indicator of reliability and security. For example, MySQL, PostgreSQL, and Berkeley DB have
certified versions of their software that contain zero Coverity defects.
5.2 SOFTWARE METRICS

Software metric is a measure of some property of a piece of software or its specifications. Since
quantitative measurements are essential in all sciences, there is a continuous effort by computer
science practitioners and theoreticians to bring similar approaches to software development. The
goal is obtaining objective, reproducible and quantifiable measurements, which may have
numerous valuable applications in schedule and budget planning, cost estimation, quality
assurance testing, software debugging, software performance optimization, and optimal
personnel task assignments. Software metrics measure different aspects of software complexity
and therefore play an important role in analyzing and improving software quality. Various
research has indicated that they provide useful information on external quality aspects of
software such as its maintainability, reusability and reliability. Software metrics provide a mean
of estimating the efforts needed for testing. Software metrics are often categorized into products
and process metrics.
5.3 TYPE OF SOFTWARE METRICS:

Process Metrics: Process metrics are known as management metrics and used to measure the
properties of the process which is used to obtain the software. Process metrics include the cost
metrics, efforts metrics, advancement metrics and reuse metrics. Process metrics help in
predicting the size of final system & determining whether a project on running according to the
schedule.
Figure 5.1: Software Metrics
Products Metrics: Product metrics are also known as quality metrics and is used to measure the
properties of the software. Product metrics includes product non reliability metrics, functionality
metrics, performance metrics, usability metrics, cost metrics, size metrics, complexity metrics
and style metrics. Products metrics help in improving the quality of different system component
& comparisons between existing systems.
5.4 ADVANTAGE OF SOFTWARE METRICS:

In Comparative study of various design methodology of software systems.
For analysis, comparison and critical study of various programming language with
respect to their characteristics.
In comparing and evaluating capabilities and productivity of people involved in software
development.
In the preparation of software quality specifications.
In the verification of compliance of software systems requirements and specifications.
In making inference about the effort to be put in the design and development of the
software systems.
In getting an idea about the complexity of the code.
In taking decisions regarding further division of complex module is to be done or not.
In providing guidance to resource manager for their proper utilization.
In comparison and making design tradeoffs between software development and
maintenance cost.
In providing feedback to software managers about the progress and quality during various
phases of software development life cycle.
In allocation of testing resources for testing the code.
5.5 LIMITATION OF SOFTWARE METRICS:

The application of software metrics is not always easy and in some cases it is difficult
and costly.
The verification and justification of software metrics is based on historical/empirical data
whose validity is difficult to verify.
These are useful for managing the software products but not for evaluating performance
of the technical staff.
The definition and derivation of Software metrics is generally based on assuming which
are not standardized and may depend upon tools available and working environment.
Most of the predictive models rely on estimates of certain variables which are often not
known exactly.
Most of the software development models are probabilistic and empirical.
5.6 SIZE METRICS

Line of Code: It is one of the earliest and simpler metrics for calculating the size of computer
program. It is generally used in calculating and comparing the productivity of programmers.
Productivity is measured as LOC/man-month.
Any line of program text excluding comment or blank line, regardless of the number of
statements or parts of statements on the line, is considered a Line of Code.
Figure 5.2: Classification of Software Metrics
Token Count:
In this metrics, a computer program is considered to be a collection of tokens, which may be
classified as either operators or operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as token. The basic measures are
n1 = count of unique operators.
n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.
In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2
Function Count:
The size of a large software product can be estimated in better way through a larger unit
called module. A module can be defined as segment of code which may be compiled
independently.
For example, let a software product require n modules. It is generally agreed that the size of
module should be about 50-60 line of code. Therefore size estimate of this Software product
is about n x 60 line of code.
5.7 SCIENCE METRICS

Halsteads model also known as theory of software science, is based on the hypothesis that
program construction involves a process of mental manipulation of the unique operators (n1) and
unique operands (n2). It means that a program of N1 operators and N2 operands is constructed
by selecting from n1 unique operators and n2 unique operands. By using this Model, Halstead
derived a number of equations related to programming such as program level, the
implementation effort, language level and so on. An important and interesting characteristics if
this model is that a program can be analyzed for various feature like size, efforts etc.
Program vocabulary is defined as n = n1 + n2

And program actual length as N = N1 + N2
One of the hypothesis of this theory is that the length of a well-structured program is a function
of n1 and n2 only. This relationship is known as length prediction equation and is defined as
Nh = n1 log2 n1 + n2 log2 n2
The following length estimators have been suggested by some other researchers:
Jensens Program Length Estimator [N1]

It is described as
N1 = Log2 (N1!) + Log2 (n2!)
It was applied and validated by Jensen and Vairavan for real time application programs written
in Pascal and found even more accurate results than Halsteads estimator.
Zipfs Program Length Estimator [Nz]

Nz = n [0.5772 + ln (n) ]
where n is program vocabulary given as n = n1 + n2
Bimleshs Program Length Estimator [Nb]
Nb = n1 Log2 (n2) + n2 Log2 (n1)
where n1 : Number of unique operators which include basic operators, keywords/reserve- words
and functions/procedures.
n2 : Number of unique operands.
Program Volume (V)

The programming vocabulary n = n1 + n2 leads to another size measures which may be defined
as :
V = N log 2 n
Potential Volume (V*)
It may be defined as V* = (n1* + n2 *) log2 (n1* + n2 *)
Where n1* is the minimum number of operators and n2* is the minimum number of operands.
5.8 FLOW METRICS

McCabes Cyclomatic Metric: McCabe interprets a computer program as a set of strongly
connected directed graph. Nodes represent parts of the source code having no branches and arcs
represent possible control flow transfers during program execution.
The notion of program graph has been used for this measure and it is used to measure and control
the number of paths through a program. The complexity of a computer program can be correlated
with the topological complexity of a graph.
McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software
complexity. The cyclomatic number is equal to the number of linearly independent paths through
a program in its graphs representation. For a program control graph G, cyclomatic number, V
(G), is given as:
V (G) = E N + P
E = The number of edges in graphs G
N = The number of nodes in graphs G
P = The number of connected components in graph G.
Stetters Program Complexity Measure: Stetters metric accounts for the data flow along with
the control flow of the program which can be calculated from the source code. So it may be view
as a sequence of declaration and statements. It is given as
P = (d1, d2, -------- , dk s1 , s2, ---------------, sm)
Where ds are declarations
ss are statements
P is a program
Here, the notion of program graph has been extend to the notion of flow graph. A flow graph of a
program P can be defined as a set of nodes and a set of edges. A node represents a declaration or
a statement while an edge represents one of the following:
1 Flow of control from one statement node say si to another sj.
2 Control flow from a statement node dj to a statement node si which is declared in dj.
3 Flow from a declaration node dj to statement node si through a read access of a variable or a
constant in si which is declared in dj.
This measure is defined as F(P) = E ns + nt
Where ns = number of entry nodes
nt = number of exit nodes.
5.9 INFORMATION FLOW METRICS

Information Flow metrics deal with this type of complexity by observing the flow of
information among system components or modules. This metrics is given by Henry and
Kafura. So it is also known as Henry and Kafuras Metric.
This metrics is based on the measurement of the information flow among system modules. It
is sensitive to the complexity due to interconnection among system component. This measure
includes complexity of a software module is defined to be the sum of complexities of the
procedures included in the module. A procedure contributes complexity due to the following
two factors.
1. The complexity of the procedure code itself.
2. The complexity due to procedures connections to its environment. The effect of the first
factor has been included through LOC (Lin Of Code) measure. For the quantification of second
factor, Henry and Kafura have defined two terms, namely FAN-IN and FAN-OUT.
FAN-IN of a procedure is the number of local flows into that procedure plus the number of data
structures from which this procedure retrieve information.
FAN OUT is the number of local flows from that procedure plus the number of data structures
which that procedure updates.
Procedure Complexity = Length * (FAN-IN * FAN-OUT) **2
Where the length is taken as LOC and the term FAN-IN *FAN-OUT represent the total number
of input output combinations for the procedure.
Metrics, for both process and software, tell us to what extent a desired characteristic is present in
our processes or our software systems. Maintainability is a desired characteristic of a software
component and is referenced in all the main software quality models (including the ISO 9126).
One good measure of maintainability would be time required to fix a fault. This gives us a handle
on maintainability but another measure that would relate more to the cause of poor
maintainability would be code complexity. A method for measuring code complexity was
developed by Thomas McCabe and with this method a quantitative assessment of any piece of
code can be made. Code complexity can be specified and can be known by measurement,
whereas time to repair can only be measured after the software is in support. Both time to repair
and code complexity are software metrics and can both be applied to software process
improvement.
5.10 PROBLEM WITH METRICS

It is not enough to simply create a metric. The measure should accurately reflect the process. We
use metrics to base decisions on and to focus our actions. It is not only important to measure the
right indicators, it is important to measure them well. To be effective and reliable, the metrics
we choose to use need to have ten key characteristics. The following table suggests the qualities
to look for in indicators.
A good measure
Description
Is quantitative
The measure can be expressed as an objective value
Is easy to understand
The measure conveys at a glance what it is measuring,

and how it is derived
Encourages
appropriate behaviour
The measure is balanced to reward productive behavior

and discourage game playing
Is visible
The effects of the measure are readily apparent to all

involved in the process being measured
Is
defined
and The measure has been defined by and/or agreed to by all
mutually understood
key process participants (internally and externally)
Encompasses
both The measure integrates factors from all aspects of the
outputs and inputs
process measured
Measures only what is The measure focuses on a key performance indicator that
important
is of real value to managing the process
Is multidimensional
Uses economies
effort
Facilitates trust
The measure is properly balanced between utilization,

productivity, and performance, and shows the trade-offs
of The benefits of the measure outweigh the costs of
collection and analysis
The measure validates the participation among the
various parties
Choosing the right metrics is critical to success, but the road to good metrics is fraught with
pitfalls. As your endeavours to become more metrics-driven, beware of errors in the design and
use of metrics.
5.10.1 Common mistakes include:

Metrics for the sake of metrics (not aligned)
Too many metrics (no action)
Metrics not driving the intended action
Lack of follow up
No record of methodology
No benchmark
Underestimation of the data extraction
Although there may never be a single perfect measure, it is certainly possible to create a measure
or even multiple measures which reflect the performance of your system. If the metrics are
chosen carefully, then, in the process of achieving their metrics, managers and employees will
make the right decisions and take the right actions that enable the organization to maximize its
performance. These guidelines will make sure you pick the right indicators and measure them
well.
5.10.2 The main points with metrics are:

i.
Dont mistake metrics for what were actually trying to measure: metrics are proxies
especially if we are trying to measure something abstract like innovation, or the quality of
universities. So dont get too hung up on your metrics concentrate on your overall goal.
ii.
Align metrics with strategy: no one really wants twitter followers. You want something
else influence, or interaction, or something that one way or another actually does you
some good. The interim steps are important, but dont only measure these. You also need
to figure out a way to measure the outcomes of your strategy.
iii.
Use multiple measures of success: this follows from the first two points. Most of the
things that we really care about are hard to actually measure. If we are going to try, we
need to use multiple measures so that we can triangulate on our desired objectives.
5.10.3 Characteristics of Good Metrics

5.10.3.1 Quality of the Metric
i.
Valid: clearly related to the feature being measured e.g. monotonically increases as the
feature increases
ii.
Objective: independent of personal opinion
iii.
Reproducible: measurements can be consistently repeated
iv.
Precise: sensitive to changes in the feature measured
v.
Robust: not easily manipulated or sensitive to extraneous factors
vi.
Comparable: highly correlated with other metrics measuring the same feature
vii.
Universal: can be translated into sub-metrics for lower parts of the product or process
5.10.3.2 Costs of the Metric

i.
Economical: does not consume significant resources for collection; preferably a biproduct of other activities
ii.
Standardised: the metric uses a mathematically appropriate scale
iii.
Sustainable: likely to be valid in the future so that trend forecasts based on the metric will
be effective
iv.
Cost-Effective: benefits from the data obtained justify the cost of gathering that data
v.
Useful: supports the goals of the organisation
5.11 OBJECTIVE AND SUBJECTIVE MEASUREMENT

A question that often arises during the planning of an experiment or a test is whether to obtain
objective performance data or subjective data, e.g. data related to preference setting. Objective
performance data are usually preferred for experiments. In addition, they are required for design
evaluations whenever the evaluation criteria are objective. Unfortunately, however, objective
measurements are frequently more difficult even impossible - to carry out, and the process of
collecting objective data is usually more time-consuming and costly. In contrast, subjective data
may be obtained easily, quickly, and inexpensively. The subjective measurement technique also
provides the only direct means for the assessment of user opinion and preferences. The sources
of objective data that are frequently used in user trials can be divided into three categories:
i.
direct objective measurements of the user,
ii.
directly recorded data resulting from users actions, registered by the investigator or by
some remote means, such as video or automatic event recording,
iii.
data measured directly from the product on the completion of or during the trial.
Many kinds of objective data can be measured when, for instance, all the components of a
balanced system are considered. This system is applicable to both working and living contexts in
the field. The same fact is often relevant in simulations.
The typical methods used in subjective measurement are:
ranking methods,
rating methods,
questionnaire methods
interviews
checklists.
However, subjective data and preference data must be interpreted with caution. Following points
should be considered when evaluating subjective data:
If the subjects in experiments and tests do not fit the user profile compiled during the planning
phase, their opinions and preferences may not accurately reflect those of the intended users of the
product. Conclusions based on data obtained from inappropriate subjects may not be valid.
Attitude measures and self-reports may be distorted by biasing factor.
Subjects preferences are affected by events in the recent past.
Collection of both objective and subjective data during experiments and tests whenever
feasible.
Collecting subjective data will add little to the cost of the study, but may provide
significant insights not obtainable by objective methods.
Subjective data may be particularly useful if objective measurements fail to detect any
differences between conditions.
5.11.1 Objective Quality Assessment

In order to provide an automatic evaluation and monitoring of video data quality, reliable and
objective metrics are required. By contrast to subjective measurements, the objective quality
metrics are based purely on mathematical methods, from quite simplistic ones, like Peak Signalto-Noise Ratio (PSNR) and the Mean Squared Error (MSE), to sophisticated ones that exploit
models of human visual perception and produce results far more consistent with the subjective
evaluation, like the Structural Similarity Index Method (SSIM). In other words, the objective
video quality measurement is done by software which processes the video signals in order to
obtain a video quality score. Thus, this type of video quality metric is more advantageous as it
could provide real time quality monitoring for video applications. The measurement of the video
distortions in a video communication system can be performed in two ways:
Data metrics: In order to measure the amount of distortion introduced by the capture,
compression and transmission processes, these metrics take into account only the signal
reliability without considering the content of the video under analysis.
Picture metrics: This distortion measurement is focused on the content of the video under
analysis, i.e., this approach allows quantifying the effect of distortions and content on
perceived quality. In this case, these metrics are closer to the human perceived quality than
the Data metrics method.
5.11.2 Subjective Quality Assessment

The subjective video quality assessment is recognized as the most reliable mean of quantifying
user perception since human beings are the ultimate receivers in most applications. The Mean
Opinion Score (MOS), which is a subjective quality measurement obtained from a group of
viewers, has been regarded for many years as the most consistent form of quality measurement.
However, this quality measurement has some disadvantages. These disadvantages are related
with the fact that the MOS method is expensive and highly time consuming for most applications
and cannot be executed automatically.
5.12 MEASURES OF CENTRAL TENDENCY

5.12.1 Definition of Measures of Central Tendency
A measure of central tendency is a measure that tells us where the middle of a bunch of data lies.
The three most common measures of central tendency are the mean, the median, and the mode.
5.12.2 More about Measures of Central Tendency

i.
Mean: Mean is the most common measure of central tendency. It is simply the sum of the
numbers divided by the number of numbers in a set of data. This is also known as
average.
ii.
Median: Median is the number present in the middle when the numbers in a set of data
are arranged in ascending or descending order. If the number of numbers in a data set is
even, then the median is the mean of the two middle numbers.
iii.
Mode: Mode is the value that occurs most frequently in a set of data.
5.12.3 Examples of Measures of Central Tendency

For the data 1, 2, 3, 4, 5, 5, 6, 7, 8 the measures of central tendency are
Mean =
Median = 5
Mode = 5
5.12.4 Example on Measures of Central Tendency

Find the measures of central tendency for the data set 3, 7, 9, 4, 5, 4, 6, 7, and 9.
Solution:
Step 1: Mean, median and mode of a data set are the measures of central tendency.
Step 2: Mean of the data set =
[Formula.]
Step 3:
[Substitute the values.]
Step 4:
[Add the data values in the numerator and divide.]
Step 5: The data set in the ascending order is 3, 4, 4, 5, 6, 7, 7, 9, and 9. So, Median of the set is
6.
[Median is the middle data value of the ordered set.]
Step 6: Mode is/are the data value(s) that appear most often in the data set. So, the modes of the
data set are 4, 7 and 9.
Step 7: So, the measures of central tendency of the given set of data are mean = 6, median = 6
and modes are 4, 7, and 9.
5.12.5 Properties of a good measure of central tendency are:i.
It should be rigidly defined.
ii.
It should include all observations.
iii.
it should be simple to understand and easy to calculate.
iv.
it should be capable of further mathematical treatment.
v.
It should be least affected by extreme observations.
vi.
it should possess sampling stability.
5.12.6 Characteristics of Good Measurement

As we have clearly established, software metrics in and of themselves are vacuous. They only
have meaning based on their relationship with some type of criterion measure. Therefore, the
first step in establishing a good software measurement program is to define one or more software
quality criterion measures. We might choose, for example, to measure software faults. That said,
then we must establish a good unambiguous standard for enumerating these faults. This will
insure that everyone in the organization will report them in exactly the same way. Even better,
we could build a tool that would extract these fault data for us given a completely unambiguous
definition of the notion of a software fault. Further, we will realize that there are faults
attributable to problems in the requirements document, in the software design documents, or in
the code itself. Once we have established a meaningful standard and measurement methodology,
we are then in a position to begin to collect measurement data for program products. Again, we
will choose metric primitives that we know are closely related to our criterion measure. We will
then choose a measurement tool that will produce these data for us. A good software metric
program will be built into the software build process itself. A program going through a series of
builds is evolving. This means that the metrics for each program module may be changing in this
process. We must be able to know what the metrics are for all modules of each program build.
This means that the measurement process itself must be continuous.
5.13 INSTALLING THE MEASUREMENT PROGRAM

Installation of a measurement program is a four-phased approach, with each phase containing
multiple steps.
5.13.1 Build the Measurement base

The objective of this phase is to create an environment in which the use of quantitative data is an
accepted component of the management process. The four steps for accomplishing this are:
i.
Define the objectives for the measurement program - how it is to be used. Consider how
to implement the four uses of measurement, given the maturity level of the organization.
The use of measurement should be tied to the organizations mission, goals and
objectives.
ii.
Create an environment receptive to measurement. Begin with the prerequisites listed

earlier in this section. Establish service level agreements between IT and the users to
define quality and productivity that must be defined before they can be measured. People
involved with the measurement should help develop the measure. Establish a quality
management environment
and ensure the work processes being used have been
implemented.
iii.
Define the measurement hierarchy, which has three levels of quantitative data: measures,
metrics, and a strategic results dashboard (also called key indicators). This measurement
hierarchy maps to a three-level IT organizational tier: staff, line management and senior
management. IT staff collects basic measures, such as product size, cycle time, or defect
count. IT line management uses fundamental metrics, such as variance between actual
and budgeted cost, user satisfaction or defect rates per LOC to manage a project or part of
the IT function. Senior management uses a strategic results dashboard, where the metrics
represent the quantitative data needed to manage the IT function and track to the mission,
vision, or goals. For example, a mission with a customer focus should have a customer
satisfaction metric. A metric of the number of projects completed on time gives insight
into the function's ability to meet short and long-term business goals.
iv.
Define the standard units of measurement (discussed in Measurement Concepts).
5.13.2 Manage towards results.

In this five-step phase, goals for the desired business results are identified in the form of a
strategic dashboard, and the means for measuring those results are determined. The business
results need to be prioritized and communicated to the entire IT function so that decisions will be
made in a manner that will facilitate achieving those results. This is particularly critical when the
third phase is implemented, as the process results should link to the desired business results.
i.
Identify desired business results, beginning with a mission or vision statement. Turn
operative phrases in the mission or vision (such as deliver on time or satisfy
customer) into specific objectives (such as "all software will be delivered to the
customer by the date agreed upon with the customer"), and then rank these objectives in
order of importance. When objectives are written with a subject, action, target value, and
time frame it is much easier to identify the actual metric that will serve as the results
metric or key indicator.
ii.
Identify current baselines by determining the current operational status for each of the
desired business results/objectives.
iii.
Select a measure or metric for each desired business result or objective, and determine
whether it has been standardized by the IT industry (such as cycle time, which is
measured as elapsed calendar days from the project start date to the project end date). If
not, explore the attributes of the result or objective and define a measure or metric that is
quantitative, valid, reliable, attainable, easy to understand and collect, and a true
representation of the intent. Ideally there should be three to five metrics, with no more
than seven. Convert the business results metrics into a strategic dashboard of key
indicators. Examples of indicators includes productivity, customer satisfaction,
motivation, skill sets, and defect rates.
iv.
Consider trade-offs between the number one ranked business result and the other desired
results. For example, the #1 result to complete on time will affect other desired results,
such as minimize program size and develop easy-to-read documentation.
v.
Based on the baseline and desired business result or objective, determine a goal for each
result metric. Goals typically specify a subject (such as financial, customer, process or
product, or employee) and define an action that is change or control related (such as
improve or reduce, increase or decrease or control or track). If a baseline for on time
projects is 60%, the goal might be to increase to 80% by next year. Benchmarking can
also be useful prior to setting goals, as it allows an understanding of what is possible
given a certain set of circumstances.
5.13.3 Manage by process.

Managing by process means to use processes to achieve management's desired results. When
results are not achieved, a quality management philosophy tells the organization to look at how
the system (i.e., its processes) can be improved rather than reacting, making emotional decisions,
and blaming people. Quantitative feedback, which provides indicators of process performance, is
needed in order to operate this way. Various processes usually contribute jointly to meeting
desired business results, and, therefore, it is important to understand and identify what things
contribute to, or influence, desired results. This phase consists of four steps to implement
measurement in a process, and to identify the attributes of the contributors, which if met will
achieve the desired process results. These steps provide the information to manage a process and
to measure its status.
i.
Develop a matrix of process results and contributors to show which contributors drive
which results. The results should come from the process policy statement. The
contributors can be positive or negative, and involve process, product, or resource
attributes. Process attributes include characteristics such as time, schedule, and
completion. Product attributes include characteristics such as size, correctness, reliability,
usability, and maintainability. Resource attributes include characteristics such as amount,
skill, and attitude. A cause-and-effect diagram is often used to graphically illustrate the
relationship between results and contributors.
ii.
Assure process results are aligned to business results. Processes should help people
accomplish their organizations mission. Alignment is subjective in many organizations,
but the more objective it is, the greater the chance that processes will drive the mission.
iii.
Rank the process results and the contributors from a management perspective. This will
help workers make trade offs and identify where to focus management attention.
iv.
Select metrics for both the process results and contributors, and create two tactical
process dashboards: one for process results and one for contributors. These dash boards
are used to manage the projects and to control and report project status. Normally results
are measured subjectively and contributors are measured objectively. For example, for a
result of customer satisfaction, contributors might include competent resources, an
available process, and a flexible and correct product. Sometimes, as with customer
satisfaction, factors that contribute to achieving the result can actually be used to develop
the results metric. In other words, first determine what contributes to customer
satisfaction or dissatisfaction and then it can be measured.
5.13.4 Management by fact.

Management by fact uses qualitative and quantitative data produced from, and about, work
processes to make informed decisions regarding the operation of those work processes.
Quantitative data can be objective (such as the number of defects produced) or subjective (such
as the customers perception of the quality of the products or services produced by the process).
Typically the focus of decisions is common cause problems and special cause problems.
The management by fact process contains two components:
i.
Meeting desired results
ii.
Managing the processes to drive the results
5.14 RISK MANAGEMENT

Risk management is the identification, assessment, and prioritization of risks (defined in ISO
31000 as the effect of uncertainty on objectives, whether positive or negative) followed by
coordinated and economical application of resources to minimize, monitor, and control the
probability and/or impact of unfortunate events or to maximize the realization of opportunities.
Risks can come from uncertainty in financial markets, project failures (at any phase in design,
development, production, or sustainment life-cycles), legal liabilities, credit risk, accidents,
natural causes and disasters as well as deliberate attack from an adversary, or events of uncertain
or unpredictable root-cause. Several risk management standards have been developed including
the Project Management Institute, the National Institute of Standards and Technology, actuarial
societies, and ISO standards. Methods, definitions and goals vary widely according to whether
the risk management method is in the context of project management, security, engineering,
industrial processes, financial portfolios, actuarial assessments, or public health and safety.
The strategies to manage risk typically include transferring the risk to another party, avoiding the
risk, reducing the negative effect or probability of the risk, or even accepting some or all of the
potential or actual consequences of a particular risk.
Certain aspects of many of the risk management standards have come under criticism for having
no measurable improvement on risk, whether the confidence in estimates and decisions seem to
increase.
Risk management is a process for identifying, assessing, and prioritizing risks of different kinds.
Once the risks are identified, the risk manager will create a plan to minimize or eliminate the
impact of negative events. A variety of strategies is available, depending on the type of risk and
the type of business. There are a number of risk management standards, including those
developed by the Project Management Institute, the International Organization for
Standardization (ISO), the National Institute of Science and Technology
5.14.1 Types of Risk

There are many different types of risk that risk management plans can mitigate. Common risks
include things like accidents in the workplace or fires, tornadoes, earthquakes, and other natural
disasters. It can also include legal risks like fraud, theft, and sexual harassment lawsuits. Risks
can also relate to business practices, uncertainty in financial markets, failures in projects, credit
risks, or the security and storage of data and records.
5.14.2 Categories of risks:

Schedule Risk
Project schedule get slip when project tasks and schedule release risks are not addressed
properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project
failure.
Schedules often slip due to following reasons:

Wrong time estimation
Resources are not tracked properly. All resources like staff, systems, skills of individuals
etc.
Failure to identify complex functionalities and time required to develop those
functionalities.
Unexpected project scope expansions.
Budget Risk
Wrong budget estimation.
Cost overruns
Project scope expansion
Operational Risks
Risks of loss due to improper process implementation, failed system or some external events
risks.
Causes of Operational risks:
Failure to address priority conflicts
Failure to resolve the responsibilities
Insufficient resources
No proper subject training
No resource planning
No communication in team.
Technical risks
Technical
risks
generally
lead
to
failure
of
functionality
and
performance.
Causes of technical risks are:

Continuous changing requirements
No advanced technology available or the existing technology is in initial stages.
Product is complex to implement.
Difficult project modules integration.
Programmatic Risks
These are the external risks beyond the operational limits. These are all uncertain risks
are outside the control of the program.
These external events can be:
Running out of fund.
Market development
Changing customer product strategy and priority
Government rule changes.
5.14.3 Goals of Risk Management

The idea behind using risk management practices is to protect businesses from being vulnerable.
Many business risk management plans may focus on keeping the company viable and reducing
financial risks. However, risk management is also designed to protect the employees, customers,
and general public from negative events like fires or acts of terrorism that may affect them. Risk
management practices are also about preserving the physical facilities, data, records, and
physical assets a company owns or uses.
5.14.4 Process for Identifying and Managing Risk

While a variety of different strategies can mitigate or eliminate risk, the process for identifying
and managing the risk is fairly standard and consists of five basic steps. First, threats or risks are
identified. Second, the vulnerability of key assets like information to the identified threats is
assessed. Next, the risk manager must determine the expected consequences of specific threats to
assets. The last two steps in the process are to figure out ways to reduce risks and then prioritize
the risk management procedures based on their importance.
5.14.5 Strategies for Managing Risk

There are as many different types of strategies for managing risk as there are types of risks.
These break down into four main categories. Risk can be managed by accepting the
consequences of a risk and budgeting for it. Another strategy is to transfer the risk to another
party by insuring against a particular, like fire or a slip-and-fall accident. Closing down a
particular high-risk area of a business can avoid risk. Finally, the manager can reduce the risks
negative effects, for instance, by installing sprinklers for fires or instituting a back-up plan for
data. Having a risk management plan is an important part of maintaining a successful and
responsible company. Every company should have one. It will help to protect people as well as
physical and financial assets.
Within risk management the emphasis is shifted from crisis management to anticipatory
management.
Boehm defines four major reasons for implementing software risk management:
i.
Avoiding software project disasters, including run away budgets and schedules, defectridden software products, and operational failures.
ii.
Avoiding rework caused by erroneous, missing, or ambiguous requirements, design or

code, which typically consumes 40-50% of the total cost of software development.
iii.
Avoiding overkill with detection and prevention techniques in areas of minimal or no

risk.
iv.
Stimulating a win-win software solution where the customer receives the product they
need and the vendor makes the profits they expect.
5.15 RISK MANAGEMENT PROCESS

The risk management process starts with the identification of a list of potential risks. Each of
these risks is then analyzed and prioritized. A risk management plan is created that identifies
containment actions that will reduce the probability of the risk occurring and/or reduce the
impact if the risk turns into a problem. The plan also includes contingency actions that will be
taken if the risk turns into a problem and the associated triggers (indicators that the risk is turning
into a problem). The containment part of the plan is then implemented and actions are taken. The
tracking step involves monitoring the status of known risks as well as the results of risk reduction
actions. If a trigger indicates the onset of a problem, the corresponding contingency plans are
implemented. As new status and information are obtained, the risk management plans are
updated accordingly. Tracking may also result in the addition of newly identified risks or in the
closure of known risks.
The risk management process is an on-going part of managing the software development
process. It is designed to be a continuous feedback loop where additional information and risk
status are utilized to refine the project's risk list and risk management plans. Let's use the
crossing the street analogy to examine the risk management process. First we identify the risk:
we want to cross the street and know there is a possibility of traffic. We analyze the risk. What is
the probability of being hit by the car? How much is it going to hurt if we are hit? How important
is it that we cross this street at this time? We look both ways, we see the on-coming car, and we
judge its rate of speed. We form a plan to reduce the risk and decide to wait until the car has
passed. We implement the plan and wait. We track the situation by watching the car and we see
it pull into a driveway. We change our plan and proceed across the street. We step onto the curb
across the street and stop thinking about crossing the street (i.e., we close the risk).
5.16 RISK IDENTIFICATION

During the first step in the software risk management process, risks are identified and added to
the list of known risks. The output of this step is a list of project-specific risks that have the
potential of compromising the project's success. There are many techniques for identifying risks,
including interviewing, reporting, decomposition, assumption analysis, critical path analysis, and
utilization of risk taxonomies.
Interviewing/Brainstorming: One technique for identifying risks is interviewing or
brainstorming with project personnel, customers, and vendors. Open-ended questions such as the
following can help identify potential areas of risk.
What new or improved technologies does this project implement?
What interfaces issues still need to be defined?
What requirements exist that we arent sure how to implement?
What concerns do we have about our ability to meet the required quality and performance
levels?
Voluntary Reporting: Another risk identification technique is voluntary reporting, where any
individual who identifies a risk is encouraged and rewarded for bringing that risk to
managements attention. This requires the complete elimination of the shoot the messenger
syndrome. It avoids the temptation to assign risk reduction actions to the person who identified
the risk. Risks can also be identified through required reporting mechanisms such as status
reports or project reviews.
Decomposition: As the product is being decomposed during the requirements and design phases,
another opportunity exists for risk identifications. Every TBD ("To Be Done/Determined") is a
potential risk. As Ould states, The most important thing about planning is writing down what
you dont know, because what you dont know is what you must find out. Decomposition in the
form of work breakdown structures during project planning can also help identify areas of
uncertainty that may need to be recorded as risks.
Assumption Analysis: Process and product assumptions must be analyzed. For example, we
might assume the hardware would be available by the system test date or three additional
experienced C++ programmers will be hired by the time coding starts. If these assumptions
prove to be false, we could have major problems.
Critical Path Analysis: As we perform critical path analysis for our project plan, we must
remain on the alert to identify risks. Any possibility of schedule slippage on the critical path
must be considered a risk because it directly impacts our ability to meet schedule.
Risk Taxonomies: Risk taxonomies are lists of problems that have occurred on other projects
and can be used as checklists to help ensure all potential risks have been considered. An example
of a risk taxonomy can be found in the Software Engineering Institutes Taxonomy -Based Risk
Identification report that covers 13 major risk areas with about 200 questions.
5.17 RISK ANALYSIS

During the risk analysis step, each risk is assessed to determine:
Likelihood: the probability that the risk will result in a loss
Impact: the size or cost of that loss if the risk turns into a problem
Timeframe: when the risk needs to be addressed (i.e., risk associated with activities in the
near future would have a higher priority then similar risks in later activities)
Additionally, the interrelationships between risks are assessed to determine if compounding risk
conditions magnify losses.
The following is an example of risk analysis. During our analysis, we determine that there is a
30% probability the Test Bed will be available one week later than scheduled and a 10%
probability it will be a month late. If the Test Bed is one week late, the testers can use their time
productively by using the simulators to test other aspects of the software (loss = $0). The
simulator can be utilized for up to two weeks. However, if the Test Bed delivery is one month
late, there are not enough productive activities to balance the loss. Losses include unproductive
testers for two weeks, overtime later, morale problems, and delays in finding defects for a total
estimated loss of $100,000. In addition to the dollar loss, the testing is on the critical path and not
all of the lost testing time can be made up in overtime (loss estimated at two week schedule
slippage).
Boehm defines the Risk Exposure equation to help quantitatively establish risk priorities. Risk
Exposure measures the impact of a ris k in terms of the expected value of the loss. Risk Exposure
(RE) is defined as the probability of an undesired outcome times the expected loss if that
outcome occurs.
RE = Probability(UO) * Loss (UO), where UO = Unexpected outcome
Given the example above, the Risk Exposure is 10% x $100,000 = $10,000 and 10% x 2 calendar
week = 0.2 calendar week. Comparing the Risk Exposure measurement for various risks can help
identify those risks with the greatest probable negative impact to the project or product and thus
help establish which risks are candidates for further action. The list of risks is then prioritized
based on the results of our risk analysis. Since resource limitations rarely allow the consideration
of all risks, the prioritized list of risks is used to identify risks requiring additional planning and
action. Other risks are documented and tracked for possible future consideration. Based on
changing conditions, additional information, the identification of new risks, or the closure of
existing risks, the list of risks requiring additional planning and action may require periodic
updates.
5.18 RISK MANAGEMENT PLANNING

Taking the prioritized risk list as input, plans are developed for the risks chosen for action. The
specific questions that can be asked to help focus on the type of planning required. We will use
the following two risks to illustrate the types of actions that might be taken using each risk
handling technique:
- The subcontractor may not deliver the software at the required reliability level and as a result
the reliability of the total system may not meet performance specifications.
The interface with the new control device is not defined and as a result its driver may take more
time to implement then scheduled.
Is it too big a risk? If the risk is too big for us to be willing to accept, we can avoid the risk by
changing our project strategies and tactics to choose a less risky alternate or we may decide not
to do the project at all. For example, if our project has tight schedule constraints and includes
state of the art technology, we may decide to wait until a future project to implement our newly
purchased CASE tools.
Things to remember about avoiding risks include:
Avoiding risks may also mean avoiding opportunities
Not all risks can be avoided
Avoiding a risk in one part of the project may create risks in other parts of the project.
5.19 SOFTWARE RISK MANAGEMENT PROCESS

There are several models available for risk management. The model recommended in this section
was developed by the Software Engineering Institute (SEI).
Figure 5.1: Software Risk Management Paradigm
Identify: Before risks can be managed its must be identified before adversely affecting the
project. Establishing an environment that encourages people to raise concerns and issues and
conducting quality reviews throughout all phases of a project are common techniques for
identifying risks.
Analyze: Analysis is the conversion of risk data into risk decision-making information. It
includes reviewing, prioritizing, and selecting the most critical risks to address. The Software
Risk Evaluation (SRE) Team analyzes each identified risk in terms of its consequence on cost,
schedule, performance, and product quality.
Plan: Planning turns risk information into decisions and actions for both the present and future.
Planning involves developing actions to address individual risks, prioritizing risk actions and
creating a Risk Management Plan. The key to risk action planning is to consider the future
consequences of a decision made today.
Track: Tracking consists of monitoring the status of risks and the actions taken against risks to
mitigate them.
Control: Risk control relies on project management processes to control risk action plans,
correct for variations from plans, respond to triggering events, and improve risk management
processes. Risk control activities are documented in the Risk Management Plan.
Communicate: Communication happens throughout all the functions of risk management.
Without effective communication, no risk management approach can be viable. It is an integral
part of all the other risk management activities.
5.19.1 Risk Assessment

Risk assessment is the first process in the risk management methodology. It is based on three
concepts: reviews, snapshots and reports that underpin the three layers of processing the riskrelated information: identification, analysis and reporting. Reviews establish the framework for
risk identification, snapshots pass the identified risks for further analysis and reports
communicate the results of risk assessment. The risk identification layer uses reviews to gather
risk related information from a project. Reviews differ in terms of their scope, duration,
participants and identification techniques. It is possible that two reviews overlap in time,
however differing in their scope and/or participants. Risk related information collected during a
review is represented as risk indication and identifies a particular risk, the involved project
stakeholder, timestamp, the identification technique and possible comments. After the
identification and analysis, the risk assessment report is generated. It can then be used as input
for risk mitigation related activities. It may also be taken as an input to the next risk review
action. The output of the risk assessment process helps to identify appropriate controls for
reducing or eliminating risk during the risk mitigation process. The risk assessment methodology
encompasses nine primary steps such as System Characterization, Threat Identification,
Vulnerability Identification, Control Analysis, Likelihood Determination, Impact Analysis, Risk
Determination, Control Recommendations, and Results Documentation.
5.19.2 Review based Risk Assessment Process

We assume that there is a risk identification and analysis process performed by the project
stakeholders and controlled by the risk manager (the role usually played by the project manager
except large projects where it could be assigned separately). The process is structured as a
sequence of reviews. It is assumed that at any time some review is open. The review remains
open over its time window. Time windows of subsequent reviews are adjacent. We distinguish
between two types of reviews:
Active review: Its starting and ending times are set by the risk manager as well as its scope and
participants (the stakeholders involved in the review). The review has a defined set of inputs
(reports, checklists, questionnaires, etc.) and associated risk identification techniques. As a rule,
the snapshot from the last continuous review is included as an input of the active review. The
active review ends with the risk analysis session that aims at assessing and prioritizing the
identified risks and produces a relevant report.
Continuous review: It starts with the end of the previous review and ends with the start of the
next review (being it active or continuous). It just keeps the communication channel open
enabling the communicated risk information being memorized. The set of its input documents is
not controlled by the risk manager. Any project stakeholder can pass risk-related information
disregarding the way of its generation. Typically, a snapshot is taken at the end of the continuous
review to provide an input to the subsequent active review. A snapshot is also taken at the end of
an active review to summarize the effects of risk identification activities. The risk assessment
report is generated at the end of an active review. We assume that the process has the active and
continuous reviews interleaved, their extent (in time) and scope (in terms of inputs and
participants) being controlled by the risk manager. This way we achieve the following benefits:
The communication channel is constantly open.
The identification actions are being planned (active and continuous reviews).
All communicated risk-related information is being memorized.
The identified risks are periodically reviewed and assessed and the frequency and scope
of those assessments is under control of the risk manager.
The results of the analyses are kept in the form of reports and are available downstream
of the process (can support further identification and analysis).
5.19.3 Data Model of Risk Management

The model comprises the following elements:
Project: General project description (process, methodology, organization, size, initiation date).
Mitigation area: Area of a project that is exposed to a common type of risks (e.g. requirement
specification, personnel management etc.)
Review: This is the root object of the identification phase Opening a new review starts risk
identification activities whereas closing the review ends the risk information acquisition.
Checklist: Checklists are used to collect information that helps to identify risks. A checklist
includes its name, description, authors identification and its
Predefined risk: Risk that is stored in the risk knowledge base. It may be selected by one or
more answers to the questions.
Predefined risk factor: Risk factor providing the context for a risk stored in the risk knowledge
base.
Identified risk: Detailed risk description (from the risk knowledge base) in the context of a
particular project.
Identified factor: Context of the identified risk extracted from the risk knowledge base.
5.19.4 Risk Mitigation

Risk mitigation, the second process of risk management, involves prioritizing, evaluating, and
implementing the appropriate risk-reducing controls recommended from the risk assessment
process. Because the elimination of all risk is usually impractical or close to impossible, it is the
responsibility of senior management and functional and business managers to use the least-cost
approach and implement the most appropriate controls to decrease mission risk to an acceptable
level, with minimal adverse impact on the organizations resources and mission.
5.20 SUMMARY
Metrics should always be seen as indicators, not as absolute truth. It is possible to score well on
all metrics, but still have an unsatisfactory design. The application of simple product metrics to
entire programs can only indicate certain problems but does not relate measurement results back
to design principles. It can be very difficult for developer to decide on the right action to take
upon receipt of a particular metrics value. Design metrics may be used to relate knowledge about
good design to characteristic structural system properties. Software developers should be able to
infer more about the software they are developing during the design process.
Assignment-Module 5
1.
Which one is not a software metrics
a.
Process metric
b.
Product metric
c.
Project metric
d.
People metric
2.
Software science measures developed by
a.
M. Halstead
b.
B. Littlewood
c.
T. J. Mc Cabe
d.
G. Rothermal
3.
Vocabulary of a program defined as
a.
= 1 + 2
b.
= 1 - 2
c.
= 1 * 2
d.
= 1 / 2
4.
In Halstead theory, effort measured in
a.
Person-months
b.
Hours
c.
Elementary mental discriminations
d.
None of them
5.
Types of risk
a.
Technical risk
b.
Operational risk
c.
None of them
d.
Both of them
6.
Fan-In of a procedure is
a.
Number of local flows into that procedure plus the number of data structures.
b.
Number of components dependent on it
c.
Number of components related to it
d.
None of them
7.
Fan-Out of a procedure is
a.
Number of local flows from that procedure plus the number of data structures
b.
Number of components dependent on it
c.
Number of components related to it
d.
None of them
8.
Which is not a size metric
a.
LOC
b.
Program length
c.
Function count
d.
Cyclomatic complexity
9.
Which one is not a measure of software science theory
a.
Vocabulary
b.
Level
c.
Volume
d.
Logic
10.
Which one is international standard for size measure
a.
LOC
b.
Program length
c.
Function count
d.
None of them
11.
Technique of identifying risk
a.
Brainstorming
b.
FAST
c.
Use Case
d.
None of them
12.
Steps of software risk management
a.
Identify, analyze, plan, track, control
b.
Analyze, identify, track, plan, control
c.
Plan, control, analyze, identify, track
d.
Identify, track, plan, analyze, control
13.
Program volume of a software product is
a.
V= N log2 n
b.
V = (N/2) log2 n
c.
V = 2N log2 n
d.
V = N log2 n + 1
14.
Jensens Program Length Estimator
a.
N1 = Log2 (N1!) + Log2 (n2!)
b.
N1 = Log2 (N1!) - Log2 (n2!)
c.
N1 = Log2 (N1!) * Log2 (n2!)
d.
N1 = Log2 (N1!) / Log2 (n2!)
15.
Zipfs Program Length Estimator
a.
Nz = n [0.5772 + ln (n) ]
b.
Nz = n [0.5772 - ln (n) ]
c.
Nz = n [0.5772 * ln (n) ]
d.
Nz = n [0.5772 / ln (n) ]
Key - Module 5
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CHAPTER 6 : QUALITY STANDARDS

6.1 ISO 9000 series
ISO 9000 is a series of international standards developed by quality experts from around the
world for use by companies that either want to implement their own in-house quality systems or
to ensure that suppliers have appropriate quality systems in place. The standards were developed
under the auspices of the International Organization for Standardization for both quality
management and quality assurance that has been adopted by over 90 countries in the world. The
ISO 9000 standards are developed and maintained by the International Organization for
Standardization (ISO). International standards promote international trade by providing one
consistent set of requirements recognized around the world".
A quality management system (QMS) defines and establishes an organization's quality policy
and objectives. It also allows an organization to document and implement the procedures needed
to attain these goals. A properly implemented QMS ensures that procedures are carried out
consistently, that problems can be identified and resolved, and that the organization can
continuously review and improve its procedures, products and services. It is a mechanism for
maintaining and improving the quality of products or services so that they consistently meet or
exceed the customer's implied or stated needs and fulfil their quality objectives"
The standards are voluntary and as a result have no legal requirements attached. The best known
quality standards are known as the 9000 Series or ISO 9000.
6.1.1 Benefits of ISO 9000

The primary value of ISO 9000 registration is consistent delivery of a product or service to a
defined standard and improved bottom line performance. ISO registration also has a significant
bearing on market credibility as well.
The ISO 9000 quality management system can enable your company to increase profitability and
customer satisfaction through reduced waste and rework, shortened cycle times, improved
problem tracking and resolution and better supplier relations.
Other benefits of ISO certification:

Some prospective buyers may require their suppliers to be ISO registered,
90 countries around the world have adopted ISO standards,
Companies wishing to do business in Europe may have no choice but to adopt it as it is
an accepted part of doing business,
perceived higher quality product/service,
objective third party verification of quality assurance.
6.1.2 Advantages And Disadvantages Of ISO?

6.1.2.1 Advantages
see "Benefits" above,
quality is maintained,
opportunity to compete with larger companies,
more time spent on customer focus,
confirmation that your company is committed to quality,
may facilitate trade and increased market opportunities,
improvements in facility performance and quality as a result of implementing and
maintaining the process,
can increase customer confidence and satisfaction.
6.1.2.2 Disadvantages
costly,
time consuming to document and maintain,
requires employee buy-in
To achieve maximum benefit from ISO 9000 the focus must be on documenting, understanding
and improving your systems and processes.
The ISO 9000 standards require:
A standard language for documenting quality procedures;

documented procedures, covering all parts of the organization within the scope of
registration, for ensuring that quality objectives are met;
A system to track and manage evidence that these practices are instituted throughout the
organization; and
A third party auditing model to assess, certify and maintain certification of organizations
6.1.3 ISO 9000 Series

The ISO 9000 series classifies products into generic product categories: hardware, software,
processed materials and services. The standards are applicable to all industry sectors. The
standards are published in a series of five booklets, each covering a specific area:
ISO 9000 - Explains fundamental quality concepts and provides guidelines for the
selection and application of each standard.
ISO 9001 - Model for quality assurance in design, development, production, installation
and servicing.
ISO 9002 - Model for quality assurance in the production and installation of
manufacturing systems.
ISO 9003 - Quality assurance in final inspection and testing.
ISO 9004 - Guidelines for the applications of standards in quality management and
quality systems.
ISO 9000 and ISO 9004 are guidance standards. They describe what is necessary to
accomplish the requirements outlined in standards 9001, 9002 or 9003.
Organizations choose the standards to which they want to become registered, based on their
structure, their products, services and their specific function. Selecting the appropriate standards
is an important decision.
6.2 SIX SIGMA

Six Sigma is a business management strategy, originally developed by Motorola in 1986. Six
Sigma became well known after Jack Welch made it a central focus of his business strategy at
General Electric in 1995, and today it is widely used in many sectors of industry.
Six Sigma seeks to improve the quality of process outputs by identifying and removing the
causes of defects (errors) and minimizing variability in manufacturing and business processes. It
uses a set of quality management methods, including statistical methods, and creates a special
infrastructure of people within the organization ("Black Belts", "Green Belts", etc.) who are
experts in these methods. Each Six Sigma project carried out within an organization follows a
defined sequence of steps and has quantified financial targets (cost reduction and/or profit
increase).
The term Six Sigma originated from terminology associated with manufacturing, specifically
terms associated with statistical modelling of manufacturing processes. The maturity of a
manufacturing process can be described by a sigma rating indicating its yield or the percentage
of defect-free products it creates. A six sigma process is one in which 99.99966% of the products
manufactured are statistically expected to be free of defects (3.4 defects per million).
Six Sigma originated as a set of practices designed to improve manufacturing processes and
eliminate defects, but its application was subsequently extended to other types of business
processes as well. In Six Sigma, a defect is defined as any process output that does not meet
customer specifications, or that could lead to creating an output that does not meet customer
specifications.
The core of Six Sigma was born at Motorola in the 1970s out of senior executive Art Sundry's
criticism of Motorolas bad quality. As a result of this criticism, the company discovered a
connection between increases in quality and decreases in costs of production. At that time, the
prevailing view was that quality costs extra money. In fact, it reduced total costs by driving down
the costs for repair or control. Bill Smith subsequently formulated the particulars of the
methodology at Motorola in 1986. Six Sigma was heavily inspired by the quality improvement
methodologies of the six preceding decades, such as quality control, Total Quality Management
(TQM), and Zero Defects, based on the work of pioneers such as Shewhart, Deming, Juran,
Crosby, Ishikawa, Taguchi, and others.
Like its predecessors, Six Sigma doctrine asserts that:
Continuous efforts to achieve stable and predictable process results (i.e., reduce process
variation) are of vital importance to business success.
Manufacturing and business processes have characteristics that can be measured,
analyzed, improved and controlled.
Achieving sustained quality improvement requires commitment from the entire
organization, particularly from top-level management.
Features that set Six Sigma apart from previous quality improvement initiatives include:
A clear focus on achieving measurable and quantifiable financial returns from any Six
Sigma project.
An increased emphasis on strong and passionate management leadership and support.
A special infrastructure of "Champions", "Master Black Belts", "Black Belts", "Green
Belts", "Red Belts" etc. to lead and implement the Six Sigma approach.
A clear commitment to making decisions on the basis of verifiable data, rather than
assumptions and guesswork.
The term "Six Sigma" comes from a field of statistics known as process capability studies.
Originally, it referred to the ability of manufacturing processes to produce a very high proportion
of output within specification. Processes that operate with "six sigma quality" over the short term
are assumed to produce long-term defect levels below 3.4 defects per million opportunities
(DPMO). Six Sigma's implicit goal is to improve all processes to that level of quality or better.
Six Sigma is a registered service mark and trademark of Motorola Inc. As of 2006 Motorola
reported over US$17 billion in savings from Six Sigma. Other early adopters of Six Sigma who
achieved well-publicized success include Honeywell (previously known as AlliedSignal) and
General Electric, where Jack Welch introduced the method. By the late 1990s, about two-thirds
of the Fortune 500 organizations had begun Six Sigma initiatives with the aim of reducing costs
and improving quality.
In recent years, some practitioners have combined Six Sigma ideas with lean manufacturing to
create a methodology named Lean Six Sigma. The Lean Six Sigma methodology views lean
manufacturing, which addresses process flow and waste issues, and Six Sigma, with its focus on
variation and design, as complementary disciplines aimed at promoting "business and
operational excellence". Companies such as IBM use Lean Six Sigma to focus transformation
efforts not just on efficiency but also on growth. It serves as a foundation for innovation
throughout the organization, from manufacturing and software development to sales and service
delivery functions.
6.2.1 Methods
Six Sigma projects follow two project methodologies inspired by Deming's Plan-Do-Check-Act
Cycle. These methodologies, composed of five phases each, bear the acronyms DMAIC and
DMADV.
DMAIC is used for projects aimed at improving an existing business process. DMAIC is
pronounced as "duh-may-ick".
DMADV is used for projects aimed at creating new product or process designs. DMADV
is pronounced as "duh-mad-vee".
6.2.1.1 DMAIC Method

The DMAIC project methodology has five phases:
Define the problem, the voice of the customer, and the project goals, specifically.
Measure key aspects of the current process and collect relevant data.
Analyze the data to investigate and verify cause-and-effect relationships. Determine what
the relationships are, and attempt to ensure that all factors have been considered. Seek out
root cause of the defect under investigation.
Improve or optimize the current process based upon data analysis using techniques such
as design of experiments, poka yoke or mistake proofing, and standard work to create a
new, future state process. Set up pilot runs to establish process capability.
Control the future state process to ensure that any deviations from target are corrected
before they result in defects. Implement control systems such as statistical process
control, production boards, visual workplaces, and continuously monitor the process.
Some organizations add a Recognize step at the beginning, which is to recognize the right
problem to work on, thus yielding an RDMAIC methodology.
6.2.1.2 DMADV or DFSS Method

The DMADV project methodology, also known as DFSS ("Design For Six Sigma"), features
five phases:
Define design goals that are consistent with customer demands and the enterprise
strategy.
Measure and identify CTQs (characteristics that are Critical To Quality), product
capabilities, production process capability, and risks.
Analyze to develop and design alternatives, create a high-level design and evaluate
design capability to select the best design.
Design details, optimize the design, and plan for design verification. This phase may
require simulations.
Verify the design, set up pilot runs, implement the production process and hand it over to
the process owner(s).
6.2.2 Quality management tools and methods used in Six Sigma

Within the individual phases of a DMAIC or DMADV project, Six Sigma utilizes many
established quality-management tools that are also used outside Six Sigma. The following table
shows an overview of the main methods used.
Analysis of variance
Pareto analysis
ANOVA Gauge R&R
Pareto chart
Axiomatic design
Pick chart
Business Process Mapping
Process capability
Cause & effects diagram
Quality Function Deployment
(also known as fishbone or Ishikawa diagram)
Quantitative marketing research through

use of Enterprise Feedback Management (EFM)
Check sheet
Chi-squared test of independence and
systems
Regression analysis
fits
Rolled throughput yield
Control chart
Root cause analysis
Correlation
Run charts
Cost-benefit analysis
Scatter diagram
CTQ tree
SIPOC
Design of experiments
Failure
mode
and
effects
analysis
analysis
(Suppliers,
Inputs,
Process, Outputs, Customers)
(FMEA)
General linear model
Histograms
Stratification
Taguchi methods
Taguchi Loss Function
6.2.3 Implementation roles

One key innovation of Six Sigma involves the "professionalizing" of quality management
functions. Prior to Six Sigma, quality management in practice was largely relegated to the
production floor and to statisticians in a separate quality department. Formal Six Sigma programs
adopt a ranking terminology (similar to some martial arts systems) to define a hierarchy (and
career path) that cuts across all business functions.
Six Sigma identifies several key roles for its successful implementation.
Executive Leadership includes the CEO and other members of top management. They are
responsible for setting up a vision for Six Sigma implementation. They also empower the
other role holders with the freedom and resources to explore new ideas for breakthrough
improvements.
Champions take responsibility for Six Sigma implementation across the organization in
an integrated manner. The Executive Leadership draws them from upper management.
Champions also act as mentors to Black Belts.
Master Black Belts, identified by champions, act as in-house coaches on Six Sigma. They
devote 100% of their time to Six Sigma. They assist champions and guide Black Belts
and Green Belts. Apart from statistical tasks, they spend their time on ensuring consistent
application of Six Sigma across various functions and departments.
Black Belts operate under Master Black Belts to apply Six Sigma methodology to
specific projects. They devote 100% of their time to Six Sigma. They primarily focus on
Six Sigma project execution, whereas Champions and Master Black Belts focus on
identifying projects/functions for Six Sigma.
Green Belts are the employees who take up Six Sigma implementation along with their
other job responsibilities, operating under the guidance of Black Belts.
Some organizations use additional belt colours, such as Yellow Belts, for employees that
have basic training in Six Sigma tools and generally participate in projects and 'white
belts' for those locally trained in the concepts but do not participate in the project team.
6.2.4 Certification
Corporations such as early Six Sigma pioneers General Electric and Motorola developed
certification programs as part of their Six Sigma implementation, verifying individuals'
command of the Six Sigma methods at the relevant skill level (Green Belt, Black Belt etc.).
Following this approach, many organizations in the 1990s started offering Six Sigma
certifications to their employees. Criteria for Green Belt and Black Belt certification vary; some
companies simply require participation in a course and a Six Sigma project. There is no standard
certification body, and different certification services are offered by various quality associations
and other providers against a fee. The American Society for Quality for example requires Black
Belt applicants to pass a written exam and to provide a signed affidavit stating that they have
completed two projects, or one project combined with three years' practical experience in the
body of knowledge. The International Quality Federation offers an online certification exam that
organizations can use for their internal certification programs; it is statistically more demanding
than the ASQ certification. Other providers offering certification services include the the Juran
Institute, Six Sigma Qualtec, Air Academy Associates and many others.
6.2.5 Origin and meaning of the term "six sigma process"

The term "six sigma process" comes from the notion that if one has six standard deviations
between the process mean and the nearest specification limit, as shown in the graph, practically
no items will fail to meet specifications. This is based on the calculation method employed in
process capability studies.
Figure 6.1 Graph of six sigma process
Capability studies measure the number of standard deviations between the process mean and the
nearest specification limit in sigma units. As process standard deviation goes up, or the mean of
the process moves away from the center of the tolerance, fewer standard deviations will fit
between the mean and the nearest specification limit, decreasing the sigma number and
increasing the likelihood of items outside specification.
Graph of the normal distribution, which underlies the statistical assumptions of the Six Sigma
model. The Greek letter (sigma) marks the distance on the horizontal axis between the mean,
, and the curve's inflection point. The greater this distance, the greater is the spread of values
encountered. For the green curve shown above, = 0 and = 1. The upper and lower
specification limits (USL and LSL, respectively) are at a distance of 6 from the mean. Because
of the properties of the normal distribution, values lying that far away from the mean are
extremely unlikely. Even if the mean were to move right or left by 1.5 at some point in the
future (1.5 sigma shift, coloured red and blue), there is still a good safety cushion. This is why
Six Sigma aims to have processes where the mean is at least 6 away from the nearest
specification limit.
6.2.6 Role of the 1.5 sigma shift

Experience has shown that processes usually do not perform as well in the long term as they do
in the short term. As a result, the number of sigma that will fit between the process mean and the
nearest specification limit may well drop over time, compared to an initial short-term study. To
account for this real-life increase in process variation over time, an empirically-based 1.5 sigma
shift is introduced into the calculation. According to this idea, a process that fits 6 sigma between
the process mean and the nearest specification limit in a short-term study will in the long term fit
only 4.5 sigma either because the process mean will move over time, or because the long-term
standard deviation of the process will be greater than that observed in the short term, or both.
Hence the widely accepted definition of a six sigma process is a process that produces 3.4
defective parts per million opportunities (DPMO). This is based on the fact that a process that is
normally distributed will have 3.4 parts per million beyond a point that is 4.5 standard deviations
above or below the mean (one-sided capability study). So the 3.4 DPMO of a six sigma process
in fact corresponds to 4.5 sigma, namely 6 sigma minus the 1.5-sigma shift introduced to account
for long-term variation. This allows for the fact that special causes may result in a deterioration
in process performance over time, and is designed to prevent underestimation of the defect levels
likely to be encountered in real-life operation.
6.2.7 Sigma levels

A control chart depicting a process that experienced a 1.5 sigma drift in the process mean toward
the upper specification limit starting at midnight. Control charts are used to maintain 6 sigma
quality by signaling when quality professionals should investigate a process to find and eliminate
special-cause variation.
Figure 6.2 Control chart for six sigma level
The table below gives long-term DPMO values corresponding to various short-term sigma levels.
It must be understood that these figures assume that the process mean will shift by 1.5 sigma
toward the side with the critical specification limit. In other words, they assume that after the
initial study determining the short-term sigma level, the long-term Cpk value will turn out to be
0.5 less than the short-term Cpk value. So, for example, the DPMO figure given for 1 sigma
assumes that the long-term process mean will be 0.5 sigma beyond the specification limit (Cpk =
0.17), rather than 1 sigma within it, as it was in the short-term study (Cpk = 0.33). Note that the
defect percentages indicate only defects exceeding the specification limit to which the process
mean is nearest. Defects beyond the far specification limit are not included in the percentages.
Sigma level DPMO Percent defective Percentage yield Short-term Cpk Long-term Cpk
1
691,462 69%
31%
0.33
0.17
308,538 31%
69%
0.67
0.17
66,807 6.7%
93.3%
1.00
0.5
6,210
0.62%
99.38%
1.33
0.83
233
0.023%
99.977%
1.67
1.17
3.4
0.00034%
99.99966%
2.00
1.5
0.019
0.0000019%
99.9999981%
2.33
1.83
6.2.8 Software used for Six Sigma

There are generally four classes of software used to support Six Sigma:
Analysis tools, which are used to perform statistical or process analysis
Program management tools, used to manage and track a corporation's entire Six Sigma
program
DMAIC and Lean online project collaboration tools for local and global teams
Data Collection tools that feed information directly into the analysis tools and
significantly reduce the time spent gathering data
Analysis tools
Arena
ARIS Six Sigma
Bonita Open Solution BPMN2 standard and KPIs for statistic monitoring
JMP
Microsoft Visio
Minitab
R language (The R Project for Statistical Computing). Open source software: statistical and
graphic functions from the base installation can be used for Six Sigma projects. Furthermore,
some contributed packages at CRAN contain specific tools for Six Sigma: SixSigma,
qualityTools, qcc and IQCC.
SDI Tools
Sigma XL
Software AG web Methods BPM Suite
SPC XL
Stat graphics
STATISTICA
6.2.9 Application
Six Sigma mostly finds application in large organizations. An important factor in the spread of
Six Sigma was GE's 1998 announcement of $350 million in savings thanks to Six Sigma, a
figure that later grew to more than $1 billion. According to industry consultants, companies with
fewer than 500 employees are less suited to Six Sigma implementation, or need to adapt the
standard approach to make it work for them. This is due both to the infrastructure of Black Belts
that Six Sigma requires, and to the fact that large organizations present more opportunities for
the kinds of improvements Six Sigma is suited to bringing about.
In healthcare
Six Sigma strategies were initially applied to the healthcare industry in March 1998. The
Commonwealth Health Corporation (CHC) was the first health care organization to successfully
implement the efficient strategies of Six Sigma. Substantial financial benefits were claimed, for
example in their radiology department throughput improved by 33% and costs per radiology
procedure decreased by 21.5%; Six Sigma has subsequently been adopted in other hospitals
around the world.
Critics of Six Sigma believe that while Six Sigma methods may have translated fluidly in a
manufacturing setting, they would not have the same result in service-oriented businesses, such
as the health industry.
6.2.10 Criticism
6.2.10.1 Lack of originality
Noted quality expert Joseph M. Juran has described Six Sigma as "a basic version of quality
improvement", stating that "there is nothing new there. It includes what we used to call
facilitators. They've adopted more flamboyant terms, like belts with different colors. I think that
concept has merit to set apart, to create specialists who can be very helpful. Again, that's not a
new idea. The American Society for Quality long ago established certificates, such as for
reliability engineers."
6.2.10.2 Role of consultants

The use of "Black Belts" as itinerant change agents has (controversially) fostered an industry of
training and certification. Critics argue there is overselling of Six Sigma by too great a number of
consulting firms, many of which claim expertise in Six Sigma when they have only a
rudimentary understanding of the tools and techniques involved.
6.2.10.3 Potential negative effects

A Fortune article stated that "of 58 large companies that have announced Six Sigma programs,
91 percent have trailed the S&P 500 since". The statement was attributed to "an analysis by
Charles Holland of consulting firm Qualpro (which espouses a competing quality-improvement
process)." The summary of the article is that Six Sigma is effective at what it is intended to do,
but that it is "narrowly designed to fix an existing process" and does not help in "coming up with
new products or disruptive technologies." Advocates of Six Sigma have argued that many of
these claims are in error or ill-informed.
A more direct criticism is the "rigid" nature of Six Sigma with its over-reliance on methods and
tools. In most cases, more attention is paid to reducing variation and less attention is paid to
developing robustness (which can altogether eliminate the need for reducing variation).
Articles featuring critics have appeared in the November-December 2006 issue of USA Army
Logistician regarding Six-Sigma: "The dangers of a single paradigmatic orientation (in this case,
that of technical rationality) can blind us to values associated with double-loop learning and the
learning organization, organization adaptability, workforce creativity and development,
humanizing the workplace, cultural awareness, and strategy making."
A Business Week article says that James McNerney's introduction of Six Sigma at 3M had the
effect of stifling creativity and reports its removal from the research function. It cites two
Wharton School professors who say that Six Sigma leads to incremental innovation at the
expense of blue skies research. This phenomenon is further explored in the book Going Lean,
which describes a related approach known as lean dynamics and provides data to show that
Ford's "6 Sigma" program did little to change its fortunes.
6.2.10.4 Lack of evidence of its success

In articles and especially on Internet sites and in text books, claims are made about the huge
successes and millions of dollars that Six Sigma has saved. Six Sigma seems to be a "silver
bullet" method. However, there does not seem to be trustworthy evidence for this:
Probably more to the Six Sigma literature than concepts, relates to the evidence for Six Sigmas
success. So far, documented case studies using the Six Sigma methods are presented as the
strongest evidence for its success. However, looking at these documented cases, and apart from a
few that are detailed from the experience of leading organizations like GE and Motorola, most
cases are not documented in a systemic or academic manner. In fact, the majority are case studies
illustrated on websites, and are, at best, sketchy. They provide no mention of any specific Six
Sigma methods that were used to resolve the problems. It has been argued that by relying on the
Six Sigma criteria, management is lulled into the idea that something is being done about quality,
whereas any resulting improvement is accidental (Latzko 1995). Thus, when looking at the
evidence put forward for Six Sigma success, mostly by consultants and people with vested
interests, the question that begs to be asked is: are we making a true improvement with Six
Sigma methods or just getting skilled at telling stories? Everyone seems to believe that we are
making true improvements, but there is some way to go to document these empirically and
clarify the causal relations.
6.2.10.5 Based on arbitrary standards

While 3.4 defects per million opportunities might work well for certain products/processes, it
might not operate optimally or cost effectively for others. A pacemaker process might need
higher standards, for example, whereas a direct mail advertising campaign might need lower
standards. The basis and justification for choosing six (as opposed to five or seven, for example)
as the number of standard deviations, together with the 1.5 sigma shift is not clearly explained.
In addition, the Six Sigma model assumes that the process data always conform to the normal
distribution. The calculation of defect rates for situations where the normal distribution model
does not apply is not properly addressed in the current Six Sigma literature. This particularly
counts for reliability-related defects and other problems that are not time invariant. The IEC,
ARP, EN-ISO, DIN and other (inter)national standardization organizations have not created
standards for the Six Sigma process. This might be the reason that it became a dominant domain
of consultants (see critics above).
6.2.10.6 Criticism of the 1.5 sigma shift

The statistician Donald J. Wheeler has dismissed the 1.5 sigma shift as "goofy" because of its
arbitrary nature. Its universal applicability is seen as doubtful.
The 1.5 sigma shift has also become contentious because it results in stated "sigma levels" that
reflect short-term rather than long-term performance: a process that has long-term defect levels
corresponding to 4.5 sigma performance is, by Six Sigma convention, described as a "six sigma
process. The accepted Six Sigma scoring system thus cannot be equated to actual normal
distribution probabilities for the stated number of standard deviations, and this has been a key
bone of contention over how Six Sigma measures are defined. The fact that it is rarely explained
that a "6 sigma" process will have long-term defect rates corresponding to 4.5 sigma
performance rather than actual 6 sigma performance has led several commentators to express the
opinion that Six Sigma is a confidence trick.
6.3 CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

CMMI is a process improvement approach whose goal is to help organizations improve their
performance. CMMI can be used to guide process improvement across a project, a division, or an
entire organization. Currently supported is CMMI Version 1.3. CMMI in software engineering
and organizational development is a process improvement approach that provides organizations
with the essential elements for effective process improvement. CMMI is registered in the U.S.
Patent and Trademark Office by Carnegie Mellon University.
According to the Software Engineering Institute (SEI, 2008), CMMI helps integrate
traditionally separate organizational functions, set process improvement goals and priorities,
provide guidance for quality processes, and provide a point of reference for appraising current
processes.
Figure 6.3: Characteristics of maturity levels
CMMI currently addresses three areas of interest:

1.
Product and service development CMMI for Development (CMMI-DEV),
2.
Service establishment, management, and delivery CMMI for Services (CMMI-SVC),
and
3.
Product and service acquisition CMMI for Acquisition (CMMI-ACQ).
CMMI was developed by a group of experts from industry, government, and the Software
Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for
developing or improving processes that meet the business goals of an organization. A CMMI
model may also be used as a framework for appraising the process maturity of the organization.
CMMI originated in software engineering but has been highly generalized over the years to
embrace other areas of interest, such as the development of hardware products, the delivery of all
kinds of services, and the acquisition of products and services. The word "software" does not
appear in definitions of CMMI. This generalization of improvement concepts makes CMMI
extremely abstract. It is not as specific to software engineering as its predecessor, the Software
CMM.
CMMI was developed by the CMMI project, which aimed to improve the usability of maturity
models by integrating many different models into one framework. The project consisted of
members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI).
The main sponsors included the Office of the Secretary of Defense (OSD) and the National
Defense Industrial Association.
CMMI is the successor of the capability maturity model (CMM) or Software CMM. The CMM
was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released, Version 1.2
followed in August 2006, and CMMI Version 1.3 in November 2010. Some of the major changes
in CMMI V1.3 are the support of Agile Software Development, improvements to high maturity
practices and alignment of the representation (staged and continuous).
6.3.1 CMMI representation

CMMI exists in two representations:- continuous and staged. The continuous representation is
designed to allow the user to focus on the specific processes that are considered important for the
organization's immediate business objectives, or those to which the organization assigns a high
degree of risks. The staged representation is designed to provide a standard sequence of
improvements, and can serve as a basis for comparing the maturity of different projects and
organizations. The staged representation also provides for an easy migration from the SW-CMM
to CMMI.
The SEI published that 60 organizations measured increases of performance in the categories of
cost, schedule, productivity, quality and customer satisfaction. The median increase in
performance varied between 14% (customer satisfaction) and 62% (productivity). However, the
CMMI model mostly deals with what processes should be implemented, and not so much with
how they can be implemented. These results do not guarantee that applying CMMI will increase
performance in every organization. A small company with few resources may be less likely to
benefit from CMMI; this view is supported by the process maturity profile (page 10). Of the
small organizations (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of
the organizations with 10012000 employees are rated at the highest level (5: Optimizing).
Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences
between CMMI and agile methods, both approaches have much in common. They believe
neither way is the 'right' way to develop software, but that there are phases in a project where one
of the two is better suited. They suggest one should combine the different fragments of the
methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum
and CMMI brings more adaptability and predictability than either one alone. David J. Anderson
(2005) gives hints on how to interpret CMMI in an agile manner. Other viewpoints about using
CMMI and Agile development are available on the SEI website.
CMMI Roadmaps, which are a goal-driven approach to selecting and deploying relevant process
areas from the CMMI-DEV model, can provide guidance and focus for effective CMMI
adoption. There are several CMMI roadmaps for the continuous representation, each with a
specific set of improvement goals. Examples are the CMMI Project Roadmap, CMMI Product
and Product Integration Roadmaps and the CMMI Process and Measurements Roadmaps. These
roadmaps combine the strengths of both the staged and the continuous representations.
The combination of the project management technique earned value management (EVM) with
CMMI has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme
Programming (XP), a software engineering method, has been evaluated with CMM/CMMI
(Nawrocki et al., 2002). For example, the XP requirements management approach, which relies
on oral communication, was evaluated as not compliant with CMMI.
CMMI can be appraised using two different approaches: staged and continuous. The staged
approach yields appraisal results as one of five maturity levels. The continuous approach yields
one of six capability levels. The differences in these approaches are felt only in the appraisal; the
best practices are equivalent and result in equivalent process improvement results.
6.3.2 Appraisal
An organization cannot be certified in CMMI; instead, an organization is appraised. Depending
on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a
capability level achievement profile.
Many organizations find value in measuring their progress by conducting an appraisal.

Appraisals are typically conducted for one or more of the following reasons:
To determine how well the organizations processes compare to CMMI best practices,
and to identify areas where improvement can be made
To inform external customers and suppliers of how well the organizations processes
compare to CMMI best practices
To meet the contractual requirements of one or more customers
Appraisals of organizations using a CMMI model must conform to the requirements defined in
the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals,
A, B and C, which focus on identifying improvement opportunities and comparing the
organizations processes to CMMI best practices. Of these, class A appraisal is the most formal
and is the only one that can result in a level rating. Appraisal teams use a CMMI model and
ARC-conformant appraisal method to guide their evaluation of the organization and their
reporting of conclusions. The appraisal results can then be used (e.g., by a process group) to plan
improvements for the organization.
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal
method that meets all of the ARC requirements. Results of an SCAMPI appraisal may be
published (if the appraised organization approves) on the CMMI Web site of the SEI: Published
SCAMPI Appraisal Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known
as SPICE (Software Process Improvement and Capability Determination), assessments etc.
6.4 SUMMARY
Software quality has been a principle concern. In the early days of trading, acceptable quality
was generally decided by agreement between developers and end users. With the wider extent of
technology, some traditional means of effective acceptable quality became important. Standards
performs basis of understanding, provides degree of definiteness and precision for new methods,
permits accurate results comparison, reduce cost of design and of maintenance by use of
developed, proven products and techniques and assists in the coordination of development by
establishing methods and direction. ISO 9000 is necessary but not enough to guarantee software
quality.
Assignment-Module 3
1.
___________defines and establishes an organization's quality policy and objectives.
a.
QMC
b.
QMS
c.
QA
d.
QC
2.
Known quality standards are
a.
ISO 9126
b.
IEEE
c.
ISO 9000
d.
None of them
3.
Series of standards defined by organization for their structure, their products,
services and their specific function are

a.
Six
b.
Five
c.
Fourteen
d.
Nine
4.
Motorola developed strategy for business
a.
ISO 9000
b.
ISO 9001
c.
ISO 9004
d.
Six sigma
5.
Phases of DMAIC
a.
Define, Measure, Analyze, Improve, Control
b.
Detect, Measure, Analyze, Implement, Control
c.
Define, Maintain, Approve, Improve, Control
d.
None of them
6.
Control charts used for
a.
find and eliminate special-cause variation
b.
analyze and eliminate faults
c.
None of them
d.
Both of them
7.
A basic version of quality improvement
a.
IS0 9000
b.
Six sigma
c.
CMM
d.
None of them
8.
Total number of maturing levels in CMM are
a.
One
b.
Five
c.
Six
d.
Seven
9.
CMM stands for
a.
Capability Maturity model
b.
Capacity Maturity model
c.
Cost management model
d.
Comprehensive maintenance model
10.
Which level of CMM is for project management
a.
Initial
b.
Defined
c.
Managed
d.
Repeatable
Key - Module 6
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
REFERENCES
1. Software Engineering: A Practitioner's Approach, Pressman, R, S, , 6th Ed., PrenticeHall, 2000.
2. Software Quality Engineering: Testing, Quality
Improvement, Jeff Tian, John Wiley & Sons, 2005.
Assurance
and
Quantifiable
3. CSTE Common Body Of Knowledge, V6.1 and CSQA Common Body Of Knowledge,
V6.2.
4. Managing Quality an Integrative Approach, Foster, S. Thomas, Upper Saddle River:
Prentice Hall, 2001.
5. Quality Function Deployment - A Practitioners Approach, James L. Brossert,
(Milwaukee, Wisc.: ASQC Quality Press, 1991.
6. Software Quality: Concepts and Evidences, Luis Fernndez Sanz, Departamento de
Sistemas Informticos Universidad Europea de Madrid.
7. Software Testing, Antonia Bertolino, Istituto di Elaborazione della Informazione
Consiglio Nazionale delle RicercheResearch Area of S. Cataldo 56100 PISA Italy.
8. The Quality Toolbox, Nancy R. Tague, ASQ Quality Process, Second Edition, 2004.
9. www.acw.mit.edu
10. www.aleanjourney.com
11. www.asq.org
12. www.cnx.org
13. www.cs.colostate.edu
14. www.csbdu.in
15. www.defectmanagement.com
16. www.drdobbs.com
17. www.ehow.com
18. www.exforsys.com
19. www.herkules.oulu.fi
20. www.icoachmath.com
21. www.ipcc-nggip.iges.org.jp
22. www.johnsonandjohnson.com.
23. www.mhhe.com
24. www.mks.com
25. www.msdn.microsoft.com
26. www.msqaa.org
27. www.peart.ucs.indiana.edu
28. www.physicaltherapyjournal.com
29. www.processexcellencenetwork.com
30. www.processexcellencenetwork.com
31. www.qualitydigest.com
32. www.selectbs.com
33. www.softwaretestingdiary.com
34. www.sqa.net
35. www.stylusinc.com
36. www.timkastelle.org
37. www.undergraduate.cse.uwa.edu.au
38. www.westfallteam.com
39. www.wikipedia.com
40. www.zarate-consult.de
41. http://dissertations.ub.rug.nl
42. http://msdn.microsoft.com

Software Quality and Assurance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Quality and Assurance

Uploaded by

Copyright:

Available Formats

Software

Software quality is a complex and multifaceted concept that can be

2.2.5 Iterative processes......................................................................................................... 41

3.3.1 Affinity Diagram .......................................................................................................... 97

4.3.5 Theoretical and practical limitations of testing .......................................................... 131

4.7 THE TESTING PROCESS ............................................................................................... 144

4.15 SUMMARY .................................................................................................................... 183

5.13.3 Manage by process. .................................................................................................. 208

CHAPTER 1 : QUALITY CONCEPTS AND PRACTICES

1.1.1 Definition of Quality

1.2 COST OF QUALITY

1.3 TOTAL QUALITY MANAGEMENT

1.3.1 TQM Definition

Reducing development cycle times

Figure 1.1 : TQM Interface

1.3.2 Principles of TQM

Systematic measurement and focus on CONQ

1.3.3 The Concept of Continuous Improvement by TQM

There are three major mechanisms of prevention:

Preventing mistakes (defects) from occurring (Mistake - proofing or Poka-Yoke).

Figure 1.1: Role if ISO 9000

1.3.4 Implementation Principles and Processes of TQM

1.3.5 The building blocks of TQM

Figure 1.2 : The TQM blocks

1.4 APPROACHES TO QUALITY

1.4.1 TQM Approach

Organizations should be consumer focused by understanding their needs and meeting

A process approach should be taken to activities and any related resources

Interrelated processes should be identified as a system to boost efficiency in meeting

Organizations should strive for continual improvement

Decisions should be based on factual information

A mutually beneficial relationship should be created between organizations and suppliers

1.4.2 Six Sigma

2. Which__________ model shows the direct relationship with quality conformance.

3. __________ states that quality is __________.

4. The objective of TQM is __________.

5. __________ quality system also requires the establishment of procedures that

8. TQM__________ of quality and Six sigma __________ of quality.

9. Deming suggested ___________ principles of quality management.

CHAPTER 2 : SOFTWARE QUALITY

2.1.1 System/Information Engineering and Modeling

2.1.2 Software Development Life Cycle

2.1.4 Software development activities

2.1.5 Process Activities/Steps

2.1.5.1 System/Information Engineering and Modeling

2.1.5.2 Requirements Analysis

2.1.5.4 Software architecture

2.1.5.8 Training and Support

2.2 SOFTWARE DEVELOPMENT MODELS OR PROCESS

2.2.1 Waterfall Model

Requirements specification (Requirements analysis)

Implementation and Integration

Testing (or Validation)

Deployment (or Installation)

2.2.2 Prototyping Model

2.2.3 Spiral model

Risk analysis: an analytical assessment of selected programs, to consider how to identify

the implementation of the project: the implementation of software development and

2.2.4 Strength and Weakness of Waterfall, Prototype and Spiral Model

(ii) Prototyping Model

The prototype may become the production system

(iii) Spiral Model

2.2.5 Iterative processes

2.2.6 Rapid Application Development (RAD) Model

3. states that quality is .

8. TQM of quality and Six sigma of quality.