II.13.1 Create a Software Release Package.
Intent: The intent of this task is to construct a Software Release Package that contains all information necessary for internal support and system integration of the software.
Mechanics: All programs, documents and data are assembled and put under control. Appropriate release procedures and final SQA procedures are initiated.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Be certain that all documents, programs and data have been placed under configuration management and control (see Chapter 5, Umbrella Activities).
Do: "Test" the deliverables that are about to be released to the customer. Are they complete? comprehensible? useful? correct?
Don't: Assume that you or someone else on the project team will be around to answer questions after-the-fact. Be certain that the Software Release Package can stand on its own.
Helpful Hints
The Software Release Package should be defined as a checklist that your group or project team creates. Every item on the checklist should be considered as the package is assembled.
Deliverables: Software Release Package
II.13.2 Design and implement customer training, as req'd.
Intent: The intent of this task is to develop any necessary customer training that is required prior to use of the product. [This task is required only for stand alone applications and is not used when embedded products are developed.]
Mechanics: Technical staff and the customer meet to determine the content, format and, duration of any application training. A course outline is developed and approved by the customer and then design and implementation of the course commence.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Get help from training professionals if a formal training curriculum is to be developed.
Do: Consider alternative knowledge delivery media (e.g., video) in lieu of classroom training.
Do: Be certain to collect feedback from all customer staff who receive training.
Do: Use only experienced instructors who are knowledgeable about the product.
Don't: Assume that the user will understand how to use the application with training.
Helpful Hints
Training need not always be conducted in a classroom setting. Video-based training and even multi-media training should be considered as alternative delivery modes.
Deliverables: knowledge delivery/training component(s)
II.13.3 Establish customer integration and live-test strategy.
Intent: The intent of this task is to develop an approach for introducing the software into the customer environment and evaluating customer reaction.
Mechanics: All programs, documents and data are assembled used as the basis for an alpha and beta testing program.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has a formal mechanism for recording customer/user reactions been established?
2. Has a 'help-desk' been established for the user?
3. Have technical staff been assigned to oversee alpha and beta testing?
Do's & Don'ts
Do: Be certain that all customer reactions to the software during alpha and beta test are recorded. QFD methods can be used to help analyze results.
Do: Suggest that the customer test the documentation (e.g., user manual) as well as the executable software.
Deliverables:
1. Results of alpha and beta testing
2. Customer test status report
II.13.4 Transmit deliverable(s) to customer(s).
Intent: The intent of this task is to develop a systematic and controlled approach for delivery of the software. This major task is coupled alpha and beta testing discussed in with Task II.13.3.
Mechanics: After the Software Release Package (Task II.13.1) has been completed and reviewed and alpha/beta-test planning has been completed (Task II.13.3), a formal procedure for delivery of the product to the customer occurs. The delivery procedure contains the following steps:
1. Alpha testing of the software at the development site.
2. Beta testing of the software at the customer site.
3. Field application of the software.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Deliverables: Delivered documents, prototype or engineered system
II.13.5 Define customer feedback mechanism(s).
Intent: The intent of this task is to define a mechanism through which customer feedback can be obtained and analyzed. The feedback mechanism should be explained as part of the Software Release Package (Task II.13.1) and should begin as soon as the product has been delivered to the customer site for beta-test or field use.
Mechanics: A feedback mechanism includes both formal and informal feedback paths. Formal feedback is collected through a Software Problem Report form and a Software Change Request form. Informal feedback is collected via meetings between technical staff and the customer.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Develop feedback forms that guide the customer as a problem or request for change is described.
Do: Consider alternative modes of feedback (e.g., voice mail, electronic bulletin boards).
Do: Be certain to assign an individual with the responsibility to manage all formal feedback.
Don't: Make the formal feedback mechanisms unnecessarily complicated.
Helpful Hints
Feedback mechanisms are best if they are integrated with an electronic mail system. The feedback "forms" should be E-mail templates so that reporting is made as effortless as is possible.
Deliverables:
II.13.6 Establish "help desk" capability for customer(s).
Intent: The intent of this task is to establish a 'help desk' facility to address customer questions, inquiries and problems.
Mechanics: The help desk can be a separate organization or a project staff member or group equipped to support the customer in the use of the product.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Be certain to respond to all requests for help within t.b.d. hours.
Do: Be certain to classify every request for help so that SQA can analyze them statistically. Help desk staff should create a trouble shooting guide (that contains solution to common problems and answers to commonly asked questions) that can be distributed to all customers.
Don't: Assign individuals who are abrupt, abrasive, or obnoxious to the help desk!
Deliverables:
1. Help desk guidelines for the software
2. Assigned staff for the help desk
II.13.7 Monitor early customer application of product/system.
This activity can range from formal alpha/beta testing to the informal collection of customer feedback. A relative structured approach to the collection of customer reactions is recommended.
II.13.8 Collect and analyze customer feedback.
Intent: The intent of these tasks is to collect customer feedback and analyze it. The feedback mechanism (Task II.13.5) should be explained as part of the Software Release Package (Task II.13.1) and should begin as soon as the product has been delivered to the customer site.
Mechanics: If the product is business critical, monitoring should be direct during early use of the software. That is, staff should be on sight with the customer, addressing questions, problems in real time. The formal and informal feedback mechanisms defined in Task II.13.5 are used during subsequent stages of customer use.
Application of Formal Methods: none
Application of CASE Tools: t.b.d
Do's & Don'ts
Do: Be certain to respond to all feedback.
Do: Be certain to classify every problem report and change request so that they can be analyzed statistically.
Do: Be certain to assign an individual with the responsibility to manage all formal feedback.
Helpful Hints
Feedback mechanisms are best if they are integrated with an electronic mail system. The feedback "forms" should be E-mail templates so that reporting is made as effortless as is possible.
Deliverables:
Use Browser "back" arrow or return to APM Process Design Language Description
