Quality management checklist

In this file, you can ref useful information about quality management checklist such as quality
management checklistforms, tools for quality management checklist, quality management
checkliststrategies If you need more assistant for quality management checklist, please leave
your comment at the end of file.
Other useful material for quality management checklist:
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 checklist

==================
Applicable
Yes, No,
Comment?

Quality Planning Area

Key quality concepts to consider

Quality management

Optional

Executive summary of
quality assurance practices

Include a high-level list of your project's

quality practices. For example:

Identify the set of reviews and

checkpoints for the project, including entry
and/or exit criteria; hold those reviews, and
measure against entry/exit criteria.

Identify the standards to be used to

measure project deliverable quality.

Identify the metrics to be used to

measure project deliverable quality.

Establish the problem reporting,

change, and configuration management
practices for the project.

Test the project deliverables.

Recommende
d

Roles and responsibilities

Identify who is responsible for doing which

quality tasks. See the Quality Plan
Template for examples.

Optional

Quality assurance estimated

resources and training needs

Estimate the resources needed to complete

the quality activities.

Quality checkpoints and deliverable reviews

Identify the reviews and checkpoints used to determine whether the
deliverables and processes are meeting an acceptable level of
quality.Checkpoints are milestones or stage gates held during a project to
assess the state of the project and its deliverables.

Recommende
d

Requirements reviews

Identify how requirements are reviewed.

See the Requirements Checklist. The
requirements for some projects may be
developed and reviewed using Agile
techniques, collaborating with business
partners to create user stories with
acceptance criteria, tracking user stories to
project deliverables, and using acceptance
criteria as the basis for acceptance,
functional and unit tests.
Key quality questions:

Recommende
d

Does everyone understand the

problem statement or the meaning of each
requirement?

Does everyone understand which

requirements are most important?

Does everyone agree on how we'll

know the requirements have been met
(definition of 'done')?

Have major decisions been

captured?

Architecture checkpoint
Identify the plan for assessing the
architecture. Significant new or changed
architecture will warrant a separate
architecture checkpoint; otherwise the
architecture and design checkpoints may be
combined. This checkpoint allows external
architecture advisors to contribute the
enterprise view to the architecture and
design of the application, and also provides
a forum to inject security best practices
early in the design process.
Key quality questions:

Is the architecture the best solution?

Are there alternatives?

Does the proposed architecture

adhere to the UW applications
architecture guiding principles?

Has an external architecture advisor

participated in the architecture discussions
or reviewed the architecture?

Recommende
d

Design checkpoint with test

plan review

Have major decisions been

captured?

Identify the plan for reviewing the design

and test plan. This checkpoint could be
combined with the architecture checkpoint.
This checkpoint determines if security risks
have been addressed, if the best solution has
been chosen from the alternatives, if all the
requirements are addressed in the design &
test plan, and if support has been
considered. See the Design Review
Checklist and the Test Planning Checklist on
the UW Project Management Portal. For
small projects, the design and test plan can
be as little as a single paragraph or a few
bullet items each.
Key quality questions:

Do the design and test plan address

all of the business and technical
requirements in scope?

Does everyone understand the

design?

Is the design the best solution? Are

there alternatives?

Is there enough information for

production support?

Does the proposed design adhere to

the UW applications architecture guiding
principles? To team or other standards?

Have solutions to security risks been

discussed?

Has an external architecture advisor

participated in the design discussions or
reviewed the design?

Has an Application Security

Review been held?

Does the test plan adequately verify

that

the solution completely

resolves the problem or meets the request?

security isn't impaired?

the design is implemented

correctly?

the application, changed

functionality, and any 'affected-bys' or
downstream systems still work (regression)

Have major decisions been

captured?

Security Reviews
Recommende
d

Recommende
d

Identify the plan for holding security

reviews. For example, a statement indicating
that the project team conducts internal
reviews of high risk deliverables against
OWASP Secure Coding Principles for Web
applications and the OWASP top ten most
critical web application security flaws. See
the UW-IT Application Security Review
Process.

Code walkthroughs

Identify the plan for code walkthroughs. For

example, the project team members hold
informal 'desk check' code reviews for most

of the code, including any automated tests,

with more formal code walkthroughs for
high risk code, such as code involving new
methods, new technology, new design, or
restricted/confidential data.
Key quality questions:

Recommende
d

Does the code reflect the intent of

the design?

Does the code meet team,

architectural or security standards?

Has every new or changed

component been unit tested?

Have major decisions been

captured?

Testing
At a high level, describe the plans and
procedures for testing the deliverables,
referencing separate test plans if needed.
Reference testing standards and practices,
including which test phases and test
readiness checkpoints are planned. Identify
the process for reviewing the test plans, test
cases, and test results. If not addressed in a
separate test plan, identify the defect
tracking processes, test environments, test
roles and responsibilities, and test phase
entrance/exit criteria. See the Test Planning
Checklist on the UW Project Management
Portal.
Key quality questions:

Is the test environment adequate?

Do testers have enough training to

know how to test?

Optional

Have major decisions been

captured?

See Design checkpoint with test plan

review (above) for additional questions
related to testing

Project management
reviews

Identify project management areas to be

evaluated. For example:

Optional

progress relative to the overall

project plan, scope, deliverables, project
budget, and project schedule
project risks and risk management

requirements coverage (e.g., user

story tracking to project deliverables and
testing)

quality issues raised during the

quality checkpoints and reviews

Project documentation
reviews

Identify the project documents that will be

reviewed for completeness and correctness.
For example:

Project Plan (as part of the project

management reviews)

Test Plans (as part of the testing

process and design checkpoint)

Production Readiness
Checklist (ongoing and as part of the

production readiness checkpoint)

