Skip to main content
SpringerLink
Log in

On generic method models

  • Original Research
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

The generic method model assumes that methods abound and method engineering and application engineering is done in diverse areas. Therefore, it is necessary to understand the notion of a method independent of information systems and software engineering. The generic model presented here abstracts out from product and process meta-models to define a system of concepts that can be used in any domain. Additionally, it integrates in it essential features of methods like quality checking, guidance, backtracking, and traceability. The proposed generic model looks upon a method in two parts, the static and the dynamic parts. The former provides the basic structure of a method whereas the latter is the enactment support provided for application development. The static part provides the notion of method blocks and dependencies between them. Method blocks can be enacted. The generic model is a triple <M, D, E> where M is the set of method blocks, D is the set of dependencies between method blocks, and E is the enactment mechanism.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig 11

Similar content being viewed by others

References

  1. Hornby AS (2000) Oxford advanced learner’s dictionary of current English. Oxford University press, Oxford

    Google Scholar 

  2. Brinkkemper S, Saeki M, Harmsen F (1999) Meta-modelling based assembly techniques for situational method engineering. Inform Syst 24(3):209–228

    Article  Google Scholar 

  3. Plihon V, Rolland C (1995) Modelling ways-of-working. In: Proceedings of CAiSE’95, Springer, Berlin Heidelberg New York

  4. Ralyte J, Rolland C (2001) An assembly process model for method engineering, In: Proceedings of CAiSE’01, Springer, Berlin Heidelberg New York

  5. Rolland C, Prakash N, Benjamen A (1999) A multi-model view of process modelling. REJ 4(4):169–187

    Google Scholar 

  6. Prakash N (1994) A process view of methodologies, advanced information systems engineering. In: Wijers, Brinkkemper, Wasserman (eds) LNCS 811, Springer, Berlin Heidelberg New York, pp 339–352

  7. Smolander K (1991) OPRR: a model for modeling systems development methods, next generation of CASE tools. IOS Press, Amsterdam

    Google Scholar 

  8. Souveyet C (1991) Validation des Specifications Conceptuelles d’un Systeme d’information, Ph.D. thesis, University of Paris

  9. Brinkkemper S (1990) Formalisation of information systems modelling, Ph.D. thesis, University of Nijmegen, Thesis Publishers, Amsterdam

  10. Wijers GM (1991) Modelling support in information systems development, Ph.D. thesis, University of Delft, Thesis Publishers, Amsterdam

  11. Grosz G et al (1997) Modelling and engineering the requirements engineering process: an overview of the NATURE approach. REJ 2(3):115–131

    Google Scholar 

  12. Prakash N (1999) On method statics and dynamics. Inform Syst J 24(8):613–637

    Article  Google Scholar 

  13. Jarke M et al (1994) Experience based method evaluation and improvement: a process modelling approach. In: Verrijn-Stuart, Olle (eds) Methods and associated tools for the information systems life cycle, Elsevier, Amsterdam, pp 1–28

  14. Harmsen F et al (1994) Situational method engineering for information system project approaches. In: Verrijn-Stuart, Olle (eds) Methods and associated tools for the information systems life cycle, Elsevier, Amsterdam, pp 169–194

  15. Prakash N (1997) Towards a formal definition of methods. REJ 2(1):23–50

    Google Scholar 

  16. Prakash N, Bhatia MPS (2002) Generic models for engineering methods of diverse domains, advanced information systems engineering (CAiSE 02). In: Pidduck, Mylopoulos, Woo, Ozsu (eds), LNCS 2348:612–625

  17. Checkland OP, Scholes J (1990) Soft systems methodology in action. Wiley, Chichester

    Google Scholar 

  18. Atkinson CJ (1997) Soft information systems and technologies methodology (SISTeM): a case study on developing the electronic patient record. REJ 1–22

  19. Blum BI (1994) A taxonomy of software development methods. CACM, pp 82–94

  20. Davis AM et al (1988) A strategy for comparing alternative software development life cycle models. IEEETSE, pp 1453–1461

  21. Lyttinen K (1987) A taxonomic perspective of information systems development: theoretical constructs and recommendations. In: Boland, Herschheim (eds) Critical issues in information systems research, Wiley, New York, pp 3–41

  22. Krogstie J, Solvberg A (1996) A classification of methodological framework for computerized information systems support in organizations. In: Brinkkemper, Lyytinen, Welke (eds) Method engineering: principles of method construction and tool support, Chapman & Hall, London, pp 278–295

  23. Rolland C, Souveyet C, Ben Achour C (1998) Guiding goal modelling and scenarios. IEEETSE 24(12):1055–1071

    Google Scholar 

  24. Prakash N, Sibal R (1999) Modelling method heuristics for better quality products, advanced information systems engineering. In: Jarke M, Oberweis A, (eds) LNCS 1626, Springer, Berlin Heidelberg New York, pp 429–433

  25. Prakash N, Bhatia MPS (2003) Developing application centric methods. In: Eder, Missikoff (eds) CAiSE Forum, pp 225–228

  26. Ralyte J et al (2003) Towards a generic model for situational method engineering, advanced information systems engineering. In: Eder J, Missikoff M (eds) CAiSE 2003, LNCS 2681, Springer, Berlin Heidelberg New York, pp 95–110

