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 : 1. Product complexity : # of operational modes the product permit. 2. Product visibility : SW products are invisible. 3. 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: CharacteristicSW productsOther 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

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  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

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

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 )  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 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

24 Faulty requirement definition 1. Erroneous definition of requirements 2. Absence of vital requirements 3. Incomplete definition of requirements 4. 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.