slide 1 construction (testing) chapter 15 alan dennis, barbara wixom, and david tegarden john wiley...
Post on 01-Jan-2016
217 Views
Preview:
TRANSCRIPT
Slide 1
Construction (Testing)
Chapter 15
Alan Dennis, Barbara Wixom, and David Tegarden
John Wiley & Sons, Inc.
Slides by Fred NiedermanEdited by Solomon Negash
Slide 2
Key DefinitionsConstruction 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.
Slide 3
Main Tasks of Managing the Programming Effort
Assigning the programmersCoordinating the activitiesManaging the schedule
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.
Slide 5
Managing the Schedule
Use initial time estimates as a baselineRevise time estimates as construction proceedsFight against scope creepMonitor “minor” slippageCreate risk assessment and track changing risksFight the temptation to lower quality to meet unreasonable schedule demands
Slide 6
Avoid Classic Mistakes
1. Research-oriented developmentIf you use state-of-the art technology, lengthen planned time
2. Using “low-cost” personnelIf using a significant number of entry level personnel, lengthen planned time
3. Lack of code controlUse source code library to keep programmers from changing the same code at the same time
4. Inadequate testingAlways allocate sufficient time for formal testing
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
Slide 8
Testing Philosophy
It is dangerous to test early modules without an overall testing planIt may be difficult to reproduce sequence of events causing an errorTesting must be done systematically and results documented carefully
Slide 9
Stages of TestingUnit testing
Tests each module to assure that it performs its function
Integration testingTests the interaction of modules to assure that they work together
System testingTests to assure that the software works well as part of the overall system
Acceptance testingTests to assure that the system serves organizational needs
Slide 10
Error Discover Rates
Slide 11
Testing and Object-Orientation
Encapsulation and information hidingPolymorphism and dynamic bindingInheritanceReuseOO Development process and products
Slide 12
Test Planning
Address all products created during developmentTest completeness of CRC cardsTest casesStubs
Slide 13
Class Test Plan
Slide 14
Unit Testing
Black Box TestingFocuses on whether the unit meets requirements stated in specification
White-Box TestingLooks inside the module to test its major elements
Slide 15
Integration TestingUser interface testing
Tests each interface functionUse-case testing
Ensures that each use case works correctlyInteraction testing
Tests each process in a step-by-step fashionSystem interface testing
Ensures data transfer between systems
Slide 16
System TestingRequirements Testing
Ensures that integration did not cause new errorsUsability Testing
Tests how easy and error-free the system is in useSecurity Testing
Assures that security functions are handled properlyPerformance Testing
Assures that the system works under high volumes of activity
Documentation TestingAnalysts check that documentation and examples work properly
Slide 17
Acceptance Testing
Alpha TestingRepeats tests by users to assure they accept the system
Beta TestingUses real data, not test data
Slide 18
DEVELOPING DOCUMENTATION
Slide 19
User DocumentationIntended to help users operate the systemHigh quality documentation takes about 3 hours per pageThe task should not be left to the end of the projectTime required to develop and test user documentation should be built into project planOn-line documentation is growing in importance
Slide 20
Types of User Documentation
Reference documentsProcedures manualsTutorials
Slide 21
Designing the Documentation Structure
Documentation navigation controlsDocumentation topics
Commands and menusCommon tasksDefinitions
Slide 22
Organizing On-Line Reference Documents
Slide 23
Guidelines for Crafting Documentation Topics
Use the active voiceMinimize use of “to be” verbsUse consistent termsUse simple languageUse friendly languageUse parallel grammatical structureUse steps correctlyUse short paragraphs
Slide 24
SummaryThe 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.
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/
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
top related