UNIT 1

Software quality IEEE definition

Software quality is:
1. The degree to which a system, component, or process meets specified
requirements.
2. The degree to which a system, component, or process meets customer or user
needs or expectations.
Software quality Pressmans definition
Software quality is defined as:
Conformance to explicitly stated functional and performance requirements,
explicitly documented development standards, and implicit characteristics that are
expected of all professionally developed software.
Pressmans definition suggests three requirements for quality assurance
that are to be met by the developer:
Specific functional requirements, which refer mainly to the outputs of the
software system.
The software quality standards mentioned in the contract.
Good Software Engineering Practices (GSEP), reflecting state-of-the-art
professional practices, to be met by the developer even though not explicitly
mentioned in the contract.
In effect, Pressmans definition provides operative directions for testing the degree
to which the requirements are met.
--------------------------------------------------------------------------------------Software quality assurance The IEEE definition
Software quality assurance is:
1. A planned and systematic pattern of all actions necessary to provide adequate
confidence that an item or product conforms to established technical requirements.
2. A set of activities designed to evaluate the process by which the products are
developed or manufactured. Contrast with quality control.
This definition may be characterized in the following:
Plan and implement systematically. SQA is based on planning and the
application of a variety of actions that are integrated into all the stages of the
software development process. This is done in order to substantiate the clients
confidence that the software product will meet all the technical requirements.
Refer to the software development process.
Refer to the specifications of the technical requirements.

SQA expanded definition

Software quality assurance is:
A systematic, planned set of actions necessary to provide adequate confidence that
the software development process or the maintenance process of a software system
product conforms to established functional technical requirements as well as with
the managerial requirements of keeping the schedule and operating within the
budgetary confines.
--------------------------------------------------------------------------------------Software quality assurance vs. software quality control
Two phrases are constantly repeated within the context of software quality:
Quality control and quality assurance. Are they synonymous? How are they
related? According to the IEEE software quality assurance definition (see Frame
2.5), quality control is to be contrasted with quality assurance.
These two terms represent separate and distinct concepts:
Quality control is defined as a set of activities designed to evaluate the quality
of a developed or manufactured product (IEEE, 1991); in other words, activities
whose main objective is the withholding of any product that does not qualify.
Accordingly, quality control inspection and other activities take place as the
development or manufacturing of the product is completed yet before the product
is shipped to the client.
The main objective of quality assurance is to minimize the cost of guaranteeing
quality by a variety of activities performed throughout the development and
manufacturing processes/stages. These activities prevent the causes of errors, and
detect and correct them early in the development process. As a result, quality
assurance activities substantially reduce the rate of products that do not qualify for
shipment and, at the same time, reduce the costs of guaranteeing quality in most
cases.
In sum:
(1) Quality control and quality assurance activities serve different objectives.
(2) Quality control activities are only a part of the total range of quality assurance
activities.
Distinguish and explain the differences between software quality assurance
and quality control.
Quality control is a set of activities carried out with the main objective of
withholding products from shipment if they do not qualify.
In contrast, quality assurance is meant to minimize the costs of quality by
introducing a variety of activities throughout the development and maintenance

process in order to prevent the causes of errors, detect them, and correct them in
the early stages of development. As a result, quality assurance substantially reduces
the rates of non-qualifying products.
--------------------------------------------------------------------------------------Components of SQA
Software Quality Assurance Components
The SQA Components that are used by the Software Quality Assurance System can
be classified into six different categories; each of which is necessary to guarantee
maximum quality and to ensure the compliance with the standards and procedures.
The environment in which software development and maintenance is undertaken
directly influences the SQA components. Alongside this various errors will also
affect the SQA components; therefore it is usually necessary to include all of the
components.
The six different components are broken down into the following categories

Figure 1: The SQA System Overview

1. Pre-project Components
The Pre-Project component ensures that the project has been adequately defined
ensuring that the resources available, budget and so forth have not been

misinterpreted by the client or the organisation. This improves the preliminary

