This document discusses quality management in software engineering. It provides an abstract and introduction about quality management frameworks like ISO, TickIT and CMM. It examines the concept of quality in software development using these frameworks. The document also discusses some key characteristics of software quality and compares the different quality standards. Finally, it lists and describes some common quality management tools used in software engineering like check sheets, control charts, Pareto charts and scatter plots.

1. Quality management in software engineering
In this file, you can ref useful information about quality management in software engineering
such as quality management in software engineeringforms, tools for quality management in
software engineering, quality management in software engineeringstrategies … If you need more
assistant for quality management in software engineering, please leave your comment at the end
of file.
Other useful material for quality management in software engineering:
• qualitymanagement123.com/23-free-ebooks-for-quality-management
• qualitymanagement123.com/185-free-quality-management-forms
• qualitymanagement123.com/free-98-ISO-9001-templates-and-forms
• qualitymanagement123.com/top-84-quality-management-KPIs
• qualitymanagement123.com/top-18-quality-management-job-descriptions
• qualitymanagement123.com/86-quality-management-interview-questions-and-answers
I. Contents of quality management in software engineering
==================
Abstract
Purpose – The purpose of this paper is to examine the concept of quality related to the context of
software development using the ISO, TickIT and CMM frameworks. The paper also seeks to
stress the fact that the different perspectives of those involved in software development will
influence how quality is seen and measured. In the context of software engineering projects,
quality takes on a broad meaning that refers not only to the way in which companies manage
software engineering projects, but also to the software development process itself.
Design/methodology/approach – The approach and methodology adopted for this paper were a
review of the literature and best practice in software engineering. It is argued that users of
software systems are more interested in how easy the software is to use than in the underlying
application code that is used to generate the system. Using the body of knowledge that is
software quality the basic characteristics of software quality are described and compared in terms
of quality standards such as ISO, TickIT and CMM. Each of these standards is decomposed
further in order to clarify its usefulness.
Findings – The findings in the paper suggest that, whilst there are many differences in the
quality standards used, there are a number of similar characteristics. In essence the underlying
philosophies of ISO and CMM have at the core the same goals. Some academics see CMM as
being technically over-engineered; a CMM-compliant quality system is in many respects far in
advance of ISO.
Research limitations/implications – This paper helps define the strengths and weaknesses within
ISO, TickIT and CMM from a software engineering practitioner perspective.

2. Practical implications – The paper shows that software engineers need to pay more attention to
the performance and conformance issues in software projects and to be proactive rather than
reactive to quality issues.
Originality/value – It may be argued that the importance of this paper lies in the assertion that
those engaged in the software engineering are in need of a multi-perspective view on quality and,
with that in mind, this paper should appeal to practitioners and members of the academic
community with an interest in software quality. Keywords Quality, ISO 9000 series, Quality
standards Paper type Conceptual paper
Introduction
According to Juran (1988), 90 per cent of all problems in companies are systematic and beyond
the positive influence of staff. Unfortunately, these problems also include issues related to
quality. This means that one of the greatest challenges faced by project managers and software
professionals alike is to get the process right first time. In turn, this means initiating a rigorous
quality regime, which is both defined and measurable. A widely used definition of quality has
been supplied by the International Organisation for Standardization (ISO8042, 1988)[1]: “The
totality of features and characteristics of a product or service that bear on its ability to satisfy
specified or The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0954-478X.htm A quality management perspective 315 implied
needs”. This view of quality has come to dominate the quality movement in many software
companies. Software professionals generally acknowledge that the quality of a product (or
software system) is very much influenced by the quality of the processes used to build it. This
means in order to build high quality software systems, it is necessary to have high quality
processes and people committed to quality (Crosby, 1979).
It is also recognized (Gillies, 1996; and McManus, 2000) that software quality has its own
peculiarities. Take the following as an example: in 2002, I arranged a workshop for a specialist
group of software developers. Those who attended were asked “why software quality was
different from other types of quality”. It was suggested that each type of product made had its
own quality demands but that software was particularly problematical for the following reasons:
. Software has no physical existence.
. The lack of knowledge of client needs at the start.
. The change of client needs over time.
. The rapid rate of change in both hardware and software.
. The high expectations of customers, particularly with respect to adaptability.
Barker (1992), his observations on quality was that the quality is by large motivated by an
individuals expectations and perceived value. Barker’s point is that people determine quality, not
just procedures, tools or systems. After all, it is people that define the problems and specify the
solutions.
==================
III. Quality management tools
1. Check sheet

3. The check sheet is a form (document) used to collect data
in real time at the location where the data is generated.
The data it captures can be quantitative or qualitative.
When the information is quantitative, the check sheet is
sometimes called a tally sheet.
The defining characteristic of a check sheet is that data
are recorded by making marks ("checks") on it. A typical
check sheet is divided into regions, and marks made in
different regions have different significance. Data are
read by observing the location and number of marks on
the sheet.
Check sheets typically employ a heading that answers the
Five Ws:
 Who filled out the check sheet
 What was collected (what each check represents,
an identifying batch or lot number)
 Where the collection took place (facility, room,
apparatus)
 When the collection took place (hour, shift, day
of the week)
 Why the data were collected
2. Control chart
Control charts, also known as Shewhart charts
(after Walter A. Shewhart) or process-behavior
charts, in statistical process control are tools used
to determine if a manufacturing or business
process is in a state of statistical control.
If analysis of the control chart indicates that the
process is currently under control (i.e., is stable,
with variation only coming from sources common
to the process), then no corrections or changes to
process control parameters are needed or desired.
In addition, data from the process can be used to
predict the future performance of the process. If
the chart indicates that the monitored process is
not in control, analysis of the chart can help
determine the sources of variation, as this will

