participants gain some kind of advantage for their own work during reviewing. In

The reviewers
The task of the reviewers (also called checkers or inspectors) is to check any material
for defects, mostly prior to the meeting. The level of thoroughness required depends
on the type of review. The level of domain knowledge or technical expertise needed
by the reviewers also depends on the type of review. Reviewers should be chosen to
represent different perspectives and roles in the review process. In addition to the
document under review, the material reviewers receive includes source documents,
standards, checklists, etc. In general, the fewer source and reference documents
provided, the more domain expertise regarding the content of the document under
review is needed.
The manager
The manager is involved in the reviews as he or she decides on the execution of
reviews, allocates time in project schedules and determines whether review process
objectives have been met. The manager will ensure that any review training
requested by the participants takes place. Of course a manager can also be involved
in the review itself depending on his or her background, playing the role of a
reviewer if this would be helpful.
3.2.3 Types of review
A single document may be the subject of more than one review. If more than one
type of review is used, the order may vary. For example, an informal review may be
carried out before a technical review, or an inspection may be carried out on a
requirements specification before a walkthrough with customers. It is apparent that
none of the following types of review is the
‘winner’, but the different types serve
different purposes at different stages in the life cycle of a document.
The main review types, their main characteristics and common objectives are
described below.
Walkthrough
A walkthrough is characterized by the author of the document under review
guiding the participants through the document and his or her thought processes, to
achieve a common understanding and to gather feedback. This is especially useful if
people from outside the software discipline are present, who are not used to, or
cannot easily understand software development documents. The content of the
document is explained step by step by the author, to reach consensus on changes
or to gather information.
Within a walkthrough the author does most of the preparation. The participants, who
are selected from different departments and backgrounds, are not required to do a
detailed study of the documents in advance. Because of the way the meeting is
structured, a large number of people can participate and this larger audience can bring
a great number of diverse viewpoints regarding the contents of the document being
reviewed as well as serving an educational purpose. If the audience represents a
broad cross-section of skills and disciplines, it can give assurance that no major defects
are
‘missed’ in the walk-through. A walkthrough is especially useful for higher-level
documents, such as requirement specifications and architectural documents.
The specific goals of a walkthrough depend on its role in the creation of the
document. In general the following goals can be applicable:
Walkthrough A step-
by-step presentation by
the author of a document
in order to gather
information and to
establish a common
understanding of its
content.
Section 2 Review Process 59

l
to present the document to stakeholders both within and outside the software
discipline, in order to gather information regarding the topic covered by the
document:
l
to explain (knowledge transfer) and evaluate the contents of the document;
l
to establish a common understanding of the document;
l
to examine and discuss the validity of proposed solutions and the viability of
alternatives, establishing consensus.
Key characteristics of walkthroughs are:
l
The meeting is led by the author or authors; often a separate scribe is present.
l
Scenarios and dry runs may be used to validate the content.
l
Separate pre-meeting preparation for reviewers is optional.
Technical review
A technical review is a discussion meeting that focuses on achieving consensus
about the technical content of a document. Compared to inspections, technical
reviews are less formal and there is little or no focus on defect identification on
the basis of referenced documents, intended readership and rules. During technical
reviews defects are found by experts, who focus on the content of the document.
The experts that are needed for a technical review are, for example, architects, chief
designers and key users. In practice, technical reviews vary from quite informal to
very formal.
The goals of a technical review are to:
l
assess the value of technical concepts and alternatives in the product and project
environment;
l
establish consistency in the use and representation of technical concepts;
l
ensure, at an early stage, that technical concepts are used correctly;
l
inform participants of the technical content of the document.
Key characteristics of a technical review are:
l
It is a documented defect-detection process that involves peers and technical
experts.
l
It is often performed as a peer review without management participation.
l
Ideally it is led by a trained moderator, but possibly also by a technical expert.
l
A separate preparation is carried out during which the product is examined and
the defects are found.
l
More formal characteristics such as the use of checklists and a logging list or
issue log are optional.
Inspection
Inspection is the most formal review type. The document under inspection is prepared
and checked thoroughly by the reviewers before the meeting, comparing the work
product with its sources and other referenced documents, and using rules and check-
lists. In the inspection meeting the defects found are logged and any discussion is
postponed until the discussion phase. This makes the inspection meeting a very
efficient meeting.
Technical review A
peer group discussion
activity that focuses on
achieving consensus on
the technical approach to
be taken.
Peer review A review of
a software work product
by colleagues of the
producer of the product
for the purpose of
identifying defects and
improvements. Examples
are inspection, technical
review and walkthrough.
Inspection A type of
peer review that relies on
visual examination of
documents to detect
defects, e.g. violations of
development standards
and non-conformance to
higher level
documentation. The
most formal review
technique and therefore
always based on a
documented procedure.
60
Chapter 3 Static techniques

