Maintaining a legacy: towards support at the architectural level

Abstract

An organization that develops large, software intensive systems with a long lifetime will encounter major changes in the market requirements, the software development environment, including its platform, and the target platform. In order to meet the challenges associated with these changes, software development has to undergo major changes as well. Especially when these systems are successful, and hence become an asset, particular care shall be taken to maintain this legacy; large systems with a long lifetime tend to become very complex and difficult to understand. Software architecture plays a vital role in the development of large software systems. For the purpose of maintenance, an up‐to‐date explicit description of the software architecture of a system supports understanding and comprehension of it, amongst other things. However, many large complex systems do not have an up‐to‐date documented softwarearchitecture. Particularly in cases where these systems have a long lifetime, the (natural) turnover of personnel will make it very likely that many employees contributing to previous generations of the system are no longer available. A need to ‘recover’ the software architecture of the system may become prevalent, facilitating the understanding of the system, providing ways to improve its maintainability and quality and to control architectural changes. This paper gives an overview of an on‐going effort to improve the maintainability and quality of a legacy system, and describes the recent introduction of support at the architectural level for program understanding and complexity control. Copyright © 2000 John Wiley & Sons, Ltd.

Architectural support in industry: a reflection using C‐POSH

“…As described in [7], the Jolly Jumper did not reach the same level of quality as the MAB during the development of URSA. During the past four years, the Jolly Jumper was re-implemented from scratch using SDE-specific technology, motivated by its quality, amongst others.…”

“…In an earlier paper [7], we reported that organizational issues are considerably more demanding than technical issues when developing and subsequently introducing means for AS, i.e., an architectural methodology with an accompanying toolset. In [8], we described influential elements for AS, however, this paper is entirely dedicated to the C-POSH model for embedding AS within organizations.…”

“…These systems were very successful, hence became an asset, and particular care was taken to maintain this legacy. In [7], an overview is given of the ongoing efforts to improve the maintainability and quality of the software core of this legacy. Moreover, the paper describes the identification of the need, development, and subsequent deployment of support for program understanding and complexity control at the architectural level for SOPHO.…”

“…In the following, we first briefly recapitulate the situation medio 1999 as described in [7]. We then describe the developments during the past four years and characterize the current situation.…”

A model of factors affecting an information system's change in state

“…Enhancements to control flow logic would be expected to be of a deep structure nature because they would most likely involve changes to the semantic component of the system. Furthermore, Bril et al [25] show evidence that good understanding is supported by good documentation.…”