130 likes | 281 Views
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
E N D
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 4th 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 20th 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