Software quality - Definition IEEE

1. Software quality - Definition IEEE • The degree to which a system, component, or process meets specified requirements. • The degree to which a system, component, or process meets customer or user needs or expectations.

2. Software Quality Pressman’s def. Conformance to explicitly stated functional and performance requirements, explicitly documented standards, and implicit characteristics that are expected of all professionally developed software.

3. Software Quality Assurance The IEEE Definition • SQA is : • A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. • A set of activities designed to evaluate the process by which the products are developed or manufactured. Contrast with quality control.

4. IEEE SQA definition – exclude the maintenance & timetable and budget issues. • The Author adopts the following : • SQA should not be limited to the development process. It should be extended to cover the long years of service subsequent to product delivery. Adding the software maintenance functions into the overall conception of SQA. • SQA actions should not be limited to technical aspects of the functional requirements, It should include activities that deal with scheduling and timetable and budget .

5. SQA – Expanded Definition A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines. . This definition corresponds strongly with the concepts at the foundation of ISO 9000-3, 1997and also corresponds to the main outlines of the CMM for softwareSee the Table 2.2 page 27

6. Software Quality Assurance Vs. Software Quality Control • Quality Control : a set of activities designed to evaluate the quality of a developed or manufactured product. It take place before the product is shipped to the client. • Quality Assurance : the main objective is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the causes of errors, and detect and correct them early in the dev. Process.

7. The objectives of SQA activitiessee page 29 • Software development ( process-oriented ) • Software maintenance ( Product-oriented )

8. SQA Vs Software Engineering • SW Engineering ( IEEE def. ) • The application of a systematic, restricted, quantifiable approach to the development and maintenance of SW; that is the application of engineering to software.

9. Chapter 3 Software Quality Factors

10. SQ. Factors • From the previous chapters we have already established that the requirements documentis one of the most important elements for achieving SQ. • What is a “Good” SQ requirements document ?

11. The need for comprehensive SQ requirements • Our Sales IS seems v. good , but it is frequently fails, at least twice a day for 20 minutes or more.( SW house claims no responsibility…. • Local product contains a SW and every thing is ok, but, when we began planning the development of a European version, almost all the design and programming will be new. • etc see page 36.

12. There are some characteristics common to all these buts : • All SW projects satisfactorily fulfilled the basic requirements for correct calculations. • All SW projects suffered from poor performance in important areas such as maintenance, reliability, SW reuse, or training. • The cause for poor performance of the developed SW projects in these areas was lack of predefined requirements to cover these important aspects of the SW functionality. • The solution is : The need for a comprehensive definition of requirements ( SQ Factors )

13. Classification of SW requirements into SW quality factors. • McCall’s Factor Model • This model classifies all SW requirements into 11 SW quality factors, grouped into 3 categories: • Product operation: Correctness, Reliability, Efficiency, Integrity, Usability • Product revision : Maintainability, Flexibility, Testability • Product transition : Portability, Reusability, Interoperability. See the McCall model of SW quality factors tree see page 38

14. Product operation SW quality factors • Correctness: Output specifications are usually multidimensional ; some common include: • The output mission • The required accuracy • The completeness • The up-to-dateness of the info. • The availability of the info.( the reaction time ) • The standards for coding and documenting the SW system • See Example page 39.

15. Product operation SW quality factors • Reliability: Deals with failures to provide service. They determine the maximum allowed SW system failure rate, and can refer to the entire system or to one or more of its separate functions. See examples page 39 ( heart-monitoring unit )

16. Product operation SW quality factors • Efficiency: Deals with the HW resources needed to perform all the functions of the SW system in conformance to all other requirements. See examples page 40 ( CPU speed .. etc ) • Integrity: Deals with the SW system security, that is requirements to prevent access to unauthorized persons. See examples page 40

17. Product operation SW quality factors • Usability: Deals with the scope of staff resources needed to train a new employee and to operate the SW system. See examples page 41

18. Product revision SW quality factors • Maintainability : Maintainability requirements determine the efforts that will be needed by users and maintenance personnel to identify the reasons for SW failures, to correct the failure, and to verify the success of the corrections. Example : Typical maintainability requirements: • The size of a SW module will not exceed 30 statements • The programming will adhere to the company coding standards and guidelines.

19. Product revision SW quality factors • Flexibility : The capabilities and efforts required to support adaptive maintenance activities are covered by flexibility requirements. This factor’s requirements also support perfective maintenance activities, such as changes and additions to the SW in order to improve its service and adapt it to changes in the firm’s technical or commercial environment. Example :page 42

20. Product revision SW quality factors • Testability : • Deal with the testing of an IS as well as with its operation. • Providing predefined intermediate results and log files. • Automatic diagnostics performed by the SW system prior starting the system, to find out whether all components of SW system are in working order. • Obtain a report about detected faults. Example :page 42, 43

21. Product transition SW quality factors • Portability : • Tend to the adaptation of a SW system to other environments consisting : • Different HW • Different OS Example : SW designed to work under windows 2000 env. Is required to allow low-cost transfer to Linux.

22. Product transition SW quality factors • Reusability : • Deals with the use of SW modules originally designed for one project in a new SW project currently begin developed. • The reuse of SW is expected to save resources., shorten the project period, and provide higher quality modules. These benefits of higher quality are based on the assumption that most SW faults have already been detected by SQA activities performed previously on it.

23. Product transition SW quality factors • Interoperability : • Focus on creating interfaces with other SW systems or with other equipment firmware. • Example: • The firmware of medical lab. equipment is required to process its results according to a standard data structure that can be then serve as input for a number of standard laboratory IS.

24. Alternative Models Of SW Quality Factors • Two other models for SQ factors: • Evans and Marciniak 1987 ( 12 factors ) • Deutsch and Willis 1988. ( 15 factors ) • Five new factors were suggested • Verifiability • Expandability • Safety • Manageability • Survivability

25. Alternative Models Of SW Quality Factors • Five new factors were suggested • Verifiability: define design and programming features that enable efficient verification of the design and programming ( modularity, simplicity, adherence to documentation and prog guidelines. ) • Expandability: refer to future efforts that will be needed to serve larger populations, improve services, or add new applications in order to improve usability. • Safety: meant to eliminate conditions hazardous to equipment as a result of errors in process control SW. • Manageability: refer to the admin. tools that support SW modification during the SW development and maintenance periods. • Survivability: refer to the continuity of service. These define the minimum time allowed between failures of the system, and the maximum time permitted for recovery of service.

26. Who is interested in the definition of quality requirements ? • The client is not the only party interested in defining the requirements that assure the quality of the SW product. • The developer is often interested also specially : • Reusability • Verifiability • Porotability • Any SW project will be carried out according to 2 requirements document : • The client’s requirements document • The developer’s additional requirements document.