toward a well-structured development methodology for business process-oriented software systems...

Procedia Technology 9 ( 2013 ) 351 – 360

2212-0173 © 2013 The Authors Published by Elsevier Ltd.Selection and/or peer-review under responsibility of SCIKA – Association for Promotion and Dissemination of Scientific Knowledgedoi: 10.1016/j.protcy.2013.12.039

ScienceDirect

CENTERIS 2013 - Conference on ENTERprise Information Systems / PRojMAN 2013 - International Conference on Project MANagement / HCIST 2013 - International Conference on

Health and Social Care Information Systems and Technologies

Toward a well-structured Development Methodology for Business Process-oriented Software Systems based on Services

Margarita Mondragóna,*, Manuel Moraa, Laura Garzaa, Francisco Álvareza, Laura Rodríguezb, Hector A. Duran-Limonc

aAutonomous University of Aguascalientes, Av. Universidad N° 940, Ciudad Universitaria, C. P. 20131, Ags., Ags., México bInstitute of Technology of Aguascalientes, Av. Adolfo López Mateos N° 1801 Ote., Fracc. Bona Gens, C.P. 20256, Ags., Ags., México

cUniversity of Guadalajara,Av. Juárez N° 976, Col. Centro, C.P. 44100, Gdl., Jal., México.

Abstract

Contemporaneous business organizations face process operational effectiveness and efficiency challenges for being successful in the current competitive global markets. For such aim, BPMS technology has provided support for deployment and monitoring BPM environments in the last 15 years. Rarely, the development of business process-oriented software systems (BPoSS) has been guided by diverse proprietary or ad-hoc non-standardized methodologies. Thus, for BPoSS, in contrast with other types of software systems, well-structured and standardized development methodologies are still missing. We believe that such a knowledge gap must be addressed. Therefore, this study introduces SDM-BPoSS (Systems Development Methodology for BPoSS) as an approach to a well-structured development methodology. BPMS practitioners and academicians are expected to be benefit from our approach.

© 2013 Published by Elsevier Ltd. Selection and/or peer-review under responsibility of CENTERIS/ProjMAN/HCIST.

Keywords: Business Process Management Systems, System Development Methodologies, Processes-Oriented Software Engineering, Business Process, Web Services.

* Corresponding author. Tel.: 01-449-9108417; fax: 01-449-9108402. E-mail address: [email protected]

Available online at www.sciencedirect.com

© 2013 The Authors Published by Elsevier Ltd.Selection and/or peer-review under responsibility of SCIKA – Association for Promotion and Dissemination of Scientifi c Knowledge

352 Margarita Mondragón et al. / Procedia Technology 9 ( 2013 ) 351 – 360

1. Introduction

Currently, business companies are facing relevant challenges for executing efficiently and effectively their core business process. This is derived from the fierce competitive global markets and the complexity of such business process [1]. As a result, the business organizations are investing more on information technological support for improving their core business processes [2-5]. Thus, the research in Enterprise Systems Management, Business Processes Management and Web Services, which has a significant impact on operational business processes [6], is currently investigated by individuals [7-9], and large IT firms (IBM, Oracle and Microsoft). In particular, various types of tools have emerged [10-12] for addressing the BPM (Business Process Management) problem. These BPM tools are used by large firms to model, analyze and redesign business processes. Other more advanced BPM tools also enact the business processes [12]. Nevertheless, despite the availability of these basic and advanced BPM tools, they do not provide a well-structured and standardized development methodology. Thus, the software engineering recommendations on the utilization of a well-defined development process for assuring an expected level of compliance on quality, time and budget project metrics are lost, and BPMS practitioners must use an ad-hoc methodology.

