Quality Management Ebook

Software Testing : Quality Mangement eBook from www.OneStopTesting.
com
Software Testing :Quality

Management
Free Study Material from
www.OneStopTesting.com
World’s Largest Portal on Software Testing Information & Jobs -

http://www.OneStopTesting.com
Join Software Testing Community at
http://groups.yahoo.com/group/OneStopTesting/
Over 5,000 Testing Interview Questions at
http://www.CoolInterview.com
Software Testing : Quality Mangement eBook from www.OneStopTesting.com
Quality Management
Quality management is a method for ensuring that all the activities necessary to
design, develop and implement a product or service are effective and efficient with
respect to the system and its performance. Quality management can be considered
to have three main components: quality control, quality assurance and quality
improvement. Quality management is focused not only on product quality, but also
the means to achieve it. Quality management therefore uses quality assurance and
control of processes as well as products to achieve more consistent quality.

Component Of Quality Management

There are the main components of Quality Management:
Components:
Quality Control
Quality Assurance
Quality Improvement
Software Quality Factors
Quality Control
Quality control is a process employed to ensure a certain level of quality in a product

or service. It may include whatever actions a business deems necessary to provide
for the control and verification of certain characteristics of a product or service. The
basic goal of quality control is to ensure that the products, services, or processes
provided meet specific requirements and are dependable, satisfactory, and fiscally
sound.
Essentially, quality control involves the examination of a product, service, or process

for certain minimum levels of quality. The goal of a quality control team is to identify
products or services that do not meet a companyâ€™s specified standards of quality.
If a problem is identified, the job of a quality control team or professional may
involve stopping production temporarily. Depending on the particular service or
product, as well as the type of problem identified, production or implementation may
not cease entirely.
Usually, it is not the job of a quality control team or professional to correct quality
issues. Typically, other individuals are involved in the process of discovering the
cause of quality issues and fixing them. Once such problems are overcome, the
product, service, or process continues production or implementation as usual.
Quality control can cover not just products, services, and processes, but also people.
Employees are an important part of any company. If a company has employees that
donâ€™t have adequate skills or training, have trouble understanding directions, or
are misinformed, quality may be severely diminished. When quality control is
considered in terms of human beings, it concerns correctable issues. However, it
should not be confused with human resource issues.

Often, quality control is confused with quality assurance. Though the two are very
similar, there are some basic differences. Quality control is concerned with the
product, while quality assurance is processâ€“oriented.
Even with such a clear-cut difference defined, identifying the differences between the
two can be hard. Basically, quality control involves evaluating a product, activity,
process, or service. By contrast, quality assurance is designed to make sure
processes are sufficient to meet objectives. Simply put, quality assurance ensures a
product or service is manufactured, implemented, created, or produced in the right
way; while quality control evaluates whether or not the end result is satisfactory.
Example
Quality Control refers to quality related activities associated with the creation of
project deliverables. Quality control is used to verify that deliverables are of
acceptable quality and that they are complete and correct. Examples of quality
control activities include deliverable peer reviews and the testing process.
Quality Assurance refers to the process used to create the deliverables, and can be
performed by a manager, client, or even a third-party reviewer. Examples of quality
assurance include process checklists and project audits. If your project gets audited,
for instance, an auditor might not be able to tell if the content of a specific
deliverable is acceptable (quality control). However, the auditor should be able to tell
if the deliverable seems acceptable based on the process used to create it (quality
assurance). That's why project auditors can perform a quality assurance review on
your project, even if they do not know the specifics of what you are delivering. They
don't know your project, but they know what good processes look like.
Here's an example to drive home the point. Let's say a project manager asked the
sponsor to approve the Business Requirements Report. If you were the sponsor, how
would you validate that the business requirements seemed complete and correct?
One solution would be for you to actually review the document and the business
requirements. If you did that, you would be performing a quality control activity,
since your actions would be based on validating the deliverable itself.
However, let's say the document was thirty pages long and that you (as the sponsor)
did not have the expertise, the time, or the inclination to do a specific content
review. In that case, you wouldn't ask to review the document itself. Instead, you
would ask the project manager to describe the process used to create the document.
Let us say you received the following reply.

Project manager - "I gathered eight of your major users in a facilitated session. After
the meeting, I documented the requirements and asked the group for their feedback,
modifications, etc. I then took these updated requirements to representatives from
the Legal, Finance, Manufacturing and Purchasing groups and they added
requirements that were needed to support company standards. We then had a
meeting with the four managers in your area that are most impacted by this system.
These managers added a few more requirements. I then asked your four managers
to sign off on the requirements and you can see their signatures on the last page."
If you were the sponsor, would you now feel comfortable to sign the requirements?
If it were me, I would feel pretty comfortable.
That's the difference. Quality control activities are focused on the deliverable itself.
Quality assurance activities are focused on the process used to create the
deliverable. They are both powerful techniques and both must be performed to
ensure that the deliverables meet your customers quality requirements.
Quality Assurance
Quality assurance, or QA for short, is the activity of providing evidence needed to

establish quality in work, and that activities that require good quality are being
performed effectively. All those planned or systematic actions necessary to provide
enough confidence that a product or service will satisfy the given requirements for
quality.
Quality assurance activities
Quality assurance covers all activities from design, development, production,

installation, servicing and documentation. This introduced the rules: "fit for purpose"
and "do it right the first time". It includes the regulation of the quality of raw
materials, assemblies, products and components; services related to production; and
management, production, and inspection processes.
One of the most widely used paradigms for QA management is the PDCA (Plan-Do-
Check-Act) approach, also known as the Shewhart cycle.
• Failure testing
Quality assurance covers all activities from design, development, production,

installation, servicing and documentation. This introduced the rules: "fit for
purpose" and "do it right the first time". It includes the regulation of the
quality of raw materials, assemblies, products and components; services
related to production; and management, production, and inspection

processes.
• Statistical control
Many organizations use statistical process control to bring the organization to

Six Sigma levels of quality, in other words, so that the likelihood of an
unexpected failure is confined to six standard deviations on the normal
distribution. This probability is less than four one-millionths. Items controlled
often include clerical tasks such as order-entry as well as conventional
manufacturing tasks.
Traditional statistical process controls in manufacturing operations usually

proceed by randomly sampling and testing a fraction of the output. Variances
of critical tolerances are continuously tracked, and manufacturing processes
are corrected before bad parts can be produced.
• ISO 17025
ISO 17025 is an international standard that specifies the general

