UNIT -IV

Software Quality Planning & Control

Having set the goals for effort and schedule, the goal for the third key dimension of a project—
quality—needs to be defined. However, unlike schedule and effort, quantified quality goal setting
for a project and then planning to meet it is much harder. For effort and schedule goals, we can
easily check if a detailed plan meets these goals (e.g., by seeing if the last task ends before the target
date and if the sum total of effort of all tasks is less than the overall effort goal). For quality, even if
we set the goal in terms of expected delivered defect density, it is not easy to plan for achieving this
goal or for checking if a plan can meet these goals. Hence, often, quality goals are specified in
terms of acceptance criteria— the delivered software should finally work for all the situations and
test cases in the acceptance criteria. Further, there may even be an acceptance criterion on the
number of defects that can be found during the acceptance testing. For example, no more than n
defects are uncovered by acceptance testing.

The quality plan is the set of quality-related activities that a project plans to do to achieve the
quality goal. To plan for quality, let us first understand the defect injection and removal cycle, as it
is defects that determine the quality of the final delivered software.

Software development is a highly people-oriented activity and hence it is error-prone. In a software

project, we start with no defects (there is no software to contain defects). Defects are injected into
the software being built during the different phases in the project. That is, during the transformation
from user needs to software to satisfy those needs, defects are injected in the transformation
activities undertaken. These injection stages are primarily the requirements specification, the high-
level design, the detailed design, and coding. To ensure that high-quality software is delivered, these
defects are removed through the quality control (QC) activities. The QC activities for defect
removal include requirements reviews, design reviews, code reviews, unit testing, integration
testing, system testing, acceptance testing, etc. Figure 4.2 shows the process of defect injection and
removal.

Figure 4.2: Defect injection and removal cycle

As the final goal is to deliver software with low defect density, ensuring quality revolves around
two main themes: reduce the defects being injected, and increase the defects being removed. The
first is often done through standards, methodologies, following of good processes, etc., which help
reduce the chances of errors by the project personnel. (There are specific techniques for defect
prevention also.) The quality plan therefore focuses mostly on planning suitable quality control
tasks for removing defects.

Reviews and testing are two most common QC activities utilized in a project. Whereas reviews are
structured, human-oriented processes, testing is the process of executing software (or parts of it) in
an attempt to identify defects. The most common approach for quality planning in a project is to
specify the QC activities to be performed in the project, and have suitable guidelines for performing
each of the QC tasks, such that the chances of meeting the quality goals are high. During project
execution, these activities are carried out in accordance with the defined procedures.

When this approach is used for ensuring quality, making quantitative claims can be quite hard. For
quantitative assessment of the quality processes, metrics-based analysis is necessary. That, however,
is an advanced topic, beyond the scope of this book (and indeed many organizations). Hence, for
ensuring quality, the reliance is primarily on applying suitable QC techniques at the right places in
the process, and using experience to ensure that sufficient QC tasks are done in the project.

Hence, the quality plan for the project is largely a specification of which QC task is to be done and
when, and what process and guidelines are to be used for performing the QC task. The choice
depends on the nature and goals and constraints of the project. Typically, the QC tasks will be
schedulable tasks in the detailed schedule of the project. For example, it will specify what
documents will be inspected, what parts of the code will be inspected, and what levels of testing
will be performed. The plan can be considerably enhanced if some expectations of defect levels that
are expected to be found for the different quality control tasks are also mentioned—these can then
aid the monitoring of quality as the project proceeds.

SOFTWARE QUALITY CONTROL Fundamentals

Software Quality Control (SQC) is a set of activities for ensuring quality in software products.
It includes the following activities:
 Reviews
 Requirement Review
 Design Review
 Code Review
 Deployment Plan Review
 Test Plan Review
 Test Cases Review
 Testing
 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing
Software Quality Control is limited to the Review/Testing phases of the Software Development Life
Cycle and the goal is to ensure that the products meet specifications/requirements.
The process of Software Quality Control (SQC) is governed by Software Quality Assurance (SQA).
While SQA is oriented towards prevention, SQC is oriented towards detection. Read Differences
between Software Quality Assurance and Software Quality Control.
Some people assume that QC means just Testing and fail to consider Reviews; this should be
discouraged.
Differences between Software Quality Assurance (SQA) and Software Quality Control (SQC):
Many people still use the term Quality Assurance (QA) and Quality Control (QC) interchangeably
but this should be discouraged.
Criteria Software Quality Assurance (SQA) Software Quality Control (SQC)
SQA is a set of activities for ensuring quality in SQC is a set of activities for
software engineering processes (that ultimately ensuring quality in software
Definition result in quality in software products). The products. The activities focus on
activities establish and evaluate the processes identifying defects in the actual
that produce products. products produced.
Focus Process focused Product focused
Orientation Prevention oriented Detection oriented
Breadth Organization wide Product/project specific
 Relates to all products that will ever be created
Scope Relates to specific product
by a process
 Process Definition and Implementation
 Reviews
 Audits
Activities  Testing
 Training

⇒ Software Quality Assurance Activities

SQA is the process of evaluating the quality of a product and enforcing adherence to software
product standards and procedures. It is an umbrella activity that ensures conformance to
standards and procedures throughout the SDLC of a software product. There are a large
number of tasks involved in SQA activities.These include:
i)Formulating a quality management plan
ii.Applying software engineering techniques
iii.Conducting formal technical reviews
iv.Applying a multi-tiered testing strategy
v.Enforcing process adherence
vi.Controlling change
vii.Measuring impact of change
viii.Performing SQA audits
ix.Keeping records and reporting

i)Formulating a Quality Management Plan

One of the tasks of SQA is the formulation of a quality management plan. The quality
management plan identifies the quality aspects of the software product to be developed. It
helps in planning checkpoints for work products and the development process. It also tracks
changes made to the development process based on the results of the checks. The quality
management plan is tracked as a live plan throughout the SDLC.
ii.Applying Software Engineering
Application of software engineering techniques helps the software designer to achieve high
quality specification. The designer gathers information using techniques such as interviews and
FAST. Using the information gathered, the designer prepares project estimation with the help of
techniques such as WBS, SLOC estimation, or FP estimation .
iii)Conducting Formal Technical Reviews
Formal technical review (FTR) in conducted to assess the quality and design of the prototype. It
is a meeting with the technical staff to discuss the quality requirements of a software product
and its design quality. FTRs help in detecting
errors at an early phase of development. This prevents errors from percolating down to the
latter phases and resulting in rework.
iv. Applying a Multi-tiered Testing Strategy
Software testing is a critical task of SQA activity, which aims at error detection. Unit testing is
the first level of testing. The subsequence levels of testing are integration testing and system
level testing. There are various testing strategies followed by organization. At times,
developers perform unit testing and integration testing with independence testing support.
There are also occasions where testers perform functional testing and system level testing with
developer support. Sometimes beta testing with selected clients is also conducted to test the
product before it is finally released.
v.Enforcing Process Adherence
This task of SQA emphasizes the need for process adherence during product development. In
addition, the development process should also adhere to procedures defined for product
development. Therefore, this is a combination of two tasks, product evaluation and process
monitoring.
vi)Product Evaluation
Product evaluation ensures that the standards laid down for a project are followed. During
product evaluation, the compliance of the software product to the existing standards is verified.
Initially, SQA activities are conducted to monitor the standards and procedures of the project.
Product evaluation ensures that the software product reflects the requirements identified in the
project management plan.
Vii. Process Monitoring
Process monitoring ensures that appropriate steps to follow the product development
procedures are carried out. SQA monitors processes by comparing the actual steps carried out
with the steps in the documented procedures. Product evaluation and process monitoring
ensure that the development and control processes described in the project management plan
are correctly carried out. These tasks ensure that the project-re1ated procedures and standards
are followed. They also ensure that products and processes conform to standards and
procedures. Audits ensure that product evaluation and process monitoring are performed.
Viii. Controlling Change
This task combines human procedures and automated tools to provide a mechanism for change
control. The change control mechanism ensures software quality by formalizing requests for
change, evaluating the nature of change, and controlling the impact of change. Change control
mechanism is implemented during the development and maintenance stages.

