Example of a Method Engineering Process. This figure provides a process-oriented view of the approach used to develop prototype IDEF9 method concepts, a procedure, and candidate graphical and textual language elements.
Method engineering in the "field of information systems is the discipline to construct new methods from existing methods". It focuses on "the design, construction and evaluation of methods, techniques and support tools for information systems development".
Furthermore, method engineering "wants to improve the usefulness of systems development methods by creating an adaptation framework whereby methods are created to match specific organisational situations".
Types
Computer aided method engineering
The meta-process modeling process is often supported through software tools, called computer aided method engineering (CAME) tools, or MetaCASE tools
(Meta-level Computer Assisted Software Engineering tools). Often the
instantiation technique "has been utilised to build the repository of
Computer Aided Method Engineering environments". There are many tools for meta-process modeling.
Method tailoring
In
the literature, different terms refer to the notion of method
adaptation, including 'method tailoring', 'method fragment adaptation'
and 'situational method engineering'. Method tailoring is defined as:
A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation.
Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context.
Situation-appropriateness can be considered as a distinguishing
characteristic between agile methods and traditional software
development methods, with the latter being relatively much more rigid
and prescriptive. The practical implication is that agile methods allow
project teams to adapt working practices according to the needs
of individual projects. Practices are concrete activities and products
that are part of a method framework. At a more extreme level, the
philosophy behind the method, consisting of a number of principles, could be adapted.
Situational method engineering
Situational method engineering is the construction of methods which are tuned to specific situations of development projects. It can be described as the creation of a new method by
- selecting appropriate method components from a repository of reusable method components,
- tailoring these method components as appropriate, and
- integrating these tailored method components to form the new situation-specific method.
This enables the creation of development methods suitable for any
development situation. Each system development starts then, with a
method definition phase where the development method is constructed on
the spot.
In case of mobile business development, there are methods available for specific parts of the business model
design process and ICT development. Situational method engineering can
be used to combine these methods into one unified method that adopts the
characteristics of mobile ICT services.
Method engineering process
The developers of the IDEF
modeling languages, Richard J. Mayer et al. (1995), have developed an
early approach to method engineering from studying common method
engineering practice and experience in developing other analysis and design methods. The following figure provides a process-oriented view of this approach. This image uses the IDEF3
Process Description Capture method to describe this process where boxes
with verb phrases represent activities, arrows represent precedence
relationships, and "exclusive or" conditions among possible paths are
represented by the junction boxes labeled with an "X.".
This image provides a general overview of the IDEF Method engineering process approach.
According to this approach there are three basic strategies in method engineering:
- Reuse: one of the basic strategies of methods engineering is reuse. Whenever possible, existing methods are adopted.
- Tailormade: find methods that can satisfy the identified needs with minor modification. This option is an attractive one if the modification does not require a fundamental change in the basic concepts or design goals of the method.
- New development: Only when neither of these options is viable should method designers seek to develop a new method.
This basic strategies can be developed in a similar process of concept development.
Knowledge engineering approach
A knowledge engineering
approach is the predominant mechanism for method enhancement and new
method development. In other words, with very few exceptions, method
development involves isolating, documenting, and packaging existing
practice for a given task in a form that promotes reliable success among
practitioners. Expert attunements are first characterized in the form
of basic intuitions and method concepts. These are often initially
identified through analysis of the techniques, diagrams, and expressions
used by experts. These discoveries aid in the search for existing
methods that can be leveraged to support novice practitioners in
acquiring the same attunements and skills.
New method development is accomplished by establishing the scope
of the method, refining characterizations of the method concepts and
intuitions, designing a procedure that provides both task accomplishment
and basic apprenticeship support to novice practitioners, and
developing a language(s) of expression. Method application techniques
are then developed outlining guidelines for use in a stand-alone mode
and in concert with other methods. Each element of the method then
undergoes iterative refinement through both laboratory and field
testing.
Method language design process
The
method language design process is highly iterative and experimental in
nature. Unlike procedure development, where a set of heuristics and
techniques from existing practice can be identified, merged, and
refined, language designers rarely encounter well-developed graphical
display or textual information capture mechanisms. When potentially
reusable language structures can be found, they are often poorly defined
or only partially suited to the needs of the method.
A critical factor in the design of a method language is clearly
establishing the purpose and scope of the method. The purpose of the
method establishes the needs the method must address. This is used to
determine the expressive power required of the supporting language. The
scope of the method establishes the range and depth of coverage which
must also be established before one can design an appropriate language
design strategy. Scope determination also involves deciding what
cognitive activities will be supported through method application. For
example, language design can be confined to only display the final
results of method application (as in providing IDEF9 with graphical and
textual language facilities that capture the logic and structure of
constraints). Alternatively, there may be a need for in-process language
support facilitating information collection and analysis. In those
situations, specific language constructs may be designed to help method
practitioners organize, classify, and represent information that will
later be synthesized into additional representation structures intended
for display.
With this foundation, language designers begin the process of
deciding what needs to be expressed in the language and how it should be
expressed. Language design can begin by developing a textual language
capable of representing the full range of information to be addressed.
Graphical language structures designed to display select portions of the
textual language can then be developed. Alternatively, graphical
language structures may evolve prior to, or in parallel with, the
development of the textual language. The sequence of these activities
largely depends on the degree of understanding of the language
requirements held among language developers. These may become clear only
after several iterations of both graphical and textual language design.
Graphical language design
Graphical
language design begins by identifying a preliminary set of schematics
and the purpose or goals of each in terms of where and how they will
support the method application process. The central item of focus is
determined for each schematic. For example, in experimenting with
alternative graphical language designs for IDEF9, a Context Schematic
was envisioned as a mechanism to classify the varying environmental
contexts in which constraints may apply. The central focus of this
schematic was the context. After deciding on the central focus for the
schematic, additional information (concepts and relations) that should
be captured or conveyed is identified.
Up to this point in the language design process, the primary
focus has been on the information that should be displayed in a given
schematic to achieve the goals of the schematic. This is where the
language designer must determine which items identified for possible
inclusion in the schematic are amenable to graphical representation and
will serve to keep the user focused on the desired information content.
With this general understanding, previously developed graphical language
structures are explored to identify potential reuse opportunities.
While exploring candidate graphical language designs for emerging IDEF
methods, a wide range of diagrams were identified and explored. Quite
often, even some of the central concepts of a method will have no
graphical language element in the method.
For example, the IDEF1
Information Modeling method includes the notion of an entity but has no
syntactic element for an entity in the graphical language.8. When the
language designer decides that a syntactic element should be included
for a method concept, candidate symbols are designed and evaluated.
Throughout the graphical language design process, the language designer
applies a number of guiding principles to assist in developing high
quality designs. Among these, the language designer avoids overlapping
concept classes or poorly defined ones. They also seek to establish
intuitive mechanisms to convey the direction for reading the schematics.
For example, schematics may be designed to be read from left to
right, in a bottom-up fashion, or center-out. The potential for clutter
or overwhelmingly large amounts of information on a single schematic is
also considered as either condition makes reading and understanding the
schematic extremely difficult.
Method testing
Each
candidate design is then tested by developing a wide range of examples
to explore the utility of the designs relative to the purpose for each
schematic. Initial attempts at method development, and the development
of supporting language structures in particular, are usually
complicated. With successive iterations on the design, unnecessary and
complex language structures are eliminated.
As the graphical language design approaches a level of maturity,
attention turns to the textual language. The purposes served by textual
languages range from providing a mechanism for expressing information
that has explicitly been left out of the graphical language to providing
a mechanism for standard data exchange and automated model
interpretation. Thus, the textual language supporting the method may be
simple and unstructured (in terms of computer interpretability), or it
may emerge as a highly structured, and complex language. The purpose of
the method largely determines what level of structure will be required
of the textual language.
Formalization and application techniques
As
the method language begins to approach maturity, mathematical
formalization techniques are employed so the emerging language has clear
syntax and semantics. The method formalization process often helps
uncover ambiguities, identify awkward language structures, and
streamline the language.
These general activities culminate in a language that helps focus
user attention on the information that needs to be discovered,
analyzed, transformed, or communicated in the course of accomplishing
the task for which the method was designed. Both the procedure and
language components of the method also help users develop the necessary
skills and attunements required to achieve consistently high quality
results for the targeted task.
Once the method has been developed, application techniques will
be designed to successfully apply the method in stand-alone mode as well
as together with other methods. Application techniques constitute the
"use" component of the method which continues to evolve and grow
throughout the life of the method. The method procedure, language
constructs, and application techniques are reviewed and tested to
iteratively refine the method.