Standardized BPMS (Business Process Management Systems) development methodologies are expected by BPMS practitioners similarly to the available methodologies for other types of software systems (e.g. object-oriented, component-based, and service-oriented approaches). However, a recent review on the state of the art literature shows that such a standardization in methodologies does not exist at present [13]. Consequently, BPMS practitioners face a variety of methodologies which are reported with different structure levels (e.g. phases, activities, tasks, roles, artifacts, and tools) [7]. Additionally, while there are some well-structured proprietary methodologies (ARIS, IBM, Oracle), these are not affordable for small and medium sized business. In the event of searching in the open source domain, knowledge gaps are still reported in BPMS development methodologies [14-15].

Software Engineering literature suggests that systems development methodologies (or software development processes) are required [16-18]. In [16] it is reported that following a methodology is a key success factor for the development of software projects. In [17] it is reported that some software applications are complex, and difficult to develop and evaluate, thus, a well-defined development process can help to reduce the risks of failures. In turn in [18] it is reported that the new software systems based on operational business processes are demanding better development approaches, given that the unique utilization of BPMS tools is insufficient. Therefore one of the main objectives pursued by researchers in the area of Software Engineering is to improve the process whereby software is developed, and in particular improve the development processes for business process-oriented software systems based in services [2, 15, 18, 19].

In this research, we address such a knowledge gap, and using a Design Research [20] approach, a new BoSS well-structured development methodology is reported. According to Hevner [20] the generated artifact is a method, and the evaluation method is descriptive/scenarios (e.g. a demo problem case and a proof of concept).

2. State of the Art in Business Process-oriented System Development Methodologies

Despite the availability of advanced BPMS technology for deploying BPoSS, still there are several factors that limit their effective and efficient utilization. Main of them are the following: (i) communication barriers due to the different used terminology between business process users and developers [21-22]; (ii) unshared and incompatible business and technological vision on the operational business processes using different ad-hoc system development methodologies [15, 18, 22]; (iii) a non-standardized and uncompleted set of documentation of the developed system caused by the particular BPMS used tool [7, 18, 21]; (iv) lack of stability in the developed system caused by the false belief that using an advanced BPMS tool will permit


complex changes in a seamless mode [7, 18]; and (v) lack of standardized and well-structured development methodologies [11, 12, 15, 21].

In [13] an extensive review of main system development methodologies is reported which can be used for business process-oriented software systems based on services. In this section, we present an updated summarization of it. This review is based on the following foundations: (i) Avison’s definition of methodology [16] as "recommended collection of phases, procedures, rules, techniques, tools, documentation, management, and training used to develop a system."; and (ii) Oktaba and Ibarguengoitia’s [23] definition of a well-structured software process as "a composition of phases, activities, artifacts, roles and actors (people or tools)”. Nine methodologies were analyzed. All of them were selected as they provided the minimum information required to apply consistent analysis considering systems development with Business Process approach through Web Services. For each methodology various phases were identified with their activities, artifacts, tools, techniques and roles. Figure 1 reports a partial view of the analysis by space limitations (the complete analysis can be consulted in [13]). The key issues for each analyzed methodology are as follows:

Fig. 1 Partial comparison matrix of SDM for Business Process oriented Software Systems


M1: Papazoglou and Van Den [24]. It provides a roadmap to assist service providers and multipart assembly of Business Processes as well as inventory control and invocation of Web services. It comprises a preparatory stage of development planning and five phases that focus on Business Processes. The main objective is to define a basis for the development of web services inside the business process.

M2: Rodriguez et al. [19]. Although its primary focus is on services, their initial phases within are considered as a starting point to the Business Processes modeling task, as well as the inclusion of web services. It consists of various phases outlined each with different roles and artifacts.

M3:M. Stember, Kovacic and Jacklic [25]. It aims to be a methodology to implement Business Processes in the Public Sector supported by the levels of maturity of Business Processes in the target organization.

M4: Karastoyanova [26]. It is a methodology for development and implementation of Web Services based on Process. It is aimed at the life cycle flow of Web services (WS-Flow). Each stage adds different aspects of the process definition.

