SMEA/L: AN APPROACH TO ENGINEERING SITUATIONAL METHODS BY
MATCHING PROJECT SITUATIONS TO EXISTING ISD-METHODS
Karel Lemmen
Faculty of Engineering, Open University of the Netherlands, P.O. Box 2960, 6401 DL Heerlen,
the Netherlands, e-mail: karel.lemmen@ouh.nl
Sjaak Brinkkemper
Baan Company, R&D, Software Engineering Process Group, P.O. Box 143, 3770 AC
Barneveld, The Netherlands, e-mail: sbrinkkemper@baan.nl
Abstract
Organizations are always struggling with the development of information systems. One of the
problems is to find a uniform approach to information systems development (ISD) that is
flexible enough to adapt to the actual project situation. In this respect Method Engineering is
very promising. The approach to Method Engineering presented in this paper – the SMEA/Lmodel – shows that uniformity and flexibility in ISD can be achieved by characterizing and
matching project situations and methods for ISD on a common basis. Opportunities offered by
the Internet create the possibility to make such an approach company wide available as an
interactive tool for management consultants.
Keywords
Method engineering, situational methods, efficient information systems, Internet services
1
INTRODUCTION
In their day-to-day business of developing information systems, organizations are confronted
with many different methods that can be used for the design process. Each method copes with
its own problem area or development paradigm. The Yourdon method (Yourdon, 1989), for
example, deals with the analysis of processes in an organization, whereas a method such as
OMT (Rumbaugh et al., 1991) is based on the object-oriented paradigm. It seems there is a
specific method for each problem area. An alternative approach would be to develop a
universally applicable method. The possibility of such a method has already been disputed by
Malouin and Laundry (1983), Benyon and Skidmore (1987) and more recently by Rijsenbrij
(see Vlasblom et al., 1995). Rijsenbrij presents the absence of a universally applicable method
as an important overall statement with respect to ISD.
Apart from their problems with ISD, organizations conclude that in reaching their strategic goals
communication services such as EDI and Internet are becoming more and more important. From
its academic beginnings, the Internet has grown to a stage where it is paving the way for future
business communications. Its current success rides largely on the www’s flexible and userfriendly presentation of information. New opportunities arise: the increasing availability of
commercial tools for content preparation and knowledge management meet the most pressing
business needs.
1
Many companies recognise these opportunities offered by Internet not only as a customer
benefit, but also as an internal communication tool. The latter opportunity is better known as
Intranet. KPMG for example, an international oriented Management Consultancy firm with
offices all over the world, launched Knowledge Manager (K-man) based on Internet-technology.
We will discuss the Methods & Tools section of K-man that aims at providing a uniform
approach to the efficient development of information systems.
1.1
Situational Method Engineering
In order to have an answer to the struggle with ISD in the nineties the idea arose to construct a
situational dependent ISD-approach (Kumar & Welke, 1992) by combining (parts of) existing
methods. Thus we can combine the best parts of existing methods and develop an optimal
solution for a given problem(area). Such (coherent) parts of methods are called method
fragments. The approach of adapting and combining (parts of) different methods is also known
as Situational Method Engineering (Harmsen, 1997). Van Slooten and Hodes (1996) use the
term Situated Method Engineering, while Rolland and Prakash (1996) propose Context-Specific
Method Engineering. The feasibility of Situational Method Engineering approaches is recently
discussed in a paper by Ter Hofstede and Verhoef (1997).
In this paper we present an approach to Situational Method Engineering (SME) based on a
framework for ISD. Over the years several frameworks have been proposed e.g. by Olle et al.
(1991), Sowa & Zachman (1992), van Swede & van Vliet (1993) and Van Slooten (1995). Such
frameworks are aimed at giving an overview of the process of ISD and they are mostly based on
empirical experience with that process in combination with a theoretical view on ISD. The
framework we use is based on the work of Essink (1988) and will be explained in section 2.
2
SMEA/L: AN APPROACH TO SITUATIONAL METHOD ENGINEERING
We already mentioned that in SME we are confronted with the question: “Which method or
method fragments should be combined in order to create an optimal solution for a specific
project situation?” To answer this question we should have an approach for matching a project
situation to existing methods. A second question a method engineer has to answer is: “How
should methods and selected fragments of method be assembled in order to get a coherent
situational method?” Answering these questions leads to approaches to SME. We start with
introducing the A/L-framework as a view on the process of ISD.
2.1
The A/L-framework
ME frameworks give an overview of the process of IS development and are usually based upon
a combination of empirical experience and theoretical views. Over the years, several
frameworks mainly related to the analysis and design process in IS development have been
proposed. This limited scope also holds for our A(spect)/L(evel)-framework (Figure 1) which is
based on the work of Essink (1988).
2
Figure 1
The A/L-framework
Each element of the A/L-framework stands for one particular aspect (A) on a specific modelling
level (L) of IS development. The framework has 8 x 4 = 32 entries. We indeed observe that the
A/L-framework concentrates mainly on the analysis and design aspects of IS. The strength of the
framework is that it enforces the same set of aspects at each modelling level. The four modelling
levels are:
 OSM, describes the part of the organization for which an IS should be designed and realized
