Our Requirements Document was quite complete, which ensured that we were creating the right product. The requirements were extremely stable, which made for very little rework. Most of them were straightforward, and only a few were misunderstood (such as the Tagged Array).

The design and coding were sufficient, but more comments in the code would have been helpful. The unit testing wasn’t too helpful, since we didn’t use it until after the modules had already been integrated into the main build for quite some time. At this point, the modules had already been exercised quite a bit and most of the defects had already been located and fixed.

Since our program was small enough, private builds tended to work out any inconsistencies. Hence the daily build never broke, but we were able to confirm that everything was working OK.

When we stuck with the project plan, our releases came out fine. On the other hand, when we ventured off and ignored the project plan, our releases tended to fall apart.

It helps if the program is done in time to test. It was helpful to allocate a large chunk of time before a release to devote to testing (in other words, no new code was added). It also helps to have a very thorough test plan. Automated testing on a project this small wasn’t worth the time it took to learn the tools and set up the automated test cases. A better testing tool than TRecorder would have been extremely useful, too.

Some tools saved us a huge amount of time and effort, such as Whiteboard and Teamatic. Other tools, such as JMetric, took more time to learn to use than we were expecting, which caused us to fall behind schedule.