Software Reviews Ashima Wadhwa

Reviews A review is any activity in which a work product is distributed to reviewers who examine it and give feedback.

Need of Software Review Reviews are useful not only for finding and eliminating defects, but also for gaining consensus among the project team, securing approval from stakeholders, and aiding in professional development for team members. Reviews help teams to find defects soon after they are injected making them cost less to fix than they would cost if they were found in test. All work products in a software project should be either reviewed or tested

Need of Software Review

Objectives To uncover errors in function, logic, or implementation for any representation of the software To verify that the software under review meets its requirements To ensure that the software has been represented according to predefined standards To achieve software that is developed in a uniform manner To make projects more manageable Serves as a training ground for junior software engineers to observe different approaches to software analysis, design, and construction Promotes backup and continuity because a number of people become familiar with other parts of the software

Scheduling

Types of Review In process Reviews Phase end Reviews

In process Reviews Peer Reviews Walkthrough Inspection In-process audits

Phase End Reviews SRR -Software Requirement Review PDR- Preliminary Design Review CDR-Critical Design Review TDR-Test Readiness Review Formal Audits PIR- Post Implementation Review

Peer Reviews Peer review is the evaluation of work by one or more people of similar competence to the producers of the work .It constitutes a form of self-regulation by qualified members of a profession within the relevant field. 

Peer Reviews When performed as part of each Software development process activity, peer reviews identify problems that can be fixed early in the life cycle. That is to say, a peer review that identifies a requirements problem during the Requirements analysis activity is cheaper and easier to fix than during the Software architecture or Software testing activities.

Walkthrough A walkthrough is an informal way of presenting a technical document in a meeting. Unlike other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that everyone present understands the work product. Walkthroughs are used when the author of a work product needs to take into account the perspective of someone who does not have the technical expertise to review the document. After the meeting, the author should follow up with individual attendees who may have had additional information or insights. The document should then be corrected to reflect any issues that were raised.

Inspections Inspections are moderated meetings in which reviewers list all issues and defects they have found in the document and log them so that they can be addressed by the author . The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product.

Inspection Process Running an inspection meeting: A work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. Discussion is focused on each defect, and coming up with a specific resolution. It’s the job of the inspection team to do more than just identify the problems; they must also come up with the solutions. The moderator compiles all of the defect resolutions into an inspection log

Inspection Log Example

In-Process Audits Audit of all notes and materials All phase of SDLC Predefine format /structure Informal

In Process Reviews

Phase End Review A formal review held at the end of each project phase to gain consensus that the phase is complete. Identify process improvements The required outcome from the review is to receive authorization to continue to the next phase or close out the project if it is in its final phase.

The objectives of the review are: Verify that phase objectives have been met Verify phase exit criteria Evaluate phase performance in terms of: Has the schedule been met? Has the required scope been delivered? Do planned costs equal actual costs?

Phase End Reviews SRR -Software Requirement Review PDR- Preliminary Design Review CDR-Critical Design Review TDR-Test Readiness Review Formal Audits PIR- Post Implementation Review

Documents required :

Document Reviews Peer Walkthrough Format Reviews Content Review Algorithm Analysis

Requirement Review Requirement review intend to show that following aspects related to problem to be solved are spelled out: Necessity Feasibility Correctness Completeness Clarity Testability Measurability

Design Review Design Review verifies that the evolving design is both correct and traceable back to approved requirements through: Walkthrough Inspection PDR CDR

Test Documentation Review Test documentation is reviewed to ensure that the test program will find defects and will test the software against its requirements. Unit, Module, Integration, Subsystem, Acceptance test are planned ,documented and reviewed before execution.

User Documentation Review User Documentation not only provide the information about the system ,it must be meaningful to the reader. A critical step in this review is actual trial use of the documentation by one or more actual user before the document is released.

Other Documentation Review Software Development Plan Software quality system Plan Configuration Management Plan

Thank you!!