1. Static techniques
BY : M.KHAIRIL
INFORMATION SYSTEM UIN SUSKA RIAU 2017
http://sif.uin-suska.ac.id
http://fst.uin-suska.ac.id
http://www.uin-suska.ac.id
2. REVIEWS AND THE TEST PROCESS
• static testing is a very suitable method for improving the
quality of software work products. This applies primarily to
the assessed products themselves, but it is also important
that the quality improvement is not achieved once but has
a more structural character. The feedback from the static
testing process to the development process allows for
process improvement, which supports the avoidance of
similar errors being made in the future.
3. REVIEW PROCESS
• Reviews vary from very informal to formal (i.e. well
structured and regulated). Although inspection is perhaps
the most documented and formal review tech-nique, it is
certainly not the only one. The formality of a review
process is related to factors such as the maturity of the
development process, any legal or regulatory requirements
or the need for an audit trail. In practice the informal
review is perhaps the most common type of review.
Informal reviews are applied at various times during the
early stages in the life cycle of a document.
4. Phases of a formal review
In contrast to informal reviews, formal reviews follow a formal
process. A typical formal review process consists of six main steps:
• Planning
• Kick-off
• Preparation
• Review meeting
• Rework
• Follow-up.
5. Planning
• The review process for a particular review begins with a
'request for review' by the author to the moderator (or
inspection leader). A moderator is often assigned to take
care of the scheduling (dates, time, place and invitation) of
the review. On a project level, the project planning needs
to allow time for review and rework activities, thus
providing engineers with time to thoroughly participate in
reviews.
6. Kick-off
• Role assignments, checking rate, the pages to be checked,
process changes and possible other questions are also
discussed during this meeting. Of course the distribution of
the document under review, source documents and other
related documentation, can also be done during the kick-
off.
7. Preparation
• The participants work individually on the document under
review using the related documents, procedures, rules and
checklists provided. The individual participants identify
defects, questions and comments, according to their
understanding of the document and role.
8. Review meeting
• The meeting typically consists of the following elements
(partly depending on the review type): logging phase,
discussion phase and decision phase.During the logging
phase the issues, e.g. defects, that have been identified
during the preparation are mentioned page by page,
reviewer by reviewer and are logged either by the author
or by a scribe.
9. Rework
• Based on the defects detected, the author will improve the
document under review step by step. Not every defect that
is found leads to rework. It is the author's responsibility to
judge if a defect has to be fixed. If nothing is done about an
issue for a certain reason, it should be reported to at least
indicate that the author has considered the issue.
10. Follow-up
• The moderator is responsible for ensuring that satisfactory
actions have been taken on all (logged) defects, process
improvement suggestions and change requests. Although
the moderator checks to make sure that the author has
taken action on all known defects, it is not necessary for
the moderator to check all the corrections in detail.
11. Roles and responsibilities
• The best formal reviews come from well-organized teams,
guided by trained moderators (or review leaders). Within a
review team, four types of participants can be
distinguished: moderator, author, scribe and reviewer. In
addition man-agement needs to play a role in the review
process.
12. The moderator
• The moderator (or review leader) leads the review process.
He or she deter-mines, in co-operation with the author, the
type of review, approach and the composition of the
review team. The moderator performs the entry check and
the follow- up on the rework, in order to control the quality
of the input and output of the review process. The
moderator also schedules the meeting, disseminates
documents before the meeting, coaches other team
members, paces the meeting, leads possible discussions
and stores the data that is collected.
13. The author
• As the writer of the document under review, the author's
basic goal should be to learn as much as possible with
regard to improving the quality of the document, but also
to improve his or her ability to write future documents.
The author's task is to illuminate unclear areas and to
understand the defects found.
14. The scribe
• During the logging meeting, the scribe (or recorder) has to
record each defect mentioned and any suggestions for
process improvement. In practice it is often the author
who plays this role, ensuring that the log is readable and
understand-able. If authors record their own defects, or at
least make their own notes in their own words, it helps
them to understand the log better during rework.
15. 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 tech-nical 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.
16. 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 also take care
of any review training requested by the participants. 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.
17. 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.
18. Technical review
• A technical review is a discussion meeting that focuses on
achieving con-sensus about the technical content of a
document. Compared to inspec-tions, technical reviews are
less formal and there is little or no focus on defect
identification on the basis of referenced documents,
intended read-ership and rules. During technical reviews
defects are found by experts, who focus on the content of
the document.
19. Inspection
• Inspection is the most formal review type. The document
under inspection is prepared and checked thoroughly by
the reviewers before the meeting, compar-ing the work
product with its sources and other referenced documents,
and using rules and checklists. 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.