requirements for the competence to carry out tests and or calibrations. There
are 15 management requirements and 10 technical requirements. These
requirements outline what a laboratory must do to become accredited.
Management system refers to the organization's structure for managing its
processes or activities that transform inputs of resources into a product or
service which meets the organization's objectives, such as satisfying the
customer's quality requirements, complying with regulations, or meeting
environmental objectives.
For software development organization, CMMI (Capability Maturity Model

Integration) standards are widely used to measure the Quality Assurance.
These CMMI standards can be divided in to 5 steps, which a software
development company can achieve by performing different quality
improvement activities within the organization.
Company Quality
During the 1980s, the concept of “company quality” with the focus on management
and people came to the fore. It was realised that, if all departments approached
quality with an open mind, success was possible if the management led the quality
improvement process.

The company-wide quality approach places an emphasis on four aspects :-
1. Elements such as controls, job management, adequate processes,

performance and integrity criteria and identification of records
2. Competence such as knowledge, skills, experience, qualifications
3. Soft elements, such as personnel integrity, confidence, organizational culture,
motivation, team spirit and quality relationships.
4. Infrastructure (as it enhances or limits functionality)
The quality of the outputs is at risk if any of these aspects is deficient in any way.
The approach to quality management given here is therefore not limited to the
manufacturing theatre only but can be applied to any business activity:
• Design work
• Administrative services
• Consulting
• Banking
• Insurance
• Computer software
• Retailing
• Transportation
It comprises a quality improvement process, which is generic in the sense it can be

applied to any of these activities and it establishes a behaviour pattern, which
supports the achievement of quality.
This in turn is supported by quality management practices which can include a

number of business systems and which are usually specific to the activities of the
business unit concerned.
In manufacturing and construction activities, these business practices can be

equated to the models for quality assurance defined by the International Standards
contained in the ISO 9000 series and the specified Specifications for quality systems.
Still, in the system of Company Quality, the work being carried out was shop floor
inspection which did not control the major quality problems. This led to quality
assurance or total quality control, which has come into being recently.

Concepts and Definitions
Software Quality Assurance (SQA) is defined as a planned and systematic approach

to the evaluation of the quality of and adherence to software product standards,
processes, and procedures.SQA includes the process of assuring that standards and
procedures are established and are followed throughout the software acquisition life
cycle. Compliance with agreed-upon standards and procedures is evaluated through
process monitoring, product evaluation, and audits. Software development and
control processes should include quality assurance approval points, where an SQA
evaluation of the product may be done in relation to the applicable standards.
Standards and Procedures
Establishing standards and procedures for software development is critical, since

these provide the framework from which the software evolves. Standards are the
established criteria to which the software products are compared. Procedures are the
established criteria to which the development and control processes are compared.
Standards and procedures establish the prescribed methods for developing software;
the SQA role is to ensure their existence and adequacy.Proper documentation of
standards and procedures is necessary since the SQA activities of process
monitoring, product evaluation and auditing rely upon unequivocal definitions to
measure project compliance. Types of standards include:
Documentation Standards specify form and content for planning, control, and
product documentation and provide consistency throughout a project. The NASA
Data Item Descriptions (DIDs) are documentation standards.
Design Standards specify the form and content of the design product.They provide
rules and methods for translating the software requirements into the software design
and for representing it in the design documentation.
Code Standards specify the language in which the code is to be written and define
any restrictions on use of language features. They define legal language structures,
style conventions, rules for data structures and interfaces, and internal code
documentation. Procedures are explicit steps to be followed in carrying out a
process. All processes should have documented procedures. Examples of processes
for which procedures are needed are configuration management, nonconformance
reporting and corrective action, testing, and formal inspections.

If developed according to the NASA DID, the Management Plan describes the
software development control processes, such as configuration management, for
which there have to be procedures, and contains a list of the product standards.
Standards are to be documented according to the Standards and Guidelines DID in
the Product Specification. The planning activities required to assure that both
products and processes comply with designated standards and procedures are
described in the QA portion of the Management Plan.
Software Quality Assurance Activities
Product evaluation and process monitoring are the SQA activities that assure the
software development and control processes described in the project's Management
Plan are correctly carried out and that the project's procedures and standards are
followed. Products are monitored for conformance to standards and processes are
monitored for conformance to procedures. Audits are a key technique used to
perform product evaluation and process monitoring. Review of the Management Plan
should ensure that appropriate SQA approval points are built into these processes.
Product evaluation is an SQA activity that assures standards are being followed.
Ideally, the first products monitored by SQA should be the project's standards and
procedures. SQA assures that clear and achievable standards exist and then
evaluates compliance of the software product to the established standards. Product
evaluation assures that the software product reflects the requirements of the
applicable standard(s) as identified in the Management Plan.
Process monitoring is an SQA activity that ensures that appropriate steps to carry
out the process are being followed. SQA monitors processes by comparing the actual
steps carried out with those in the documented procedures. The Assurance section of
the Management Plan specifies the methods to be used by the SQA process
monitoring activity.
A fundamental SQA technique is the audit, which looks at a process and/or a product
in depth, comparing them to established procedures and standards. Audits are used
to review management, technical, and assurance processes to provide an indication
of the quality and status of the software product.
The purpose of an SQA audit is to assure that proper control procedures are being
followed, that required documentation is maintained, and that the developer's status
reports accurately reflect the status of the activity. The SQA product is an audit
report to management consisting of findings and recommendations to bring the
development into conformance with standards and/or procedures.

SQA Relationships to Other Assurance Activities

Some of the more important relationships of SQA to other management and
assurance activities are described below.
1. Configuration Management Monitoring
SQA assures that software Configuration Management (CM) activities are performed
in accordance with the CM plans, standards, and procedures. SQA reviews the CM
plans for compliance with software CM policies and requirements and provides
follow-up for nonconformances. SQA audits the CM functions for adherence to
standards and procedures and prepares reports of its findings.
The CM activities monitored and audited by SQA include baseline control,

configuration identification, configuration control, configuration status accounting,
and configuration authentication. SQA also monitors and audits the software library.
SQA assures that: Baselines are established and consistently maintained for use in
subsequent baseline development and control.
Software configuration identification is consistent and accurate with respect to the

numbering or naming of computer programs, software modules, software units, and
associated software documents. Configuration control is maintained such that the
software configuration used in critical phases of testing, acceptance, and delivery is
compatible with the associated documentation.
Configuration status accounting is performed accurately including the recording and

reporting of data reflecting the software’s configuration identification, proposed
changes to the configuration identification, and the implementation status of
approved changes.
Software configuration authentication is established by a series of configuration

