Tools

This is part of the supporting fabric from our first book,ÂApplied Software Project Management, which was published by O’Reilly in 2005. Yous can encounter all of the material here: https://www.stellman-greene.com/applied-software-projection-management/

Contents

  • i Inspections
    • 1.1 Preparation
    • 1.2 Overview
    • 1.3 Page-by-page review
    • 1.4 Rework
    • i.5 Follow-upwards
    • 1.6 Approval
    • 1.7 Inspections in Outsourced Projects
  • 2 Deskchecks
  • 3 Walkthroughs
  • 4 Code Reviews
    • 4.1 Select the Code Sample
    • 4.two Hold the Review Session
    • 4.3 Code Review Checklist
      • iv.iii.1 Clarity
      • 4.iii.2 Maintainability
      • 4.3.3 Accuracy
      • 4.iii.iv Reliability and Robustness
      • 4.3.five Security
      • 4.3.vi Scalability
      • 4.3.7 Reusability
      • 4.3.8 Efficiency

Inspections

An inspection is one of the nigh common sorts of review institute in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a piece of work product and approve it for use in the projection. Ordinarily inspected work products include software requirements specifications (run into Chapter 6) and test plans (run into Affiliate 8). In an inspection, a work product is selected for review and a team is gathered for an inspection coming together to review the piece of work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the coming together by reading the work product and noting each defect. In an inspection, a defect is whatever part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with.

During the inspection meeting, a moderator leads the team page by page through a printed copy of the piece of work production. The purpose of the coming together is to identify and ready any defects. The moderator does not actually read each page out loud or give the team time to read the page. The team members read the document prior to the inspection, during their preparation. When the moderator goes through the document page by page, he simply asks the reviewers for their defects on page 1; one time those are done, he asks for the defects on folio 2 and continues through the rest of the certificate.

Prior to the inspection coming together, each team member should be given a checklist to aid them place defects. Checklists volition be different for unlike kinds of work products. (In other chapters, checklists will be included for each blazon of work production that should exist inspected.)

Name Inspection Meeting script
Purpose To run a moderated inspection coming together.
Summary In an inspection meeting, a moderator leads a team of reviewers in reviewing a work production and fixing any defects that are found.
Piece of work Products Input
Work product beingness inspected
Output
Inspection log
Entry Criteria A moderator must be selected, as well as team of three to 10 people. A piece of work product must be selected, and each team member has read it individually and identified all wording which must be changed or clarified before he or she volition approve the work product. A unique version number has been assigned to the work production.
 Basic Course of Events
  1. Preparation. The moderator distributes printed version of the work product (with line numbers) to each inspector, along with a checklist to aid in the review. Each inspector reads the work production and identifies whatsoever defects to be brought up at the coming together.
  2. Overview. The inspection meeting begins. The moderator verifies that each team member is prepared.
  3. Page-by-page review. The moderator runs through the work product page by page. Inspectors signal where there are defects. Each defect is either resolved or left as an open issue. The moderator adds each defect to the inspection log.
  4. Rework. The author repairs the defects identified in the inspection meeting.
  5. Follow-upwards. Inspection team members verify that the defects were repaired.
  6. Approval. The inspection team approves the work product.
 Alternative
Paths
  1. During step ii, if any team member has not read the piece of work production then the inspection is halted. The meeting is rescheduled and the script returns to step 1.
  2. During step 4, if an inspection team member discovers additional defects in the piece of work product then the moderator calls some other meeting and the process returns to step i.
 Leave Criteria The piece of work product has been approved.

Preparation

Each inspector reviews the printed re-create of the piece of work product individually prior to the inspection meeting. Any defects that are establish should be marked on the copy so that they can be brought up in the meeting.
In many organizations, moderator requires that each inspector submit a written listing of defects that were establish prior to the inspection meeting, and all defects are compiled into a unmarried inspection log and distributed to the unabridged inspection team. This optional step tin reduce the time required for the meeting considering instead of going through the unabridged work product page by page, the moderator simply goes through the log, and the writer and inspectors take fourth dimension to ready in accelerate to respond to the defects.

Overview

The moderator verifies that each inspection team fellow member has read the printed re-create of the work production. If any team member has not prepared, the inspection is aborted and rescheduled for a later date.

Page-past-page review

