Software Project Management Lecture # 12

Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews  Formal Inspections & Technical Reviews  FTR & its features  Cost Impact of Software Defects  Defect Amplification & Removal  Formal Approaches to SQA

Software Quality Assurance (taken from 4 th Edition - Pressman) Conformance to …  the explicitly stated functional & performance requirements,  explicitly documented development standards &  implicit characteristics that are expected of all professionally developed software This definition emphasizes on 3 important points  S/W requirements – a foundation from which quality is measured  Standards – define development criteria against which S/W is engineered  Implicit requirements – often go unmentioned but if not met, can cause suspicion in quality

Who does it? Prior to 20 th Century  SQA was responsibility of the craftsperson During 1950s and 1960s  Responsibility of programmer Today responsible ones are …  S/W Engrs. (Apply technical methods & measures, Conduct FTRs & perform planned testing)  Project managers  Customers  Sales Person  SQA group (Serves as customer’s in-house representative, Looks at S/W from customer’s point of view, Assists the S/W Engrs team to achieve quality)

SQA Group & SQA Activities SQA group is responsible for QA planning, oversight, record keeping, analysis and reporting SEI recommends the following set of SQA group activities:  Prepares an SQA plan for project  Participates in the development of project’s software process description  Reviews s/w engg activities to verify compliance with defines s/w process  Audits designated s/w work products to verify compliance  Ensures that deviations in s/w work & work products are documented  Records any non compliance & reports to senior management SQA groups also participates in change management & help to collect & analyze s/w metrics

Software Reviews These are applied at various stages of software engg. process to identify errors that can be removed Hence they are a filter or purifier for software process Reviews are important as errors often go unnoticed by the originator. Others can catch them more easily. The idea is to use diverse people as reviewers to:  Point out improvements in a product  Confirm parts of product that do not need improvement  Achieve technical work of uniform or at least predictable quality

Formal Inspections & Technical Reviews Formal inspection is a formal & scheduled activity where a designer presents material about a design and a selected group of peers evaluate the tech. aspects of the design Formal inspection or Formal Technical Review (FTR) is an SQA activity Its objectives are:  To uncover errors in function, logic or implementation for any s/w  To verify s/w under review meets its requirements  To ensure that s/w complies to standards  To achieve a s/w developed in uniform manner  To make projects more manageable

FTR & its features FTR is conducted as a meeting and is a set of reviews including walk- throughs, inspections, round-robin reviews and technical assessments Its distinguishing features are:  Knowledgeable peers are used  The producer is an active participant  An explicit, completed work product is inspected  The primary purpose is to find defects  Specific roles are assigned  Specific inspection steps are used  At least 3 to 5 people are involved

Inspection Roles Moderator  Review leader  Selects the team  conducts inspections  Reports results Reader  Usually not the producer  Will guide the team through the work product during inspection Recorder  Maintains records of inspection and accurately reports each defect Producer  Who originally produced the product  He/she is required to answer questions during inspection  Responsible for correcting identified problems

FTR Steps FTR focuses on portion of the overall software. Rather than reviewing entire component, portions can be under focus Following are the FTR steps  Overview The producer gives an overview of the work product to acquaint the team with the product  Advanced Preparation Moderator give a copy of product details to each reviewer Each review team member studies his/her copy Base don product size, preparation time is decided, typically more than 2 hours per person A checklist is used to focus on significant issues  Inspection Meeting Moderator supervises the meeting Some approaches use a reader other than producer to conduct the inspection The producer/reader can explain material while reviewers raise issues based on their preparation

FTR Steps (contd.) Recorder maintains record of issues raised All team members sign the compiled review report Review meeting should be les than 2 hours long Decision made by all review members is made to  Accept  Reject  Provisionally accept  Rework The producer reviews the report and corrects the product  Follow up Moderator reviews report and corresponding corrections If satisfied, the inspection/review is completed If not, the moderator can make the producer rework and re- inspection can be scheduled

Review guidelines Review the product, not the producer Set an agenda and maintain it Limit debate and rebuttal Enunciate problem area but don’t attempt to solve every problem noted Take written notes Limit number of participants & insist on advanced preparation Develop a checklist for each product to be reviewed Allocate resources & schedule time for FTRs Conduct meaningful training of all reviwers Review your early reviews