(the ‘why’ question);
 CIM, views the IS as a set of (functional) components by which the information
requirements of the users should be fulfilled (the ‘what’ question);
 DSM, considers the IS as a data processing system (the ‘how’ question);
 IPM, views the IS as a concrete, operative and maintainable system (the ‘with what’
question).
With respect to the eight different aspects we conclude that five of them (the shaded area in the
framework) concern the architecture of the system, starting from a conceptual view (OSM,
CIM) up to and including the implementation view (DSM, IPM). The remaining three aspects:
goal structure, allocation and realization, should be considered in order to identify the goals,
meaning and feasibility of the chosen architecture and to view the system as an operational and
functional system. More details on the framework can be found in Lemmen et al. (1993).
2.2
The SMEA/L-model
Using the A/L-framework, ME proceeds as illustrated in a simplified way in Figure 2.
Figure 2
The SMEA/L-model (simplified view).
3
SMEA/L is an acronym for Situational Method Engineering with the A/L-framework. The A/Lframework is used in three different ways. In a generic sense the existing methods for IS
development are mapped onto the framework. In a specific sense each particular project
situation is to be characterized through the framework. And finally the project situation can be
matched within the framework with the available methods resulting in a ‘best fit’ method or a
‘best fit’ construct or assembly of parts of different methods. Figure 3 illustrates the process of
matching.
Figure 3
Matching
An example of characterizing a project situation and evaluating methods will be described in the
next sections, including the process of matching.
The SMEA/L-model has been elaborated in more detail in Punter and Lemmen (1996).
Approaches to describe and fragment methods can be found in Harmsen and Brinkkemper
(1995) and Harmsen (1997). An approach for characterizing project situations can also be found
in Van Slooten and Hodes (1996). The above-mentioned papers also describe practical
experiences with SME. The SMEA/L-model itself is also part of a research project in which the
approach is used in an educational setting. In that project we validate the feasibility of SME
with experienced practitioners and also use the approach for evaluating information system
curricula. This can for example be found in Lemmen, Mulder and Brinkkemper (1997).
3
PROJECT CHARACTERIZATION: MAPPING A SITUATION ONTO THE
FRAMEWORK
The characterization of a project situation according to the presented model for Method
Engineering implies the mapping of the initial problem onto the framework. Mapping means
that we have to determine which of the 32 entries of the framework are related to the actual
project situation. Mapping onto an entry takes place if it supports to the modelling process in
order to solve the problem stated in the project. Guidelines for doing this can be found in
Lemmen et al. (1993). Because of the limited space we cannot elaborate on them here. We
remember the fact that each entry of the framework concerns a specific aspect of ISD on a
specific modelling level. In most cases a problem is related to more than one entry in the
framework.
We illustrate the characterization of a project situation with the aid of the A/L-framework with
an example (case study). We have the following global description of a project situation:
A manufacturer of sailing boats called HOISTED SAIL employs 120 men of whom six are
working with the EDP-department. HOISTED SAIL delivers sailing boats on demand. The
4
planning of the company’s production process is done by an information system called
Logisplan. The system generates the list of materials needed to produce each sailing boat. It
also determines the production lines on which a boat is soldered, assembled and dyed. Input
data for the system includes specifications such as the size and colour of the sailing boat. The
system has functioned well since its implementation eight years ago.
The management however is not satisfied. Using the present system, the exact delivery date and
price of a sailing boat cannot be given to clients in advance. Experience learns that such
information is important for clients when deciding to buy a boat. The lack of information is a
problem for the sales representatives. The management expects the sales function would be
supported with more accurate data if Logisplan and the sales system were integrated.
Therefore both systems should be integrated.
A discussion between the members of the management team leads to the following more
detailed description of the problem:
There are some doubts whether the functionality of Logisplan should be further extended. After
discussing this with different employees in the organization the idea arose to integrate the
system with other company systems, such as the sales system and the financial systems. The
boundaries of the new system are not yet specified exactly. It is not clear if several parts of the
integrated system can be matched. Perhaps it will be necessary to automate activities that are
not yet part of the current systems. The management of the company has also proposed to
support the integrated system by communication facilities such as EDI (electronic data
interchange) in order to improve the accuracy for the data of the sales representatives.
We can characterize the situation by analyzing the text. Sentences in the text that describe the
problem are related to entries in the A/L-framework. After explaining each sentence, a number
appears. This number is used to depict the mapping of the project situation onto the framework
(see figure 4). The abbreviations used in the figure are self-explaining in relation to the A/Lframework.
Figure 4
The project characterization for HOISTED SAIL
– The idea of integrating the system with other company systems.
This implies the setting up of development goals. These goals are related to the function and
quality of the integrated system. We have to determine the exact information problems. Is the
lack of information for the sales representative, for example, the only information problem?
These are questions on the aspect domain of goal structure (GS) on the level of conceptual
information system modelling (CIM) (1).
– The boundaries of the integrated system are not yet specified.
5
We must determine which of the former systems becomes part of the new integrated system.
This depends on the goals of the integrated system. The boundaries of the new system and the
communication between the system and its users have to be determined. This is a question
related to the domain aspect environmental interaction (EI) on the level of CIM (2).
– It is not clear if the several parts of the integrated system can be matched.
Combining the systems for planning and sales, for example, makes it necessary to have data
about stocks available. Therefore a supply function has to be incorporated. If such a subsystem
is not yet available it has to be developed. A new model of entities and data collections could be
developed. It depends to what degree the required functionality is covered by the existing
systems. The determination of the functionality of the integrated system and the necessary data
collections are subjects of the aspect functional structure (FS) and entity structure (ES) on the
level of CIM (3,4).
– Perhaps it is necessary to automate activities which are not yet part of the current systems.
If a missing sub-system, such as the stock system, has to be developed, we need to know the
organization’s relevant activities and the relationship between these activities and the
environment such as clients and suppliers (functional structure (FS) and environmental
interaction (EI) on the level of OSM (5,6)).
– To support the integrated system with communication facilities.
The subject of supporting communication facilities deals with environmental interaction on two
different levels of the framework. Firstly it is related to the way in which in- and output
processes are implemented, e.g. the communication could be done automatically (with EDI) or
manually (by telephone). This is subject to the level of DSM (7). Secondly the technology used
for communication is important. When a sales representative has questions about delivery dates
or prices this could handled over the phone. When he or she places an order it has to be written
down on paper. In the near future it can probably be done by EDI. This is subject to
environmental interaction (EI) on the level of IPM (8).
At this stage we must recognize that different messages have a different impact on the
integrated system. For example a request for information starts up a process which generates
data for the sales representative. An order, on the other hand, generates planning which results
in the production of a boat. This forces us to pay attention to system dynamics (SD) on the level
of DSM (9). This modelling area concerns about input processes. It describes the resulting
database transactions that have to be triggered
Figure 4 demonstrates a first characterization of the problem. It is clear that in discussions e.g.
with the management of the company, it could lead to further refinements of the mapping.
4.
MAPPING A METHOD ONTO THE FRAMEWORK
By mapping an ISD-method onto the framework we also determine the entries in the framework
that are covered by the method. Each entry can be seen as an activity during the process of
system analysis and design to deliver specific products related to the new IS. In order to
organize the process of mapping methods onto the framework in a more structured way, we
need a template to describe methods. This template will be represented as an entity relationship
diagram (figure 5). It is called the Method Entity Model.
6
Figure 5
The Method Entity Model
Every method can be split up into phases. For example in Information Engineering we can
distinguish the phases Strategy Planning and Business Area Analysis. Each phase in turn
consists of one or more design steps that may consist of sub-steps or activities. Design steps can
be anything from a technique to construct a product, such as a DFD, to a decision mark or a
named but not elaborated step.
However, the most important goal of a method is to deliver a product, namely (a contribution
to) an information system. A product is usually delivered during those design steps that use
techniques. A technique consists of a procedure that in turn is supported by specific ways of
describing results (notation). For example, entity relationship modelling offers a way to present
an entity relationship diagram including a procedure on how to construct such a diagram for a
specific situation.
Based upon the Method Entity Model, the starting point of mapping a method onto the
framework is a general indication of how the method fits onto the entries in the framework.
During this step we only focus on phases of the method. Investigating how the different steps in
each phase are related to the entries in the framework refines the mapping. Mapping of design
steps means that we try to investigate the contribution of each step to a specific entry. The same
guidelines as mentioned earlier can be applied in order to map a method onto the framework
(see Lemmen et al., 1993).
In order to demonstrate the mapping process, we will evaluate a version of Modern Structured
Analysis (MSA) by Yourdon (1989). MSA has the following structure in relation to the Method
Entity Model:
Phases
Steps (sub-steps)
Analysis
Essential model
Environmental model
Goal description
Context diagram
Event list
Behavioural model
7
Process model
Process specifications
Data dictionary
Data model
State (transition) diagram
User Implementation model
Design
Implementation model
System Implementation model
Processor model
Task model
Module model
Figure 6
Structure of MSA related to the Method Entity Model
The essential model is related to the analysis phase. The functionality of the IS is elaborated.
Therefore the essential model is almost completely mapped onto the CIM-level. The design
phase on the other hand deals with the implementation model. It is mapped onto the levels
DSM and IPM. The third model is the user implementation model. It is part of the analysis
activity and describes the translation from the essential model to the implementation model. It
appears on different levels of the A/L-framework, especially related to environmental
interaction and functional structure.
MSA uses several techniques, such as dataflow diagrams and event partitioning. If we study the
different techniques, they can more specifically be related to the different aspect domains of the
A/L-framework according to the models and phases of MSA they are part of. Figure 7 illustrates
the mapping of MSA onto the framework.
Figure 7
Mapping of MSA onto the A/L-framework
The techniques used in the method do not necessarily support entries of the framework on
which they are mapped completely. The degree of support is a further refinement of the
mapping. This will not be described in this paper (see Lemmen et al., 1993).
Figure 7 shows that MSA is particularly related to four aspect domains i.e. environmental
interaction, functional structure, process structure and system dynamics. The mapping also
shows that MSA does not take the OSM-level into consideration.
5
MATCHING THE PROJECT SITUATION TO METHOD FRAGMENTS
8
Matching the specific project situation of the HOISTED SAIL company to MSA (comparing
figure 4 and figure 7) we could select fragments from MSA, for example:
 a description of the goals on the CIM-level,
 user implementation model; determines the man-machine interface and specifying