4. result in degraded process performance.[1] A
process that is stable but operating outside of
desired (specification) limits (e.g., scrap rates
may be in statistical control but above desired
limits) needs to be improved through a deliberate
effort to understand the causes of current
performance and fundamentally improve the
process.
The control chart is one of the seven basic tools of
quality control.[3] Typically control charts are
used for time-series data, though they can be used
for data that have logical comparability (i.e. you
want to compare samples that were taken all at
the same time, or the performance of different
individuals), however the type of chart used to do
this requires consideration.
3. Pareto chart
A Pareto chart, named after Vilfredo Pareto, is a type
of chart that contains both bars and a line graph, where
individual values are represented in descending order
by bars, and the cumulative total is represented by the
line.
The left vertical axis is the frequency of occurrence,
but it can alternatively represent cost or another
important unit of measure. The right vertical axis is
the cumulative percentage of the total number of
occurrences, total cost, or total of the particular unit of
measure. Because the reasons are in decreasing order,
the cumulative function is a concave function. To take
the example above, in order to lower the amount of
late arrivals by 78%, it is sufficient to solve the first
three issues.
The purpose of the Pareto chart is to highlight the
most important among a (typically large) set of
factors. In quality control, it often represents the most
common sources of defects, the highest occurring type
of defect, or the most frequent reasons for customer
complaints, and so on. Wilkinson (2006) devised an

5. algorithm for producing statistically based acceptance
limits (similar to confidence intervals) for each bar in
the Pareto chart.
4. Scatter plot Method
A scatter plot, scatterplot, or scattergraph is a type of
mathematical diagram using Cartesian coordinates to
display values for two variables for a set of data.
The data is displayed as a collection of points, each
having the value of one variable determining the position
on the horizontal axis and the value of the other variable
determining the position on the vertical axis.[2] This kind
of plot is also called a scatter chart, scattergram, scatter
diagram,[3] or scatter graph.
A scatter plot is used when a variable exists that is under
the control of the experimenter. If a parameter exists that
is systematically incremented and/or decremented by the
other, it is called the control parameter or independent
variable and is customarily plotted along the horizontal
axis. The measured or dependent variable is customarily
plotted along the vertical axis. If no dependent variable
exists, either type of variable can be plotted on either axis
and a scatter plot will illustrate only the degree of
correlation (not causation) between two variables.
A scatter plot can suggest various kinds of correlations
between variables with a certain confidence interval. For
example, weight and height, weight would be on x axis
and height would be on the y axis. Correlations may be
positive (rising), negative (falling), or null (uncorrelated).
If the pattern of dots slopes from lower left to upper right,
it suggests a positive correlation between the variables
being studied. If the pattern of dots slopes from upper left
to lower right, it suggests a negative correlation. A line of
best fit (alternatively called 'trendline') can be drawn in
order to study the correlation between the variables. An
equation for the correlation between the variables can be
determined by established best-fit procedures. For a linear
correlation, the best-fit procedure is known as linear

6. regression and is guaranteed to generate a correct solution
in a finite time. No universal best-fit procedure is
guaranteed to generate a correct solution for arbitrary
relationships. A scatter plot is also very useful when we
wish to see how two comparable data sets agree with each
other. In this case, an identity line, i.e., a y=x line, or an
1:1 line, is often drawn as a reference. The more the two
data sets agree, the more the scatters tend to concentrate in
the vicinity of the identity line; if the two data sets are
numerically identical, the scatters fall on the identity line
exactly.
5.Ishikawa diagram
Ishikawa diagrams (also called fishbone diagrams,
herringbone diagrams, cause-and-effect diagrams, or
Fishikawa) are causal diagrams created by Kaoru
Ishikawa (1968) that show the causes of a specific
event.[1][2] Common uses of the Ishikawa diagram are
product design and quality defect prevention, to identify
potential factors causing an overall effect. Each cause or
reason for imperfection is a source of variation. Causes
are usually grouped into major categories to identify these
sources of variation. The categories typically include
 People: Anyone involved with the process
 Methods: How the process is performed and the
specific requirements for doing it, such as policies,
procedures, rules, regulations and laws
 Machines: Any equipment, computers, tools, etc.
required to accomplish the job
 Materials: Raw materials, parts, pens, paper, etc.
used to produce the final product
 Measurements: Data generated from the process
that are used to evaluate its quality
 Environment: The conditions, such as location,
time, temperature, and culture in which the process
operates
6. Histogram method

7. A histogram is a graphical representation of the
distribution of data. It is an estimate of the probability
distribution of a continuous variable (quantitative
variable) and was first introduced by Karl Pearson.[1] To
construct a histogram, the first step is to "bin" the range of
values -- that is, divide the entire range of values into a
series of small intervals -- and then count how many
values fall into each interval. A rectangle is drawn with
height proportional to the count and width equal to the bin
size, so that rectangles abut each other. A histogram may
also be normalized displaying relative frequencies. It then
shows the proportion of cases that fall into each of several
categories, with the sum of the heights equaling 1. The
bins are usually specified as consecutive, non-overlapping
intervals of a variable. The bins (intervals) must be
adjacent, and usually equal size.[2] The rectangles of a
histogram are drawn so that they touch each other to
indicate that the original variable is continuous.[3]
III. Other topics related to Quality management in software engineering (pdf
download)
quality management systems
quality management courses
quality management tools
iso 9001 quality management system
quality management process
quality management system example
quality system management
quality management techniques
quality management standards
quality management policy
quality management strategy
quality management books