Resolve Change Request
The Assigned role performs the set of tasks defined within the appropriate section of the delivery
process such as requirements, analysis & design, implementation, produce user-support materials, and design test.
These tasks will include all normal review and unit test tasks as described within the normal delivery process. The CR
will then be marked as Resolved. This signifies that the resolution of this CR is complete and is now
ready for verification.
|
Verify Changes in Test Build
After the changes are Resolved by the assigned role (analyst, developer, tester, tech writer, and so on),
the changes are placed into a test queue to be assigned to a tester and Verified in a test build of the
product. A CR that has been Verified in a test build is ready to be included in a release. A CR that
fails testing in either a test build or a release build will be placed in the Test Failed state. The
owner automatically gets changed to the role who resolved the CR.
|
Verify Changes in Release Build
Once the resolved changes have been Verified in a test build of the product, the CR is placed into a
release queue to be verified against a release build of the product, produce release notes, etc. and
Close the CR.
A Closed CR no longer requires attention. This is the final state a CR can be assigned. Only the CCB
Review Admin has the authority to close a CR. When a CR is Closed, the submitter will receive an email
notification with the final disposition of the CR. A CR may be Closed: 1) after its
Verified resolution is validated in a release build, 2) when its Rejected state is
confirmed, or 3) when it is confirmed as a Duplicate of an existing CR. In the latter case, the submitter
will be informed of the duplicate CR and will be added to that CR for future notifications (see the definitions of
states "Rejected" and "Duplicate" for more details). If the submitter wishes to contest a
closing, the CR must be updated and re-Submitted for CCB review.
Typical states that a Change Request may pass through are shown in Change Request Management.
|
Evaluate and verify your results
Purpose:
|
To verify that the task has been completed appropriately and that the resulting work products are
acceptable.
|
Now that you have completed the work, it is beneficial to verify that the work was of sufficient value, and that you
did not simply consume vast quantities of paper. You should evaluate whether your work is of appropriate quality, and
that it is complete enough to be useful to those team members who will make subsequent use of it as input to their
work. Where possible, use the checklists provided in RUP to verify that quality and completeness are "good enough".
Have the people performing the downstream tasks that rely on your work as input take part in reviewing your interim
work. Do this while you still have time available to take action to address their concerns. You should also evaluate
your work against the key input work products to make sure you have represented them accurately and sufficiently. It
may be useful to have the author of the input work product review your work on this basis.
Try to remember that that RUP is an iterative delivery process and that in many cases work products evolve over time.
As such, it is not usually necessary-and is often counterproductive-to fully-form a work product that will only be
partially used or will not be used at all in immediately subsequent work. This is because there is a high probability
that the situation surrounding the work product will change-and the assumptions made when the work product was created
proven incorrect-before the work product is used, resulting in wasted effort and costly rework. Also avoid the trap of
spending too many cycles on presentation to the detriment of content value. In project environments where presentation
has importance and economic value as a project deliverable, you might want to consider using an administrative resource
to perform presentation tasks.
|
|