The reason for carrying out inspections can be explained by using Weinberg
’s
concept of egoless engineering [Weinberg 1971]. Weinberg refers to the human
tendency to self-justify actions. Since we tend not to see evidence that conflicts with
our strong beliefs, our ability to find errors in our own work is impaired. Because of
this tendency, many engineering organizations have established independent test
groups that specialize in finding defects. Similar principles have led to the introduc-
tion of inspections and reviews in general.
Depending on the organization and the objectives of a project, inspections can be
balanced to serve a number of goals. For example, if the time to market is extremely
important, the emphasis in inspections will be on efficiency. In a safety-critical market,
the focus will be on effectiveness.
The generally accepted goals of inspection are to:
l
help the author to improve the quality of the document under inspection;
l
remove defects efficiently, as early as possible;
l
improve product quality, by producing documents with a higher level of
quality;
l
create a common understanding by exchanging information among the
inspection participants;
l
train new employees in the organization
’s development process;
l
learn from defects found and improve processes in order to prevent recurrence
of similar defects;
l
sample a few pages or sections from a larger document in order to measure the
typical quality of the document, leading to improved work by individuals in
the future, and to process improvements.
Key characteristics of an inspection are:
l
It is usually led by a trained moderator (certainly not by the author).
l
It uses defined roles during the process.
l
It involves peers to examine the product.
l
Rules and checklists are used during the preparation phase.
l
A separate preparation is carried out during which the product is examined
and the defects are found.
l
The defects found are documented in a logging list or issue log.
l
A formal follow-up is carried out by the moderator applying exit
criteria.
l
Optionally, a causal analysis step is introduced to address process improvement
issues and learn from the defects found.
l
Metrics are gathered and analyzed to optimize the process.
3.2.4 Success factors for reviews
Implementing (formal) reviews is not easy as there is no one way to success and
there are numerous ways to fail. The next list contains a number of critical success
factors that improve the chances of success when implementing reviews. It aims to
answer the question,
‘How do you start (formal) reviews?’
Section 2 Review Process 61

Find a
‘champion’
A champion is needed, one who will lead the process on a project or organizational
level. They need expertise, enthusiasm and a practical mindset in order to guide
moderators and participants. The authority of this champion should be clear to the
entire organization. Management support is also essential for success. They should,
among other things, incorporate adequate time for review activities in project
schedules.
Pick things that really count
Select the documents for review that are most important in a project. Reviewing
highly critical, upstream documents like requirements and architecture will most
certainly show the benefits of the review process to the project. These invested
review hours will have a clear and high return on investment.
Pick the right techniques
In the previous subsection, we discussed a number of techniques, each of which has
its strengths and weaknesses, advantageous scenarios of use and disadvantageous
scenarios of use. You should be careful to select and use review techniques that will
best enable the achievement of the objectives of the project and the review itself.
Also, be sure to consider the type, importance, and risk level of the work product to
be reviewed, and the reviewers who will participate.
In addition make sure each review has a clear objective and the correct type of
review is selected that matches the defined objective. Don
’t try to review everything
by inspection; fit the review to the risk associated with the document. Some docu-
ments may only warrant an informal review and others will repay using inspection. Of
course it is also of utmost importance that the right people are involved.
Explicitly plan and track review activities
To ensure that reviews become part of the day-to-day activities, the hours to be
spent should be made visible within each project plan. The engineers involved are
prompted to schedule time for preparation and, very importantly, rework. Tracking
these hours will improve planning of the next review. As stated earlier, management
plays an important part in planning of review activities.
Train participants
It is important that training is provided in review techniques, especially the more
formal techniques, such as inspection. Otherwise the process is likely to be impeded
by those who don
’t understand the process and the reasoning behind it. Special
training should be provided to the moderators to prepare them for their critical role
in the review process.
Manage people issues
Reviews are about evaluating someone
’s document. Some reviews tend to get too
personal when they are not well managed by the moderator. People issues and
psychological aspects should be dealt with by the moderator and should be part of
the review training, thus making the review a positive experience for the author. During
the review, defects should be welcomed and expressed objectively. It is important that
all participants create and operate in an atmosphere of trust. Managers especially must
commit not to use metrics or other information from reviews for the evaluation of the
author or the participants.
62
Chapter 3 Static techniques

