1 / 299

Chapter 1

Chapter 1. The Software Quality Challenge. 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 ?

junior
Download Presentation

Chapter 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 1 The Software Quality Challenge

  2. 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?

  3. The essential differences between software and other industrial products can be categorized as follows : • Product complexity : # of operational modes the product permit. • Product visibility : SW products are invisible. • Product development and production process.

  4. 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

  5. Factors affecting detecting defects in SW products VS other industrial products:

  6. 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

  7. The environment for which SQA methods are developed • Pupils & students • Hobbies • Engineers, economics , mgt & other fields • SW development professionals All those SW developers are required to deal with SW quality problems “Bugs”

  8. SQA environmentThe main characteristics of this environment : • Contractual conditions • Subjection to customer-supplier relationship • Required teamwork • Cooperation and coordination with other SW teams • Interfaces with other SW systems • The need to continue carrying out a project despite team member changes. • The need to continue out SW maintenance for extended period.

  9. Contractual conditions the activities of SW development & maintenance need to cope with : • A defined list of functional requirements • The project budget • The project timetable

  10. 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

  11. 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

  12. 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.

  13. 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

  14. 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

  15. 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 )

  16. Chapter 2 What is Software Quality ?

  17. What is Software ? • IEEE Definition: Software Is : Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.

  18. 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.

  19. TO sum up: Software quality assurance always includes : • Code quality • The quality of the documentation • And the quality of the necessary SW data

  20. SW errors, faults and failures • Questions arise from HRM conference Page 16. • 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.

  21. 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. • Example page 17-18

  22. 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

  23. The nine causes of software errors • Faulty requirement definition • Client-developer communication failures • Deliberate deviation from SW requirements • Logical design errors • Coding errors • Non-compliance with documentation and coding instructions • Shortcomings of the testing process • Procedure errors • Documentation errors

  24. Faulty requirement definition • Erroneous definition of requirements • Absence of vital requirements • Incomplete definition of requirements • Inclusion of unnecessary requirements

  25. 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

  26. 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

  27. 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

  28. Coding errors • Misunderstanding the design documentation • Linguistic errors in the prog. Lang. • Errors in the application of CASE and other dev. Tools • etc

  29. 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

  30. 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.

  31. Procedure errors & documentation errors • See example page 22

  32. 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.

  33. 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.

  34. 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.

  35. 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 .

  36. 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

  37. 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.

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

  39. 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.

  40. Chapter 3 Software Quality Factors

  41. 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 ?

  42. 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.

  43. 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 )

  44. 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

  45. 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.

  46. 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 )

  47. 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

  48. 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

  49. 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.

  50. 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

More Related