Sei sulla pagina 1di 16

Information and Software Technology 52 (2010) 656671

Contents lists available at ScienceDirect

Information and Software Technology


journal homepage: www.elsevier.com/locate/infsof

Using the DEMO methodology for modeling open source software development processes
Philip Huysmans, Kris Ven *, Jan Verelst
Department of Management Information Systems, University of Antwerp, Prinsstraat 13, 2000 Antwerp, Belgium

a r t i c l e

i n f o

a b s t r a c t
Context: Open source software development (OSSD) process modeling has received increasing interest in recent years. These efforts aim to identify common elements in the development process between multiple open source software (OSS) projects. However, the complexity inherent to OSSD process modeling puts signicant demands on the modeling language. Objective: In this paper, we propose that the Design and Engineering Methodology for Organizations (DEMO) may provide an interesting alternative to develop OSSD process models. DEMO exhibits two unique features within the context of OSSD process modeling. First, DEMO analyzes processes at the ontological level and provides high-level process descriptions, instead of focusing on the implementation level. Second, DEMO studies the communication patterns between human actors, instead of the sequences in which activities are performed. Method: We investigate the feasibility of using DEMO to construct OSSD process models by means of a case study. DEMO models were constructed to describe the NetBeans Requirements and Release process. In addition, the quality of these DEMO models was evaluated using a quality framework for conceptual modeling. Results: Our results showed that our DEMO models exhibited a high level of abstraction, thereby reducing the complexity of the OSSD process models. In addition, the evaluation of the models developed in this paper by using the quality framework for conceptual modeling showed that the models were of high quality. Conclusions: We have shown that the DEMO methodology can be successfully used to model OSSD processes and to obtain abstract and high-quality OSSD process models. However, given some potential drawbacks with respect to understandability and implementability, we primarily propose the use of DEMO within OSSD process modeling as an analysis tool that should be complemented with other techniques and models for communication and reenactment purposes. 2010 Elsevier B.V. All rights reserved.

Article history: Received 29 June 2009 Received in revised form 2 February 2010 Accepted 3 February 2010 Available online 10 February 2010 Keywords: Software process modeling Open source software DEMO Enterprise ontology

1. Introduction In the past few years, open source software development (OSSD) processes have attracted the interest of many researchers in the open source software (OSS) domain [1]. It is generally known that the processes through which OSS is developed deviate in several ways from the proprietary software development model [24]. Many individuals and organizations are becoming interested in OSS development, and want to learn how to participate in OSS projects, or which OSSD practices have proven to be successful [5,6]. Unfortunately, OSS projects do not clearly document and advertise their development model [6,5]. In addition, considerable variability exists between the development processes across different OSS
* Corresponding author. Tel.: +32 3 265 44 70; fax: +32 3 265 40 64. E-mail addresses: philip.huysmans@ua.ac.be (P. Huysmans), kris.ven@ua.ac.be (K. Ven), jan.verelst@ua.ac.be (J. Verelst). 0950-5849/$ - see front matter 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2010.02.002

projects [5,6]. Since some OSSD processes may be idiosyncratic to the specic OSS project being studied, no single OSSD process exists that is valid for all OSS projects [6]. Similar to software process modeling in general, research on modeling OSSD processes generally tries to identify some common elements in the development process between OSS projects. OSSD process modeling attempts to provide more insight into how OSSD processes are structured, so that these process models can be communicated to other developers [5]. Previous research has documented OSSD processes using semi-structured hyperlinked models, formal computational process models, process ow graphs, and use cases. However, the complexity inherent to OSSD process modeling puts signicant demands on the modeling language. It has also been noted that many of the existing languages are too low-level and that a higher level of abstraction is needed [6]. In this paper, we propose that the Design and Engineering Methodology for Organizations (DEMO) [7] may provide an interesting

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

657

alternative to develop OSSD process models. DEMO represents a fundamentally different approach to process modeling. Our research hypothesis is that DEMO can aid in obtaining abstract and high-quality OSSD process models. To investigate this, we present a case study in which we apply DEMO within the context of OSSD process modeling. Since it is important that software process models are of a sufciently high quality [8], we also evaluate the quality of the DEMO models developed in this paper using a quality framework from conceptual modeling. The paper is structured as follows. We will start by providing a brief overview of the literature on OSSD process modeling and the DEMO methodology. Next, we present the results of a case study in which DEMO is used to describe the NetBeans Requirements and Release process. Subsequently, we evaluate the quality of the resulting DEMO models by using a quality framework from conceptual modeling. This is followed by a discussion on the applicability of DEMO to OSSD process modeling. Finally, our conclusions are offered.

2. Background 2.1. Open source software development process modeling Given the fact that OSSD exhibits several unique features compared to proprietary software development, it has been noted that it is important to develop software process models to gain more insight into these OSSD processes [2,3]. OSSD process modeling has therefore received considerable attention in literature. These efforts further build on the large body of research on software process modeling. Software process models tend to provide more detail on the development process [2,9]. A software process model can be dened as a model describing the overall ow and sequence of software project life-cycle activities, including project planning, tracking, requirements management, software construction and release [10]. The goal of software process modeling is . . . to produce quality models in terms of accuracy, completeness and tness for purpose in an efcient, repeatable manner [8, p. 114]. Such models make an abstraction of the software development process by identifying the common elements in multiple software development projects [11,2]. Software process models allow to validate the process before enactment, to explore various alternative models before enactment in a cost-efcient manner, and to facilitate the design of tools that provide automatic validation before enactment [12]. Some early studies on analyzing OSSD processes have provided narrative descriptions of OSSD practices. A classic example is the description of the Apache and Mozilla project by Mockus et al. [13]. Although such descriptions offer a rich insight into the phenomenon, they do not provide sufcient detail to build a process model that can be communicated to other parties [14,4,6]. Subsequent studies have established the need for the development of models that can be shared, reviewed, modied and reenacted (see e.g., [6,15,16,3]). These studies have used techniques such as semi-structured hyperlinked models, formal computational process models, process ow graphs, use cases, and reenactment simulators [16,6,12]. They have, for example, provided more insight into how requirements analysis and release management is handled in OSS projects [4,3]. Recently, some authors have performed research on the automatic discovery of OSSD processes in order to facilitate large-scale process analysis [17,5,1820]. Results show that such automatic discovery is hard to achieve [5]. In his discussion on OSSD process modeling, Scacchi has identied several opportunities for future research on OSSD process modeling [4,14]. In this paper, we are concerned with one of these topics, namely the modeling language that can be used to describe

OSSD processes. We see two main challenges in this regard. Similar to other authors [14,5], we acknowledge the complexity of OSSD process modeling, given the very rich data sources involved. This puts signicant demands on the modeling language, since it needs to be able to cope with a huge amount of data. It should also be possible to conduct a meaningful comparison of the OSSD process models of dozens, hundreds and maybe thousands of OSS projects. This means that process models should not be susceptible to incidental variationsthat do not reect fundamental differencesbetween processes (e.g., a slightly different sequence of activities, or the use of a different software tool). Therefore, a rst challenge is that the process modeling language should be able to aggregate and synthesize data from a large number of projects, abstracting from incidental variations in processes across OSS projects. In addition, OSS projects are continuously evolving with respect to the composition of the community of developers and the practices used within this community [14,6]. This means that the stability of the model over time may be a concern. Therefore, the second challenge is that the process modeling language should be able to model the essential underlying processes of OSS projects in order to be stable with respect to incidental changes in the composition or practices of the community. These two challenges suggest that the process modeling language should be sufciently high-level and abstract. It has indeed been noted that several process modeling languages are too lowlevel and complex to be used in OSSD process modeling [6]. 2.2. Design and Engineering Methodology for Organizations DEMO is a methodology that originated in the organization engineering domain [7]. It aims to develop high-level and abstract models of the construction and operation of organizationsindependent of the actual implementationby focusing on the communication patterns between human actors. DEMO assumes that communication between human actors is a necessary and sufcient basis for a theory of organizations. Apart from the organization engineering domain, DEMO is also being used in the context of business process redesign (BPR) and information systems development (ISD) [21]. The DEMO methodology applies the Enterprise Ontology theory. Enterprise Ontology is dened by Dietz as the implementation independent essence of an enterprise [7]. More generally, an ontology can be dened as an explicit specication of a conceptualization [22, p. 908]. The Enterprise Ontology has a strong theoretical foundation and further builds upon the results from theories from philosophy, sociology and language, such as Habermas theory of Communicative Action [23] and the Language-Action Perspective [24]. The strong theoretical foundation ensures that DEMO models can be claimed to be formally correct [7]: they are coherent, comprehensive, consistent, concise and essential. The Enterprise Ontology theory consists of four axioms that are based on the Communicative Action theory and the Language-Action Perspective. We will now introduce the four axioms of the Enterprise Ontology theory. 2.2.1. Distinction axiom The distinction axiom differentiates between three human abilities which are needed to fulll certain actions. This differentiation is made based on the semiotic layers as dened by Stamper et al. [25] (i.e., social, pragmatic, semantic, syntactic, and empiric). A graphical representation of the layers is provided in Fig. 1. We will illustrate these layers using a practical example of a bug request. The rst ability is needed to perform actions on the forma level. This ability concerns the syntactic and empiric semiotic layers (the bottom layer in Fig. 1). The actions concern the form aspects of information and communication and are called datalogical actions. The datalogical action in the bug report example would be the act

