1. Slide 1 Construction (Testing) Chapter 15 Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc. Slides by Fred Niederman Edited by Solomon Negash

2. Slide 2 Key Definitions Construction is the development of all parts of the software itself, documentation, and new operating procedures. Testing is a form of insurance. It costs more to repair software bugs when people are depending on the programs than in earlier stages before the systems are in use. Documentation provides information to make the system easier to use and repair.

3. Slide 3 Main Tasks of Managing the Programming Effort Assigning the programmers Coordinating the activities Managing the schedule

4. Slide 4 The Programmer Paradox After an appropriate number of people are assigned to a programming task, adding more people slows down rather than speeds up completion of the project. When projects are so complex they require a large team, the best strategy is to break the project into a series of smaller parts that can function as independently as possible.

5. Slide 5 Managing the Schedule Use initial time estimates as a baseline Revise time estimates as construction proceeds Fight against scope creep Monitor “minor” slippage Create risk assessment and track changing risks Fight the temptation to lower quality to meet unreasonable schedule demands

6. Slide 6 Avoid Classic Mistakes 1. Research-oriented development If you use state-of-the art technology, lengthen planned time 2. Using “low-cost” personnel If using a significant number of entry level personnel, lengthen planned time 3. Lack of code control Use source code library to keep programmers from changing the same code at the same time 4. Inadequate testing Always allocate sufficient time for formal testing

7. Slide 7 Designing Tests The purpose is not to demonstrate that the system is free of errors; The purpose is to detect as many errors as possible

8. Slide 8 Testing Philosophy It is dangerous to test early modules without an overall testing plan It may be difficult to reproduce sequence of events causing an error Testing must be done systematically and results documented carefully

9. Slide 9 Stages of Testing Unit testing Tests each module to assure that it performs its function Integration testing Tests the interaction of modules to assure that they work together System testing Tests to assure that the software works well as part of the overall system Acceptance testing Tests to assure that the system serves organizational needs

10. Slide 10 Error Discover Rates

11. Slide 11 Testing and Object- Orientation Encapsulation and information hiding Polymorphism and dynamic binding Inheritance Reuse OO Development process and products

12. Slide 12 Test Planning Address all products created during development Test completeness of CRC cards Test cases Stubs

13. Slide 13 Class Test Plan

14. Slide 14 Unit Testing Black Box Testing Focuses on whether the unit meets requirements stated in specification White-Box Testing Looks inside the module to test its major elements

15. Slide 15 Integration Testing User interface testing Tests each interface function Use-case testing Ensures that each use case works correctly Interaction testing Tests each process in a step-by-step fashion System interface testing Ensures data transfer between systems

16. Slide 16 System Testing Requirements Testing Ensures that integration did not cause new errors Usability Testing Tests how easy and error-free the system is in use Security Testing Assures that security functions are handled properly Performance Testing Assures that the system works under high volumes of activity Documentation Testing Analysts check that documentation and examples work properly

17. Slide 17 Acceptance Testing Alpha Testing Repeats tests by users to assure they accept the system Beta Testing Uses real data, not test data

18. Slide 18 DEVELOPING DOCUMENTATION

19. Slide 19 User Documentation Intended to help users operate the system High quality documentation takes about 3 hours per page The task should not be left to the end of the project Time required to develop and test user documentation should be built into project plan On-line documentation is growing in importance

20. Slide 20 Types of User Documentation Reference documents Procedures manuals Tutorials

21. Slide 21 Designing the Documentation Structure Documentation navigation controls Documentation topics Commands and menus Common tasks Definitions

22. Slide 22 Organizing On-Line Reference Documents

23. Slide 23 Guidelines for Crafting Documentation Topics Use the active voice Minimize use of “to be” verbs Use consistent terms Use simple language Use friendly language Use parallel grammatical structure Use steps correctly Use short paragraphs

24. Slide 24 Summary The project manager needs to manage coordination, scheduling, and overall effectiveness of the project. Testing begins early in the development process and continues looking to find problems throughout the development lifecycle. Documentation helps the user quickly assimilate the new technology and provide assistance in transitioning to the new business processes.

25. Slide 25 Expanding the Domain An extensive example of on-line documentation of the Java language is available at the Sun Corporation website: http://java.sun.com/j2se/javadoc/

26. Slide 26 Expanding the Domain An excellent source of information about many aspects of computing can be found through the IEEE Computing Society, and in particular through their software development conferences. See the following for a list of proceedings: http://www.computer.org/proceedings/compsac