Next Topic: Software Quality Quality Attributes Weve Already Seen - PowerPoint PPT Presentation

☞ ☞ ☞ ✞ ✝ ✝ ✝ ✝ ✝ ✝ ✝ ☞ ☞ ☛ ✝ ✟ ✡ ✟ ☛ ✠ ☛ ☛ ✟ ☛ ✠ ☛ ☛ ✝ ✡ ✂ ✂ ✂ ✂ ✂ ✝ ✄ ✁ ☎ ✁ ☞ ✌ � ☞ ✆ Next Topic: Software Quality Quality Attributes We’ve Already Seen “Fundamental”: Plan (4 lectures): cohesion What is software quality? coupling Techniques for improving software quality information hiding “Derived”: Quality objectives Change control procedures readability modifiability Process guidelines and standards maintainability Reviews reusability Testing reliability/availability performance Reading : security Bahrami, chapter 13 (testing only) 1 2 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality Other Quality Attributes A Different Classification External (visible to end user) Satisfaction of requirements satisfaction of requirements performance Usability availability reliability The ease with which users can learn and use the security system testability Internal (visible to designer, coder, or tester) Testability Internal fundamental The degree to which you can test the system; the cohesion coupling degree to which you can verify that system meets information hiding requirements Internal derived readability modifiability maintainability reusability 3 4 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality

✏ ✓ ✓ ✍ ✍ ✔ ✓ ✎ ✓ ✒ ✎ ✑ ✎ ✑ ✏ ✎ Techniques for Improving Software You Can’t Have Them All Quality … also gives you more (+) or less (-) of this To achieve quality, ensure that high low info readabilit reusability maintaina relia/avail performa cohesion coupling hiding y bility nce T1) quality objectives are Lots of this … high + + + + cohesion stated explicitly and clearly low + + + + + - (layered, coupling pub/sub) measurable (as much as possible) info + + + + - (iterator) + - (iterator) hiding + T2) change control procedures are used readabilit + + - (façade) y + T3) software engineering guidelines and standards reusability + + (tested) - (adapter) - (Ariane) are used maintaina + + bility T4) reviews are conducted relia/avail + - a T5) testing is done performa - (direct - (direct - nce access) access) 5 6 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality T1: Clear and Measurable Quality T2: Change Control Procedures Objectives Achieving quality is impossible in presence of With clear and measurable objectives, uncontrolled changes to artifacts (e.g., requirements, people know what to look out for design, code, or test suites) quality is made a primary goal , rather than With change control procedures an afterthought artifacts more likely to be consistent changes are traceable ( people are more careful) changes to the quality assurance plan can be changes less likely to result in accidental loss evaluated accidental duplication of work less likely people more likely to be focused and easier to use time efficiently motivated Main change control procedure: Configuration management 7 8 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality

✜ ✙ ✘ ✢ ✙ ✙ ✘ ✙ ✙ ✤ ✗ ✤ ✢ ✢ ✚ ✣ ✛ ✢ ✤ ✙ ✗ ✗ ✕ ✗ ✗ ✗ ✕ ✖ T3: SW Engineering Guidelines and Configuration Management Standards Can be used to control changes to Documentation standards completeness design precision What to document? code traceability How to document? readability Version control software : Allows coders to Where to put documentation? modifiability avoid that a artifact is edited by more than one person (cycle: Coding standards check out, edit, check in; see MS’s “Sync & Save” process) Names easily get most recent copies of system artifact readability layout (indentation, etc) easily backtrack to previous version of a artifact modifiability easily get list of changes performed on a artifact (aka change etc history) not have to worry about backups artifact: source code, requirements, design, etc 9 10 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality SW Engineering Guidelines and SEI’s Capability Maturity Model (CMM) Standards (Cont’d) Assessed using an 85-item questionaire Process quality standards Used by government agencies and companies mostly in US 2 kinds Five-level scale of process maturity: Maturity models 1. CMM Level 1 (Initial) attempt to measure how well developed (mature) the Characteristics : chaotic; cost, schedule, and quality unpredictable software process in a particular organization is 2. CMM Level 2 (Repeatable) Example : Capability Maturity Model (CMM) Characteristics : intuitive; cost and quality highly variable; reasonable control Certification standards of schedules Key elements: requirements management; project planning; configuration measure an organization’s software process against a management; quality assurance procedure defined standard, and certify organization, if its process meets standard Example : ISO 9000 Source: Software Quality Assurance (CISC327). Jim Cordy. 2002 Source: Software Quality Assurance (CISC327). Jim Cordy. 2002 11 12 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality

✧ ✧ ✧ ✦ ✦ ✩ ★ ✧ ✧ ✧ ✧ ✧ ✧ ✥ ✧ ✧ ✧ ✧ ✧ ✧ ✧ ✧ ✧ ✧ ✧ ✦ ✧ ✩ ✥ Capability Maturity Model (Cont’d) ISO 9000 Standard 3. CMM Level 3 (Defined) ISO 9000 Characteristics: qualitative; reliable costs and schedules; improving, but Set of standards and guidelines for quality assurance unpredictable quality management Key elements: process definition and improvement; training program; Many customers, especially in Europe, require ISO 9000 peer reviews registration of their suppliers 4. CMM Level 4 (Managed) Companies become “registered” as result of formal audit by Characteristics: quantitative; reasonable statistical control over product the ISO quality ISO 9000-3 Key elements: process management and analysis, quality management 5. CMM Level 5 (Optimized) gives standards for software development, supply and maintenance Characteristics: quantitative basis for continual process automation and improvement specifies 20 elements to be assessed, with detailed Key elements: defect prevention; technology innovation; process requirements for each element change management Source: Software Quality Assurance (CISC327). Jim Cordy. 2002 Source: Software Quality Assurance (CISC327). Jim Cordy. 2002 13 14 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality ISO 9000-3 Elements T4: Reviews Inspection, measuring and Management responsibility At least 2 kinds: test equipment Quality system Inspection Contract review Inspection and test status Walkthrough Design control Control of nonconforming products Document control Corrective action Purchasing Handling, packaging, and delivery Quality records Purchaser-supplied product Internal quality audits Product identification and Training traceability Servicing Process control Inspection and testing Statistics 15 16 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality Source: Software Quality Assurance (CISC327). Jim Cordy. 2002

✫ ✫ ✭ ✬ ✬ ✬ ✭ ✭ ✭ ✫ ✫ ✪ ✫ ✫ ✭ ✫ ✭ ✪ ✪ ✭ Inspection Inspection Metrics To be classified as “inspection”, metrics must be kept "...a formal evaluation technique in which Record : software requirements, design, or code are which defects found in product under inspection examined in detail by a person or group other where defect was found in product than the author to detect faults, violations of time taken to perform inspection size of product inspected development standards, and other May also record: problems..." category of defect (e.g., major/minor) --- IEEE Standard Glossary of what prompted detection of defect Software Engineering Terminology suggested improvements 17 18 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality People Involved in Inspection Inspection Process Inspection is a team process : ideally 2-6 people Inspection leader: organizes & manages inspection process moderates meetings should have special training (multi-day course, certification) Checkers (inspectors): spend time reading/analyzing the product may include author(s), leader short training: 1-day course or "on the job" technical knowledge relating to product from Software Inspection , Tom Gilb & Dorothy Graham 19 20 CISC 323, Winter 2004, Software Quality CISC 323, Winter 2004, Software Quality