Unit –I SQA

The software quality challenge:

The uniqueness of software quality assurance

The environments for which SQA methods are developed

The uniqueness of software quality assurance:

 High complexity, as compared to other industrial products

 Invisibility of the product
 Opportunities to detect defects (“bugs”) are limited to the product development phase.

The environments for which SQA methods are developed:

 Being contracted
 Subjection to customer–supplier relationship
 Requirement for teamwork
 Need for cooperation and coordination with other development teams
 Need for interfaces with other software systems
 Need to continue carrying out a project while the team changes
 Need to continue maintaining the software system for years

Being contracted:

Professional software development is almost always contracted.

 Have requirements / supplied requirements (hopefully)

– But may have in-house customer representatives.
– Or, customer representatives available…
 Budget
 Time schedule

Subjection to customer–supplier relationship:

The project team has to cooperate continuously with the customer:

 Changes will occur

 Criticisms will arise.
 Cooperation is critical to overall project success.
 Customer availability / relationship is essential

Requirement for teamwork:

We need teams due to

 Time required for development.
– Workload is too much for a single person
 A frequent variety of experts needed
– Database; networking; algorithms; …
 Need ‘independent’ reviews to ensure quality (me).
 Who is team: Developers, Clients, Customers & others.
Need for cooperation and coordination with other development teams:

For developing large Scale projects cooperation needed between:-

 Other software development teams in the same organization.
 Hardware development teams in the same organization.
 Software and hardware development teams of other suppliers.
 Customer software and hardware development teams that take part in the project’s
development.

Need for interfaces with other software systems:

Interfaces allow data in electronic form to flow between the software systems:
 Input interfaces, where other software systems transmit data to your software system.
 Output interfaces, where your software system transmits processed data to other software
systems.
 Input and output interfaces to the machine’s control board, as in medical and laboratory
control systems, metal processing equipment, etc.
Need to continue carrying out a project while the team changes:

 Team members leave, are hired, fired, take unexpected vacations, transferred within the
company, and more.

Need to continue maintaining the software system for years:

2
  Whether external customers or in-house customers, follow-on maintenance is typical and for
many years

What is software quality?

Software:

Software is a Computer programs, procedures, and possibly associated documentation and data
pertaining to the operation of a computer system. (IEEE)

Lists of four components of software (ISO):

A Software is a

 Computer programs (the “code”)

 Procedures
 Documentation
 Data necessary for operating the software system.

Software errors, faults and failures:

Software Error – made by programmer they are like

 Syntax (grammatical) error

 Logic error

Software Fault:

 All software errors may not cause software faults

 That part of the software may not be executed.(An error is present but not encountered….)

Software Failures:

 Software fault becomes a software failure only when it is “activated” – when the software
user tries to apply the specific, faulty application.
 Example: Standard software running in different client shops.

3
Classification of the causes of software errors:

The nine causes of software errors:

 Faulty requirements definition
 Client–developer communication failures
 Deliberate deviations from software requirements
 Logical design errors
 Coding errors
 Non-compliance with documentation and coding instructions
 Shortcomings of the testing process. Procedure errors
 Documentation errors

Software Quality – definition

Software Quality is (IEEE)

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.

3. Conformance to explicitly stated functional and performance requirements, explicitly documented

development standards, and implicit characteristics that are expected of all professionally developed
software.(Pressman’s).

Software Quality Assurance:

Software Quality Assurance is (IEEE)

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.

4
3. 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.( Expanded Definition).

Software Quality Assurance vs. Software Quality Control:-

Quality Control is defined as a designed to evaluate the quality of a set of activities developed or
manufactured product

 We have QC inspections during development and before deployment.

 QC activities are only a part of the total range of QA activities.

Quality Assurance’s objective is to minimize the cost of guaranteeing quality by a variety of

activities performed throughout the development / manufacturing processes / stages.

 Activities prevent causes of errors; detect and correct them early in the development process.
 QA substantially reduces the rate of products that do not qualify for shipment and/at the
