Software Product Quality - Part 1 Presentation
Download as PPT, PDF0 likes429 views
The document discusses software product quality and its critical importance in managing software projects, highlighting how errors become more costly to rectify later in the development process. It outlines ISO standards such as ISO 9126, which specifies attributes of software quality, including functionality, reliability, usability, and maintainability, along with guidelines for measuring these quality characteristics. Additionally, it emphasizes the necessity of defining entry, implementation, and exit requirements for activities at each stage of the software development process to ensure high product quality.
Software Product Quality - Part 1 Presentation
- 1. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 1 Software Project Management Fifth Edition Chapter 13.1 Software product quality
- 2. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 2 The importance of software quality Increasing criticality of software The intangibility of software Project control concerns: errors accumulate with each stage errors become more expensive to remove the later they are found it is difficult to control the error removal process (e.g. testing)
- 3. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 3 Quality specifications Where there is a specific need for a quality, produce a quality specification Definition/description of the quality Scale: the unit of measurement Test: practical test of extent of quality Minimally acceptable: lowest acceptable value, if compensated for by higher quality level elsewhere Target range: desirable value Now: value that currently applies
- 4. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 4 ISO standards: development life cycles A development life cycle (like ISO 12207) indicates the sequence of processes that will produce the software deliverable and the intermediate products that will pass between the processes. elicit require- ments requirements design software s/w architecture code/test tested code processes intermediate products deliverable
- 5. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 5 ISO standards ISO 9126 Software product quality Attributes of software product quality External qualities i.e. apparent to the user of the deliverable Internal qualities i.e. apparent to the developers of the deliverables and the intermediate products ISO 14598 Procedures to carry out the assessment of the product qualities defined in ISO 9126
- 6. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 6 Types of quality assessment During software development, to assist developers to build software with the required qualities During software acquisition to allow a customer to compare and select the best quality product Independent evaluation by assessors rating a software product for a particular community of users
- 7. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 7 ISO 9126 software product quality process quality Process Process measures (ISO 15504) internal quality attributes external quality attributes quality in use attributes influences depends on influence s depends on influences Software products Effect of software product Internal measures External measures Quality in use measures Context of use
- 8. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 8 Quality in use Effectiveness – ability to achieve user goals with accuracy and completeness Productivity – avoids excessive use of resources in achieving user goals Safety – within reasonable levels of risk of harm to people, business, software, property, environment etc, Satisfaction – happy users! ‘users’ include those maintain software as well as those who operate it.
- 9. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 9 ISO 9126 software qualities functionality does it satisfy user needs? reliability can the software maintain its level of performance? usability how easy is it to use? efficiency relates to the physical resources used during execution maintainability relates to the effort needed to make changes to the software portability how easy can it be moved to a new environment?
- 10. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 10 Sub-characteristics of Functionality Suitability Accuracy Interoperability ability of software to interact with other software components Functionality compliance degree to which software adheres to application- related standards or legal requirements e.g audit Security control of access to the system
- 11. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 11 Sub-characteristics of Reliability Maturity frequency of failure due to faults - the more the software has been used, the more faults will have been removed Fault-tolerance Recoverability note that this is distinguished from ‘security’ - see above Reliability compliance – complies with standards relating to reliability
- 12. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 12 Sub-characteristics of Usability Understandability easy to understand? Learnability easy to learn? Operability easy to use? Attractiveness – this is a recent addition Usability compliance compliance with relevant standards
- 13. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 13 Sub-characteristics of Efficiency Time behaviour e.g. response time Resource utilization e.g. memory usage Efficiency compliance compliance with relevant standards
- 14. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 14 Sub-characteristics of Maintainability “Analysability” ease with which the cause of a failure can be found Changeability how easy is software to change? Stability low risk of modification having unexpected effects “Testability” Maintainability conformance
- 15. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 15 Sub-characteristics of portability Adaptability “Installability” Co-existence Capability of co-existing with other independent software products “Replaceability” factors giving ‘upwards’ compatibility - ‘downwards’ compatibility is excluded Portability conformance Adherence to standards that support portability
- 16. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 16 Using ISO 9126 quality standards (development mode) Judge the importance of each quality for the application for example, safety critical systems - reliability very important real-time systems - efficiency important Select relevant external measurements within ISO 9126 framework for these qualities, for example mean-time between failures for reliability response-time for efficiency
- 17. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 17 Using ISO 9126 quality standards map measurement onto ratings scale to show degree of user satisfaction – for example response time response (secs) rating <2 Exceeds requirement 2-5 Target range 6-10 Minimally acceptable >10 Unacceptable
- 18. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 18 Using ISO 9126 quality standards Identify the relevant internal measurements and the intermediate products in which they would appear e.g. at software design stage the estimated execution time for a transaction could be calculated
- 19. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 19 Using ISO9126 approach for application software selection Rather than map engineering measurement to qualitative rating, map it to a score Rate the importance of each quality in the range 1-5 Multiply quality and importance scores – see next slide Response (secs) Quality score <2 5 2-3 4 4-5 3 6-7 2 8-9 1 >9 0
- 20. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 20 Weighted quality scores Product A Product B Product quality Importance rating (a) Quality score (b) Weighted score (a x b) Quality score (c) Weighted score (a x c) usability 3 1 3 3 9 efficiency 4 2 8 2 8 maintain- ability 2 3 6 1 2 Overall totals 17 19
- 21. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 21 How do we achieve product quality? the problem: quality attributes tend to retrospectively measurable need to be able to examine processes by which product is created beforehand the production process is a network of sub-processes output from one process forms the input to the next errors can enter the process at any stage
- 22. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 22 Correction of errors Errors are more expensive to correct at later stages need to rework more stages later stages are more detailed and less able to absorb change Barry Boehm Error typically 10 times more expensive to correct at coding stage than at requirements stage 100 times more expensive at maintenance stage
- 23. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 23 For each activity, define: Entry requirements these have to be in place before an activity can be started example: ‘a comprehensive set of test data and expected results be prepared and independently reviewed against the system requirement before program testing can commence’
- 24. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 24 For each activity, define Implementation requirements these define how the process is to be conducted example ‘whenever an error is found and corrected, all test runs must be completed, including those previously successfully passed’
- 25. SPM (5e) Product quality© The McGraw-Hill Companies, 2011 25 For each activity, define Exit requirements an activity will not be completed until these requirements have been met example: ‘the testing phase is finished only when all tests have been run in succession with no outstanding errors’
Editor's Notes
- #2: Increasing criticality of software – e.g .software is increasingly being used in systems that can threaten or support human life and well-being The intangibility of software – it is difficult for observers to judge the quality of software development, especially during its early stages Project control concerns: The products of one sub-process in the development process are the inputs to subsequent sub-processes, thus errors accumulate with each stage e.g. at the design stage, the specification errors are incorporated into the design, and at the coding stage specification and design errors are incorporated into the software errors become more expensive to remove the later they are found it is difficult to control the error removal process (e.g. testing) See Section 13.3 page 295
- #3: Section 13.4 page 296.
- #4: The deliverables are the products that are handed over to the client at the end of the project, typically the executable code. Intermediate products are things that are produced during the project, but which are not (usually) handed to the client at the end. Typically they are things that are produced by one sub-process (e.g. a requirements document created by the requirements elicitation and analysis processes) and used by others (e.g. a design process which produces a design that fulfils the requirements). These sub-processes will fit into the overall framework of a development cycle. Some software quality models focus on evaluating the quality of software products, others on the processes by which the products are created.
- #5: ISO 9126 focuses on the definition of software quality, while ISO 14598 focuses on the way that the quality, once defined, is assessed. The ISO 9000 series of standards establishes requirements for quality management systems for the creation/supply of all types of goods and services while the ones mentioned here relate specifically to software.
- #7: Internal quality attributes are the things that developers would be aware of during the project. They could be qualities in the intermediate products that are created. External quality attributes are the qualities of the final products that are delivered to the users. Thus users would be very aware of these. A key task is mapping these two types of quality. Acceptable quality in software depends on the use to which the software is put. For example, a higher standard of reliability would be expected of a software component that was very heavily used and the continued functioning of which was essential to the organization, than of a rarely used software tool for which there were many alternatives. See Section 13.4 page 298
- #8: Section 13.5 page 298
- #9: These are the six top-level qualities identified in ISO9126. Note that ‘functionality’ is listed as a quality. Sometimes ‘functional’ requirements are distinguished from ‘non-functional’ (i.e. quality) requirements. Page 299.
- #10: In the case of interoperability, a good example is the ability to copy and paste content between different Microsoft products such as Excel and Word. Page 299.
- #11: Maturity – in general you would expect software that has been in operation for a relatively long time and had many users to be more reliable than brand-new software which has only a few users. In the first case, one would hope that most of the bugs had been found by the users and had been fixed by the developers.
- #12: Note that there may need to be a trade-off between ‘learnability’ and ‘operability’ – an analogy would be in learning shorthand writing: it takes a long time to do, but once you have done it you can write very quickly indeed. ‘Attractiveness’ is a new addition – it is important where the use of software is optional – if users don’t like the software then they won’t use it. See page 300.
- #13: Page 300
- #14: Testability can be particularly important with embedded software, such as that used to control aircraft. Software that simulates the actions of the aircraft in terms of inputs to the control system etc would need to be built. Page 301
- #15: Replaceability - A new version of a software product should be able to deal correctly with all the inputs that the previous versions could deal with. However there could be new features that need new inputs that the old system would not be able to deal with. Page 301
- #16: Pages 301-302
- #20: This suggests that Product B is slightly more likely to meet the users’ quality needs.
- #21: There is a bridge here between the focus on the quality of products as discussed in this lecture and the quality of processes discussed in the lecture 13.2 on process quality
- #22: The additional time needed to change products later is partly because more products in the project life cycle have to change e.g. the specification, design and code, rather than just the specification. Also the later products of the project tend to be more detailed and therefore more complicated.
- #23: We are moving into process quality now. However, the entry requirements could well relate to the quality of the products of other processes tha this process will need to use.
- #25: The exit requirements, however, could well relate to characteristics of the products created by the process in question.