658

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

physical record of this request at the datalogical level is the bug report. The corresponding C-fact is the submission of the bug report, namely bug report #1534 has been requested. 2.2.3. Transaction axiom 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. The basic transaction pattern is shown in Fig. 2. A transaction consists of three phases. 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 in process steps, which consist of four coordination acts (i.e., request, promise, state and accept) and one production act (i.e., execute). 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 [7]. This authority can be attributed to individuals or groups of individuals. In the transaction pattern in Fig. 2, acts are represented by squares. Light-gray boxes demarcate the acts which fall under the responsibility of a certain actor (i.e., the actor Initiator is responsible for the request and accept acts, while the actor Executor is responsible for the promise, execute and state acts). The coordination facts (represented by disks) and the production fact (represented by a diamond) are modeled separately from the acts. The arrows represent the process ow. The basic transaction pattern can be extended to include disagreement between the actors. For example, a transaction request from the initiator may not be fullled by the executor (e.g., the refusal to x a certain bug), or the initiator may refuse to accept the transaction as successful (e.g., by disagreeing that a given bug has been xed). In total, 24 process steps have been identied to provide a complete transaction pattern. However, the basic transaction pattern is sufciently detailed for the purpose of this paper. Some of the transaction pattern process steps may not have datalogical artifacts (i.e., physical records of their occurrence). Such steps are called implicit process steps. When, for example, every request for a bug x will be handled, it could be that no records will be found of a promise to x a certain bug. This does not mean that the promise step did not occur; instead, it could be that the culture of the project prescribes that every bug request should be handled,

Fig. 1. The layers from the distinction axiom.

of sending an email to the project mailing list, or entering a bug report in the bug tracking system. The second ability is needed to perform actions on the informa level. This ability coincides with the semantic and pragmatic semiotic layers (the middle layer in Fig. 1). These actions concern the content aspects and are called infological actions. On the infological level, the bug request is considered to be the transmission of information concerning the bug (e.g., in which situation the bug occurs and which versions are affected). On this level, it does not matter how this information is transferred: that is abstracted away from the datalogical level. The third ability is used to perform actions on the performa level, which are on the social semiotic layer (the top layer in Fig. 1). Actions from the performa level are called ontological actions. Such actions concern the creation of new things (e.g., new products, services or information). Ontological actions are considered to be the fundamental human actions in a process ow. In the bug request example, the decision of the user to submit a bug report is the ontological action. On the ontological level, the information concerning the bug is omitted, as is the form in which the bug request is submitted. This distinction is useful to make. Research has shown that 70% of the information about the process is located on the datalogical and infological layers. Hence, by only focusing on the ontological level, model documentation can be reduced by 70% [7]. Therefore, to describe the essence of an organization by using DEMO it is sufcient to focus on the actions on the ontological level, since actions on the infological and datalogical level do not introduce new products, services, or information. 2.2.2. Production axiom The production axiom states that social individuals or actors fulll 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 corresponds to the delivery of products, services and information to the environment of an organization. By performing a P-act, a new P-fact is brought into existence. A P-fact is considered to be the successful completion of a P-act. This differs from the concrete outcome of that act. If we return to the bug report example and explore the action of actually xing the bug, we consider writing a bug x to be a P-act. The corresponding P-fact is the completion of such an act, namely the bug with id #1534 has been xed. The concrete outcome of the act, in this case the xed source code, is a physical representation of that fact: it is considered to be on the forma or datalogical level. While the source code is not the P-fact in itself, it indicates that the Pact has been successfully fullled. In order to construct the model on the ontological level, we therefore need to look at the datalogical level in the real world for physical records of P-facts. In order to complete the performance of a P-act, social individuals or actors have to communicate, negotiate and commit themselves. These activities are called coordination acts (C-acts), and they result in C-facts. As with P-acts and P-facts, physical records of C-facts can be observed to indicate the occurrence of a C-act. The action of requesting a bug x is an example of a C-act. The

Fig. 2. The DEMO transaction pattern [51].

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

659

or that an agreement or contract is in place. The implicit occurrence of process steps needs to be explained, since they may be the result of assumptions or habits which no longer hold. Moreover, making the reasoning behind implicit process steps explicit may be necessary to compare various projects (e.g., differences in culture). 2.2.4. Composition axiom 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 (1) initiated by an external party (e.g., a request for a bug x by a user), (2) time-based triggered (e.g., the nightly building of the software), or (3) enclosed in another transaction. In the case of an enclosed transaction, an information dependency usually exists between the enclosing and the enclosed transaction. For example, before a new version of the software can be released, a number of bug reports may need to be xed. The release transaction then contains the bug x transaction, and can only continue when the bug request transaction is successfully completed (i.e., it is accepted). 2.3. Motivation for applying DEMO to process modeling Several other methodologies and frameworks have already been proposed for (business) process modeling that could be used for OSSD process modeling. Some notable examples in this regard include ARIS, ADONIS, IBM Rational Method Composer, OSSAD, SPEARMINT, and the Eclipse modeling framework. These methodologies and frameworks originate from, for example, business process re-engineering, ofce reorganization, or industry best practices. Other researchers have noted that several of these modeling techniques are too practice-driven and lack a strong theoretical foundation [9]. The main characteristic that distinguishes DEMO from these other methodologies and frameworks is the fact that DEMO has a strong theoretical foundation, grounded in theories on Communicative Action and the Language-Action Perspective. An essential part of this theoretical foundation is comprised of the Enterprise Ontology theory which further builds upon the results of these theories. In addition, the distinction axiom of the Enterprise Ontology theory distinguishes between the ontological, infological, and datalogical level, thereby allowing to construct essential models that only contain the ontological information contained within a process. This represents a fundamentally different approach to abstraction compared to other methodologies and frameworks. However, there is more to the DEMO methodology than just abstraction. Other methodologies and frameworks do not offer an equivalent to the axioms dened in DEMO. Previous research comparing DEMO to other methodologies and frameworks such as BPMN and ARIS has indeed shown that the main difference consists of the theoretical background provided by DEMO [26,27]. The presence of this theoretical background in the form of the Enterprise Ontology has two important consequences. A rst consequence is that DEMO provides clear and unambiguous denitions for the constructs used in the various models. Having clear denitions is an important property. Irrespective of the modeling technique that is used, each model contains a number of constructs (or symbols) that represent abstract conceptualizations of the real world. When clear denitions are lacking, additional information is required to fully understand the model. This has several disadvantages in terms of understandability and communicability of the model. Moreover, the main goal of abstraction, namely complexity reduction, is jeopardized since a construct that is not clearly dened can have hidden dependencies with

