When the developers have received their assignments, we need to see which software components they will change as a result of the development task they have been given. Before allowing a change, a copy is made of the previous version so that a roll back can occur, if required. This copy is also useful to see the differences between this copy and future versions.

After the programmer has made the changes, the testers can perform their work. All of their work including test results should be logged and documented. In addition formal signoff needs to be recorded before the change is allowed the transition into production.

If you do this for a while, and if you are able to open up your database, then you can create all kinds of documentation, whether it is aimed at the end-user, the developer (see #2) or your SOX auditor (see #4).

The picture shows an example of a drill down view on all historic changes of a program called PGM01. This view can exist because the ALM process provides automatic documentation.