Abstract

Software quality problem has become increasingly visible as software has emerged
as the dominant factor in determining system costs. Software inspection, or static
analysis
of software artifacts, is commonly recognized as an efficient way of finding
defects.
Unfortunately, in software inspection we often face the problem of non-existent,
unsatisfactory or inconsistent software documentation.
This thesis investigates existing inspection methods and derives a generic
inspection
process for assuring quality, evaluating and specifying post-release software
product.
The inspection strategy refers to a set of scenarios and to the associated
comparison
scheme to be used for diagnosing software defects.
To be rigorous and systematic, the process of inspecting incompletely documented
software needs an evolvable base of software artifacts analysis in order to avoid
desperate
understanding of the software system under study. To realize this, a generic
process
within the framework suggested employs a lifecycle-centric approach to software
inspection. To facilitate the process, we propose a stepwise abstraction system
recovery
while engineering the system in reverse.
We will also introduce an experiment investigating the development of a rigorous
approach for effective software inspection.

Chapter 1
Introduction
Even with the best software development technologies in place, defects cannot be
completely avoided. This stems from the fact that software development is a
humanbased
activity, and therefore prone to defects.
Quality is an elusive goal throughout the software development industry. The common
assumption is that there is simply no efficient way to improve quality without
significantly lengthening the development cycle, increasing development costs,
or both [1].
In the absence of feasible and cost-effective purely mechanical methods for
verifying
the correctness of software requirements, designs and implementations, software
inspection plays a vital role in validating them. The goal of inspection is to
reduce the
cost of software failure over the life of a software product.
The industry widely employs testing and the research community advocates formal
verification as methods for improving software quality. Inspection, also known as
one of
the forms of static analysis, falls somewhere between the two [2]. Inspection is
not the
same as testing or formal verification – all are needed to ensure the highest
quality
software.
Testing typically does not cover all code paths and is therefore frequently
incomplete.
Inspection seeks to complement testing: with inspection, defects can be found on
infrequently executed paths that would be unlikely to be included in test cases.
Software
inspection does not execute the code, so it requires no target system resources or
changes
to the program's operational behaviour, and can be used before the target hardware
is
available for testing purposes [1].
1
MASc Thesis – Michael Sharygin – McMaster – Software Engineering
Formal verification helps to determine mathematical correctness, but often
developers
use mathematical requirements inaccurately to capture their particular intents.
Since
inspection can be applied to any software artifact, inspection of documents helps
to
overcome this problem.
In addition to finding errors in code and related software documents, inspection
can
also help to determine whether coding style guidelines are followed, comments in
the
code are relevant, naming conventions are clear and consistent, the code is easy to
maintain, and so on [2].
The choice of inspection strategy depends on whether or not existent software
documentation adequately represents software. In reality, we often face a problem
of inadequate software documentation. At this point, it is useful to clarify the
term
“incompletely documented software”.
In this work, “incomplete documentation” signifies a set of available official
software
documents that is not sufficient to fulfil the inspection assignment on that
software
straightforwardly, i. e., by checking software development decisions dynamics in a
topdown
manner.
If software documentation is lacking, the inspector faces a number of initial
uncertainties while determining the best way of assuring the software product's
quality.
It is a challenging task for the inspector, since he/she might have to recover the
sought-for
software system first, redocument it, and then compare the newly created software
artifacts against their official counterparts in a bottom-up manner.
In case of inadequate software documentation, inspections need to be structured and
managed with respect to the structure of the idealized development process. To
establish
this, the logical relationship between typical software development artifacts
should be
investigated, and inspection should be focused on the compliance of those
relationships.
1.1. Objectives
Our concern is to improve defect detection performance. We concentrate our research
on seeking methods for systematic, rigorous static analysis of software that ensure
confidence in the thoroughness of the process and allow to reduce the process'
cost.
Therefore, our goal in this work is to investigate the effectiveness of existing
inspection
methods and techniques with respect to poorly documented software and, if needed,
to make suggestions improving the practice.
In creating a generic inspection process, numerous software engineering issues are
relevant for thorough research. Clearly, all of them cannot be covered by a single
study.
Our idea is to outline those that are crucial for achieving a “big picture” of the
problem
2
Chapter 1 – Introduction
under study. Some of the solutions proposed are experimentally evaluated, but most
of
the related issues are mentioned as potential candidates for separate research
topics
(see Section 6.3).
The work focuses on three main problems:
1) How to find an appropriate way of achieving (or assuring) quality of
incompletely
documented software
2) How to recover the sought-for software system's design, architecture and
requirements
from its implementation when particular (including intermediate) stages of the
development process are not documented and likely to be validated
3) How to make a rigorous static analysis of software more applicable and realistic
1.2. Overview of the thesis
To achieve the goals of this thesis, we first examine a sample program, analyze the
pros and cons of the applied inspection approaches, and finally, elaborate and
describe
a generic inspection framework for inspecting post-release software.
This work overviews inspection techniques, briefly describes those software
engineering issues that are relevant to the subject, presents in detail the
organizational and
procedural aspects of the framework proposed, and concludes with the inspection
materials produced during the practical evaluation of the applied inspection
technique.
The thesis consists of six chapters and two appendices:
􀀀 Chapter 1 introduces the background and research aims, and then outlines the
structure of the thesis.
􀀀 Chapter 2 presents basic definitions, a retrospective of software inspection
methods
and techniques, and a practical view of software inspection technology. This
chapter
also introduces the analysis of software inspection problems that need to be
resolved.
􀀀 Chapter 3 supplies the reader with some basic concepts and notations used for
documenting the software product itself and the process of its development.
This section observes both forward and reverse engineering principles within the
basis
of the proposed inspection framework.
􀀀 In Chapter 4, we investigate organizational and methodological issues concerning
the
inspection of incompletely documented software.
􀀀 Chapter 5 presents the framework for inspecting incompletely documented software
along with a detailed analysis of internal subprocesses found within an entire
inspection process. The reader is provided with a step-by-step description of a
generic
inspection process.
3
MASc Thesis – Michael Sharygin – McMaster – Software Engineering
􀀀 In Chapter 6, the work concludes with the results of the partially performed
experimental evaluation of the proposed inspection technique, lessons learned, and
suggestions for future work.
􀀀 Appendix A presents, in glossary form, the syntax, basic definitions, and
notational
conventions with respect to formal methods used (or assumed to be used) for
specifying software.
􀀀 Appendix B contains the inspection materials produced during the experiment. Due
to
the large amount of relevant documentation, this section of the thesis is presented
on
the attached compact disc.