Software process and product quality assurance in it organizations

International Journal of Computer Engineering (IJCET), ISSN 0976 – 6367(Print),
International Journal of Computer Engineering and Technology
ISSN 0976 – 6375(Online) Volume 1, Number 1, May - June (2010), © IAEME
and Technology (IJCET), ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online) Volume 1
IJCET
Number 1, May - June (2010), pp. 147-157 ©IAEME
© IAEME, http://www.iaeme.com/ijcet.html

SOFTWARE PROCESS AND PRODUCT QUALITY
ASSURANCE IN IT ORGANIZATIONS
Mr. S. Manivannan
Research Scholar
Anna University of Technology, Coimbatore
E-mail: smanivannan2003@yahoo.com

Dr. S. Balasubramanian
Research Scholar
Anna University of Technology, Coimbatore
E-mail: s_balasubramanian@rediffmail.com

ABSTRACT:
The objective of Process and Product Quality Assurance (PPQA) is to objectively
evaluate the processes and associated work-products and provide management with the
details of current strength and weakness of the process and work products, which aid for
the continual process improvement. The purpose of Process and Product Quality
Assurance is to provide staff and management with objective insight into processes and
associated work products

INTRODUCTION TO PPQA
The Process and Product Quality Assurance process area involves the following:

• Objectively evaluating performed processes, work products, and services against
the applicable process descriptions, standards, and procedures
• Identifying and documenting noncompliance issues
• Providing feedback to project staff and managers on the results of quality
assurance activities
• Ensuring that non compliance issues are addressed.
The Process and Product Quality Assurance process area supports the delivery of
high-quality products and services by providing the project staff and managers at all

147

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),

levels with appropriate visibility into, and feedback on, processes and associated work
products throughout the life of the project.
The practices in the Process and Product Quality Assurance process area ensure
that planned processes are implemented, while the practices in the Verification process
area ensure that the specified requirements are satisfied. These two process areas may on
occasion address the same work product but from different perspectives. Projects should
take advantage of the overlap in order to minimize duplication of effort while taking care
to maintain the separate perspectives.
Objectivity in process and product quality assurance evaluations is critical to the
success of the project. (See the definition of “objectively evaluate” in the glossary.)
Objectivity is achieved by both independence and the use of criteria. A combination of
methods providing evaluations against criteria by those not producing the work product is
often used. Less formal methods can be used to provide broad day-to-day coverage. More
formal methods can be used periodically to assure objectivity.
Examples of ways to perform objective evaluations include the following:
• Formal audits by organizationally separate quality assurance organizations
• Peer reviews which may be performed at various levels of formality
• In-depth review of work at the place it is performed (i.e., desk audits)
• Distributed review and comment of work products
Traditionally, a quality assurance group that is independent of the project provides
this objectivity. It may be appropriate in some organizations, however, to implement the
process and product quality assurance role without that kind of independence. For
example, in an organization with an open, quality-oriented culture, the process and
product quality assurance role may be performed, partially or completely, by peers; and
the quality assurance function may be embedded in the process. For small organizations,
this might be the most feasible approach.
If quality assurance is embedded in the process, several issues must be addressed
to ensure objectivity. Everyone performing quality assurance activities should be trained
in quality assurance. Those performing quality assurance activities for a work product
should be separate from those directly involved in developing or maintaining the work

148


