As with all specifications and code, a review is the simplest and most economic
way of identifying bugs. This can precede the
Item acceptance review
or (if the change is well understood)
can be that review itself. Such a review can be done by one person though it may be even more effective
to collect a number of proposed changes together and have them reviewed by several people. These
people may have a collective title such as
Change Control Board
. The points to remember are:
??? The design authority for the software to be changed must be an approver.
??? Include all the specifications which reflect the change, in the review. The simplest approach is to
have someone propose the change(s) to the relevant code and documents all together, and then
have the reviewers review them from the requirements specifications onwards.
??? Ensure that all aspects of the new feature or bug, and all the side effects are considered.
??? Formally note the change under the following headings:
??â Change description
??â List of specifications, and units affected, including their version numbers
??â Test documentation, changes required in the test plan, test specifications, procedures, etc.
This approach might appear to be very inflexible and unagile. It doesn??âĒt have to be provided:
??? The change control board is kept small.
??? The process is understood by everyone involved.
??? Change meetings are prepared for by the members, so decisions can be taken quickly.
Pages:
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254