1. © The McGraw-Hill Companies, 2006 Chapter 9 Software quality

2. © The McGraw-Hill Companies, 2006 Software Quality There are many desirable features of a piece of software. We will concentrate on the following: maintainability; reliability; robustness; usability.

3. © The McGraw-Hill Companies, 2006 The waterfall approach Until a few decades ago software developers went through a number of phases and complete each of these before moving on to the next. This approach to software development was often called the waterfall model.

4. © The McGraw-Hill Companies, 2006 The RAD approach Involves doing the activities described above a "little bit at a time";

5. © The McGraw-Hill Companies, 2006 Maintainability The requirements of an application are rarely fixed and often change over time. Maintaining a system refers to the need to update an existing system to reflect these changing requirements. Code should be designed in such a way as to make these changes easier rather than harder.

6. © The McGraw-Hill Companies, 2006 Documentation For a software system to be easy to maintain, the software design needs to be clearly documented. When developing object-oriented programs, this design documentation should include: - complete class diagrams; - clear method definitions (parameter and return types, plus pseudocode when appropriate).

7. © The McGraw-Hill Companies, 2006 Guidelines for in-code documentation When writing in-code documentation you should always include the following: comments to make the meaning of your code clear; meaningful data names; constants in place of fixed literal numbers; consistent and clear indentation.

8. © The McGraw-Hill Companies, 2006 Javadoc Sun's JDK contains a tool, Javadoc, that allows you to generate professional documentation for classes that you write. In order to use this tool you must comment your classes in the Javadoc style.

9. © The McGraw-Hill Companies, 2006

10. Reliability A reliable program is one that does what it is supposed to do, in other words what it is specified to do. When attempting to build a program, two kinds of errors could occur: –compile-time errors; –run-time errors.

11. © The McGraw-Hill Companies, 2006 Compile-time errors Compile-time errors occur during the process of compilation. Examples of these kinds of mistakes in Java include: –missing semi-colons; –forgetting to close a bracket; –being inconsistent with names and/or types; –attempting to access a variable/object without having first initialized it.

12. © The McGraw-Hill Companies, 2006 Verification Involves running your application in order to trap errors you may have made in program logic. A Java application typically consists of many classes working together. Testing for such errors will start with a process of –unit testing (testing individual classes) followed by –integration testing (testing classes that together make up an application).

13. © The McGraw-Hill Companies, 2006 Unit testing All applications require a class with a main method before they can be run. This new class then acts as the driver for the original class. A driver is a special program designed to do nothing except exercise a particular class. If you look back at all our previous examples, this is exactly how we tested individual classes. When testing classes in this way, every method of the class should be tested.

14. © The McGraw-Hill Companies, 2006 Dummy classes If you need to unit test a given class that relies upon the development of another class to which you do not have access, you can develop your own dummy class in place of the missing class. A dummy class is one that mimics an actual class in order for testing to proceed.

15. © The McGraw-Hill Companies, 2006 During integration testing check for the following compilation errors: All methods that are called must have an implementation in the receiving class The names of method calls must match the names of methods in the receiving class Parameter list of a method call must match the parameter list of the method in the receiving class The expected types of values returned from the method call must match the return type of the method in the receiving class

16. © The McGraw-Hill Companies, 2006 Black box testing

17. © The McGraw-Hill Companies, 2006 Testing equivalent groups: an example

18. © The McGraw-Hill Companies, 2006 Test data generated by examining equivalent groups of input Here, there are eight equivalent input groups. When testing this method you should test at least one mark from each equivalent group

19. © The McGraw-Hill Companies, 2006 Boundary testing In addition to taking sample test cases from each equivalent group, the boundary values in particular should be tested. In this case the following boundary values should all be tested as well as the sample from each equivalent group identified earlier: –1, 0, 1, 29, 30, 31,39, 40, 41,49, 50, 51,59, 60, 61, 69, 70, 71, 99, 100, 101

20. © The McGraw-Hill Companies, 2006 White box testing

21. © The McGraw-Hill Companies, 2006 The test log

22. © The McGraw-Hill Companies, 2006 Robustness A program is said to crash when it terminates unexpectedly. A robust program is one that doesn't crash even if it receives unexpected input values.

23. © The McGraw-Hill Companies, 2006 How robust is the SalesStaff class?

24. © The McGraw-Hill Companies, 2006 A driver for the SalesStaff class: an example of stress testing

25. © The McGraw-Hill Companies, 2006 Fixing the problem

26. © The McGraw-Hill Companies, 2006 Usability The usability of a program refers to the ease with which users of your application can interact with your program. For example, adding a help option into your menus

27. © The McGraw-Hill Companies, 2006 Escape sequences

28. © The McGraw-Hill Companies, 2006 Using the DecimalFormat objects to format decimal numbers The instructions above would lead to the following values being displayed: before 12345.6789 after 012,345.679

29. © The McGraw-Hill Companies, 2006 Optional digits (using the # symbol) This would result in the following output: before 12345.6789 after 12,345.679

30. © The McGraw-Hill Companies, 2006 Graphical user interfaces