steps taken prior to initiating work on the project itself, thus leading to fewer errors
later in the development phase.
There are two key concepts to this component;
1.1 Contract Review
The Contract Review begins the negotiations of a contract between the company
and the client. One of the key focuses is on the areas or points that could go wrong,
known as development risks.
The contract ensures that commitments have been documented including an
agreement upon the functional specification, budget and the schedule.
The contract review activities must include a detailed examination of the project
proposal draft and the contract draft, each of which have different objectives, to
ensure that the commitments have been properly and clearly defined. A checklist is
often used by reviewers to make this stage easier and it is expected that the review
stage will occur more than once.
The outcome from this stage is a documented agreement between the company and
client stating the projects requirements, budgets and so on ensuring that no new
changes have been added to the contract draft.
1.2 Development and Quality Plans
The development and Quality Plans stage occurs once an agreement has been made
and a software development contract has been signed. The time between a
proposal, the contract review and the signing of the contract could be prolonged
and during this time changes may occur. Consequently proposal materials need to
be revised and new plans are required; a development plan and a quality plan.
The development plan focuses on eleven specific elements, some of which are; the
products of the project i.e. software products and design documents specifying
deliverables. Project interfaces detailing what, if any, interfaces the product will
have with existing software packages. The methodology clearly states which
methodology should be used at each phase of the project.

The quality plan has four main elements; however, how many of these are used is
dependent upon the project. Quality Goals refers to the goals of the product, it is
always better to have more goals as it is easier to see how well the system
performs. Planned review activities are a listing of all the planned reviews such as
Design Reviews (DR) and Code Inspections. Planned software tests details all the
software tests that are to be performed with details such as the unit, integration or
complete system to be tested. Finally, planned acceptance tests for externally
developed software; this is only necessary for products not developed in-house.
Approval of the two plans is necessary and is approved or rejected according to the
procedures within the organisation.
2. Project Lifecycle Activities and Assessment
This component has two main stages; 1. The Development Lifecycle stage which
aims to detect design and programming errors. 2. The Operation-Maintenance
stage focuses on maintenance tasks that improve functionality.
When developing the product there are a number of activities that take place, these
are reviews, such as formal design reviews and peer reviews, expert opinions,
software testing, software maintenance and finally, the assurance of the quality of
external participants work which ensures that any efforts by external members
meet the quality and standards of the organisation.
The reviews occur during the design phase of the development process and should
be conducted at any milestone. The formal Design Review (DR) is a very
important document as the project cannot continue until a formal approval by the
DR committee has been received. The document itself includes a list of action
items (corrections) that are required. The peer review, guided by checklists,
standards and past problems, is a document that reviews short documents or
sections to attempt to detect design and programming faults documenting a list of
its findings.
Expert Opinions is the use of an external member to review in-house work; it can
reinforce the internal (in-house) quality assurance activities. Although not all
organisations may use this approach it is useful for small organisations which may
not have sufficient professional capabilities in-house or for a replacement to the

regular in-house professional for whatever reasons. The outcome from this is often
a document similar to a formal design review.
Software Testing is a formal process carried out by a specialized team in which a
software unit, several integrated software units or an entire software package are
examined by running the programs on a computer. All associated tests are
performed according to the approved test procedures on approved test cases
D.Galin (2003)
In general, Software Testing is aimed at reviewing the running and functionality of
the software in which the testing is based on a prepared list of test cases.
Software Maintenance specifies three categories in which maintenance for a
system can fall into. The first is corrective maintenance in which the correction of
failed software, for whatever reason, occurs. The second is adaptive maintenance
in which maintenance occurs to the system it needs to be adapted; however the
basic functionality of the system is left untouched. Finally, the third is functionality
improvement where the system is modified to add improvements, this could
significantly change the system compared to the other two points.
3. Infrastructure components for error prevention and Improvement
The main goal of this component is to reduce the number of errors in the system
and improve productivity. This is achieved through the use of a number of subcomponents.

1. Procedures and Work Instructions