same time, reduce the costs of guaranteeing quality in most cases.

Objectives of Software Quality Assurance Activities

The objectives of SQA activities for software development and maintenance are:
 Assuring, with acceptable levels of confidence, conformance to functional technical
requirements.
 Assuring, with acceptable levels of confidence, conformance to managerial requirements of
scheduling and budgets.
 Initiating and managing activities for the improvement and greater efficiency of Software
development and SQA activities.

Software Quality Assurance and Software Engineering

Software engineering is the application of a systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software.

3. Software Quality Factors

The need for comprehensive software quality requirements:

Many cases of low customer satisfaction are situations where software projects have satisfactorily
fulfilled the basic requirements of correctness, while suffering from poor performance in other
important areas such as maintenance, reliability, software reuse, or training.
This is due to lack of defined requirements pertaining to these aspects of software functionality.
Therefore, there is a need for the comprehensive definition of requirements that will cover all aspects
of software use throughout all stages of the software life cycle.

Classifications of software requirements into software quality factors:

McCall’s factor model classifies all software requirements into 11 software quality factors. The 11
factors are grouped into three categories:
The three categories are:
5
 Product operation category
 Product revision category
 Product transition category

 Product operation factors:

Correctness: Correctness requirements are defined in a list of the software system’s required
outputs, such as a query display of a customer’s balance in the sales, printout, and
temperature, completeness of the output information etc.

Reliability: Reliability requirements deal with failures to provide service.

Efficiency: Efficiency requirements deal with the hardware resources needed to perform all
the functions of the software system in conformance to all other requirements.

Integrity: Integrity requirements deal with the software system security, that is,
requirements to prevent access to unauthorized persons

Usability: Usability requirements deal with the scope of staff resources needed to train a new
employee and to operate the software system.

 Product revision factors: These factors deal with those requirements that affect the
complete range of software maintenance activities.

Maintainability: Maintainability requirements determine the efforts that will be needed by

users and maintenance personnel to identify the reasons for software failures, to correct the
failures, and to verify the success of the corrections.

Flexibility: This factor’s requirements also support perfective maintenance activities, such as
changes and additions to the software in order to improve its service and to adapt it to
changes in the firm’s technical or commercial environment.

Testability: Testability requirements deal with the testing of an information system as

well as with its operation, diagnostics of system weather all components are working properly
& to detect the causes of software failures

 Product transition factors: According to McCall, three quality factors are included in the
product transition category, a category that pertains to the adaptation of software to other
environments and its interaction with other software systems.

Portability: Portability requirements tend to the adaptation of a software system to other

environments consisting of different hardware, different operating systems & same
basic software in different hardware’s.

Reusability: The reuse of software is expected to save development resources, shorten the
development period, and provide higher quality modules.

Interoperability: Interoperability requirements focus on creating interfaces with other

software systems.

6
 McCall’s factor model tree

Alternative models of software quality factors:

Two factor models, appearing during the late 1980s, considered to be alternatives to the McCall
classic factor model (McCall et al., 1977), deserve discussion:

 The Evans and Marciniak factor model (Evans and Marciniak, 1987).
 The Deutsch and Willis factor model (Deutsch and Willis, 1988).

Formal comparison of the alternative models:

A formal comparison of the factor models reveals:

 Both alternative models exclude only one of McCall’s 11 factors, namely the testability factor.
 The Evans and Marciniak factor model consists of 12 factors that are classified into three
categories.
 The Deutsch and Willis factor model consists of 15 factors that are classified into four
categories.
Taken together, five new factors were suggested by the two alternative factor models:
 Verifiability (by both models): verification of design and programming features.
 Expandability (by both models): to improve usability like serve larger populations, improve
service.
 Safety (by Deutsch and Willis): to provide alarm signals when the dangerous conditions to
be detected by the software arise.
 Manageability (by Deutsch and Willis): Allows changes in software procedures.
 Survivability (by Deutsch and Willis): Survivability requirements refer to the continuity of
