1 / 27

CSC-3325: Chapter 6

CSC-3325: Chapter 6. Title : The Software Quality Reading: I. Sommerville , Chap: 24. Topics covered. Software Quality management Process of quality assurance Quality reviews Software standards Software metrics Product quality metrics. Software quality management.

catalina-amora
Télécharger la présentation

CSC-3325: Chapter 6

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. CSC-3325: Chapter 6 Title : The Software Quality Reading: I. Sommerville, Chap: 24 Dr Driss Kettani, from I. Sommerville

  2. Topics covered • Software Quality management • Process of quality assurance • Quality reviews • Software standards • Software metrics • Product quality metrics Dr Driss Kettani, from I. Sommerville

  3. Software quality management • Concerned with ensuring that the required level of quality is achieved in a software product • Involves defining appropriate quality standards and procedures and ensuring that these are followed • Should aim to develop a ‘quality culture’ where quality is seen as everyone’s responsibility Dr Driss Kettani, from I. Sommerville

  4. What is quality? • In its simple understanding, Quality means that a product should meet its specification • This is problematical for software systems • Tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.) • Some quality requirements are difficult to specify in an unambiguous way • Software specifications are usually incomplete and often inconsistent Dr Driss Kettani, from I. Sommerville

  5. Software quality attributes Dr Driss Kettani, from I. Sommerville

  6. Quality management activities • Quality assurance • Establish organizational procedures and standards for quality • Quality planning • Select applicable procedures and standards for a particular project and modify these as required • Quality control • Ensure that procedures and standards are followed by the software development team Dr Driss Kettani, from I. Sommerville

  7. ISO 9000 • ISO 9000 is an iinternational set ofstandards for quality management in all industries … • Applicable to a range of organizations from manufacturing to service industries… • Each country has its own version… • ISO 9001 applicable to organizations which design, develop and maintain products… • It is a generic model of the quality process… Must be instantiated for each organization… • ISO 9000-3 interprets ISO 9000 for software engineering… Dr Driss Kettani, from I. Sommerville

  8. ISO 9000 certification • Quality standards and procedures should be documented in an organizational quality manual • External body may certify that anorganisation’s quality manual conforms to ISO 9000 standards • Customers are, increasingly, demanding that suppliers are ISO 9000 certified Dr Driss Kettani, from I. Sommerville

  9. ISO 9000 and quality management Dr Driss Kettani, from I. Sommerville

  10. Process quality assurance • The quality of a developed product is influenced by the quality of the production process • Particularly important in software development as some product quality attributes are hard to assess • However, there is a very complex and poorly understood relation between software processes and product quality… Dr Driss Kettani, from I. Sommerville

  11. Quality reviews • The principal method of validating the quality of a process or of a product • Group examined part or all of a process or system and its documentation to find potential problems • There are different types of review with different objectives • Inspections for defect removal (product) • Reviews for progress assessment(product and process) • Quality reviews (product and standards) Dr Driss Kettani, from I. Sommerville

  12. Quality reviews • Objective is the discovery of system defects and inconsistencies • Any documents produced in the process may be reviewed • Review teams should be relatively small and reviews should be fairly short • Review should be recorded and records maintained Dr Driss Kettani, from I. Sommerville

  13. Review results • Comments made during the review should be documented and classified: • No action. No change to the software or documentation is required. • Refer for repair. Designer or programmer should correct an identified fault. • Reconsider overall design. The problem identified in the review impacts other parts of the design. Some overall judgement must be made about the most cost-effective way of solving the problem. Dr Driss Kettani, from I. Sommerville

  14. Software standards • Key to effective quality management • May be international, national, organizational or project • Product standards define characteristics that all components should exhibit e.g. a common programming style • Process standards define how the software process should be conducted Dr Driss Kettani, from I. Sommerville

  15. Importance of standards • Encapsulation of best practice. Avoids repetition of past mistakes • Framework for QA process - it involves checking standard compliance • Provide continuity. New staff can understand the organisation by understand the standards applied Dr Driss Kettani, from I. Sommerville

  16. Problems with standards • Not seen as relevant and up-to-date by software engineers • Involve too much bureaucratic form filling • Unsupported by software tools and manual work is involved to maintain standards Dr Driss Kettani, from I. Sommerville

  17. Standards development • Involve practitioners in development • Engineers should understand the rationale underlying a standard • Review standards and their usage regularly. Standards can quickly become outdated and this reduces their credibility amongst practitioners • Detailed standards should have associated tool support. Excessive clerical work is the most significant complaint against standards Dr Driss Kettani, from I. Sommerville

  18. Software metrics • Any type of measurement which relates to a software system, process or related documentation • Lines of code in a program, number of person-days required to develop a component, the number of errors per module… • Allow the software and the software process to be quantified • Measures of the software process or product • Should be captured automatically if possible Dr Driss Kettani, from I. Sommerville

  19. Metrics assumptions • A software property can be measured • It isdifficult to relate what can be measured todesirable quality attributes • There is a relationship between what we can measure and what we want to know • This relationship has been formalized and validated Dr Driss Kettani, from I. Sommerville

  20. Internal and external attributes Dr Driss Kettani, from I. Sommerville

  21. Design Metrics • Cohesion • How closely are the parts of a component related • Coupling • How independent is a component • Understandability • How easy is it to understand a component’s function • Adaptability • How easy is to change a component Dr Driss Kettani, from I. Sommerville

  22. Validation of quality metrics The whole area is still a research area rather than practically applicable. Dr Driss Kettani, from I. Sommerville

  23. Programs quality metrics • Design metrics also applicable to programs • Other metrics include • Length. The size of the program source code • Cyclomatic complexity. The complexity of program control • Length of identifiers • Depth of conditional nesting • Anomalous metric values suggest a component may contain an above average number of defects or may be difficult to understand Dr Driss Kettani, from I. Sommerville

  24. Common Metrics for programs • Length of code is simple but experiments have suggested it is a good predictor of problems • Cyclomatic complexity can be misleading • Long names should increase program understandability • Deeply nested conditionals are hard to understand. May be a contributor to an understandability index Dr Driss Kettani, from I. Sommerville

  25. Problems with Metrics • Metrics still have a limited value and are not widely collected • Relationships between what we can measure and what we want to know are not well-understood • Lack of commonality across software process between organizations makes universal metrics difficult to develop Dr Driss Kettani, from I. Sommerville

  26. Key points • Software quality management is concerned with ensuring that software meets its required standards • Quality assurance procedures should be documented in an organisational quality manual • A project quality plan should identify project-specific quality requirements • Software standards are an encapsulation of best practice Dr Driss Kettani, from I. Sommerville

  27. Key points • Reviews are the principal means of implementing quality assurance • Metrics gather information about both process and product • Control metrics provide management information about the software project. Predictor metrics allow product attributes to be estimated • Quality metrics should be used to identify potentially problematical components Dr Driss Kettani, from I. Sommerville

More Related