​

SOFTWARE QUALITY ASSURANCE

​

PLANNING FOR SOFTWARE QUALITY ASSURANCE

​

Prepared by

C.Jamunadevi

Assistant Professor(SrG)

Department of Computer Technology-PG

Kongu Engineering College

�

C.Jamunadevi,AP(SrG),KEC

3.1 Software Quality Assurance Plans

3.1.1 Purpose of SQA Plan

• Software must pass the AcceptanceTest.
• acceptance tests are conducted to enable the customer to validate all requirements.
• The user's public liability for damages, should the public be harmed in some way by the malfunctioning of the software.
• Quality Assurance does have a dimension of social commitment, too.
• Quality is achieved by building it into the software all throughout the project lifecycle;

C.Jamunadevi,AP(SrG),KEC

3.1.2 Content of the Software Quality Assurance Plan:

The IEEE Standard for Software Quality Assurance Plans states that the plan should contain the following sections:

• Purpose
• Reference documents
• Management
• Documentation
• Standards, practices and
• conventions Reviews and Audits
• Configuration Management
• Problem reporting and corrective action
• Tools, techniques and methodologies
• Code Control
• Media Control
• Supplier Control
• Records collection, maintenance and retention

C.Jamunadevi,AP(SrG),KEC

3.2 SOFTWARE QUALITY ASSURANCE: ORGANIZATIONAL INITIATIVES

3.2.1. MANAGING SOFTWARE PROCESS

3.2.1.1 Process Management

• Software development can be extremely complex, with a choice for selecting an alternative from among those available for performing the same task.
•  A "defined software process" provides a framework within which the development staff can make choices in an orderly way rather than in an ad-hoc fashion. 
• organizational activity feedback:
• Define standard software process: method procedures, develop maintain process documentation usable software process assets.
• Ensure project appropriate version - process tailored individual needs
• Metric program need to be addressed

​

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

3.2.1.2 Standard Process Definition

• It is important for staff & managers involved implementation process to participate in the definition of it.
• documented plan : must activities schedule defining process, specify group individual responsibilities activities, identify required reso

The Process Process Definition should typically address:

• Activities Process Definition:
• Develop and maintain Organization's software process
• Identify organization's software process.
• Define /Change Organization's software process
• Document The Process Reply Forward
• Review and Approve the Process
• Release, Distribution and Retirement of QMS Document 
•  Identification and documentation of Software Life cycle, methods and tools
• Develop and Maintain Tailoring guidelines for projects
• Guidelines for Writing a Process Document .
• Guidelines for creating a Release Notice for announcing the new/ modified processes
• Guidelines for reviewing new Process documents
• Guidelines on Process Release

​

C.Jamunadevi,AP(SrG),KEC

Each project has its own approved life cycle that defines:

• Required procedures, practices, methods and technologies.
• Applicable process and product standards
• Responsibilities, authorities and staff interrelationships 
• Required tools and resources
• Process dependencies and interfaces
• Process outputs and completion criteria
• Product and process measurements to be collected.

It is important to set and track quantitative, measurable goals for process improvement, and to direct these goals at increasing the quality of products and services as well as productivity.  �

​

C.Jamunadevi,AP(SrG),KEC

3.2.1.3 Software Process Measurements

•  It is said that you cannot "improve" some thing that you cannot "measure". 
• This analysis should be used to adjust or tune the standard process, with a view to improving it and stabilizing its performance within acceptable limits.
• The aim of the metrics program is to determine the various parameters to be monitored and measured, define a mechanism for assimilation of data from the implementation team for analysis at Project level as well as at Organization level.

​

In developing a metrics program, the following issues need to be resolved:

• "What" should be measured?

​

• "Why" it should be measured?
• �. "How" it should be measured?
• �. "Who" should measure it?

​

• . "When" and "Where" in the process it should be measured

​

​

�

�

C.Jamunadevi,AP(SrG),KEC

The selected metrics should therefore:

• be linked to real customer requirements
• support the overall goals and objectives of the measurement
• be consistent across all projects
•  cover the entire life cycle, including support and maintenance

​

