About Us


  Process Models

  SE Resources


  Contact us

Breaking News!

A new blog ...

visit OnCenter, Roger Pressman's running commentary on the world at large

A new edition ... the 7th edition of Software Engineering is available now

A new book ... Roger Pressman and David Lowe on Web Engineering

A first novel ... Roger Pressman's first novel is a technothriller -- The Aymara Bridge

A new curriculum! RSP&A has partnered with QAI to develop a comprehensive Internet-based software engineering curriculum.

A redesigned site! ... we've done a major redesign and added many new features for 2009 - 2010

Adaptable Process Model
Umbrella Task 2
Formal Technical Reviews

IMPORTANT NOTICE: The complete Adaptable Process Model (APM) is provided for informational purposes and for assessment by potential users. The APM is copyrighted material and may not be downloaded, copied, or extracted for use in actual project work. The full hypertext (html) version of the APM may be licensed for use and customization within your organization. Contact R.S. Pressman & Associates, Inc. for complete licensing information.

Umbrella Task 2. Formal Technical Reviews

U.2.1 Establish a review strategy before completing the project plan.

U.2.1.1 Select an appropriate set of review guidelines as part of the SQA plan developed in Task U.1.13.

U.2.1.2 Identify review points for the project.

U.2.1.3 Schedule review points as project tasks.

The project manager and staff should select review points for the project. Questions answered include: Where in the process flow should reviews be conducted? How many reviews should be conducted for each CPF activity? The project plan/schedule should identify review points explicitly and should allocate effort and duration to each. In addition, the plan should allocate effort to the work required to respond to issues uncovered during review.


U.2.2 Initiate formal technical reviews as project deliverables are produced.

Formal technical reviews are conducted as deliverables are produced. In essence, the reviews become SQA "exit conditions" for movement to the next CPF activities and tasks.

U.2.3 Conduct a formal technical review to uncover errors in a software engineering deliverable.

U.2.3.1 Assign a review leader to coordinate the review.

U.2.3.2 Distribute review materials [work product(s)] to reviewers.

U.2.3.2 Set the review agenda and select appropriate checklists.

U.2.3.3 Review work product(s) to uncover errors.

U.2.3.4 Conduct the review meeting.

U.2.3.5 Record any errors and/or issues that are raised during the review meeting.

U.2.3.6 Decide the outcome of the review.

U.2.3.7 Ensure that proper review records are kept.

U.2.3.8 Collect any defined metrics for the review.

Intent: The intent of this task is to uncover errors in any work product produced as a consequence of a software engineering task

Mechanics: See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, p. 328 - 334.

Application of Formal Methods: walkthrough or inspection approach

Application of CASE Tools: t.b.d.

SQA Checklist:

    1. Are reviews scheduled as part of the project timeline?

    2. Have review team members prepared in advance?

    3. Are written records maintained for each review?

Do’s & Don’ts

    Do: Review small work products, not massive deliverables. The review should generally take no more that 60 - 90 minutes.

    Do: Train team members in review technique and psychology before conducting reviews.

    Do: Keep the tone light.

    Don’t: Tolerate people who will not prepare in advance. They must.

    Don’t: Review the person. Review the product.

    Don’t: Let reviews turn into a personnel appraisal.

Helpful Hints

Reviews are actually a technical meeting. Therefore, if you avoid the problems that cause meeting to fail, you’ll avoid the problems that cause reviews to fail. Be sure that you have an agenda before starting the review. Be certain that you define a strong review leader. Take notes. Don’t let the review turn into a problem solving session. The purpose of a formal technical review is to uncover errors, not necessarily to resolve them.


1. Technical review summary report

2. Issues list


U.2.4 Evaluate review results on a regular basis.

The project team should "debrief" on reviews regularly in an effort to improve the review approach.

Use Browser "back" arrow or return to APM Process Design Language Description


Site search! We've added links to a search engine that will enable you to search our entire site for information you need. Enter the appropriate word or phrase below.


Home About us Products Product Models SE Resources Commentary Contact us

Web site and all contents © R.S. Pressman & Associates, Inc. 2001 - 2010, All rights reserved.
Free website templates