Constructing Software-intensive Methods: A Design ...

4 downloads 36467 Views 182KB Size Report
lows the construction of so-called software-intensive methods. ... specific IT systems documentation, realized exemplarily for business intelligence (BI) systems ...
Constructing Software-Intensive Methods: A Design Science Research Process with Early Feedback Cycles Robert Krawatzeck1, Marcus Hofmann1, Frieder Jacobi1, and Barbara Dinter2 1

Chemnitz University of Technology, Chemnitz, Germany

{robert.krawatzeck,marcus.hofmann,frieder.jacobi} @wirtschaft.tu-chemnitz.de 2

University of Erlangen-Nuremberg, Erlangen-Nuremberg, Germany

[email protected]

Abstract. Methods are a common artifact within design science research (DSR). In the context of a research project we faced the challenge to develop a method and a software artifact in parallel. However, existing work in DSR and method engineering does not explicitly address the simultaneous development of two interdependent artifacts. Therefore, we developed a DSR process that allows the construction of so-called software-intensive methods. It considers the interdependencies of both artifacts and optimizes common DSR processes by including early feedback cycles for intermediate results - allowing the identification of initial design weaknesses like missing or dispensable design elements, inappropriate element design and usability flaws. The process has been applied and its feasibility has been demonstrated in the research project. Keywords: design science, research process, method engineering, software prototype, early feedback, generate-test cycle.

1

Motivation and Problem Statement

Methods are a major and approved means for organizational engineering in information systems research by providing detailed, goal-oriented descriptions of activities which have to be performed in order to solve a specific problem [1]. The construction is methodologically supported (amongst others) by generic design science research (DSR) processes, such as proposed by [2], and by method engineering [3]. Sometimes the application of a method requires extensive use of software artifacts. In such cases, the method should provide instructions describing the role of the software artifact within the method. If the required software artifact does not exist at the time of method construction, it should be developed simultaneously. We call such a method a software-intensive method (SIM). The construction of a SIM combines the disciplines of information systems research and software engineering (SE). For two years we are working on a research project [4] in the context of IT system documentation. Throughout our research project aiming at constructing a SIM we realized that the simultaneous development of a method and a corresponding software artifact is not well covered by generic DSR processes. This observation resulted in the The final publication is available at link.springer.com: http://link.springer.com/chapter/10.1007/978-3-64238827-9_41.

Constructing Software-Intensive Methods

following research question: How can the construction of a SIM be supported by a DSR process that explicitly considers the simultaneous development of a method and of a software artifact? In order to answer this question we have designed a SIM-specific DSR process by ‘recursively’ applying the generic DSR process as proposed in [2]. We have demonstrated its feasibility in the aforementioned research project. The remainder of the paper is organized as follows: After a short presentation of our research project we discuss the need for a SIM-specific research process in more detail (Section 2). By means of a generic DSR process we develop the SIM-specific DSR process in Section 3. Its demonstration in the context of our research project is presented in Section 4. Concluding, the findings are summarized and an outlook to further research is given (Section 5).

2

Situation and Project Presentation

The third party funded research project “Computer-Aided Data Warehouse Engineering” (CAWE) runs for three years (currently in its third year) with four researchers. The project aims at constructing a method for cost-efficient, high-quality, userspecific IT systems documentation, realized exemplarily for business intelligence (BI) systems [4]. Analyzing the state of the art has shown that no suitable software artifacts (tools) exist which cover the system documentation tasks comprehensively. Thus, the need to simultaneously develop such an artifact has emerged. A prototype has been implemented and presented to the scientific community [5] and practitioners. Currently, we construct the method for automated BI system documentation using the prototype. We checked the domains of DSR, method engineering, and SE for adequate methodologies for SIM construction. However, existing DSR approaches [e.g. 2, 6] are of limited benefit, since they are too generic and do not address the simultaneous development of multiple artifacts as it is required for a SIM. Applying a generic DSR process would result in cycling the process (semi-)sequentially several times (in our case twice). In addition, the mutual and/or combined evaluation of the artifacts would be deferred to the final stages of the design and development process. If potential design weaknesses are not detected before the final evaluation, the adaptation of artifacts will be costly (in terms of time and money) since design, development, and evaluation activities have to be repeated. Also, method engineering [3, 7] does not consider the interdependencies of a SIM and its corresponding software artifact. SE methods on the other hand describe in detail how to develop the software artifact but do not take into account how to construct the method. The missing support for the SIM construction in our concrete case and the observation that many projects in research and practice face the same problem have underlined the need for answering the research question as formulated in Section 1.

