The components of the

software quality assurance

system
SQA system component 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
 Pre-project components
• Contract review
• Development and quality plans
Contract review
• Software may be developed within the framework of a contract negotiated with a
customer or in response to an internal order originating in another department.

• An internal order may entail a request for developing a firmware software system to be
embedded within a hardware product, an order for a software product to be sold as a
package, or an order for the development of administrative software to be applied
within the company.

• In all these instances, the development unit is committed to an agreed-upon functional

specification, budget and schedule.
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
• Once a software development contract has been signed or a commitment made to undertake an
internal project for the benefit of another department of the organization, a plan is prepared of
the project (“development plan”) and its integrated quality assurance activities (“quality plan”).

• These plans include additional details and needed revisions based on prior plans that provided the
basis for the current proposal and contract. It is quite common for several months to pass
between the tender submission and the signing of the contract.

• During this period, changes may occur in staff availability, in professional capabilities, and so forth.
The plans are then revised to reflect the changes that occurred in the interim
Development and quality plans
The main issues treated in the project The main issues treated in the project’s quality plan
development plan are: are:

■ Quality goals, expressed in the appropriate

■ Schedules
measurable terms
■ Required manpower and hardware resources
■ Criteria for starting and ending each project stage
■ Risk evaluations
■ Lists of reviews, tests, and other scheduled
■ Organizational issues: team members, verification and validation activities

subcontractors and partnerships

■ Project methodology, development tools, etc.

■ Software reuse plans.

 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.
 Software project life cycle components
Reviews
The design phase of the development process produces a variety of documents.
The printed products include design reports, software test documents, software
installation plans and software manuals, among others. Reviews can be categorized
as
❖ Formal design reviews (DRs)
❖ Peer reviews.
 Software project life cycle components
Reviews - Formal design reviews (DRs)
✔ A significant portion of these documents requires formal professional approval of their quality
as stipulated in the development contract and demanded by the procedures applied by the
software developer.
✔ 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.
✔ Ad hoc committees whose members examine the documents presented by the development
teams usually carry out formal design reviews (widely known as “DRs”)
✔ The committees are composed of senior professionals, including the project leader and, usually,
the department manager, the chief software engineer, and heads of other related departments.
✔ The majority of participants hold professional and administrative ranks higher than the project
leader.
✔ On many occasions, the customer’s representative will participate in a DR
 Software project life cycle components
Reviews - Formal design reviews (DRs)
The DR report itself includes a list of required corrections (termed “action items”).
When a design review committee sits in order to decide upon the continuation of
the work completed so far, one of the following options is usually open for
consideration:
■ Immediate approval of the DR document and continuation to the next
development phase.
■ Approval to proceed to the next development phase after all the action items
have been completed and inspected by the committee’s representative.
■ An additional DR is required and scheduled to take place after all the action items
have been completed and inspected by the committee’s representative.
Formal design reviews will focus on

The participants
The review leader : characteristics are to be looked for in a candidate for this position:
■ Knowledge and experience in development of projects of the type reviewed. Preliminary acquaintance
with the current project is not necessary.
■ Seniority at a level similar to if not higher than that of the project leader.
■ A good relationship with the project leader and his team.
■ A position external to the project team.
The review team
The entire review team should be selected from among the senior members of the project team together
with appropriate senior professionals assigned to other projects and departments, customer–user
representatives, and in some cases, software development consultants. It is desirable for non-project staff to
make up the majority of the review team.
The prior preparations
The DR session
The recommended post-DR activities.
Formal design reviews will focus on
The prior preparations
DR session are to be completed by all three main participants in the review – the review leader, the review team and
the development team – each participant is required to focus on distinct aspects of the process
Review leader preparations
The main tasks of the review leader in the preparation stage are:
■ To appoint the team members
■ To schedule the review sessions
■ To distribute the design document among the team members (hard copy, electronic file, etc.).
Review team preparations
• Team members are expected to review the design document and list their comments prior to the review session.
• Checklists contribute to the design review’s effectiveness by reminding the reviewer of all the primary and
secondary issues requiring attention.
Development team preparations
• The team’s main obligation as the review session approaches is to prepare a short presentation of the design
document. Assuming that the review team members have read the design document thoroughly and are now
familiar with the project’s outlines, the presentation should focus on the main professional issues awaiting approval
rather than wasting time on description of the project in general.
The DR session
The recommended post-DR activities.
 Formal design reviews will focus on
The DR session
The review leader’s experience in leading the discussions and sticking to the agenda is the key to a successful
DR session.
A typical DR session agenda includes:
(1) A short presentation of the design document.
(2) Comments made by members of the review team.
(3) Verification and validation in which each of the comments is discussed to determine the required actions
(corrections, changes and additions) that the project team has to perform.
(4) Decisions about the design product (document), which determines the project’s progress. These decisions
can take three forms:
❑ Full approval
❑ Partial approval
❑ Denial of approval

The recommended post-DR activities.

