Obvious Statements About Software Change Management: #9 The Result of an Automated ALM Process is Documentation

What we do in an automated process in each of the change states is typically managed by electronic documents. For example, if a user reports a bug this is logged as a problem. Based on this problem the process will issue a change request. If we are advanced we will flag this in the problem document and we will log the details such as the date and time when the change request was raised.

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.

Add new comment