3

Design of a Research Process for the Construction of a SIM

We followed the DSR process as introduced by [2] to design a research process for the SIM construction. The steps are described briefly in the following. 3.1

Problem Identification and Motivation

The relevance of supporting the construction of SIMs has already been motivated in Sections 1 and 2. As previous contributions do not address the simultaneous development of artifacts (and of a method and a software artifact in particular) this research gap has to be closed. 3.2

Objectives of the Solution

Keeping in mind that costly steps should not be repeated during the construction of a SIM, and that early evidence about the SIM usability should be gained, evaluable intermediate results should be available as soon as possible. Those intermediate results aim at providing  early information about initial design weaknesses like missing or dispensable design elements, inappropriate element design and usability flaws caused by design decisions (objective A) and  insights, if the method will be superior compared to existing solutions (objective B). Such information allows early, incremental adaptation instead of late and expensive changes. Consequently, the SIM research process should consider early intermediate results in the design and development process. A further objective is its applicability in other projects (both, in research and practice). 3.3

Design and Development

We are using the DSR process by Peffers et al. [2] not only to design and develop the research process for SIM construction. It also constitutes an appropriate starting point for our research question, i.e. we will modify this process by adding activities for the simultaneous development of a SIM and its supporting software artifact. Therefore, we adapt the activities as proposed by [2] and combine them with the “generate/test cycle” as proposed by [6]. The generate/test cycle allows early feedback cycles as also known from agile software development methods [8]. Those feedback cycles are necessary to ensure early information about initial design weaknesses and meet objective A. Developing a method and the corresponding software being of use when applying the method can be supported by a model which describes and connects the business problem and software solution space [1]. Figure 1 exemplarily shows an extract of such a model which connects the domains BI and Documentation. Such a model can, for example, be specified using the Unified Modeling Language (UML) as known

Constructing Software-Intensive Methods

from SE. The model – in terms of a framework – can be used to develop the software prototype by instantiation and the method by construction. Since the model is a crucial part within the method development, its suitability and possible contribution should be proven early (objective B). According to [6], one option to evaluate artifacts is to compare the usefulness of the created artifacts against the usefulness of other existing artifacts which solve the same problem. If such other models are known and accessible, the evaluation can be performed at that time. Otherwise the evaluation has to be done indirectly via the model-based software prototype and the comparison with other software solutions. If the model is extensive, it might suffice to develop a vertical prototype which covers all model elements but not the whole business problem space.

Business Intelligence Configuration Model

Organization Model

conforms to

conforms to

Documentation Configuration Meta-Model

Organization Meta-Model uses

uses (Platform-independent) Documentation Subject Model

conforms to

(Platform-independent) Documentation Subject Meta-Model uses IT Infrastructure Meta-Model

PIM M2M

Documentation

M2M

uses Documentation Meta-Model

conforms to

Documentation Model

uses ...... ... T

Fig. 1. Exemplary extract of a model which serves as the basis for software prototype development and method construction [4]

The considerations lead to the following SIM-specific DSR process (cf. Fig. 2). After the problem identification and motivation (1) objectives have to be defined (2). Thereafter, a model (3) has to be developed with regard to the objectives. This model describes the problem and solution spaces and connects them. In order to prove that the developed model is suitable, a software prototype will be instantiated based on the model (4). This prototype constitutes the basis for demonstrating the feasibility and serves as the starting point for the subsequent comparative evaluation (5). Positive evaluation results underline the suitability of the model as a basis for the method aimed at. The steps 3 to 5 should be repeated until the model suitability is proven (corresponds to the generate/test cycle as proposed by [6]). If so, the method based on this model can be constructed (6). This will be achieved by assigning all elements described in the model (e.g. the Configuration Model; cf. Fig. 1) to different stakeholder roles involved and formulating activities as well as necessary deliverables [3]. Finally, the method can be evaluated e.g. in form of case studies (7) which terminates the process if the result is positive. Otherwise, the process has to be repeated, starting

from step 2, 3, or 6, depending on the weaknesses identified during the evaluation. The main modifications of the initial, generic DSR process by [2] refer to the steps 3 to 5.

Problem identification & motivation

Definition of objectives 1

2

Design and development of a framework with regard to the objectives (Model) 3

Demonstration of the feasibility of the model through prototypical implementation (Instance) 4

Indicates the suitability of the model

Evaluation of the method 7