M5: Chinosi [27]. This methodology includes three phases which provide a design methodology. It considers the utilization of Web Services and presents mainly a contribution to a new conceptual model for BPMN called BPEX for the Business Processes.

M6: Chopra and Munindar [28]. A methodology called Amoeba is reported. This methodology introduces key computational abstractions in addition to the process modeling and adaptations to the inter-organizational Business Process.

M7: Sanchez, Beautiful and Joyanes [29]. This methodological proposal is focused on business context on demand based on MDA and SOA. Its focus is on the early phases related to modeling business until the early models of software.

M8: Fernandes and Duarte [5]. They present a generic framework for software development in organizations with a high process orientation. Its main focus is on using RUP and UML.

M9: Kruchten [30]. It is a proposal to updated classic RUP as a Software Development Methodology also for BPoSS. It adds to its early stages business processes modeling task. As mentioned in Figure 1, an initial comparison matrix was generated to report each of the elements that are

part of each one of the compared methodologies. Subsequently additional tables (not reported here by space limitations) with detailed analysis were developed. These tables were useful to answering the following inquiries: (i) what are the most complete methodologies for BPoSS ? ; (ii) what are the most business process-oriented methodologies? ; (iii) what are the similarities and differences among them?; and (iv) what are the most relevant components reported in them useful for a generic system development methodology?

M9, M2 and M5 methodologies were the most comprehensive. These methodologies cover all expected phases, activities, roles, tools and artifacts. Nevertheless, they have different structure of components and they cannot be reported as standardized methodologies. From the business process-oriented perspective, M4, M2 and M3 provides more number of components linked to business process issues. Here, whereas M9 is the most comprehensive it also is for traditional object-oriented systems rather than for business process-oriented systems.

To measure the degree of complexity to implement each approach, we have used a simple but useful metric: the number of activities that are reported. Based on it, M8 has 23 elements, M1 has 22, M5 has 20, M9 has 17 and M2 has 16. It is noteworthy that a more detailed analysis is required given that each element can present per se an internal level of greater or lesser complexity. Nevertheless, such single metric is useful to estimate the number of documents to be generated in each methodology. Under this overall evaluation, [13] is reported as the current best methodology for developing BPoSS to M5, M4 and M2.

As a result of the State of the Art an initial proposal of SDM-BPoSS design (Alpha version) was generated and reported in [13]. It had 4 phases, 20 activities, 17 artifacts, 4 techniques and 6 roles. This proposal is shown in Figure 2. SDM-BPoSS aims to provide a simple alternative for practical use and teaching guide suitable for real projects of medium size. The phases, activities, artifacts, techniques and roles proposal in Figure 2, have


been evaluated conceptually through its rationality within the SDM foundations, by a panel of 12 academics in Software Engineering (from Latin America and Europe regions). Their evaluations were on constructs: perceived usefulness, ease of use, and compatibility.

3. SDM-BPoSS

3.1. Description of SDM-BPoSS

From the results of the previous reported evaluation of SDM-BPoSS, the three activities with highest scores in each phase were selected. Our rationale was to generate a version with balanced rigor and agile levels. Thus, a reduced SDM-BPoSS version (Beta version) emerged. For completing it, the artifact, role and technical elements with scores greater than average score were selected. This SDM-BPoSS (Beta version) has 4 phases, 11 activities, 11 artifacts, 4 techniques and 6 Roles (see Figure 2 and Table 1).

Fig. 2 SDM-BPoSS (Alpha Version) vs SDM-BPoSS (Beta Version)


3.2. Phases Description SDM-BPoSS (Beta Version)

Table 1.Phases and Activities of SDM-BPoSS

Prevision Phase. It is a preparation phase. It aims to establish a real commitment from the stakeholders of the planned BPoSS. It has been identified as a critical success factor.

Activity 1. Identify Stakeholders To identify the key parties which are involved in the project (stakeholders). Afterwards, it is required to discover and understand the main needs of stakeholders.

Activity 2. Define Objectives, Purpose and Scope.

