Lecture Software process improvement: Lesson 2 provide students with knowledge about: software quality assurance; quality and its need; SQA tasks; SQA group skills and responsibilities; SQA reviews; SQA reporting;... Please refer to the detailed content of the lecture!
Software Quality Assurance Lecture # 2 SQA Lecture Agenda • • • • • Quality and its need SQA tasks SQA group skills and responsibilities SQA Reviews SQA Reporting Software Quality • Low levels of defects when deployed, ideally approaching zero • High reliability, or the capability of running without crashes or strange results Why Software Quality? 1 • Reduces time to market for new products • Enhances market share compared to direct competitors • Minimizes “scrap and rework” expenses • Attracts and keeps “topgun” personnel • Minimizes the risk of serious litigation Why Software Quality? 2 • Minimizes the risk of serious operating failures and delays • Minimizes the risk of bankruptcy or business failures, which may be attributed directly to poor quality or poor software quality Cost to Find and Fix a Defect 100 60.00100.00 log scale 10.00 10 1.00 0.75 1.50 3.00 test Design field system Req use code test Software Quality Assurance • So, there is a need for a active and independent group within every organization, who is devoted to assuring quality of software products • This group is called SQA Goals of SQA 1 • To improve software quality by appropriately monitoring both the software and development process that produces it • To ensure full compliance with the established standards and procedures for the software and the software process Goals of SQA 2 • To ensure that any inadequacies in the product, the process, or the standards are brought to management’s attention so they can be fixed SQA in pictorial form 10 Review Planning 1 • Distribute review package one week in advance – Document to be reviewed – Review agenda – Identification of the individual who will manage the agenda and schedule – Exit and entrance criteria for the review – Objective of the review 35 Review Planning 2 – Names of attendees, their roles and responsibilities – Review location – Date and time of review – List of classifications that will be used for defects discovered (defect type, defect origin, and defect severity) – Procedures for handling issues raised during the review and escalation phase 36 Review Meeting 1 • Facilitator begins the meeting with an introduction of agenda, people, and description of their roles • Author of the document proceeds to explain the materials, while reviewers raise issues based on advance preparation 37 Review Meeting 2 • When valid problems, issues, or defects are discovered, they are classified according to their origin or severity and then recorded • These are accompanied with the names of individuals who are responsible for resolution and the time frame during which the item will be resolved • Related recommendations are also recorded 38 Guidelines for Reviewers • Be prepared evaluate product before the review meeting • Review the product, not the producer • Keep your tone mild, ask questions instead of making accusations • Stick to the review agenda • Raise issues, don’t resolve them • Avoid discussions of style stick to technical correctness 39 Decisions at the End of a Review Meeting • All attendees must decide whether to – – – – Accept the product without further modification Reject the product due to severe errors Accept the product provisionally Hold a followup review session 40 Review Report 1 • Published by the recorder, with approval from all attendees, after a week of the review meeting • Review report consists of – Elements reviewed – Names of individuals who participated in the review – Specific inputs to the review 41 Review Report 2 – List of unresolved items – List of issues that need to be escalated to management – Action items/ownership/status – Suggested recommendations 42 Rework • It is the responsibility of project manager to ensure that all defects identified in the review are fixed and retested 43 FollowUp • During the followup, that all discrepancies identified are resolved and the exit criteria for the review have been met • Document lessons learned during the final report also 44 SQA Reporting 45 SQA Reporting 1 • SQA should not report to the project manager • SQA should report somewhere within the local office and division office • There should typically be no more than one management position between SQA and the senior location manager 46 SQA Reporting 2 • SQA should always have a “dottedline” relationship to a senior corporate quality executive • Whenever possible, SQA should report to someone who has a vested interest in software quality, like the staff head responsible for field service 47 Summary 48 References • Software Engineering 5th Edition by Roger Pressman, Chapter 8 • Inroads to Software Quality by Alka Jarvis and Vern Crandall, PH 1997 (Ch. 7) 49 ... To verify that the? ?software? ?under review meets its requirements • To ensure that the? ?software? ?has been represented according to predefined standards 22 Objectives of FTR ? ?2 • To achieve? ?software? ?that is developed in a ... established standards and procedures for the software? ?and the? ?software? ?process Goals of SQA ? ?2 • To ensure that any inadequacies in the product, the? ?process, or the standards are brought to management’s attention so they ... Statistical methods Quality control principles Software? ?process An ability to deal effectively with people in contentious situations 12 Role of SQA • The people responsible for the? ?software? ? projects are the only people who can be