SourceInventory Shell

FrontEndART SourceInventory Shell is framework based on J2EE technology which serves for storing, monitoring and querying System Development Lifecycle Attributes. The central database is capable of storing various kinds of metrical, structural and hierarchical pieces of IT operational information. The repository is prepared for tracking the changes of all the uploaded attributes which makes easy to analyze tendencies and trends and define action points if necessary.

The framework also consists of a graphical user interface which can be used for querying, visualizing and browsing the extracted results. The sophisticated reporting engine allows to send customized reports on regular basis to the appropriate users.

The results stored in the central repository may come from different external sources of information like the Configuration Management System, Issue Tracking System, Test Management System, etc. The framework itself does not deal with extracting the results from the external sources, it is just prepared for storing and tracking data that has already been extracted form them in format which is acceptable for upload. For the integration with external sources of information, just the appropriate conversion tools need to be developed.

One particular use case of the framework is storing and monitoring source code related quality attributes. For this purpose several extractor and conversion tools have been developed which analyze source code written in various programming languages, extract source code metrics, coding rule violations, code duplications, architectural information, etc. SourceInventory with Build Engine boundle does exactly what is needed: integrates with the most popular CMS systems, obtains source codes on regular basis, drives the analysis and extraction process, uploads the obtained results into the central repository and at last, generates custom reports which are then sent to managers and developers.

Another example use case would be to have the hardware infrastructure of a software house represented in a form of a graph. The connections of the graph would be the physical connections between the hardware components, possibly with attributes like bandwidth. An automatic tool would create the map of topology regularly, and the obtained results would be uploaded into the central repository. Any change in the topology would be reported automatically.