To set objectives, purpose and scope of the project. Clear objective, purpose and scope of what is expected to achieve will impact positively to the work-plan. It will, in turn, impact on the schedule, quality and budget metrics.

Activity 3. Establish a management commitment.

To get success at every stage of a development project it is essential to count with a complete support and commitment of the management team. A formal document that establishes this liabilities is highly recommended.

Analysis and Design Phase. In this phase are identified the key business processes to be considered for the BPoSS. Clear boundaries are set and elements which are necessary for their design and subsequent automation are completed.

Activity 4. Identify Roles and Responsibilities and Map Interaction.

A key element in the business process analysis is to identify roles and activities done by its participants. To observe the way they interact to deeply understand the process itself and identity issues as bottleneck in it are also necessary. At this step it is worthy to specify whether the process is or has been executed in a different way, identifying actors and its interaction as a point of reference for alternatives modes of operation.

Activity 5. Identify Business Rules Business Rules are statements of policy or conditions that must be met. These are usually documented as passive entities that contain purely declarative statements and therefore should not take any action. However they should be available through engines of BPMS.

Activity 6. Process Modeling This activity can be considered one of the central which links the planned with the build BPoSS. It is suggested to model the business process using BPMN. It due to that BPMN is an international standard modeling processes notation accepted by the community, it is independent of any process modeling methodology, and helps to create a standardized bridge to reduce the gap between business processes and the implementation of these.

Construction Phase. In this phase the planned and identified specifications for the BPoSS are realized in an executable BPoSS.

Activity 7. Codification Services Web services help to automate processes. Furthermore they foment the efficiency through the avoidance of repetitive codification of the same functionalities. The used level of Coding is adapted through the chosen development tool by the company, given its needs and the project budget.

Activity 8. Service Orchestration The integration of internal (made-in-house) and external web services to create a business processes in high level view is known as service orchestration. In the event of considered business process that is being automated, then this activity should be included, but if not required, can be omitted.

Activity 9. System Integration (Extra Code)

This activity refers to all remaining coding that are required to complete the development of the BPoSS.

Execution and Monitoring Phase. Once that the BPoSS has been built (including implicit tests), it is ready for being released. This phase accounts for its utilization and monitoring. Such a monitoring task must provide statistics for future improvements.

Activity 10. Execution and Process Monitoring.

The climax of process automation is the execution. It is realized using a proprietary or open source BPMS tool.


Activity 11. Detection Process Improvement.

The reports generated from process monitoring task must be analyzed. Their analysis can reveal unsatisfactory for correction or opportunities for improvement actions.

3.3. Artifact Samples

Due to space limitation, we illustrate the utilization of SDM-BPoSS reporting only some diagrams generated by using this methodology in a demo real-alike case. It is about a Process Credit Card, which is reported in the BPMS ProcessMaker open source tool. SDM-BPoSS was used for documenting such an already computational demo, and augmented in several steps. This case of reverse engineering illustrates the SDM-BPoSS potential for improving the understanding of key stakeholders: users and developers.

Fig. 3 (a) Artifact Request Stakeholders (b) Artifact Project Specification.

Fig. 4 (a) Artifact Commitment Letter (b) Artifact Roles and Responsibilities


Fig. 5 Artifact Business Process Diagram (A)

Fig. 6 Part of Artifact Business Process Diagram (B - Flow complementary Interfaces)


4. Discussion and Conclusions

