1. Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior to release. However, they don’t want to take the time to inspect the software thoroughly prior to release. Instead they must deal with the complaints after release.

2. Inspection “Inspection” is the systematic approach to examining a program in detail. Assess the quality of the software product itself, not the quality of the process by which it was developed.

3. Development Process The following three categories: Design, Code and Documentation Test and Verification Control of the Development Processes

4. Programmer “Natural” Flow like an assembly line. Design/Document Code Test Integrate Performance/Measure Release

5. Quality Control Software must be: functionally complete easily usable and installable low error rates. To correct a problem found in the final product is much more costly and time consuming then doing so earlier on in the development process.

6. Detect errors early and correct them as soon as possible to prevent further errors from slipping into the next development phase. Increase ease of use and future maintenance of the product.

7. Design High Level Design 1.Overall specification on what is to be performed. 2.Dependencies for each major function by modules identifying both internal/external cases. 3.Linkages between modules are specified. 4.For each function, a control flow describing the logic given by modules.

8. Detailed Design 1.Receives input from High Level Design. 2.Used as input to coding. 3.Complete “Structured” logic flow (by module) should be given. 4.Data Structure should be clearly specified.

9. Testing Function Test Verification of each function using a series of test cases within its intended environment. Component Test Verification of inter-functional activities. System Test Make sure no part of the system is adversely effected (including performance) and that it doesn’t crash even under unusual, non-intended environment.

10. Continuous Integration Complete main function path Build upon main with additional functions which are added individually. Thus when errors are found, they can be isolated to the newly added function or interface areas.

11. Documentation Project “workbook” that contains the design documentation for each function must be maintained in an up to date manner. Used as : A source for use publication. Source for test case development Control information for Continuous Integration. Source for quality control activities.

12. Inspection and Reviews Number of errors passed from one phase to the next is greatly reduced. Specific exit criteria must be met to proceed to next step. Control steps in the development cycle. Two new steps: 1.Error Prone Analysis 2.Post Functional Test Analysis

13. Inspection Preparation All appropriate and required outputs for that phase are distributed to the inspectors. They are given time to digest the material before actual inspection. Inspection itself Inspection falls between testing and formal verification. Rework Follow-Up

14. Control Steps Error-Prone Analysis step follows the coding phase. The content of the inspection results from High Level Design, Detailed Design, and Code are analyzed and any changes or corrections are then identified. The reports that are created from this step serve two purposes. 1.They will allow the developers to decide whether certain areas should be reworked before entering the Test phase. 2. The reports can also be used as additional guideline to the Testing phase in that the error prone areas may require more extensive test effort.

15. Control Step continued… Post Functional Test Analysis The results from the previous test are analyzed. Besides identifying areas which are functionally weak, the data may be used to estimate the number of errors that will occur when the system goes into production. They measure this estimation against a predetermined error tolerance level. Thus the results from Post Functional Test Analysis may be used to determine the quality of the final product.

16. Exit Criteria 1 The output from High Level Design is in flowcharts andHIPO diagrams. Flowcharts are used in structured programming, so they make an excellent tool for inspection of this phase. Exit Criteria 1 is made up of the following: 1.High level design inspection results logged into an inspection file, all necessary rework signed-off by managers and logged on the inspection file as complete. 2.The updated version of the High Level Design specification is logged into a project workbook, signed-off by managers, and distributed to : (i) project developers, (ii) testers, (iii) documentation and publications groups and (iv) product assurance group (if any), each module is assigned an owner.

17. Exit Criteria 1 3. The output serves as an input to the next phase of the development cycle as well as input for early test planning and documentation. The development cycle is considered a static part of the development environment as every function produced must go through the same cycle. The development cycle has quality controls built into it and they are the static part of a dynamic programming process paradigm.

18. Justification The objective of the previous methods was to reduce error rate and make it easier to enhance and use. This all relates to the user using the software. However, developers can benefit just as much. Their schedules will be met and cost of development will go down. It's estimated that on average a programmer makes 7 errors per 1,000 lines of code. This means even after 60% of the errors have been eliminated by testing, inspection and other quality controls that there is still errors left after release. These remaining errors are estimated to cost 70 people hours to fix per error.

19. Justification This involves identifying the problem, making the correction, compile or assemble, test and check the test. If redesigning is necessary the cost is much higher. This of course is dependent upon these being unique errors. Should these errors have additional effects that cause more time to be spent verifying they're due to the same unique error this could lead to more people hours to correct. It's a matter of whether its more cost effective to introduce the techniques into the development or to just correcting the errors as they come up. For example: to bring 3.5 errors down to 2.0 it costs 105 people hours.

20. Conclusion It is not until 60% error elimination quality control that the cost of introducing these techniques seem worth doing. However, a lower level of quality control would likely be sufficient, because machine time cost was never introduced into the comparison. They used a fixed 70 people hours per error correction, which resulted in a linear relationship between the size of the product and the error correction cost. Reasonably, the cost of fixing an error would be higher the larger the product. With the implementation of quality control you can lower error rate, making maintenance easier and lower total cost.