Examples of specific measurements that can be used are:

• estimated versus actual SIZE, COST and SCHEDULE data
• quality measurements as defined in the quality plan (PRODUCTIV ITY, EFFORT, DEFECT REMOVAL EFFICIENCY, PROCESS COMPLIANCE etc)
• Number and severity of defects in requirements, design and code
• Number and cost of changes to approved requirements and design specifications
• Number and turnaround time of customer requests and bug reports

�

C.Jamunadevi,AP(SrG),KEC

3.2.1.4 Defect Prevention

• Defect prevention is concerned with ensuring that sources of defects that are inherent in the software process, or of defects that occur repeatedly.
• Defect prevention activities should be defined and implemented at both organizational and project level. 

The defects are identified from following inputs:

• Project wind up reports

• Organizational metrics analysis

• Audit & Assessment reports

• Other organizational level meetings

�

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

 Proposed defect prevention actions such as the following:

• description of the defect
• description of the cause category of the cause
• stage where the defect was identified
• description of the proposed action
• Whether the proposed action is feasible or not
• person responsible for implementing the action
• date by which the action is to be completed
• description of the areas affected by the corrective action
• individuals who are to be kept informed of the action's status
• date of the next status review
• rationale for key decision

​

C.Jamunadevi,AP(SrG),KEC

3.2.1.5 Technology Innovation

New technologies that are likely to improve the capability of it. These changes:

• Enable the organization to achieve exacting quality standards resulting in decreases in defects.�• Empower it to reduce process cycle times and increase process effectiveness, both of which would in turn improve productivity �and quality

• Improve the capability of the organization's standard software processes

�

C.Jamunadevi,AP(SrG),KEC

Sources of inputs for process change are:

• Findings and recommendations from Audits and Assessments

• Lessons learnt from monitoring process activities • Change proposals from project staff and managers

• Analyzed and interpreted processes and product measurement data

• A system must be established for employees to communicate the Process Change Request to the Process Engineering Group. 
• The group will then evaluate the change request and accordingly reject or accept the request.

�

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

The format for Process Change request should include the following:

• Requester's Name
• Requester's contact no
• Ref to process in the Quality Management System for which change is requested
• Description of change requested
• Justification for the change suggested

​

​

�

C.Jamunadevi,AP(SrG),KEC

3.3 Quality Planning-Some Interesting Dilemmas and Observations

• It is well known that "quality" owes its origin to the manufacturing industry,
• Quality buzz word 
• Software Quality Assurance Plan is vehicle to put the quality policy in practice.
• It is a mechanism whereby the procedures/processes defined in the Quality Management System get implemented. 
• senior management commitment to quality gets expressed through the Quality Plan.

​

C.Jamunadevi,AP(SrG),KEC

• the project gets initiated as per organization's process, the quality goals get documented; 
• It could even be that half of these project managers could be certified project manag ers who, as a part of their certification preparation, vouched for "quality practices"; 
• QA department goes on talent scoot to look for best practices, to look for assets that can be submitted etc.
• et another scenario; when a customer-visit is announced, projects would become very friendly with the Quality Department.

C.Jamunadevi,AP(SrG),KEC

•  The reality is that to collect periodic metrics from these same project would probably be the worst nightmare for the quality team.
• Indian software industry-"do we dare to give enough authority to our quality deparment to put their foot down and stop the shipment of a product/service if it is not found to be worthy of release/shipment?" Are we capable of educating our clients right from the beginning that quality is a serious business issue and that we want to be married to it right from start end of a project:

C.Jamunadevi,AP(SrG),KEC

• When a client to push a Change Request implementation tries to "quickly" enough for us to be called a "co-operative" supplier; 
•  Quality professionals need to have the "tact" of "selling" the QMS processes to the practitioners to see its realistic and yet meaningful implementation.

C.Jamunadevi,AP(SrG),KEC

PRODUCT QUALITY AND PROCESS QUALITY

C.Jamunadevi,AP(SrG),KEC

• Product quality means to incorporate features that have a capacity to meet consumer needs (wants) and gives customer satisfaction by improving products (goods) and making them free from any deficiencies or defects.
• Process quality refers to the degree to which an acceptable process, including measurements and criteria for quality, has been implemented and adhered to in order to produce the artifacts. ... The objectives of measuring and assessing process quality are to: Manage profitability and resources.

C.Jamunadevi,AP(SrG),KEC

4.2 Software Systems Evolution

C.Jamunadevi,AP(SrG),KEC

Software products, as compared to non-software products have certain characteristics:

• Software is "developed" or "engineered"; it is not "manufactured” in the classical sense
• Software does not "wear out"; it only deteriorates over a period of time” --it needs "Enhancements"

• Most software today is assembled from reusable components rather than being custom-built based on fresh requirements analysis.

C.Jamunadevi,AP(SrG),KEC

4.3 Product Quality

• The "attributes and characteristics of the software products and the degree that the fulfill specific project needs provides an incremental measure of ou ity of the end product. 
• IEEE Standard Glossary of Software Engineering Technology – define "Software Product" as (1) The complete set of computer programs, procedures, and possibly associated documentation and data designated for delivery to a user. (2) Any of the individual items in (1)

C.Jamunadevi,AP(SrG),KEC

4.3.1 Software Attributes:

• According to IEEE STD 983-1986, "Standards" are Mandatory require ments employed and enforced to prescribe a disciplined uniform approach to software development, that is, mandatory conventions and practices are in fact standards.
• quality "gates" identified, which will monitor the quality of the software products being produced before they are used by the project. 

C.Jamunadevi,AP(SrG),KEC

• Quality Models are important because they tell us what people think is important and also help us to understand the commonalities of their views. 

Software Product Quality into a number of features or characteristics. Such features typically include:

• Reliability
• Usability
• Functionality
• Maintainability
• Correctness
• Portability
• Testability
• Efficiency

�

C.Jamunadevi,AP(SrG),KEC

4.3.2 Classification of Software Application Attributes:

• Performance Attributes:

which describe the execution characteristics of the software when, integrated into an operational configuration.

• Form Attributes:

which describe the form of the product and how it will appear when delivered.

• Processing Attributes:

Those which describe processing characteristics of the software.

• Functional Attributes:

Those, which describe the functionality of the system when, integrated into an operational configuration. 

• Operational Integrity:

Those, which describe the reliability, system control, and operational support characteristics of the soft ware and the degree that the system supports the requirements of the application. 

�

C.Jamunadevi,AP(SrG),KEC

2.4 Models for Software Product Quality

4.4.1 McCall's Factor-Criteria-Metric Model:

This model is incorporated with many attributes, termed as software factors, which influence a software. The model distinguishes between two levels of quality attributes :

• Quality Factors –�The higher level quality attributes which can be assessed directly are called quality factors. These attributes are external attributes.The attributes in this level are given more importance by the users and managers.
• Quality Criteria –�The lower or second level quality attributes which can be assessed either subjectively or objectively are called Quality Criteria. These attributes are internal attributes. Each quality factor has many second level of quality attributes or quality criteria.

​

​

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

• The purpose of McCall product quality model was to define the characteristics to be assessed and to suggest some measures to capture those characteristics.
• The McCall model was originally developed for the US Air Force and its use is promoted within the US Department of Defense for evaluating software product quality.

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

4.4.2 The ISO 9126 Standard Quality Model

• Software Product Evaluation: Quality Characteristics and Guidelines for their Use".
• The totality of features and characteristics of a software product that bear on it ability to satisfy stated or implied needs.
• Quality is decomposed into six factors:
• Functionality
• Reliability
• Efficiency
• Usability
• Maintainability
• Portability

​

C.Jamunadevi,AP(SrG),KEC

4.4.3 Other Models for Software Product Quality:

• Goal-Question-Metric Model is another well-known model from Basili and Rombach. 
• The basic idea behind the work of Basili and Rombach is that metrics are derived from measurement goals.
• Gilb (and Kitchenham) have pioneered the "define-your-own-model approach. This method can be thought of as "design by measurable objectives";
• The COQUAMO (Constructive QUAlity Model) approach of Kitchenham and Walker extends Gilb's ideas and supports them with automated tools as part of an ESPRIT (European Community) project

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

