Information Technology Reference
In-Depth Information
(c) The CR would then be allocated for Peer Review. The personnel involved
in the Peer Review would review the code to ensure that the:
a. Implementation fulfills the requirements of the CR.
b. The implementation conforms to the project guidelines and other soft-
ware engineering standards of the organization.
c. There is no trash or malicious code left in the software.
d. The changed code ensures efficiency of execution and response times.
(d) Once the CR is passed thru the Peer Review, it would be submitted for
Regression Testing.
(e) The testing team would carry out regression testing to ensure that all
changes and additions requested in the CR are correctly working and that
the original functionality is unaffected by the implementation.
(f) Once regression testing is completed and all defects pointed out either in
peer review or regression testing are resolved and closed, then the artifact is
promoted to the next stage and the CR is closed in the CRR.
8.6 CRR
The CRR is used to record all the CRs received from any source and track each
one to closure. The actual format of CRR can be an excel sheet or a tool based
register. It is normally maintained electronically as soft copy.
The CRR would normally contain the following entries:
1. CR Reference number
2. Date on which the CR is received
3. Approval information including who approved it and the date of approval
4. Allocation details for Analysis including to whom it is allocated and comple-
tion date
5. Allocation details for implementation of CR including to whom it is allocated,
and completion date
6. Allocation details for peer review including to whom it is allocated, and
completion date
7. Allocation details for regression testing including to whom it is allocated, and
completion date
8. Status—open, closed or under analysis/approval/implementation/peer review/
regression testing
9. Date on which CR is closed
Table
8.4
shows a suggested CRR format.
Search WWH ::
Custom Search