ix)Measuring Impact of Change

Change is inevitable in the SDLC. However, the change needs to be measured and monitored.
Changes in the product or process are measured using software quality metrics. Software
qua1ity metrics helps in estimating the cost and resource requirements of a project. To control
software quality; it is essential to measure quality and then compare it with established
standards. Software qua1ity metrics are used to evaluate the effectiveness of techniques and
tools, the productivity of development activities and the qua1ity of products. Metrics enables
mangers and developers to monitor the activities and proposed changes throughout the SDLC
and initiate corrective actions.
x)Performing SQA Audits
SQA audits scrutinize the software development process by comparing it to established
processes. This ensures that proper control is maintained over the documents required during
SDLC. Audits also ensure that the status of an activity performed by the developer is reflected
in the status report of the developer.
xi)Keeping Records and Reporting
Keeping records and reporting ensure the collection and circulation of information relevant to
SQA. The results of reviews, audits, change control, testing, and other SQA activities are
reported and compiled for future reference.

⇒ Software Review
Software review is an effective way of filtering errors in a software product. Typically, an error
found after the product release costs 50 times as much to correct as one detected during the
design phase. This means the cost of fixing a defect rises dramatically if it is found late in the
development life cycle of the product. Therefore, you need to filter errors as early as
possible.Software review is used as a filter at various points of software development.Reviews
conducted at each of these phases, analysis, design, coding, and testingreveal areas of
improvement in the product.Reviews also indicate those areas that do not need any
improvement. You can use software reviews to achieve consistency and uniformity across
products. Reviews also make the task of product creation more manageable. Some of the most
common software review techniques, practiced across software organizations include: a)
Inspection b) Walkthrough c) Formal technical reviews
a) Inspections
Inspections improve the reliability, availability, and maintainability of a software product.
Anything readable that is produced during software development can be inspected. The
readable material can be requirements specifications, design documents and models, test
plans, system documentation, and user aids. Group inspections enable team members to
exchange knowledge and ideas during an inspection session. Inspections can be combined with
structured, systematic testing to provide a powerful tool for creating defect-free programs. The
inspection activity follows a specified process and the participants play well-defined roles. An
inspection team consists of three to eight members who play the roles of moderator, author,
reader, recorder, and inspector. Moderator leads the inspection, schedules meetings, controls
meetings, reports inspection results, and follows up on rework issues. Author creates or
maintains the work product being inspected. Reader describes the sections of the work product
to the team as they proceed through inspection. Recorder classifies and records defects and
issues raised during the inspection. The moderator might perform this role in a small inspection
team. Inspector finds errors in the product. All participants play the role of inspectors. However,
good inspectors are those who have created the specification for the work product being
inspected. For example, the designer can act as an inspector during code inspection while a
quality assurance representative can act as standard enforcer. It also helps to have a client
representative participate in requirements specification inspections.
b) Walkthroughs
The term walkthrough refers to a group activity in which the developer of the product guides
the progress of the review. Walkthroughs are less rigorous than either formal inspections or
peer reviews in which the developer plays a more passive role. Normally walkthroughs turn into
a presentation by the author. The focus of finding errors is diluted. Such misadventures make
walkthroughs usually less successful at detecting bugs than the more formal review
methods.Two useful walkthrough approaches adopted worldwide are group reviews with
individual preparation and individual peer desk-checks. Group reviews are not very rigorous like
inspections. The group reviews involve many of the same activities and roles, such as
individual preparation and the use of a moderator and a recorder. Usually the overview meeting
and the follow-up steps are skipped and checklists are used sparingly. At the end, the readers
paraphrase their interpretation of what a program is doing.Individual peer desk-checks are
quite cost-effective. Only one person besides the author examines the material. This approach
can be more effective if there are individuals who are extremely good at finding defects on
their own.
Tip:If someone consistently finds most of the group-identified defects during the individual
preparation step, such a person is fit to perform individual peer desk-checks.
c) Formal Technical Reviews
One of the most common, yet important, software quality assurance activity performed is FTR.
This activity is performed to check errors in logic,function, or implementation for any
representation of the software.Using FTR, you can verify whether or not the software product
adheres to the defined standards. FTR is also conducted to check for consistency in thesoftware
product and audit the manageability of the software product. It includes activities such as
walkthrough and inspection.FTR focuses on specific parts of the software product, such as the
requirements components, detailed design module, and the source code listing for a
module.FTR also concentrates on the entire product. The participants in FTR are the developer,
the project leader, and all the reviewers.At the end of the review meeting, the issues recorded
are formalized into review issues list.