reviews and audits that exhibit the performance required by the software
requirements specification and the configuration of the software is accurately
reflected in the software design documents. Software development libraries provide
for proper handling of software code, documentation, media, and related data in
their various forms and versions from the time of their initial approval or acceptance
until they have been incorporated into the final media.
Approved changes to baselined software are made properly and consistently in all
products, and no unauthorized changes are made.

2. Verification and Validation Monitoring
SQA assures Verification and Validation (V&V) activities by monitoring technical

reviews, inspections, and walkthroughs. The SQA role in formal testing is described
in the next section. The SQA role in reviews, inspections, and walkthroughs is to
observe, participate as needed, and verify that they were properly conducted and
documented. SQA also ensures that any actions required are assigned, documented,
scheduled, and updated.
Formal software reviews should be conducted at the end of each phase of the life
cycle to identify problems and determine whether the interim product meets all
applicable requirements. Examples of formal reviews are the Preliminary Design
Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). A
review looks at the overall picture of the product being developed to see if it satisfies
its requirements. Reviews are part of the development process, designed to provide
a ready/not-ready decision to begin the next phase. In formal reviews, actual work
done is compared with established standards. SQA's main objective in reviews is to
assure that the Management and Development Plans have been followed, and that
the product is ready to proceed with the next phase of development. Although the
decision to proceed is a management decision, SQA is responsible for advising
management and participating in the decision.
An inspection or walkthrough is a detailed examination of a product on a step-by-

step or line-of-code by line-of-code basis to find errors. For inspections and
walkthroughs, SQA assures, at a minimum, that the process is properly completed
and that needed follow-up is done. The inspection process may be used to measure
compliance to standards.
3. Formal Test Monitoring
SQA assures that formal software testing, such as acceptance testing, is done in
accordance with plans and procedures. SQA reviews testing documentation for
completeness and adherence to standards. The documentation review includes test
plans, test specifications, test procedures, and test reports. SQA monitors testing
and provides follow-up on nonconformances. By test monitoring, SQA assures
software completeness and readiness for delivery.
The objectives of SQA in monitoring formal software testing are to assure that:
The test procedures are testing the software requirements in accordance with test
plans.

The test procedures are verifiable.
The correct or "advertised" version of the software is being tested (by SQA
monitoring of the CM activity).
The test procedures are followed.
Nonconformances occurring during testing (that is, any incident not expected in the
test procedures) are noted and recorded.
Test reports are accurate and complete.
Regression testing is conducted to assure nonconformances have been corrected.
Resolution of all nonconformances takes place prior to delivery.
Software testing verifies that the software meets its requirements. The quality of
testing is assured by
verifying that project requirements are satisfied and that the testing process is in
accordance with the test plans and procedures.

Software Quality Assurance During the Software

Acquisition Life Cycle
In addition to the general activities described in subsections C and D, there are

phase-specific SQA activities that should be conducted during the Software
Acquisition Life Cycle. At the conclusion of each phase, SQA concurrence is a key
element in the management decision to initiate the following life cycle phase.
Suggested activities for each phase are described below.
1. Software Concept and Initiation Phase
SQA should be involved in both writing and reviewing the Management Plan in order
to assure that the processes, procedures, and standards identified in the plan are
appropriate, clear, specific, and auditable. During this phase, SQA also provides the
QA section of the Management Plan.
2. Software Requirements Phase
During the software requirements phase, SQA assures that software requirements
are complete, testable, and properly expressed as functional, performance, and
interface requirements.
3. Software Architectural
(Preliminary) Design Phase SQA activities during the architectural (preliminary)

design phase include:
·Assuring adherence to approved design standards as designated in the Management

Plan.
·Assuring all software requirements are allocated to software components.
· Assuring that a testing verification matrix exists and is kept up to date.
·Assuring the Interface Control Documents are in agreement with the standard in
form and content.
·Reviewing PDR documentation and assuring that all action items are resolved.
·Assuring the approved design is placed under configuration management.

4. Software Detailed Design Phasev
SQA activities during the detailed design phase include:
·Assuring that approved design standards are followed.
·Assuring that allocated modules are included in the detailed design.
·Assuring that results of design inspections are included in the design.
Reviewing CDR documentation and assuring that all action items are resolved.
5. Software Implementation Phase
SQA activities during the implementation phase include the audit of:
·Results of coding and design activities including the schedule contained in the s/w
Development Plan.
·Status of all deliverable items.
·Configuration management activities and the software development library.
·Nonconformance reporting and corrective action system.
6. Software Integration and Test Phase
SQA activities during the integration and test phase include:
Assuring readiness for testing of all deliverable items.
·Assuring that all tests are run according to test plans and procedures and that any
nonconformances are reported and resolved.
·Assuring that test reports are complete and correct.
· Certifying that testing is complete and software and documentation are ready for
delivery.
·Participating in the Test Readiness Review and assuring all action items are
completed.

7. Software Acceptance and Delivery Phase
As a minimum, SQA activities during the software acceptance and delivery phase
include assuring the performance of a final configuration audit to demonstrate that
all deliverable items are ready for delivery.
8. Software Sustaining Engineering and Operations Phase
During this phase, there will be mini-development cycles to enhance or correct the
software. During these development cycles, SQA conducts the appropriate phase-
specific activities described above.

Techniques and Tools

SQA should evaluate its needs for assurance tools versus those available off-the-
shelf for applicability to the specific project, and must develop the others it requires.
Useful tools might include audit and inspection checklists and automatic code
standards analyzers.

Quality Improvement
Glossary of Quality Improvement Terms
Common-Cause Variation: Any normal variation inherent in a work process. (See

also Special-Cause Variation.)
Complexity: Unnecessary work; any activity that makes a work process more
complicated without adding value to the resulting product or service.
Continuous Improvement Process: The ongoing enhancement of work processes

for the benefit of the customer and the organization; activities devoted to
maintaining and improving work process performance through small and gradual
improvements as well as radical innovations.
Control Chart: A line graph that identifies the variation occurring in a work process
over time; helps distinguish between common-cause variation and special-cause
variation.
Cost of Quality: A term used by many organizations to quantify the costs

associated with producing quality products. Typical factors taken into account are
prevention costs (training, work process analyses, design reviews, customer
surveys), appraisal costs (inspection and testing), and failure costs (rework, scrap,
customer complaints, returns).
Cross Functional: Involving the cooperation of two or more departments within the
organization (e.g., Marketing and Product Development).
Customer: Any person or group inside or outside the organization who receives a
product or service.
Customer Expectations: The "needs" and "wants" of a customer that define