Formal design reviews will focus on
The recommended post-DR activities.
Apart from the DR report, the DR team or its representative is required to follow up performance of
the corrections and to examine the corrected sections.
The DR report
The report’s major sections contain:
■ A summary of the review discussions.
■ The decision about continuation of the project.
■ A full list of the required actions – corrections, changes and additions that the project team has to
perform. For each action item, the anticipated completion date and project team member
responsible are listed.
■ The name(s) of the review team member(s) assigned to follow up performance of corrections.
The follow-up process
• The person appointed to follow up the corrections, in many cases the review leader him or
herself, is required to determine whether each action item has been satisfactorily accomplished as
a condition for allowing the project to continue to the next phase.
• Follow-up should be fully documented to enable clarification of the corrections in the future, if
necessary.
Pressman’s 13 “golden guidelines” for a successful design
review
Fig: Formal Design Review
Process
 Software project life cycle components
Reviews - Peer reviews
✔ Peer reviews (inspections and walkthroughs) are directed at reviewing short documents,
chapters or parts of a report, a coded printout of a software module, and the like.
✔ Inspections and walkthroughs can take several forms and use many methods; usually, the
reviewers are all peers, not superiors, who provide professional assistance to colleagues.
✔ 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, for inspections, also a defect summary and statistics
to be used as a database for reviewing and improving development methods.
✔ Because a peer’s participation is usually voluntarily and viewed as a supplement to the regular
workload, “reciprocity” considerations frequently enter.
✔ Thus, a current participant is expected to initiate a future inspection or walkthrough in which
other colleagues will probably exchange roles regarding the inspection activities.
Peer Review
Inspection is usually based on a comprehensive infrastructure,
including:
■ Development of inspection checklists developed for each type of design
document as well as coding language and tool, which are periodically updated.
■ Development of typical defect type frequency tables, based on past findings, to
direct inspectors to potential “defect concentration areas”.
■ Training of competent professionals in inspection process issues, a process that
makes it possible for them to serve as inspection leaders (moderators) or
inspection team members. The trained employees serve as a reservoir of
professional inspectors available for future projects.
■ Periodic analysis of the effectiveness of past inspections to improve the
inspection methodology.
■ Introduction of scheduled inspections into the project activity plan and allocation
of the required resources, including resources for correction of detected defects.
Peer Review
Our discussion of peer review methods will thus focus on:
■ Participants of peer reviews
■ Requisite preparations for peer reviews
■ The peer review session
■ Post-peer review activities
■ Peer review efficiency
■ Peer review coverage.
 Peer Review
Our discussion of peer review methods will thus focus on:
Participants of peer reviews
The optimal peer review team is composed of three to five participants. In certain cases, the
addition of one to three further participants is acceptable.
A recommended peer review team includes:
■ A review leader
The role of review leader (“moderator” in inspections, “coordinator’ in walkthroughs) differs only
slightly by peer review type. Candidates for this position must:
(1) Be well versed in development of projects of the current type and familiar with its technologies.
Preliminary acquaintance with the current project is not necessary.
(2) Maintain good relationships with the author and the development team.
(3) Come from outside the project team.
(4) Display proven experience in coordination and leadership of professional meetings.
(5) For inspections, training as a moderator is also required.
■ The author
■ Specialized professionals.
Peer Review
■ The author
The author is, invariably a participant in each type of peer review.
■ Specialized professionals.
The specialized professionals participating in the two peer review methods differ by review. For
inspections, the recommended professionals are:
■ A designer: the systems analyst responsible for analysis and design of the software system
reviewed.
■ A coder or implementer: a professional who is thoroughly acquainted with coding tasks,
preferably the leader of the designated coding team. This inspector is expected to contribute his or
her expertise to the detection of defects that could lead to coding errors and subsequent software
implementation difficulties.
■ A tester: an experienced professional, preferably the leader of the assigned testing team, who
focuses on identification of design errors usually detected during the testing phase.
Team assignments
Conducting a review session requires, naturally, assignment of specific tasks to the team members.
Two of these members are the presenter of the document and the scribe, who documents the
discussions. The presenter &The scribe
Peer Review
Preparations for a peer review session
1. Peer review leader’s preparations for the review session
The main tasks of the review leader in the preparation stage are:
■ To determine, together with the author, which sections of the design document
are to be reviewed.
Such sections can be:
– The most difficult and complex sections
– The most critical sections, where any defect can cause severe damage to the program application and thus to
the user
– The sections prone to defects.
■ To select the team members.
■ To schedule the peer review sessions.
■ To distribute the document to the team members prior to the review session.
Peer Review
Preparations for a peer review session
2. Peer review team’s preparations for the review session
• At this meeting, the author provides the inspection team members with the necessary relevant
background for reviewing the chosen document sections: the project in general, the logic,
processes, outputs, inputs, and interfaces.
• An important tool supporting the inspector’s review is a checklist
• Prior to the walkthrough session, team members briefly read the material in order to obtain a
general overview of the sections to be reviewed, the project and its environment.
 Peer Review