Identifying SQA Issues

Software Quality Assurance is a good practice that every large scale business should employ. IT
related businesses have never hesitated to use SQA to ensure that the application they will release
for their users or sell to their customers will live up to their expectations.

Identifying SQA Issues

Software Quality Assurance is a good practice that every large scale business should employ. IT
related businesses have never hesitated to use SQA to ensure that the application they will release
for their users or sell to their customers will live up to their expectations.
On the other hand, there are companies that has opted to forgo with the usage of SQA and relied on
application testers just to make sure the application will never have internal errors. The SDLC on
the other hand, will ensure the development of the application will work as planned.
Like other development plans, there are issues why developers and companies do not use SQA.

SQA Cost
This is the main reason why small scale companies hesitated to use SQA as part of their
development plan. SQA is a different entity that works separately from the development team.
Hiring another set of developers will mean another set of people to pay for. Developing software
takes months to take and if you are a small-scaled company you will definitely have to cut costs.
This problem cannot just be answered with more money and resources. Unfortunately, the
developers have to face the fact that SQA cannot just be implemented when everyone has to cut
costs. Only the SDLC and the testing team could compensate what the SQA is lacking.
SQA Complexity
Years ago, an application could be easily built by a single developer and let the whole world enjoy
them. Today, a highly efficient application would take years for a single developer to develop. By
the time it could be integrated and implemented, it is already outdated.
The point is, software today is very complicated that team after team will be working on developing
a single application and will take them months to develop. SQA has already been here for years and
there are models that are not as good as it was.
To answer this concern the SQA team should carefully use CASE tools. These tools could easily
summarize the functions. They ensure consistency in the evaluation of the application. That
includes documentation of every stage of development.

SQA Integration
This is one of the many concerns of the SQA models today. Because application development has
been very rapid, the standardization of the application might not be the same as it was five years
ago. The result for this is that although it has been deemed as an application developed with SQA,
the type of SQA might not live up according to what is expected.
The standardization models might ensure that the application developed ten years ago is good but it
might work today. Fortunately, this issue was answered with the development of new
standardizations. This ensured that the application was developed according to the plan and today’s
need. Today’s standards usually come with set of tools with an understanding that the application is
more complex than it was.
{mospagebreak title=Demand for Faster Development}

Demand for Faster Development

More than ever, the market for better software is increasing and everyone wants to sell and
developing something new. The software has to be developed faster more than every to be ahead of
everyone. Complimenting that speed is also the increasing complexity of the application.
It is not only the developers that have this problem of rapid software development but also the SQA
as well. They have to act really fast and decide whether or not the application is worthy to be
released for operation. If that was the case 10 years ago, everyone will have a very hard time.
Checking the application used to be manual and if that will be the case today, everyone will
definitely have a very hard time approving the application.
Today, there are tools that have great testing capabilities that could work faster like any other
manual testers. That does not include the stability the application could offer. Formal verification
could be attained using this application since it has been sanctioned by standards to work. The
development of the application for formal verification has ease up the demand

