Assuring Software Quality

Objectives of Software Quality Reviews

• A review is basically some type of meeting.
• Software quality review is a type of review in which we examine a work product that is produced during the course of a project
• work product could be a project plan, a requirements document, a design document, code, a test plan
• The work product is a key component of a software quality review
• only be a few objectives for a software quality review
• identify any defects that exist in the work product, to remove the defect
• shouldn’t be used to share information, to inform stakeholders about what our strategy and direction are, to challenge project scope, to talk about project schedules or project, or anything else
• round-robin review
• work product is circulated around to a team of reviewers
• Each reviewer reviews the work product in isolation and makes comments
• Eventually, the document gets circulated back to the author.
• potential advantages of this review model are that reviewers can fit the review into their own schedule for the most part
• disadvantages of this review model are several: there is often a lack of consistency and rigor
• another potential disadvantage is that if the review team doesn’t provide timely feedback, the project schedule can be delayed
• And finally, in many reviews of this type the work product author is under no obligation to implement the reviewer comments
• informal walkthrough model
• walkthrough model is appropriate for all major project work products
• This review model is synchronous. The review team will meet in-person or virtually over the Internet
• formal inspection model
• more structured, rigorous, and formal than the walkthrough model
• industry best practice

Software Quality Reviews

• Effective use of quality reviews has shortened project schedules by 10 to 30 percent.
• Rework consists of unplanned repeating of tasks that were already performed
• All of those studies have found that the cost of finding and fixing defects increases over time in an exponential-like way.
• Performing software quality reviews can range from 5 percent to 15 percent of total project effort, depending upon the type of review process used and how many reviews need to be performed.
• In fact, unless reviews are effective they will add to the project cost and they will cause schedule increases.

Defect Detection & Repair Costs

• Error amplification is a phenomenon that exists on every single software project.
• Additional drivers are size and complexity.

Informal Walkthrough

• Used as a software quality review, the objectives of a walkthrough are to detect and remove defects in a work product, and to ensure that the work product meets its requirements.
• The review is implemented as a meeting, either in- person or virtual
• The work product author leads the review team through the work product, usually summarizing and paraphrasing chunks of material.
• Reviewers, who ideally have looked through the work product as part of their pre-review meeting preparation, can ask questions, make comments, and raise defect issues.
• The issues should be logged and resolved after the walkthrough meeting.
• In this model, the work product author acts as both a presenter, literally walking the review team through the work product, and also typically serves as the meeting facilitator.
• important guideline
• minimize the objectives to include only those mentioned earlier
• invite only those who can directly contribute to the review’s objectives
• communicate objectives and expectations in advance
• use a checklist to help reviewer focus attention
• limit review meeting time
• produce an issue list
• include a follow-up step
• log issues but limit discussion of solutions

Formal Inspection

• considered to be an industry best practice for finding defects in software work products
• Inspections have the highest defect detection rate of any defect identification technique
• average defect detection rates of 60-90 percent, whereas the more informal walkthrough model averages 30-60 percent
• There are specialized roles that some of the reviewers play
• there are more steps than just the inspection meeting
• there are rules for conducting
• the inspection meeting
• there is mandatory preparation and follow-up.
• Inspections require that some participants play specialized roles
• The moderator is responsible for ensuring that all the steps in the inspection process are followed and that all the inspection process rules are complied with
• The moderator is also responsible for facilitating the inspection meeting
• The author is responsible for answering questions posed by the inspection team, for providing clarifying information, and for resolving any issues for which he or she is the designated owner
• An issues list is a mandatory inspection work product, and the person assigned to play the role of recorder is responsible for logging the issues
• someone other than the author is selected to do walks the review team through the work product, presenter
• Anyone else on the inspection team falls into the category of general inspector.
• inspectors are relevant stakeholders and perhaps subject matter experts who evaluate the work product for defects and ensure the work product meets its requirement
• The steps help to give the inspection process structure and repeatability
• The kick-off step starts the inspection process for a given work product.
• The author and moderator meet to verify that the work product is ready for inspection, the inspection team is selected, and the inspection meeting is scheduled
• The moderator decides whether the overview step is necessary.
• The preparation step is a mandatory step in the inspection process, because advance preparation is essential if the inspection meeting is to be effective.
• Participants are also typically asked to record and report their preparation times.
• During the inspection meeting, the work product is presented, issues are logged, and the inspection outcome is determined.
• outcomes of an inspection meeting are defined in advance
• conditional acceptance, re-inspect, or the inspection is not yet finished and requires another meeting

Software Metrics

• A metric is a measurement of something.
• metrics can provide useful visibility into project status
• provide feedback to management, staff, and stakeholders
• Feedback may also be in the form of quality indicators
• Process metrics measure something associated with a process
• total effort spent on each phase in a project life cycle
• estimate of time remaining for project completion
• Product metrics measure something associated with a product
• Quality metrics measure something that is associated with the quality characteristics of a process or product
• Quality requirement’s visibility

Specifying & Measuring Software Quality

• At the top is the quality requirement that needs to be satisfied, such as testability
• The next level defines product or process attributes that lead to a product having that quality characteristic.
• Then, for each of the defined product and process attributes, one or more metrics is defined.
• Simplicity is a characteristic of a products design and code. Are they implemented in a straightforward manner.
• Self-descriptiveness also applies to the design and code. Are they easy to understand by visual inspection.
• Modular applies to the design and code as well. Is it easy to see which components of the product perform certain functions.
• Traceability has to do with the ease of relating test cases to the requirements that are being tested and to the specific product components that implement those requirements.
• Support has to do with the infrastructure that is in place to support the testing effort.

Sample Software Quality Metrics

• Coupling is a measure of inter-dependence between software components.
• Loose coupling is good. Tight coupling is not good.
• Cohesion is a measure of how single-purposed or well-defined a software component is.
• High cohesion is good. Low cohesion is not good.
• Cyclomatic complexity is a metric that measures how complicated the control flow logic for a software component is.
• Halstead’s Information Volume metric. how much information is contained in a software component based on a count of operators and operands.