1. Acceptance and Delivery
CSCI 5801: Software Engineering

2. Acceptance Testing
Complete system is tested against the requirements by client, assisted by developers
including documentation, training materials, installation scripts, etc.

3. Acceptance Testing
Black box testing by the client without knowledge of the internal structure
The entire system is tested as a whole
Emphasis on whether system meets requirements
Tests should use real data in realistic situations, with actual users, administrators, and operators
The acceptance test must be successfully completed before a new system can go live/replace a legacy system
Completion of acceptance test may be a contractual requirement before the system is paid for

4. Acceptance Testing in Iterative Models
Customer will have already tested many parts of the system
At the end of each iteration
During user testing in XP
Problems and suggestions for improvement will have been incorporated
Must still be an acceptance test of the final version before it is released
Customer is ultimately interested in system as a whole

5. Acceptance Testing Good acceptance testing requires careful planning
For each functional requirement:
Describe scenario to customer
Allow them to accomplish scenario on system
For each non-functional requirement:
Create stress test that describes “worst case scenario” within bounds of requirements
Explain and demonstrate system passes stress test

6. Acceptance Testing
Acceptance testing ultimately controlled by customer
During one test, customer may want to follow another branch (“what would happen if I…”)
Role of developers is to provide assistance when necessary
Introduce scenario, its goals and major steps
Give customers guidance to accomplish steps when needed

7. Testing and Release Stages
Alpha Testing:
Clients operate the system in a realistic but non-production environment
Example: Prof. Bodnovich uses system pretending to be employers/students
Beta Testing:
Clients operate the system in a carefully monitored production environment
Example: Select employers and students are allowed to use the system, providing feedback on its usability

8. Testing and Release Stages
Parallel Testing:
Clients operate the new system alongside the old system with same data and compare results
Can be expensive and may take months!
Requires two of everything (staff, equipment, etc.)
Requires software to control changeover (do not mail two sets of payments, etc.)
Requires automated scripts to compare results
Ideally, the new system will be brought into production incrementally

9. Other Deliverables Everything needed to install software Help systems
Configuration files
Data files needed for system operation
An installation program or shell script to install the system on target hardware
Help systems
Training materials

10. Help Systems
Users need many routes to find information (people learn in different ways)
Index by many terms
Examples
Tutorials
Help systems need to be tested with real users (just like other parts of system)
Tradeoffs
A good help system requires a major commitment (time, expense, difficulty)
A good help system saves user time and support staff effort

11. Training
Providing users with knowledge necessary to fulfill role in system
Types of training:
One on one training sessions for critical users
Classes for large groups of every day users
On-line tutorials for other users
Help materials

12. Help and Training Systems
Different materials (at different levels of detail) for different users
Different types of users (faculty, advisors, students in Banner)
System maintenance
Other trainers…
Different skill levels need different types of training
Skilled users work from the conceptual model, relating the system to a task they already know well
Less-skilled users prefer cookbook sets of instructions
Occasional users will forget complex details, but remember general structure, so will need reminders when requested