Optional

Deployment plan

Support plan

Production support documentation

Process reviews
Identify the planned evaluations of the
project's project and development processes.
These evaluations help to determine if the
processes provide value and how they can
be improved. For example, evaluate key
processes during sprint retrospectives and at
the end of the project:

Recommende
d

review the defect management

process to determine if defects are being
documented with adequate information for
analysis, and if defects are analyzed to find
trends

review development processes to

determine if they identified deficiencies or
defects in requirements, architecture, design,
code and test plans at an early enough point
for corrective action

review change management

processes

Production readiness
checkpoint (go/no-go to
'Deploy')

Identify the process for determining whether

deliverables are ready to deploy to
production, and production readiness criteria
(see the Production Readiness Checklist).
Example production readiness criteria:

All integration, functional, and user

acceptance tests have been run and all high

priority tests have passed

Load testing results meet the

minimum performance thresholds identified
in the requirements

All "Blocker" bugs have been

resolved and associated tests rerun
successfully

All unresolved bugs have been

documented and include workarounds if
needed

Production environment is available,

stable, populated and validated

The state of operational readiness is

acceptable

The project production readiness

recommendation has been completed and
stakeholders agree with it
Key quality questions:

Was the solution adequately tested

(including security & regression)?

Did someone other than the

developer run tests? Have users tested the
solution?

Are test results documented? (for

small efforts, this can be a copy of the test
plan with notes)

Have defects found during testing

been captured? Were critical defects

resolved and retested?

Have all requirements in scope been

met?

Has a schedule and communication

plan been determined for implementation?

Has maintenance documentation

been updated?

Has changed user documentation

been reviewed and approved by the users?

Is the customer satisfied?

Does the change work in

production?

Is there an audit trail of production

changes?

Is there a plan for ongoing security

reviews of the application?

Have major decisions been

captured?

Optional

Project closure review

Identify the entrance and exit criteria for

project closeout. This review highlights
lessons learned and identifies improvements
for future projects. See the Project Closure
Checklist on the Project Management Portal.

Optional

Operational readiness
review (transition to
support)

Identify the plan for reviewing readiness for

transitioning from active development to
production support.

Standards and guidelines

Identify standards and guidelines which will be used to measure project
deliverable and process quality. Describe quality requirements, any metrics,
and how conformance will be monitored. Include links or references to team
and organizational standards.

Recommende
d

Project change and system

configuration management
practices

Document the change and configuration

management practices for the project. For
example, the list of tools used for version
control and deployment from development
environment into test and production.

Recommende
d

Problem reporting and

corrective actions

Describe the process for capturing and

tracking resolutions to problems found
during the reviews. Include product, project
and process issues and defects.

Documentation standards

Identify project and product documentation

standards.

Technical standards

Identify technical standards to be used

during the project. For example:

Optional

Recommende
d

Recommende

Security and

Architecture and design standards

Naming standards (coding and data)

Coding, construction or
configuration standards

Accessibility standards

Identify the standards addressing

authentication/authorization
standards

authentication and authorization

(appropriate authorized users/systems with
the appropriate level of access)
and management of external security threats
(e.g., OWASP standards).

Recommende
d

Project management
standards and practices /
development methodology

Identify the project management methods

and the development methodology, and
reference team practices. For example:

Recommende
d

The project uses Agile processes,

including Scrum and Lean-Kanban, which
are reviewed for improvement at the end of
each sprint and defined in the Team
Agreement.

The criteria for moving user stories

from state to state (from Specify to Execute
to Verify to Done) are defined and refined
by the team. The teams definition of done
will be documented in the Team Agreement.

Deployment guidelines

Identify standard processes for deploying

changes from environment to environment
and into production.

Metrics
Optional

Identify quality assurance product and

process metrics. For example:

The number of errors detected

during design and/or code walkthroughs

The number of staff hours expended

(actual vs. planned) on development and
bug fixing

The number of errors detected

during user acceptance tests

The number of project-related

defects found in production after
implementation

The number of staff hours expended

on quality reviews

The number of errors detected in

project-generated software deliverables
during the pilot

The ratio of positive vs. negative

results from a user satisfaction survey

The amount of time spent on fixing

defects after a feature is considered
complete

The amount of time spent on fixing

defects after implementation

Supplier control
Optional

Identify the methods and procedures for:

assuring that deliverables provided

by suppliers meet established requirements

assuring that the software supplier

receives adequate and complete
requirements

assuring that the supplier has

prepared and implemented a quality plan,
and the methods to determine the supplier's
compliance with that plan

contract review and update.

Optional

Tools, techniques, and

methodologies

Identify the software tools, techniques, and

methods used to support the quality
activities. (May be included in other
sections.)

Media control
Optional

Optional

Identify the media for deliverables and the

processes for storage/copying/restoration of
the media. Include how the media will be
protected from unauthorized access or
inadvertent damage or degradation during
all phases of the project life cycle. (May be
included in the System Configuration
Management Plan.)
Records collection,
maintenance, and
retention

Identify the quality assurance

documentation to be retained. Describe the
methods to be used to assemble, file,
safeguard, and maintain this documentation,
including the retention period. (May be
included in the project Records Retention
Plan.)

Training
Optional

Identify the training activities necessary to

meet the needs described in the quality plan.
For example:

Train production support teams in

root cause analysis and defect prevention
methods.

Train all project members in basic

testing methods, including problem
reporting.

Risk management
Optional

Describe the methods and procedures used

to identify, assess, monitor, and control

areas of risk arising during the project life
cycle. (May be included in the project Risk
Management Plan.)

==================

III. Quality management tools

1. Check sheet
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
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
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
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

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 checklist (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