1. Software project management (intro) Quality assurance

2. Software quality Of increasing concern e.g. because of safety critical systems e.g. because of safety critical systems Project control concerns: need to make project progress visible need to make project progress visible every task has a deliverable – to make task tangible every task has a deliverable – to make task tangible errors accumulate with each stage errors accumulate with each stage errors become more expensive to remove the later they are found errors become more expensive to remove the later they are found it is difficult to control the error removal process (e.g. testing) it is difficult to control the error removal process (e.g. testing)

3. quality specification each project has three sets of requirements functional requirements: what the system is to do functional requirements: what the system is to do quality requirements: how well it is to do it quality requirements: how well it is to do it resource requirements: how much it is going to cost resource requirements: how much it is going to cost

4. Defining Software Quality There are product qualities appropriate to software. McCall grouped software qualities into: 1. Product operation qualities 2. Product revision qualities 3. Product transition qualities

5. Product Operation Quality Factors Correctness The extent to which program satisfies its specification and fulfill the user’s objective The extent to which program satisfies its specification and fulfill the user’s objectiveReliability The extent to which program can be expected to perform its intended function with required precision The extent to which program can be expected to perform its intended function with required precisionEfficiency The amount of computer resources required The amount of computer resources requiredIntegrity The extent to which access to software or data by unauthorized person can be controlled The extent to which access to software or data by unauthorized person can be controlledUsability The effort required to learn, operate, prepare input and interpret output The effort required to learn, operate, prepare input and interpret output

6. Product revision quality factors Maintainability The effort required to locate and fix an error in an operational program The effort required to locate and fix an error in an operational programTestability The effort required to test a program to ensure it performs its intended function The effort required to test a program to ensure it performs its intended functionFlexibility The effort required to modify an operational program The effort required to modify an operational program

7. Product transition quality factors Portability The effort required to transfer a program from one hardware configuration and/or software system environment to another The effort required to transfer a program from one hardware configuration and/or software system environment to anotherReusability The extent to which a program can be used in other application The extent to which a program can be used in other applicationInteroperability The effort required to couple one system to another The effort required to couple one system to another

8. ISO 9126 software qualities

9. sub-characteristics of functionality suitabilityaccuracyinteroperability ability of software to interact with other software components ability of software to interact with other software componentscompliance degree to which software adheres to application-related standards or legal requirements e.g audit degree to which software adheres to application-related standards or legal requirements e.g auditsecurity control of access to the system control of access to the system

10. sub-characteristics of reliability maturity frequency of failure due to faults - the more the software has been used, the more faults will have been removed frequency of failure due to faults - the more the software has been used, the more faults will have been removedfault-tolerancerecoverability note that this is distinguished from ‘security’ - see above note that this is distinguished from ‘security’ - see above

11. sub-characteristics of usability understandability easy to understand? easy to understand?Learn-ability easy to learn? easy to learn?operability easy to use? easy to use?

12. sub-characteristics of efficiency time behaviour e.g. response time e.g. response time resource behaviour e.g. memory usage e.g. memory usage

13. sub-characteristics of maintainablity analysability ease with which the cause of a failure can be found ease with which the cause of a failure can be foundchangeability how easy is software to change? how easy is software to change?stability low risk of modification having unexpected effects low risk of modification having unexpected effectstestability

14. sub-characteristics of portability adaptabilityinstallabilityconformance standards that have bearing on portability (compare to ‘compliance’) - e.g. use of high-level language standards that have bearing on portability (compare to ‘compliance’) - e.g. use of high-level languagereplaceability factors giving ‘upwards’ compatibility - ‘downwards’ compatibility is excluded factors giving ‘upwards’ compatibility - ‘downwards’ compatibility is excluded