The moderator turns to the first page of the piece of work product and asks if anyone found whatsoever problems on that folio. Team members bring up each issue that they institute during their preparation. For each consequence, the moderator leads a discussion between the team and the author to identify new wording that will resolve the result. (For work products which are not text or documents, the team describes the change in sufficient detail and so that the repair of the defect is unambiguous to the author.) The team should come up up with the actual text which will be inserted into the document in society to fix the defect; the moderator should add this fix should to the inspection log. If the squad cannot come with a fix on the spot, or if give-and-take lasts more than than well-nigh 5 minutes, the moderator adds it to the inspection log as an open issue and assigns it to the team member who brought it upwardly (and anyone else who is involved) so they can work with the author to resolve information technology. Once all bug for the folio are discussed, the moderator moves to the side by side folio in the piece of work product.

Sample Inspection Log
Sample Inspection Log

Rework

After the inspection meeting is over, the author makes the changes in the inspection log and works with the inspection team members to resolve all open issues. When the changes are complete, the author turns the updated work product over to the moderator.

Follow-up

The moderator distributes the updated work product to the inspection team. Each team fellow member verifies that he can at present approve the work product. If at that place are any issues that cannot be resolved or additional defects which were not caught, he notifies the moderator, who calls some other inspection meeting and starts the inspection process again. One time the team gets through an inspection without any open bug and can agree on whatsoever changes that must exist fabricated, the work product tin can be updated and distributed for approval.

Approving

If whatsoever inspector feels that at that place are still farther bug raised by the corrections to the work production, another inspection coming together can exist held; yet, the project manager and author can too work individually with everyone involved to make sure that the changes are adequate. Once everyone on the squad feels that the changes they identified are acceptable, they can approve the updated work product without holding another inspection meeting.
The moderator adds a signature page to the piece of work product and distributes a printed version for signature approval. The signed work product is archived

Inspections in Outsourced Projects

Reviews in outsourced projects tin can be highly time-consuming; much more and then, in fact, than in an in-business firm project. In an in-business firm project, the team is already familiar with that detail organization’s standards, and there are commonly plenty of examples to piece of work from. The project managing director doesn’t need to spend nearly as much time making sure that the team understands the work beingness accomplished. What’s more than, an in-firm team normally understands the mission of the organisation and the needs of its users. Many project managers take this for granted, and don’t recollect to communicate these things to the vendor.  It requires constant effort and vigilance on the part of the project manager to brand sure that the needs are properly understood when moving work outside the organization. In addition to cognition transfer, reviews are also important tools for collaboration. It is important to encourage collaboration between the project team members at the vendor and the team members inside the system. When an inspection team is made up of people from both organizations, the only fashion for them to reach consensus on a piece of work production in order to approve information technology is to collaborate on identifying and fixing the defects in that work product. After the inspection, everyone has a better understanding of the work to be done, too as of how anybody else thinks about that work.

The script beneath is an inspection procedure that has been modified to exist used with an outsourced project. This script differs from the normal inspection procedure in that it does non require an inspection meeting. Instead, the inspectors gear up comments and transport them dorsum to the moderator, who consolidates them and works with individual inspectors to identify solutions that they all concord on. This requires much more than fourth dimension than a single inspection meeting because, instead of having one unmarried word about each defect, the moderator must have many unlike discussions with individual inspectors regarding each defect. Information technology also requires that the moderator who is selected take extensive familiarity and expertise with the work product existence inspected. This may hateful that the projection manager must serve as the moderator, but that’s not always the case.