The peer review session
• A typical peer review session takes the following form. The presenter reads a section of the
document and adds, if needed, a brief explanation of the issues involved in his or her own words.
• As the session progresses, the participants either deliver their comments to the document or
address their reactions to the comments.
• The discussion should be confined to identification of errors, which means that it should not deal
with tentative solutions.
Session documentation
• The documentation produced at the end of an inspection session is much more comprehensive
than that of a walkthrough session.
• Two documents are to be produced following an inspection session and subsequently distributed
among the session participants:
(1) Inspection session findings report.(This report, produced by the scribe)
(2) Inspection session summary report. This report is to be compiled by the inspection leader
shortly after the session or series of sessions dealing with the same document.
Peer Review
Post-peer review activities
Post-inspection activities are conducted to attest to:
■ The prompt, effective correction and reworking of all errors by the
designer/author and his team, as performed by the inspection leader (or other
team member) in the course of the assigned follow-up activities.
■ Transmission of the inspection reports to the internal Corrective Action Board
(CAB) for analysis. This action initiates the corrective and preventive actions that
will reduce future defects and improve productivity
Peer Review
The efficiency of peer reviews
Some of the more common metrics applied to estimate the efficiency of peer
reviews, as suggested in the literature, are:
■ Peer review detection efficiency (average hours worked per defect detected).
■ Peer review defect detection density (average number of defects detected per
page of the design document).
■ Internal peer review effectiveness (percentage of defects detected by peer
review as a percentage of total defects detected by the developer)
 Software project life cycle components
Expert opinions
✔ Expert opinions support quality assessment efforts by introducing additional external capabilities into the
organization’s in-house development process.
✔ Turning to outside experts may be particularly useful in the following situations:

■ Insufficient in-house professional capabilities in a given area.

■ In small organizations in many cases it is difficult to find enough suitable candidates to
participate in the design review teams. In such situations, outside experts may join a DR
committee or, alternatively, their expert opinions may replace a DR.
■ In small organizations or in situations characterized by extreme work pressures, an
outside expert’s opinion can replace an inspection.
■ Temporary inaccessibility of in-house professionals (waiting will cause substantial delays
in the project completion schedule).
■ In cases of major disagreement among the organization’s senior professionals, an
outside expert may support a decision
 Software project life cycle components
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).
✔ Recurrent tests (usually termed “regression tests”), carried out after correction of previous test
findings, are continued till satisfactory results are obtained.
✔ The direct objective of the software tests, other than detection of software faults and other
failures to fill the requirements, is the formal approval of a module or integration setup so that
either the next programming phase can be begun or the completed software system can be
delivered and installed.
 Software project life cycle components
Software testing

✔ Software testing programs are constructed from a variety of tests, some manual
and some automated.
✔ All tests have to be designed, planned and approved according to development
procedures.
✔ The test report will include a detailed list of the faults detected and
recommendations about the performance of partial or complete recurrent tests
following a subsequent round of corrections based on the test findings. (The
advantages and disadvantages of automated testing are discussed later.)
✔ It is recommended that software tests be carried out by an independent, outside
testing unit rather than by the project team, as the project team will naturally
find it difficult to detect faults they failed to detect during development as well as
to avoid conflicts of interest.
 Software project life cycle components
Software maintenance components
Software maintenance services vary in range and are provided for extensive periods, often several
years. These services fall into the following categories:
■ Corrective maintenance – User’s support services and correction of software code and
documentation failures.
■ Adaptive maintenance – Adaptation of current software to new circumstances and customers
without changing the basic software product. These adaptations are usually required when the
hardware system or its components undergo modification (additions or changes).
■ Functionality improvement maintenance – The functional and performance-related improvement
of existing software, carried out with respect to limited issues.
 Software project life cycle components
Software maintenance components
✔ Software maintenance services should meet all kinds of quality requirements, particularly functionality and scheduling requirements
(generally decided together with the customer) as well as budget limitations (determined by the service provider).
✔ The provision of ongoing maintenance services involves the application of a great variety of SQA components. The main SQA
components employed in the quality assurance of the maintenance system are as follows.

Pre-maintenance components Software development life cycle components

■ Maintenance contract review These components are applied for functionality improvement and adaptive
■ Maintenance plan. maintenance tasks, activities whose characteristics are similar to those of the
software development process.
Managerial control SQA components Infrastructure SQA components
■ Maintenance service control ■ Maintenance procedures and instructions
■ Maintenance quality metrics ■ Supporting quality devices
■ Maintenance quality costs. ■ Maintenance staff training, retraining, and certification
■ Maintenance preventive and corrective actions
■ Configuration management
■ Control of maintenance documentation and quality records.
 Software project life cycle components
Assurance of the quality of the external participant’s work
Subcontractors and customers frequently join the directly contracted developers (the “supplier”) in carrying
out software development projects.
The larger and more complex the project, the greater the likelihood that external participants will be required,
and the larger the proportion of work transmitted to them (subcontractors, suppliers of COTS (Commercial
Off-the-Shelf Software )software and the customer).