Download references

Author information

Authors and Affiliations

  1. JUIT, 173215, Waknaghat, Himachal Pradesh, India

    Naveen Prakash

Authors
  1. Naveen Prakash
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Naveen Prakash.

Appendices

Appendix 1

We show here an example of the use of the generic model by instantiating it with the meta-model of [12]. For reasons of space, we assume knowledge of this meta-model and shall not explain its concepts. The focus shall be on giving a flavour of the way the generic model can be instantiated to yield the meta-model. Thereafter the CAME tool, MERU, reported in [25] can be used to engineer the method itself.

The static part of the generic model is instantiated to yield meta-model statics, instances of method blocks and the set of dependencies between these. In our meta-model, method blocks are instantiated to purposes, product primitives to conceptual structures and fixed structures, and process primitives to operations which can be of two types, product manipulation and quality checking. There are four dependency types, requirements, removal, activate and inactivate. The set of dependencies is instantiated with dependencies between purposes of different types.

Through the click and drag features of the generic-CAME tool, the instantiations of product primitives with conceptual and fixed structures shown in Figs. 12 and 13 are arrived at. As shown in Fig. 12, conceptual structures can be partitioned into two clusters. The first cluster classifies them as either simple or complex. The second cluster partitions conceptual structures into disjoint classes of structures called constraint, definitional, constructional, link and collection of concepts, respectively.

Fig. 12
figure 12

The conceptual structure

Full size image
Fig. 13
figure 13

The fixed structure

Full size image

Figure 13 shows the product primitive instances that identify the criteria that must be met by a good quality product. There are four kinds of fixed structures as shown. Again, these are created by the drag and drop facilities of the generic-CAME tool.

Operations identify the instances of process primitives of the generic model that operate upon conceptual and fixed structures to provide product manipulation and quality checking capability to application engineers. Again, the generic-CAME tool is used to produce Fig. 14.

Fig. 14
figure 14

The operation

Full size image

There are two operations in the basic life cycle class, create and delete. The relational class of operations is axiomatically defined and this definition can be found in [15].

A purpose is an instance of the method block of the generic model. It is a pair

$$ {\text{Purpose}} = <{\text{structure}},\,{\text{operation}}> . $$

Thus, the following are purposes

$$ \begin{aligned}{} & <{\text{simple}}\,{\text{constructional}}\,{\text{structure}},\,{\text{create}}> \\ & <{\text{simple}}\,{\text{constructional}}\,{\text{structure}},\,{\text{method}}\,{\text{constraint}},\,{\text{method}}\,{\text{constraint}}\,{\text{enforcement}}> . \\ \end{aligned} $$

The definition of the set of meaningful purposes of the meta-model is supported by the generic-CAME tool which generates the cross product of structure and operation. This cross product is presented and the meaningful purposes are then selected. The complete set of purposes can be found in [25].

Finally, the set of dependencies of different types are instantiated and the generic-CAME tool keeps an internal representation of the dependency graphs.

The enactment algorithm is inherited by the meta-model. Therefore, its full enactment power including guidance, tracing and backtracking is available. The meta-model is validated using this algorithm to enact typical purposes expected to be found in a method which, in turn, shall be produced from the meta-model.

Appendix 2: Glossary

Product primitive

The smallest unit that can be operated upon in a method

Process primitive

An atomic action that can be enacted

Method primitive

The smallest meaningful process unit of a method that can be enacted. It is a pair <product primitive, process primitive>

Complex method block

A composition of simpler method blocks

Abstract method block

A generalization of a method block

Method block

It can be either a method primitive, a complex or an abstract method block

Product part

A part of a product that is the focus of further development

DPC

The product part together with the method block that can operate upon it. It is the smallest unit of the development process

Development process

The sequence of DPCs enacted to build the product

Rights and permissions

Reprints and permissions

About this article

Cite this article

Prakash, N. On generic method models. Requirements Eng 11, 221–237 (2006). https://doi.org/10.1007/s00766-005-0026-1

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-005-0026-1

Keywords

Search

Navigation