Question 01:

a) Define software quality and software quality assurance.

b) Distinguish between software errors and software faults. Identify the various causes of software
errors.
Software quality

IEEE definition: Software quality is:
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.

Pressmans definition: Software quality is defined as:
Conformance to explicitly stated functional and performance requirements, explicitly documented
development standards, and implicit characteristics that are expected of all professionally developed
software.
Software quality assurance

IEEE definition: Software quality assurance is:
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.

Expanded definition: Software quality assurance is 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.
Distinguish between software errors, software faults and software failures.
Software errors are sections of the code that are partially or totally incorrect as a result of a
grammatical, logical or other mistake made by a systems analyst, a programmer, or another
member of the software development team.
Software faults are software errors that cause the incorrect functioning of the software during a
specific application.
Software faults become software failures only when they are activated, that is, when a user tries
to apply the specific software section that is faulty. Thus, the root of any software failure is a
software error.
The nine causes of software errors
1. Faulty requirements definition
2. Clientdeveloper communication failures
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding instructions
7. Shortcomings of the testing process
8. Procedure errors
9. Documentation errors

Question 02:
a) Explain the relationship between software quality assurance and software engineering.
b) What are the three factor categories belonging to McMall's factor model? What factors are
included in each of the categories?
a) Explain the relationship between 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. The characteristics of software engineering,
especially its systematic, disciplined and quantitative approach, make software engineering a good
environment for achieving SQA objectives. It is commonly accepted that cooperation between
software engineers and the SQA team is the way to achieve efficient and economic development and
maintenance activities that, at the same time, assure the quality of the products of these activities.
b) McCalls factor model
McCalls factor model classifies all software requirements into 11 software quality factors. The 11
factors are grouped into three categories
a) Product operation,
b) Product revision and
c) Product transition

Product operation factors: According to McCalls model, five software quality factors are
included in the product operation category, all of which deal with requirements that directly affect
the daily operation of the software. These factors are as follows:
o Correctness,
o Reliability,
o Efficiency,
o Integrity,
o Usability.
Product revision factors: According to the McCall model of software quality factors, three quality
factors comprise the product revision category. These factors deal with those requirements that
affect the complete range of software maintenance activities: corrective maintenance (correction
of software faults and failures), adaptive maintenance (adapting the current software to additional
circumstances and customers without changing the software) and perfective maintenance
(enhancement and improvement of existing software with respect to locally limited issues). These
are as follows:
o Maintainability,
o Flexibility,
o Testability.
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. These are as follows:
o Portability,
o Reusability,
o Interoperability.

Question 03:
a) Mention different components of SQA system architecture.
b) What are the main issues treated in the project development plan.
a) SQA system architecture component are:
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
b) 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 projects quality plan are:
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.

Question 04:
a) Briefly describe Formal design reviews (DRs) method.
b) What are the functions of Expert opinions component in software development project life cycle.
a) 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).

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 committees representative.
An additional DR is required and scheduled to take place after all the action items have been
completed and inspected by the committees representative.
b) Expert opinions
Expert opinions support quality assessment efforts by introducing additional external capabilities into
the organizations 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
experts 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 organizations senior professionals, an outside expert
may support a decision.

Question 05:
a) List the objectives of contract review.
b) Briefly describe software maintenance components.
a) Contract review objectives:
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.

Accordingly, contract review activities must include a detailed examination of
(a) The project proposal draft and
(b) The contract drafts.
Specifically, contract review activities include:
Clarification of the customers requirements
Review of the projects schedule and resource requirement estimates
Evaluation of the professional staffs capacity to carry out the proposed project
Evaluation of the customers capacity to fulfill his obligations
Evaluation of development risks.
b) 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 Users 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.