to record unit testing scripts and results. These in turn can be used by the test teams to help ensure that their verification suites are updated, though developer test scripts should serve as an alternate accounting of the required tests to complement those developed by the verification team. CM/ALM tools should also make it easy to do peer reviews. It should not be necessary for all peer reviewers to meet at the same time to review the changes. On-line reviews, with comments and responses, should be easily managed by the CM tool. As well, it should be easy for architectural gurus, and others involved in multiple reviews, to perform multiple reviews in succession with minimal keystrokes. The CM tool here can help by tracking reviewers, providing reviewers with To-Be-Reviewed in-boxes, and by providing effective dashboards to navigate change packages in these in-boxes. It should also help by providing point-and-click traceability to the specs, problem reports or other data from which the changes were derrived.
So there you have it. Another 10 CM Best Practices geared for Next Generation projects, processes and tools. Combined with my previous "Best Practices" article, we've covered a lot of ground. If you want your CM to be more effective, run through these practices, where applicable, and through the previous 20 I've referenced. Let me know if you disagree with them, and I'll either try to convince you otherwise or change my mind. If there's some that I've still not covered, don't be surprised, but let's hear from you so that I can cover them in the "reply" section or in a future column.