Why reviews are known to be cost effective.
Any document can be reviewd. For instance, requirements specifications, design specifications, code, test plans, user guides, etc. Ideally review as soon as possible.
Costs - on-going review costs of approx. 15% of development budget. The cost of reviews includes activities such as trhe review process itself, metrics analysis and process development.
Benefits - include areas such as development productivity improvements, reduced development time-scales, testing cost and time reductions, lifetime cost reductions, reduced fault levels, etc.
Explain similarities/differences between walktrhoughs, inspections, informal reviews, and technical reviews, where each can be identified by the following attributes:
Walkthroughs - scenarios, dry runs, peer group, led by author.
Inspections - led by trained moderator (not author), defined roles, includes metrics, formal process based on rules and checklists with entry and exit criteria.
Informal reviews - undocumented, but useful, cheap, widely-used.
Technical reviews (also known as peer reviews) - documented, defined fault-detection process, includes peers and technical experts, no management participation.
Goals - validation and verification against specifications and standards, (and process improvement). Achieve consensus.
Activities - planning, overview meeting, preparation, review meeting, and follow-up (or similar).
Roles and responsibilities - moderators, authors, reviewers/inspectors and managers (planning activities).
Deliverables - product changes, source document changes, and improvements (both review and development).
Pitfalls - lack of training, lack of documentation, lack of management support (and failure to improve process).
Explain that static analysis involves no dynamic execution and can detect possible faults such as unreachable code, undeclared variables, parameter type mismatches, uncalled functions and procedures, possibe array bound violations, etc.
Explain that any faults found by compilers are found by static analysis. Compilers find faults in the syntax. Many compilers also provide information on variable use, which is useful during maintenance.
Explain that data flow analysis considers the use of data on paths through the code, looking for possible anomalies, such as "definitions" with no intervening "use", and "use" of a variable after it is "killed".
Explain use of, and provide example of production of control flow graph for a program.
Introduce complexity metrics, including cyclomatic complexity.
This page is very heavily based on the ISEB Foundation Certificate Syllabus.
This is unavoidable, as to pass the exam, you have to use their terminology.
Back to top Next Home Serious Stuff
© 2002. Copyright Sue Nethercott.