A procedure describes how the process, a specific development activity, is
performed whilst a work instruction is more specific and provides detailed
directions for the use of methods. Having a detailed guideline ensures that all
members know how to achieve some goal.
Work instructions and procedures contribute to the correct and effective
performance of established technologies and routines
http://kur2003.if.itb.ac.id/file/SW%20Quality%20Components.pdf

2. Supporting Quality Devices

Quality Devices are used to maximise efficiency and quality. A quality device
could be a template or a checklist which saves time as the document will be
complete and will not have to be developed, from scratch each time.
Using Quality Devices offers an improved form of communication and provides
standardisation within the organisation as each document will be of the same
nature.
3. Staff Training, Instruction and Certification
Staff training is a vital element to avoiding errors throughout the development of
the system. Having well trained professional staff enables efficient and high quality
performance from each member.
New staff have to be trained in respect to the standards and procedures of the
organisation and existing staff should be re-trained when assignments change.

4. Preventive and Corrective Actions

Studying existing data for similar faults and failures can enable future ones to be
solved easily either by correcting it once it has occurred or by preventing it from
happening.
The data should be recorded, or found, in design review reports, software test
reports or customer complaints. It should be managed effectively so that if it occurs
in the future the solution, if one was found, can be easily accessible.
5. Configuration Management
This deals with the dangers of version releases. With intense work focusing on new
versions and new software releases dangers arise when different members carry out
the same tasks. This can lead to misidentification or the versions or releases or loss
of records or development activities.

Configuration management introduces procedures that are used to control the

change process and monitor it.
6. Documentation Control
Document Control is necessary to ensure long term availability of controlled
documents. Controlled documents are maintained and updated. They are formally
approved and contain evidence of the systems performance.
4. Software Quality Management
Quality management not only focuses on product quality but also the means in
which it can be achieved.
Some of the components used to support the managerial control of software
development projects are the Project Progress Control, Software Quality Metrics
and Software Quality costs.
The aim of Project Progress Control is simply to monitor the progress of the
project to ensure that it does not deviate from its initial plans. It focuses
particularly on monitoring resource usages, schedules (whether they are being
met), risk management activities and the budget.
A Software Quality Metric is a measurement that is used to evaluate software
quality in a system. The software is the input, and the output is a numeric value
which represents the degree to which the software possesses a given quality
attribute. The measures can apply to functional quality, productivity and the
organization side of the project.
The Software Quality Costs are the costs that incur throughout the entire project;
the total cost is calculated from the costs of control and the costs of failure. The
organisations main interest is the sum of the total costs which will determine a
success or failure.
5. SQA Standards, System Certification, and Assessment Components
This component focuses on using external tools to achieve the, in-house, goals of
software quality assurance. There are three main objectives, D.Galin (2003):
1. Utilization of international professional knowledge

2. Improvement of coordination with other organizations quality systems

3. Objective professional evaluation and measurement of the achievements of
the organizations quality systems
The standards available to achieve the above objectives can be classified into two
sub-classes
1. Quality Management Standards what is required
2. Project Process Standards how it is done
The outcome of this component is simply to use external tools, i.e. staff, to achieve
the desired in-house software quality assurance complying with the standards of
the organization.
6. Organizing for SQA The Human Components
SQA cannot be directly applied to an organization; instead an organizational base
is required. The organizational base is collectively made up of the SQA Unit, SQA
trustees, committees and forums along with the continuous support of the
management.
The SQA Unit focuses purely on Software Quality Assurance, thus ensuring that all
standards, procedures and components are efficiently and correctly in use. This is,
in part, done through the audits and quality programs that the SQA Unit is required
to produce.
Management must ensure that all staff are aware of the quality policy, they are
required to define sufficient resources and accurately assign an adequate number of
staff to the tasks.
The SQA organizational base has three main objects
1. To aid the development and implementation of the SQA system
2. To detect and prevent deviations from organizational standards and
procedures
3. To continuously suggest improvements that will benefit the SQA
components

Difference between Quality and Quality Assurance and Quality Engineering