"quality" in a specified product or service.
Deming Cycle (also known as Shewart's Wheel): A model that describes the
cyclical interaction of research, sales, design, and production as a continuous work
flow, so that all functions are involved constantly in the effort to provide products
and services that satisfy customers and contribute to improved quality. (See also
PDCA.)

Department Improvement Team: Made up of all members of a department and

usually chaired by the manager or supervisor, department improvement teams
function as a vehicle for all employees to continuously participate in ongoing quality
improvement activities.
Executive Steering Committee (or Executive Improvement Team): Includes

top executives and is chaired by the CEO; encourages and participates in a quality
initiative by reviewing, approving, and implementing improvement activities.
Fitness-For-Use: Juran's definition of quality suggesting that products and services

need to serve customers' needs, instead of meeting internal requirements only.
Improving Steering Council (also known as Quality Steering Committee): A

group of people with representation from all functions in the organization, usually
drawn from management levels, chartered to develop and monitor a quality
improvement process in their own functions. This group is often responsible for
deciding which improvement projects or work processes will be addressed and in
what priority.
Internal Customer: Anyone in the organization who relies on you for a product or
service. (See also Customer.)
Internal Supplier: Anyone in the organization you rely on for a product or service.
(See also Supplier.) Juran Trilogy: The interrelationship of three basic managerial
processes with which to manage quality, quality control, and quality improvement.
Just-In-Time (JIT): A method of production and inventory cost control based on

delivery of parts and supplies at the precise time they are needed in a production
process.
Kaizen: Japanese term meaning continuous improvement involving everyone-

managers and employees alike.
Key Expectations: The requirements concerning a specified product or service that

a customer holds to be most important.
PDCA Cycle: An adaptation of the Deming Cycle, which stresses that every
improvement activity, can best be accomplished by the following steps: plan, do,
check, etc. (See Deming Cycle.)
Process Improvement Team: Includes experienced employees from different

departments who solve problems and improve work processes that go across-
functional lines. (Also known as Service Improvement Team, Quality Improvement
Team, or Corrective Action Team.)

Quality: a customer's perception of the value of a product or service; organizations,

theorists, and dictionaries define it differently. Well-known definitions include:
"conformance to requirements" (Crosby)
"the efficient production of the quality that the market expects" (Deming)
"fitness for use"; "product performance and freedom from deficiencies" (Juran)
"the total composite product and service characteristics of marketing, engineering,

manufacturing, and maintenance through which the product and service in use will
meet the expectations of the customer" (Felgenbaum)
"anything that can be improved" (Imal)
"meeting or exceeding customer expectations at a cost that represents value to

them" (Harrington)
"does not impart loss to society" (Taguchi)
"the totality of features and characteristics of a product or service that bear on its
ability to satisfy a given need" (American Society for Quality Control)
"degree of excellence" (Webster's Third New International Dictionary)
Quality Circle: A small group of employees organized to solve work-related

problems; often voluntarily; usually not chaired by a department manager.
Quality Initiative: A formal effort by an organization to improve the quality of its

products and services; usually involves top management development of a mission
statement and long-term strategy.
Special-Cause Variation: Any violation arising from circumstances that are not a
normal part of the work process. (See also Common-Cause Variation.)
Supplier: Any person or group inside or outside the organization that produces a
product or service. Suppliers improve quality by identifying customer expectations
and adjusting work processes so that products and services meet or exceed those
expectations. (See also Customer.)
Task Force: An ad hoc, cross-functional team formed to resolve a major problem as

quickly as possible; usually includes subject matter experts temporarily relieved of
their regular duties.

Total Quality Control (TQM): A management approach advocating the

involvement of all employees in the continuous improvement process-not-just quality
control specialists.
Work Partnership: A mutually beneficial work relationship between internal and

external customers and suppliers.
Work Process: A series of work steps that produce a particular product or service
for the customer.
Zero Defects: An approach to quality based on prevention of errors; often adopted

as a standard for performance or a definition of quality (notably in Crosby Quality
Training).

Software Quality Factors

A software quality factor is a non-functional requirement for a software program
which is not called up by the customer's contract, but nevertheless is a desirable
requirement which enhances the quality of the software program.
Some software quality factors are listed here:
1. Understandability is possessed by a software product if the purpose of the

product is clear. This goes further than just a statement of purpose - all of the
design and user documentation must be clearly written so that it is easily
understandable. This is obviously subjective in that the user context must be
taken into account, i.e. if the software product is to be used by software
engineers it is not required to be understandable to the layman.
2. A software product possesses the characteristic completeness to the extent
that all of its parts are present and each of its parts is fully developed. This
means that if the code calls a sub-routine from an external library, the
software package must provide reference to that library and all required
parameters must be passed. All required input data must be available.
3. A software product possesses the characteristic conciseness to the extent
that no excessive information is present. This is important where memory
capacity is limited, and it is important to reduce lines of code to a minimum.
It can be improved by replacing repeated functionality by one sub-routine or
function which achieves that functionality. It also applies to documents.
4. A software product possesses the characteristic portability to the extent that
it can be operated easily and well on computer configurations other than its
current one. This is particularly important with PC applications where, for
example, a product is expected to work on all 80486 processors.
5. A software product possesses the characteristic maintainability to the extent
that it facilitates updating to satisfy new requirements. Thus the software
product which is maintainable should be well-documented, not complex,
and should have spare capacity for memory usage and processor speed.
6. A software product possesses the characteristic testability to the extent that
it facilitates the establishment of acceptance criteria and supports evaluation
of its performance. Such a characteristic must be built-in during the design
phase if the product is to be easily testable - a complex design leads to poor
testability.
7. A software product possesses the characteristic usability to the extent that it
is convenient and practicable to use. This is affected by such things as the
human-computer interface. The component of the software which has most
impact on this is the graphical user interface (GUI).
8. A software product possesses the characteristic reliability to the extent that
it can be expected to perform its intended functions satisfactorily. This implies
a time factor in that a reliable product is expected to perform correctly over a
period of time. It also encompasses environmental considerations in that the

Capability Maturity Model

The Capability Maturity Model (CMM) is a process capability maturity model which
aids in the definition and understanding of an organisation's processes.
The CMM (aka Humphrey's Capability Maturity Model) was originally described in the
book Managing the Software Process (Addison Wesley Professional, Massachusetts,
1989) Watts Humphrey. The CMM was conceived by Watts Humphrey, who based it
on the earlier work of Phil Crosby. Active development of the model by the SEI (US
Dept. of Defence Software Engineering Institute) began in 1986. The SEI was at
Carnegie Mellon University in Pittsburgh.
The CMM was originally intended as a tool for objectively assessing the ability of
government contractors' processes to perform a contracted software project. Though
it comes from the area of software development, it can be (and has been and still is
being) applied 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), personnel management. It has been used
extensively for avionics software and government projects around the world.
Though still thus widely used as a general tool, for software development purposes
the CMM has been superseded by CMMI (Capability Maturity Model Integration). The
old CMM was renamed to Software Engineering CMM (SE-CMM) and organizations
accreditations based on SE-CMM expired on the 31st of December, 2007.
Other variants of the CMM include Software Security Engineering CMM SSE-CMM and
People CMM. Other maturity models such as ISM3 have also emerge
Contents:
Maturity Model
Structure of CMM
Levels of the CMM
Key process areas
Sokftware process framework for SEI's CMM
History
Controversial aspects
Beneficial Elements of CMM Level 2 and 3

Maturity Model
A maturity model is a structured collection of elements that describe certain aspects
of maturity in an organization. A maturity model may provide, for example:
• a place to start
• the benefit of a community’s prior experiences
• a common language and a shared vision
• a framework for prioritizing actions
• a way to define what improvement means for your organization.
A maturity model can be used as a benchmark for assessing different organizations

for equivalent comparison. The model describes the maturity of the company based
upon the project the company is handling and the related clients.

Structure of CMM
The CMM involves the following aspects:
• Maturity Levels: It is a layered framework providing a progression to the

discipline needed to engage in continuous improvement (It is important to
state here that an organization develops the ability to assess the impact of a
new practice, technology, or tool on their activity. Hence it is not a matter of
adopting these, rather it is a matter of determining how innovative efforts
influence existing practices. This really empowers projects, teams, and
organizations by giving them the foundation to support reasoned choice.)
• Key Process Areas: A Key Process Area (KPA) identifies a cluster of related
activities that, when performed collectively, achieve a set of goals considered
important.
• Goals: The goals of a key process area summarize the states that must exist
for that key process area to have been implemented in an effective and
lasting way. The extent to which the goals have been accomplished is an
indicator of how much capability the organization has established at that
maturity level. The goals signify the scope, boundaries, and intent of each key
process area.
• Common Features: Common features include practices that implement and
institutionalize a key process area. These five types of common features
include: Commitment to Perform, Ability to Perform, Activities Performed,
Measurement and Analysis, and Verifying Implementation.
• Key Practices: The key practices describe the elements of infrastructure and
practice that contribute most effectively to the implementation and
institutionalization of the key process areas.

Levels of the CMM
There are five levels of the CMM. According to the SEI,
"Predictability, effectiveness, and control of an organization's software

processes are believed to improve as the organization moves up these five
levels. While not rigorous, the empirical evidence to date supports this belief."
Level 1 - Initial
At maturity level 1, processes are usually not documented and change based on the
user or event. The organization does not have a stable environment and may not
know or understand all of the components that make up the environment. As a
result, success in these organizations depends on the institutional knowledge, the
competence and heroics of the people in the organization, and the level of effort
expended by the team. In spite of this chaotic environment, maturity level 1
organizations often produce products and services; however, they frequently exceed
the budget and schedule of their projects. Due to the lack of formality, level 1
organizations, often over commit, abandon processes during a crisis, and are unable
to repeat past successes. There is very little planning and executive buy-in for
projects and process acceptance is limited. IT organizations at level 1 are often seen
as a service instead of a partner.
Level 2 - Repeatable
At maturity level 2, some software development processes are repeatable, possibly

with consistent results. The processes may not repeat for all the projects in the
organization. The organization may use some basic project management to track
cost and schedule.
Process discipline is unlikely to be rigorous, but where it exists it may help to ensure
that existing practices are retained during times of stress. When these practices are
in place, projects are performed and managed according to their documented plans.
Project status and the delivery of services are visible to management at defined
points (for example, at major milestones and at the completion of major tasks).
Basic project management processes are established to track cost, schedule, and
functionality. The minimum process discipline is in place to repeat earlier successes
on projects with similar applications and scope. There is still a significant risk of
exceeding cost and time estimates.

Level 3 - Defined
The organization’s set of standard processes, which are the basis for level 3, are
established and subject to some degree of improvement over time. These standard
processes are used to establish consistency across the organization. Projects
establish their defined processes by applying the organization’s set of standard
processes, tailored, if necessary, within similarly standardized guidelines.
The organization’s management establishes process objectives for the organization’s

set of standard processes, and ensures that these objectives are appropriately
addressed.
A critical distinction between level 2 and level 3 is the scope of standards,

process descriptions, and procedures. At level 2, the standards, process
descriptions, and procedures may be quite different in each specific instance
of the process (for example, on each particular project). At level 3, the
standards, process descriptions, and procedures for a project are tailored
from the organization’s set of standard processes to suit a particular project
or organizational unit.
Level 4 - Managed
Using process metrics, management can effectively control the process (e.g., for
software development ). In particular, management can identify ways to adjust and
adapt the process to particular projects without measurable losses of quality or
deviations from specifications. Organizations at this level set quantitative
quality goals for both software process and software maintenance.
Subprocesses are selected that significantly contribute to overall process
performance. These selected subprocesses are controlled using statistical
and other quantitative techniques. A critical distinction between maturity level 3
and maturity level 4 is the predictability of process performance. At maturity level 4,
the performance of processes is controlled using statistical and other quantitative
techniques, and may be quantitatively predictable. At maturity level 3, processes are
only qualitatively predictable.

Level 5 - Optimizing
Maturity level 5 focuses on continually improving process performance through both

incremental and innovative technological improvements. Quantitative process-
improvement objectives for the organization are established, continually
revised to reflect changing business objectives, and used as criteria in
managing process improvement. The effects of deployed process improvements
are measured and evaluated against the quantitative process-improvement
objectives. Both the defined processes and the organization’s set of standard
processes are targets of measurable improvement activities.
Process improvements to address common causes of process variation and

measurably improve the organization’s processes are identified, evaluated, and
deployed.
Optimizing processes that are nimble, adaptable and innovative depends on the
participation of an empowered workforce aligned with the business values and
objectives of the organization. The organization’s ability to rapidly respond to
changes and opportunities is enhanced by finding ways to accelerate and share
learning.
A critical distinction between maturity level 4 and maturity level 5 is the type of
process variation addressed. At maturity level 4, processes are concerned with
addressing special causes of process variation and providing statistical
predictability of the results. Though processes may produce predictable results,
the results may be insufficient to achieve the established objectives. At maturity
level 5, processes are concerned with addressing common causes of process
variation and changing the process (that is, shifting the mean of the process
performance) to improve process performance (while maintaining statistical
probability) to achieve the established quantitative process-improvement
objectives.

Extensions
Recent versions of CMMI from SEI indicate a "level 0", characterized as

"Incomplete". Many observers leave this level out as redundant or unimportant, but
Pressman and others make note of it. See page 18 of the August 2002 edition of
CMMI from SEI.
Anthony Finkelstein extrapolated that negative levels are necessary to represent

environments that are not only indifferent, but actively counterproductive, and this
was refined by Tom Schorsch as the Capability Immaturity Model.

Key process areas

The CMMI contains several key process areas indicating the aspects of product
development that are to be covered by company processes.
Key Process Areas of the Capability Maturity Model Integration (CMMI)

Maturity
Abbreviation Name Area
Level
REQM Requirements Management Engineering 2
Project
PMC Project Monitoring and Control 2
Management
Project
PP Project Planning 2
Management
Project
SAM Supplier Agreement Management 2
Management
CM Configuration Management Support 2
MA Measurement and Analysis Support 2
Process and Product Quality
PPQA Support 2
Assurance
PI Product Integration Engineering 3
RD Requirements Development Engineering 3
TS Technical Solution Engineering 3
VAL Validation Engineering 3
VER Verification Engineering 3
Process
OPD Organizational Process Definition 3
Management
Process
OPF Organizational Process Focus 3
Management
Process
OT Organizational Training 3
Management
Project
IPM Integrated Project Management 3
Management
Project
ISM Integrated Supplier Management 3
Management
Project
IT Integrated Teaming 3
Management
Project
RSKM Risk Management 3
Management
DAR Decision Analysis and Resolution Support 3
OEI Organizational Environment for Support 3

Integration
Process
OPP Organizational Process Performance 4
Management
Project
QPM Quantitative Project Management 4
Management
Organizational Innovation and Process
OID 5
Deployment Management
CAR Causal Analysis and Resolution Support 5

Software process framework for SEI's CMM
The software process framework documented is intended to guide those wishing to

assess an organization/projects consistency with the CMM. For each maturity level
there are five checklist types:
TypeSD Description
Policy Describes the policy contents and KPA goals recommended by the CMM.
Describes the recommended content of select work products described
Standard
in the CMM.
Describes the process information content recommended by the CMM.
The process checklists are further refined into checklists for:
roles
entry criteria
inputs
activities
outputs
Process
exit criteria
reviews and audits
work products managed and controlled
measurements
documented procedures
training
tools
Describes the recommended content of documented procedures
Procedure
described in the CMM.
Level Provides an overview of an entire maturity level. The level overview
Overview checklists are further refined into checklists for:

KPA purposes (Key Process Areas)
KPA goals
policies
standards
process descriptions
procedures
training
tools
reviews and audits
work products managed and controlled
measurements

History of CMM
The Capability Maturity Model was initially funded by military research. The United
States Air Force funded a study at the Carnegie-Mellon Software Engineering
Institute to create an abstract model for the military to use as an objective
evaluation of software subcontractors. The result was the Capability Maturity Model,
published as Managing the Software Process in 1989. The CMM is no longer
supported by the SEI and has been superseded by the more comprehensive
Capability Maturity Model Integration (CMMI), of which version 1.2 has now been
released.
Context
In the 1970s, technological improvements made computers more widespread,

flexible, and inexpensive. Organizations began to adopt more and more
computerized information systems and the field of software development grew
significantly. This led to an increased demand for developers—and managers—which
was satisfied with less experienced professionals.
Unfortunately, the influx of growth caused growing pains; project failure became
more commonplace not only because the field of computer science was still in its
infancy, but also because projects became more ambitious in scale and complexity.
In response, individuals such as Edward Yourdon, Larry Constantine, Gerald
Weinberg, DeMarco, and David Parnas published articles and books with research
results in an attempt to professionalize the software development process.
Watts Humphrey's Capability Maturity Model (CMM) was described in the book
Managing the Software Process (1989). The CMM as conceived by Watts Humphrey
was based on the work a decade earlier of Phil Crosby who published the Quality
Management Maturity Grid in his book Quality is Free in Active development of the
model by the SEI (US Dept. of Defense Software Engineering Institute) began in
1986.
The CMM was originally intended as a tool to evaluate the ability of government
contractors to perform a contracted software project. Though it comes from the area
of software development, it can be, has been, and continues to be widely applied as
a general model of the maturity of processes (e.g., IT Service Management
processes) in IS/IT (and other) organizations.
Note that the first application of a staged maturity model to IT was not by CMM/SEI,
but rather Richard L. Nolan in 1973.

The model identifies five levels of process maturity for an organisation:
1. Initial (chaotic, ad hoc, heroic) the starting point for use of a new process.
2. Repeatable (project management, process discipline) the process is used
repeatedly.
3. Defined (institutionalized) the process is defined/confirmed as a standard
business process.
4. Managed (quantified) process management and measurement takes place.
5. Optimising (process improvement) process management includes deliberate
process optimization/improvement.
Within each of these maturity levels are KPAs (Key Process Areas) which characterise
that level, and for each KPA there are five definitions identified:
1. Goals
2. Commitment
3. Ability
4. Measurement
5. Verification
The KPAs are not necessarily unique to CMM, representing — as they do — the
stages that organizations must go through on the way to becoming mature.
The assessment is supposed to be led by an authorised lead assessor. One way in

which companies are supposed to use the model is first to assess their maturity level
and then form a specific plan to get to the next level. Skipping levels is not allowed.
N.B.: The CMM was originally intended as a tool to evaluate the ability of
government contractors to perform a contracted software project. It may be suited
for that purpose. When it became a general model for software process
improvement, there were many critics.
"Shrinkwrap" companies are also called "COTS" or commercial-off-the-shelf firms or

software package firms. They include Claris, Apple, Symantec, Microsoft, and Lotus,
amongst others. Many such companies rarely if ever managed their requirements
documents as formally as the CMM described in order to achieve level 2, and so all of
these companies would probably fall into level 1 of the model.

Origins
In the 1980s, several military projects involving software subcontractors ran over-
budget and were completed much later than planned, if they were completed at all.
In an effort to determine why this was occurring, the United States Air Force funded
a study at the SEI. The result of this study was a model for the military to use as an
objective evaluation of software subcontractors. In 1989, the Capability Maturity
Model was published as Managing the Software Process. The basis for the model is
the Quality Management Maturity Grid introduced by Philip Crosby in his 1979 book
'Quality is Free'.
Timeline
• 1987: SEI-87-TR-24 (SW-CMM questionnaire), released.

• 1989: Managing the Software Process, published.
• 1990: SW-CMM v0.2, released (first external issue see Paulk handout).
• 1991: SW-CMM v1.0, released.
• 1993: SW-CMM v1.1, released.
• 1997: SW-CMM revisions halted in support for CMMI.
• 2000: CMMI v1.02, released.
Current State
Although these models have proved useful to many organizations, the use of multiple
models has been problematic. Further, applying multiple models that are not
integrated within and across an organization is costly in terms of training, appraisals,
and improvement activities. The CMM Integration project was formed to sort out the
problem of using multiple CMMs. The CMMI Product Team's mission was to combine
three source models:
1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C

2. The Systems Engineering Capability Model (SECM)
3. The Integrated Product Development Capability Maturity Model (IPD-CMM)
v0.98
4. Supplier sourcing
CMMI is the designated successor of the three source models. The SEI has released a
policy to sunset the Software CMM and previous versions of the CMMI. The same can
be said for the SECM and the IPD-CMM; these models were superseded by CMMI.
Future Direction
With the release of the CMMI Version 1.2 Product Suite, the possibility of multiple
CMMI models was created. There is now a CMMI for Development (CMMI-DEV), V1.2
and a CMMI for Acquisition (CMMI-ACQ), V1.2. A version of the CMMI for Services is
being developed by a Northrop Grumman-led team under the auspices of the SEI,
with participation from Boeing, Lockheed Martin, Raytheon, SAIC, SRA, and Systems
and Software Consortium (SSCI).
Suggestions for improving CMMI are welcomed by the SEI. For information on how to
provide feedback, see the CMMI Web site.
In some cases, CMMI can be combined with other methodologies. It is commonly

used in conjunction with the ISO 9001 standard. JPMorgan Chase & Co. tried
combining CMM with Extreme Programming (XP), and Six Sigma. They found that
the three systems reinforced each other well, leading to better development, and did
not mutually contradict, see Extreme Programming (XP), Six Sigma and CMMI.

Controversial Aspects
The software industry is diverse and volatile. All methodologies for creating software
have supporters and critics, and the CMM is no exception.
Praise
• The CMM was developed to give Defense organizations a yardstick to assess

and describe the capability of software contractors to provide software on
time, within budget, and to acceptable standards. It has arguably been
successful in this role, even reputedly causing some software sales people to
clamour for their organizations' software engineers/developers to "implement
CMM."
• The CMM is intended to enable an assessment of an organization's maturity

for software development. It is an important tool for outsourcing and
exporting software development work. Economic development agencies in
India, Brazil, Ireland, Egypt, Syria, and elsewhere have praised the CMM for
enabling them to be able to compete for US outsourcing contracts on an even
footing.
• The CMM provides a good framework for organizational improvement. It

allows companies to prioritize their process improvement initiatives.
Criticism
• CMM has failed to take over the world. It's hard to tell exactly how wide
spread it is as the SEI only publishes the names and achieved levels of
compliance of companies that have requested this information to be listed.
The most current Maturity Profile for CMMI is available online.
• CMM is well suited for bureaucratic organizations such as government

agencies, large corporations and regulated monopolies. If the organizations
deploying CMM are large enough, they may employ a team of CMM auditors
reporting their results directly to the executive level. (A practice encouraged
by SEI.) The use of auditors and executive reports may influence the entire IT
organization to focus on perfectly completed forms rather than application
development, client needs or the marketplace. If the project is driven by a
due date, CMMs intensive reliance on process and forms may become a
hindrance to meeting the due date in cases where time to market with some
kind of product is more important than achieving high quality and
functionality of the product.

• Suggestions of scientifically managing the software process with metrics only

occur beyond the Fourth level. There is little validation of the processes cost
savings to business other than a vague reference to empirical evidence. It is
expected that a large body of evidence would show that adding all the
business overhead demanded by CMM somehow reduces IT headcount,
business cost, and time to market without sacrificing client needs.
• No external body actually certifies a software development center as being

CMM compliant. It is supposed to be an honest self-assessment. Some
organizations misrepresent the scope of their CMM compliance to suggest that
it applies to their entire organization rather than a specific project or business
unit.
• The CMM does not describe how to create an effective software development
organization. The CMM contains behaviors or best practices that successful
projects have demonstrated. Being CMM compliant is not a guarantee that a
project will be successful, however being compliant can increase a project's
chances of being successful.
• The CMM can seem to be overly bureaucratic, promoting process over

substance. For example, for emphasizing predictability over service provided
to end users. More commercially successful methodologies (for example, the
Rational Unified Process) have focused not on the capability of the
organization to produce software to satisfy some other organization or a
collectively-produced specification, but on the capability of organizations to
satisfy specific end user "use cases" as per the Object Management Group's
UML (Unified Modeling Language) approach.
• From the systemic perspective, the CMM(I) represents a (n+1) classical

engineering approach which does not take under consideration numerous
human cognitive, organizational and cultural factors, essential for the success
of every projects, see also socio-cognitive engineering viewpoint. On the
other hand, a process design is strongly connected with the process carrier
systems and their requested functions and goals, these clear computational
relations are especially important for the validation of the results of the
CMM(I) applications. It seems, the CMM(I) requires yet a solid theoretical
ontological and epistemological background in order to be a trustworthy
standard, for an example only, the arbitrary initial choice of the levels and
Key Process Areas are not sufficiently motivated.

Critical analysis of CMM has been published in at least two papers.

Bach raises questions about the validity of CMM's assertions
regarding what constitutes good software-development processes.
Bollinger and McGowan discuss flaws in CMM's use of assembly-line
process models.
• Creation of Software Specifications, stating what is going to be developed,

combined with formal sign off, an executive sponsor and approval
mechanism. This is NOT a living document, but additions are placed in a
deferred or out of scope section for later incorporation into the next cycle of
software development.
• A Technical Specification, stating how precisely the thing specified in the

Software Specifications is to be developed will be used. This is a living
document.
• Peer Review of Code (Code Review) with metrics that allow developers to
walk through an implementation, and to suggest improvements or changes.
(Note - This is problematic because the code has already been developed, and
a bad design potentially cannot be fixed by "tweaking".) The Code Review
gives complete code a formal approval mechanism.
• Version Control - a very large number of organizations have no formal

revision control mechanism or release mechanism in place.
• The idea that there is a "right way" to build software, that it is a scientific
process involving engineering design and that groups of developers are not
there to simply work on the problem du jour.

Capability Maturity Model® Integration (CMMI)

Capability Maturity Model® Integration (CMMI) is a process improvement approach
that provides organizations with the essential elements of effective processes. It can
be used to guide process improvement across a project, a division, or an entire
organization. CMMI helps integrate traditionally separate organizational functions,
set process improvement goals and priorities, provide guidance for quality processes,
and provide a point of reference for appraising current processes.
This page points you to places where you can find more information about CMMI,
and describes the worldwide adoption and benefits of CMMI.
Worldwide Adoption
The SEI is excited about the response that organizations around the world are having
to the CMMI Product Suite. CMMI is being adopted worldwide, including North
America, Europe, Asia, Australia, South America, and Africa. This kind of response
has substantiated the SEI's commitment to the CMMI models and the Standard CMMI
Appraisal Method for Process Improvement (SCAMPISM).
SCAMPI incorporates the best ideas of several process-improvement appraisal

methods. The SCAMPI Class A method is being used successfully by many
organizations. The emerging SCAMPI Class B and Class C methods will extend the
suite of SCAMPI methods. For more information about SCAMPI, see CMMI Appraisals.

Benefits of Process Improvement
The following are some of the benefits and business reasons for implementing
process improvement:
• The quality of a system is highly influenced by the quality of the process used
to acquire, develop, and maintain it.
• Process improvement increases product and service quality as organizations
apply it to achieve their business objectives.
• Process improvement objectives are aligned with business objectives.

CMMI Benefits
The following are some of the benefits and business reasons for implementing
process improvement:
The CMMI Product Suite is at the forefront of process improvement because it

provides the latest best practices for product and service development and
maintenance. The CMMI models improve the best practices of previous models in
many important ways. CMMI best practices enable organizations to do the following:
• more explicitly link management and engineering activities to their business

objectives
• expand the scope of and visibility into the product lifecycle and engineering
activities to ensure that the product or service meets customer expectations
• incorporate lessons learned from additional areas of best practice (e.g.,
measurement, risk management, and supplier management)
• implement more robust high-maturity practices
• address additional organizational functions critical to their products and
services
• more fully comply with relevant ISO standards

Process Areas
CMMI v1.2(CMMI-DEV) model contains the following 22 process areas:
• Causal Analysis and Resolution

• Configuration Management
• Decision Analysis and Resolution
• Integrated Project Management
• Measurement and Analysis
• Organizational Innovation and Deployment
• Organizational Process Definition
• Organizational Process Focus
• Organizational Process Performance
• Organizational Training
• Project Monitoring and Control
• Project Planning
• Process and Product Quality Assurance
• Product Integration
• Quantitative Project Management
• Requirements Management
• Requirements Development
• Risk Management
• Supplier Agreement Management
• Technical Solution
• Validation
• Verification

For more Software Testing Resources, please visit
Join largest Software Testing Community at
Over 5,000 Software Testing Interview Questions at
and
http://www.TestingInterviewQuestions.com
and
http://www.NewInterviewQuestions.com


Quality Management Ebook

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Quality Management Ebook

Enviado por

Direitos autorais:

Formatos disponíveis

Software Testing : Quality Mangement eBook from www.OneStopTesting.

Software Testing :Quality

World’s Largest Portal on Software Testing Information & Jobs -

World’s Largest Portal on Software Testing Information & Jobs -

Component Of Quality Management

Quality control is a process employed to ensure a certain level of quality in a product

Essentially, quality control involves the examination of a product, service, or process

World’s Largest Portal on Software Testing Information & Jobs -

World’s Largest Portal on Software Testing Information & Jobs -

Quality assurance, or QA for short, is the activity of providing evidence needed to

Quality assurance activities

Quality assurance covers all activities from design, development, production,

Quality assurance covers all activities from design, development, production,

related to production; and management, production, and inspection

Many organizations use statistical process control to bring the organization to

Traditional statistical process controls in manufacturing operations usually

ISO 17025 is an international standard that specifies the general

For software development organization, CMMI (Capability Maturity Model

World’s Largest Portal on Software Testing Information & Jobs -

The company-wide quality approach places an emphasis on four aspects :-

1. Elements such as controls, job management, adequate processes,

It comprises a quality improvement process, which is generic in the sense it can be

This in turn is supported by quality management practices which can include a

In manufacturing and construction activities, these business practices can be

World’s Largest Portal on Software Testing Information & Jobs -

Concepts and Definitions

Software Quality Assurance (SQA) is defined as a planned and systematic approach

Standards and Procedures

Establishing standards and procedures for software development is critical, since

World’s Largest Portal on Software Testing Information & Jobs -

Software Quality Assurance Activities

World’s Largest Portal on Software Testing Information & Jobs -

SQA Relationships to Other Assurance Activities

1. Configuration Management Monitoring

The CM activities monitored and audited by SQA include baseline control,

Software configuration identification is consistent and accurate with respect to the

Configuration status accounting is performed accurately including the recording and

Software configuration authentication is established by a series of configuration

World’s Largest Portal on Software Testing Information & Jobs -

2. Verification and Validation Monitoring

SQA assures Verification and Validation (V&V) activities by monitoring technical

An inspection or walkthrough is a detailed examination of a product on a step-by-

3. Formal Test Monitoring

World’s Largest Portal on Software Testing Information & Jobs -

The test procedures are verifiable.

The test procedures are followed.

Test reports are accurate and complete.

Regression testing is conducted to assure nonconformances have been corrected.

Resolution of all nonconformances takes place prior to delivery.

World’s Largest Portal on Software Testing Information & Jobs -

Software Quality Assurance During the Software

In addition to the general activities described in subsections C and D, there are

1. Software Concept and Initiation Phase

2. Software Requirements Phase

(Preliminary) Design Phase SQA activities during the architectural (preliminary)

·Assuring adherence to approved design standards as designated in the Management

·Assuring all software requirements are allocated to software components.

· Assuring that a testing verification matrix exists and is kept up to date.

·Assuring the approved design is placed under configuration management.

World’s Largest Portal on Software Testing Information & Jobs -

4. Software Detailed Design Phasev

SQA activities during the detailed design phase include:

·Assuring that approved design standards are followed.