product. An independent reporting channel to the appropriate level of organizational
management must be available so that noncompliance issues can be escalated as
necessary.
For example, in implementing peer reviews as an objective evaluation method:
• Members are trained and roles are assigned for people attending the peer reviews.
• A member of the peer review who did not produce this work product is assigned to
perform the role of QA.
• Checklists are available to support the QA activity.
• Defects are recorded as part of the peer review report and are tracked and escalated
outside the project when necessary.
Quality assurance should begin in the early phases of a project to establish plans,
processes, standards, and procedures that will add value to the project and satisfy the
requirements of the project and the organizational policies. Those performing quality
assurance participate in establishing the plans, processes, standards, and procedures to
ensure that they fit the project’s needs and that they will be useable for performing
quality assurance evaluations. In addition, the specific processes and associated work
products that will be evaluated during the project are designated. This designation may be
based on sampling or on objective criteria that are consistent with organizational policies
and project requirements and needs.
When noncompliance issues are identified, they are first addressed within the
project and resolved there if possible. Any noncompliance issues that cannot be resolved
within the project are escalated to an appropriate level of management for resolution.
This process area applies primarily to evaluations of the activities and work
products of a project, but it also applies to evaluations of nonproject activities and work
products such as training activities. For these activities and work products, the term
“project” should be appropriately interpreted.

149


SOFTWARE DEVELOPMENT ACTIVITIES

The activities of the software development process represented in the waterfall model.
There are several other models to represent this process.
PLANNING
The important task in creating a software product is extracting the requirements or
requirements analysis. Customers typically have an abstract idea of what they want as an
end result, but not what software should do. Incomplete, ambiguous, or even
contradictory requirements are recognized by skilled and experienced software engineers
at this point. Frequently demonstrating live code may help reduce the risk that the
requirements are incorrect.
Once the general requirements are gleaned from the client, an analysis of the
scope of the development should be determined and clearly stated. This is often called a
scope document.
Certain functionality may be out of scope of the project as a function of cost or as
a result of unclear requirements at the start of development. If the development is done
externally, this document can be considered a legal document so that if there are ever
disputes, any ambiguity of what was promised to the client can be clarified.

150


DESIGN
Domain Analysis is often the first step in attempting to design a new piece of
software, whether it be an addition to an existing software, a new application, a new
subsystem or a whole new system. Assuming that the developers (including the analysts)
are not sufficiently knowledgeable in the subject area of the new software, the first task is
to investigate the so-called "domain" of the software. The more knowledgeable they are
about the domain already, the less work required. Another objective of this work is to
make the analysts, who will later try to elicit and gather the requirements from the area
experts, speak with them in the domain's own terminology, facilitating a better
understanding of what is being said by these experts. If the analyst does not use the
proper terminology it is likely that they will not be taken seriously, thus this phase is an
important prelude to extracting and gathering the requirements. If an analyst hasn't done
the appropriate work confusion may ensue: "I know you believe you understood what
you think I said, but I am not sure you realize what you heard is not what I meant."[1]
ARCHITECTURE
The architecture of a software system or software architecture refers to an abstract
representation of that system. Architecture is concerned with making sure the software
system will meet the requirements of the product, as well as ensuring that future
requirements can be addressed. The architecture step also addresses interfaces between
the software system and other software products, as well as the underlying hardware or
the host operating system.
IMPLEMENTATION, TESTING AND DOCUMENTING
Implementation is the part of the process where software engineers actually
program the code for the project.
Software testing is an integral and important part of the software development
process. This part of the process ensures that bugs are recognized as early as possible.
Documenting the internal design of software for the purpose of future
maintenance and enhancement is done throughout development. This may also include
the authoring of an API, be it external or internal.

151


DEPLOYMENT AND MAINTENANCE
Deployment starts after the code is appropriately tested, is approved for release
and sold or otherwise distributed into a production environment.
Software Training and Support is important because a large percentage of
software projects fail because the developers fail to realize that it doesn't matter how
much time and planning a development team puts into creating software if nobody in an
organization ends up using it. People are often resistant to change and avoid venturing
into an unfamiliar area, so as a part of the deployment phase, it is very important to have
training classes for new clients of your software.
PPQA PROCEDURE
The CMMI Requirements Development process area describes three types of
requirements:-
Customer requirements, product requirements, and product-component
requirements.
SQA role to observe (audit) that documented standards, processes, and procedures
are followed.
SQA would also establish software metrics in order to measure the effectiveness
of this process.
A common metric for measuring the Requirements process would be the number
of errors (found during system testing) that could be traced to inaccurate or ambiguous
requirements (note: SQC would perform the actual system testing but SQA would collect
the metrics for monitoring and continuous improvement).
SQC role SQC takes an active role with Verification. Verification of the
requirements would involve inspection (reading) and looking for clarity and
completeness.
SQC would also verify that any documented requirement standards are followed.
Note there is a subtle difference between SQA and SQC with regard to standards,
SQC’s role is in verifying the output of this process (that is the Requirement document
itself) while SQA’s role is to make sure the process is followed correctly.