Diff b/w QA And QE -https://www.linkedin.com/pulse/moving-from-qualityassurance-engineering-brief-history-nitin-mehra
Quality - Product oriented to User requirements.
Quality Control (QA) - Assessment after making/manufacturing the Product to
check if it complies to the requirements.
Quality Assurance (QC) - Process enhancement to prevent Product production
defects. Quality Assurance "assures" quality in the process and the product.
Quality Engineering (QE) is an infrastructure-building activity. Quality
Engineering establishes an environment to support quality in both the process and
in the product.

Difference between QA and QC

The truth is that both terms have strong interdependence; QA relies mostly on the
QC feedback and both work to deliver good quality products/services; but they are
different processes.

QA

vs.

QC

Definition from ASQ.org

Definition from ASQ.org

Assurance: The act of giving

Control: An evaluation to

confidence, the state of being

indicate needed corrective

certain or the act of making

responses; the act of guiding a

certain.

process in which variability is

QA: The planned and systematic

activities

implemented

in

quality system so that quality

requirements for a product or

attributable to a constant system

of chance causes.

service will be fulfilled.

QC: The observation techniques
Other definition
QA

is

and activities used to fulfill

prevention requirements for quality.

a failure

system that

predicts

almost

Other definition

everything about product safety,

quality standards and legality that
could possibly go wrong, and
then takes steps to control and
prevent

flawed

services

from

products
reaching

or
the

advanced stages of the supply

chain.

QC

is

system that

a failure
uses

detection
a

testing

technique to identify errors or

flaws in products and tests the
end

products

at

specified

intervals, to ensure that the

products or services meet the
requirements as defined during
the earlier process for QA.

As some process parameters

cannot

be

controlled,

QC

QA department develops all the department checksthe products

planning

processes

and or services for defects that

procedures in order to try to make happen due to these parameters,

sure

that

manufactured

the
or

products trying to achieve the overall QC

the

service objective of providing a defect-

delivered by the organization will free product or service to the

be of good quality.

customers.

QA defines the
standards/methodology

to

be

followed in order to meet the

customer requirements. *

QC ensures that

the

defined

standards are followed at every

step.*

* This is done by conducting various tests and checks. Based on

them, the QC prepares regular reports that act as an input to the QA
department which then reviews the same and decides on
the corrective and preventive actionsrequired in the processes.

In general, the QA activities are The QC activities are done

done

before the

manufactured

or

product
the

is duringthe

manufacturing

service process and once the product is

delivered (proactive approach).

manufactured.

QA is process oriented.

QC is product oriented.

QA makes sure you are doing the QC makes sure the results of

right things, the right way.

what youve done are what you
expected.

QA

tasks

are conducted

bymanagers, third party auditors,

and customers. *

QC

tasks

are executed

by experts who are directly

involved with the design, or
manufacture of a product on the
shop floor such as engineers,
inspectors, etc. *

* For this reason, one person cannot perform both activities (QA and
QC) because will result in a conflict of interest.

Examples

Examples

A QA audit would focus on the A QC review will focus on

process elements of a project.

e.g.:

Are

requirements

being

defined at the proper level of

detail?

Process

documentation

Establishing

standards

Developing

checklists

Conducting internal audits

product elements. e.g.: Are the

defined requirements the right
requirements?

Performing

inspections

Preforming testing
Example
QC detected a recurrent problem with the quality of the products.
QC provides feedback to QA personnel that there is a problem in the
process or system that is causing product quality problems. QA
determines the root cause of the problem and then brings changes to
the process to ensure that there are no quality issues in future.

---------------------------------------------------------------------------------------

Justify how six sigma is superior to quality standard

