Lectures Software Engineering - Chapter 24: Quality Management

54 trang hoanguyen 3950

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 24: Quality Management", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_24_quality_management.ppt

Nội dung text: Lectures Software Engineering - Chapter 24: Quality Management

Quality Management l Managing the quality of the software process and products ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 1
Objectives l To introduce the quality management process and key quality management activities l To explain the role of standards in quality management l To explain the concept of a software metric, predictor metrics and control metrics l To explain how measurement may be used in assessing software quality ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 2
Topics covered l Quality assurance and standards l Quality planning l Quality control l Software measurement and metrics ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 3
Software quality management l Concerned with ensuring that the required level of quality is achieved in a software product l Involves defining appropriate quality standards and procedures and ensuring that these are followed l Should aim to develop a ‘quality culture’ where quality is seen as everyone’s responsibility ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 4
What is quality? l Quality, simplistically, means that a product should meet its specification l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 5
The quality compromise l We cannot wait for specifications to improve before paying attention to quality management l Must put procedures into place to improve quality in spite of imperfect specification l Quality management is therefore not just concerned with reducing defects but also with other product qualities ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 6
Quality management activities l Quality assurance • Establish organisational procedures and standards for quality l Quality planning • Select applicable procedures and standards for a particular project and modify these as required l Quality control • Ensure that procedures and standards are followed by the software development team l Quality management should be separate from project management to ensure independence ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 7
ISO 9000 l International set ofstandards for quality management l Applicable to a range of organisations from manufacturing to service industries l ISO 9001 applicable to organisations which design, develop and maintain products l ISO 9001 is a generic model of the quality process Must be instantiated for each organisation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 9
ISO 9000 certification l Quality standards and procedures should be documented in an organisational quality manual l External body may certify that an organisation’s quality manual conforms to ISO 9000 standards l Customers are, increasingly, demanding that suppliers are ISO 9000 certified ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 11
Quality assurance and standards l Standards are the key to effective quality management l They may be international, national, organizational or project standards l Product standards define characteristics that all components should exhibit e.g. a common programming style l Process standards define how the software process should be enacted ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 13
Importance of standards l Encapsulation of best practice- avoids repetition of past mistakes l Framework for quality assurance process - it involves checking standard compliance l Provide continuity - new staff can understand the organisation by understand the standards applied ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 14
Problems with standards l Not seen as relevant and up-to-date by software engineers l Involve too much bureaucratic form filling l Unsupported by software tools so tedious manual work is involved to maintain standards ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 16
Standards development l Involve practitioners in development. Engineers should understand the rationale underlying a standard l Review standards and their usage regularly. Standards can quickly become outdated and this reduces their credibility amongst practitioners l Detailed standards should have associated tool support. Excessive clerical work is the most significant complaint against standards ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 17
Documentation standards l Particularly important - documents are the tangible manifestation of the software l Documentation process standards • How documents should be developed, validated and maintained l Document standards • Concerned with document contents, structure, and appearance l Document interchange standards • How documents are stored and interchanged between different documentation systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 18
Document standards l Document identification standards • How documents are uniquely identified l Document structure standards • Standard structure for project documents l Document presentation standards • Define fonts and styles, use of logos, etc. l Document update standards • Define how changes from previous versions are reflected in a document ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 20
Document interchange standards l Documents are produced using different systems and on different computers l Interchange standards allow electronic documents to be exchanged, mailed, etc. l Need for archiving. The lifetime of word processing systems may be much less than the lifetime of the software being documented l XML is an emerging standard for document interchange which will be widely supported in future ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 21
Process and product quality l The quality of a developed product is influenced by the quality of the production process l Particularly important in software development as some product quality attributes are hard to assess l However, there is a very complex and poorly understood between software processes and product quality ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 22
Process-based quality l Straightforward link between process and product in manufactured goods l More complex for software because: • The application of individual skills and experience is particularly imporant in software development • External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality l Care must be taken not to impose inappropriate process standards ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 23
Practical process quality l Define process standards such as how reviews should be conducted, configuration management, etc. l Monitor the development process to ensure that standards are being followed l Report on the process to project management and software procurer ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 25
Quality planning l A quality plan sets out the desired product qualities and how these are assessed ande define the most significant quality attributes l It should define the quality assessment process l It should set out which organisational standards should be applied and, if necessary, define new standards ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 26
Quality plan structure l Product introduction l Product plans l Process descriptions l Quality goals l Risks and risk management l Quality plans should be short, succinct documents • If they are too long, no-one will read them ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 27
Quality control l Checking the software development process to ensure that procedures and standards are being followed l Two approaches to quality control • Quality reviews • Automated software assessment and software measurement ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 29
Quality reviews l The principal method of validating the quality of a process or of a product l Group examined part or all of a process or system and its documentation to find potential problems l 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) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 30
Quality reviews l A group of people carefully examine part or all of a software system and its associated documentation. l Code, designs, specifications, test plans, standards, etc. can all be reviewed. l Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 32
Review functions l Quality function - they are part of the general quality management process l Project management function - they provide information for project managers l Training and communication function - product knowledge is passed between development team members ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 34
Quality reviews l Objective is the discovery of system defects and inconsistencies l Any documents produced in the process may be reviewed l Review teams should be relatively small and reviews should be fairly short l Review should be recorded and records maintained ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 35
Review results l Comments made during the review should be 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. l Requirements and specification errors may have to be referred to the client. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 36
Software measurement and metrics l Software measurement is concerned with deriving a numeric value for an attribute of a software product or process l This allows for objective comparisons between techniques and processes l Although some companies have introduced measurment programmes, the systematic use of measurement is still uncommon l There are few standards in this area ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 37
Software metric l Any type of measurement which relates to a software system, process or related documentation • Lines of code in a program, the Fog index, number of person- days required to develop a component l Allow the software and the software process to be quantified l Measures of the software process or product l May be used to predict product attributes or to control the software process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 38
Metrics assumptions l A software property can be measured l The relationship exists between what we can measure and what we want to know l This relationship has been formalized and validated l It may be difficult to relate what can be measured to desirable quality attributes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 40
The measurement process l A software measurement process may be part of a quality control process l Data collected during this process should be maintained as an organisational resource l Once a measurement database has been established, comparisons across projects become possible ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 42
Data collection l A metrics programme should be based on a set of product and process data l Data should be collected immediately (not in retrospect) and, if possible, automatically l Three types of automatic data collection • Static product analysis • Dynamic product analysis • Process data collation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 44
Data accuracy l Don’t collect unnecessary data • The questions to be answered should be decided in advance and the required data identified l Tell people why the data is being collected • It should not be part of personnel evaluation l Don’t rely on memory • Collect data when it is generated not after a project has finished ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 46
Product metrics l A quality metric should be a predictor of product quality l Classes of product metric • Dynamic metrics which are collected by measurements made of a program in execution • Static metrics which are collected by measurements made of the system representations • Dynamic metrics help assess efficiency and reliability; static metrics help assess complexity, understandability and maintainability ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 47
Dynamic and static metrics l Dynamic metrics are closely related to software quality attributes • It is relatively easy to measure the response time of a system (performance attribute) or the number of failures (reliability attribute) l Static metrics have an indirect relationship with quality attributes • You need to try and derive a relationship between these metrics and properties such as complexity, understandability and maintainability ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 48
Measurement analysis l It is not always obvious what data means • Analysing collected data is very difficult l Professional statisticians should be consulted if available l Data analysis must take local circumstances into account ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 51
Measurement surprises l Reducing the number of faults in a program leads to an increased number of help desk calls • The program is now thought of as more reliable and so has a wider more diverse market. The percentage of users who call the help desk may have decreased but the total may increase • A more reliable system is used in a different way from a system where users work around the faults. This leads to more help desk calls ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 52
Key points l Software quality management is concerned with ensuring that software meets its required standards l Quality assurance procedures should be documented in an organisational quality manual l Software standards are an encapsulation of best practice l Reviews are the most widely used approach for assessing software quality ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 53
Key points l Software measurement gathers information about both the software process and the software product l Product quality metrics should be used to identify potentially problematical components l There are no standardised and universally applicable software metrics ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 54