other constructs. Therefore, its internal complexity cannot be neglected. It has been noted in literature that clear and unambiguous denitions of constructs are lacking in several modeling methodologies. Within the context of BPMN, for example, it has been noted that the semantic analysis of BPMN models is hindered by the heterogeneity of its constructs and the lack of an unambiguous denition of the notation [28, p. 1282]. In DEMO, all constructs have a clear and unambiguous denition that is grounded in theory [7]. As a result, the abstract conceptualizations are shared by all stakeholders, thereby eliminating much ambiguity in interpreting the models. In addition, by having these clear and unambiguous denitions, many details can be omitted from the models. This further contributes to the high level of abstraction provided by DEMO. A second consequence is that DEMO provides clear guidelines on how and why abstractions can be made. It has been noted in literature that many methodologies and frameworks lack precise guidelines. For example, by using theories of Weber to evaluate the ARIS framework, Green and Rosemann conclude that no guidelines are provided for modeling complete business rules [29]. This implies that this responsibility is delegated to the modeler, which is not a trivial task since the modeler then has considerable liberty in how a process is modeled. DEMO provides clear and strict guidelines that assist the modeler [7]. More specically, the modeler is forced to only consider those actions that occur on the ontological level. In addition, the transaction pattern clearly prescribes which steps are contained in the transaction, and which actors need to be dened for each transaction. This approach considerably limits the degrees of freedom that modelers have during the modeling process. As a result, there is much less variability between DEMO models that are produced by multiple modelers for the same process(es) [7]. DEMO therefore represents a fundamentally different approach to modeling compared to most other methodologies and frameworks. We do not claim that DEMO outperforms all other methodologies in all possible circumstances. However, we have highlighted several unique characteristics of DEMO, which we feel may have important advantages in a communication-intensive environment such as OSSD process modeling. In addition, we do not claim that DEMO has to be used exclusively. As previous research illustrates, DEMO models can be used in addition toand alongsideexisting modeling efforts in ARIS or BPMN [26,27]. For the specic case of OSSD process modeling, we see two major arguments for the use of DEMO. First, while many modeling languages primarily focus on the implementation level, DEMO analyzes processes within an organization at the ontological level. Therefore, DEMO aids in understanding and managing the complexity of an organization by providing a high-level and abstract view of the organization. There are several practical indications that DEMO results in very concise models [7]. This property may be very interesting for OSSD process modeling, as various authors have mentioned the complexity involved in OSSD process modeling given the very rich data sources involved [46]. Previous research on OSSD process modeling indeed suggests that a highlevel language is required in order to obtain stable models that allow for comparison between OSS projects [6]. Since DEMO focuses on the ontological level, we feel that it is able to provide such a high-level language. A second interesting feature of DEMO is that while other approaches tend to be task-oriented and rather mechanistic, DEMO is grounded in communication theory, is human oriented, and focuses on the interaction betweenand responsibilities ofhuman actors. The DEMO transaction pattern is specically used to model coordination and communication patterns between human actors within processes. Although the data sources of previous research into OSSD process modeling include communication-related artifacts (e.g., web pages, discussion lists, chat, bug reporting tools,

660

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

and newsletters), the resulting process models have emphasized the sequence of various OSSD activities [5]. Since OSS projects can be considered a virtual organization [30,31,16], communication issues between team members may come to the foreground [32,5]. We feel that in such an environment, an understanding of the communication and coordination patterns between developers may provide a deeper insight in the software development process than the sequence in which a number of activities are performed. Issues of collaboration, coordination and control have indeed been studied by OSS researchers in the context of how OSS communities are organized [3335,32,36,37]. It therefore appears that the DEMO methodology is well suited to address the two challenges that were mentioned in Section 2.1. Therefore, we expect DEMO to be able to produce abstract OSSD models by describing the essential processes of OSS projects on the ontological level. 3. OSSD process modeling with DEMO In this section, we investigate the feasibility of using DEMO for OSSD process modeling by means of a case study. 3.1. Methodology Our study was conducted by using the case study method [38,39]. The case study approach is particularly suited to investigate a contemporary phenomenon in its real-life context [38,40]. This approach therefore allowed us to investigate the feasibility of using DEMO by means of a real-life OSSD process, instead of a ctitious example. This increased the practical relevance of our study and allowed us to obtain an in-depth insight into how DEMO can assist in OSSD process modeling. It was decided to perform a single case study, as this would allow us to investigate and describe the case in sufcient detail. Our case study had an exploratory nature: since no prior research has been performed on this topic, our main interest was in determining whether it is feasible to use DEMO for OSSD process modeling. The unit of analysis consisted of a single OSSD process within a specic OSS project. This scope is suitable for a case study [39,38,40]. Hence, a suitable OSSD process needed to be selected. We posited two main criteria that such a process needed to satisfy. First, the process should be sufciently large so that it produces something of value for the OSS community. Second, we preferred to study an OSSD process that has already been modeled and published before in literature using a different modeling technique. By starting from a previously published model, we are condent that the original model is an accurate representation of the actual OSSD process. Hence, it can be assumed the model exhibits a sufcient degree of internal validity. We decided to study the NetBeans Requirements and Release process, which satises both criteria described above. The main production fact that can be identied in this process is the completion of a new release. In addition, the process was previously modeled by Atkinson et al. [12] by using a formal modeling language (i.e., PML). This model is based on the early work of Jensen et al. [41] who described various OSS artifacts (e.g., update events, road maps, message postings, and forums). As discussed in Section 2.2, DEMO considers these artifacts as physical representations of production and coordination facts, which indicate ontological process steps. Data collection took place by gathering secondary data. The most important data source consisted of the PML model developed by Atkinson et al. [12]. This model is included as an appendix to this paper. Additional information to construct the DEMO models was taken from other research studies investigating the NetBeans Requirements and Release process (i.e., [41,5,16,6]). Finally, archival

data was used from the NetBeans website to further support model development. This publicly available data was very helpful when there was any uncertainty with respect to how the process should be modeled in DEMO. Data analysis consisted of the development of the DEMO models representing the OSSD process. To this end, the data was interpreted by following the methodology prescribed by DEMO. This was an iterative process, in which the models were step-wise rened. Triangulation between the various data sources took place by ensuring consistency of the model with the various data sources in order to increase the validity of the study. To further increase validity, the models were developed by the rst author of this paper and subsequently reviewed by the other two authors. The rst version of the models presented in this paper took one author about 8 h to develop. The models were then rened in iterative discussions with the other authors. In total, 2 person-days were invested in the development of the nal models. 3.2. DEMO models The DEMO model of an organization is expressed in various diagrams. In this paper, we will only use the Process-Structure-Diagram (PSD) and the Actor-Transaction-Diagram (ATD). The PSD shows the details of interactions between transactions. The ATD provides an overview of the actors and transactions within the scope of the enterprise and therefore aggregates the information contained within the PSD. Additional diagrams need to be specied to obtain a complete DEMO model: a state model to specify the data used in the process, an interstriction model to relate the information to the actors who need it, and an action model to represent the action rules for the various actors. These models include additional ontological information about the process. The original PML model focuses on the process activities and does not specify which data is used, or which action rules apply to the process. Therefore, additional data would be needed to construct all DEMO models. However, the ATD and PSD models are most relevant to this paper. Both the ATD and PSD are basic models that are always developed for a given process or organization. They allow to obtain a quick, high-level and abstract overview of the process. The additional models are only developed if there is a specic need for them. Most applications of DEMO in practice are limited to the PSD and ATD models. In addition, the ATD and PSD most clearly illustrate the different approach taken by DEMO. Since our aim is to illustrate the advantages of DEMO within OSSD process modeling, we will make use of the ATD and PSD. Before developing the PSD and ATD model for the NetBeans Requirements and Release process, we will rst briey describe the purpose and syntax of both diagrams. We will illustrate this with a practical example within the context of OSSD process modeling. Consider the process through which patches can be submitted to an OSS project by using a patch tracker such as available on SourceForge.net. A contributor can submit a patch which xes a given bug to the tracking system. Before the patch is actually committed to the version control system, the maintainer requests one of the core developers to verify that the patch xes the bug, does not introduce new bugs, and complies with the coding and quality conventions of the OSS project. If this review is positive, the patch is committed to the version control system by the project maintainer. Although this example is ctitious, it is a process that is commonly found in many OSS projects [13]. A rst model that was developed for this example is the ProcessStructure-Diagram (PSD). The notation for the PSD is based on the notation used in the basic transaction pattern shown in Fig. 2. However, in order to make this model more compact, the symbols used in the basic transaction pattern to denote the act and fact related to each process step are merged into a single symbol in the

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

661

Fig. 4. An Actor-Transaction-Diagram. Fig. 3. A Process-Structure-Diagram.

PSD. This is possible since each P-act or C-act has a corresponding P-fact or C-fact, respectively. A combination of a P-act and P-fact is represented by a diamond in a square, while a combination of a Cact and C-fact is represented by a circle within a square. Each symbol therefore represents a single process step. The process steps belonging to the responsibility of a single actor role are grouped in a box with a light-gray border.1 An arrow with a solid line represents the normal process ow, while an arrow with a dotted line represents a wait condition. The PSD for the imaginary process described above is shown in Fig. 3. The process starts with the T01rq process step in which the Contributor submits a patch by using the tracker, thereby requesting the Maintainer to include the patch in the new release. The Maintainer acknowledges receipt of the patch by assigning the patch a priority level. This represents the Maintainers promise to execute transaction T01 (cf., T01pm). The Maintainer then requests a new transaction (cf., T02rq). The Maintainer requests that one of the Core Developers in the project performs a review of the proposed patch by assigning one of the developers to the patch. The Core Developer then promises to perform the review (cf., T02pm). The developer may, for example, acknowledge that he will review the patch by adding a comment to the tracker. This can also be an implicit process step if it is common that a Core Developer reviews all patches that are assigned to him by the Maintainer. The Core Developer then performs the review (cf., the T02 execute process step). In the next step, the Core Developer publishes his recommendation by changing the resolution eld of the patch to accepted, assuming of course that the review was positive (cf., T02st). The Maintainer then accepts the recommendation by the Core Developer (cf., T02ac) by adding a comment to the tracker. Next, once again assuming that the recommendation is positive, the Maintainer executes transaction T01 by committing the patch to the version control system. The dotted arrow from T02ac to T01 indicates that the Maintainer waits with performing transaction T01 until the recommendation of the Core Developer has been received (cf., the composition axiom). After committing the patch, the Maintainer sets the status eld of the patch to closedand possibly adds a comment explaining that the patch has been committedthereby showing that the transaction T01 has been per-

