1
play

1 QUALITY CONTROL QUALITY ASSURANCE Controlling the software - PDF document

Feb 28, 2024 •152 likes •228 views

SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY COMPONENTS Today we talk about software process quality and Objective quality component: properties that can certification be measured or approximated objectively

  1. SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY COMPONENTS • Today we talk about software process quality and • Objective quality component: properties that can certification be 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. 24.3.2004 Software Engineering 2004 1 24.3.2004 Software Engineering 2004 2 Jyrki Nummenmaa Jyrki Nummenmaa THE QUALITY SYSTEM THE QUALITY SYSTEM (cont’d) • Quality control - controlling the way things are • The quality system of a company is simply the way done the 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 documented or not. • Quality planning • Quality improvement • However, in the long run in a big company it makes a major difference, if the management • These terms come from the standard ISO 8402 takes quality seriously and knowingly emphasizes it in all activities. 24.3.2004 Software Engineering 2004 3 24.3.2004 Software Engineering 2004 4 Jyrki Nummenmaa Jyrki Nummenmaa 1

  2. QUALITY CONTROL QUALITY ASSURANCE • Controlling the software development process • Improving software quality by monitoring the products (software) and process • Standards for the development process, e.g. - well-defined phases - checklists • Ensuring full compliance with the standards for - reviews: what and when products and process - organisational standards • Visibility and bookkeeping of the development • Ensuring that any inadequacies in the product and process process (and standards) are brought to • Standards for software code and documentation, e.g. management’s attention. - naming and style - document skeletons and formats - different kinds of review and feedback forms 24.3.2004 Software Engineering 2004 5 24.3.2004 Software Engineering 2004 6 Jyrki Nummenmaa Jyrki Nummenmaa QUALITY ASSURANCE - PROCESS QUALITY METRICS PREREQUISITES • Top management commitment • Actual vs. estimated time and cost • The quality assurance organisation must be • Number of faults detected independent from 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- • Quality expenses (e.g. repairs required after operate properly with the development delivery) organisation. Quality must be seen as a common goal. 24.3.2004 Software Engineering 2004 7 24.3.2004 Software Engineering 2004 8 Jyrki Nummenmaa Jyrki Nummenmaa 2

  3. A GENERAL SCHEME FOR QUALITY REVIEW TYPES REVIEWS • Design or program inspections/audits. These are • Select the review team. commonly 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 • Distributed the documents. overall progress of 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 • Note the actions and complete the review forms. members and technical management. 24.3.2004 Software Engineering 2004 9 24.3.2004 Software Engineering 2004 10 Jyrki Nummenmaa Jyrki Nummenmaa POSSIBLE ACTIONS FOR INSPECTIONS / AUDIT SESSIONS FINDINGS IN REVIEWS • No action. Some kind of an anomaly was found, • The ”Fagan method” - named after an IBM but it was not cost-effective to fix it. employee who 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 product has to correct the fault. • Inspections can be carried out by collagues at all levels except the very top. • Inspections are carried out using a predefined set • Reconsider the overall design. It may be more of steps. reasonable to fix other components of the system to solve the problem which was found. • Inspection meetings do not last for more than two hours. • The inspection is lead by a moderator who has a specific trainging in the technique. 24.3.2004 Software Engineering 2004 11 24.3.2004 Software Engineering 2004 12 Jyrki Nummenmaa Jyrki Nummenmaa 3

  4. INSPECTIONS / AUDIT SESSIONS A CHECKLIST FOR (continued) REVIEW EVALUATIONS • The other participants have defined roles. For • Is material complete (and does it meet the example, one person will act as a recorder and standards)? note all defects found and another will act as a • Was material distributed on time? reader who takes the other participants through • Are applicable standards referenced and available? the document under inspection. • Were attendees prepared to contributed? • Checklists are used to assist the fault-finding • Did evaluation start on time? process. • Were number of defects identified? • Material should be inspected at an optimal rate of • Was review conducted per standard protocols? about 100 lines per hour. • Were entrance criteria met? • Statistics are maintained so that the effectiveness of the inspection process can be monitored. • Were exit criteria met? 24.3.2004 Software Engineering 2004 13 24.3.2004 Software Engineering 2004 14 Jyrki Nummenmaa Jyrki Nummenmaa A CHECKLIST FOR SOFTWARE QUALITY CIRCLES REVIEW EVALUATIONS (cont’d) • Are all issues scheduled for resolution? • A Japanese practice. • 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 • Were HCI, testing, maintenance, and tools hour a week to identify, analyse and solve their considered? 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. 24.3.2004 Software Engineering 2004 15 24.3.2004 Software Engineering 2004 16 Jyrki Nummenmaa Jyrki Nummenmaa 4

  5. PROBLEM SOLVING BY ISO 9000 SOFTWARE QUALITY CIRCLES • Identify a list or problems and choose one. • Series of standards for general use in different fields of industry. • Clarify the problem. • ISO 9001 is for companies with product • Identify and evaluate the causes. development and production. • Identify and evaluate the solutions. • Separate certification organisations give • Decide on the solution. certification for companies which fulfill the • Develop an implementation plan. requirements of the standards. • Present the plan to the management. • Implement the plan. • Monitor the plan. • Consider wider apllicability of solution. • Restart from choosing another problem. 24.3.2004 Software Engineering 2004 17 24.3.2004 Software Engineering 2004 18 Jyrki Nummenmaa Jyrki Nummenmaa INGREDIENTS OF ISO 9001 INGREDIENTS OF ISO 9001 (continued) • Management responsibility • Inspection, measuring and test equipment • Quality system • Inspection and test status • Contract review • Control of nonconforming product • Design control • Corrective action • Document control • Handling, storage, packaging and delivery • Purchasing • Quality records • Purchaser supplied control • Internal quality audits • Product identification adn traceability • Training • Process control • Servicing • Inspection and testing • Statistical techniques 24.3.2004 Software Engineering 2004 19 24.3.2004 Software Engineering 2004 20 Jyrki Nummenmaa Jyrki Nummenmaa 5

Recommend

More recommend