QUALITY
STANDARDS
Unit V
Topics
Covered:
§ Need for standards
§ ISO
9000 series
§ ISO
9000-3 series
§ CMM
and CMMI
§ Six
Sigma Concepts
1.Need
for Standards:
Standardization
(or standardisation) is the process of agreeing on technical standards.
A
standard is a document that establishes uniform engineering or technical
specifications, criteria,
methods,
processes, or practices. Some standards are mandatory while others are
voluntary.
Some
standards are defacto, meaning informal practices followed out of convenience,
or dejure, meaning formal requirements. Formal standards bodies such as the
International Standard Organisation(ISO) or the American National Standard
University are independent of the manufacturers of the goods for which they
publish standards.
The
goals of standardization can be to help with independence of single suppliers
(commodification), compatibility, interoperability, safety, repeatability, or
quality.
In
social sciences, including economics, the idea of standardization is
close to the solution for a coordination problem, a situation in which all
parties can realize mutual gains, but only by making mutually consistent
decisions. Standardization is the process for select better choices and
ratificate this consistent decisions, as an obtained standard.
Types
of standardization process:
- Emergence in de facto use: tradition (old standards on countries) and/or domination (Microsoft ex.).
- Fixed by a standard body:
- in an impositive process: usually in mandatory norms (like dictatorial Laws).
- in a consensus process: usually for voluntary standards
standardization is defined as: The development and implementation of
concepts, doctrines, procedures and designs to achieve and maintain the
required levels of compatibility, interchangeability or commonality in the
operational, procedural, material, technical and administrative fields to
attain interoperability
2.ISO
9000 Series:
ISO
9000 is a family of standards
for quality management systems. ISO 9000 is maintained by ISO, the
International Organization for Standardization and is administered by
accreditation and certification bodies.
ISO-9001
covers the entire process from product design through after sales service.
ISO-9002
covers only the manufacture (or a specific service such as a QC/QA laboratory)
of the product.
ISO-9003
covers the "final inspection" of the product only.
ISO-9004 is
an "Internal Use" standard - it cannot be registered and is not
subject to the third party audits.
ISO-9001:
Some of
the requirements in ISO 9001 (which is one of the standards in the ISO 9000
family) would include
- a set of procedures that cover all key processes in the business;
- monitoring processes to ensure they are effective;
- keeping adequate records;
- checking output for defects, with appropriate corrective action where necessary;
- regularly reviewing individual processes and the quality system itself for effectiveness; and
- facilitating continual improvement
A
company or organization that has been independently audited and certified to be
in conformance with ISO 9001 may publicly state that it is "ISO 9001
certified" or "ISO 9001 registered." Certification to an ISO
9000 standard does not guarantee the compliance (and therefore the quality) of
end products and services; rather, it certifies that consistent business
processes are being applied.
Although the standards
originated in manufacturing, they are now employed across a wide range of other
types of organizations. A "product", in ISO vocabulary, can mean a
physical object, or services, or software. In fact, according to ISO in 2004, "service
sectors now account by far for the highest number of ISO 9001:2000 certificates
- about 31% of the total"
ISO 9001:2000 specifies
requirements for a quality management system where an organization
- needs to demonstrate its ability to consistently provide product that meets customer and applicable regulatory requirements, and
- aims to enhance customer satisfaction through the effective application of the system, including processes for continual improvement of the system and the assurance of conformity to customer and applicable regulatory requirements.
All requirements of this
International Standard are generic and are intended to be applicable to all
organizations, regardless of type, size and product provided.
Where
any requirement(s) of this International Standard cannot be applied due to the
nature of an organization and its product, this can be considered for
exclusion.
Where exclusions are made,
claims of conformity to this International Standard are not acceptable unless
these exclusions are limited to requirements within clause 7, and such
exclusions do not affect the organization's ability, or responsibility, to
provide product that meets customer and applicable regulatory requirements.
ISO-9002:
Developing products to a standard of consistent high quality, Scorpion Research is a recognised leader in its field and proud to announce its achievement of the coveted ISO 9002 quality certification. The ISO 9002 standard is an emerging global standard for product and process quality, adopted by 91 countries which comprise the International Organisation for Standardisation (ISO). ISO 9002 is best known to European countries who use the certification as a means of identifying companies dedicated to providing a customer with the best product and service possible. Scorpion Research has always emphasised its quality through a continuous improvement program complementing its other quality initiatives. Achieving ISO 9002 certification further demonstrates commitment to a consistent level of quality recognised under International standards. According to ISO assessors, the certification process is rigorous and only a minority of the applicants who strive to become certified are successful on their first audit. Scorpion Research is amongst this minority of organisations that passed the required certification audit on the first assessment demonstrating its consistent emphasis towards a high quality standard. Certification is an ongoing process and Scorpion Research will undergo regular internal and external audits by third party ISO assessors in order to retain its certification. The ISO certification complements the quality program by establishing an externally verified unbiased process of self-monitoring and problem-solving. Scorpion Research joins firms such as British Telecom, Sony, IBM, Compaq, Digital Equipment, Xerox, Toshiba and Hewlett-Packard in ISO certification. |
ISO-9003:
ISO 9003
This is the least complex and easiest to install of three standards in the ISO 9000 series. This standard is for organizations that do not participate in design and development, purchasing or have production controls. It is designed for organizations that only require final inspection and testing of their products and services to ensure that they have met the specified requirements. This system is generally only relevant to simple products and services. It is also an option for organizations that cannot justify the expense of one of the other systems but still desire a quality management system for their organization.
This is the least complex and easiest to install of three standards in the ISO 9000 series. This standard is for organizations that do not participate in design and development, purchasing or have production controls. It is designed for organizations that only require final inspection and testing of their products and services to ensure that they have met the specified requirements. This system is generally only relevant to simple products and services. It is also an option for organizations that cannot justify the expense of one of the other systems but still desire a quality management system for their organization.
ISO-9004:
·
Your quality system must balance two needs:
·
Your customers' need to have quality
products at a reasonable price.
products at a reasonable price.
·
Your company's need to make quality
products at a reasonable cost.
products at a reasonable cost.
3.ISO9000-3
for software development:
ISO 9000-3 |
4.4 Software development and design |
4.4.1
General |
Develop
and document procedures to control the product design and development
process. These procedures must ensure that all requirements are being
met.
|
Software
development
|
Control
your software development project and make
sure that it is executed in a disciplined manner.
·
Use one or more life cycle models to
help
organize your software development project.
·
Develop and document your software
development
procedures. These procedures should ensure that:
·
Software products meet all
requirements.
·
Software development follows your:
·
Quality plan.
·
Development plan.
|
Software
design
|
Control
your software design process and make
sure that it is performed in a systematic way.
·
Use a suitable software design method.
·
Study previous software design
projects
to avoid repeating old mistakes.
Design
software that is:
·
Easy to test, install, use, and
maintain.
·
Safe and reliable when failure could
cause:
·
Human injury.
·
Property damage.
·
Environmental harm.
Develop
and document rules to control:
·
Coding activities.
·
Naming conventions.
·
Commentary practices.
·
Programming languages.
Apply
configuration management techniques to
document and control the use and review of all:
·
Analysis tools.
·
Design techniques.
·
Compilers and assemblers.
Train
personnel in the use of such tools and techniques.
|
4.4.2
Design and development planning |
Create
design and development planning procedures.
Your product planning procedures should ensure that:
·
Plans are prepared for each design
activity or phase.
·
Responsibility for implementing each
plan,
activity, or phase is properly defined.
·
Qualified personnel are assigned to
the
product design and development process.
·
Adequate resources are allocated to
the
product design and development process.
·
Plans are updated, and circulated to
the
appropriate participants, as designs change. |
Software
design and development planning
|
Prepare
a software development plan. Your plan should be documented and approved
before it is implemented. Your plan should control:
·
Technical activities.
·
Requirements analyses.
·
Design processes.
·
Coding activities.
·
Integration methods.
·
Testing techniques.
·
Installation work.
·
Acceptance testing.
·
Management activities.
·
Project supervision.
·
Progress reviews.
·
Reporting requirements.
Your
software development plan should:
·
Define your project.
·
Identify related plans and projects.
·
List your project objectives.
·
Define project inputs and outputs.
·
Define inputs for each project
activity.
·
Define outputs for each project
activity.
·
Explain how your project will be
organized.
·
Explain how your teams will be
structured.
·
Explain who will be responsible for
what.
·
Explain how subcontractors will be
used.
·
Explain how project participants will
interact.
·
Explain how all resources will be
managed.
·
Discuss project risks and potential
problems.
·
Identify important project
assumptions.
·
Present your project schedule.
·
Define project phases and
dependencies.
·
Specify project time lines and
milestones.
·
Introduce your project budget.
·
Describe the work that will be done.
·
Describe each task.
·
Describe the inputs for each task.
·
Describe the outputs for each task.
·
Identify all relevant control
strategies.
·
Identify all relevant standards and
conventions.
·
Identify all relevant rules and
regulations.
·
Identify all relevant practices and
procedures.
·
Identify configuration management
practices.
·
Identify backup and recovery
procedures.
·
Identify archiving procedures.
·
Identify all relevant methods and
approaches.
·
Identify methods used to control
nonconforming products.
·
Identify methods used to control
software development software
·
Identify methods used to control virus
protection activities.
·
Identify all relevant tools and
techniques.
·
Identify methods used to qualify all
tools and techniques.
·
Identify methods used to control all
tools and techniques.
|
4.4.3
Organizational and technical interfaces |
Identify
the groups who should be routinely involved in the product design and
development process, and ensure that their design input is properly
documented, circulated, and reviewed.
Make
sure that your software development
plan or your subcontractors' plans:
·
Define how the responsibility for
software development
will be distributed between all participants.
·
Define how technical information will
be shared
and transmitted between all participants.
Explain
how all project participants will provide input.
·
Explain how subcontractors will provide
input during
design, installation, maintenance, and training.
·
Explain how regulatory authorities
will provide input
during design, installation, maintenance, and training.
·
Explain how help desk staff will
provide input during
design, installation, maintenance, and training.
·
Explain how other related projects
will provide input
during design, installation, maintenance, and training.
·
Explain how end users will provide
input during
design, installation, maintenance, and training.
Make
sure that your customer has
accepted the responsibility to:
·
Cooperate and support your project.
·
Provide the information you need when
you need it.
·
Resolve outstanding issues in a timely
manner.
Make
sure that your customer representative has
been given the responsibility and authority to:
·
Clarify requirements and expectations.
·
Answer questions and solve problems.
·
Make and implement agreements.
·
Approve plans and proposals.
·
Establish acceptance criteria.
·
Provide appropriate customer-supplied
products.
·
Define and distribute authorities and
responsibilities.
Schedule
joint progress reviews. You and
your customer together should review:
·
Activities.
·
Your developmental activities.
·
Your customer's activities.
·
Your users' activities.
·
Training activities.
·
Conversion activities.
·
Results.
·
Results of verification activities.
·
Results of acceptance tests.
·
Results of conformance evaluations.
|
4.4.4
Design input |
Develop
procedures to ensure that all design-input requirements are identified,
documented, and reviewed; and that all design flaws, ambiguities,
contradictions, and deficiencies are resolved. Design input requirements
can be classified as follows:
·
Customer expectations.
·
Contractual conditions.
·
Statutory imperatives.
·
Regulatory requirements.
·
Environmental constraints.
·
Safety considerations.
·
Performance standards.
·
Functional specifications.
·
Descriptive prescriptions.
·
Aesthetic preferences.
|
Software
design input |
Design
input requirements should be specified by the customer. However, sometimes
the customer will expect you to develop the
design input specification. In this case, you should:
·
Prepare procedures that you can use to
develop the design input specification. These procedures should be
documented and should explain:
·
How interviews, surveys, studies,
prototypes, and demonstrations will be used to develop
your design-input specification.
·
How you and your customer will
formally agree:
·
To accept the official specification.
·
To accept changes to the official
specification.
·
How changes to specifications will be
controlled.
·
How prototypes and product
demonstrations will be evaluated.
·
How system oriented input requirements
will be met through the use of hardware, software, and
interface technologies.
·
How reviews, evaluations, and other
discussions
between you and your customer will be recorded.
·
Work closely with your customer in
order to avoid misunderstandings and to ensure that the
specification meets the customers needs.
·
Express your specification using terms
that will make
it easy to validate during product acceptance.
·
Ask your customer to formally approve
the
resulting design input specification.
Your
design input specification may address the
following kinds of characteristics or requirements:
·
Functional requirements.
·
Reliability requirements.
·
Usability requirements.
·
Efficiency requirements.
·
Maintainability requirements.
·
Portability requirements.
·
Interface requirements.
·
Hardware interface requirements.
·
Software interface requirements.
Your
design input specification may also need
to address the following kinds of requirements:
·
Operational requirements.
·
Safety requirements.
·
Security requirements.
·
Statutory requirements.
|
4.4.5
Design output |
Develop
procedures to control design outputs.
·
Design outputs are usually documents.
They include drawings, parts lists, process specifications, servicing
procedures, and storage instructions. These types of documents are used for
purchasing, production, installation, inspection, testing, and servicing.
·
Design outputs must be expressed in terms
that allow
them to be compared with design input requirements.
·
Design output documents must identify
those aspects of the product that are crucial to its safe and effective
operation. These aspects can include operating, storage, handling, maintenance,
and disposal requirements.
·
Design output documents must be
reviewed
and approved before they are distributed.
·
Design outputs must be accepted only
if
they meet official acceptance criteria. |
Software
design output |
·
Prepare design output documents using
standardized methods and make sure that your documents are
correct and complete.
·
Software design outputs can include
design specifications,
source code, user guides, etc. |
4.4.6
Design review |
Develop
procedures that specify how design reviews should be
planned and performed. Design review procedures should:
·
Be formally documented.
·
Ensure that reviews are recorded.
·
Ensure that representatives from all
relevant
areas are involved in the process of review. |
Software
design review
|
Plan
and perform design reviews for software development
projects. Your reviews should ensure that all:
·
Design activities and results are
reviewed.
·
Product nonconformities are identified
and addressed.
·
Process deficiencies are identified
and addressed.
·
Review conclusions and observations
are recorded.
|
Software
design review procedures
|
Develop
and document design review procedures.
Your procedures should make sure that you:
·
Clarify exactly what is being
reviewed.
·
Distinguish between different types of
reviews.
·
Organize and schedule design review
meetings.
·
Indicate when design reviews should be
performed.
·
Maintain a record of all design review
meetings.
·
Invite all appropriate groups to
participate.
·
Invite customers to participate (when
required).
·
Confirm that customers agree with your
results.
·
Allow design activities to continue
only if all:
·
Deficiencies and nonconformities have
been addressed.
·
Risks and consequences have been
assessed.
Your
design review procedures may also:
·
Define the methods that should be used
to ensure
that all rules and conventions are being followed.
·
Define what needs to be done to
prepare
for a design review. This may include:
·
Defining roles.
·
Listing objectives.
·
Preparing an agenda.
·
Collecting documents.
·
Define what should be done during the
review.
This may include:
·
Defining the guidelines that should be
followed.
·
Defining the techniques that should be
used.
·
Define the criteria that constitute a
successful review.
·
Define the follow-up methods that
should be used to
ensure that all outstanding issues will be addressed. |
4.4.7
Design verification |
Develop
procedures that specify how design outputs, at every stage
of the product design and development process, should be verified. These procedures should:
·
Verify that outputs satisfy
design-input requirements.
·
Ensure that objective evidence is used
to verify outputs.
·
Ensure that all design verifications
are recorded.
·
Ensure that all design documents are
verified.
These
design verification procedures may also:
·
Use alternative calculations to verify
design outputs.
·
Use tests and demonstrations to verify
outputs.
·
Compare design outputs with proven
designs.
|
Software
design verification
|
Verify
design outputs by:
·
Performing design reviews.
·
Performing demonstrations.
·
Evaluating prototypes.
·
Carrying out simulations.
·
Performing tests.
Maintain
a record of design verifications.
·
Record verification results.
·
Record remedial actions.
·
Record action completions.
Accept
design outputs for subsequent use only if they have been
properly verified and only if all remedial actions have been taken.
|
4.4.8
Design validation |
Develop
procedures that validate the assumption that your newly
designed products will meet customer needs. Develop design validation procedures that:
·
Confirm that your new product performs
properly
under all real-world operating conditions.
·
Confirm that your new product will
meet every
legitimate customer need and expectation.
·
Ensure that validations are carried
out early in the design process whenever this will help guarantee
that customer needs will be met.
|
Software
design validation
|
·
Prove that your product is ready for
its intended
use before you ask your customer to accept it.
·
Accept validated products for
subsequent use only if they have been properly verified and only if
all remedial actions have been taken.
·
Maintain a record of design
validations.
·
Record validation results.
·
Record remedial actions.
·
Record action completions.
|
4.4.9
Design changes |
Develop
procedures to ensure that all product design modifications are
documented, reviewed, and formally authorized before the resulting documents are circulated and the changes are implemented. |
Software
design changes
|
·
Develop procedures to control design
changes that may occur during
the product life cycle. Your procedure should ensure that you:
·
Document the design change.
·
Evaluate the design change.
·
Justify the design change.
·
Verify the design change.
·
Approve the design change.
·
Implement the design change.
·
Monitor the design change.
Your
configuration management process
may be used to control design changes. |
4.CMM and CMMI:
The Capability
Maturity Model (CMM), also sometimes referred to as the Software
CMM (SW-CMM).The CMM is a process capability model based on
software development organisation processes/practices.
Though
the CMM was retired in 1997 and has not been updated since, having been
superseded by CMMI (Capability Maturity Model Integration), it has been
used as a generally applicable model to assist in understanding the process
capability maturity of organisations in diverse areas. For example, software
engineering, system engineering, project management, risk management, system
acquisition, information technology (IT) or personnel management, against a
scale of five maturity levels, namely: Initial, Repeatable, Defined, Managed
and Optimized.
The Capability Maturity Model (CMM)
is a process capability maturity model which aids in the definiton and
understanding of an organisation's processes. The CMM was originally used to
enable the assessment of software development processes.
The
SEI’s Capability Maturity Model (CMM) and Capability Maturity Model Integrated
(CMMI) are the most prominent examples of a model based approach to process
improvement. The CMM is limited to management and software engineering
practices. The CMMI expands the CMM to
address systems engineering and integrated product development as well.
The
CMMI is organized around a set of Process Areas (PAs). The PAs are divided into
groups associated with what are called maturity levels. In the CMMI, most basic management practices
are considered part of maturity level 2, while most software engineering
practices are associated with level 3. Level 4 is about process and product
quality management, while level 5 includes processes for process optimization
and technology change management.
An
organization that has practices that meet all the goals of maturity level 2 is
characterized as a level 2 organization. An organization that cannot
demonstrate that its practices meet all the applicable level 2 goals is
considered level 1 by default. An organization that meets the goals of all the
PAs at level 2 and level 3 is a level 3 maturity organization and so on.
The
CMMI also offers an alternate approach
call the "continuous representation", where individual PA's are rated
on a maturity scale of 1 - 5. This
allows the organization the flexibility to tailoring its maturity goals based
on business needs for particular PA's.
As
organizations move up the maturity ladder, they are more likely to produce
higher quality products with more predictable costs and cycle times. The higher levels are more likely to
correlate with higher productivity and shorter cycle times as well.
The
idea of model based software improvement is very simple. First pick the applicable Process Areas. Next perform an assessment of
organizational practices relative to the model.
The organization practices do not have to conform exactly to the
representative practices included in the model.
They just have to meet the stated goals of each PA. Based on this comparison, assign a maturity
level to the organization and produce a list of strengths and weakness relative
to the model.
The
output of the assessment is used to prioritize areas for improvement. The idea is to improve deficient practices at
the lower maturity levels first and systematically move up in maturity level
over time using additional assessments to measure progress.
Focusing
on the lowest level practices puts a firm foundation in place before tacking
the higher level processes and it give the organization time to internalize the
changes. This approach nicely avoids the
twin problems of putting practices in place before required supporting
practices are available and trying to do too much too soon.
So
model based improvement has a lot of very attractive features. One of the most attractive ones is the level
goal itself. The numerical level gives
organizations a metric that that can be easily understood, can used to measure
progress, and can used to benchmark against other organizations.
SEI
has defined a formal appraisal methodology and provided a lead assessor
training and certification program. This
means that assessment results, particular those obtained using a third party
assessor, will be reasonably consistent and can be used to benchmark against
other organizations. In fact SEI
maintains a publicly accessible database of assessment results giving the
number of organizations at each level by industry and the average time for an
organization to improve from one level to the next.
6.Six Sigma Concept:
Six Sigma at many organizations simply means a measure of
quality that strives for near perfection. Six Sigma is a disciplined,
data-driven approach and methodology for eliminating defects (driving towards
six standard deviations between the mean and the nearest specification limit)
in any process -- from manufacturing to transactional and from product to
service.
The statistical representation of Six Sigma describes
quantitatively how a process is performing. To achieve Six Sigma, a process
must not produce more than 3.4 defects per million opportunities. A Six Sigma
defect is defined as anything outside of customer specifications. A Six Sigma
opportunity is then the total quantity of chances for a defect. Process sigma
can easily be calculated using a Six-Sigma calculator.
The fundamental objective of the Six Sigma methodology is
the implementation of a measurement-based strategy that focuses on process
improvement and variation reduction through the application of Six Sigma
improvement projects. This is accomplished through the use of two Six Sigma
sub-methodologies: DMAIC and DMADV. The Six Sigma DMAIC process (define,
measure, analyze, improve, control) is an improvement system for existing
processes falling below specification and looking for incremental improvement.
The Six Sigma DMADV process (define, measure, analyze, design, verify) is an
improvement system used to develop new processes or products at Six Sigma
quality levels. It can also be employed if a current process requires more than
just incremental improvement. Both Six Sigma processes are executed by Six
Sigma Green Belts and Six Sigma Black Belts, and are overseen by Six Sigma
Master Black Belts.
Six
Sigma is a set of practices
originally developed by Motorola to systematically improve processes by
eliminating defects.A defect is defined as nonconformity of a product or
service to its specifications.
While
the particulars of the methodology were originally formulated by Bill Smith at
Motorola in 1986, Six Sigma was heavily inspired by six preceding decades of
quality improvement methodologies such as quality control, TQM, and Zero
Defects. Like its predecessors, Six Sigma asserts the following:
- Continuous efforts to reduce variation in process outputs is key to business success
- Manufacturing and business processes can be measured, analyzed, improved and controlled
- Succeeding at achieving sustained quality improvement requires commitment from the entire organization, particularly from top-level management
Sigma
(the lower-case Greek letter σ) is used to represent standard deviation (a measure of variation) of
a population (lower-case 's', is an estimate, based on a sample). The term
"six sigma process" comes from the notion that if one has six
standard deviations between the mean of a process and the nearest specification limit, there
will be practically no items that fail to meet the specifications. This is the
basis of the Process Capability Study, often used by quality
professionals. The term "Six Sigma" has its roots in this tool,
rather than in simple process standard deviation, which is also measured in
sigmas. Criticism of the tool itself, and the way that the term was derived
from the tool, often sparks criticism of Six Sigma.
No comments:
Post a Comment