The reported sample of artifacts is part of a demo real-alike case implemented for empirical evaluation of SDM-BPoSS. As it was reported in [13], despite the variety of current methodological proposals for developing BPoSS, we found that some approaches are proprietary and that small and medium sized companies can not afford them. Moreover, proprietary approaches are not available for academy and general public. Other approaches are open source (e.g. free access) but are focused on particular phases and activities and do not provide a well-defined full development processes. It would be unrealistic to claim we have provided the silver bullet methodology for BPoSS. However, we believe that our approach provides useful insights to get progress towards an accepted standard methodology by BPM global academic and practitioner community. This lack of a well-structured methodology for BPoSS, together with the false belief that the development BPM tool will provide it, is avoiding the suitable deployment of these IT technologies in small and medium sized companies. Whereas that BPM tools implicitly endorse a basic development process, similar as other development technologies, a well-structured development process is required for a suitable practice of Software Engineering. Thus, we discourage the omission using a development methodology even for very small or small projects (e.g. with a duration between 2-4 weeks). This wrong practice is followed by the fact that BPM tools are usually utilized for academic demo purposes, and consequently is erroneously inferred that this kind of software system projects will not require of a well-defined development methodology.

The proposed SDM-BPoSS has been constructed from the best practices reported in the current BPM literature. The design of our approach has pursued as one of the main goals to count with a well-structured methodology which is both agile and rigorous. Rigor is achieved by including the main four phases and eleven activities identified in the state of the art of BPM methodologies in SDM-BPoSS. Agility is achieved through the reduction of the initial set of phases, activities, artifacts, roles and techniques identified in such best practices. In particular, SDM-BPoSS considers Web Services (e.g. local and remote web services) as the main technology for developing these systems. However, SDM-BPoSS can model systems, which either do not use web services or barely use web services.

Hence, we consider that further researchers can follow this research path for enhancing and empirically testing SDM-BPoSS with the final purpose to obtain a standardized SDM for BPoSS in the mid-term. We consider it imperative to encourage the community toward such a goal. Until such a standardization process is not achieved, all of the benefits potentially provided by BPM tools (in particular from open source tools) will not be fully exploited by small and medium sized companies.

Acknowledgements

Lead author thanks to IDSCEA and Autonomous University of Aguascalientes for their support to carry out this research.

References

[1] Allen, P., 2006, Service Orientation: Winning Strategies and Best Practices. New York: Cambridge University Press. [2] Berrocal, J., García, J. & Murillo, J., 2007, “Hacia una gestión del proceso de software dirigida por Procesos de Negocio”,

Conference Proceeding, JISBD: I Taller sobre Procesos de Negocio E Ingeniería del Software (PNIS´07), September, Zaragoza, España.

[3] Aalst, W. M. P., 2009, “Process-Aware Information Systems: Design, Enactment and Analysis”, Wiley Encyclopedia of Computer Science and Engineering, John Wiley & Sons, pp. 2221-2233.

[4] Reijers, H.A., 2006, “Implementing BPM systems: the role of process orientation”, Business Process Management Journal, vol. 12(4), 389-409.


[5] Fernandes, J.M., & Duarte, F.J., 2005, “A reference model for process-oriented software development organizations”, Software and Systems Modeling (SoSyM), Springer Verlag, vol. 4(1), 94-105.

[6] Khoshafian, S., 2007, BPM Inteligente para Empresas Orientadas al Servicio, FinancialTech Magazine, February. [7] Aalst, W. M. P., Netjes, M. & Reijers, H.A., 2007, “Supporting the Full BPM Life Cycle using Process MIning and Intelligent

Redesign”, In Contemporary Isues in Database Design and Information Systems Development, vol. (4), IGI Global, Hershey, USA, 100-132.

[8] Bell, M., 2008, Serviced-Oriented Modeling:SErvice Analysis, Design and Architecture, John Wiley & Sons, New Jersey. [9] White, S., 2004, “Introduction to BPMN”, IBM Corporation. [10] Ko, R., Lee, S. & Lee, E., 2009, "Business process management (BPM) standards: a survey", Business Process Management Journal,

vol. 15(5), 744 – 791. [11] Wolf, C. & Harmon, P., 2010, The State of Business Process Management 2010, BPTrends, February, USA. [12] BPTrends, 2007, A Detailed Analysis of Enterprise Architecture, Process Modeling, and Simulation Tools, Business Process. [13] Mondragón, M. & Mora, M., 2012, Un Análisis Comparativo de Metodologías de Ciclo de Vida de Desarrollo de Software que