Name Inspection script for apply in multiple organizations
Purpose To run a chastened inspection (without a meeting) for a team with members in unlike organizations
Summary In an inspection, a moderator leads a team of reviewers in reviewing a work product and fixing any defects that are found. The inspectors are in multiple organizations, so they never come across face to face.
Work Products Input
Work product being inspected
Output
Inspection log
Entry Criteria A moderator must be selected, besides as squad of three to ten people. A work product must be selected, and each team member has read it individually and identified all wording which must be changed or antiseptic before he or she will approve the piece of work product.
Basic Course of Events
  1. Preparation. The moderator distributes a printed or electronic version of the work product (with line numbers) to each inspector, along with a checklist to aid in the review. Each inspector reads the work product and identifies any defects that must be resolved, compiles those defects into a unmarried certificate, and returns it to the moderator.
  2. Compile the typhoon inspection log. Each list of defects returned past each inspector must be compared with the others, in order to identify and combine overlapping defects. The moderator compiles a draft of the inspection log that includes all distinct defects found by inspectors. The log does not yet contain whatever solutions to those defects.
  3. Place conflicts. The moderator searches for any defects reported by different inspectors which contradict each other. For each set of conflicting defects, the moderator holds a word (either in person or via teleconference or video conference, or using a collaboration tool like a mailing list or instant message organization) between the inspectors who identified those defects, in guild to identify the assumptions behind the defects and resolve them into a single defect. The inspection log is updated to reverberate the combined defects.
  4. Place solutions. The moderator uses the aforementioned ways to come across with individual inspectors to identify solutions to the defects and add those solutions to the inspection log. If more than than one person identified the same defect, they must all exist involved in creating the solution. Inspectors may likewise identify boosted defects which were not originally found, as well as their solutions.
  5. Compile and distribute inspection log. The moderator compiles all solutions identified in Footstep four into the inspection log. Any defects which were not resolved are left as open issues to exist resolved past the author. The moderator sends the final inspection log to all inspectors for confirmation. When the inspectors have confirmed that the log is correct, it is sent to the author of the work product.
  6. Rework. The author repairs the defects identified in the inspection meeting.
  7. Follow-upwardly. Inspection team members verify that the defects were repaired.
  8. Approval. The inspection squad approves the piece of work product.
 Alternative Paths
  1. During step five, if one or more team members notice errors in the inspection log, the moderator must address those errors before rework can occur. The script returns to step 2.
 Exit Criteria  The work production has been canonical.

Deskchecks

A deskcheck is a unproblematic review in which the writer of a work production distributes it to one or more than reviewers. In a deskcheck, the writer sends a copy of the work product to selected project team members. The team members read it, and then write upwards defects and comments to ship back to the author. Unlike an inspection, a deskcheck does non produce written logs which tin be archived with the certificate for later reference. There is no follow-upwards meeting or approval process. It is but a way for 1 team member to check another’southward piece of work. Deskchecks are non formal reviews (where “formal” simply means that it generates a written work production which meets a sure standard and is archived with the rest of the project documentation); there is no standard for the results of the deskcheck. The reviewers merely review the piece of work product and render the results. In that location is no moderator, and there is non necessarily whatsoever consensus generated.

There are times when a total inspection is neither necessary nor useful. Some piece of work products practise not benefit enough to warrant the attention of an entire inspection team because they do non need consensus or approval. In these cases, the author simply needs input from others to prevent defects, but does not require that they approve the document. In these cases, the deskcheck is a useful review practice.

The illustration beneath contains an case of comments from a deskcheck which was used by a tester to find defects in an automation script. In this example, the entire review was performed via e-mail: the writer mailed the script to the reviewer, and the reviewer read it and e-mailed the comments dorsum to the writer. These comments are much simpler than the inspection log in Figure 5-1. In an inspection, each log entry must either resolve a defect or bespeak that it is an open issue which must exist resolved. Deskcheck comments can but bespeak out issues or raise questions without having to supply solutions or promise a resolution. There was no follow-upwards or approving, and the reviewer had no more contact with this script.

Sample Deskcheck Comments
Sample Deskcheck Comments

Deskchecks can be used as predecessors to inspections. In many cases, having an author of a piece of work product laissez passer his work to a peer for an informal review will significantly reduce the corporeality of effort involved in the inspection. Many defects can be defenseless by a single person reviewing a document. Approval and consensus is congenital afterwards during the inspection meeting; this is simply a fashion of saving effort. Subsequently a deskcheck, many authors will feel much more than comfy sending their document into an inspectionâ€"it will often help the author to be more objective and to accept the inspection comments less personally.

Walkthroughs

A walkthrough is an informal way of presenting a technical certificate in a meeting. Dissimilar other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that anybody present understands the work product. It typically does non follow a rigid procedure; rather, the author presents the piece of work product to the audience in a style that makes sense. Many walkthroughs present the certificate using a slide presentation, where each section of a work product is shown using a set up of slides. Work products that are commonly reviewed using a walkthrough include design specifications and use cases.

Wakthroughs are used when the author of a work product needs to accept into account the perspective of someone who does non have the technical expertise to review the document. For example, a requirements analyst must make sure that the use cases she builds will provide the functionality that the users need, but the user representatives may non have seen utilize cases earlier and would exist overwhelmed by them. If these users are just included as part of an inspection team, it is probable that they will read the certificate and, failing to observe many defects, sit silently through the inspection meeting without contributing much. This is not their faultâ€"their training is in the business of the organization, not in reading and agreement software applied science documents. This is where a walkthrough tin be a useful technique to ensure that everyone understands the document.