Defective Software
After months and moths of development and manual coding, it is very frustrating when your
application is disregarded and has to start all over again. SQA has that function to be a little bit
perfectionists and anything bad is disregarded. Considering the need to develop an application
rapidly, everyone has to complete the application really fast. Perfection and speed is always a
requirement for SQA and have been one of the biggest reasons why developers and small scale
companies have opted not to use SQA too much. They have limited themselves to code testing and
SDLC.
Today, that problem is addressed with the aid of libraries. There are many libraries today that can
easily be used to develop the application. The good thing about it is that they do not have to code.
The well known libraries can easily be used in an application and in no time the application could
be used and tested.
SQA has been tested on these applications and have passed so many times. Although there are no
frameworks that have been approved to bypass SQA, they would almost pass the SQA as soon as
they are tested. What’s lest is just the documentation and proper commenting in each function.
These are the issues that have been holding back the small scale companies. However, there are
now solutions to these concerns that small scale companies does not need to have second doubts in
using SQA for developing a good looking and well functioning application. Besides the monetary
consideration, every issue that surrounds the SQA has been addressed.
One of the biggest reasons why SQA could now be used by any company is automation. CASE
tools can easily gauge if the application has enough software or user requirements. Although there
are things that the SQA team should work on themselves, automation has helped application to be
the best it could be. Testing tools has also developed and it has not checked the codes only but also
on stresses. Anything that concerns around SQA has already been address so anyone could easily
use this service.
 Managing SQA Projects
 Identifying SQA Issues
 Why SQA
 SQA Costs and Benefits
 SQA Implementation
 SQA Lifecycle Standards
 SQA Planning and Requirements
 SQA Approaches and Methodologies
 SQA Analysis
 SQA Software and Tools
 SQA Project Metrics
 SQA Planning
 SQA Principles
 What is Software Quality Assurance?
 Software Quality Assurance Training
.
Zero Defect Software:

Not to be taken as meaning "bug-free," Zero-Defect Software Development (ZDSD) is a practice of

developing software that is maintained in the highest quality state throughout the entire
development process. "Defects" are aspects of the evolving software that would not be suitable for
the final product as-is. This broad definition includes bugs as well as unwanted deviations from the
desired final outcome. Defects in the development of a computer game would include unpolished
artwork, an unacceptably low frame rate on the target system, levels that aren't fun enough, or any
number of unfinished features.

The basic tenet of ZDSD is this: Maintain your product in what you believe to be a defect-free state
throughout the development process. This sounds simple, but it is a rare practice. The most common
approach is to delay major testing until the final QA phase of software development, where defects
are often discovered for the first time. Most bugs are not detected or fixed until long after their
introduction. The longer a defect remains, the harder it is to fix. On large software products, each
stage of development that a defect survives will increase the cost of fixing the defect by ten to fifty
times. A defect introduced in the design phase can cost hundreds of times more to fix in the testing
phase than it would if fixed immediately after its introduction.

By focusing on product quality throughout the development lifecycle, you will actually complete
products faster than if you didn't pay attention to quality until the end of the project. The general
rule of software quality is counter-intuitive: Improving quality actually reduces development time.
This is because you eliminate all the time spent fixing bugs and reworking code, which can account
for as much as 50% of development costs on a large project. The typical programmer writes
between eight and twenty lines of code a day; the rest of the day is usually spent on debugging.
ZDSD shortens schedules by eliminating most debugging time. Extensive studies done at NASA,
IBM, and elsewhere have shown that better QA leads to shorter schedules. An IBM study concluded
that software projects that make quality a top priority typically have the shortest schedules, the
highest productivity, and even the best sales.

Here are the ten basic rules of ZDSD:

 Test your product every day as you develop it, and fix defects as soon as you find them.