service

Who is interested in the definition of quality requirements?

7
The client is not the only party interested in thoroughly defining the requirements that assure
the quality of the software product. The developer is often interested in adding requirements
that represent his own interests, such as reusability, verifiability and portability requirements.
These may not, however, be of interest to the client.
Thus, one can expect that a project will be carried out according to two requirements
documents:
 The client’s requirements document
 The developer’s additional requirements document.

Software compliance with quality factors:

4. The components of the software quality assurance system

The SQA system – SQA Architecture:

An SQA system always combines a wide range of SQA components, all of which are employed to
challenge the multitude of sources of software errors and to achieve an acceptable level of
software quality.

SQA system components can be classified into six classes:

 Pre-project quality components

 Project life cycle quality components
 Infrastructure error preventive and improvement components
 Software quality management components
 Standardization, certification and SQA assessment components
 Organizing for SQA – the human components

8
 The SQA system – SQA Architecture

Pre-project components

The SQA components belonging here are meant to improve the preparatory steps taken prior to
initiating work on the project itself:
 Contract review
 Development and quality plans.

Contract review:
Specifically, contract review activities include:

 Clarification of the customer’s requirements

 Review of the project’s schedule and resource requirement estimates
 Evaluation of the professional staff’s capacity to carry out the proposed project
 Evaluation of the customer’s capacity to fulfill his obligations
 Evaluation of development risks.

Development and quality plans:

The main issues treated in the project development plan are:

 Schedules
 Required manpower and hardware resources
 Risk evaluations
 Organizational issues: team members, subcontractors and partnerships
 Project methodology, development tools, etc.
 Software reuse plans.

The main issues treated in the project’s quality plan are:

9
  Quality goals, expressed in the appropriate measurable terms
 Criteria for starting and ending each project stage
 Lists of reviews, tests, and other scheduled verification and validation activities.

Software project life cycle components:

The project life cycle is composed of two stages:

 The development life cycle stage and
 The operation–maintenance stage.

Several SQA components enter the software development project life cycle at different points.
Their use should be planned prior to the project’s initiation.
The main components are:
 Reviews
 Expert opinions
 Software testing
 Software maintenance
 Assurance of the quality of the subcontractors’ work and the customer supplied parts.

Reviews: Reviews can be categorized as formal design reviews (DRs) and peer reviews.
Reviews done on design reports, software test documents, software installation plans and
software manuals, among others.

Formal design reviews (DRs): It should be emphasized that the developer can continue to the
next phase of the development process only on receipt of formal approval of these documents.

Peer reviews: The main objective of inspections and walkthroughs is to detect as many design
and programming faults as possible. The output is a list of detected faults and improving
development methods.

Expert opinions: Expert opinions support quality assessment efforts by introducing additional
external capabilities into the organization’s in-house development process.

Software testing: Software tests are formal SQA components that are targeted toward review
of the actual running of the software. The tests are based on a prepared list of test cases that
represent a variety of expected scenarios. Software tests examine software modules, software
integration, or entire software packages (systems).

Software maintenance: Corrective maintenance, Adaptive maintenance, Functionality

improvement maintenance.
The main SQA components employed in the quality assurance of the maintenance system are as
follows.
Pre-maintenance components
 Maintenance contract review
 Maintenance plan.

Software development life cycle components:

These components are applied for functionality improvement and adaptive maintenance tasks,
activities whose characteristics are similar to those of the software development process.

Infrastructure SQA components:

 Maintenance procedures and instructions
 Supporting quality devices
 Maintenance staff training, retraining, and certification

10
  Maintenance preventive and corrective actions
 Configuration management
 Control of maintenance documentation and quality records.

Managerial control SQA components:

 Maintenance service control

 Maintenance quality metrics
 Maintenance quality costs.

Assurance of the quality of the external participant’s work:

Infrastructure components for error prevention and improvement:

The goals of SQA infrastructure are the prevention of software faults or, atleast, the lowering of
software fault rates, together with the improvement of productivity.

This class of SQA components includes:

 Procedures and work instructions
 Templates and checklists
 Staff training, retraining, and certification
 Preventive and corrective actions
 Configuration management
 Documentation control.

Procedures and work instructions:

Procedures and work instructions are based on the organization’s accumulated experience and
knowledge; as such, they contribute to the correct and effective performance of established
technologies and routines.

Supporting quality devices:

One way to combine higher quality with higher efficiency is to use supporting quality devices,
such as templates and checklists.
 Saving the time required to define the structure of the various documents or prepare lists
of subjects to be reviewed.
 Contributing to the completeness of the documents and reviews.
 Improving communication between development team and review committee members
by standardizing documents and agendas.

Staff training, instruction and certification:

 Training new employees and retraining those employees who have changed assignments.
 Continuously updating staff with respect to professional developments and the in-house,
hands-on experience acquired.
 Certifying employees after their knowledge and ability have been demonstrated.

Preventive and corrective actions:

 Implementation of changes that prevent similar failures in the future.

11
  Correction of similar faults found in other projects and among the activities performed by
other teams.
 Implementing proven successful methodologies to enhance the probability of repeat
successes.

Configuration management:

Configuration management procedures to control the change process like modify software to
create new versions and releases, conducted throughout the entire software service period.

Documentation control:
Documentation control functions refer mainly to customer requirement documents, contract
documents, design reports, project plans, development standards, etc.

Management SQA components

 Project progress control (including maintenance contract control)

 Software quality metrics
 Software quality costs.

Project progress control:

The main objective of project progress control components is to detect the appearance of any
situation that may induce deviations from the project’s plans and maintenance service
performance.
Project control activities focus on:

 Resource usage
 Schedules
 Risk management activities
 The budget.

Software quality metrics:

The software quality metrics available or still in the process of development, we can list metrics
for:
 Quality of software development and maintenance activities
 Development teams’ productivity
 Help desk and maintenance teams’ productivity
 Software faults density
 Schedule deviations.

Software quality costs:

SQA standards, system certification, and assessment components

External tools offer another avenue for achieving the goals of software quality assurance.
Specifically, the main objectives of this class of components are:

 Utilization of international professional knowledge.

 Improvement of coordination with other organizations’ quality systems.
 Objective professional evaluation and measurement of the achievements of the
organization’s quality systems.
The SQA Standards are classified into two types:
 Quality Management Standards
12
  Project Process Standards

Quality management standards:

Organizations that comply with quality achievement requirements can then seek SQA certification.
The most familiar examples of this type of standard are:
 SEI CMM assessment standard
 ISO 9001 and ISO 9000-3 standards.

Project process standards:

 IEEE 1012 standard

 ISO/IEC 12207 standard.

Organizing for SQA – the human components

 To develop and support implementation of SQA components.

 To detect deviations from SQA procedures and methodology.
 To suggest improvements to SQA components.

Management’s role in SQA:

The responsibilities of top management are

 Definition of the quality policy
 Effective follow-up of quality policy implementation
 Allocation of sufficient resources to implement quality policy
 Assignment of adequate staff
 Follow-up of compliance of quality assurance procedures
 Solutions of schedule, budget and customer relations difficulties.

The SQA unit:

This unit and software testers are the only parts of the SQA organizational base
that devote themselves full-time to SQA matters.

 Preparation of annual quality programs

 Consultation with in-house staff and outside experts on software quality issues
 Conduct of internal quality assurance audits
 Leadership of quality assurance various committees
 Support of existing quality assurance infrastructure components and their updates, and
development of new components.

SQA trustees, committees and forums:

SQA trustees are members of development and maintenance teams who have a special interest
in software quality
 Solving team or unit local quality problems
 Detecting deviations from quality procedures and instructions
 Initiating improvements in SQA components
 Reporting to the SQA unit about quality issues in their team or unit.

