INFORMATION SYSTEM METHODOLOGIES

Information System Methodologies

Table of Contents

Information System Methodologies3

Introduction3

Method Fragments6

Method Chunks8

Alternative Views on Chunk12

The Pros and Cons of Fragments and Chunks13

The Pros and Cons of Interfaces for Method Components19

Choosing Between the Two Approaches21

Summary and Conclusions23

References25

Appendix26

List of Tables26

Table 1: Two example fragments, the details of each following the standard template as specified by the ISO/IEC 24744 metamodel.26

Table 2: Summary Comparison27

List of Figures27

Figure 1: The triangle of Producers, Work Units and Work Products that underpins the SPEM, OPF and 24744 standards for software engineering process modelling. Method fragments conform to one specific subclass of these metaclasses.27

Figure 2: Revised metamodel for method chunk28

Figure 3: An example of a method chunk, consisting of a single process part and a single product part. A chunk has a body plus an interface as well as an affiliated descriptor. Details of the origin, reuse situation, reuse intention and experience report have been only partially presented in order to retain clarity.28

Figure 4: Metamodel for Method Components, Chunks and Fragments.29

Figure 5: Metamodel for Method Components, Chunks and Fragments with cardinalities revised to support a 1:m relationship between process and product parts of the chunk.29

Figure 6: NIMSAD Framework29

Information System Methodologies

Introduction

Both in theory and practice, it is argued that high quality software development methods (a.k.a. methodologies) can best be created by means of construction - identifying small elements of a methodology, variously called fragments or chunks, and putting them together for a specific situation. Done in an ad hoc manner, this can lead to a large number of variations on the one methodology within a single organization together with its concomitant challenge of methodology management. A more structured formal and potentially repeatable approach to methodology construction is Situational Method Engineering (SME), which is a subset of the IT sub-discipline of Method Engineering (ME) that itself includes not only SME but also comparison of methods and knowledge infrastructures. SME provides a solid, theoretically sound basis for creating useful methodologies as well as giving the development team "ownership" of their methodological approach.

The chunks/fragments, of course, need to exist prior to construction - typically these are gleaned from best practice, theory and/or abstracted from other (static) methodologies. Once identified and documented, they are stored in a methodbase, which serves as a repository for these method chunks/fragments.

While there are many research and practical issues regarding the engineering of software development methodologies, as documented in the software engineering literature on SME, one important basic concern is the need to agree on a definition of the atomic element from which methodologies can be constructed.

Throughout we use the ISO/IEC International Standard 24744 Software Engineering Metamodel for Development Methodologies as an underpinning "theory" that assists us in identifying similarities and differences in these two approaches to Situational Method Engineering (SME).

NIMSAD Framework

NIMSAD (Normative Information Model-based Systems Analysis and Design) is a framework that serves as a way of understanding problem solving in general. It draws upon systems theory and thinking in its consideration of the organizational context wherein problems exist, the logical and physical aspects of the problem solving process that ...