A Framework for Process Driven Software Configuration Andreas Daniel Sinnhofer1, Peter Puhringer,¨ Klaus Potzmader2, Clemens Orthacker2, Christian Steger1 and Christian Kreiner1 1Institute of Technical Informatics, Graz University of Technology, Graz, Austria 2NXP Semiconductors, Gratkorn, Austria a.sinnhofer, christian.kreiner, steger @tugraz.at, [email protected], klaus.potzmader, clemens.orthacker @nxp.com { } { } Keywords: Software Product Lines, Feature Oriented Modelling, Business Processes, Tool Configuration. Abstract: Business processes have proven to be essential for organisations to be highly flexible and competitive in today’s markets. However, good process management is not enough to survive in a market if the according IT landscape is not aligned to the business processes. Especially industries focused on software products are facing big problems if the according processes are not aligned to the overall software system architecture. Often, a lot of development resources are spent for features which are never addressed by any business goals, leading to unnecessary development costs. In this paper, a framework for a business process driven software product line configuration will be presented, to provide a systematic way to configure software toolchains. 1 INTRODUCTION ularly for resource constraint devices like embedded systems, it is vital to have a working software configu- Business Process (BP) oriented organisations are ration process since unnecessary features may occupy known to perform better regarding highly flexible a lot of memory. Further, it is important to have a demands of the market and fast production cycles software architecture which is synchronised with the (e.g. McCormack and Johnson (2000); Valena et al. business goals. Otherwise, a lot of resources are spent (2013); Willaert et al. (2007)). This is achieved for developing and maintaining software components through the introduction of a management process, which are never used anyway. Thus, process aware- where business processes are modelled, analysed and ness is crucial for an efficient development. optimised in iterative ways. Nowadays, business pro- Context Aware Business Process modelling is a cess management is also coupled with a workflow technique for businesses living in a complex and management, providing the ability to integrate the re- dynamic environment (Saidani and Nurcan (2007)). sponsible participants into the process and to moni- In such an environment a company needs to tackle tor the correct execution of it in each process step. changing requirements which are dependent on the To administer the rising requirements, so called busi- context of the system. Such context sensitive busi- ness process management tools are used (BPM-Tools) ness process models are able to adapt the execution of which cover process modelling, optimization and exe- their process instances according to the needs, such cution. In combination with an Enterprise-Resource- that the company can react faster and more flexible. Planning (ERP) system, the data of the real process This is achieved by analysing the context states of can be integrated into the management process. the environment and mapping these states to the ac- In the domain of software products, different cording business processes and their related software choices in business processes lead to different soft- system. The problem with such approaches is, that ware configurations. To handle variability automat- the used software systems are often developed in- ically is a challenging task because the variability of dependently from each other, although they share a the process model needs to be reflected in the software similar software architecture. Therefore, this work architecture. Further, the actual customer choice dur- focuses on the development of a framework which ing the ordering process needs to be mapped to the ac- covers the variability of process models and mapping cording software features. Due to this, software con- such variable process structures to software configu- figuration is often done manually which takes a con- ration artefacts such that the software system can be siderable amount of time during production. Partic- adapted automatically with respect to its context. This 196 Daniel Sinnhofer A., PÃijhringer P., Potzmader K., Orthacker C., Steger C. and Kreiner C. A Framework for Process Driven Software Configuration. DOI: 10.5220/0006223701960203 In Proceedings of the Sixth International Symposium on Business Modeling and Software Design (BMSD 2016), pages 196-203 ISBN: 978-989-758-190-8 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved A Framework for Process Driven Software Configuration BPM-Tool SPLE-Tool No Business Derive / Feature Model Yes Processes Update Quotation Approve Order Approved? Payment Handling Order Handling Process Designer Evolution / Feature Selection Customer No Procure In House? ... Maintenance Requirements Contractors Production Experts Derive Process Variant Transformation Update Yes Schedule / ... assign work Sub-Process: Order Handling Production Experts Figure 1: Exemplary order process to illustrate the basic Figure 2: Used framework for an automatic business pro- concepts defined by Osterle¨ (1995): A high level descrip- cess variant generation (adapted from Sinnhofer et al. tion of the process is split into its sub-processes until a com- (2015)). The grey lines indicate process steps which need plete work description is reached. to be done manually. is achieved through software product line engineering cording to Osterle¨ (1995) the process design on a techniques. Thus, only one system needs to be devel- macroscopic level (high degree of abstraction) is split oped and maintained for whole product families. The up into sub-processes until the microscopic level is modelling of business process variability is based on reached. This is achieved, when all tasks are detailed our previous work, which can be found in Sinnhofer enough, so that they can be used as work instructions. et al. (2015). In particular, a SPLE Tool was used An exemplary order process is illustrated in Figure 1. to systematically reuse expert knowledge in form of As illustrated, the top layer is a highly abstracted de- valid process variations, designed in an appropriated scription, while the production steps are further re- BPM Tool. The integrity of the process variations is fined on the lower levels. As a result, the lowest secured by the capabilities of the BPM Tool and a level is highly dependable on the concrete product and rich cross functional constraint checking in the SPLE production environment, providing many details for Tool. This work will extend the framework in order to the employees. Usually, the top layers are indepen- be able to map process artefacts to software configu- dent from the concrete plant and the supply chain and rations. Hence, software toolchains can be configured could be interchanged throughout production plants. in an automatic way and the architecture can be kept Only the lower levels (the refinements) would need to aligned with the business goals. be reconsidered. Variability of such a process struc- This work is structured in the following way: ture can either be expressed through a variable struc- Section 2 gives an overview over the used design ture of a process/sub-process (e.g. adding/removing paradigm for business processes modelling and Soft- nodes in a sequence) or by replacing the process re- ware Product Line Engineering techniques which finement with different processes. were needed for the framework. Section 3 summa- Traditionally, processes for similar products are rizes the concept of our work and Section 4 describes created using a copy and clone strategy. As a result, our implementation in an industrial use case. Finally, maintaining such similar processes is a time consum- Section 5 summarizes the related work and Section 6 ing task, since every improvement needs to be propa- concludes this work and gives an overview over future gated manually to the respective processes. To solve work. this issue, we proposed a framework to automatically derive process variants from business process mod- els by modelling the variable parts of a process us- 2 BACKGROUND ing Software Product Line Engineering techniques in a previous work (see Sinnhofer et al. (2015)). The presented framework can be split into four different 2.1 Business Processes phases which are illustrated in Figure 2. In the first phase, process designers create process templates in a A business process can be seen as a sequence of BPM tool, adding all wished features like documen- tasks/sub-processes which need to be executed in a tation artefacts, responsible workers or resources. In specific way to produce a specific output with value the second phase, the created processes are imported to the costumer (Hammer and Champy (1993)). Ac- into the SPLE tool and added to a feature model. Pro- 197 Sixth International Symposium on Business Modeling and Software Design car Process Process Variability Model Framework Engine Type Gear Type Entertainment System Domain Experts Maintenance Evolve generated Order Entry Process Variant Execute Process Electrical Gas Diesel Automatic Manual Radio CD-Player (e.g. Web-Interface) configures Figure 3: An exemplary feature model of a car. Customer configures cess experts define a comprehensive set of rules and influences restrictions so that only valid process variants can be derived from the model. The