Acceptance and Delivery

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
• 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