formed (cf., T01st). Finally, the Contributor accepts this result (cf., T01ac), which may be an implicit process step, or can take place by posting an acknowledgment to the tracker. The second model that was developed for this example is the Actor-Transaction-Diagram (ATD). In the ATD, a single symbol is used for each transaction, which thus contains all the process steps. This symbol is a diamond in a circle, to represent the combination of the P-fact and C-facts related to the transaction. The initiator is connected to the transaction symbol by a solid line. The executor is connected to the transaction by a solid line ending in a black square. The corresponding ATD for our example is shown in Fig. 4. It shows that for transaction T01, the Contributor is the initiator and the Maintainer the executor. For transaction T02, the Maintainer is the initiator and the Core Developer the executor. 3.3. The NetBeans Requirements and Release process The rst step in constructing a DEMO model consists of the identication of actors responsible for initiating and executing a transaction. Although the PML model does not dene any specic actors, we base our naming of DEMO actors on subsequent work of Jensen and Scacchi [5,16] in which a number of agents are identied. For the Requirements and Release process, the following actors are retained: ReleaseManager, Debugger and Community. The Community hereby refers to the union of all agents (e.g., ReleaseManager, Debugger, User and The Board). The Community initiates the request for a new release. The release is then managed by the ReleaseManager who initiates the transactions required to create a new release. These transactions require the Community and Debugger in order to be completed.2 We can now specify the DEMO process steps of the main transaction T01: Release Completion. The process ow is represented graphically in the PSD in Fig. 5 as the process steps of transaction T01 (T01rq, T01pm, T01ex, T01st and T01ac).  Request (T01rq): In this process step, the Community species a request, i.e., a set of features to be added to the project. The Community therefore is the initiating actor of this transaction. The aggregation of the various agents into the Community actor allows that features can be requested by users, developers and

1 In order to improve model readability, a certain actor role can have multiple boxes.

2 For illustrative purposes, some simplications have been made. In order to provide more detail, additional actors could possibly be identied.

662

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

Fig. 5. Process-Structure-Diagram for the NetBeans Requirements and Release process.

the NetBeans Board. The completion of the request is a coordination fact, which is expressed in the ProspectiveFeatures list. The features in this list are based on the road map, vision statement, documentation from the previous release and IssueZilla repository.3  Promise (T01pm): The ReleaseManager then has to evaluate the request, and decide which features will be included in the new release. This responsibility belongs to the executing actor of the transaction. While certain tasks can be delegated to other members of the community, the ReleaseManager remains responsible for the promised features. Based on the prospective features list, a development proposal is made, and developers and deadlines are assigned. Also, a new release manager is ofcially chosen.4 Once again, we see that documents from the datalogical level (i.e., the development proposal) are artifacts which indicate the coordination facts in the DEMO model. The promise step is completed when the features are frozen, developers have been assigned and release dates have been set.  Execute (T01ex): The executor of the transaction (i.e., the ReleaseManager) ensures that those features which were conrmed in the promise step will be included in the next release. The features are implemented in the software and executables are built. This step is not elaborated upon in the PML model.  State (T01st): In this process step, the executor delivers the result of the execution step to the initiator. Here, the new release is offered to the community. The binaries are uploaded to the web repositorywhich is the responsibility of the ReleaseManagerand the Community is notied by the web site and mailing lists. These notications are datalogical indications of the state coordination fact.

 Accept (T01ac): The initiator of the transaction (i.e., the Community) accepts the result stated by the executor. Before accepting the nal release, it has to be veried that the release works properly. Therefore, the accept step contains the test and debug sequences. Once accepted, the nal release can be used by the Community. Every process step of this high-level transaction still contains many activities. Not all of these activities have separate goals or result in new production facts. Hence, no additional DEMO transactions were created for such activities. However, the addition of new information usually indicates that a new transaction occurs. We can distinguish three additional transactions that result in a new production fact and which group cohesive communication and production activities together. In the promise process step, various activities relate to community feedback (e.g., SendMessageToCommunityForFeedback, ReviewFeedbackFromCommunity and ReviseProposalBasedOnFeedback). These activities are actually coordination acts aimed at incorporating the community feedback for nalizing the feature set. Therefore, we can summarize these activities in a new transaction. We called this transaction T02: Feature Set Finalizing. The request of this transaction consists of the proposal of a feature set, which is sent to the Community for feedback. The Community will review the feature set and state its feedback. This feedback is the Pfact that is created in this transaction. Based upon the accepted feedback, a revised feature set is composed and posted on the web site. The inclusion of community feedback is important new information for the OSSD process. Other transactions that can be identied are T03: Establishing a Release Manager and T04: Debugging. Fig. 5 also shows the interaction between the process steps of the four transactions. It can be seen that T02ac and T03st have to be completed before the ReleaseManager can promise the execution of T01: the feature set must be nalized and the ReleaseManager must be appointed. Also, the Community does not accept the new release before T04: Debugging has been completed.

3 These documents would be modeled in DEMO as information banks. Information banks are production or coordination facts which are created in another transaction, but which are required to complete the current transaction. However, information banks are only modeled in DEMO diagrams that are outside the scope of this paper. 4 Based on the PML model, it can be assumed that the release manager for version n will be responsible for the former tasks, until the release manager for version n 1 is chosen. In DEMO, both individuals are aggregated into the ReleaseManager actor.

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671 Table 2 Mapping of the PML activities to DEMO T02: Feature Set Finalizing. DEMO process step Request (T02rq) PML activities

663

Execute (T02) Accept (T02ac)

CompileListOfPossibleFeaturesToInclude CategorizeFeaturesProposedFeatureSet CreateDevelopmentProposal SendMessageToCommunityForFeedback Community formulates feedbacka ReviewFeedbackFromCommunity ReviseProposalBasedOnFeedback PostFinalDevelopmentProposalToNetBeansWebsite

This process step was not mentioned in the PML model.

Table 3 Mapping of the PML activities to DEMO T03: Establishing Release Manager. DEMO process step Request (T03rq) Promise (T03pm) Execute (T03) State (T03st) PML activities EmailSolicitationForReleaseManager CollectCandidacyNominations EstablishReleaseManagerConsensus AnnounceNewReleaseManger

Fig. 6. Actor-Transaction-Diagram for the NetBeans Requirements and Release process.

Table 4 Mapping of the PML activities to DEMO T04: Debugging. DEMO process step PML activities PostBugstats ExamineTestReport WriteBugFix VerifyBugFix CommitCodeToCvsCodeRepository UpdateIssueZillaToReectChanges

Table 1 Mapping of the PML activities to DEMO T01: Release Completion. DEMO process step Request (T01rq) PML activities ReviewRoadmap SetReleaseDate ReviewNetBeansVisionStatement ReviewUncompletedMilestonesFromPreviousRelease ReviewIssueZillaFeatureRequests T02 Feature Set Finalizing Requesta AssignDevelopersToCompleteProjectMilestones SetReleaseCompletionDates SetMilestoneCompletionDates T03 Establishing Release Manager Requesta ChangeBuildBranchName MakeInstallTarForEachPlatform BuildBinaryRelease UploadInstallTarFilesToWebRepository UpdateWebpage MakeReadmeInstallationNotesAndChangelog SendReleaseNoticationToCommunityInvitingTheCommunityToDownload AndTestIt CreateTestScripts ExecuteAutomaticTestScripts ExecuteManualTestScripts ReportIssuesToIssueZilla UpdateStandingIssueStatus T04 Debugging Requesta CompleteStabilization

Request (T04rq) Promise (T04pm) Execute (T04) Accept (T04ac)

Promise (T01pm)

Execute (T01) State (T01st)

Accept (T01ac)

Process step requires completion of other DEMO transaction.

