3. Reviews in brief figures
• Cost of reviews is 10-15% of development budget
• Savings are about 14-25% (calculation includes
review efforts).
• More than 70% of defects in documents can be
found before they go to next work steps.
4. Review Objective and Types
Objective
• To decide if the review object has met the
requirements and complies with the standards, as
well as to find defects.
Major types of reviews:
• Reviews of tech products
• Project review aka Management review
8. Review Type: Walkthrough
• Informal procedure where author presents
document to reviewers (and chairs the meeting).
• Main focus is on meeting.
• Preparation is smallest among review types or
omitted; follow-up is optional.
• Suitable for small teams (<=10 members). Can be
used for checking ‘non-critical’ documents.
9. Review Type: Inspection
• Most formal review process – uses formal evaluation
criteria.
• Checklists with formal inspection criteria (entry- and
exit-criteria) are used.
• Focus: finding unclear points and possible defects,
measuring document quality, improving quality of
the product, development and inspection processes.
• Follow-up and re-inspection are formally regulated.
10. Review Type: Technical Review
• Focus: assessing document’s compliance with
specification, fitness for its intended purpose and
compliance to standards.
• Some of reviewers should not be project participants.
Management does not participate.
• Based on only ‘official’ specs and specified review tasks.
• Most effort lies in the preparation work.
• Review meeting normally not attended by author.
• Consequences of review result are decided by
management but not by review participants.
11. Review Type: Informal Review
• Follows general review procedure in a simplified way.
Usually initiated by author.
• Is a kind of cross-read of one or more colleagues.
• Examples: pair programming, buddy testing, code
swapping.
• Results should not be explicitly documented – a list
of remarks or revised document is enough.
• Very common review type. Takes little effort.
12. Static Analysis
• Commonly, only program code can be static-analyzed,
but sometimes there are also models (UML). Outputs in
e.g. XML or HTML can be static-analyzed as well.
• Only makes sense with support of tools – documents
must follow certain formal structure.
• Best practice is to perform it before review as it is
automated and so cheaper to perform.
• Usually practiced by developers in component (by coding
guidelines) and integration (by interface guidelines)
testing.
13. Flaws Detected by Static Analysis
• Syntax violation
• Deviation from conventions and standards
• Control flow anomalies
• Data flow anomalies
14. Data Flow Analysis
Variables can be defined (d), referenced (r) and
undefined (u).
Anomalies:
• ur – undefined then read or used
• du – defined then gets invalid or undefined without
use
• dd – defined twice without use of first value
15. Control Flow Analysis
• Cyclomatic (McCabe) number:
c(G) = e – n + 2
where e - graph edges,
n - graph nodes.
• If c(G) > 10 then rework of program code needed.
• c(G) specifies number of independent paths in the
program part.
• c(G) used to estimate testability & maintainability.
