V.36 Evaluate the reengineered deliverable
V.36.1 Deliver product to each customer.
Intent: The intent of this task is to develop a systematic and controlled approach for delivery of the software.
Mechanics: After the Software Release Package (Task V.35.9) has been completed and reviewed and alpha/beta-test planning has been completed), a formal procedure for delivery of the product to the customer occurs.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Deliverables: Delivered documents, prototype or engineered system
V.36.2 Define feedback mechanisms.
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 V.35.8) 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:
1. Software Problem Report
2. Software Change Request
V.36.3 Refine help-desk to accommodate multiple customer locations.
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
V.36.4 Conduct training and provide implementation support.
V.36.5 Collect and analyze customer feedback.
Intent: The intent of these tasks is to collect customer feedback and analyze it. The feedback mechanism (Task V.36.2) should be explained as part of the Software Release Package (Task V.36.2) 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 V.36.2 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:
1. completed Software Problem Report
2. completed Software Change Request
3. results of feedback analysis
Reengineering Tasks V.29 through V.36 are iterative in nature. That is, an actual reengineering project might approach these tasks in a number of planned increments, each designed to produce a deliverable that can be evaluated by the customer.
Use Browser "back" arrow or return to APM Process Design Language Description
