SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY - PDF document

SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY COMPONENTS • Today we talk about software process quality and certification • Objective quality component: properties that can be Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department measured or approximated objectively • Subjective quality component: customer satisfaction (”What does the product feel like?”) • Other: features which can not be (even subjectively) evaluated at the time. This is related with future events which can not be predicted - unexpected circumstances, changes, etc. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se THE QUALITY SYSTEM THE QUALITY SYSTEM (cont’d) • Quality control - controlling the way things are done • The quality system of a company is simply the way the Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department company works and it covers all areas of activity. • Quality assurance - making sure quality is achieved • Quality policy • Therefore, a quality system always exists. It may be • Quality planning documented or not. • Quality improvement • However, in the long run in a big company it makes a major • These terms come from the standard ISO 8402 difference, if the management takes quality seriously and knowingly emphasizes it in all activities. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se QUALITY CONTROL QUALITY ASSURANCE • Improving software quality by monitoring the products Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department • Controlling the software development process (software) and process • Standards for the development process, e.g. - well-defined phases • Ensuring full compliance with the standards for products and - checklists process - reviews: what and when - organisational standards • Ensuring that any inadequacies in the product and process • Visibility and bookkeeping of the development process (and standards) are brought to management’s attention. • Standards for software code and documentation, e.g. - naming and style - document skeletons and formats - different kinds of review and feedback forms Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se 1

PROCESS QUALITY QUALITY ASSURANCE - METRICS PREREQUISITES • Top management commitment • Actual vs. estimated time and cost Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department • The quality assurance organisation must be independent from • Number of faults detected the development organisation. • Phase of the project when faults were found • The quality assurance organisation must be properly staffed. • Productivity (e.g. lines of code / man-month) • The quality assurance organisation must co-operate properly with the development organisation. Quality must be seen as a • Quality expenses (e.g. repairs required after delivery) common goal. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se QUALITY REVIEW TYPES A GENERAL SCHEME FOR REVIEWS • Design or program inspections/audits. These are commonly • Select the review team. Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department driven by a checklist of possible errors. • Arrange the place and time. • Management reviews. These are intended to provide information for the management about the overall progress of • Distributed the documents. the software project. • Hold the review. • Quality reviews. The work of an individual or a team is reviewed by a panel made up of project members and • Note the actions and complete the review forms. technical management. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se POSSIBLE ACTIONS FOR INSPECTIONS / AUDIT FINDINGS IN REVIEWS SESSIONS • No action. Some kind of an anomaly was found, but it was not • The ”Fagan method” - named after an IBM employee who Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department cost-effective to fix it. pioneered the technique • All types of defects are noted - not just logic or function errors. • Refer for repair. The team or individual in charge of the • Inspections can be carried out by collagues at all levels product has to correct the fault. except the very top. • Inspections are carried out using a predefined set of steps. • Reconsider the overall design. It may be more reasonable to • Inspection meetings do not last for more than two hours. fix other components of the system to solve the problem • The inspection is lead by a moderator who has a specific which was found. trainging in the technique. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se 2

INSPECTIONS / AUDIT A CHECKLIST FOR SESSIONS (continued) REVIEW EVALUATIONS • The other participants have defined roles. For example, one • Is material complete (and does it meet the standards)? Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department person will act as a recorder and note all defects found and • Was material distributed on time? another will act as a reader who takes the other participants • Are applicable standards referenced and available? through the document under inspection. • Were attendees prepared to contributed? • Checklists are used to assist the fault-finding process. • Did evaluation start on time? • Material should be inspected at an optimal rate of about 100 • Were number of defects identified? lines per hour. • Was review conducted per standard protocols? • Statistics are maintained so that the effectiveness of the • Were entrance criteria met? inspection process can be monitored. • Were exit criteria met? Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se A CHECKLIST FOR SOFTWARE QUALITY REVIEW EVALUATIONS CIRCLES (cont’d) • Are all issues scheduled for resolution? • A Japanese practice. Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department • Are interface issues coordinated? • Is disposition of all defects complete? • A quality circle is a group of four to ten volunteers working in the same area who meet for, say, an hour a week to identify, • Were HCI, testing, maintenance, and tools considered? analyse and solve their work-related problems. • Were quality attributes reported? • Has trace of defects been initiated? • One of the group is a group leader and one (maybe from outside) is a facilitator giving advice. • Training is required, and so is full support from the management. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se PROBLEM SOLVING BY SOFTWARE QUALITY ISO 9000 CIRCLES • Identify a list or problems and choose one. • Series of standards for general use in different fields of Jyrki Nummenmaa University of Tampere, CS Department Jyrki Nummenmaa University of Tampere, CS Department industry. • Clarify the problem. • ISO 9001 is for companies with product development and • Identify and evaluate the causes. production. • Identify and evaluate the solutions. • Separate certification organisations give certification for • Decide on the solution. companies which fulfill the requirements of the standards. • Develop an implementation plan. • Present the plan to the management. • Implement the plan. • Monitor the plan. • Consider wider apllicability of solution. • Restart from choosing another problem. Software Engineering – http://www.cs.uta.fi/se Software Engineering – http://www.cs.uta.fi/se 3