the three additional DEMO transactions that were previously identied (i.e., T02, T03 and T04). Transaction T02: Feature Set Finalizing, for example, is part of the promise process step of the transaction T01: Release Completion. It was also noted that some process steps were missing from the PML model. For example, the Community formulates feedback activity (see Table 2) has been added since the execute process step of transaction T02: Feature Set Finalizing was not provided in the PML model. In DEMO, this step is crucial since it determines who is the executor of the transaction. In the same transaction T02, no state process step is identied in which the community presents its feedback to the release manager. Despite the omission of this step in the PML model, it clearly does occur, and physical artifacts will exist to indicate its occurrence. Therefore, this process step should be added to the PSD. The promise process step of transaction T02 is also missing. No explicit communication artifact seems to correspond with this process step. It can therefore considered to be an implicit process step. However, it should be considered whether this omission means that the community can be expected to always provide feedback, or whether the absence of feedback indicates that the community agrees with the development proposal. 4. Evaluating the quality of DEMO models So far, we have illustrated that it is possible to apply DEMO to OSSD process modeling, and that DEMO results in abstract OSSD models. However, it is also important that the models are of high quality to allow for the processes to be reenacted in other projects or settings [8]. Hence, we need to determine whether the DEMO models that were developed in this paper are of a sufciently high quality. Literature has paid much attention to the quality of conceptual models, as evidenced by the number of quality frameworks

A summary of the transactions is provided by the ATD in Fig. 6. In this model, the Community requests a new release from the ReleaseManager (T01: Release Completion). The ReleaseManager then requests other transactions (T02: Feature Set Finalizing, T03: Establishing Release Manager and T04: Debugging) in order to be able to execute this request. In order to further clarify the relationship between the original activities in the PML model and the process steps in the DEMO transactions, we added the concrete mapping in Tables 14. Table 1 shows that additional activities have been added to those included in the PML model. These activities refer to the execution of

664

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

that have been proposed (see e.g., [4247]). The framework of Moody and Shanks [48] attempts to largely integrate the efforts of these previous frameworks and is one of the few that has been empirically tested. We will use the criteria included in the quality framework of Moody and Shanks to evaluate the quality of the DEMO models that were created in this paper. 4.1. Completeness and integrity Completeness refers to the extent to which the model contains all user requirements [49,48]. A related quality factor is integrity, which refers to the extent to which all business rules have been included in the model [49,48]. Both completeness and integrity are closely related [49] and are therefore discussed here together. In our case study, we noticed that some process steps of a DEMO transaction were not documented in the PML model. Table 2 shows that no activities were related to the promise, execute and state steps concerning the T02: Feature Set Finalizing transaction. Although the promise step was considered to be implicit in this process, the addition of an execution step is mandatory, as it is the essence of a transaction in DEMO. An additional activity Community formulates feedback has been added to rectify this problem. Overall, ensuring completeness is mainly the responsibility of the analyst. However, it can be argued that DEMO has assisted us in this task by the use of the transaction pattern (see Fig. 2), since it forces the analyst to look for manifestations of the process steps. 4.2. Flexibility Flexibility refers to the ease with which the model can cope with business and/or regulatory change [49,48]. It can be noted that both the PSD and ATD in Figs. 5 and 6 are robust against several changes in the NetBeans development process. The PSD is stable against changes in the exact sequence in which the various activities within each process step are executed. Table 1 shows that if the sequence of activities within the promise step changed (e.g., the release and milestone completion dates are set before assigning developers to milestones), the PSD would not need to be changed (while the PML model would need to be updated). Similarly, the PSD is not concerned with the implementation of the various activities, and is therefore not dependent on the exact tools that are used. If NetBeans changed their bug tracker from IssueZilla to BugZilla or Mantis, the PSD model would not require any changes (while the PML model would need to be modied). In addition, the ATD and PSD are stable against changes in the composition of members of the OSS community that participate in the OSSD process. According to DEMO, all these changes do not reect a change on the ontological level. This is facilitated by dening actors in terms of the initiator and executor of a transaction. Therefore, the use of the transaction pattern appears to be a quite stable foundation to build process models. Since both DEMO models that were developed in this paper are stable against incidental changes within the OSSD process and the composition of the OSS community, they appear to address both challenges mentioned in Section 2.1. 4.3. Integration Integration refers to the extent to which the model is consistent with the rest of the organization [49,48]. This reduces the development effort and assists in the collection, comparison and aggregation of data [49]. With respect to OSSD process modeling, integration is concerned with the extent to which different models of various OSS projects can be integrated or compared to each other. Since we have conducted a single case study, we cannot make any claims about the quality of our DEMO models with respect to this quality factor. However, it can be argued that our

examples in Section 4.2 on exibility are also relevant in this context. We have demonstrated that our DEMO models were stable against incidental changes in the implementation of the OSSD process and the composition of the OSS community within a single OSSD process over time. Hence, if these changes occurred between two OSSD processes, it would mean that the DEMO models for both OSSD processes would be the same. The models should only differ if there are essential, ontological differences between both OSSD processes. This should allow to more easily compare OSSD process models between multiple OSS projects. However, since we have no data that can support this claim, we remain cautious with respect to this statement. 4.4. Simplicity Simplicity refers to the size and complexity of the model, or in other words, the extent to which the model contains a minimum number of constructs [49,48]. The fewer constructs are used, the higher the exibility, implementability and understandability of the model [49]. Both the ATD and PSD models developed in this paper are very concise models. Furthermore, if the PSD in Fig. 5 was translated into a textual format, the description would still be more concise than the PML model. Conversely, if the PML model was transformed into a graphical model, the number of elements in the model would be larger than those in the PSD. In general, an ATD only contains four constructs, while a PSD consists of ve constructs and ve process steps. The low number of constructs is a consequence of the high level of abstraction provided by DEMO by only modeling the essential transactions underlying a process. This also lowered the complexity of both the ATD and PSD developed in this paper. 4.5. Understandability Understandability refers to the extent to which the concepts and constructs in the models are easy to understand by users of the model [49,48]. At rst sight, the PSD and ATD developed in this paper may be rather difcult to understand for someone who is not familiar with the notation. On the other hand, it must be noted that the DEMO models use a limited number of constructs (cf., simplicity) and follow the transaction pattern (cf., completeness and integrity). This limits the number of concepts that someone must learn in order to understand the models described in this paper. 4.6. Implementability Implementability refers to the ease with which the model can be implemented within time and budget, subject to technical and economical constraints [49,48]. The DEMO models described in this paper do not score well with respect to implementability. The PSD in Fig. 5 describes the NetBeans OSSD process at the ontological level, thus leaving out all details related to the actual implementation of the process. This is inherent to DEMO, since its aim is to obtain an implementation independent view of an organization. Although this can be considered an important advantage with respect to exibility and integration, it also implies that the PSD and ATD models are not sufcient to actually implement the model. For example, it is unknown from the PSD which activities can be found in each process step. To assist in the implementation, additional DEMO models (which are outside the scope of this paper) are required.5
5 We only discussed the ontological level of DEMO due to space limitations. Currently, research is being performed to model the infological and datalogical levels in DEMO as well, which provide more insight into how the processes are implemented.

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

665

4.7. Correctness Correctness refers to the extent to which the model conforms to the rules and conventions of the modeling technique, and thus whether it can be considered to be a valid model [48]. We are condent that the ATD and PSD developed in this paper are correct models, meaning that they comply with the notation and practices of DEMO and that they accurately model the NetBeans Requirements and Release process. However, similar to completeness and integrity, the modeling language cannot ensure correctness of the model and remains the responsibility of the analyst. Nevertheless, we experienced that the use of a limited number of constructs (cf., simplicity) and the standard transaction pattern (cf., completeness and integrity) allowed us to more easily verify the correctness of the ATD and PSD models. 5. Discussion The research hypothesis guiding our study was that the DEMO methodology can be used to obtain abstract and high-quality OSSD process models. To this end, a case study on the NetBeans Requirements and Release process was performed. We have determined that DEMO can indeed be used for OSSD process modeling by creating the ATD and PSD model that describes this OSSD process. The case study also showed that our DEMO models exhibited a high level of abstraction, thereby reducing the complexity of the OSSD process models. Finally, the evaluation of the models developed in this paper by using the quality framework of Moody and Shanks [48] showed that both models were of a sufciently high quality. Based on these observations, we can conclude that DEMO can indeed be used to model OSSD processes to obtain abstract and high-quality OSSD process models. We will now discuss our results in more detail. 5.1. Potential of DEMO for OSSD process modeling DEMO uses a fundamentally different approach compared to other modeling techniques given its theoretical foundation. Within the context of OSSD process modeling, DEMO offers two unique features. A rst feature of DEMO is that it analyzes processes at the ontological level. This results in high-level and abstract process descriptions. At the start of this paper, we established that OSSD process modeling languages should be sufciently high-level and abstract. This is required to address two important challenges in OSSD process modeling, namely that the process modeling language should be able to: (1) aggregate and synthesize the data from a large number of projects; and (2) model the essential underlying processes of OSS projects. We have illustrated that since DEMO only models the essential transactions underlying a process, it addresses both of these challenges and therefore results in models that are stable against incidental variations in processes across OSS projects as well as incidental changes in the composition or practices of the community over time. The robustness of DEMO models is also demonstrated in previous research by the application of DEMO to the business process re-engineering of the Ford purchasing department described by Hammer [50]. Although the implementation of the business processes were drastically altered, the DEMO model describing the essential transactions remained the same [51]. This is enabled by the fact that DEMO makes abstraction of the actual implementation of the business processes. The high level of abstraction also considerably reduces model documentation [51]. For example, DEMO was recently used to assist in the merger of the cargo divisions of Air France and KLM [52]. The essential model of the joint cargo divisions of Air France and KLM consisted of 49 transactions and 46 actors, thereby providing a concise model of

