3. RESEARCH APPROACH
3.4 DEMO METHODOLOGY
DEMO is abbreviated for Design and Engineering Methodology for
Organisations and has its origin from organisational engineering domain. This
methodology is used for developing high-level and abstract models of construction and operation of organizations. This methodology applies enterprise ontology theory and ‘Ontology’ can be simply defined as ‘‘an explicit specification of a conceptualization” (Gruber, 1994). Enterprise ontology theory is described as the implementation independent essence of an enterprise (Dietz, 2006) and has a strong theoretical foundation. The strong theoretical foundation ensures that DEMO models can be claimed to be coherent, comprehensive, consistent, concise and essential (Albani and Dietz, 2011).
It is essential to understand briefly the enterprise ontology theory and importantly its terms in order to understand how DEMO methodology and its models can be used for modelling OS e-learning system development. Therefore, Enterprise ontology theory and its axioms are first explained along with the different terms used.
Enterprise Ontology Theory
The enterprise ontology theory consists of four axioms which form the basis for DEMO methodology and its models. They are Distinction Axiom, Production Axiom, Transaction Axiom and Composition Axiom. The distinction axiom differentiates between three human abilities which are required to fulfil certain actions - datalogical actions, infological actions and ontological actions (Stamper, 1973). Ontological actions are considered to be the fundamental human actions in a process flow. Since, the actions on the infological and datalogical level do not introduce new products/ services/
32
information, if is sufficient to focus on the ontological level actions in-order to describe its essence using DEMO.
The production axiom states that social individuals/ actors fulfil the goals of an enterprise by performing ‘acts’. The result of successfully performing an act is recorded in a ‘fact’. On the ontological level, two kinds of acts occur: production acts (P-acts) and coordination acts (C-acts). Performing a P-act correspond to the delivery of products, services and information to the environment of an organization. By performing a P-act, a new production fact (P-fact) is brought into existence. In order to complete the performance of a P- act, social individuals / actors have to communicate, negotiate and commit themselves. These activities are called coordination acts (C-acts), and they result in coordination facts (C-facts).
The transaction axiom states that the coordination involved to successfully complete a P-act can be expressed in a universal pattern, which is called a ‘Transaction’. A transaction consists of three phases: order phase, execution phase and result phase. In the order phase, the actors negotiate about the P-fact that is the subject of the transaction. Once an agreement is reached, the P-fact is produced in the execution phase. In the result phase, the actors can negotiate and discuss about the result of the transaction. These phases are subdivided into process steps, which consist of four coordination acts and one production act. C-act includes request, promise, state and accept. While the production act includes execute (process step). In DEMO, exactly two actors are associated with a transaction: an initiator and an executor. The authority over the execution of a single transaction is assigned to the executor (Huysmans et al., 2010). This authority can be attributed to individuals or groups of individuals. Some processes may produce more than one P-fact for the organization. In that case, a DEMO transaction needs to be created for each P-fact. This requires coordination between transactions. The composition axiom describes how these transactions can interact. One aspect of interaction is how transactions are initiated. Any transaction is either initiated by an external party (e.g., a request for a bug fix by a user) or a time-based trigger (e.g., the nightly building of the software), or enclosed in another transaction. In the case of an
33
enclosed transaction, an information dependency usually exists between the enclosing and the enclosed transaction. The models created using the DEMO methodology for this research are based on these four axioms.
Further, DEMO methodology focuses on the communication pattern and various outputs produced during various software developments (Huysmans, et al., 2010). From the context of this research, DEMO methodology gives a high level overview of how the OS e-learning software products are developed without taking into consideration the technology or technique used for the development. Yet, it identifies precisely who is responsible for producing an output. Also, the DEMO methodology has been already applied to OS systems and has been proved to provide a high quality, abstract model (Huysmans, et al., 2010). Unlike other modelling methods used for modelling OSS development, DEMO exhibits two specific features within the context of OSSD process modelling that adds strength to this approach.
DEMO analyses processes at the ontological level and provides high- level process descriptions, instead of focusing on the implementation level.
DEMO studies the communication pattern between human actors, instead of the sequences in which activities are performed.
These characteristic of DEMO makes it extremely appropriate for modelling the development practices of software products and therefore OS e-learning systems by extension. The DEMO models and its application are explained in detail in chapter 5.
3.5 Summary
This chapter introduced the two-stage research approach and also explained each stage in detail. Further, the various tasks performed under each of these stages were explained that provided a comprehensive overview of this research work. A detailed and individual explanation of each tasks are provided in the remainder of this thesis under chapter 4, 5, 6 and 7.
34