CIE 203 Software Engineering Lecture 15: SW Quality Assurance

1. CIE 203 Software Engineering Lecture 15: SW Quality Assurance Mohammad El-Ramly, PhD 2016 http://www.acadox.com/join/4DMHHB http://www.acadox.com/class/37407

2. حديث شريف • إن الله يحب إذا عمل أحدكم عملا أن يتقنه • إن الله كتب الإحسان على كل شئ

3. Requirement Design Implement Testing Where are we now? Software Configuration Management Software Quality Assurance Software Process

4. Requirement Design Implement Testing Where are we now? Software Configuration Management Software Quality Assurance Software Process

5. Last Lecture(s) • Definition of SCM • Version Control • Change Management • Backup Plan • SW Lifecycle • SW Process Models • Example SW Process Models in Practice

6. SQA Outline • Understanding SW Quality Attributes • Understand the value of SW QA • Quality Landscape • SW QA Jobs and Certificates • Effectiveness of QA Techniques • Review of Course Objectives Readings#8 – Code Complete Ch 20

7. LIMITED WARRANTY • ABC provides no warranty, either expressed or implied, with respect to AMGAL’s performance, reliability or fitness for any specified purpose. • ABC does not warrant that the software or its documentation will fulfill your requirements.

8. LIMITED WARRANTY • Although ABC has performed thorough tests of the software and reviewed the documentation, ABC does not provide any warranty that the software and its documentation are free of errors. • ABC will in no case be liable for any damages, incidental, direct, indirect or consequential, incurred as a result of impaired data, recovery costs, profit loss and third party claims.

9. Quality: According to ISO 8402: The totality of features and characteristics of a product or a service that bear on its ability to satisfy stated or implied needs.

10. LIMITED WARRANTY • The software is licensed “as is”. The purchaser assumes the complete risk stemming from application of the AMGAL program, its quality and performance.

11. Software: • According to IEEE: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.

12. Software Quality: According to 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.

13. Software Quality: According to Pressman’s: Conformance to explicitly functional stated functional and performance requirements, explicitly documented development standards, and implicitcharacteristics that are expected of all professionally developed software.

14. Software Quality: • According to Pressman’s: • This definition suggests 3 requirements to be met by the developer: • Specific functional requirements (o/p) • The software quality standards mentioned in the contract • Good Software Engineering Practices

15. 1. What is SW Quality? • Customer’s Perspective • System does not crash • System follows documentation & contract • System is logical and easy to use • Developer’s Perspective • System is easy to change • System is easy to understand • System is pleasant to work on

16. External Quality Characteristic ● Correctness. • The degree to which a system is free from faults in its specification, design, and implementation. ● Usability. • The ease with which users can learn and use a system. ● Efficiency. • Minimal use of system resources, including memory and execution time.

17. External Quality Characteristic ● Reliability • The ability of a system to perform its required functions under stated conditions whenever required—having a long mean time between failures. ● Robustness • The degree to which a system continues to function in the presence of invalid inputs or stressful environmental conditions.

18. External Quality Characteristic ● Integrity • The degree to which a system prevents unauthorized or improper access to its programs and data. • Ensuring that data is accessed properly ● Adaptability • The extent to which a system can be used, without modification, in applications or environments other than those for which it was specifically designed.

20. Internal Quality Characteristic ● Maintainability • The ease with which you can modify a software system to change or add capabilities, improve performance, or correct defects. ● Flexibility • The extent to which you can modify a system for uses or environments other than those for which it was specifically designed.

21. Internal Quality Characteristic ● Reusability • The extent to which and the ease with which you can useparts of the system in other systems. ● Understandability / Readability • The ease with which you can comprehend a system at organizational and detailed levels.

23. What Are The Causes of Errors ?

24. Causes of Errors #1: Faulty Requirements • The root cause of software errors • Incorrect requirement definitions • Incomplete definitions • Unclear or implied requirements • Missing requirements • Inclusion of unneeded requirements • (many projects have gone amuck for including far too many requirements that will never be used. • Impacts budgets, complexity, development time, …

25. Causes #2: Communication Failure • Misunderstanding of instructions in requirements documentation • Misunderstanding of writtenchanges during development. • Misunderstanding of oralchanges during development. • Lack of attention to client messages by developers dealing with requirement changes and to client responses by clients to developer questions.

