Information Technology Reference
In-Depth Information
become worried about the basic certifi cate record processing fl ow design. The de-
sign is complex and not stabilizing quickly. If this design is faulty, it could contribute
to the defect counts for all the top scoring screens.
On a hunch, you check with the testers assigned to test case PT-04.0 and -07.0,
which measure the response times of certifi cate record counting, printing, and back-
ing up. The performance tester alerts you that when small numbers of certifi cate re-
cords are tested (less than 10), the process completes within the specifi ed maximum
response time. However, when a larger number of certifi cate records are tested, the
response time for each process becomes unacceptably slow as the number of records
increases. The specifi ed maximum response time is exceeded when the certifi cate
master fi le grows to 230 records, well before the 311 records per week expected dur-
ing next year.
The puzzle pieces begin to fall into place. The basic certifi cate record process-
ing fl ow design presents two signifi cant risks to CPI if only piecemeal action is taken
against the defects found so far. The fi rst risk is that the design code will not stabilize
regardless of the amount of effort the developers invest in trying to make it work.
The second risk is that when the design code stabilizes, it will always fail the per-
formance requirements. Based on these two risks, you recommend that a new basic
certifi cate record processing fl ow design be implemented in the Final construction
stage and that a moratorium be imposed on any further testing and correction of the
current design in the Preliminary construction stage.
This process of analyzing test results and inferring the usefulness (economy) of
further testing responds to the ā€œEā€ in SPRA E . The test team begins to see patterns
of test execution results that imply continued program code instability. As a result,
the testers recommend stopping testing the unstable code in lieu of redesign or re-
programming. This tester recommendation provides economy of project resources
by minimizing any further time spent on code that may never stabilize suffi ciently
to be used in production.
13.5.7 Exiting the Preliminary Construction Stage
Several events occur during the Preliminary construction stage that will shape
the plans for the Final construction stage. The fi rst event is the root cause analysis
of the majority of the Preliminary construction defects. Based on the root cause
analysis conclusions, the development manager decides to have the basic certifi -
cate record processing fl ow redesigned in an attempt to stabilize the code. Because
the use cases state what needs to be fi nished and not how , the redesign does not
cause a requirement modifi cation, only a specifi cations modifi cation at the next
level of development detail. The authors recommend that a defect log entry be
made against the certifi cate record processing fl ow specifi cation in order to fully
document and track the redesign effort and outcome.
The next completion shaping event is CPI asking DSA for suggested approaches
to cut over to the new automated system from the manual system. The CPI project
team asked the DSA representatives about possible cutover plans during the Design
Search WWH ::




Custom Search