involucran Procesos de Negocio y Servicios Web, Actas de la 7ª Conferencia Ibérica de Sistemas y Tecnologías de Información, Vol. I, AISTI - UPM, ISBN: 978-989-96247-6-4, Madrid, España, 759-764.

[14] Payne, J., 2008, BPM y la Metodología de la Bola de Cristal: Fallos en los métodos actuales para planificar e implementar un Sistema BPM, Banca y Finanzas: Revista Profesional de Gestión Financiera, 133, January, 52-53.

[15] Recker, J. & Indulska, M., 2009, Business Process Modeling- A Comparative Analysis. Journal of the Association for Information Systems JAIS, Vol. 10 (4), 333-363.

[16] Avison, D., 2003, “Where Now for Development Methodologies?”, Communications of the ACM , vol. 46 (1), pp.78-82. [17] Fuggetta, A., 2000, Software Process: a Roadmap. The Future of Software Enginnering, Ireland: ACM Press, pp. 25-34. [18] Mutschler, B., Reichert, M. & Bumiller, J., 2008, “Unleashing the Effectiveness of Process-Oriented Information Systems: Problem

Analysis, Critical Success Factors, and Implications, Systems, Man, and Cybernetics, Part C: Applications and Reviews”, IEEE Transactions on, vol.38 (3), May, 280 – 291.

[19] Rodríguez, C., 2009, Diseño de un Modelo de Proceso de Ciclo de Vida de Sistemas de Software, en el Paradigma de Ingeniería de Software Orientada a Servicios. Tesis Doctoral, UAA, December, Aguascalientes, México.

[20] Hevner, A. R., March, S. T., Park, J., & Ram, S., 2004. Design science in information systems research. MIS quarterly, 28(1), 75-105. [21] Kühne, S., Thränert, M. & Andreas, S., 2005, “Towards a methodology for orchestration and validation of cooperative e-business

components”, 7th GPCE Young Researcher Workshop , Rutherford, 29-34. [22] Delgado, A., 2007, “Desarrollo de Software con enfoque en el Negocio”, Conference Proceeding JISBD: I Taller sobre Procesos de

Negocio e Ingeniería del Software (PNIS’07), September, Zaragoza, España. [23] Oktaba, H. & Ibarguengoitia, 1998, G., “Software Process Modeled with Objects:Static View”, Computación y Sistemas, vol. 1 (4),

228-238. [24] Papazoglou, M. P., & Van Den Heuvel, W. J. , 2007. Business process development life cycle methodology. Communications of the

ACM, 50(10), 79-85. [25] Stemberger, M. I., Kovacic, A., & Jaklic, J., 2007. A methodology for increasing business process maturity in public sector.

Interdisciplinary Journal of Information, Knowledge, and Management, 2, 119-133. [26] Karastoyanova, D. ,2004. A methodology for development of web service-based business processes. Proceedings of AWESOS. [27] M. Chinosi, 2008, Representing Business Processes: Conceptual Model and Design Methodology, Thesis Doctoral, Università degli

studi dell'Insubria, Italia. [28] Desai, N., Chopra, A. K., & Singh, M. P., 2009. Amoeba: A methodology for modeling and evolving cross-organizational business

processes. ACM Transactions on Software Engineering and Methodology (TOSEM), 19(2), 6. [29] Sánchez, M.A, Hermoso, A. & Joyanes, L., 2007, ” Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a

partir de procesos del negocio en un contexto de Negocio Bajo Demanda”. Presentado en PNIS 2007: Primer Taller sobre Procesos de Negocio e Ingeniería del Software, Zaragoza, Septiembre, 64-71.

[30] Kruchten, P., 2000, The Rational Unified Process An Introduction, Second Edition, Addison Wesley.

toward a well-structured development methodology for business process-oriented software systems...

Documents