A method for comparing traditional and component-based models in information systems re-engineering

Abstract

Many organisations have become aware of the limitations of their legacy systems to adapt to new technical requirements. Trends towards e-commerce applications, platform independence, reusability of pre-built components, capacity for reconfiguration and higher reliability have contributed to the need to update current systems. Consequently, legacy systems, typically designed and developed using traditional methods, need to be re-engineered into new component-based systems. The objective of the study is to develop a method to compare traditional and component-based models of systems. Design science is the approach used to build and evaluate the method. The method incorporates and integrates existing methodologies for information systems re-engineering and conceptual model evaluation. A case study illustrating the comparison method revealed that a reengineered component-based conceptual model was capable of representing and enriching all the traditional conceptual model constructs. However, there was a conflict with the use of data flows as these can represent both events and also couplings between processes, data stores, and external agents. Thus, the project derived an additional set of rules to use when generating a component-based model to improve the re-engineering step.

Navigating Complex Systems Design with the PEArL Framework

“…The NASA (2011) Vee model is the basis for the International Standard for Systems Engineering: ISO 15288 and hence is widely applied in engineering firms as a broad framework for creating and building complex systems and products. The Vee model facilitates a component-based view of the systems under development which has, to date, made such projects manageable (Boehm and Basili, 2001;Valverde et al, 2011). But the component based approach to systems design also creates significant practical challenges when building complex systems, as unforeseen and unexpected relationships between systems often only become apparent when a design enters the build phase.…”

“…Issues identified at a late stage of the development process are notoriously difficult and expensive to fix. For example, unexpected integration issues between software controllers embedded in 'black box' components sourced globally can lead to expensive changes and reworking of designs further down the work stream (Holmstrom and Sawyer, 2011;Valverde et al, 2011).…”

A pattern based approach for data quality requirements modelling

“…For example, product artefacts can be found in Roser et al (2006) where the authors produce models for cross-organizational business process coordination and, in Purao et al (2003) where the authors developed analysis patterns to improve conceptual designs. On the other hand process artefacts can be found in Rosenkranz and Holten (2011) where the authors build the Variety Engineering Method (VEM) as a process artefact to analyse, diagnose, and design information flows similarly, in Valverde et al (2011) the authors develop a specific software engineering method as a process artefact to compare traditional and component-based models of systems in systems re-engineering.…”