Apply the daily build and smoke test. At the end of every day you work on your project,
build the current version of your software, and test it for basic functionality. Microsoft
enforces this policy religiously, using large teams to build each project on a daily basis. A
programmer whose code breaks the build may be called in the middle of the night and must
go back to work to fix the problem immediately. For independent game developers working
on small projects, this is far easier. At the end of each day, test your program for at least ten
minutes. Make a list of anything you would consider a "defect," and resolve to fix all defects
before implementing any new features. Once you find a defect, fixing it becomes your
number one priority, and you avoid writing any new code until the defect is 100%
eliminated.
 Review your code regularly. When most people think of QA, they think of testing, but
testing is actually one of the least cost-effective strategies for finding bugs. The most
rigorous testing will typically find less than 60% of all bugs in a program, and there are
certain types of bugs that testing will rarely find. Studies conducted at many large software
organizations have concluded that code inspections are far more cost-effective than testing.
A NASA study found that code reading detected almost twice as many defects per hour as
testing. Whenever you've added a few hundred lines of new code to your project, set aside
an hour or two to read over your work and look for mistakes. One hour of code review is
equivalent to two or more hours of methodical testing. As you gain experience, keep a list of
the types of defects you find, and run down your list whenever reviewing new code. To find
even more defects, have someone else read your code as well.
 Rewrite poor-quality modules. When you discover an obscure new bug, do you ever pray,
"Oh no! Please don't let it be in that module!" We all have monster modules of legacy code
that were written when we weren't such seasoned programmers as we are today. Don't fear
them; rewrite them. Often a better approach will only become clear when an inferior
solution has already been implemented. This is certainly true for John Carmack, who coded
dozens of different approaches when writing the Quake engine before discovering one that
satisfied him. Defects will not be distributed evenly across your code. You will typically find
that 20% of your routines are responsible for 80% of your errors. In my programs it is
normally the modules that interact with the hardware or with third-party drivers, especially
DirectX, that are the most buggy. Raise your standards for those modules that seem to
produce a never-ending supply of bugs, and take the time to rewrite them from scratch. You
may find that other intermittent bugs disappear completely as a result.
 Assume full responsibility for every bug. 95% of all software defects are caused by the
programmer. Only 1% of defects are hardware errors, and the remaining 4% are caused by
the compiler, the OS, or other software. Never dismiss a potential bug; find out the exact
cause of any anomaly. When the Mars probe suffered serious software glitches during its
 mission, it was learned that the same glitch had occurred only once during testing on earth,
but the engineers dismissed it as a temporary hardware hiccup. Unless your hardware drinks
soda, it does not hiccup.
 Handle change effectively. You will always think of great new features to add after you
have started coding. Carefully consider how each change will impact your pre-existing code.
Poor integration of unanticipated features is a major cause of defects.
 Rewrite all prototyping code from scratch. Sometimes you may quickly prototype a new
feature to see if it will be viable. Often this is done by sacrificing code quality in the name of
rapid development. If you eventually decide to keep the feature, it is very tempting to simply
tack on some basic error checking to the prototyping code. Don't fall into this trap. If you
weren't writing the code originally with quality as a priority, scrap the prototyping code, and
re-implement the feature from scratch. Rapidly prototyped features that slip into the final
product are a major source of bugs because they are not subject to the same quality standards
as the rest of the code.
 Set QA objectives at the beginning of every project. Studies have shown that developers
who set reasonable QA goals will usually achieve them. Decide in advance if your product
must be fast, small, feature-rich, intuitive, scalable, etc. Then prioritize those objectives.
When designing the interface code for an upcoming game, I decided that my top three
priorities were to make it beginner-intuitive, fast, and fun, in that order. Consequently, my
game's interface isn't as graphically rich as other games, but it is easier to use and faster than
any other game of its type. Whenever you have to make a design decision, keep your
objectives in mind. If you do not set clear QA goals, then you are doomed to accept the
results of random chance.
 Don't rush debugging work. Fully 50% of all bug fixes are done incorrectly the first time,
