company. The activities of this phase are: (i) Selection of Activities, responsible ... design of application screens, one iOS developer and one android developer ...
AGILE PDD - ONE APPROACH TO SOFTWARE DEVELOPMENT USING BPMN Adriana Herden UTFPR – Universidade Tecnológica Federal do Paraná – Departamento de Informática Avenida Sete de Setembro, 3165, Rebouças, CEP 80230-901, Curitiba – PR, Brasil
Adriano Bessa Albuquerque, Pedro Porfirio M. Farias, Paulo Roberto Martins de Andrade UNIFOR – Universidade de Fortaleza – Programa de Pós-Graduação em Informática Aplicada Avenida Washington Soares, 1321, Edson Queiroz, CEP 60811-905, Fortaleza – CE, Brasil
ABSTRACT The standardization of BPMN v2 gave opportunity to the emergence of tools for modeling and execution of business processes that enable rapid prototyping of applications. This paper proposes an agile development methodology driven by processes that use this facility to refine and validate executable prototypes produced during the software development. Also is presented a case study the methodology proposed. The results show reduction in development time and number of errors. KEYWORDS agile; process; project; development; bpmn.
1. INTRODUCTION The standardization of BPMN (Business Process Management Notation), in particular the version 2, by the OMG (Object Management Group) introduced an inflection point in the approaches that deal with the representation and manipulation of business processes. Business processes typically involve the cooperation of many employees whose activities must be performed to achieve a task, and may involve the record of information in many enterprise systems. According to Sommerville (2011) a workflow is a model of the business process and these are represented in the UML activity diagrams or BPMN. In addition, BPMN is being widely used to represent high-level processes responsible for the integration of applications in the context of SOA (Service Oriented Architecture). A large number of tools adopt the new standard enabling the use of a graphical interface to design processes, also to associate activities to data, services and other existing processes as well as generate executable prototypes from the specification. According to van der Aalst (2013) Business Process Management (BPM) is defined as "a supporting to business processes using methods, techniques and software to design, perform, monitor and analyze operational processes involving human beings, organizations, applications, documents and other sources of information." And Business Process Management System (BPMS) is a "generic system of software that is driven by explicit process designs in order to execute and to manage operational business processes." The possibility of quickly generate executable prototypes from the graphical representation of business processes opens the possibility of using BPMN in the context of agile systems development, especially workflow systems. The graphical representation facilitates the understanding of the business process for users and prototypes allow a palpable experience of using the system that facilitates the validation. This article explores these possibilities proposing a development methodology called Agile Process Driven Development (Agile PDD). According to Tran, Zdun and Dustdar (2011) Process Driven Development provides a suitable mapping between design and implementation processes.
The remainder of the paper is organized as follows: section 2 describes research relating BPMN and UML; Section 3 shows some methods of development services with BPM; section 4 the model of the process Agile PDD; Section 5 shows the use of the methodology and the results achieved; Section 6 outlines some conclusions and future work.
2. RELATED WORK Baresi et. al. (1999) proposes a methodology for developing workflow that enhances the flexible representation of exceptions, workflow interaction with external applications and prototyping of workflow systems. This approach is based on UML modeling as use case diagrams, class and sequence. There are other works that study the relationship between the elements of UML and BPMN notation elements in the context of systems development. Peixoto et. al. (2008) proposes an evaluation of modeling languages for business processes (UML 2 and BPMN), from the perspective of readability of the models from the perspective of end users. The evaluation showed that these two languages have no significant differences to its users. Already, Macek and Richta (2009) believe that the transformation of BPMN diagrams to activity diagrams in UML is required for the development of systems because UML has better support in modeling tools and are easier to read from end users. To Lübke, Schneider and Weidlich (2008), the extent to which the use cases increases it becomes more complex to get an overview of the system and understand the dependencies and the order of execution of the use cases. So, these authors suggest an approach for generating graphical models of business process in BPMN as a means of restoring overview of the use cases, and sort them according to their pre and post conditions. In Hernadez et. al. (2010) proposed a process-oriented business called "use processes", in which the requirements are obtained from elements of BPMN and UML activity diagram approach. The approach was implemented in three case studies, and the results showed that it was possible for users who are heavily involved with projects, identify and correct problems in their own business processes from the moment they were described. Kaloyanova and Napoli (2011) describe an integrated system with the aim of supporting the inclusion of SOA, BPM and EA (Enterprise Architecture) within the RUP (Rational Unified Process) framework. In the authors' view the process of software development depends on more flexible business models, requiring the use of technologies such as SOA and BPM to support the changes and integrate services. Among the new activities include: “Identify Business Processes” and “Exploring Process Automation” at the design stage. The results showed that these methodologies have complementary aspects, and if used in an integrated manner offer real benefits to developing systems.
2.1 BPMN and SOA Ramollari, Dranidis and Simons (2007) developed a survey of methodologies for developing serviceoriented, in which features were identified before comparing with existing approaches. Among the methodologies studied the authors cite BPMN to BPEL (Business Process Execution Language) as an approach for expressing business processes in an abstract model, which is automatically mapped to BPEL description language being implemented by a machine process. The authors also believe that agile methods like XP (Extreme Programming) are successfully employed in SOA projects. Patricia et. al. (2011) proposes a model for the interaction between the activities of business processes and the functionality provided by service. Use BPMN for process modeling, level of granularity for modeling services, and the identification and specification requirements are process oriented. Such an approach provides interaction between steps of process modeling and service modeling, and was based on characteristics of frameworks SOAF and MINERVA. Delgado et. al. (2011) uses the OMG SoaML standard, for generation service from the steps defined by the methodology called BPSOM. This allies are the concepts of BPM, SOA and prototyping in a sequence of steps based on the structure of RUP. Munehira (2011) believes that there is a gap between actual and implemented business systems, which can be solved by a method of developing BPM combined with SOA. In this method the services are
registered in a repository of services and classified into three categories, which are: process services, business services and basic services.
2.2 SCRUM For Cohn (2011), the software development with Scrum brings benefits to stakeholders, that have more visibility of the project; as for developers that manage better their daily activities. Furthermore, agile teams develop higher quality products and the time to market is faster than in traditional teams. Cohn (2011) believes that agile development has been misinterpreted in the past as opposed to the documentation. Currently, it is clear that agile methodologies aim to find balance between documentation and discussion. Thus, the author suggests begin the development without a complete specification document, and create user stories to compose the product backlog, which is a list of all the desired features.
3. AGILE PROCESS DRIVEN DEVELOPMENT The Agile PDD process is characterized by the philosophy of agile methods, in addition to adopting the concepts of BPM and SOA in its life cycle. The roles in Agile PDD are business analysts, systems analysts and programmers. Its main stages are: Scope Definition, Prototyping System, Production Sprint, Implementation, Monitoring and Optimization. We chose to represent the Agile PDD in BPMN, and this representation phases and their explanations are shown as processes and sub-processes. Figure 1 shows the overview of the process.
Figure 1. Agile PDD
3.1 Scope Definition In the first phase, the “Scope Definition”, there are two activities to be performed, which are: (i) Definition of Scope and Vision, responsible for defining the scope of the product and the work to be performed, in which the vision document is generated; (ii) Definition of Use Cases, responsible for defining the use cases to be used during the process, in which the use case diagram is created. Figure 2 shows the interaction between the activities of this phase.
Figure 2. Scope Definition Subprocess
3.2 Prototyping System
After knowing the use cases, begins the phase “Prototyping of System”, which aims to present the user with an early executable code that allows them to see the operation of the system under development. Fig. 3 shows the dynamics of the activities of this phase. The activities are: ( i ) Details of Use Case using BPMN , responsible for specifying the flow of activities that comprise the scenarios of use cases through processes represented in BPMN notation. It is considered that at this stage the developer uses a BPMS tool; ( ii ) Definition of data, responsible for identifying the data that will transact within the process . These data can be internal to an activity, or may have global scope carrying information from one activity to another; ( iii ) Definition of Screens, responsible for defining elements and layout of screens for each activity of the BPMN diagram that require user interaction. Its specification takes into account the document of vision, use cases and data of the process; ( iv ) Generation of Prototypes, responsible for the creation of prototypes , generated by a BPMS tool from BPMN diagram; ( v) Validation with the User, responsible for confirming of the users in relation to their expectations, based on prototypes presented. The activities of phase Prototyping of System are performed by business analysts in collaboration with users.
Figure 3. Prototyping System Subprocess
3.3 Production Sprint The phase of “Production Sprint” is also iterative and incremental as commonly used in agile methodologies. Figure 4 shows the interaction of the activities of this phase.
Figure 4. Production Sprint Subprocess
3.4 Integration with Existing Processes and Data The task of the Data and Integration with Existing Processes is shown in Figure 5, where you can view the execution of activities in parallel. The activities of this phase are: (i) Integration with External Services, responsible for identifying external to system services and their integration with the existing system; (ii) Integration with Other Processes, responsible for identifying other processes of the organization that will be used and will have interaction with the current process; (iii) Definition and Integration Data Model, responsible for the creation of data models; (iv) Integration Testing, responsible for testing the integrations with respect to the operation, availability, and integrity.
Figure 5. Integration with Existing Processes and Data Subprocess
3.5 Automation of Activities The task of Automation Activities, presented in Figure 6 shows a typical iterative cycle based on the agile sprints. The number of sprints depends on the level of maturity of business processes modeled in the company. The activities of this phase are: (i) Selection of Activities, responsible for the selection of activities to be automated in the sprint; (ii) Coding, responsible for coding the selected activities; (iii) Test, responsible for each activity tests, while not valid is possible to return to the activity coding; (iv) Generation of Prototypes, responsible for verifying the completion of Sprint and generate functional prototypes; (v) Validation with the User, responsible for validating the user. If not validated, the activities encoded back to the backlog to be encoded again.
Figure 6. Automation of Activities Subprocess
Then the implementation of the system and its monitoring on the functioning and stability is made. Monitoring is a typical activity of workflow systems that can trigger notifications and corrective actions when events or when exceeded limits for the execution time of activities. Finally, the optimization phase has the idea of continuous improvement process or system, causing the evolution of the process is provided in its life cycle.
3.6 Contribution of Agile Methods
The Agile PDD, such as agile methods, prioritizes the generation of executable code from the initial stages of development. Although it will be refactored, since the beginning of development, executable versions of software that are shown and validated by the customer are produced. Is also advocated closer ties between customers and developers and is valued informal communication. Business processes modeled in BPMN are designed for business analysts, who are sometimes the clients themselves. The customers can specify their own business processes without requiring technical knowledge. BPMS tools to generate prototypes in early stages, to validate the system design are used. During the construction phase of the Agile PDD, which can be integrated with existing systems (legacy), there is a cycle that is analogous to sprints automation. As occurs in agile methods, user participation in the validation of each sprint occurs.
4. CASE STUDY To show the efficiency of the process as well as the ease it offers to those involved, the methodology Agile PDD was applied in the development of version 2.0 of the application for mobile device that belongs to a government organization called Cagece. Scope, processes and results are described the following.
4.1 Project definition and scope The object of study is a mobile application available for smartphones and tablets that use Android or iOS, developed by the Water and Sewage Company of Ceará (Cagece) a public sector company which provides basic sanitation services. The initial idea for the app called "Cagece App" was helping people to report problems related to water leaks, sewer, fraud in the use of water resources and holes. The application operation is simple: The user accesses the application, it beats a photo of the problem report, the application captures its exact location, he confirms the address the address captured by GPS and then sends its occurrence to Cagece. Arriving in Cagece, this occurrence is analyzed and treated pro an analyst who will validate the data and make a call from repaired to a local drive. Meanwhile, the client receives all the monitoring of their occurrence, execution and completion status via the app. The application also has the administrative part developed in scope, which is a module of the company's trading system. Other features of the application include textual information, such as FAQs, news, service nearest shops, contacts and forms of sustainability tips. The first version of the application was released in August 2013 and had all the development of the project carried out in eight months. The first version with all your planning and project execution performed using the methodology as a guide of best practices for project management, PMBOK, in its fourth edition. We used 34 of the 42 cases contained in the guide. Just when it launched the first version, the company has already started to think in the new ideas and features for the application. It was decided that the new version of the application would have a new look, changing completely. It would be also changed the way that information is sent to the trading system, where before they were sent as XML, would now be sent as JSON and authentication. Were even thought the user functionality to have a single login to use either the application, as the web portal services, being necessary to perform the integration of information. It would be even added the application to "My Account" feature, where the user could access their records, request services, check duplicate account and make payments. Would be even more added textual information to the user, as the list of offered services and price list. Would still need to update module of the commercial system to support application development. The team to implement the project of the second version of the application is the same team that did the first version. The team consists of two front-end developers, one java developer working in the commercial system module, one java developer working on developing web-services, one web-designer working on the design of application screens, one iOS developer and one android developer to work on adapting the coding in HTML 5 for each platform, two business analysts to design the flow of each process of the application and five suppliers of requirements divided into different areas, totaling 14 people involved in the project. The design of the new version of the application was created the same way as the first version, using a methodology based on PMBOK and had an estimated completion period of six months.
4.2 Project Execution and results After training the team on the new methodology, was made a new project planning. Once finalized, the total time of the project declined to 4 months. The people who make up the team of project development, already has experience of at least two years each in their area of expertise. These people were chosen precisely to eliminate factor of learning. It is taken into account also the recreation of the methods of application and the re-design, not in the case of a repetition. This happened due to parallel execution of development, test and validation activities, avoiding sequential tasks. Weekly Sprints, where activities were avidly and tested as soon as they were completed, making with that nonconformities were detected immediately and avoid rework were created. In numbers, this means that the reduction of time to develop the project fell by 33%, and the number of errors found for the use case "Register Occurrence" was 9 errors, against 15 in the previous version, showing a decrease 40%. In total, there were some benefits found during the project, Some data are shown in Table 1. Table 1. Project execution data Evaluated subject Errors and failures Time required per use case Idle time between use cases Use cases
Version 1 35 16 days 0,8 days 18
Version 2 26 12 days 0,3 days 21
Variation - 26% - 25% - 63% + 17%
After finishing the project, a survey was carried out among staff, IT manager, and the business area (in the role of client) to evaluate the methodology used, totaling 26 people. With the research, four criteria were raised: Productivity (time spent on documentation, and development meetings, checks whether there was an improvement), Transparency (if the development process is accompanied by the client in a simple and clear way to know what was done and what is missing), facility (how is not difficult or application and the use of the methodology) and interaction (ease and opportunity of interaction between the customer and the development team). The data obtained in the research can be seen in Table 2. Table 2. Evaluation of the use of the methodology for staff Item Reviewed Productivity Transparency Facility Interaction
Great 62,5% 50,0% 62,5% 37,5%
Regular 37,5% 37,5% 25,0% 62,5%
Poor 0,0% 12,5% 12,5% 0,0%
An interesting point is that, from the outside, the customers thought that the process could be more streamlined to expedite further development, but seen from point of view of developers, the team agreed that it was a big gain compared to the previous methodology. In the previous method does not perform the alignment between BPM and life cycle of software.
5. CONCLUSION The "Agile PDD" has the contribution, define an agile process that uses BPMN to generate prototypes from the early stages of development, facilitating the validation of the software by the customer. Follows the approach of agile methods that prioritize produce executable artifacts rather than textual descriptions that increase the time required for system development. Furthermore, the graphical representation of BPMN, used to specify the flow of tasks and service orchestration, gives scope for users to play the role of business analysts. As future work the use of the proposed experiments to validate all stages of PDD Agile process will be conducted.
ACKNOWLEDGEMENT This work has the support of the University of Fortaleza and the University Federal Technological of Paraná.
REFERENCES [1]
BARESI, L. et. al. (1999) “WIDE Workflow Development Methodology” In: WACC '99 Proceedings of the international joint conference on Work activities coordination and collaboration, New York, USA.
[2] [3]
COHN, M. (2011) “Desenvolvimento de Software com Scrum”. Porto Alegre: Bookman.
[4]
[5]
[6] [7]
[8]
[9]
[10] [11]
DELGADO, A. et. al. (2011) “Business Process Service Oriented Methodology (BPSOM) With Service Generation In Soaml”. In: Advanced Information Systems Engineering (pp. 672-680). Springer Berlin Heidelberg. HERDEN, A.; FARIAS, P.P.M; ALBUQUERQUE, A. B. (2013) “An Approach Based on BPMN to Detail Use Cases”. In: International Joint Conferences on Computer, Information and Systems Sciences and Engineering (CISSE 13), USA, ISBN 9789048136575. HERNADEZ, U. I. et .al. (2010) “Use Processes – Modeling Requirements Based on Elements of BPMN and UML Use Case Diagrams”. In: 2nd International Conference on Software Technology and Engineering (ICSTE), Puerto Rico, USA. LÜBKE, D.; SCHNEIDER, K.; WEIDLICH, M. (2008) “Visualizing Use Case Sets as BPMN Processes”. In: REV '08 Proceedings of the 2008 Requirements Engineering Visualization, Washington, USA. MACEK, O.; RICHTA, K. (2009) “The BPM to UML Activity Diagram Transformation using XSLT”. In: Proceedings of the Dateso 2009 Annual International Workshop on Databases, Texts, Specifications and Objects, SpindleruvMlyn, Czech Republic. MUNEHIRA, T. (2011) “A Study on a Generic Development Process for the BPM+SOA Design and Implementation”. In: World Academy of Science, Engineering and Technology. Available em: http://www.waset.org/journals/waset/v59/v59-434.pdf. NAPOLI, J. P.; KALOYANOVA, K. (2011) “An Integrated Approach for RUP, EA, SOA and BPM Implementation” In: CompSysTech '11-12th International Conference on Computer Systems and Technologies, Vienna, Austria. PATRICIA, B. et.al. (2011) “Process-Service Interactions using a SOA BPM based Methodology”. In: 30th International Conference of the Chilean Computer Science Society (SCCC), Curico, Chile. PEIXOTO, D. et.al.(2008) “A Comparison of BPMN and UML2.0 Activity Diagram”.In: VII Simpósio Brasileiro de Qualidade de Software VII SBQS 2018. Florianópolis, Santa Catarina.
[12] RAMOLLARI, E.; DRANIDIS, D.; SIMONS, A. J. H. (2007) “A Survey of Service Oriented Development Methodologies”. In: 2nd European Young Researchers Workshop on Service Oriented Computing, Oadby, England. http://www.cs.le.ac.uk/events/yrsoc2007. [13] SOMMERVILLE, I. (2011) “Engenharia de Software”, 9.e.d. São Paulo: Pearson Prentice Hall. [14] TRAN H.; ZDUN,U.; DUSTDAR, S. “VbTrace: using view-based and model-driven development to support traceability in process-driven SOAs”. Software & Systems Modeling, Springer-Verlag. http://dx.doi.org/10.1007/s10270-009-0137-0, 2011.
[15] VAN DER AALST, W. M. P., “Business Process Management: A Comprehensive Survey”. SNRI Software Engineering, vol. 2013; doi: 10.1155/2013/507984, 2013.