15. the relationship between any two qualities may be: indifferent one has no effect on the other one has no effect on the othercompetitive a system can only be good in respect to one quality at the expense of another a system can only be good in respect to one quality at the expense of anothercomplementary a system which is good in respect to one quality is likely to be also good in respect to the other a system which is good in respect to one quality is likely to be also good in respect to the other

16. internal versus external qualities External quality changeability changeability testability testability Internal qualities modularity generality expandibility self-descriptiveness simplicity modularity instrumentation self-descriptiveness

17. internal versus external qualities portability modularity self-descriptiveness machine independence software system independence

18. using ISO 9126 quality standards Judge the importance of each quality for the application for example, safety critical systems - reliability very important for example, safety critical systems - reliability very important real-time systems - efficiency important real-time systems - efficiency important Work out ways of measuring quality for example, mean-time between failures for reliability for example, mean-time between failures for reliability response-time for efficiency response-time for efficiency

19. using ISO 9126 quality standards map measurement onto ratings scale to show degree of satisfaction

20. using ISO 9126 quality standards Work out how ratings are to be combined

21. software measurement may apply to: final products final products intermediate products (predictive metrics) intermediate products (predictive metrics) may be: relative or binary (does it/ does it not exist?) relative or binary (does it/ does it not exist?) direct or indirect direct or indirect tightly or loosely coupled tightly or loosely coupled

22. quality specification e.g. ‘ease of installation’ definition of attribute the amount of effort needed to install the package for a new customer the amount of effort needed to install the package for a new customer measurement scale hours hours how tested time needed to install system at three different sites time needed to install system at three different sites

23. quality specification e.g. ‘ease of installation’ -continued worst acceptable limit 4 hours 4 hours planned limit 1 hours 1 hours best achievable 30 minutes 30 minutes Define these for ‘user-friendliness’

24. how do we achieve product quality? the problem: quality attributes tend to retrospectively measurable need to be able to examine processes by which product is created beforehand the production process is a network of sub-processes output from one process forms the input to the next errors can enter the process at any stage

25. correction of errors errors are more expensive to correct at later stages need to rework more stages need to rework more stages later stages are more detailed and less able to absorb change later stages are more detailed and less able to absorb change Barry Boehm error typically 10 times more expensive to correct at coding stage than at requirements stage error typically 10 times more expensive to correct at coding stage than at requirements stage 100 times more expensive at maintenance stage 100 times more expensive at maintenance stage

26. Process requirements for each activity, define: entry requirements these have to be in place before an activity can be started these have to be in place before an activity can be started example: ‘a comprehensive set of test data and expected results be prepared and independently reviewed against the system requirement before program testing can commence’ example: ‘a comprehensive set of test data and expected results be prepared and independently reviewed against the system requirement before program testing can commence’

27. Process requirements (2) for each activity, define Implementation requirements these define how the process is to be conducted these define how the process is to be conducted example ‘whenever an error is found and corrected, all test runs must be completed, including those previously successfully passed’ example ‘whenever an error is found and corrected, all test runs must be completed, including those previously successfully passed’

28. Process requirements (3) for each activity, define exit requirements an activity will not be completed until these requirements have been met an activity will not be completed until these requirements have been met example: ‘the testing phase is finished only when all tests have been run in succession with no outstanding errors’ example: ‘the testing phase is finished only when all tests have been run in succession with no outstanding errors’ software quality plan these requirements may be laid down in site standards, or a quality plan may be drawn up for a specific project these requirements may be laid down in site standards, or a quality plan may be drawn up for a specific project

29. inspections - general principles when a piece of work is completed, copies are distributed to co-workers time is spent individually going through the work noting defects a meeting is held where the work is then discussed a list of defects requiring re-work is produced

30. inspections (2) – advantages of approach an effective way of removing superficial errors from a piece of software motivates the software developer to produce better structured and self-descriptive code spreads good programming practice enhances team-spirit the main problem maintaining the commitment of participants

31. Techniques to enhance quality Increase the visibility of software put method into processes of development check intermediate stages