often introducing new bugs in the process. Never experiment by simply changing "x-1" to
"x+1" to see if that will do the trick. Take the time to understand the source of the bug. Long
ago when I was a boy scout and had to put out a campfire, the Scoutmaster would sometimes
test my thoroughness by asking me to put my hand in the ashes. I learned very quickly how
to put out a fire so well that I had complete confidence it was 100% extinguished. When you
find a defect, it means your code is on fire. As long as the defect remains, any new code you
write will add fuel to that fire. Whenever you find a defect, drop everything to fix it, and
don't move on until you are 100% confident that your fix is correct. If you don't take the
time to do it right the first time, when will you find the time to do it over?
 Treat the quality of your code at the same level of importance as the quality of your
product. Rate your code on a scale of one to ten for overall quality. The first time I did this,
I rated my 30,000-line project as a four. I rewrote the worst of the code until I reached an
eight overall. It was one of the best investments of time I ever made because I was then able
to add new features at double my previous rate. The quality of your code is highly indicative
of the quality of your product. You may find as I have that your best selling products also
receive your highest ratings for code quality.
 Learn from every bug; each one represents a mistake that you made. Learn why you
made each mistake, and see if you can change something about your development practices
to eliminate it. Over the years I have adopted many simple coding practices that allow me to
avoid common bugs that used to plague me. There are many types of bugs that I now never
encounter because my coding style makes it physically impossible for me to introduce them.
Each of these rules represents a simple concept, but their combined benefits are significant. You will
achieve higher progress visibility, avoiding the situation of being "99% done" for the last 80% of
your development time. Higher quality will make your products easier to maintain and less
expensive to support. You will spend less time debugging old code and more time writing new code.
And most importantly, it actually takes less time to write high-quality code than it does to write
low-quality code, so you will save a great deal of time on overall development. If you have never
developed products with a zero-defect philosophy from day one, its adoption can reduce your
development time for new products by 30% or more while simultaneously improving product
quality.

SQA Techniques

The major technique that is used in Software Quality Assurance is the audit.  They are used to 
perform product evaluation and process monitoring.  Audits are performed routinely throughout the 
software development process.  Their job is to look 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 [2].

The purpose of using an 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 [2].

S TAT I S T I C A L Q U A L I T Y A S S U R A N C E :

Statisticalqualityassurancereflects agrowingtrendthroughout industry to becomemore quantitativeabout quality. For

software, statisticalquality assurance implies the followingsteps

1.Information about software defects is collected and categorized

2.An attempt is made to trace each defect to its underlying cause
3.UsingParetoprinciple (80%of the defects canbe traced to20% ofallpossiblecauses), isolatethe 20% (the “vital few”)
Oncethe vitalfewcauseshave beenidentified, movetocorrectthe problems that have causedthe defects.Thisrelatively
simpleconcept represents animportant steptoward thecreationof an adaptive softwareengineeringprocessinwhich
changesaremade toimprovethoseelements oftheprocessthatintroduceerrors.To ilustratethe process,assumethat a
softwaredevelopment organizationcollects information ondefects for a period of one year. Some errors are
uncovered as software is being developed. Other defects are encountered after the software has been
released to its end user.Although hundreds of errors are uncovered all can be tracked to one of the
following causes.
i-IncompleteorErroneousSpecification(IES)
ii.Misinterpretationof CustomerCommunication (MCC)
iii.IntentionalDeviation fromSpecification (IDS)
iv.Violation ofProgrammingStandards( VPS)
v.Error in Data Representation (EDR)
vi.Inconsistent Module Interface (IMI)
vii.Errorin Design Logic (EDL)

Quality Assurance Standards :

Differing views of quality standards: taking a systems view (that good management systems yield
high quality); and taking an analytical view (that good measurement frameworks yield high
quality). Examples:
Quality management:
ISO 9000-3 Quality Management and Quality Assurance Standards - Part 3: Guidelines for the
application of 9001 to the development, supply, installation and maintenance of computer software.
Quality measurement:
IEEE Std 1061-1992 Standard for Software Quality Metrics Methodology