Both Six Sigma and Total Quality Management are effective tools for quality
management but a thin line of difference does exist between them. Although the
methodologies and procedures involved in both the two appear quite similar but
there are certain major differences.
Six-Sigma is a relatively newer concept than Total Quality Management but
not exactly its replacement. The basic difference between Total Quality
Management and Six Sigma is that TQM delivers superior quality manufactured
goods whereas six sigma on the other hand results in better results. Total Quality
management refers to continuous effort by employees to ensure high quality
products. The process of Six Sigma incorporates many small changes in the
systems to ensure effective results and better customer satisfaction.
Total Quality Management involves designing and developing new systems and
processes and ensures effective coordination among various departments. New
Processes are developed based on various customer feedbacks and researches.
The main focus of Total quality management is to maintain existing quality
standards whereas Six Sigma primarily focuses on making small necessary
changes in the processes and systems to ensure high quality.
The process of Total quality management does reach to a saturation level after a
certain period of time. After reaching the saturation stage, no further improvements
in quality can be made. Six Sigma on the other hand seldom reaches the saturation
stage by initiating a next level quality process.
The process of Total quality management involves improvement in existing
policies and procedures to ensure high quality. Six-Sigma focuses on improving
quality by minimizing and eventually eliminating defects from the system. The
process of total Quality management ensures that every single member associated
with the organization is working towards the improvement of existing processes,
systems, services and work culture for long term quality products/services. Six
Sigma, on the other hand focuses on first identifying and eventually removing

various defects and obstacles which might come in the way of organizations
success. In a laymans language total quality management emphasizes on
improving the existing policies and making necessary changes in the systems to
ensure superior quality products and services. Organizations practicing Six Sigma
are focused on removing errors and defects to ensure high quality products.
Total Quality management is a less complicated process than Six Sigma. SixSigma involves specially trained individuals whereas total quality management
does not require extensive training. The process of Six Sigma creates special levels
for employees who are only eligible to implement the same. Employees trained for
Six Sigma are often certified as Green Belts or Black Belts depending on their
level of proficiency. Six-Sigma requires participation of only certified
professionals whereas total quality management can be referred to a part time
activity which does not require any special training. Six-Sigma can be
implemented by dedicated and well trained professionals.
Six-Sigma is known to deliver better and effective results as compared to total
quality management. The process of Six Sigma is based on customer feedbacks
and is more accurate and result oriented. Customer feedbacks play an important
role in Six Sigma. Experts predict that six sigma will outshine total quality
management in due course of time.
---------------------------------------------------------------------------------------

Difference between CMM, CMMI and PCMM

CMM
CMMI
Capability Maturity
Capability Maturity
Model
Model Integration
CMM describes about the CMMI describes both
software engineering
software and system
alone
engineering.

PCMM
People Capability
Maturity Model
It is a maturity framework
that focuses on
continuously improving
the management and
development of the
human assets of an

organization.
CMM & PCMM -> http://www.chrmglobal.com/Qanda/15/1/What-do-CMMand-PCMM-mean-.html
--------------------------------------------------------------------------------------DIFFERENCE BETWEEN THREE SIGMA AND SIX SIGMA

Sigma Levels
The science of statistics as they relate to quality control came from the mind of
Walter Shewhart who determined that error rates or exceptions are empirical
qualities based on standard deviation.
Sigma levels 1 through 6 designate the maximum number of defects per million in
a process or system and relate to the overall percentage of accuracy according to
the following specifications.

1 Sigma: 690K errors per million (31% accuracy).

2 Sigma: 308K errors per million (69% accuracy).
3 Sigma: 66.8K errors per million (93.3% accuracy).
4 Sigma: 6.2K errors per million (99.4% accuracy).
5 Sigma: 233 errors per million (99.97% accuracy).
6 Sigma: 3.4 errors per million (99.999997% accuracy).

Right away you can see that one way to differentiate 3 Sigma vs.
6 Sigma is the defect rate, but that is not the full meaning of the difference between
the terms. Take a look at Six Sigma and then see how it compares to Three Sigma
in common usage.

6 Sigma
Although one of the key concepts of Six Sigma is to strive for near perfection, the
practical goal of Six Sigma programs is to continually improve the rate of accuracy
as it approaches that nearly perfect goal. As the quality control of an enterprise
progresses, it traverses lower sigma levels that have less accuracy. Six Sigma,
however, is not just a measuring stick for performance, nor is it a technique for
improving performance: Six Sigma as we know it addresses corporate culture and
seeks to change it into an environment that is at every point optimized for quality.