Follow the rules but keep it simple
Follow all the formal rules until you know why and how to modify them, but make
the process only as formal as the project culture or maturity level allows. Do not
become too theoretical or too detailed. Checklists and roles are recommended to
increase the effectiveness of defect identification.
Continuously improve process and tools
Continuous improvement of process and supporting tools (e.g. checklists), based
upon the ideas of participants, ensures the motivation of the engineers involved.
Motivation is the key to a successful change process. There should also be an
emphasis, in addition to defect finding, on learning and process improvement.
Report results
Report quantified results and benefits to all those involved as soon as possible, and
discuss the consequences of defects if they had not been found this early. Costs
should of course be tracked, but benefits, especially when problems don
’t occur in
the future, should be made visible by quantifying the benefits as well as the costs.
Use testers
As discussed in Chapter 1, testers are professional pessimists. This focus on what could
go wrong makes them good contributors to reviews, provided they observe the earlier
points about keeping the review experience a positive one. In addition to providing
valuable input to the review itself, testers who participate in reviews often learn about
the product. This supports earlier testing, one of the principles discussed in Chapter 1.
Just do it!
The process is simple but not easy. Every step of the process is clear, but experience
is needed to execute them correctly. So, try to get experienced people to observe and
help where possible. But most importantly, start doing reviews and start learning
from every review.
3 . 3
S T A T I C A N A L Y S I S B Y T O O L S
SYLLABUS LEARNING OBJECTIVES FOR
3.3 STATIC ANALYSIS BY TOOLS (K2)
LO-3.3.1 Recall typical defects and errors identified by static analysis
and compare them to reviews and dynamic testing. (K1)
LO-3.3.2 Describe, using examples, the typical benefits of static
analysis. (K2)
LO-3.3.3 List typical code and design defects that may be identified by
static analysis tools. (K1)
In this section, we
’ll focus on static analysis as a form of static testing. We’ll look at
ways to use tools to find defects effectively, efficiently, and very quickly using such
static analysis tools. We
’ll talk about the benefits and challenges of static analysis
Section 3 Static Analysis by Tools 63

