Decisions concerning prioritisation occur in di erent moments during software development and can involve di erent stakeholders. Our research objective is to develop prioritisation processes that meet stakeholders' needs, and allow obtaining better quality decisions. In this paper we propose a structured approach to model decision-making in real setting with the purpose of eliciting from the stakeholders involved in the decision-making process their needs for improvements. We use the resulting models to derive a general model for prioritisation processes and outline how such processes could be tool-supported.
Decision-making (DM) is a frequently occurring activity during software
evolution. The decisions often take the form of prioritisation [
The work in this paper is based on the analyses of DM processes in the industrial use cases of SUPERSEDE 3, a European H2020 project under the theme \Tools and Methods for Software Development". SUPERSEDE aims at delivering methods and tools to support requirements prioritisation and enactment, to enable a continuous software evolution, driven by user-feedback and monitored data. SUPERSEDE has industrial use cases coming from three di erent companies: ATOS Spain, Siemens AG, and SEnerCon GmbH. In this paper, we focus on the use case from SEnerCon since it is compact enough to present in a paper while sharing most of the cross-cutting issues and challenges of the other uses cases. However, the methodology presented in this paper has been applied to the other use cases as well.
SEnerCon is a Small-Medium Enterprise with 25-years of experience in engineering and consultancy in the domain of energy e ciency management. The company has mainly software developers and engineers, who focus on software development and energy consulting. The software application iESA 4 (interactive Energy Saving Account) developed by SEnerCon is the subject of the case study. iESA is used in Germany by private households, public buildings and ofces, as well as in several projects as a monitoring tool of energy consumption. For SEnerCon it is important to improve the quality of its services in order to satisfy its customers. Therefore, a monthly DM process takes place to evolve and maintain iESA.
To analyse DM processes for requirements prioritisation in the use cases, we de ned a structured methodology, including a semi-structured survey to elicit information about the current practice, and modelled the resulting processes. The formulation of a reliable and representative model is an important step in the study of DM processes. Knowing, understanding, and being able to represent how decisions are adopted is a fundamental prerequisite for improving existing DM processes or designing new ones. We used the models to identify the main concepts involved in the prioritisation DM process, and consequently to derive a general model for a tool-supported prioritisation DM process. These results could help managers and designers to explore and implement their own prioritisation DM processes.
In the rest of the paper, we describe the methodology in Section 2 and illustrate how we applied it to the case study in Section 3. We discuss the analysis of the models and how they supported us in deriving a general, tool-supported prioritisation DM process in Section 4. Related works and conclusion are presented in Sections 5 and 6 respectively. 2
The methodology for modelling prioritisation DM processes We introduce the methodology used to elicit and model prioritisation DM processes from SUPERSEDE use cases. This methodology is divided in parts: 1. eliciting and modelling the \as-is" prioritisation DM process from the use cases; 2. identifying the main concepts involved in the prioritisation DM processes;
3. identifying potential improvements in the current (as-is) processes. Thus, we model the \to-be" prioritisation DM process considering the identi ed improvements.
The technique adopted to elicit information from stakeholders in the use cases about their relevant DM processes is questionnaire-based. The interviewed stakeholders should know very well their DM processes, they could be project managers, developer leaders, and so on. The objective of the questionnaire is to obtain a vision of the major aspects of the DM processes when software products are evolved. The following main questions are used: Q1 What are the inputs to the DM process? the sources of information used in the DM process are described and discussed. For example: list of alternatives (features), company policies, or decisions from other DM processes. Q2 What is the output of the DM process? the result of the DM process is described. For example: artefacts that are approved, rankings of features or allocation of development activities to developers.
Q3 Who are the stakeholders involved in the DM process? the stakeholders involved in the DM process are identi ed and described in order to have a clear vision of their roles, goals, expertises and perspectives.
Q4 What are the methods/tools used for the DM process? the methods/tools exploited in the DM activities are described. For example: face-to-face meetings, discussions, focus groups, automated methods already in place. Q5 How is the DM process structured and how is its ow of activities? the set of activities and their sequence are detailed in the DM process.
The information elicited through the questionnaire are used to model the as-is
prioritisation DM processes . To this end, we use the Decision Model
Notation (DMN) [
BPMN provides multiple diagrams to analysts who design and manage business processes. BPMN provides businesses with the capability of understanding their internal business procedures in a graphical notation and will give organisations the ability to communicate these procedures in a standard manner. It facilitates the understanding of the performance of collaborations and business transactions within and between the organisations.
Figure 1 depicts the elements and dependencies involved in a DM. A decision denotes the act of determining an output from a number of inputs, using decision logic (see below) which may reference one or more business knowledge models.
Decision 1 Input Data 1
Knowledge source 1
Business Knowledge 1 Decision 2
Knowledge source 2
Business Knowledge 2 Input Data 2
Information Requirement Knowledge Requirement
Authority Requirement Notice that the output of a decision could be the input of other decision. A business knowledge model denotes a function encapsulating business knowledge, e.g., as business rules, a decision table, or an analytic model. An input data denotes information used as input by one or more decisions. A knowledge source denotes an authority for a business knowledge model or decision. Concerning the dependencies, an information requirement denotes input data or decision output being used as input to a decision. A knowledge requirement denotes the invocation of a business knowledge model by the decision logic of a decision. Finally, an authority requirement denotes the dependence of an element on another element that acts as a source of guidance or knowledge.
At this level, the de ned decision requirements elements (see above) may be speci ed in greater detail, to capture a complete set of business rules and calculations, and to allow the DM to be automated. Thus, every decision is de ned using a value expression which is a table specifying how the decision's output is determined from its inputs. In the same way, a business knowledge model is de ned using a value expression , which can be expressed as functions invoked from decisions' value expressions.
The combined use of BPMN and DMN provides a graphical language for describing multiple levels of human DM within an organisation. In this context, DMN models describe collaborative organisational decisions, their governance, and the business knowledge required for them. These models help us in understanding the current practice and exploring new methods that can support the \as-is" processes, e.g. automated or semi-automated DM methods. 3
Applying the methodology in SEnerCon case SEnerCon's iESA application enables end-users to monitor and analyse their energy consumption. It counts today tens of thousands of end-users. Most of the features of iESA are free, on condition that the data of registered end-users is used and analysed, upon anonymity. SEnerCon performs a monthly DM process to improve the quality of iESA's services. The DM process is related to product maintenance and aims at selecting which new features and bug xes to implement in an upcoming release of the product. To elicit the current (\as-is") DM process of the iESA, we apply the rst step of the methodology introduced in Section 2. In this section, we report the elicited information via the questionnaire introduced as part of the methodology.
Q1: inputs to the DM process: the main input to the DM process is a set of requests, i.e., requests for new features and bug reports, to be implemented or resolved. They are collected from the Ticket System, from project managers, and from advisors.
From the \Ticket System": Requests for new features and bug reports are collected form telephone calls, emails and feedback gathering mechanism of iESA. The help-desk adds them as requests to the Ticket System. Table 1 shows examples of such requests. A subject and a priority should be established initially. The e ort and due date could also be added, if not they are addressed later in the DM process. Priorities can be maximum, high, normal, and low. From project managers : Other requests are collected from project managers of external projects which, in one way or another, are related to the iESA application. In most cases they have due dates based on the corresponding project plan of the related application. Table 1 shows examples of such types of requests. The collection of information is mainly done manually during inter-project meetings. However, some of the new feature requests may be created in the Ticket System. From advisors of the iESA application : Advisors, who are stakeholders of SEnerCon , can suggest new features to implement. Their suggestions mainly focus on strategical aspects, e.g., to improve the iESA's visibility.
Q2: outputs of the DM process: the goal of the DM process is the next release plan, i.e., the list of new requests to implement in the upcoming release. For this, the priorities should be assigned (if they are not set before), and clarications on the due dates should be establish accordingly available resources. Q3: stakeholders involved in the DM process: di erent stakeholders, with varying expertise and levels of decision power, are involved in the DM process. In particular, the following stakeholders were identi ed: { Help-desk, s/he uses the Ticket System to collect new requests from endusers. { Product manager, collects all requests, lters and merges them. S/he leads meetings with the developers and project managers to assign the importance, called attributes, to the requests. S/he decides the requests to be implemented for the next release. { Developers, they maintain the software. They express the development e ort of each request. { Project manager is responsible for collecting requests of their applications (software applications that use iESA's services). These requests are expressed in the inter-project meetings. { Advisors, who can be the CEO, editors and sales sta , inform new requests accordingly their impressions to make more useful and visible the application. Q4: methods/tools used in the DM process: besides the Ticket System, there is no automated tool employed for supporting the DM process. The most important method used is the weekly stand-up meeting, which is conducted by the Product manager and attended by the development team, the help desk and project manager. The Product manager should collect and analyse the data to decide on a new release plan as soon as possible.
Q5: current DM process A representation of the DM process using BPM and DMN is depicted in Figure 2. The main steps are: { Requests are collected form the Ticket System and project managers. { Requests are ltered and merged by product manager with the whole development team, help-desk and project managers. { Attributes are assigned to requests in order to indicate their importance.
These attributes change the priorities of requests. They can be: due date, such a date may be xed during press releases; user impact, this re ects, for instance, the number of users a ected by the bug, on the value expected with the new feature; and, development e ort, this estimation represents the number of hours to implement a request. { Once the attributes are collected, Product manager decides the priorities of the requests. This list is consequently reviewed to determine its stability. { Once the prioritised list is stable, the Product manager plans the next release considering available time and resources. requests from the [Ticket System] [project managers] [advisors]
Filtered list of requests Filter and merge requests [product manager] [help-desk] [developers] [project managers]
Assign attributes to requests [product manager] [help-desk] [developers] [project managers] attributes not ended Analysis of requests Negotiation
Meeting Decision on: “attributes” Filtered requests
Priorities from help-desk prioritisation not stable prioritised list of requests Filtered list of requests with attributes Tables Filtered requests with attributes atetrnibduetdes oDf ethceisliiosnt oofnrePqriuoeristyts [product manager]
Next release …
Plan Decision on: “Priority” Due dates by project managers
Manual inspection Negotiation
Meeting Priorities (if specified )
As discussed above, the product manager plays a central role in the prioritisation DM process of SEnerCon . While in a small organisation this may have its advantages, it could easily become a bottleneck as well as a single point of failure as the organisation grows. Furthermore, in an organisation where the input of every stakeholder int he DM process is to be considered, a more collaborative and transparent process involving all stakeholders would be bene cial. 4
Extracting the requirements for a general, tool-supported prioritisation DM process In this section, we use the previous model to extract the main general concepts involved in prioritisation DM processes. We then introduce a general, toolsupported prioritisation DM process based on these concepts.
Figure 3 depicts a class diagram containing the main concepts involved in the prioritisation DM process. The top and bottom parts of the gure present the SEnerCon concepts, depicted as dotted rectangles, identi ed from the (\as-is") DM process. The middle-part of the gure contains the SW development and the prioritisation DM concepts, they are depicted as classes with associations.
The SEnerCon concepts are used to identify/match the counterparts in the prioritisation DM process. The prioritisation DM concepts allow designers to know the requirements to implement a tool that supports this DM process. We also present a matching of concepts between the software development and the prioritisation DM. This matching allows managers to know the sources of setting inputs to con gure the prioritisation DM process.
In the SW development, on one side, an organisation (e.g. SEnerCon ) develops software products (e.g. the iESA software application) using a software development process. This process is composed of a set of phases, each development phase a ects software artefacts (e.g. requests, i.e., new features and bug reports). On the other side, an organisation contains roles (e.g. developers, projects managers, product manager ) which are played by stakeholders (concrete people) inside or outside the organisation, the stakeholders could have di erent in uences (e.g. derived from their expertises ). Finally, an organisation contains some policies or rules that manage/guide the decision processes (e.g. attributes to take into account when a decision is taken).
In the prioritisation DM, when a software artefact requires a prioritisation, it becomes feature in the prioritisation DM process. Then, a subset of stakeholders (see SW development), who are a ected by the decision, become decision makers. A stakeholder becomes negotiator to solve the potential con icts in the process. Decision makers express preferences on features according to some criteria, the criteria are derived from policies of the organisation (see SW development). Decision makers could have di erent powers of decision per criterion that can alter the nal decision. These powers are derived from the in uences and roles played by decision-makers (see SW development). Finally, methods are used to determine the list of prioritised features.
Concerning SEnerCon , three kind of stakeholders are involved in the prioritisation DM process: developers, project managers and the product manager. In case of con icts concerning the priorities of features expressed by the various stakeholders, the product manager acts as negotiator to solve these con icts. The criteria used in this process are provided as types of attributes. The preferences are expressed as attributes to support the features. Currently, attributes provided by decision makers depend on their roles, e.g. developers provided attributes related to implementation whilst project managers related to the management. Thus, the power of decision per criterion is derived from the roles played by decision makers. Finally, the methods used to determine the list of prioritised features are tables, manual inspection and negotiation meetings.
Based on the previously discussed prioritisation concepts and the proposal by
Ruhe et al. [
Ruhe et al [
The aforementioned works help us understand the main concepts, issues and challenges related to the prioritisation DM process. In this paper, we build on these concepts and propose a methodology to elicit the information involved in such processes in the context of real industrial use cases. 6
In this paper, we presented a structured approach to elicit and model prioritisation DM processes. The elicited information was used to derive the main concepts required for the implementation of a general, tool-supported prioritisation DM process. Speci cally, we presented (i) a methodology to elicit prioritisation DM processes, (ii) the application of the methodology to industrial use cases, (iii) the derivation of the main general concepts involved in the prioritisation DM process, and (iv) the identi cation of a general, tool-supported DM process. In conclusion, this paper can be useful as a guideline for companies that wish to explore and implement their own prioritisation DM processes.
Acknowledgement. The research described in the paper was funded by the EU project SUPERSEDE (grant agreement no 644018).