the organization [52]. The ontological approach used by DEMO has other advantages than abstraction. The use of an ontology provides clear denitions for the constructs used in the various models, thereby removing much ambiguity in interpretation. It ensures that the abstract conceptualizations are shared and understood by all stakeholders. DEMO also provides clear guidelines, thereby limiting the subjectivity in the modeling process. This reduces variability in the models developed by multiple modelers [7]. A second interesting feature of DEMO is that it focuses on the communication between social actors [51]. This allows for a clear specication of actor roles and responsibilities. The focus on the interaction of social actors is particularly useful when studying the OSSD process, in which the aim is to understand how various actors within the community cooperate (see e.g., [36]). Other process modeling techniques (e.g., ow charts) tend to focus more on the control ow in the process [53]. Hence, DEMO provides an alternative perspective with its focus on communication patterns between actors. The application of DEMO within the context of OSSD process modeling may therefore offer interesting new insights into how OSSD processes are organized. Notwithstanding the strong points of DEMO, the evaluation of our models based on the various quality factors also identied a few reservations towards its use within the OSSD process modeling context. A rst reservation concerns the implementability of the DEMO models. Since all implementation-related details are abstracted away in DEMO, additional models should be created. To assist in this, DEMO supports a multi-level modeling approach. As can be derived from Fig. 6, the ATD abstracts a lot from the underlying process, but more detail can be added in the PSD (see Fig. 5). In fact, DEMO supports additional model views, but given the space available in this paper, we did not elaborate upon these. This multi-level modeling approach is useful, since the system may be too large to be depicted in a single model. Also, it allows the designer of the model to focus his or her attention on a specic part of the model, since one is often not interested in all details of a model [53]. Other authors have also argued for a multi-level modeling approach, including in OSSD process modeling [6,15]. Whether this low implementability is an issue depends on the aim for which the models are going to be used. If the aim is to construct models that allow a process to be reenacted in other OSS projects, then DEMO models will omit information that is required to actually implement the model. In that case, the use of DEMO is not desirable. However, if the aim of the model is to analyze a process at a high level of abstraction, then DEMO assists in removing information from the model that is not essential. A second reservation concerned the understandability of the DEMO models. The main issue is that the DEMO notation is currently not well-known which may be a concern when communicating a model to other parties. However, it is our experience that the DEMO methodology is relatively easy to learn. Various education programs exist to teach the DEMO methodology and allow participants to become Certied DEMO Professional. Courses at the postgraduate level take approximately 5 full days. We are teaching the DEMO methodology at the undergraduate level in a class of 6 ECTS (European Credit Transfer and Accumulation System). It is our experience that although students initially nd the models very abstract and rather difcult to comprehend, they quickly gain profound insight into the DEMO methodology. The aim for which the models are going to be used may once again inuence whether DEMO offers the most desirable approach in a specic situation. When the aim of the researcher is to communicate process models back to other parties (e.g., the OSS community), traditional modeling techniques may be more appropriate since they are generally easier to understand. However, researchers could use DEMO to analyze their data and use other notations for communicating the results.

666

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

5.2. Research contributions This study has a number of contributions. A rst contribution is that we illustrated that it is feasible to use DEMO for OSSD process modeling. We therefore propose the use of a new approach within the domain of OSSD process modeling. As illustrated in this paper, DEMO may offer some signicant advantages over other modeling techniques. DEMO has already proven several of these advantages in other domains and in real-life and complex settings. We believe researchers working on OSSD process modeling could similarly benet from using the DEMO approach. More specically, we have shown that DEMO has the potential to address two important challenges within the OSSD process modeling eld. A second contribution is that the methodology we propose to use within OSSD process modeling is fundamentally different from the currently used methodologies and approaches. DEMO indeed differs in several ways from other modeling techniques. Not only does DEMO offer a high level of abstraction, it also uses an ontological approach to process modeling. This ontological approach has a strong theoretical background in the Communicative Action and Language-Action Perspective theories. Such theoretical foundation is not present in other methodologies that are used for process modeling. Thanks to this fundamentally different approach, DEMO offers a different perspective to analyze OSSD processes. It can therefore be expected that the application of DEMO for OSSD process modeling will generate new insights. A nal contribution is that we extended the use of DEMO in a new domain, i.e., OSSD process modeling. DEMO has already been used in domains such as organization engineering, business process redesign, and information systems development. Our study was the rst to investigate the feasibility of using DEMO for OSSD process modeling. This further increases the external validity of the DEMO approach. 5.3. Limitations and future research This study has a few limitations that could provide the basis for future research. A rst limitation concerns the external validity of this study. Since we have made use of an exploratory single case study, it is difcult to generalize the results of this study to other settings. This raises the question as to whether DEMO can also be used to model larger and more complex processes than the one described in this paper. DEMO has been frequently used to model the processes within an organization in real world situations (see e.g., [52,7,54,21]). Since there is no apparent reason why OSSD processes would be inherently more complex than organizational processes, it can be expected that DEMO is suitable for modeling other OSSD processes as well. Another consequence of using a single case study is that we cannot demonstrate that the use of DEMO is also feasible in other application domains. However, DEMO can in principle be applied to model any process, as long as the process creates a relevant new production fact. Therefore, there is no theoretical reason why the use of DEMO would be limited to a specic application domain. There are also no indications from previous applications of DEMO in various domains (such as organization engineering, business process redesign and information systems development) that would suggest the existence of such limitations. Nevertheless, although there are indications that DEMO scales up to applications beyond the scope of this paper, more research is required to investigate whether our ndings indeed hold in other situations. Another limitation is that DEMO currently does not contain any features that are specic to the modeling of software development processes. Other techniques are specically focused on modeling software development processes, such as the meta-model of Mi and Scacchi [55], or PML [12]. Other authors have proposed reference models or taxonomies that provide OSS-specic extensions