Construction of activites and instructions from the developed model (Method) 6

Evaluation of the instance in comparison to existing solutions 5

Fig. 2. A DSR process for the construction of SIMs with early feedback cycles

3.4

Demonstration

We demonstrate the feasibility of the SIM construction process in detail in Section 4 by applying it in the research project CAWE and therefore refer to this section. 3.5

Evaluation & Communication

Since this paper presents work-in-progress, not all research activities have been conducted at the time of writing. The research process will be evaluated by case studies and expert interviews. Communication will take place mainly by means of research papers, starting with this contribution.

4

Demonstration of the Feasibility through the Project CAWE

In this section a case study is presented to demonstrate the feasibility of the suggested research process. It is based on the research project introduced in Section 2. Step 1: Problem Identification and Motivation. By means of an online survey, the CAWE project has identified three reasons why enterprises document the architecture components of BI systems insufficiently or not at all [4]: (I) The costs of the documentation creation are too high, (II) the durability of the documentation is too low, and (III) the lacking suitability of the structure and content of the documentation for different audiences. These shortcomings motivate the following research goal of the project [4]: Development of a method for BI system documentation.

Constructing Software-Intensive Methods

An analysis of the software market has shown that no tool exists that can document BI systems comprehensively in an automated manner. Furthermore, existing software solutions for specific BI system layers document insufficiently [9]. Hence, not only a method but also a software artifact is needed to attain the research goal. Step 2: Description of Objectives. In face of the aforementioned reasons why enterprises document their BI system architecture components insufficiently or not at all, the following objectives of a solution were defined [4]: The method aimed at should provide a possibility to generate documentation in a cost-efficient manner (objective I), being of high-quality (objective II), and user-specific (objective III). Step 3: Design and Development of a Framework. Since previous studies have shown that the costs for the generation of documentation for multidimensional data structures – as one part of BI systems – using automated documentation processes can be reduced by up to 75% [10], an automated approach for meeting objective I has been chosen [4]. To meet objective II we decided to fulfill the eight criteria for highquality documentation as suggested by Wallmüller [11]: changeability, up-todateness, clarity, identifiability, norm-conformity, comprehensibility, completeness and consistency. In order to consider different user needs (objective III), Wallmüller [11] further suggests to generate different instances of the documentation which are customized according to the interests of the audience. However, not all criteria of high-quality documentation are necessarily different for different audiences. Therefore, the criteria were divided into audience-dependent (called document criteria, such as completeness) and audience-independent criteria (so-called creation process criteria, such as changeability) [4]. The decision to use automation was applied to both criteria groups because the quality of the documentation as well as the user-specific content shall be achieved without high costs. Subsequently, a model in form of a framework which describes the domains “BI systems” and “documentation” (cf. Fig. 1) has been designed and developed [4]. We decided to use the Model-driven Architecture (MDA) approach for automating the documentation process and for linking both domains. By applying the automated generation of documentation directly on reverseengineered BI application models, all creation process criteria are fulfilled. For generating audience-specific documentation, new models have been introduced to ensure the configuration ability. This configuration approach allows an audience-specific adjustment of the provided content [4]. Step 4: Demonstration of the Feasibility through a Software Prototype. In order to demonstrate the feasibility of the developed framework through a prototypical instantiation, the framework for the documentation has been limited to ETL (extraction, transformation, and loading) processes in BI systems [9]. This limitation allows the implementation of a vertical prototype, which covers all proposed model elements without the effort of implementing all BI system layers. Consequently, the

