Software Quality Assurance class 1
- 1. 14ITPK0-Software Quality Assurance—Lecture Notes Text Book----Daniel Galin Mrs.C.Santhiya Assistant Professor TCE,Madurai 1
- 2. Course Outcomes C01-explain the Sw Quality Stds and models-Understand C02-Apply different project management techniques such as configuration mgt and quality assurance practices during product life cycle-Apply C03-Apply verification and validation methods such as inspection and testing during project life cycle-Apply C04-Analze different software products metrics to asses the project quality-Apply C05-Manage and track software prjects based on quality standards- Apply 2
- 3. 3 Chapter 1 The Software Quality Challenge
- 4. 4 The uniqueness of software quality assurance DO you think that there is a bug-free software? Can software developers warrant their software applications and their documentation from any bugs or defects ? What are the essential elemental differences between software and other industrial products such as automobiles, washing machines etc?
- 5. 5 The essential differences between software and other industrial products can be categorized as follows : 1. Product complexity : # of operational modes the product permit. 2. Product visibility : SW products are invisible. 3. Product development and production process.
- 6. 6 The phases at which the possibility of detecting defects in industrial products and software products: SW products do not benefit from the opportunities for detection of defects at the three phases of the production process Industrial products: Product development : QA -> product prototype Product production planning : Production - line Manufacturing : QA procedure applied Software products: Product development : QA -> product prototype Product production planning : Not required Manufacturing : Copying the product & printing copies
- 7. 7 Factors affecting detecting defects in SW products VS other industrial products: Characteristic SW products Other industrial products Complexity Usually, v. complex allowing for v. large number of operational options Degree of complexity much lower Visibility Invisible, impossible to detect defects or omissions by sight ( diskette or CD storing ) Visible, allowing effective detection of defects by sight Nature of development and production process Opportunities to detect defects arise in only one phase, namely product development Opportunities to detect defects arise in all phases of development and production
- 8. 8 Important Conclusion The great complexity as well as invisibility of software, among other product characteristics, make the development of SQA methodologies and its successful implementation a highly professional challenge
- 9. 9 Pupils & students Hobbies Engineers, economics , mgt & other fields SW development professionals All those SW developers are required to deal with SW quality problems “Bugs” The environment for which SQA methods are developed
- 10. 10 SQA environment The main characteristics of this environment : 1. Contractual conditions 2. Subjection to customer-supplier relationship 3. Required teamwork 4. Cooperation and coordination with other SW teams 5. Interfaces with other SW systems 6. The need to continue carrying out a project despite team member changes. 7. The need to continue out SW maintenance for extended period.
- 11. 11 Contractual conditions the activities of SW development & maintenance need to cope with : A defined list of functional requirements The project budget The project timetable
- 12. 12 Subjection to customer-supplier relationship SW developer must cooperate continuously with customer : To consider his request to changes To discuss his criticisms To get his approval for changes
- 13. 13 Required teamwork Factors motivating the establishment of a project team: Timetable requirements The need of variety The wish to benefit from professional mutual support & review for enhancement of project quality
- 14. 14 Cooperation and coordination with other SW teams Cooperation may be required with: Other SW dev. Teams in the same org. HW dev. teams in the same org. SW & HW dev. teams of other suppliers Customer SW and HW dev. teams that take part in the project’s dev.
- 15. 15 Interfaces with other SW Systems Input interfaces Output interfaces I/O interfaces to the machine’s control board, as in medical and lab. Control systems
- 16. 16 The need to continue carrying out a project despite team member changes. During project dev. Period we might be face : Leave from the members of the team Switch in employees Transfer to another city
- 17. 17 The need to continue out SW maintenance for extended period. From 5 to 10 years , customers need continue to utilizing their systems: Maintenance Enhancement Changes ( Modification )
- 18. 18 Chapter 2 What is Software Quality ?
- 19. 19 What is Software ? IEEE Definition: Software Is : Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.
- 20. 20 IEEE Definition is almost identical to the ISO def. ( ISO/IEC 9000-3 ) Computer programs (“Code”) Procedures Documentation Data necessary for operation the SW system.
- 21. 21 TO sum up: Software quality assurance always includes : Code quality The quality of the documentation And the quality of the necessary SW data
- 22. 22 SW errors, faults and failures Questions arise from HRM conference. An error : can be a grammatical error in one or more of the code lines, or a logical error in carrying out one or more of the client’s requirements. Not all SW errors become SW faults. SW failures that disrupt our use of the software.
- 23. 23 The relationship between SW faults & SW failures: Do all SW faults end with SW failures? The answer is not necessarily The SW fault becomes a SW failure only when it is activated.
- 24. 24 Classification of the causes of SW errors SW errors are the cause of poor SW quality SW errors can be Code error Documentation error SW data error The cause of all these errors are human
- 25. 25 The nine causes of software errors 1. Faulty requirement definition 2. Client-developer communication failures 3. Deliberate deviation from SW requirements 4. Logical design errors 5. Coding errors 6. Non-compliance with documentation and coding instructions 7. Shortcomings of the testing process 8. Procedure errors 9. Documentation errors
- 26. 26 Faulty requirement definition 1. Erroneous definition of requirements 2. Absence of vital requirements 3. Incomplete definition of requirements 4. Inclusion of unnecessary requirements
- 27. 27 Client-developer communication failures Misunderstandings resulting from defective client-developer comunications. Misunderstanding of the client’s requirements changes presented to the developer In written forms Orally Responses to the design problems others
- 28. 28 Deliberate deviation from SW requirements The developer reuse SW modules taken from the earlier project Due to the time budget pressure Due to the unapproved improvements
- 29. 29 Logical design errors This is come from systems architects, system analysts, SW engineers such as: Erroneous algorithms Process definitions that contain sequencing errors Erroneous definition of boundary conditions Omission of required SW system states Omission of definitions concerning reactions to illegal operations
- 30. 30 Coding errors Misunderstanding the design documentation Linguistic errors in the prog. Lang. Errors in the application of CASE and other dev. Tools etc
- 31. 31 Non-compliance with documentation and coding Team members who need to coordinate their own codes with code modules developed by non-complying team members Individuals replacing the non-complying team member will find it difficult to fully understand his work. Design review to other non-complying team
- 32. 32 Shortcomings of the testing process Incomplete testing plans Failures to document and report errors and faults Failures to promptly correct detected SW faults as a result of inappropriate indications of the reasons for the fault. Incomplete correction of detected errors.
- 33. 33 Procedure errors & documentation errors No Clarity in Hardcopy
- 34. 34 Software quality - Definition IEEE 1. The degree to which a system, component, or process meets specified requirements. 2. The degree to which a system, component, or process meets customer or user needs or expectations.
- 35. 35 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.
- 36. 36 Software Quality Assurance The IEEE Definition SQA is : 1. A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. 2. A set of activities designed to evaluate the process by which the products are developed or manufactured. Contrast with quality control.
- 37. 37 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 .
- 38. 38 SQA – Expanded Definition . This definition corresponds strongly with the concepts at the foundation of ISO 9000-3, 1997 and also corresponds to the main outlines of the CMM for software See the Table 2.2 page 27 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.
- 39. 39 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.
- 40. 40 The objectives of SQA activities Software development ( process-oriented ) Software maintenance ( Product-oriented )
- 41. 41 SQA Vs Software Engineering SW Engineering ( IEEE def. ) 1. The application of a systematic, restricted, quantifiable approach to the development and maintenance of SW; that is the application of engineering to software.