26. Causes #4: Logical design errors • Erroneous algorithms. • Process definitions that contain sequencing errors. • Erroneous definition of boundary conditions.

27. Causes #5: Coding Errors • Too many to list • broad range of reasons cause programmers to make coding errors. These • include misunderstanding the design documentation, linguistic errors in the programming languages, errors in the application of CASE and other development tools, errors in data selection, and so forth.

28. Causes #6: Non-compliance with documentation and coding instructions • Almost every development unit has its own documentation and coding standards. • To support this requirement, the unit develops and publicizes its templates and coding instructions. • Members of the development team or unit are required to comply with these requirements. • Non-compliance hinders future development.

29. Causes #7: Shortcomings of the Testing Process • Likely the part of the development process cut short most frequently! • Incomplete test plans • Parts of application not tested or not tested thoroughly! • Failure to document, report detected errors and faults • Failure to fix the errors.

30. Causes #8: Documentation Errors • Errors in the design documents • Trouble for subsequent redesign and reuse. • Errors in the documentation within the software for the User Manuals • Errors in on-line help, if available. • Listing of non-existing software functions • Planned early but dropped; remain in documentation! • Meaningless error messages.

32. 2. The Cost of Poor Quality • Money • Time • Resources • Lives • Reputation • Business 32

33. Failure Costs • Internal • Rework • Repair • Failure analysis • External • Resolving complaints • Returning and replacing product • Help line

34. Prevention Costs • Prevention • Planning • Managing and collecting information • Reviews • Appraisal • Inspection • Testing

35. The Cost of Poor Quality

37. 3. Techniques for Improving SW Quality • What can we do improve quality ? • SW QA is a wide spectrum of activities conducted through out the development process that focus on: • Product quality • Process quality

38. Techniques for Improving SW Quality (Code Complete) • SW Q Objectives & Planning • Explicit QA Activities • Testing Strategy • SE Guidelines • Formal / Informal Technical Reviews • Change-control Procedures • Measurement of Results • Prototyping

40. Change and Configuration Management Software Quality Landscape Reviews Collaborative Development / Reviews Requirements V & V Guidelines, Standards and Templates Design Review Bug Tracking Surveys Contract Review QA Planning and Budgeting Testing Metrics Debugging Refactoring Deployment & Maintenance Planning Design Testing Requirements Development M a n a g e m e n t

41. 1. SW Quality Objectives • Decide explicit quality characteristics • Inform the developers • They are morelikely to achieve quality objectives if they now them. • Review their work • Study by G M Weinberg, E L Schulman, Goals and Performance in Computer Programming (1974)

44. 2. Explicit QA Activities • QA should be perceived as a primary not secondary goal • QA should be an organizationalculture. • Organization should train developers that quality is a priority.

45. 3. Testing Strategy • Develop a test strategy with product requirements, architecture and design. • Or even consider test-driven development.

46. 4. SE Guidelines • Decide on guidelines, templates, checklists and standards to follow. • Requirements, architecture and design guidelines. • Templates for plans, reports, etc. • Coding style. • File naming conventions. • Apply them and enforce them in every phase.

47. 5. Reviews • Informal Reviews • Desk-checking • Walk through • Formal Technical Reviews • Act as a “quality gate” • Catch problems at the “lowest-value” stage—that is, at the stage in which problems cost the least tocorrect. • Can be a peer review, a customer review, an, inspection, or an externalaudit.

48. 6. Change-control Procedures • Changing hurts quality. • Remember the Vaza • Uncontrolled changes: • Requirements => unstable designs and code • Design => Inconsistency with req. and code • Code => Inconsistency / invalid doc. • Adopt incremental development • Adopt Configuration and Change Management

49. 7. Measurement of Results • Measuring what ? • 3P => Product, Project and Process • Quality attributes. • Measurements tells you if QA plan failed or succeeded. • Can be the basis for improvement.

50. 8. Prototyping • Develop realistic model of the system’s key functionalities. • UI to evaluate usability • Key calculations to see their results, memory requirements and performance • Studies suggest that prototyping can lead to better designs, better satisfaction of user needs and improved maintainability.