Timbus - Timeless Business

Blog Post: Long-Term Software Maintenance: TIMBUS to the Rescue!

Details

Created on Tuesday, 06 August 2013 09:10

Last Updated on Tuesday, 21 October 2014 08:32

On the one hand, there is a clear tendency towards ever more complex IT systems, with complexity arising in both size and interdependencies of involved systems. On the other hand, organizations from virtually all business sectors require IT support for their business processes in order to stay ahead of the game and to remain competitive.

For ACME, Inc. (for the sake of this blog post let's just call them like that) the same is true. And therefore, they contracted the design, implementation and testing of a very large management information system (MIS) comprising of more than 15 million lines of source code (MLOC) to a systems integrator (Pinnacle, Inc.).

While the project is laboring towards final delivery of the completed system to ACME, ACME program management has been alerted to the fact, that danger may be lurking in just accepting the system – after all ACME intends to operate the system on a 30-year lifespan. For a system to be operated, maintained and adapted to changing real world requirements, aspects of quality other than functionality, such as maintainability come into play.

But how can an adequate level of maintainability be ascertained? Fortunately for ACME, the methods and techniques developed by the TIMBUS project provide the tool chain necessary to not only establish the status quo, but also to identify the necessary level of maintainability for the planned lifecycle of the relevant business processes and the supporting IT system.

In the context of TIMBUS the tools in question have been developed mainly to address the software escrow use case. In this case, the intent is to safeguard a potential transfer of responsibility for the maintenance of an IT system from the supplier to the purchaser at an unknown point in time in the future, for instance because of the discontinuation of the product by the supplier. For such an analysis, a multitude of dimensions from risk, to legal and technical aspects have to be considered.

In the case of an existing contractual agreement, such as the one between ACME and Pinnacle, the situation is a bit less complex: The existing contracts provide the framework in which the scope of delivery is made explicit, the point in time at which responsibility is transferred is known, or at least planned, and therefore the risks are fairly well known.

This leaves the technical aspects, i.e. whether Pinnacle will deliver the necessary artefacts to ACME to take over maintenance and development of the MIS once it is accepted by ACME. The model depicted in the following illustration shows the approach used to evaluate the required level of maintainability, the actual level of maintainability, the gaps and required corrective action for ACME:

With this approach, the first step is designed to ensure that no relevant artefact is left out, i.e. a comprehensive catalogue of all potentially relevant artefacts is customized to reflect the concrete use case of ACME.

In a second step the important attributes are identified, consisting of a precise specification of the target state and context in which ACME intends to maintain the system and the resulting requirements and their respective priorities. Subsequently, for all relevant combinations of artefact and attribute (not all mathematically possible combinations make sense or are applicable) a set of so-called indicators is defined.

For example, for aspects concerning the system test activities for the MIS, ACME evaluated indicators concerning existence, structure, content, actuality and availability for the artefacts test cases, test data, test environment, test tools, stubs, drivers and test documentation/reporting.

For each such combination of artefact and indicator, the TIMBUS approach offers suitable methods and tools to evaluate the status quo and its relation to the target state. This may range from conducting interviews to fully automated and tool-supported methods that parse artefacts, configuration information or their context to gather the required information.

For the concrete example this may result in the insight that, for instance, Pinnacle's system test cases may not be delivered to ACME at all as there is no contractual stipulation to do so or that no artefacts related to unit testing will be available, as Pinnacle does not conduct this kind of test.

Using this approach, ACME has been able to establish and document the target state, gain transparency concerning the status quo in relation to this target state and, thus, to regain control over future maintainability of the MIS system. In a timeframe of only three months a change program could be initiated to bridge the identified gaps. This ranges from efforts to complement the available artefacts, for instance by defining ACME unit tests, to contractual negotiations to extend the scope of the original contract to cover additional artefacts.