1 / 33

Quality Assurance & Standards

Quality Assurance & Standards. MechEng SE3 (non-)lecture 12 Slides by Phil Gray. Where to go for more…. Sommerville 7 th & 8 th Editions, Chap. 27 6 th Edition, Chap. 24. The Capability Maturity Model.

JasminFlorian
Download Presentation

Quality Assurance & Standards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quality Assurance & Standards MechEng SE3 (non-)lecture 12 Slides by Phil Gray

  2. Where to go for more… • Sommerville • 7th & 8th Editions, Chap. 27 • 6th Edition, Chap. 24

  3. The Capability Maturity Model • Description of the characteristic levels of quality in the software development process • Developed by the Carnegie Mellon Software Engineering Institute

  4. Initial Ad hoc, chaotic Repeatable Basic tracking processes Defined Document, standardised processes Managed Measures of process and product quality collected; process understood and controlled Optimizing Continuous process improved via feedback The Capability Maturity Model

  5. CMM and Quality • Key feature of CMM is centrality of process and product quality • How is this achieved? • Answer: Quality Assurance or QA

  6. What is Quality Assurance • From Software QA/Test Resource Center: ".. Software QA involves the entire software development process - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention' .. “

  7. Sommerville onQuality Assurance • for Sommerville: • Quality Assurance – framework of procedures and standards • Quality Plan – selection and adaptation of procedures and standards for a project • Quality Control – carrying out processes that ensure procedures and standards are followed • the term ‘Quality Assurance’ sometimes refers to all of the above

  8. What’s involved insoftware quality assurance? • At the level of an institution, company or standards body • Develop procedures and standards • Perform certification • to prove that the QA mechanism used is acceptable and effective • At the level of a particular project • Prepare a quality plan • specifying processes, deliverables, measures of quality (metrics, standards) • Carry out quality control • Collect data • So-called metrics • Compared to standards • Conducting reviews • checking reality against plan and against standards • At all levels • Change attitudes • convince staff that quality is important • develop a “quality culture”

  9. economic justification • Reported gains • up to 50% reduction in development time • 85% of faults removed via inspections (over 1 million lines of code) • 90% reduction in maintenance effort required • Costs • Typically 5-10% of development effort

  10. techniques for quality reviews • Progress review • Examination of progress with respect to plans • Quality review • Examination of project artefacts with respect to attributes of quality • Inspection • an FTR that tries to identify likely areas for faults and to identify lack of conformity to standards • Includes code walkthrough

  11. planning review preparation individual preparation review meeting re-work re-review follow-up stages of review process

  12. minimum 3, maximum 6 roles author moderator reader plus scribe QA staff specialists dependent developers maintainers review team

  13. review dos and don’ts • DO make it peer group review, applicable to all stages of software development • method of finding faults cheaply • method of training and learning • method of control • method of encouraging “egoless teamwork” • DON’T make it • a problem-solving session – faults should be identified, but solutions should not be patched together ‘in committee’ • a managerial appraisal of personnel

  14. standards for assessment • documents • structure • section numbering and title styles • spelling, grammar, style • accuracy and appropriateness of content • diagrams • semantic correctness • syntactic and lexical correctness (use of symbols, connectivity rules) • number of nodes per page

  15. standards for assessment 2 • programs • use of comments • indentation style • module length • completeness • consistency • cohesion and coupling • maintainability • N.B. these semantic standards difficult to measure

  16. code inspection guidelines • tracing requirements • check off each requirement against piece(s) of code • (possibly) provide a cross-reference of document tracing to the review team • can use code walkthrough • questioning assumptions • any assumptions not justified by the requirements? • sizes and volumes of data consistent with requirements

  17. code inspection guidelines 2 • program structure • program structure sensible? • data structures updated properly (wrt DFDs) • scoping • variables as tightly scoped as possible? • global variables used only where absolutely necessary? • local subprograms used where appropriate?

  18. code inspection guidelines 3 • optimisation / factoring • overlapping subprograms which can be combined? • opportunities for code re-use? • code optimised where needed to satisfy efficiency requirements? • algorithms • algorithm efficiency appropriate for data volume assumptions • standard algorithms / libraries used where appropriate

  19. code inspection guidelines 4 • description of functionality • links from requirements to code via design documents • adequate embedded comments

  20. reviewing the inspection process • statistics collected on • details of items inspected • list of faults found & classification • resources required for re-working • number of people involved & time • analysis provides • fault checklists • management reports on effectiveness of inspections • it’s the process being assessed, not the authors or inspectors

  21. What is a Standard? "A standard is a document approved by a recognized body, that provides, for common and repeated use, rules, guidelines, or characteristics for products, processes or services with which compliance is not mandatory.”A Guide to Project Management Body of Knowledge, 1996

  22. Standards Organisations • International Organization for Standardization (ISO) • non-governmental • develops standards for various technical fields (more than 11000) • 120 national members, which are themselves standards organisations

  23. Standards Organisations • BSI (UK) • ANSI (USA) • DIN (Germany) • ETSI (European) • IEC (International) • Other standard setting bodies • IET • BCS • EU • W3C • OMG

  24. Software Engineering/IT Standards • ISO/IET/EU have specific standards that can be used for measuring product and process quality • E.g., • ISO/IEC TR 14471:1999 : Information Technology – Software Engineering – Guidelines for the adoption of CASE tools • ISO 9241-1 Ergonomic requirements for office work with visual display terminals • W3C • Standard = “recommendation” • E.g., XML 1.1

  25. ISO 9000 • international standard for quality management and quality assurance • states what must be in a quality management system • first established in 1987 • derived from BS 5750, a British standard • ISO 9001 • applies to products involving design • Latest version is ISO 9001:2000 • 9001-3 interprets 9001 for software development

  26. ISO 9000 (cont’d) • certification is not carried out by ISO • carried out by independent certification bodies • organisation is awarded a Certificate of Conformity

  27. What’s in ISO 9000? • covers 20 topics, including • Quality System • Design Control • Process Control • Inspection & Testing • Contract Review • Quality Records • Internal Quality Audits • Training

  28. What’s in ISO 9000? (cont’d) • standard is abstract; it sets ends not means • for example, “The supplier shall establish and maintain a documented quality system as a means of ensuring that product confirms to specified requirements.” [from Section 4.2 of ISO 9001]

  29. TickIt • developed by DTI • provides a nationally accredited certification body • interpretation of ISO 9000 • related to ISO 9001-3

  30. TickIt (cont’d) • gives concrete guidelines on how software development should conform to the standard • based on developing a scheme of internal audits • audits related to standards compliance • auditors require training • audits involve document reviews and staff interviews

  31. QA Standards: A Good Thing? • pro • makes quality assurance assessable • as of 1993, 40 000 organisations in 93 countries have adopted the standard • US survey • 89% reported greater operational efficiency • 48% reported increased profitability

  32. QA Standards: A Good Thing? • con • fosters “command & control” style of management • emphasises inflexible compliance with a set of rigid written rules • standards rely heavily on assessors’ judgements • standards are not completely objective

  33. QA Standards: A Good Thing? • staff will pay attention to controls, not the things affected by the controls • attention to quality inspection and monitoring can deflect from attention to quality itself • like the problem of exams distorting education

More Related