(see e.g., [6,19,5]). Currently, DEMO does not provide such OSSor software-oriented features. However, we believe that this does not necessarily have to be a disadvantage. DEMO makes no prior assumptions about the OSSD process, which allows the modeler to start from a clean slate without being restricted to specic actors, artifacts or transactions. Nevertheless, future research could investigate whether such modications are desirable. 6. Conclusion In this paper, we have shown by means of a case study that the DEMO methodology can be successfully used to model OSSD processes to obtain abstract and high-quality OSSD process models. DEMO exhibits two unique features within the context of OSSD process modeling. First, it studies OSSD processes at the ontological level, while other modeling approaches primarily focus on the implementation level. As a result, DEMO offers a high-level process view in a very concise form. This is a desirable property since process models for the purpose of aggregating and synthesizing data from a large number of OSS projects and/or modeling the essential underlying processes of OSS projects should not include too many details. Otherwise, some differences may be magnied which complicates the comparison of multiple process models. A second interesting characteristic of DEMO is that it takes the communication patterns between human actors as the starting point for the analysis; this in contrast to modeling techniques such as PML that focus on the sequences in which certain development activities are performed. We feel that OSSD process modeling is more concerned with how developers communicate and coordinate work, rather than the exact sequence in which tasks are performed. When evaluating the DEMO models developed in this study using a quality framework from the conceptual modeling literature, it shows that DEMO exhibits several desirable characteristics within the context of OSSD process modeling. Notwithstanding these desirable properties, DEMO also has a number of potential drawbacks. The most important disadvantage concerns the understandability and implementability of DEMO models. Due to the specic notation, DEMO models may be hard to understand by those that are unfamiliar with the notation. In addition, DEMO models do not contain any implementation-related details. Hence, DEMO may be less well suited for communicating and reenacting OSSD process models to other parties. Therefore, we primarily propose the use of DEMO within OSSD process modeling as an analysis tool, that should be complemented with other techniques and models for communication and reenactment purposes. Researchers should therefore consider the aim for which the models are going to be used in order to decide whether DEMO is the most desirable approach. Therefore, we are not proposing the use of DEMO to fully replace existing software process modeling techniques such as PML, SPEM or ow charts, but rather to complement these existing techniques. In that case, the lesser understandability and implementability of DEMO models become less important concerns. 7. Further reading We would like to refer readers who are interested in learning more about DEMO to two main sources. The primary reference on DEMO is the book by Jan Dietz [7]. It fully describes the ontological background, the methodology and models (including those not covered in this paper) of DEMO and provides various examples of DEMO models. Second, additional information on DEMO is available on the website of the DEMO Knowledge Centre (http://www. demo.nl/). The goal of the DEMO Knowledge Centre is to drive the further development of DEMO and to stimulate its use. The website contains information on the various DEMO models, case

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

667

studies on real-life applications of DEMO, a list of tools that support DEMO, as well as a list of education initiatives that are dedicated to teaching DEMO. The website also hosts a large database of publications related to DEMO.

Appendix A. PML NetBeans Model The PML Model of the NetBeans Requirements and Release process, as described by [12] is shown below:

process RequirementsAndRelease { sequence Requirements { sequence SetProjectTimeline { action ReviewRoadmap { requires {Roadmap} provides {Roadmap.Reviewed} } action SetReleaseDate { requires {Roadmap} provides {(derived) ReleaseDate} } sequence DetermineProject { branch SunONEStudioDevelopmentMeeting { action ReviewNetBeansVisionStatmenet { requires {VisionStatement} provides {VisionStatement.Reviewed} } action ReviewUncompletedMilestonesFromPreviousRelease { requires {Documentation.PreviousVersionRelease} provides {(derived) ProspectiveFeatures.PreviousVersions == "complete"} } action ReviewIssuzillaFeatureRequests { requires {IssuzillaIssueRepository} provides {(derived) ProspectiveFeatures.Issuezilla == "complete"} } } iteration EstablishFeatureSet { action CompileListOfPossibleFeaturesToInclude { requires {ProspectiveFeatures.Issuezilla && ProspectiveFeatures.PreviousVersions} provides {(derived) ReleaseFeatureSet} } action CategorizeFeaturesProposedFeatureSet { requires {ReleaseFeatureSet} provides {ReleaseFeatureSet.weighted} } action CreateDevelopmentProposal { requires {ReleaseFeatureSet.weighted} provides {(derived) DevelopmentProposal} } action SendMessageToCommunityForFeedback { requires {ReleaseFeatureSet.weighted && DevelopmentProposal && CommunityMailingList} provides {(derived) CommunityFeedback} } action ReviewFeedbackFromCommunity { requires {CommunityFeedback && DevelopmentProposal} provides {DevelopmentProposal.PotentialRevisions} } action ReviseProposalBasedOnFeedback { requires {DevelopmentProposal.PotentialRevisions} provides {DevelopmentProposal.Revised} } } action PostFinalDevelopmentProposalToNetBeansWebsite { requires {DevelopmentProposal.Revised}

668

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

provides {DevelopmentProposal.Finalized} } action AssignDevelopersToCompleteProjectMilestones { requires {DevelopmentProposal.Finalized} provides {(derived) DeveloperAssignments} } } sequence SetReleaseStageCompletionDates { action SetFeatureFreezeDate { requires {ReleaseDate} provides {(derived) FeatureFreezeDate} } action SetMilestoneCompletionDates { requires {FeatureFreezeDate && ReleaseDate} provides {(derived) MilestoneCompletionDates} } } } sequence EstablishReleaseManager { action EmailSolicitationForReleaseManager { requires {CommunityMailingList} provides {(derived) ReleaseManagerRequest} } iteration CollectCandidacyNominations { action SendCandidacyAnnouncement { requires {ReleaseManagerRequest} provides {(derived) ReleaseManagerCandidacyAnnouncement} } } action EstablishReleaseManagerConsensus { requires {ReleaseManagerCandidacyAnnouncement} provides {(derived) ReleaseManagerDecision} } action AnnounceNewReleaseManager { requires {ReleaseManagerDecision} provides {(derived) ReleaseManagerAnnoucementToNbdevMailingList} } } action SolicitModuleMaintainersForInclusionInUpcomingRelease { requires {FeatureFreezeDate} provides {(derived) ModuleInclusionNoticeToNbdevMailingList} } } sequence Release { iteration Stabilization { sequence Build { action ChangeBuildBranchName { requires {CvsCodeRepository} provides {(derived) BuildBranch} } iteration MakeInstallTar { action MakeInstallTarForEachPlatform { requires {BuildBranch} provides {(derived) InstallExecutableTar} } } } sequence Deploy { action BuildBinaryReleases { requires {BuildBranch && InstallExecutableTar} provides {(derived) ReleaseBinaries} } action UploadInstallTarFilesToWebRepository { requires {ReleaseBinaries && WebRepository}

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

669

provides {ReleaseBinaries.Uploaded} } action UpdateWebPage { requires {Webpage} provides {Webpage.Updated} } action MakeReadmeInstallationNotesAndChangelog { requires {Modules.Changes} provides {(derived) README && (derived) InstallationNotes && (derived) ChangeLog} } action SendReleaseNotificationToCommunityInvitingTheCommunityToDownloadAndTestI t { requires {CommunityMailingList} provides {(derived) ReleaseNotice} } } sequence Test { action CreateTestScripts { requires {BuildBranch && ReleaseFeatureSet} provides {(derived) TestScripts} } action ExecuteAutomaticTestScripts { requires {TestScripts && ReleaseBinaries} provides {(derived) TestResults.ScriptResults} } action ExecuteManualTestScripts { requires {TestScripts && ReleaseBinaries} provides {(derived) TestResults.ManualResults} } iteration UpdateIssuezilla { action ReportIssuesToIssuezilla { requires {TestResults.ScriptResults && TestResults.ManualResults} provides {(derived) IssuezillaIssueRepository.StandingIssues} } action UpdateStandingIssueStatus { requires {IssuezillaIssueRepository.StandingIssues && TestResults} provides {IssuezillaIssueRepository.Updated} } } action PostBugStats { requires {TestResults} provides {(derived) BugStatusReport && (derived) TestReport} } } sequence Debug { action ExamineTestReport { requires {TestReport && BugStatusReport} provides {TestReport.Examined} } action WriteBugFix { requires {BuildBranch} provides {(derived) PotentialBugFix} } action VerifyBugFix { requires {PotentialBugFix} provides {(derived) WorkingBugFix} } action CommitCodeToCvsCodeRepository { requires {WorkingBugFix && CvsCodeRepository} provides {CvsCodeRepository.Updated} } action UpdateIssuezillaToReflectChanges { requires {IssuezillaIssueRepository} provides {IssuezillaIssueRepository.Updated} }

670

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671

} } action CompleteStabilization { requires {ReleaseBinaries && TestReport && Webpage} provides {(derived) FinalRelease && Webpage.Updated} } } }

References
[1] J. Feller, P. Finnegan, D. Kelly, M. MacNamara, Developing open source software: a community-based analysis of research, in: E.M. Trauth, D. Howcroft, T. Butler, B. Fitzgerald, J.I. Degross (Eds.), Social Inclusion: Societal and Organizational Implications for Information Systems, IFIP TC8 WG8.2 International Working Conference, Limerick, Ireland, July 1215, 2006, IFIP International Federation for Information Processing, vol. 208, Springer, Boston, MA, 2006, pp. 261278. [2] W. Scacchi, Process models in software engineering, in: J.J. Marciniak (Ed.), Encyclopedia of Software Engineering, second ed., John Wiley & Sons, New York, NY, 2002, pp. 9931005. [3] W. Scacchi, C. Jensen, J. Noll, M. Elliott, Multi-modal modeling, analysis and validation of open source software requirements processes, in: Proceedings of the 1st International Conference on Open Source Systems, Genova, Italy, 2005. [4] W. Scacchi, Opportunities and challenges for modeling and simulating free/ open source software processes, keynote Address presented at the 5th International Workshop on Software Process Simulation and Modeling, Edinburgh, Scotland, May 2004, October 2004. [5] C. Jensen, W. Scacchi, Experiences in discovering, modeling, and reenacting open source software development processes, Lecture Notes in Computer Science 3840 (2006) 449462. [6] J. Lonchamp, Open source software development process modeling, in: Software Process Modeling, International Series in Software Engineering, vol. 10, Springer, Boston, MA, 2005, pp. 2964. [7] J.L. Dietz, Enterprise Ontology: Theory and Methodology, Springer, Berlin, 2006. [8] L. Carvalho, L. Scott, R. Jeffery, An exploratory study into the use of qualitative research methods in descriptive process modelling, Information and Software Technology 47 (2) (2005) 113127. [9] P. Soffer, Y. Wand, Goal-driven multi-process analysis, Journal of the Association for Information Systems 8 (3) (2007) 175203. [10] P. Kettunen, M. Laanti, How to steer an embedded software project: tactics for selecting the software process model, Information and Software Technology 47 (9) (2005) 587608. [11] J.-C. Derniame, B.A. Kaba, D.G. Wastell (Eds.), Software Process: Principles, Methodology, Technology, Lecture Notes in Computer Science, vol. 1500, Springer-Verlag, London, UK, 1999. [12] D.C. Atkinson, D.C. Weeks, J. Noll, Tool support for iterative software process modeling, Information and Software Technology 49 (5) (2006) 493514. [13] A. Mockus, R.T. Fielding, J.D. Herbsleb, Two case studies of open source software development: Apache and Mozilla, ACM Transactions on Software Engineering and Methodology 11 (3) (2002) 309345. [14] W. Scacchi, Free/open source software development: recent research results and emerging opportunities, in: Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software Engineering (ESEC-FSE07), ACM, New York, NY, 2007, pp. 459468. [15] W. Scacchi, C. Jensen, J. Noll, M. Elliott, Multi-modal modeling, analysis and validation of open source software requirements processes, International Journal on Internet Technology and Web Engineering 1 (3) (2006) 4963. [16] C. Jensen, W. Scacchi, Process modeling across the web information infrastructure, Software Process: Improvement and Practice 10 (3) (2005) 255272. [17] C. Jensen, W. Scacchi, Computer support for discovering OSS processes, in: Proceedings of the 3rd International Workshop on Public Data about Software Development, Milan, Italy, September 10, 2008, 2008. [18] C. Jensen, W. Scacchi, Data mining for software process discovery in open source software development communities, in: A.E. Hassan, R.C. Holt, A. Mockus (Eds.), Proceedings of the Workshop on Mining Software Repositories (MSR 2007), Edinburgh, Scotland, May 25, 2004, 2004. [19] C. Jensen, W. Scacchi, Guiding the discovery of open source software processes with a reference model, in: Open Source Development, Adoption and Innovation: Proceedings of the Third International Conference on Open Source Systems (OSS 2007), Limerick, Ireland, June 1114, 2007, IFIP International Federation for Information Processing, vol. 234, Springer, Boston, MA, 2007, pp. 265270. [20] C. Jensen, W. Scacchi, Automating the discovery and modeling of open source software development processes, in: J. Feller, B. Fitzgerald, S.A. Hissam, K. Lakhani (Eds.), Taking Stock of the Bazaar: Proceedings of the 3rd ICSE [21]

[22]

[23] [24]

[25]

[26]

[27]

[28]

[29] [30]

[31]

[32]

[33]

[34]

[35]

[36]

[37] [38] [39]

[40] [41]

[42] [43] [44] [45]

Workshop on Open Source Software Engineering, Portland, Oregon, May 3, 2003, 2003, pp. 7578. J. Dietz, M. Dumay, H. Mulder, Demo or practice: critical analysis of the language/action perspective, in: Proceedings of the 10th International Conference on the Language-Action Perspective, 2005. T.R. Gruber, Toward principles for the design of ontologies used for knowledge sharing?, International Journal HumanComputer Studies 43 (5/6) (1995) 907928 J. Habermas, The Theory of Communicative Action: Reason and Rationalization of Society, vol. 1, Beacon Press, Boston, MA, 1984. F. Flores, J. Ludlow, Doing and speaking in the ofce, in: G. Fick, R.H. Sprague (Eds.), Decision Support Systems: Issues and Challenges, Pergamon Press, New York, NY, 1980, pp. 95118. R. Stamper, K. Liu, M. Hafkamp, Y. Ades, Understanding the roles of signs and norms in organizations: A semiotic approach to information systems, Journal of Behavior and Information Technology 19 (1) (2000) 1527. D. Van Nuffel, H. Mulder, S. Van Kervel, Enhancing the formal foundations of BPMN by enterprise ontology, in: Advances in Enterprise Engineering III, Lecture Notes in Business Information Processing, vol. 34, Springer, Berlin, Heidelberg, 2009, pp. 115129. D. Strijdhaftig, On the coupling of architectures leveraging DEMO theory within the ARIS framework, Masters thesis, Delft University of Technology, The Netherlands, September 2008. R.M. Dijkman, M. Dumas, C. Ouyang, Semantics and analysis of business process models in BPMN, Information and Software Technology 50 (12) (2008) 12811294. P. Green, M. Rosemann, Integrated process modeling: an ontological evaluation, Information Systems 25 (2) (2000) 7387. K. Crowston, B. Scozzi, Open source software projects as virtual organizations: Competency rallying for software development, IEE Proceedings Software 149 (1) (2002) 317. M.J. Gallivan, Striking a balance between trust and control in a virtual organization: a content analysis of open source software case studies, Information Systems Journal 11 (4) (2001) 277304. K. Crowston, J. Howison, Hierarchy and centralization in free and open source software team communications, Knowledge, Technology & Policy 18 (4) (2006) 6585. R. van Wendel de Joode, H. de Bruijn, M. van Eeten, Software development and coordination tools in open source communities, in: S.K. Sowe, I. Stamelos, I. Samoladas (Eds.), Emerging Free and Open Source Software Practices, IGI Publishing, Hershey, PA, 2007, pp. 96119. K. Crowston, B. Scozzi, Coordination practices for bug xing within FLOSS development teams, in: Proceedings of the First International Workshop on Computer Supported Activity Coordination (CSAC 2004), Porto, Portugal, 2004. C. Jensen, W. Scacchi, Collaboration, leadership, control, and conict negotiation and the netbeans.org open source software development community, in: Proceedings of the 38th Hawaii International Conference on System Sciences, Hawaii, 2005. K. Crowston, Q. Li, K. Wei, U.Y. Eseryel, J. Howison, Self-organization of teams for free/libre open source software development, Information and Software Technology 49 (6) (2007) 564575. L. Yu, Self-organization process in open-sourcenext term software: an empirical study, Information and Software Technology 50 (5) (2008) 361374. R.K. Yin, Case Study Research: Design and Methods, 3rd ed., Sage Publications, Newbury Park, CA, 2003. P. Runeson, M. Hst, Guidelines for conducting and reporting case study research in software engineering, Empirical Software Engineering 14 (2) (2009) 131164. I. Benbasat, D.K. Goldstein, M. Mead, The case research strategy in studies of information systems, MIS Quarterly 11 (3) (1987) 368386. C. Jensen, W. Scacchi, M.O. Oza, E.N. Nistor, S. Hu, A rst look at the netbeans requirements and release process, Technical report, Institute for Software Research, 2004. O.I. Lindland, G. Sindre, A. Solvberg, Understanding quality in conceptual modeling, IEEE Software 11 (2) (1994) 4249. S. Kesh, Evaluating the quality of entity relationship models, Information and Software Technology 37 (12) (1995) 681689. A. Levitin, T.C. Redman, Quality dimensions of a conceptual view, Information Processing & Management 31 (1) (1994) 8188. C. Fox, A.V. Levitin, T.C. Redman, The notion of data and its quality dimensions, Information Processing & Management 30 (1) (1994) 919.

P. Huysmans et al. / Information and Software Technology 52 (2010) 656671 [46] R.G. Dromey, A model for software product quality, IEEE Transactions on Software Engineering 21 (2) (1995) 146162. [47] M. El-Attar, J. Miller, Improving the quality of use case models using antipatterns, Software and Systems Modeling, forthcoming, doi:10.1007/ s10270-009-0112-9. [48] D.L. Moody, G.G. Shanks, Improving the quality of data models: empirical validation of a quality management framework, Information Systems 28 (6) (2003) 619650. [49] D.L. Moody, G.G. Shanks, What makes a good data model? Evaluating the quality of entity relationship models, in: Proceedings of the 13th International Conference on the Entity-Relationship Approach (ER94), Lecture Notes in Computer Science, Springer, London, UK, 1994, pp. 94111. [50] M. Hammer, Reengineering work: do not automate, obliterate, Harvard Business Review 68 (4) (1990) 104112.

671

[51] J.L. Dietz, The deep structure of business processes, Communications of the ACM 49 (5) (2006) 5864. [52] M. Opt Land, H. Zwitzer, P. Ensink, Q. Lebel, Towards a fast enterprise ontology based method for post merger integration, in: Proceedings of the 2009 ACM Symposium on Applied Computing (SAC09), Honolulu, Hawaii, March 812, 2009, ACM, New York, NY, 2009, pp. 245252. [53] J. Barjis, Automatic business process analysis and simulation based on DEMO, Enterprise Information Systems 1 (4) (2007) 365381. [54] H. Mulder, Rapid enterprise design, Ph.D. Dissertation, Technische Universiteit Delft, Delft, The Netherlands, 2006. [55] P. Mi, W. Scacchi, A meta-model for formulating knowledge-based models of software development, Decision Support Systems 17 (4) (1996) 313330.

Potrebbero piacerti anche