Quality management checklist

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.

Recommended 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.
Recommended 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:
 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?
Recommended 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.
 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?
Recommended Design checkpoint with test
plan review
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.
 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)
Recommended Security Reviews 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.
Recommended 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.
 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?
Recommended 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.
 Is the test environment adequate?
 Do testers have enough training to know how
to test?
 See Design checkpoint with test plan review
(above) for additional questions related to
testing
Optional Project management reviews Identify project management areas to be
evaluated. For example:
 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
Optional 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)
 Deployment plan
 Support plan
 Production support documentation
Optional 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:
 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
Recommended 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
 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?
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.
Recommended 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.
Recommended 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.
Optional Documentation standards Identify project and product documentation
standards.
Recommended Technical standards Identify technical standards to be used during
the project. For example:
 Architecture and design standards
 Naming standards (coding and data)
 Coding, construction or configuration
standards

 Accessibility standards
Recommended Security and
authentication/authorization
standards
Identify the standards addressing
authentication and authorization (appropriate
authorized users/systems with the appropriate
level of access) and management of external
security threats (e.g., OWASP standards).
Recommended Project management
standards and practices /
development methodology
Identify the project management methods and
the development methodology, and reference
team practices. For example:
 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 team’s ‘definition of done’ will be
documented in the Team Agreement.
Recommended Deployment guidelines Identify standard processes for deploying
changes from environment to environment
and into production.
Optional Metrics 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
Optional Supplier control 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.)
Optional Media control 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.)
Optional 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.)
Optional Training 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.
Optional Risk management 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

Quality management checklist

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Quality management checklist

Similar to Quality management checklist (20)

More from selinasimpson321

More from selinasimpson321 (13)

Quality management checklist