using tools. As we go through this section, watch for the Syllabus terms compiler,
complexity, control flow, cyclomatic complexity, data flow, and static analysis.
You
’ll find these terms defined in the glossary.
There is much to be done examining software work products without actually
running the system. For example, we saw in the previous section that we can
carefully review requirements, designs, code, test plans and more, to find defects
and fix them before we deliver a product to a customer. In this section, we focus on
a different kind of static testing, where we carefully examine requirements, designs
and code, usually with automated assistance to ferret out additional defects before
the code is actually run. Thus, what is called static analysis is just another form of
testing.
Static analysis is an examination of requirements, design and code that differs
from more traditional dynamic testing in a number of important ways:
l
Static analysis is performed on requirements, design or code without actually
executing the software artefact being examined.
l
Static analysis is ideally performed before the types of formal review discussed in
Section 3.2.
l
Static analysis is unrelated to dynamic properties of the requirements, design
and code, such as test coverage.
l
The goal of static analysis is to find defects, whether or not they may cause
failures. As with reviews, static analysis finds defects rather than failures.
For static analysis there are many tools, and most of them focus on software code.
Static analysis tools are typically used by developers before, and sometimes during,
component and integration testing and by designers during software modelling. The
tools can show not only structural attributes (code metrics), such as depth of nesting or
cyclomatic complexity number and check against coding standards, but also graphic
depictions of control flow, data relationships and the number of distinct paths from one
line of code to another. Even the compiler can be considered a static analysis tool,
since it builds a symbol table, points out incorrect usage and checks for non-compliance
to coding language conventions (syntax). Additional static analysis features are often
available in compilers by setting the appropriate values at compilation time.
One of the reasons for using static analysis (to check coding standards and the
like) is related to the characteristics of the programming languages themselves. One
may think that the languages are safe to use, because at least the standards committee
knows where the problems are. But this would be wrong. Adding to the holes left by
the standardization process, programmers continue to report features of the language,
which though well-defined, lead to recognizable fault modes. By the end of the
1990s, approximately 700 of these additional problems had been identified in
standard C. It is now clear that such fault modes exist. It can be demonstrated that
they frequently escape the scrutiny of conventional dynamic testing, ending up in
commercial products. These problems can be found by using static analysis tools to
detect them. In fact, many of the 700 fault modes reported in C can be detected in
this way! In a typical C program, there is an average of approximately eight such
faults per 1000 lines of source code; they are embedded in the released code, just
waiting to cause the code to fail [Hatton 1997]. Dynamic testing simply did not
detect them. C is not the culprit here; this exercise can be carried out for other
languages with broadly the same results. All programming languages have problems
and programmers cannot assume that they are protected against them. And nothing in
Static analysis Analysis
of software artifacts, e.g.
requirements or code,
carried out without
execution of these
software development
artifacts. Static analysis is
usually carried out by
means of a supporting
tool.
Compiler A software
tool that translates
programs expressed in a
high order language into
their machine language
equivalents.
64
Chapter 3 Static techniques

