1. Software Reviews
Ashima Wadhwa

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

3. 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

4. Need of Software Review

5. 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

6. Scheduling

7. Types of Review
In process Reviews
Phase end Reviews

8. In process Reviews Peer Reviews Walkthrough Inspection
In-process audits

9. 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

10. 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. 

11. 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.

12. 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.

13. 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.

14. 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

15. Inspection Log Example

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

17. In Process Reviews

18. 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.

19. 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?

20. 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

22. Documents required :

23. Document Reviews Peer Walkthrough Format Reviews Content Review
Algorithm Analysis

24. 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

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

26. 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.

27. 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.

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

29. Thank you!!