Anita Finke

What is CIM: an information system perspective

Model driven architecture usually is represented by computation independent model, platform independent model, and platform specific model. It is assumed that transformations from computation independent model to platform specific model via platform independent model are possible. However, authors rarely discuss the contents of computation independent model, its validity and correspondence to the notion „computation independent”. Philosophically, from the point of view of organizational information systems pure computation independent models do not exist, because information technology solutions are threading through the way people think in their task performance, decision making and information search strategies. Considering information as interpreted data it is possible to distinguish between two inter-related models in the upper level of model driven architecture, namely, human intelligence information processing model and artificial intelligence information processing model, which are titled depending on the substance of the object that interprets the data available and recognizable in the business domain.

Continuous Requirements Engineering Support Environment Model in Methodologically Heterogeneous Projects

In the result of scientific and technological evolution in Software and Requirements Engineering fields many techniques, methods and tools have been developed to support our daily work. Most of them are more suited for big organizations and companies. Of course this is a positive development that brings value to engineering. But not always these innovations bring value to small or medium companies working on Information Systems development and support projects. A good example is the issues with requirements management in long term use of requirements and system. If we use agile methods, in most cases in practice, the documentation is very poor or limited. Another example is the waterfall method where the documentation is developed in the beginning of the project, but at the end of the project the requirements can be changed (in practice). This all can bring us to certain problems in future work. For example, how will we know the build of a certain system, how it must work etc. This work is focusing on requirements inheritance and availability issue in small and medium companies with heterogeneous projects.

Lessons Learned from Experimental Prototype Development for KPI Acquisition and Modeling from Legacy ERP Systems

In this paper we consider a business case of an Enterprise Resource Planning (ERP) system vendor who needs to introduce qualitative features without making great investments in the legacy source code. We propose to extend legacy ERP system’s functionality by applying the Leading System paradigm so that business process management can be introduced. This enables business process awareness and provides opportunity for qualitative feature set introduction in a legacy ERP system. As a result, Key Performance Indicator (KPI) acquisition, modeling and analysis from the process aware legacy ERP system becomes possible. The main focus in this paper is on lessons learned about a suitable prototype architecture for KPI acquisition, modeling and analysis, and about best practices for KPI analysis from log data of business process execution.