the current international process of standardizing languages will prevent this from
happening in the future.
So, what kinds of defects can programmers find during static analysis of code?
That depends on the tool, but some typical defects include:
l
Referencing a variable with an undefined value (i.e. before the variable has
been properly initialized).
l
Inconsistent interfaces between modules and components, such as the improper
use of an object, method, or function, including the wrong parameters.
l
The improper declaration of variables, or the declaration of variables that are
never used.
l
Unreachable (
‘dead’) code that can safely be removed.
l
Certain types of missing or erroneous logic, such as potentially infinite loops.
l
Highly complex functions or other constructs (as will be discussed below).
l
Various types of programming standards violations, both violations that create
the risk of actual failures and violations that create long-term testability,
analyzability, and other code maintainability problems.
l
Security vulnerabilities, such as security problems related to buffer overflows
that are created by failing to check buffer length before copying into a buffer.
l
Syntax violations of code and software models (though these are often caught
by compilers).
When used to analyze code, static analysis tools are typically used by developers to
check for the kinds of problems mentioned above. This checking can occur during the
coding process, prior to code reviews, before and during component and integration
testing, or when checking code into the source code repository in the configuration
management system. In addition, system designers can use various kinds of model
validation and other static analysis tools during software modelling. Finally, various
kinds of static analysis and modelling tool are also available for requirements.
One thing to be aware of, when initiating the use of static code analysis, is that a very
large number of violations may lie hidden in the existing code base. When first used,
these static analysis tools can produce an enormous number of warning messages, many
of which turn out to be related to very low-risk situations. Therefore, our clients that
have succeeded with the introduction of these tools have employed careful management
strategies to deal with the volume of information. One strategy which works well is to
enforce the static analysis tools only for new and changed classes and/or functions. This
leads to a gradual, manageable, incremental improvement in the quality of the code over
the long-term without a spike in short-term code-clean-up tasks which can be risky in
their own right.
The various features of static analysis tools are discussed below, with a special
focus toward static code analysis tools since these are the most common in day-to-
day practice. Note that static analysis tools analyze software code, as well as
generated output such as HTML and XML.
3.3.1 Coding standards
Checking for adherence to coding standards is certainly the most well-known of all
features. The first action to be taken is to define or adopt a coding standard. Usually a
coding standard consists of a set of programming rules (e.g.
‘Always check boundaries
Section 3 Static Analysis by Tools 65

on an array when copying to that array
’), naming conventions (e.g. ‘Classes should start
with capital C
’) and layout specifications (e.g. ‘Indent 4 spaces’). It is recommended
that existing standards are adopted. The main advantage of this is that it saves a lot of
effort. An extra reason for adopting this approach is that if you take a well-known
coding standard there will probably be checking tools available that support this
standard. It can even be put the other way around: purchase a static code analyzer
and declare (a selection of) the rules in it as your coding standard. Without such tools,
the enforcement of a coding standard in an organization is likely to fail. There are three
main causes for this: the number of rules in a coding standard is usually so large that
nobody can remember them all; some context-sensitive rules that demand reviews of
several files are very hard to check by human beings; and if people spend time checking
coding standards in reviews, that will distract them from other defects they might
otherwise find, making the review process less effective.
3.3.2 Code metrics
As stated, when performing static code analysis, usually information is calculated
about structural attributes of the code, such as comment frequency, depth of nesting,
cyclomatic complexity number and number of lines of code. This information can
be computed not only as the design and code are being created but also as changes
are made to a system, to see if the design or code is becoming bigger, more complex
and more difficult to understand and maintain. The measurements also help us to
decide among several design alternatives, especially when redesigning portions of
existing code.
There are many different kinds of structural measures, each of which tells us
something about the effort required to write the code in the first place, to understand
the code when making a change, or to test the code using particular tools or techniques.
Experienced programmers know that 20% of the code will cause 80% of the
problems, and complexity analysis helps to find that all-important 20%, which relate
back to the principle of defect clustering as explained in Chapter 1. Complexity
metrics identify high risk, complex areas.
The cyclomatic complexity metric is based on the number of decisions in a
program. It is important to testers because it provides an indication of the amount
of testing (including reviews) necessary to detect a sufficient number of defects and to
have adequate confidence in the system. In other words, areas of code identified as
more complex are candidates for reviews and additional dynamic tests. While there
are many ways to calculate cyclomatic complexity, the easiest way is to sum the
number of binary decision statements (e.g. if, while, for, etc.) and add 1 to it. A more
formal definition regarding the calculation rules is provided in the glossary.
Below is a simple program as an example:
IF A = 354
THEN IF B > C
THEN A = B
ELSE A = C
ENDIF
ENDIF
Print A
The control flow generated from the program would look like Figure 3.2.
Complexity The degree
to which a component or
system has a design and/
or internal structure that
is difficult to understand,
maintain and verify.
Cyclomatic complexity
The number of
independent paths
through a program.
Cyclomatic complexity is
defined as:
L
– N + 2P, where
- L = the number of
edges/links in a
graph
- N = the number of
nodes in a graph
- P = the number of
disconnected parts
of the graph (e.g.
a called graph or
subroutine).
Control flow A
sequence of events
(paths) in the execution
through a component or
system.
66
Chapter 3 Static techniques

The control flow shows seven nodes (shapes) and eight edges (lines), thus using
the formal formula the cyclomatic complexity is 8
– 7 + 2 = 3. In this case there is
no called graph or subroutine. Alternatively one may calculate the cyclomatic
complexity using the decision points rule. Since there are two decision points, the
cyclomatic complexity is 2 + 1 = 3.
3.3.3 Code structure
There are many different kinds of structural measures, each of which tells us
something about the effort required to write the code in the first place, to understand
the code when making a change, or to test the code using particular tools or
techniques. It is often assumed that a large module takes longer to specify, design,
code and test than a smaller one. But in fact the code
’s structure plays a big part.
There are several aspects of code structure to consider:
l
control flow structure;
l
data flow structure;
l
data structure.
The control flow structure addresses the sequence in which the instructions are
executed. This aspect of structure reflects the iterations and loops in a program
’s
design. If only the size of a program is measured, no information is provided on how
often an instruction is executed as it is run. Control flow analysis can also be used to
identify unreachable (dead) code. In fact many of the code metrics relate to the
control flow structure, e.g. number of nested levels or cyclomatic complexity.
Data flow structure follows the trail of a data item as it is accessed and modified
by the code. Many times, the transactions applied to data are more complex than
the instructions that implement them. Thus, using data flow measures it is shown
how the data act as they are transformed by the program. Defects can be found
such as referencing a variable with an undefined value and variables that are
never used.

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: