Building a General PDE Solving Framework with Symbolic-Numeric Scientific Mac...
Static techniques
1. BY : YUSRAN
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 (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. 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. 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 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 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. 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. 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 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.