Six Sigma, therefore, is an attempt to unify all employees of a corporation into a

unified team that works together to produce high quality goods and services.

3 Sigma
One of the major differences between 3 Sigma vs. 6 Sigma is the tolerance for
defects. Walter Shewhart considered Three Sigma as the demarcation point that
divides the ordinary from the extraordinary; the predictable from the unpredictable.
Most companies would consider a Three Sigma performance as unacceptable.
Although the term can apply to defect rates, Three Sigma is more generally used to
refer to the predictability of outcomes and the source of deviation from average
values. It also looks at how causes can be assigned to either known causes, or
unknown causes. In cases where too much error is not assignable, Three Sigma
assumes that the system itself is to blame for errors and calls for it to be thoroughly
redesigned.

3 Sigma vs. 6 Sigma

Although on the surface, the 3 Sigma vs. 6 Sigma comparison involves merely
different levels of tolerance for defects, they are used quite differently in practice.
Six Sigma deals with desired outcomes and the amount of defects permitted. Three
Sigma determines the nature of influential factors that affect processes and their
outcomes (products and services) and whether or not those factors are predictable.
Summarizing 3 Sigma vs. 6 Sigma in a different way, Three Sigma is used to
determine the state of a process while Six Sigma constitutes a methodology to set
and achieve targets for quality outcomes.

DIFFERENCES
The Numerical Difference
The goal of a three sigma quality program is a deviation from an engineering
specification of no more than one-sixth part 1.66 percent, plus or minus. The
goal of a Six Sigma quality program is a deviation of no more than one-twelfth
part, or 0.83 percent, plus or minus. This represents a reduction in errors at every
stage of the production process. While both three sigma and Six Sigma are used as
measures of quality in a manufacturing environment, the difference is great. Three

sigma represents a deviation from the engineering standard of 2,700 parts per
million, versus two parts per billion for Six Sigma.
Production and Managment
Three sigma quality programs stress the manufacturing process. The three sigma
concept doesnt embrace processes far from the factory floor. Six Sigma is more
inclusive, extending to every essential business process. The premise posed in "The
Six Sigma Handbook" includes the customer as part of the quality process. The
customer's desire for the right price, good service, the best financing terms, the
right style and sufficient availability are elements that depend not only on
production, but also on management.
Each Step in a Process
In Six Sigma, each step in production is a process. Each must be completed
properly and efficiently. For each process on the production line, the customer is
the workers involved in the next step on the line. To satisfy the requirements of
three sigma, the deviation allowed at each step in the production process is twice
that allowed in Six Sigma. This means that each worker in the assembly process is
part of the quality team that helps in identifying a source of production errors.
Monitoring Progress
While you cannot inspect quality into a product, inspection at each stage of
production prevents product that falls outside the Six Sigma parameters from
reaching the customer. Inspection, whether on the production floor or in the office,
also provides the needed feedback to adapt the process to eliminate errors. Six
Sigma programs help eliminate customer friction unrelated to the physical quality
of the product through greater efficiency in distribution, product availability and
customer service.
--------------------------------------------------------------------------------------Steps to Develop and Implement a Software Quality Assurance Plan

The software quality assurance (SQA) plan is an outline of quality measures to

ensure quality levels within a software development effort. The plan is used as a

baseline to compare the actual levels of quality during development with the
planned levels of quality. If the levels of quality are not within the planned quality
levels, management will respond appropriately as documented within the plan.
The plan provides the framework and guidelines for development of
understandable and maintainable code. These ingredients help ensure the quality
sought in a software project. An SQA plan also provides the procedures for
ensuring that quality software will be produced or maintained in-house or under
contract. These procedures affect planning, designing, writing, testing,
documenting, storing, and maintaining computer software. It should be organized
in this way because the plan ensures the quality of the software rather than
describing specific procedures for developing and maintaining it.
Step 1: Document the Plan
The software quality assurance plan should include the following sections:
* Purpose SectionThis section delineates the specific purpose and scope of the
particular SQA plan. It should list the names of the software items covered by the
SQA plan and the intended use of the software. It states the portion of the software
life cycle covered by the SQA plan for each software item specified.
* Reference Document SectionThis section provides a complete list of
documents referenced elsewhere in the text of the SQA plan.
* Management SectionThis section describes the project's organizational
structure, tasks, and responsibilities.
* Documentation SectionThis section identifies the documentation governing
the development, verification and validation, use, and maintenance of the software.
It also states how the documents are to be checked for adequacy. This includes the
criteria and the identification of the review or audit by which the adequacy of each
document will be confirmed.
* Standards, Practices, Conventions, and Metrics SectionThis section identifies
the standards, practices, conventions, and metrics to be applied, and also states
how compliance with these items is to be monitored and assured.
* Reviews and Inspections SectionThis section defines the technical and
managerial reviews, walkthroughs, and inspections to be conducted. It also states
how the reviews, walkthroughs, and inspections are to be accomplished, including
follow-up activities and approvals.
* Software Configuration Management SectionThis section is addressed in
detail in the project's software configuration management plan.
* Problem Reporting and Corrective Action SectionThis section is addressed in

detail in the project's software configuration management plan.

* Tools, Techniques, and Methodologies SectionThis section identifies the
special software tools, techniques, and methodologies that support SQA, states
their purposes, and describes their use.
* Code Control SectionThis section defines the methods and facilities used to
maintain, store, secure, and document the controlled versions of the identified
software during all phases of development. This may be implemented in
conjunction with a computer program library or may be provided as a part of the
software configuration management plan.
* Media Control SectionThis section describes the methods and facilities to be
used to identify the media for each computer product and the documentation
required to store the media, including the copy and restore process, and protects the
computer program physical media from unauthorized access or inadvertent damage
or degradation during all phases of development. This may be provided by the
software configuration management plan.
* Supplier Control SectionThis section states the provisions for ensuring that
software provided by suppliers meets established requirements. In addition, it
should specify the methods that will be used to ensure that the software supplier
receives adequate and complete requirements. For previously developed software,
this section describes the methods to be used to ensure the suitability of the product
for use with the software items covered by the SQA plan. For software to be
developed, the supplier will be required to prepare and implement an SQA plan in
accordance with this standard. This section will also state the methods to be
employed to ensure that the developers comply with the requirements of this
standard.
* Records Collection, Maintenance, and Retention SectionThis section
identifies the SQA documentation to be retained. It states the methods and facilities
to assemble, safeguard, and maintain this documentation, and will designate the
retention period. The implementation of the SQA plan involves the necessary
approvals for the plan as well as development of a plan for execution. The
subsequent evaluation of the SQA plan will be performed as a result of its
execution.
* Testing MethodologyThis section defines the testing approach, techniques, and
automated tools that will be used.
Step 2: Obtain Management Acceptance
Management participation is necessary for the successful implementation of an
SQA plan. Management is responsible for both ensuring the quality of a software
project and for providing the resources needed for software development.

The level of management commitment required for implementing an SQA plan

depends on the scope of the project. If a project spans organizational boundaries,
approval should be obtained from all affected departments. Once approval has been
obtained, the SQA plan is placed under configuration control.
In the management approval process, management relinquishes tight control over
software quality to the SQA plan administrator in exchange for improved software
quality. Software quality is often left to software developers. Quality is desirable,
but management may express concern as to the cost of a formal SQA plan. Staff
should be aware that management views the program as a means of ensuring
software quality, and not as an end in itself
To address management concerns, software life-cycle costs should be formally
estimated for projects implemented both with and without a formal SQA plan. In
general, implementing a formal SQA plan makes economic and management
sense.
Step 3: Obtain Development Acceptance
Because the software development and maintenance personnel are the primary
users of an SQA plan, their approval and cooperation in implementing the plan are
essential. The software project team members must adhere to the project SQA plan;
everyone must accept it and follow it.
No SQA plan is successfully implemented without the involvement of the software
team members and their managers in the development of the plan. Because project
teams generally have only a few members, all team members should actively
participate in writing the SQA plan. When projects become much larger (i.e.,
encompassing entire divisions or departments), representatives of project
subgroups should provide input. Constant feedback from representatives to team
members helps gain acceptance of the plan.
Step 4: Plan for Implementation of the SQA Plan
The process of planning, formulating, and drafting an SQA plan requires staff and
word-processing resources. The individual responsible for implementing an SQA
plan must have access to these resources. In addition, the commitment of resources
requires management approval and, consequently, management support. To
facilitate resource allocation, management should be made aware of any project
risks that may impede the implementation process (e.g., limited availability of staff

or equipment). A schedule for drafting, reviewing, and approving the SQA plan
should be developed.
Step 5: Execute the SQA Plan
The actual process of executing an SQA plan by the software development and
maintenance team involves determining necessary audit points for monitoring it.
The auditing function must be scheduled during the implementation phase of the
software product so that improper monitoring of the software project will not hurt
the SQA plan. Audit points should occur either periodically during development or
at specific project milestones (e.g., at major reviews or when part of the project is
delivered).
---------------------------------------------------------------------------------------

COMPARE VARIOUS QUALITY STANDARDS USED IN IT INDUSTRY

WITH THEIR PROS AND CONS

UNIT 2
PRODUCT METRICS AND PROCESS METRICS
Classification of software quality metrics
Software quality metrics can fall into a number of categories. Here we use a twolevel system.
The first classification category distinguishes between life cycle and other phases
of the software system:
Process metrics, related to the software development process
Product metrics, related to software maintenance

The second classification category refers to the subjects of the measurements:

Quality
Timetable
Effectiveness (of error removal and maintenance services)
Productivity.
These items are dealt with in the respective sections.
A sizeable number of software quality metrics involve one of the two following
measures for system size:
KLOC this classic metric measures the size of software by thousands of code
lines. As the number of code lines required for programming a given task differs
substantially with each programming tool, this measure is
specific to the programming language or development tool used.Application of
metrics that include KLOC is limited to software systems developed using the
same programming language or development tool.
Function points a measure of the development resources (human resources)
required to develop a program, based on the functionality specified for the software
system. Customer satisfaction metrics are excluded from our presentation; the
reader can find wide coverage of this topic in the marketing literature.
PROCESS METRICS
Software development process metrics can fall into one of the following
categories:
Software process quality metrics
Software process timetable metrics
Error removal effectiveness metrics
Software process productivity metrics.
Software process quality metrics
Software process quality metrics may be classified into two classes:
Error density metrics
Error severity metrics.
Another group of indirect metrics that relates to software process quality is the
McCabes cyclomatic complexity metrics.A discussion of the above three classes
follows.
Error density metrics
This section describes six different types of metrics. Calculation of error density
metrics involves two measures: (1) software volume, and (2) errors counted.

Software volume measures. Some density metrics use the number of lines of code
while others apply function points. For a comparison of these measures, see
Section 21.2.
Errors counted measures. Some relate to the number of errors and others to the
weighted number of errors. Weighted measures that ascertain the severity of the
errors are considered to provide more accurate evaluation of the
error situation. A common method applied to arrive at this measure is classification
of the detected errors into severity classes, followed by weighting each class. The
weighted error measure is computed by summing up multiples of the number of
errors found in each severity class by the adequate relative severity weight.
Department of Defense standard MIL-STD-498, presented in Table 8.1, describes a
commonly used five-level severity classification system. It should be noted that
application of weighted measures can lead to decisions
different than those arrived at with simple (unweighted) metrics: weighted
measures are assumed to be better indicators of adverse situations.
Example 1. This example demonstrates the calculation of the number of code
errors (NCE) and the weighted number of code errors (WCE). A software
development department applies two alternative measures, NCE and
WCE, to the code errors detected in its software development projects. Three
classes of error severity and their relative weights are also defined: