Business modeling and software design

LNBIP 319 Boris Shishkov (Ed.) Business Modeling and Software Design 8th International Symposium, BMSD 2018 Vienna, Austria, July 2–4, 2018 Proceedings 123 Lecture Notes in Business Information Processing Series Editors Wil M P van der Aalst RWTH Aachen University, Aachen, Germany John Mylopoulos University of Trento, Trento, Italy Michael Rosemann Queensland University of Technology, Brisbane, QLD, Australia Michael J Shaw University of Illinois, Urbana-Champaign, IL, USA Clemens Szyperski Microsoft Research, Redmond, WA, USA 319 More information about this series at http://www.springer.com/series/7911 Boris Shishkov (Ed.) Business Modeling and Software Design 8th International Symposium, BMSD 2018 Vienna, Austria, July 2–4, 2018 Proceedings 123 Editor Boris Shishkov Bulgarian Academy of Sciences, Institute of Mathematics and Informatics (IMI)/ Interdisciplinary Institute for Collaboration and Research on Enterprise Systems and Technology (IICREST) Sofia Bulgaria ISSN 1865-1348 ISSN 1865-1356 (electronic) Lecture Notes in Business Information Processing ISBN 978-3-319-94213-1 ISBN 978-3-319-94214-8 (eBook) https://doi.org/10.1007/978-3-319-94214-8 Library of Congress Control Number: 2018947352 © Springer International Publishing AG, part of Springer Nature 2018 This work is subject to copyright All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed The use of general descriptive names, registered names, trademarks, service marks, etc in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations Printed on acid-free paper This Springer imprint is published by the registered company Springer International Publishing AG part of Springer Nature The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland Preface How did enterprises look in the 1970s (when essential technology-driven business transformations started)? What were the rudimentary business process automations at that time and how is this different from the current business process automations that go beyond conventional data manipulation and record-keeping activities? How did enterprises exchange information then, not counting on the global telecommunications and the digital multimedia and what are the differences now when a cellphone alone seems to be capable of supporting video communication, answering complex questions, and providing satellite navigation? Were associations between different enterprises possible (without Web services and cloud infrastructures) to combine manufacturing, assembly, wholesale distribution, and retail sales in what is currently called business process externalization? Were software technologists then able to develop truly adaptable information systems, not counting on sensor technology? We argue that answering these questions would bring us to the conclusion that over the past several decades enterprises have been shifting to experience a growing dependency on ICT – information and communication technology For this reason, it is not surprising that software engineering is becoming increasingly relevant with regard to enterprise developments Hence, even though enterprise engineering and software engineering have developed separately as disciplines, it is currently important to bring together enterprise modeling and software specification; we argue that this would allow enterprises to adequately utilize current technology This is especially valid for the latest technological “booms”: (a) blockchain technology; (b) Internet of Things The former (a) is about rethinking the way inter-organizational business processes are managed, assuming a high degree of security: In fact, once a transaction is certified and saved within one of the chain blocks, it can no longer be modified or tampered with (each block consists of a pointer that connects it to the previous block, a timestamp that certifies the time at which the event actually took place, and the transaction data); hence there is no central party serving as a single point of trust and failure Therefore, the actual blockchain technology developments concern both enterprise (business-processes-related) issues and technical (software-engineering-related) issues The latter (b) is about bringing together human actions, technical applications, networked devices, sensors, actuators, and so on, for the sake of providing a real-time (sensors-driven) “tuning” of what people and devices are doing Therefore, further Internet of Things developments concern (among other things) the demand for better aligning the pieces of software running on numerous devices to the overall business processes that are related not only to those devices but also to humans, institutions, regulations, and so on Thus, bringing together business (enterprise) modeling and technical (software) design is crucial BMSD (http://www.is-bmsd.org) is an annual international symposium that brings together researchers and practitioners who are inspired to consider that challenge VI Preface Since 2011, we have enjoyed seven successful BMSD editions The first BMSD edition (2011) took place in Sofia, Bulgaria, and the theme was: “Business Models and Advanced Software Systems.” The second BMSD edition (2012) took place in Geneva, Switzerland, with the theme: “From Business Modeling to Service-Oriented Solutions.” The third BMSD edition (2013) took place in Noordwijkerhout, The Netherlands, and the theme was: “Enterprise Engineering and Software Generation.” The fourth BMSD edition (2014) took place in Luxembourg, Grand Duchy of Luxembourg, and the theme was: “Generic Business Modeling Patterns and Software Re-Use.” The fifth BMSD edition (2015) took place in Milan, Italy, with the theme: “Towards Adaptable Information Systems.” The sixth BMSD edition (2016) took place in Rhodes, Greece, and had as theme: “Integrating Data Analytics in Enterprise Modeling and Software Development.” The seventh BMSD edition (2017) took place in Barcelona, Spain, and the theme was: “Modeling Viewpoints and Overall Consistency.” The 2018 edition in Vienna marks the eighth event, with the theme: “Enterprise Engineering and Software Engineering - Processes and Systems for the Future.” We are proud to have attracted distinguished guests as keynote lecturers, who are renowned experts in their fields: Norbert Gronau, University of Potsdam, Germany (2017), Oscar Pastor, Polytechnic University of Valencia, Spain (2017), Alexander Verbraeck, Delft University of Technology, The Netherlands (2017), Paris Avgeriou, University of Groningen, The Netherlands (2016), Jan Juerjens, University of Koblenz-Landau, Germany (2016), Mathias Kirchmer, BPM-D, USA (2016), Marijn Janssen, Delft University of Technology, The Netherlands (2015), Barbara Pernici, Politecnico di Milano, Italy (2015), Henderik Proper, Public Research Centre Henri Tudor, Luxembourg (2014), Roel Wieringa, University of Twente, The Netherlands (2014), Kecheng Liu, University of Reading, UK (2013), Marco Aiello, University of Groningen, The Netherlands (2013), Leszek Maciaszek, Wroclaw University of Economics, Poland (2013), Jan L.G Dietz, Delft University of Technology, The Netherlands (2012), Ivan Ivanov, SUNY Empire State College, USA (2012), Dimitri Konstantas, University of Geneva, Switzerland (2012), Marten van Sinderen, University of Twente, The Netherlands (2012), Mehmet Aksit, University of Twente, The Netherlands (2011), Dimitar Christozov, American University in Bulgaria Blagoevgrad, Bulgaria (2011), Bart Nieuwenhuis, University of Twente, The Netherlands (2011), and Hermann Maurer, Graz University of Technology, Austria (2011) The high quality of the BMSD 2018 program is enhanced by two keynote lectures delivered by outstanding guests: Jan Mendling, WU Vienna, Austria (Title: “Blockchains for Business Process Management - Challenges and Opportunities”) and Roy Oberhauser, Aalen University, Germany (Title: “The Convergence of Business, Software Development and IT Operations and the Next Wave”) Further, the keynote speakers and some other BMSD 2018 participants will take part in a panel discussion and also in other discussions stimulating community building and facilitating possible R&D project acquisition initiatives These special activities will contribute to maintaining the event’s high quality and inspiring our steady and motivated community We demonstrated for an eighth consecutive year a high quality of papers and we are proud to have succeeded in establishing and maintaining (for many years already) high scientific quality and stimulating collaborative atmosphere Also, our community is inspired to share ideas and experiences Preface VII In 2018, the scientific areas of interest to the symposium are: (a) Business Processes and Enterprise Engineering; (b) Business Models and Requirements; (c) Business Models and Services; (d) Business Models and Software; (e) Information Systems Architectures and Paradigms; (f) Data Aspects in Business Modeling and Software Development In tune with the aforementioned challenges and in line with the BMSD areas, BMSD 2018 addresses a large number of research topics: • Design Thinking • Business Processes – – – – – – – – – – – – – Enterprise Modeling Business Process Modeling Business Process Variability Business Process Management and Notations Evaluation of Notations Business Process Contracting Business Processes and Interoperability Issues Business Processes and Supply-Chain Issues Process Modeling within Augmented Reality Digital Business Models Visualizations of Business Process Models Inter-Enterprise Collaborations Business–IT Alignment • Software Specification – – – – – – – – Software Ecosystems Composition of (IT) Services and Service-Level Agreements Micro-Service Architectures Specification of Context-Aware, Self-Managing, and Value-Sensitive Systems Product Variability Software Development Monitoring Software Defect Management Vehicle Navigation Applications • Crosscutting Concerns – Information Security – Privacy • Analytics – Fuzzy Decision-Making – Data Analytics – Processing of Uncertain Data • Hot Topics in Technology and Innovation – Blockchain Technology – Internet of Things VIII Preface BMSD 2018 received 76 paper submissions from which 35 papers were selected for publication in the symposium proceedings Of these papers, 14 were selected for a 30-minute oral presentation (full papers), leading to a full-paper acceptance ratio of 19% (compared with 26% in 2017) – an indication of our intention to preserve a high-quality forum for the next editions of the symposium The BMSD 2018 keynote lecturers and authors are from: Austria, Belgium, Bulgaria, Denmark, Finland, Germany, Indonesia, The Netherlands, Russia, Slovenia, Sweden, Switzerland, Turkey, UK, and USA (listed alphabetically), i.e., a total of 15 countries (compared with 20 in 2017, 16 in 2016, 21 in 2015, 21 in 2014, 14 in 2013, 11 in 2012, and 10 in 2011) to justify a strong international presence Four countries have been represented at all eight BMSD editions so far: Bulgaria, Germany, The Netherlands, and UK, indicating a strong European influence BMSD 2018 was organized and sponsored by the Interdisciplinary Institute for Collaboration and Research on Enterprise Systems and Technology (IICREST) and co-organized by Vienna University of Economics and Business (WU Vienna), being technically co-sponsored by BPM-D Cooperating organizations were Aristotle University of Thessaloniki (AUTH), Delft University of Technology (TU Delft), the UTwente Center for Telematics and Information Technology (CTIT), the Dutch Research School for Information and Knowledge Systems (SIKS), and AMAKOTA Ltd Organizing this interesting and successful symposium required the dedicated efforts of many people Firstly, we must thank the authors, whose research and development achievements are recorded here Next, the Program Committee members each deserve credit for the diligent and rigorous peer-reviewing Further, we would like to mention the excellent organization provided by the IICREST team (supported by its logistics partner, AMAKOTA Ltd.); the team (our gratitude to Aglika Bogomilova and Tania Manova) did all the necessary work for delivering a stimulating and productive event, supported by our Austrian Colleagues Rebecca Runge and Roman Franz We are grateful to Springer for their willingness to publish the current proceedings and we offer special compliments to Ralf Gerstner for all his support and also to Christine Reiss for her professionalism, patience, and great collaboration with regard to the proceedings preparation Last but not least, we thank the keynote speakers for their invaluable contribution and for taking the time to synthesize and deliver their talks We wish you all inspiring reading We look forward to meeting you next year in Lisbon, Portugal, for the Ninth International Symposium on Business Modeling and Software Design (BMSD 2019), details of which will be made available on http://www.is-bmsd.org June 2018 Boris Shishkov Organization Chair Boris Shishkov Bulgarian Academy of Sciences/IICREST, Bulgaria Program Committee Hamideh Afsarmanesh Marco Aiello Mehmet Aksit Paulo Anita Paris Avgeriou Dimitar Birov Frances Brazier Ruth Breu Barrett Bryant Cinzia Cappiello Kuo-Ming Chao Samuel Chong Dimitar Christozov Jose Cordeiro Claudio Di Ciccio Jan L G Dietz Teduh Dirgahayu John Edwards Hans-Georg Fill Chiara Francalanci J Paul Gibson Rafael Gonzalez Norbert Gronau Clever Ricardo Guareis de Farias Jens Gulden Ilian Ilkov Ivan Ivanov Marijn Janssen Gabriel Juhas Dmitry Kan Stefan Koch Michal Krcal University of Amsterdam, The Netherlands University of Groningen, The Netherlands University of Twente, The Netherlands Delft University of Technology, The Netherlands University of Groningen, The Netherlands Sofia University St Kliment Ohridski, Bulgaria Delft University of Technology, The Netherlands University of Innsbruck, Austria University of North Texas, USA Politecnico di Milano, Italy Coventry University, UK Capgemini, UK American University in Bulgaria – Blagoevgrad, Bulgaria Polytechnic Institute of Setubal, Portugal WU Vienna, Austria Delft University of Technology, The Netherlands Universitas Islam Indonesia, Indonesia Aston University, UK University of Vienna, Austria/University of Bamberg, Germany Politecnico di Milano, Italy Telecom and Management Sud Paris, France Javeriana University, Colombia University of Potsdam, Germany University of Sao Paulo, Brazil University of Duisburg-Essen, Germany IBM, The Netherlands SUNY Empire State College, USA Delft University of Technology, The Netherlands Slovak University of Technology, Slovak Republic AlphaSense Inc., Finland Johannes Kepler University Linz, Austria Masaryk University, Czech Republic Monitoring the Software Development Process 3.3 439 Mining the Organizational Perspective Software development projects are knowledge intensive, thus involve creativity and flexibility Project participants are free to tackle development tasks according to their expertise and ideas to solve ad-hoc problems De facto, members may behave according several roles in the organization Therefore, the discovery of the roles of a software project may give important insights on the actual project Role discovery can help in the monitoring existing projects in two ways First, emerging roles can be analyzed in order to have a better skills profiling of the resources Second, emerging roles can be used to check whether resources are breaking contractual agreements or norms We have developed an approach for tackling the problem of mining the organizational perspective in software development projects The approach provides information about the actors involved in the business process and their relations In substance, it provides automatic classification of resources into company roles (e.g., developer, tester, etc.) based on the comments of project participants It works on VCS logs and provides information about the people, their roles, other systems involved, the organization hierarchy, the social network, and resource profiling Figure shows an example of resource profiles automatically inferred from VCS comments Fig Profiles of a developer and a tester, from left to right Challenges of using NLP concern the jargon used by software developers They often use technical terms, very short phrases, or a number of codes and hyperlinks These makes NLP techniques score low results even on simple tasks like sentence parsing, or name-entity recognition Therefore, approaches should take into account several factors when mining for the organizational perspective The result allows the manager to have measurable information about the resources For example, two people work better together and how can we build the best team? Details of the approach to extract resource profiles can be found in [4] 3.4 Mining the Control-Flow Perspective Important knowledge of the control flow of a software development process can be extracted from VCS and ITS One important mechanism widely used in 440 S Bala and J Mendling software development for collaboration are pull requests A pull request is issued every time a developer wants to contribute to the main source with a new piece of code Pull requests trigger communication among different people and may help shedding light into problems, learn new things and obtain new ideas on the existing software It is interesting for project managers and developers to better understand factors and behavior that makes a pull request successful In ongoing work, we are investigating the relation of the pull request process and surrounding factors such as the generation of new ideas or change of behavior We have obtained a data set of pull requests spanning over two years from an real world repository User conversations have been manually annotated with codes that classify them into categories of comments We are current able to discriminate whether a comment is a new idea, an assumption, a merge that closes a pull request, etc Considering the pull request identifiers as cases and the codes as activities, we are able extract the process of the pull requests It is interesting to compare how the conversation (i.e., behavioral perspective) unfolds before and after a pull request is merged We plan to explain these differences by also taking into account further information from text such as emotions The challenge of mining the control-flow usually pertains the completeness of data and the case and activity identification While PM contribution have been focusing mostly on the control-flow perspective, techniques from MSR hardly go beyond mining the bug lifecycle [5] The nature of software development process makes it difficult to recognize recurrent activities when only VCS are analyzed Expected Contribution and Implications for Research This position paper presents research on mining the software development process Approaches towards discovering the perspectives of time, resources and cases have been developed and the results suggest that obtaining process knowledge from software repositories brings new insights for the project managers [4,6,7] In future work, we plan to complete the research by tackling the problem of discovering the flow-perspective of the software development process Usefulness will be evaluated through user studies This research extends the process mining field towards its adoption on software repositories Project managers would benefit from this research by having a process perspective on their ongoing projects through visual models and diagrams, thus overcoming existing flat approaches based on simple indicators such as burndown charts or change plots offered by existing tools References van der Aalst, W.M.P.: Process Mining: Data Science in Action Springer, Heidelberg (2016) https://doi.org/10.1007/978-3-662-49851-4 Abate, P., Boender, J., Di Cosmo, R., Zacchiroli, S.: Strong dependencies between software components In: 2009 3rd International Symposium on Empirical Software Engineering and Measurement, ESEM 2009, pp 89–99 (2009) Monitoring the Software Development Process 441 Aggarwal, C., Zhai, C.: Mining Text Data Springer, Heidelberg (2012) https:// doi.org/10.1007/978-1-4614-3223-4 Agrawal, K., Aschauer, M., Thonhofer, T., Bala, S., Rogge-Solti, A., Tomsich, N.: Resource classification from version control system logs In: EDOC Workshop, pp 249–258, September 2016 Akbarinasaji, S., Caglayan, B., Bener, A.: Predicting bug-fixing time: a replication study using an open source software project J Syst Softw 136, 173–186 (2018) Bala, S., Cabanillas, C., Mendling, J., Rogge-Solti, A., Polleres, A.: Mining projectoriented business processes In: Motahari-Nezhad, H.R., Recker, J., Weidlich, M (eds.) BPM 2015 LNCS, vol 9253, pp 425–440 Springer, Cham (2015) https:// doi.org/10.1007/978-3-319-23063-4 28 Bala, S., Revoredo, K., de A.R Gon¸calves, J.C., Bai˜ ao, F., Mendling, J., Santoro, F.: Uncovering the hidden co-evolution in the work history of software projects In: Carmona, J., Engels, G., Kumar, A (eds.) BPM 2017 LNCS, vol 10445, pp 164–180 Springer, Cham (2017) https://doi.org/10.1007/978-3-319-65000-5 10 Chen, T.H., Thomas, S.W., Hassan, A.E.: A survey on the use of topic models when mining software repositories Empir Softw Eng 21(5), 1843–1919 (2016) D’Ambros, M., Lanza, M., Lungu, M.: Visualizing co-change information with the evolution radar IEEE Trans Softw Eng 35(5), 720–735 (2009) 10 de A.R Gon¸calves, J.C., Santoro, F.M., Bai˜ ao, F.A.: Let me tell you a story - on how to build process models J UCS 17(2), 276–295 (2011) 11 Kindler, E., Rubin, V., Schă afer, W.: Activity mining for discovering software process models Softw Eng 79, 175–180 (2006) 12 Kindler, E., Rubin, V., Schă afer, W.: Incremental workow mining based on document versioning information In: Li, M., Boehm, B., Osterweil, L.J (eds.) SPW 2005 LNCS, vol 3840, pp 287–301 Springer, Heidelberg (2006) https://doi.org/ 10.1007/11608035 25 13 Leopold, H (ed.): Natural Language in Business Process Models LNBIP, vol 168 Springer, Cham (2013) https://doi.org/10.1007/978-3-319-04175-9 14 Lindberg, A., Berente, N., Gaskin, J.E., Lyytinen, K.: Coordinating interdependencies in online communities: a study of an open source software project Inf Syst Res 27(4), 751–772 (2016) 15 Mendling, J., Leopold, H., Pittke, F.: 25 challenges of semantic process modeling Int J Inf Syst Softw Eng Big Co 1(1), 78–94 (2014) 16 Pinzger, M., Kim, S.: Guest editorial: mining software repositories Empir Softw Eng 21(5), 2033–2034 (2016) 17 Poncin, W., Serebrenik, A., van den Brand, M.: Process mining software repositories In: 2011 15th European Conference on Software Maintenance and Reengineering (CSMR), pp 5–14 IEEE (2011) 18 Richetti, P.H.P., de A.R Gon¸calves, J.C., Bai˜ ao, F.A., Santoro, F.M.: Analysis of knowledge-intensive processes focused on the communication perspective In: Carmona, J., Engels, G., Kumar, A (eds.) BPM 2017 LNCS, vol 10445, pp 269– 285 Springer, Cham (2017) https://doi.org/10.1007/978-3-319-65000-5 16 19 Rubin, V., Gă unther, C.W., van der Aalst, W.M.P., Kindler, E., van Dongen, B.F., Schă afer, W.: Process mining framework for software processes In: Wang, Q., Pfahl, D., Raffo, D.M (eds.) ICSP 2007 LNCS, vol 4470, pp 169–181 Springer, Heidelberg (2007) https://doi.org/10.1007/978-3-540-72426-1 15 20 Ruohonen, J., Hyrynsalmi, S., Leppă anen, V.: Time series trends in software evolution J Softw.: Evol Process 27(12), 990–1015 (2015) 442 S Bala and J Mendling 21 Thomas, S.W., Hassan, A.E., Blostein, D.: Mining unstructured software repositories In: Mens, T., Serebrenik, A., Cleve, A (eds.) Evolving Software Systems, pp 139–162 Springer, Heidelberg (2014) https://doi.org/10.1007/978-3-642-4539845 22 Weicheng, Y., Shen, B., Xu, B.: Mining GitHub: why commit stops - exploring the relationship between developer’s commit pattern and file version evolution In: Muenchaisri, P., Rothermel, G (eds.) APSEC 2013, Ratchathewi, Thailand, 2–5 December 2013, vol 2, pp 165–169 IEEE Computer Society (2013) 23 Zaidman, A., Rompaey, B.V., Demeyer, S., van Deursen, A.: Mining software repositories to study co-evolution of production & test code In: ICST, pp 220–229 IEEE Computer Society (2008) A Conceptual Tool to Improve the Management of Software Defects Nico Hillah(&) University of Lausanne, Lausanne, Switzerland nico.hillah@unil.ch Abstract Software teams address software defect problems in a simple way: they identify them, assign them and resolve them Nevertheless, studies have proven that having only these activities as approaches to handle a large and increasing number of software defects is inefficient As a solution to this, we propose in this study a managerial conceptual tool for mining software defects in order to improve the management of SDs With our proof of concept, we demonstrate how SDs mining management can be enhanced from a strategic and operational view This is done through the precise definition of software defects’ management objectives in line with the objectives of the software product owner Keywords: Defects mining Á Software defect management Á Control measures Introduction IEEE standard 1044-2009 [1] defines a defect as: “An imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced” Not only the software defects (SDs) are present in the whole life cycle of a software product, but different studies also proved that 80% of the total cost of the software life cycle is associated with the management of the SDs [2] Having this high impact on the software product, SDs management must be crucial to software teams as well as to organizations Nowadays, the management of SDs does not only consists of identifying, assigning, and correcting them, but also in mining them The purpose of this study is to focus on the mining aspect of SDs management In fact, there are different studies which propose solutions on how to mine SDs [2– 4] However, most of these existing techniques are limited to the collection, the classification, and the assignment of the SDs In addition, these techniques not cover the question of how to define specific SDs mining management objectives that are aligned with first, the SDs management objective, and second, with the objectives of the software product owner This results in a poor resource allocation in mining SDs as well as in the absence of control over the SDs management in a software life cycle In this regard, the problem we address in this paper is how to improve and control SDs mining management in alignment with the business objectives of the software owner? © Springer International Publishing AG, part of Springer Nature 2018 B Shishkov (Ed.): BMSD 2018, LNBIP 319, pp 443–451, 2018 https://doi.org/10.1007/978-3-319-94214-8_35 444 N Hillah As a solution to this problem, we are proposing the use of our conceptual tool to control the mining management of the SDs This conceptual tool is a guideline with four stages The paper will proceed as follows: first, we will define the software defect and its management approaches Secondly, we will present the conceptual tool that we used to conduct the proof of concept Finally, we will present the results and the advantages that we gained from applying it Related Works The defects are the source of software failures and problems Software failures are defined as “Termination of the ability of a product to perform a required function or its inability to perform within previously specified limits” [p 5, 3] In the last decade, SDs management has received a considerable amount of attention from researchers In fact, SDs management has been the center of interest for many studies in different software studies subdomains such as software project management, software engineering and evolution [6, 7] Due to the diversity of these studies, we group them into branches based on their interest in SDs management The first branch deals with questions such as how to collect and store these SDs Studies related to this branch provide answers to questions such as how to collect SDs or which SDs characteristics must be documented [8] These studies propose solution tools named bug-tracking systems to help collect SDs They take the form of a central hub accessible by project managers and software developers to manage the software products Some of these online tools are Jira [9] and Bugzilla [10] The second branch deals with questions such as how to assign SDs to developers or how to deal with the problem of an SDs duplication [11] The research in this branch proposes techniques and methods such as algorithms to automatically assign SDs to the right developer [12–14] and also techniques to eliminate the duplication of SDs [15] The third branch deals with the triage and the mining of SDs In the software life cycle, the mining of defects presents many advantages [2] Researchers as well as practitioners in this branch have proposed schemas and taxonomies for mining SDs The best-known schemas are (1) The Orthogonal Defect Classification (ODC) of IBM [16], the root cause analysis [1], (2) the HP Defect origins, types and modes [17] and standards like the IEEE standard 1044-2009 [5] In the same context, they also apply data mining methods such as the Naïve Bayes Model [13] or the regression model [2] to classify SDs In fact, the classification of defects helps the software development teams to reduce the cost of correcting SDs and helps them detect defective modules This study is conducted as part of this last branch In fact, our goal is to propose a conceptual tool to improve the quality of software mining results in an organization, since these results will lead to decision making concerning the quality of the software systems The need to assure that the mining is rightly performed with defined targets will improve decision making concerning the state of software quality A Conceptual Tool to Improve the Management of Software Defects 445 Presentation of the Conceptual Tool In order to provide a means to avoid the insignificant SDs mining results to software product owners, we decided to propose this conceptual tool Mining SDs is a complex set of activities; it goes from selecting a technique to mine the SDs, interpreting the obtained results, to taking a decision based on the obtained results Moreover, each software system is unique, thus needs a specific SDs mining management strategy, e.g., the SDs of the system Waterfox are not the same for Firefox, even though they have similar functionalities and purpose Due to this complexity, inefficient SDs mining can lead to situations such as: (1) the results obtained from the SDs mining are irrelevant for the product owner; (2) the SDs mining is requiring much more resources than planned and software teams failed to take decisions in order to improve the quality of the software system based on the mining results; (3) the mining goals are poorly aligned with the strategy and the objectives of SDs management and the product owner’s business needs and; (4) control and evaluation measures for obtained results are missing To avoid these problems, we are proposing this conceptual tool to guide SDs miners wishing to improve their mining project Although there are similar existing conceptual tools in the literature for business domain [18], our conceptual tool is designed to target the SDs mining management field The aim of this conceptual tool is to help software teams to define their SDs mining management strategy and to specify concrete actions to put in place this strategy in mining SDs The conceptual tool is defined fourfold: (1) The first step consists of defining the SDs mining management strategy in alignment with the needs of the software product owner The strategy must be broken down into short or medium term goals to achieve The software team, as well as the product owner, must approve these goals, e.g., a defect mining management strategy may be the improvement of the software quality by developing error-free programs for each software version released The approval of these goals will lead to the second stage (2) The next step, which is the operational level, is to convert this strategy into concrete objectives Referring to the previous example, the set of objectives will be to improve the detection of the defect modules and predict SDs (3) Following this, each objective must be broken down into terms of specific actions to be performed, e.g., classifying SDs according to their priorities In addition, members of the SDs mining are responsible to implement each of these actions (4) Following this and depending on the actions put in place, software teams must carefully select control measures to evaluate the state of the actions, e.g., the ratio of the corrected high level prioritized SDs over the total number of SDs received Finally, the software team must define a list of actions to establish in order to correct cases where the set objectives have not been reached, e.g reorganization of the process to detect SDs Figure presents the process to follow to implement the proposed conceptual tool 446 N Hillah Fig The process of the conceptual tool The Application of the Software Defects Managerial Conceptual Tool In order to apply the proposed conceptual tool to improve and control the SDs mining management in practice, we decided to conduct a proof of concept of a software system that we will name system A This system is developed using the scrum method The owner of this system A is an education company Its purpose is to help schools in managing the grades of their students The overall objectives set by the owner of the system A is to have a software system with a considerable high quality, with emphasis on its availability to the users, especially during the exam period In line with this objective, the software team objective aims to improve the assignment and the correction of the SDs A Conceptual Tool to Improve the Management of Software Defects 4.1 447 Stage and 2: Strategy Definition and Set of Objectives In alignment with the owner’s objective, our strategy would be to mine SDs in order to reduce the impact of SDs on the system to limit the system’s unavailability time (stage 1) In the next step (stage 2), we cascade the defined strategy in different objectives such as to reduce the impact of defects on system A and possibly to improve the correcting process of the SDs In the next step, we defined a set of actions to implement the objective of reducing the impact of defects on the system (stage 3) We first need to know the actual number of defects of this system A and then classify them according to their impact To this, we classify SDs according to their severity in order to analyze the different impact that they are having on the system availability In the next session, we will present how we classified the SDs of system A, and then we will present the application of the final stage on this system A 4.2 Stage 3: The Classification of SDs of System A We analyzed the SDs of system A over a period of a year, from January 2015 to December 2015 System A has 522 SDs We analyzed the SDs of this system by classifying them according to the defect severity attribute of IEEE 1044-2009 standards (see Table 2) This severity attribute is one of the most used attributes in SDs classification in practice [19] The main advantage of choosing the severity attribute is the possibility for managers to identify which defect should be first corrected [19] The IEEE’s standard defines this attribute as “The highest failure impact that the defect could (or did) cause, as determined by (from the perspective of) the organization responsible for software engineering.” [5] There are five values of severity They are classified from the most significant to the least significant (see Table 1) Table Severity values [5] Attribute Severity Value Blocking (B) Critical (C) Major (Mj) Minor (Mn) Inconsequential (I) 4.3 Definition Testing is inhibited or suspended pending correction or identification of suitable workaround Essential operations are unavoidably disrupted, safety is jeopardized, and security is compromised Essential operations are affected but can proceed Nonessential operations are disrupted No significant impact on operations Stage 4: The Section of Control Measures There are two important aspects to consider when selecting the evaluation metrics at the fourth stage of this conceptual tool The first one is to choose metrics based on the objective or action to evaluate, e.g a ratio of the corrected SDs over the total number of SDs received to evaluate the SDs’ correction process The second one is to take into consideration the critical level [20] of the system being managed This critical level can 448 N Hillah Table System A software defects classification Severity B C Mj Mn I Total Jan 28 10 43 Feb 15 11 32 Mar 34 14 63 Apr 38 56 May 20 29 June 25 15 42 July 10 Aug 27 Sept 11 18 15 53 Oct 22 39 Nov 15 37 20 83 Dec 18 12 45 Total 51 60 268 128 15 522 relate to its business, security, and safety aspect In addition, to determine the critical level of the system, software teams must consult and get the approval of the product owner To track and evaluate the success of our objective, we selected a metric as an indicator (stage 4) In this regard, we defined the SDs indicator as a ratio of the number of a type of SDs over the total SDs number received within a month This ratio informs us about the type of defects that is problematic during the month We define a problematic case as follows: when the number of a certain type of SDs is higher or equal to one-third of the total SDs number of a month One-third of the total SDs is an agreed upon limited number a type of SDs may have during a month The selection of this metric was based on system A’s critical mission, which is its availability during the exam periods We defined the indicator as follows: n expresses the type of SDs to evaluate X; the value of SDs and t P being a time period ðX Þt If Xn t ! then investigate ð1Þ Following this, we defined a list of actions to undertake in order to correct problematic cases These actions are: • to conduct an investigation within the problematic type of SDs to identify miscorrected defects; • to reorganize the process of correcting the problematic type of SDs; • to check other indicators such as the number of correcting defects over the total SDs within this category A Conceptual Tool to Improve the Management of Software Defects 449 Our choice of action depends on the investigation results In this regard, an investigation must be conducted when an indicator is reached, in order to identify the problem and to provide the right fix on time In Fig 2, we present the application of our indicator on SDs of system A in 2015 Major SDs 100 80 60 40 20 Jan Feb Mar Apr May June July Aug Sept Oct Nov Dec Number of SDs 100 80 60 40 20 Jan Feb Mar Apr May June July Aug Sept Oct Nov Dec Number of SDs Minor SDs Minor Total SDs Indicator Major Critical SDs Indicator Blocking SDs 100 NUmber of SDs 100 80 60 40 20 80 60 40 20 Jan Feb Mar Apr May June July Aug Sept Oct Nov Dec CriƟcal Total SDs Indicator Jan Feb Mar Apr May June July Aug Sept Oct Nov Dec Number of SDs Total SDs Blocking Total SDs Indicator Fig Classified SDs of system A with the indicators Discussion and Contribution The results clearly show us that the group of minor, blocking, and critical SDs management has reached the objective set in relation to the organization’s objectives In opposition, the major type of SDs failed to reach the fixed goal In fact, from January until June, the number of the major SDs was considerably high After investigating those months, we found that the high number of SDs of January was due to the duplication of SDs Similarly, the month of March inherited some of the SDs of January that were incorrect E.g., mistakes found in the names of some of the students were related to the use of ACSII format in system A and corrected in the system in January; but the same mistakes reappeared in the month of March, due to the use of an API to connect system A to an external system B This information leads to the assignment process reorganization for the major type of SDs 450 N Hillah Applying this conceptual tool gives not only the insight of the SDs mining management, but also of the entire SDs management In fact, knowing the status of each type of SDs will guide the SDs manager to focus on the problematic group of SDs and to reorganize the resource allocation in handling these groups of SDs This improves the decision-making in managing SDs Consequently, it improves the SDs management altogether The application of this conceptual tool is a manner not only to improve the management of SDs but also to align this management with the objectives of the software product owner Its implementation is also flexible concerning the objectives set by each organization and its software department In addition, the selection of control measures to evaluate the management must be customized for each software product This conceptual tool alerted us to bring the management of SDs into line Most of all, it did not demand many interventions from us once we set it up We propose this conceptual tool not only as contribution, but we also demonstrate its application in a real case Conclusion Our proof of concept presents some of the advantages that software teams can gain from implementing our conceptual tool This tool not only helps to define the precise objectives in line with the objectives of software owners in the context of SDs mining management but also guides the owners to evaluate the state of their SDs management Indeed, the defined control measures will alert them to possible existing problems related to the management of their SDs and, therefore, of their software products Knowing this, they will be able to take the right actions to handle the SDs Herewith they will, on the one hand, considerably achieve the set goals, on the other hand, improve the quality of the software product, and reduce the cost of its development or maintenance In our future work, we will provide a deep insight into the process of defining and implementing appropriate SDs management strategies by looking at the interdependence among the SDs management branches References Leszak, M., Perry, D.E., Stoll, D.: Classification and evaluation of defects in a project retrospective J Syst Softw 61, 173–187 (2002) Rajbahadur, G.K., Wang, S., Kamei, Y., Hassan, A.E.: The impact of using regression models to build defect classifiers In: Proceedings of the 14th International Conference on Mining Software Repositories, pp 135–145 (2017) Kagdi, H., Collard, M.L., Maletic, J.I.: A survey and taxonomy of approaches for mining software repositories in the context of software evolution J Softw Maint Evol Res Pract 19(2), 77–131 (2007) Davies, S., Roper, M., Wood, M.: Comparing text-based and dependence-based approaches for determining the origins of bugs J Softw Evol Process 26(1), 107–139 (2014) Comparing approaches for determining bug origins 1044–2009 IEEE Standard Classification for Software Anomalies (2009) A Conceptual Tool to Improve the Management of Software Defects 451 Fischer, M., Pinzger, M., Gall, H.: Analyzing and relating bug report data for feature tracking In: WCRE, vol 3, p 90 (2003) Cavalcanti, Y.C., da Mota Silveira Neto, P.A., Machado, I.D.C., Vale, T.F., Almeida, E.S., Meira, S.R.D.L.: Challenges and opportunities for software change request repositories: a systematic mapping study J Softw Evol Process 26(7), 620–653 (2014) Tian, Y., Lo, D., Sun, C.: DRONE: predicting priority of reported bugs by multi-factor analysis, pp 200–209 (2013) Atlassian: Jira | Logiciel de suivi des tickets et des projets Atlassian https://fr.atlassian.com/ software/jira Accessed 06 Apr 2018 10 Home :: Bugzilla :: bugzilla.org https://www.bugzilla.org/ Accessed 06 Apr 2018 11 Runeson, P., Alexandersson, M., Nyholm, O.: Detection of duplicate defect reports using natural language processing In: Proceedings of the 29th International Conference on Software Engineering, pp 499–510 (2007) 12 Anvik, J., Hiew, L., Murphy, G.C.: Who should fix this bug? In: Proceedings of the 28th International Conference on Software Engineering, pp 361–370 (2006) 13 Murphy, G., Cubranic, D.: Automatic bug triage using text categorization In: Proceedings of the Sixteenth International Conference on Software Engineering & Knowledge Engineering (2004) 14 Aljarah, I., Banitaan, S., Abufardeh, S., Jin, W., Salem, S.: Selecting discriminating terms for bug assignment: a formal analysis, pp 1–7 (2011) 15 da Mota Silveira Neto, P.A., Lucrédio, D., Vale, T., de Almeida, E.S., de Lemos Meira, S.R.: The bug report duplication problem: an exploratory study Softw Qual J 21(1), 39–66 (2013) 16 Chillarege, R., et al.: Orthogonal defect classification-a concept for in-process measurements IEEE Trans Softw Eng 18(11), 943–956 (1992) 17 Huber, J.T.: A comparison of IBM’s orthogonal defect classification to Hewlett Packard’s defect origins, types, and modes Hewlett Packard Company (1999) 18 Wheelen, T., Hunger, D.: A Descriptive Model of Strategic Management Scribd https:// www.scribd.com/document/29959620/A-Descriptive-Model-of-Strategic-ManagementWheelen-amp-Hunger Accessed 26 Apr 2018 19 Wagner, S.: Defect classification and defect types revisited In: Proceedings of the 2008 Workshop on Defects in Large Software Systems, pp 39–40 (2008) 20 Rushby, J.: Critical system properties: survey and taxonomy Reliab Eng Syst Saf 43(2), 189–219 (1994) Author Index Adensamer, Alexander 270 Ahoa, Emmanuel 338 Alpár, Greg 298 Alpaslan, Ferda Nur 362 Bala, Saimir 432 Barteld, Marco 328 Berkel, A R R 167 Birov, Dimitar 280, 421 Camposano, José Carlos Cecconi, Alessio 56 Colle, Didier 372 Crompvoets, Joep 289 18 Dankov, Yavor 280 Degrande, Thibault 372 Di Ciccio, Claudio 56 Engels, Gregor 390 Felix, Dominik 56 Franz, Peter 32 Garvanov, Ivan 382 Garvanova, Magdalena 382, 412 Gebhardt, Rainer 328 Giray, Görkem 221 Goman, Maksim 116 Grave, Frank 352 Grefen, Paul 133 Greff, Tobias 308 Gronau, Norbert 98 Grum, Marcus 98 Gusain, Rakesh 32 Haas, Dominik 56 Hillah, Nico 443 Huber, Jernej 260 Janssen, Marijn 69, 185, 289, 412 Jazayeri, Bahar 390 Johann, Denis 308 Jošt, Gregor 260 Kabakchiev, Christo 382 Karamanlioglu, Alper 362 Kassahun, Ayalew 338 Kazantsev, Nikolay 319 Kirchmer, Mathias 32 Klievink, Bram 69 Kocbek, Mateja 260 Kreiner, Christian 203 Kundisch, Dennis 390 Küster, Jochen 390 Larsen, John Bruntse Lilek, Daniel 56 Luthfi, Ahmad 289 185 Matic, Alexandre 83 Mehandjiev, Nikolay 319 Mendling, Jan 56, 243, 401, 432 Neu, Christian 308 Oberhauser, Roy 83 Oppermann, Felix Jonathan 203 Orthacker, Clemens 203 Ozkan, Baris 133 Papapostolu, Tasos 421 Pishchulov, Grigory 319 Pogolski, Camil 83 Polančič, Gregor 260 Potzmader, Klaus 203 Rieger, Christoph 149 Riel, Florian 56 Roubtsov, Serguei 298 Roubtsova, Ella 298 Rueckel, David 270 Rumpl, Andreas 56 Rutledge, Lloyd 352 454 Author Index Sampaio, Pedro 319 Shishkov, Boris 185, 382, 401, 412 Silvander, Johan 249 Singh, P M 167 Sinnhofer, Andreas Daniel 203 Steger, Christian 203 Suratno, Bambang 133 Suurmond, Coen Svahnberg, Mikael 249 Szopinski, Daniel 390 Tekinerdogan, Bedir 221, 338 Tilebein, Meike 328 Turetken, Oktay 133 Uhlig, Philipp 56 van de Wetering, Rogier 352 van Engelenburg, Sélinde 69 van Sinderen, M J 167 Vannieuwenborg, Frederic 372 Verbrugge, Sofie 372 Warnier, Martijn 185 Weiß, Michael 328 Werth, Dirk 308 Zimmermann, Olaf 390 ... both for Business Modelling and for Software Design: Business Modelling should be based on how real business is done and not on some rationalistic idealised view on business, and Software Design. .. Processes and Enterprise Engineering; (b) Business Models and Requirements; (c) Business Models and Services; (d) Business Models and Software; (e) Information Systems Architectures and Paradigms;... • Business Processes – – – – – – – – – – – – – Enterprise Modeling Business Process Modeling Business Process Variability Business Process Management and Notations Evaluation of Notations Business