1. Software Reviews

2. What is software reviews
Software reviews are a “quality improvement processes for written material”.
The process of examine the software product by project personnel’s managers users and customers is called software review process.
The term software product means any technical document which is developed to fulfill the needs of end user.

3. What is software reviews (Cont)
Examine the system as per the need of customer.
To ensure that the resultant product is up to the standards and satisfy all the goals described by end user.
The review process guarantee that all the requirements of the end user are available as per performing.

4. Objectives of Review Process
The basic objective of review process to provide help support to different phases of system like.
Verification and validation
Configuration management
Quality assurance
Project management
Systems engineering

5. Cycle of Review Process
Software review process is applicable on all phase of software development.
Project plans
Budget
Requirement documents
Specifications

6. Cycle of Review Process(Cont)
Design
Source code
Testing phases
Support and maintenance.

7. Examples of Software Products
Software design descriptions
Release notes
Software requirements specifications
Source code
Contracts
Installation plans
Progress reports

8. Review as Quality Improvement
Reviews can find % of all defects.
Reviews are technical, not management.
Review data can assess/improve quality of:
Work product.
Software development process.
Review process itself.

9. Review as Quality Improvement (Cont)
Reviews reduce total project cost
Early defect removal is times cheaper
Reviews distribute domain knowledge, development skills, and corporate culture.

10. Types of Review
Management Reviews
Technical Reviews
Inspections (Formal Peer Review)
Walk-throughs
Audits

11. Management Reviews Overview
Performed by those directly responsible for the system
Monitor progress
Determine status of plans and schedules
Confirm requirements and their system allocation

12. Management Reviews Outputs
Documented evidence that identifies:
Project under review
Review team members
Review objects
Software product reviewed
Inputs to the review
Action item status
List of defects identified by the review team .

13. Technical Reviews Overview
Confirms that product
Conforms to specifications
Adheres to regulations, standards, guidelines, plans
Changes are properly implemented
Changes affect only those system areas identified by the change specification

14. Technical Reviews Roles
The roles established for the technical review
Decision maker
Review leader
Recorder
Technical staff

15. Technical Reviews Outputs
Outputs, documented evidence that identifies:
Project under review
Review team members
Software product reviewed
Inputs to the review
Review objectives and status
List of resolved and unresolved software defects
List of unresolved system or hardware defects
List of management issues
Action item status .

16. Inspection (Formal Peer Reviews)
Confirms that the software product satisfies
Specifications
Specified quality attributes
regulations, standards, guidelines, plans
Identifies deviations from standard and specification

17. Inspections Roles The roles established for the Inspection
Moderator – Coordinates the inspection and leads the discussion
Producer – Responsible for the work being inspected
Reader – Paraphrases the work inspected
Inspector – Inspects the product
Recorder – Records problems discussed
Manager – Supervises the producer

18. Requirements Inspections
“If you can only afford to do one inspection on a project, you will get the biggest return on investment from a requirements inspection. A requirements inspection should be the one inspection that is never skipped.”
- Steven R. Rakitin

19. Why are Requirements Inspections Important?
Requirements are the most common source of problems in the development process
Requirements are written in English by people who typically have little or no training in writing software requirements
The English language is imprecise, ambiguous, and nondeterministic

20. Attributes of Good Requirements Specifications
Unambiguous
Complete
Verifiable
Consistent
Modifiable
Traceable
Usable

21. Requirements Inspection Objectives
Make sure each requirement in the Software Requirements Specification (SRS) is consistent and traceable to the document that preceded the SRS
Make sure each requirement in the SRS is clear, concise, internally consistent, unambiguous, and testable

22. Requirements Inspection Prerequisites
All inspection team members must receive appropriate training
The document(s) that preceded the SRS must have been reviewed and approved
The SRS must have been internally reviewed
A requirements inspection checklist must be available
Guidelines for a good SRS must be available

23. A Sample Inspection Process
Planning
Overview Meeting (optional)
Preparation
Inspection Meeting
Follow-up

24. Objectives of Planning
Determine which work products need to be inspected
Determine whether a work product is ready for inspection
Identify the inspection team
Determine whether an overview meeting is necessary
Schedule overview and inspection meetings

25. Objective of Overview Meeting
Educate the inspection team on the work product being inspected and discuss the review material

26. Objective of Preparation
To be prepared for the inspection meeting by critically reviewing the review materials and the work product

27. Objective of the Inspection Meeting
Identify errors and defects in the work product being inspected
An error is a problem in which the software or documentation does not meet defined requirements and is found at the point of origin
A defect is a problem in which the software or its documentation does not meet defined requirements and is found beyond the point of origin.

28. Objective of the Follow-Up
Assure that appropriate action has been taken to correct problems found during an inspection

30. Inspections Outputs Outputs, documented evidence that identifies:
Project under inspection
Inspection team members
Inspection meeting duration
Software product inspected
Size of the materials inspected
Inputs to inspection
Inspection objectives and status
Defect list (detail)
Defect summary list

31. Walk-throughs Evaluate a software product
Sometimes used for educating an audience
Major objectives:
Find anomalies
Improve the software product
Consider alternative implementations
Evaluate performance to standards and specs

32. Walk-throughs Roles The roles established for Walk-throughs
Walk-through leader
Recorder
Author
Team member

33. Walk-throughs Outputs
The outputs of the walk-through
Walk-through team members
Software product being evaluated
Statement of objectives and their status
Recommendations made regarding each anomaly
List of actions, due-dates, responsible parties
Recommendations how to dispose of unresolved anomalies

34. Audits
The purpose of an audit is to provide an independent evaluation of conformance of software products and processes to applicable;
Regulations
Standards
Guidelines
Plans
Procedures