In organisations where large volumes of source code are managed, it is essential to actually know what is in this source code, in a qualified as well as quantified way. Such inventories can be useful in predicting the size and complexity of projects (using methods such as the COCOMO model), in measuring the dependency on environment-related tools, such as database manager and transaction processing monitor, in evaluating the cost of a Y2K migration project, etc...

However, in many cases, the only available information is based on line counts. Some simple measures can be made with text-processing tools, but this remains far beyond the true need of measuring and managing the source code real-estate.

RainCode Roadmap can help. It can be used to produce inventories of different kinds, finding some statements or some forms of statement, uses of files or databases, inter-program relationships, etc... The true added value lies in its ability to inventorise virtually anything. It is not restricted to a specific kind of inventory or even to a number of predefined inventories, and the information it produces can be indexed in different ways, depending on the circumstances.

For instance, when considering a CICS to TUXEDO migration, one must evaluate the cost of the translation which is a function of the number and nature of the CICS statements that can be found in the code. As part of this first time inventory, those of the CICS statements that can be translated automatically to their TUXEDO counterparts are counted as well, so that the relevancy of the development of an automated solution for such case (possibly using RainCode's patching facility) can be evaluated.

Then, as the project goes, the progress of the migration can be measured, one can evaluate whether the project is running behind or ahead of schedule, one can also perform some sanity checks and detect some errors in the translation from CICS to TUXEDO, etc...

In a Y2K project, inventories are present at all stages of the migration: beforehand, to evaluate the number of places where an automatic or semi-automatic patch has been performed; during the actual migration to monitor the project's progress; and after the migration to ensure that it is completed properly, and that the patches that have been applied repeatedly are correct and conform to the organisation's guidelines.