OPRR – A Model for Modelling Systems Development Methods

Current CASE tools support a limited number of methodologies. In contrast, every organization has adopted its own ways to develop information systems, limiting the applicability of the fixed methods that CASE tools support. To overcome this problem new methods are needed for defining and customizing methodologies for CASE tools. A model by which methods can be modelled is introduced. It is called the OPRR datamodel (after Object-Property-Role-Relationship model). Also necessary graphical extensions that allow the definition of graphical modelling languages are introduced. An example which demonstrates how OPRR can be used in method modelling is shown. Finally, the shortcomings in the model are noted and some extensions to the basic model to remove these shortcomings are proposed. * This research is funded by the Academy of Finland and the Finnish Center for Technical Development 1 . I N T R O D U C T I O N Despite the extensive interest in Computer-Aided Software Engineering (CASE), connections between systems development methods and CASE-tools are rarely discussed. The introduction of CASE to an organisation is understood as a straightforward solution to a technical problem, in which common analysis and design methods are taken into use with automated tools. Moreover, it is typically believed that the new technology will speed up systems development and produce higher quality systems that satisfy users better (e.g. Fairbairn, 1990). Little attention is paid on whether the methods that the tools support are suitable for the application area and the ongoing development practice. However some research results (cf. Le Quesne, 1988, Smolander et al., 1990) show that the technology alone is not the solution to the systems development problems. For example, technology can not bring about changes that are beyond the systems development skills and knowledge in an organization. The systems development methods that an organization can use depend on the skills and knowledge, differing from an organization to an organization. Still the methods support of CASE tools is usually fixed, leaving a minimal room for customization. Every organization has its own history and its methods that are shaped by prior experiences and trial and error learning. Hence, the organization's methods are not necessarily the same as the methods supported by the tools. In addition, different systems development problems require different methods of analysis and design. Different problems may therefore lead to the use of different CASE tools. As a result there would be no integrity between various pieces of design information. A solution to the problems above would be to develop a systems development environment which could support the use of multiple methods concurrently. It would be based on a general datamodel which would help to map the features of systems development methods onto a “methodology specification”. In this type of environment, systems developers could use computer supported situation dependent methods, and still be able to communicate and transport design information between projects with different methodical needs. Although there are some research prototypes of multiple methods environments coined as CASE-shells (Bubenko, 1988), they are not common yet. Some examples of such environments with definable methods are RAMATIC (Bergsten et al., 1989), MetaEdit (Smolander et al., 1991), and MetaView (Sorenson et al., 1988). Still, what is lacking is a well established theory of meta-models and multiple, concurrent methods. What would be the best or the most suitable model to define systems development methods and methodologies? Some proposals have been published (e.g. Teichroew et al., 1980,