Earlier the walkthrough, the author should distribute any material that will be presented to each person who volition be attending. For example, if the walkthrough is done equally a slide presentation, copies of the slides should be east-mailed to the attendees. If only a portion of that material is going to be covered, that should be indicated every bit well.

During the walkthrough meeting, the author should solicit feedback from the audience. This is an opportunity to begin new or alternative ideas, and to check that each person understands the document that is being presented. The writer should go through parts of the document to make sure that it was presented in as articulate a manner equally possible.

These guidelines tin can help an author pb a successful walkthrough meeting:

  • Verify that anybody is present who needs to review the work product. This could include users, stakeholders, engineering leads, managers and other interested people.
  • Verify that everyone present understands the purpose of the walkthrough meeting, and how the material is going to exist presented.
  • Describe each department of the material to be covered by the walkthrough.
  • Present the material in each section, ensuring that anybody nowadays understands the material being presented.
  • Pb word to identify missing whatever sections or material.
  • Document all issues that are raised by walkthrough attendees.

After the meeting, the author should follow up with private attendees who may have had boosted information or insights. The document should then be corrected to reflect any bug that were raised.

Code Reviews

A code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in information technology. In a code review, a defect is a block of lawmaking which does not properly implement its requirements, which does not function as the developer intended, or which is not incorrect but could exist improved (for example, it could be fabricated more than readable or its functioning could exist improved). In addition to helping teams find and set up bugs, lawmaking reviews are useful for both cross-grooming programmers on the code existence reviewed and for helping inferior developers larn new programming techniques.

Select the Lawmaking Sample

The first task in a lawmaking review is to select the sample of code to be inspected. It’due south impossible to review every line of code, so the programmers need to be selective about which portion of the code gets reviewed. Many teams accept plant that it takes about 2 hours to review 400 lines of code (in a high-level linguistic communication such as Coffee), although this approximate differs dramatically from team to team and depends on the complication of the code existence reviewed. At that charge per unit, there is no way a team could review all of the lawmaking for a software project. Nor would the team want toâ€"in any programme, in that location is a practiced deal of uninteresting lawmaking that looks very similar to the code already adult in previous applications, which has a lower risk of containing as many defects.

Hold the Review Session

The team pick and preparation in a code review are similar to any other kind of inspection. An inspection team of three to ten people must be selected. Each of these people must exist technically capable of reading and understanding the code existence reviewed. Before the meeting the moderator distributes the code sample to each inspector, who does individual preparation exactly every bit in the inspection.

The principal deviation between a code review and whatsoever other kind of inspection is in the review session. While code review session is similar to the inspection meeting (encounter “Page-past-page review” above), there are a few important differences:

  • Ane important difference is that in addition to the moderator, at that place is a code reader who reads the code aloud during the meeting. The purpose of the reader is merely to keep the team’southward place during the inspection; the team should take already read the code and identified defects during their preparation.
  • Some other of import deviation betwixt code reviews and certificate inspections is that the code review is much more focused on detecting defects, and less on fixing them.
  • In the code review, the moderator needs to be especially careful not to let the coming together turn into a trouble-solving session. Programmers dear to solve problems. It’s easy for them to become defenseless up in a small detail and turn the coming together into an analysis of a minute problem that covers just a few lines of code.

Code Review Checklist

The following attributes should exist verified during a lawmaking review:

Clarity

  • Is the code articulate and piece of cake to understand?
  • Did the programmer unnecessarily obfuscate any office of it?
  • Tin the lawmaking be refactored to make information technology clearer?

Maintainability

  • Will other programmers exist able to maintain this code?
  • Is information technology well-commented and documented properly?

Accuracy

  • Does the lawmaking accomplish what it is meant to practice?
  • If an algorithm is being implemented, is it implemented correctly?

Reliability and Robustness

  • Is the lawmaking fault-tolerant? Is it error-tolerant?
  • Will it handle abnormal conditions or malformed input?
  • Does it fail gracefully if it encounters an unexpected condition?

Security

  • Is the lawmaking vulnerable to unauthorized access or malicious use or modification?

Scalability

  • Could the lawmaking exist a bottleneck that prevents the organization from growing to accommodate increased load, data, users or input?

Reusability

  • Could this code be reused in other applications?
  • Tin can it be made more general?

Efficiency

  • Does the code brand efficient use of memory, CPU cycles, bandwidth or other system resource?
  • Can information technology be optimized?