SQA committee members are members of various software development and maintenance units,
and are usually appointed for term or ad hoc service.

 Solution of software quality problems.

13
  Analysis of problem and failure records as well as other records, followed by initiation of
corrective and preventive actions when appropriate.
 Initiation and development of new procedures and instructions; updating existing
materials.
 Initiation and development of new SQA components and improvement of existing
components.

SQA forums are composed of professionals and practitioners who meet and/or maintain an Internet
site on a voluntary basis for discussion of quality issues pertaining to development and maintenance
processes.

Considerations guiding construction of an organization’s SQA system

 The SQA organizational base

 The SQA components to be implemented within the organization and the extent of their use.

5. Pre-project software quality components

5.1 The CFV Project completion celebration

5.2 The contract review process and its stages

Several situations can lead a software company to sign a contract with a customer. The most
common are:

 Participation in a tender.
 Submission of a proposal according to the customer’s RFP.
 Receipt of an order from a company’s customer.
 Receipt of an internal request or order from another department in the organization.

The review process itself is conducted in two stages:

Stage One: Review of the proposal draft prior to submission to the potential customer (“proposal
draft review”). This stage reviews the final proposal draft and the proposal’s foundations: customer’s
requirement documents, customer’s additional details and explanations of the requirements, cost and
resources estimates, existing contracts or contract drafts of the supplier with partners and
subcontractors.

Stage Two – Review of contract draft prior to signing (“contract draft review”). This stage
reviews the contract draft on the basis of the proposal and the understandings (including changes)
reached during the contract negotiations sessions.

5.3 Contract review objectives

Proposal draft review objectives:

The nine proposal draft review objectives that make sure the following activities have been
satisfactorily carried out:
1. Customer requirements have been clarified and documented.
2. Alternative approaches for carrying out the project have been examined.
14
3. Formal aspects of the relationship between the customer and the software firm have been
specified.
4. Identification of development risks.
5. Adequate estimation of project resources and timetable have been prepared.
6. Examination of the firm’s capacity with respect to the project.
7. Examination of the customer’s capacity to fulfill his commitments.
8. Definition of partner and subcontractor participation conditions.
9. Definition and protection of proprietary rights.

Contract draft review objectives:

The three contract draft review objectives that make sure the following activities have been
satisfactorily carried out:
1. No unqualified issues remain in the contract draft.
2. All understandings reached subsequent to the proposal are correctly documented.
3. No “new” changes, additions, or omissions have entered the contract draft.

5.4 Implementation of a contract review

Contract reviews vary in their magnitude, depending on the characteristics of the

proposed project. This complexity may be either technical or organizational.

Factors affecting the extent of a contract review:

 Project magnitude, usually measured in man-month resources.

 Project technical complexity.
 Degree of staff acquaintance with and experience in the project area
 Project organizational complexity.

Who performs a contract review?

 The leader or another member of the proposal team.

 The members of the proposal team.
 An outside professional or a company staff member who is not a member of the proposal
team.
 A team of outside experts.

Implementation of a contract review for a major proposal

The difficulties of carrying out contract reviews for major proposals:

 Time pressures
 Proper contract review requires substantial professional work.
 The potential contract review team members are very busy.

Recommended avenues for implementing major contract reviews

It is recommended that the following steps be taken to facilitate the review process:-
 The contract review should be scheduled.
 A team should carry out the contract review.
 A contract review team leader should be appointed. The activities of the team leader include:
• Recruitment of the team members
• Distribution of review tasks among the team’s members

15
 • Coordination between the members of the review team
• Coordination between the review team and the proposal team
• Follow-up of activities, especially compliance with the schedule
• Summarization of the findings and their delivery to the proposal team.

Contract reviews for internal projects

Internal software development projects are not based on what would be considered a complete
customer–supplier relationship. In many cases, these projects are based on general agreements,
with goodwill playing an important role in the relationships between the two units. It follows that the
developing unit will perform only a short and “mild” contract review, or none at all.

16