vertical prototype can be used to gather practitioners’ feedback and allows a comparative evaluation against existing ETL documentation tools. Subsequently, a prototype for the automated generation of user-specific ETL documentation has been implemented and presented to the scientific community [5] and practitioners. Several shortcomings become obvious, resulting from practitioners’ feedback and consolidated implementation experiences: a) It is not always possible to clearly assign a particular BI tool to a specific BI layer (inappropriate design), b) a central starting point, combining all available BI layer information, for analysis is missing (missing design element), and c) the proposed configuration can be implemented in general, but is too complex to be done by business users (usability problem of the design). These shortcomings have been considered within the early adoption of the initial designed framework, even before the method construction has been started. Step 5: Comparative Evaluation. The prototype allows comparing the artifacts generated during the automated documentation against generated the ones by other documentation tools. The criteria for the comparison have been derived from the aforementioned objectives. Different ETL modeling tools – namely the built-in documentation components of IBM DataStage and Talend Open Studio as well as the third-party tools SSIS Documenter and BI Documenter – were investigated with regard to their ability of automatically generating documentation [9]. Due to the restricted selection of automated solutions for documentation generation, all investigated tools, including our prototype, fulfill the objective for cost-efficiency (objective I) as well as the creation process criteria (first part of objective II). However, our prototype achieved significant improvements in the field of document criteria (second part of objective II) by means of meta-data analysis. Furthermore, our prototype is apparently the only tool providing the option for user-specific configuration (objective III). Consequently, the former argumentation allowed us to conclude that the prototype is superior to other existing documentation solutions. Since the evaluated artifacts have been generated based on the developed framework, it is deducible that the framework itself provides additional benefit. Thus, it forms an adequate basis for the construction of the method for cost-efficient generation of BI system documentation. Step 6 & 7: Method Construction & Final Evaluation. The project CAWE currently is in the phase of method construction. At the moment, the method covers activities required to fulfill objective III as formulated in Section 4.2, e.g. audiences should create and maintain their individual configuration models (cf. Fig. 1) before the automated documentation process can be started. The resulting method will be evaluated in form of case studies with industry partners who have already been involved in the research process. Finally, since the SIM-specific modification of the research process only affects steps 3 to 5, the steps 6 and 7 are conducted as described in [2].

Constructing Software-Intensive Methods

5

Conclusion and Further Work

The paper suggests a DSR process for the construction of SIMs contributing to information systems research by enabling helpful feedback within early development stages. Thus, potential design mistakes become aware early and can be fixed with manageable effort and time, which leads to a more efficient but still rigorous design process and more suitable solutions in the field. The feasibility and advantages of the research process were demonstrated within a case study. Since the presented work is in progress, further steps have to be performed. The demonstration will be enhanced by further case studies using similar research projects developing a SIM. In addition, the benefits of the suggested SIM research process in contrast to cycle generic DSR processes twice will be evaluated by expert interviews. Acknowledgements. This research has been partly funded by the European Social Fund and the Federal State of Saxony, Germany.

References 1. March, S.T., Smith, G.F.: Design and Natural Science Research on Information Technology. Decision Support Systems, 15 (4), 251–266 (1995) 2. Peffers, K., Tuunanen, T., Rothenberger, M., Chatterjee, S.: A Design Science Research Methodology for Information Systems Research. J. of MIS, 24 (3), 45–77 (2007) 3. Brinkkemper, S.: Method Engineering: Engineering of Information Systems Development Methods and Tools. J. of Information and Software Technology, 38(4), 275–280 (1996) 4. Krawatzeck, R., Jacobi, F., Müller, A., Hofmann, M.: Konzeption eines Frameworks zur automatisierten Erstellung nutzerspezifischer IT-Systemdokumentationen. In: Workshop Business Intelligence 2011 (WSBI 2011) der GI-Fachgruppe BI, pp. 15–26, CEUR (2011) 5. Krawatzeck, R., Jacobi, F., Hofmann M.: CAWE DW Documenter: A Model-driven Tool for Customizable ETL Documentation Generation. In: Castano, S., Vassiliadis, P., Lakshmanan, L., Lee, M.L. (eds.) ER 2012. LNCS, vol. 7518, pp. 400-403. Springer, Heidelberg (2012) 6. Hevner, A.R., March, S. T., Park, J., Ram, S.: Design Science in Information Systems Research. MIS Quarterly, 28(1), 75–105 (2004) 7. Braun, C., Wortmann, F., Hafner, M., Winter, R.: Method Construction – A Core Approach to Organizational Engineering. In: 20th Annual ACM symposium on Applied computing (SAC’05). pp. 1295–1299. ACM Press, New York (2005) 8. Jeffries, R., Jeffries, R. E., Anderson A.: Extreme Programming Installed. AddisonWesley, Amsterdam (2000) 9. Jacobi, F., Krawatzeck, R., Hofmann, M.: Meeting the Need for ETL Documentation: A Model-driven Framework for Customizable Documentation Generation. In: 18th Americas Conference on Information Systems (AMCIS 2012), Paper 23. AISeL (2012) 10. Gluchowski, P., Kurze, C.: Modellierung und Dokumentation von BI-Systemen. CONTROLLING 22, 676–682 (2010) 11. Wallmüller, E.: Software-Qualitätsmanagement in der Praxis: Software-Qualität durch Führung und Verbesserung von Software-Prozessen (2nd ed.). Hanser Fachbuch, Munich, Germany (2001)