The Formal Problem Tracking lifecycle is used to evaluate problem information and then hold formal reviews to determine the final disposition of modification requests. This lifecycle has no views because it is unnecessary to see or change any repository items. All the information being tracked is in the forms and packages; this lets management track when a modification request was created, the length of time taken to investigate the information, and the disposition of that investigation.
The emphasis in this lifecycle is the Review Board state. Every package must be reviewed in the Review Board state before it can be promoted. You can schedule meetings in the following ways:
During the Review Board meeting, a member promotes packages in accordance with the Review Board decisions, and can generate a report that details the results of the meeting.
Note: An alternative is to allow a single person to be responsible for the Review Board state. This person reviews each request when it is promoted, and if it is a minor request, has the authority to promote it with no Review Board approval needed. This person should be someone other than the one who promotes the requests at the Review Board meeting; two different approval processes are required, each with different rights. A user-defined process is then added to the promotion of the request to validate its priority before it is promoted.
The lifecycle can be used as a stand-alone project or can be added to another lifecycle. With a stand-alone project, requests are initiated in one project for all projects and then moved to the appropriate project when ready to be fixed. This is particularly helpful when maintaining one version of a product while working on the next version. The fix might be needed in either version or in both. By generating the request in a stand-alone project, you can select its destination.
|
Copyright © 2013 CA.
All rights reserved.
|
|