152


SQA is more of an audit role here, and may sample actual Requirements whereas
SQC is involved in the Verification of all Requirements.
The type of requirement need not be just the functional aspect (or customeruser
facing requirements) they could also include product andor component requirements.
Input Tasks Output
Project plan 1. Prepare Process and Product Quality PPQA Plan
Process assets Assurance Plan QA status Report
Organizational 2. Provide necessary process training PPQA reports
Repository 3. Objectively evaluate the processes Nonconformance
SQA Checklist 4. Objectively evaluate the work Reports
Work-Product audit products and services
Checklist 5. Prepare evaluation report
Entry Criteria 6. Initiate post evaluation activities Exit Criteria
Contract 7. Approve the work product and final Approved PPQA plan
Preliminary project product for release
plan 8. Provide QA status report to
management

Verification
Review of PPQA plan
Review of PQA report and NCR

ROLES
Abbreviation Name

PM Project manager

SM- QA Sr.Manager – Quality Assurance

QA-R Quality Assurance Representative

MI Metrics Incharge

153


1) PREPARE PROCESS AND PRODUCT QUALITY ASSURANCE
PLAN
a. Understand the scope of the project by attending Project kick-off meeting, reviewing
Preliminary project plan. (SM-QA)
b. Allocate the QA representative for the project. (SM-QA)
c. Assist the project manager in identifying life cycle model, Project defined processes
based on the following. (SM-QA)
• Type and Scope of the project
• Size of the project
• Deliverables produced by the project
• Lessons learned from the Similar completed projects
d. Facilitate the project for the following tasks completion. (QA-R)
• Allocation of resources for the project which includes hardware, software, tools and
HR
• Project directory structure creation
• Identification of Configuration controller for the project
• Review of organization repository for incorporation of best practices, lessons learned,
reusable components etc
e. Develop Process and product Quality Assurance plan for the project based on project
schedule, deliverables produced and project defined processes by mentioning the
following. (QA-R)
• Processes to be evaluated
• Work-products to be evaluated
• Criteria for evaluation
• Evaluation method
• Evaluation Schedule
• Responsibility of evaluation
f. Get process and product quality assurance plan reviewed by the PM (QA-R)
g. Get approval for the process and Product quality assurance plan from SM-QA (QA-R)]

154


2. PROVIDE NECESSARY PROCESS TRAINING.
• Identify the process training needs for the project team based on employee role /
employee’s training completion records (PM / QA-R)
• Conduct necessary process training programs. (QA-R)
• Collect feedback from the participants for process improvement / training
function improvement. (QA-R)
• Update employee’s training completion records. (QA-R)
3 OBJECTIVELY EVALUATE THE PROCESSES
• Select the work product to be evaluated based on the PPQA plan. (QA-R)
• Objectively evaluate the processes that produced the work product based on the
criteria for evaluation [Existence of work product does not provide assurance that
the specified process was followed to produce the output. Execution of process
leaves auditable quality records like review comments, MOM, checklist which
needs to be evaluated] (QA-R)
• Collect best practices and lessons learned that could improve the process and
include them in the organizational repository (QA-R)
• Identify the non-conformances found during evaluation (QA-R)
4. OBJECTIVELY EVALUATE THE WORK PRODUCTS AND
SERVICES
• Select the work product to be evaluated based on the PPQA plan (QA-R)
• Objectively evaluate the work product (including intermediate and final) to ensure
conformance to standards and requirements as set forth by the project manager
and the customer (QA-R)
• Identify the non-conformances found during evaluation [QA-R]
5. PREPARE EVALUATION REPORT

a. Prepare Non-Conformance Report based on the Non Conformities observed
during evaluation of process and work product. (QA-R)
b. Classify the NC as Major or minor based on the following guidelines (QA)

155


• Major: if the severity of the NC leads to a change in QMS or project
defined process.
• Minor: if the severity of the NC leads to document control and
typographical changes in the project documents

c. Collect evaluation findings (observations, good practices and Non-
Conformities) and prepare evaluation report. (QA-R)
d. Circulate the evaluation report to all relevant stake holders (QA-R)
e. Follow-up on for corrective action and track the NCs to closure (QA-R)

6. INITIATE POST EVALUATION ACTIVITIES.
• Consolidate the NCs and create NC database (QA-R)
• Analyze the NC data base and prepare NC trend charts (MI)
• Based on the NC analysis identify the process improvement opportunities
and include them in Process Action Plan (SM-QA)
• Consolidate the good practices captured and contribute it to organizational
repository (QA-R)
• Identify the good practices to be incorporated into QMS and include them
in process action plan (SM-QA)
• Escalate open issues to the SM-QA. (QA-R)
7. APPROVE THE WORK PRODUCT / FINAL PRODUCT FOR
RELEASE
• Ensure that all processes are complied with. (QA-R)
• In case of open NC/ finding, obtain the approval of SBU head for deviation.
• Ensure that there is specific action plan to resolve it. (SM-QA / QA-R)
• Approve the work product / final product for release (SM-QA / QA-R)
8. Provide the QA Status Report to Management
• Collect Project status details from all the projects (SM-QA/ QA-R)
• Analyze the gathered project status details and plan for mitigation / project
coaching for the risks identified in the project (SM-QA / QA-R)

156


• Prepare QA status report, by consolidating details gathered from the projects on
milestone review and audits. (SM-QA)
• Appraise the management on the QA status (SM-QA)
• Where issues are un-resolved at the SM-QA level, escalate to the Management
through the QA status report. (SM-QA)
REFERENCES
• Azuma, M.: Evaluation of Software Quality. INSTAC Research Report,
Tokio, 1991
• Kuhrau, I.: Software quality assurance (German). Study, CAP debis Curadata,
Technical University of Magdeburg, 1993
• Pohn, E.: A metric-based quality management system for software
development process. Proc. of the CONQUEST98, Nurenberg, Sept. 28/29,
1998, pp. 62-71
• Lehman, M.M.; Parry, D.E.; Ramil, J.F.: On Evidence Supporting the FEAST
Hypothesis and the Laws of Software Evolution. Proc. of the Fifth
International Software Metrics Symposium, November 20-21, 1998,
Bethesda, Maryland, pp. 84-88
• Azuma, M.: SQuaRE: The next generation of the ISO/IEC 9126 and 14598
international standards series on software product quality. Proc. of the
ESCOM 2001, April 2001, London, pp. 337-346
• Elek, A.; Jedrzejowicz, P.: Assessment and Selection of Software Products.
Proc. of the FESMA'99, Amsterdam, Netherlands, October 1999, pp. 477-486
• Hausen, H.L.: Generic Modelling of Software Quality. in: Kitchenham;
Littlewood: Measurement for Software Control and Assurance. Elsevier
Science Publisher Ltd, 1989, pp. 201-242
• Dumke, R. R.; Wille, C.: A New Metrics-Based Approach for the Evaluation
of Customer Satisfaction in the IT Area. In: Dumke/Abran: New Approaches
in Software Measurement, LNCS 2006, Springer Publ., 2001, pp. 183-195

157

Software process and product quality assurance in it organizations

More Related Content

What's hot (19)

Viewers also liked (8)

Similar to Software process and product quality assurance in it organizations (20)

More from iaemedu (20)

Software process and product quality assurance in it organizations