Evolutionary Software Models

• There is a growing recognition that software systems typically are complex and as such they evolve over a period of time. Business product require ments often change as development proceeds.
• This makes it difficult to follow the linear sequential approach to software development. 
• IEEE defines Quality Metric as

(1) A quantitative measure of the degree to which an item possesses a given quality attribute

(2) A function whose inputs are software data and whose output is a single numerical value that can be interpreted as he degree to which the sot ware possesses a given quality attribute�

C.Jamunadevi,AP(SrG),KEC

4.5 Process Quality:

“Quality is the totality of features and characteristics of a product service that bear on its ability to satisfy stated or implied needs”.

• Flexibility:

The ease with which a software system or component can be modified for use in applications or environments other than those for which it was specifically designed

• Interoperability:

The degree to which software. can be connected easily to other systems in order to operate it.

• Portability :

The effort required to transfer the software code from one hardware and/or software system environment to another.��

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

4.5.1 ISO 9001 Quality Management for Process Quality Framework:

• Quality Management Standard (QMS) for software development is the International Standards Organization's generic 'Quality Systems series of standards, ISO 9000 to 9004.
• ISO 9000 series, we will normally mean ISO 9001, which has been tailored for use in software environments by the addition of software-specific guid- ance documentation. 

C.Jamunadevi,AP(SrG),KEC

• Figure 3 provides a graphic representation of what is famously known as the PDCA cycle (PLAN, DO, CHECK, ACT).
• In applying ISO 9001 to software it has to be recognized that software differs in a number of ways from other industrial products, and that the processes used to produce software are not typical industrial processes.
• The general framework of ISO 9000 3 includes sub-sections on management, quality system, internal audits and corrective actions. 

C.Jamunadevi,AP(SrG),KEC

C.Jamunadevi,AP(SrG),KEC

A number of plans are required by the standard, including:

• A development plan

• A quality plan

• A test plan .

• A maintenance plan

Supporting activities in the ISO 9000-3 standard include:

• Configuration Management 
• Document Control
• Maintenance of Quality Records
• Process and Product Measurement
• Adoption of rules, practices and conventions
• Use of tools and techniques�
• Purchasing
• Procedures for included software
• Training

�

​

C.Jamunadevi,AP(SrG),KEC

4.5.1.1 Role of ISO 9001 in Evaluation of a software product

• ISO 9001 was designed for use between two parties; the purchaser and the supplier involved in a contract for the development of a particular (software) product.
• QUALITY MANGEMENT SYSTEMs such as ISO 9001 are little more than very general guidelines, which help to ensure that all reasonable steps have been taken to encourage process quality. �

C.Jamunadevi,AP(SrG),KEC

4.5.2 Maturity Models for Process Quality:

• The Software Engineering Institute (SEI), a federally funded re search and development laboratory based at Carnegie Mellon University in the United States, has developed a model of the software development process known as the "Capability Maturity Model (CMM)".
• The model is used as the basis for process improvement and evaluation.

​

​

C.Jamunadevi,AP(SrG),KEC

•  Basically, the SEI framework identifies five 'maturity levels' (initial, repeatable, defined, managed and optimizing),
• on an ordinal scale (for discussion on various types of scales, readers can refer the chapter on metrics and measurements) which roughly corresponds to a progression of candidate (software) process from
• 'ad hoc' (unpredictable, poorly managed), through intuitive (basic project management Practices and the ability to repeat previously mastered tasks), qualitative (well defined and institutionalized), quantitative (where the process S measured' and 'controlled'),

C.Jamunadevi,AP(SrG),KEC

The practices that describe key process areas are grouped into the following common features:

• Commitment to perform
• Ability to perform
• Activities performed
• Measurement and Analysis
• Verifying implementation

​

C.Jamunadevi,AP(SrG),KEC

REFERENCE

​

Godbole, Nina S., “Software Quality Assurance: Principles and Practice”, Narosa Publishing House, New Delhi, Eighth Reprint 2012.

​

C.Jamunadevi,AP(SrG),KEC