operational constraints (OI on the level of DSM as well as on the level of IPM),
 process model; defines how a system reacts to environmental occurrences (FS on the level of
CIM),
 data dictionary; records features of data flows and data stores (FS and ES on the level of
CIM) and
 task model; defines the connection between processes (SD on the level of DSM).
We can also conclude that MSA is not sufficient to cover the project situation as a whole. In
addition, more detailed mapping will even show that MSA probably does not cover entries
completely. In order to cover the project situation as a whole we have to select fragments from
other methods. The missing entries of MSA with respect to the HOISTED SAIL case study are
the environmental interaction and the functional structure on the level of OSM. An assessment
of Information Engineering (IE) would demonstrate that fragments of IE could be mapped onto
those entries. It even shows that fragments of IE cover more relevant entries of the framework
in the example of the HOISTED SAIL company then MSA does, although IE doesn't cover the
aspect system dynamics.
The selected fragments are used as input for the assembly process. During the assembly process
those fragments which fit best are selected. The assembly process consists of a set of rules that
provide guidelines for assembling method fragments. This will not be elaborated in this paper.
More details on the assembly process can be found in Harmsen and Brinkkemper (1994), and
Punter and Lemmen (1996). Finally the assembly process results in a situational method.
6
A COMPUTERIZED TOOL BASED ON THE SMEA/L-APPROACH: A
PROTOTYPE
As mentioned in the introduction, a company like KPMG starts reaping the benefits of the
feasibilities offered by Knowledge Manager (K-man), a company wide conferencing bulletin
board and on-line communication system for management consultants. K-man fulfils needs to
exchange information about a diversity of subjects. These subjects vary from Practice
management (forums and information relating to managing projects) to Qualifications (for
different projects broken down). Besides fulfilling the need for ordinary information exchange,
K-man will contribute to the professionalization of the consultant’s main task. Within the scope
of professionalization the re-use of e.g. documents and images is an important issue. K-man
provides an optimal path leading to the desired destination, where the wanted object can be
fetched.
We would like to discuss the relation between two special subjects of K-man called Methods &
Tools, and Closed Assignments which holds information about finished projects. It is aimed at
enhancing the level of the consultant’s activities with two interacting mechanisms. The first
mechanism contains the application of (the developed) methodology and project experiences
towards current projects, while the other mechanism, which moves into the opposite direction,
contains the abstraction of project experiences towards a methodology. These two mechanisms
can be considered as a kind of SME: constructing a method tuned to the project situation at
hand. As a concrete approach of SME we introduced the SMEA/L-approach on which the
presented prototype is based. Figure 8 illustrates some screen dumps of the prototype yet
9
available. In the prototype a more comprehensive version of the SMEA/L-approach is used that
is not described in the paper.
Figure 8
A tool based on the SMEA/L-model
One can enter the A/L–framework and subsequently zoom in on the entries in the framework.
Clicking an entry shows suitable method fragments. Refinements of the tool will be based on
future results of the research and should lead to a set of rules that guide a consultant in deciding
what approach (read methods) should be selected in a specific situation.
7
CONCLUSION AND FURTHER RESEARCH
We have outlined an approach to Situational Method Engineering in which a framework for ISD
takes up a central position. We characterize both the project situation and existing ISD-methods
in terms of the framework. This offers the opportunity to compare them and to select the most
suitable method fragments for solving the actual problem. In order to come to a uniform but
flexible approach to developing information systems, the main advantage of the presented
approach to SME is that all project situations are characterized on the same basis.
At the moment the proposed approach is limited by the fact that it mainly bared on the analyst’s
intuition and experience to characterize a project situation, although in Lemmen et al. (1993)
there are guidelines how to handle this. Future research will concentrate on structuring the
process of project characterization by offering a comprehensive set of decision rules. These
rules will be based on contingency models and characteristics of the 32 entries in the
framework.
The mapping of methods onto the framework means that we have to determine method
fragments. In order to accomplish the process of method fragmentation we need to have a clear
understanding of what is meant by a method fragment. Besides using the A/L-framework to
characterize existing ISD-methods we also have to formulate what kind of relationships (have
to) exist between different method fragments. In order to assure the overall consistency and
effectiveness of a constructed situational method there should also be rules for enforcing such
10
quality (see also Harmsen & Brinkkemper, 1994). Finally this should deliver a model for
fragmenting methods. It is clear that future results of the research will also lead to further
extensions of the SMEA/L-tool.
We conclude with the remark that models for characterizing project situations and
fragmentation of methods should harmonize in order to compare them during the matching
process. The topic of this paper has shown that a sound basis for such a harmonization is
offered by using the same framework for characterization.
ACKNOWLEDGEMENTS
The authors wish to thank their colleagues for the fruitful discussions that led to many
improvements of the paper, especially Frank Harmsen, Kees van Slooten, Marnix Klooster,
Alfred van der Veen and Jimmy Witkam of the University of Twente, Teade Punter of
Eindhoven University of Technology and Martin Boogaard of KPMG Management
Consultancy.
REFERENCES
Benyon, D., and Skidmore, S., (1987), Towards a Tool Kit for the Systems Analyst, The
Computer Journal, vol. 30, no. 1, pp. 2-7.
Essink, L.J.B., (1988), A Conceptual Framework for Information Systems Development
Methodologies, in: “Eurinfo '88, Proceedings of the First European Conference on Information
Technology for Organizational Systems”, Bullinger, H.J. et al., eds., North Holland,
Amsterdam.
Harmsen, F., Brinkkemper, S. and Oei, H., (1994), Situational method engineering for
information system project approaches, in: “Methods and Associated Tools for the Information
Systems Life Cycle”, Verrijn-Stuart, A.A. and William Olle, T., eds., North Holland,
Amsterdam.
Harmsen, F., (1997), “Situational Method Engineering”, Dissertation, University of Twente,
Enschede.
Harmsen, F., and Brinkkemper, S., (1995), Design and Implementation of a Method Base
Management System for a Situational CASE Environment, in: “Proceedings of the 2nd Asia
Pacific Software Engineering Conference (APSECÆ95)”, IEEE Computer Science Press. Also
in: Technical Report 95-19, Department of Computer Science, University of Twente, Enschede.
Harmsen, F., and Brinkkemper, S., (1995), “Design and Implementation of a Method Base
Management System for a Situational CASE Environment”, Memoranda Informatica 95-19,
University of Twente, Enschede.
Ter Hofstede, A.H.M., and Verhoef, T.F., (1997), On the Feasibility of Situational Method
Engineering, Information Systems, vol. 22, no. 6/7, pp. 401-422.
Kumar, K., and Welke, R.J., (1992), Methodology Engineering: A Proposal for SituationSpecific Methodology Construction. in: “Challenges and Strategies for Research in Systems
Development”, Cotterman, W.W. and Senn, J.A., eds., Wiley.
11
Lemmen, K.A.M., Punter, H.T, Dicker, L.M.M., et al., (1993), “A methodological framework
for IS-development” (textbook in Dutch), Open University of the Netherlands, Heerlen.
Lemmen, K.A.M., Mulder, F., and Brinkkemper, S., (1997), Classifying information system
education by method engineering, in: “Proceedings Working Conference IFIP/WG3.2”,
University of Twente, Enschede.
Malouin, J.L., and Landry, M., (1983), The mirage of universal methods in systems design,
Journal of Applied Systems Analysis, vol. 10, pp. 47-62.
Olle, T.W., J. Hagestein, MacDonald, I.G., et al., (1991), “Information Systems Methodologies
- A framework for understanding”, Addison Wesley, 2nd edition, Amsterdam
Punter, H., and Lemmen, K., (1996), The MEMA-model: Towards a new approach for Method
Engineering, Information and Software Technology, vol. 38, no. 4, pp. 295-305.
Rolland, C., and Prakash, N., (1996), A Proposal for Context-Specific Method Engineering, in:
“Method Engineering: Principles of method construction and tool support”, Brinkkemper, S.,
Lyytinnen, K., and Welke, R.J., eds., Chapman & Hall, London.
Rumbaugh, J. et al., (1991), “Object-Oriented Modeling and Design”, Prentice Hall,
Englewood-Cliffs NJ.
Slooten, K. van, (1995), “Situated Methods for Systems Development”, Dissertation,
University of Twente, Enschede.
Van Slooten, K., and Hodes, B., (1996), Characterizing IS development projects, in: “Method
Engineering: Principles of method construction and tool support”, Brinkkemper, S., Lyytinnen,
K., and Welke, R.J., eds., Chapman & Hall, London.
Sowa, J.F., and Zachman, J.A., (1992), Extending and formalizing the framework for
information systems architecture, IBM Systems Journal, vol. 31, no. 3, pp. 590-616.
Swede, V. van, and van Vliet, J.C., (1993), A Flexible Framework for Contingent Information
Modelling, Information and Software Technology, vol. 35, no. 9, pp. 530-548.
Vlasblom, G., Rijsenbrij, D., and Glastra, M., (1995), Flexibilisation of the methodology of
system development, Information and Software Technology, vol. 37, no. 11, pp. 595-607.
Yourdon, E., (1989), “Modern Structured Analysis”, Prentice Hall, Englewood-Cliffs NJ.
12