Mohamad Gharib
email: gharib@disi.unitn.it

Paolo Giorgini
email: paolo.giorgini@disi.unitn.it

Analyzing Trust Requirements in Socio-technical Systems: A Belief-based Approach

Keywords: Trust analysis, Beliefs, Requirements Engineering

The Requirements Engineering (RE) community recognizes the importance of trust proposing several approaches to model and analyze trust requirements. However, such approaches mainly focus on trust as social relations without relating them to the requirements of the system's components. We propose a belief-based trust approach based on an extended version of Secure Tropos, where social relations are modeled and analyzed along with beliefs concerning capabilities and motivations of system's components. An example concerning US stock market crash (the Flash Crash) is used to illustrate our approach.

Introduction

Trust is very important in human societies [START_REF] Sabater | Review on computational trust and reputation models[END_REF], so it is in Socio-Technical Systems (STS) [START_REF] Emery | Socio-technical systems[END_REF], where organizations and humans are an integral part of the system. Vulnerabilities of a STS are not only originated by technical issues, but they can be directly related to the social interactions of its components (both social and technical actors). For example, the Flash Crash was not caused by a mere technical failure, but it was due to undetected vulnerabilities in the interactions of the STS [START_REF] Sommerville | Large-scale complex IT systems[END_REF]. In [START_REF] Gharib | Detecting conflicts in information quality requirements: the May 6, 2010 flash crash[END_REF], we showed how STS vulnerabilities can be avoided when trust requirements are considered properly during the system design.

The RE community recognizes the importance of trust, proposing several approaches for modeling trust requirements (e.g., Secure Tropos [START_REF] Mouratidis | Secure Tropos: A security-oriented extension of the Tropos methodology[END_REF], SI* [START_REF] Zannone | A requirements engineering methodology for trust, security, and privacy[END_REF], etc.). However, none of them proposes to analyze trust starting from the perspective of socio-technical components of the system. More specifically, local objectives, competencies, motivations, etc. should be considered as main drivers for the definition of the trust requirements. One main contribution of this paper is enriching trust requirements analysis during the early phase of the system development by acquiring information about each socio-technical component (actor) and using such information to derive trust requirements.

To this end, we propose a belief-based trust approach built on an extended version of Secure Tropos [START_REF] Gharib | Modeling and reasoning about information quality requirements[END_REF], where a set of beliefs related to actors' competencies (can do) and motivations (will do) are used to clearly identify "why" an actor may trust/distrust another one. The proposed framework is fully supported by a CASE Tool, and it offers a methodological process to assist analysts during the different phases of the system analysis, along with several reasoning techniques that support the verification of the correctness and consistency of the requirements model. The rest of the paper is organized as follows; Section (2) describes the research baseline, and we discuss an example concerning the stock market system in Section [START_REF] Asnar | From trust to dependability through risk analysis[END_REF]. We detail our approach in Section (4), and we implement and evaluate it in Section [START_REF] Amit K Chopra | Sociotechnical trust: an architectural approach[END_REF]. Related work is presented in Section [START_REF] Chopra | Trust in electronic environments[END_REF], and we conclude the paper and discuss the future work in Section [START_REF] Emery | Socio-technical systems[END_REF].

Research Baseline

Our research baseline is founded on three main research areas:

(1) Goal Oriented Requirement Engineering (GORE): GORE is used to express the system requirements in terms of the actors of the system along with their objectives, entitlements, and capabilities. Among the existing GORE approaches (e.g., SI* [START_REF] Mouratidis | Secure Tropos: A security-oriented extension of the Tropos methodology[END_REF], Secure Tropos [START_REF] Zannone | A requirements engineering methodology for trust, security, and privacy[END_REF], etc.), we adopt an extended version of Secure Tropos [START_REF] Gharib | Modeling and reasoning about information quality requirements[END_REF] as a baseline for our approach. In which, an actor covers two concepts a role and an agent, where roles can be specialized from one another (is a), and an agent can play a role or more. Goals can be refined through And/Or decomposition of a root goal into sub-goals, where a goal is achieved if all of its (And-decomposition) or any of its (Or-decomposition) sub-goals are/is achieved. Goals may produce and read information. Finally, it provides concepts for modeling information provision and goals delegation among actors, and it adopts the notion of trust to capture the expectation of actors in one another.

(2) Belief-Desire-Intention (BDI): the BDI paradigm [START_REF] Anand | Modeling rational agents within a BDIarchitecture[END_REF] enables for analyzing actors of the system in terms of their beliefs, desires, and intentions. In BDI an agent has a set of beliefs representing its knowledge about the world, desires (goals) it aims to achieve, and intentions (plans) that play an important role in determining their behavior to achieve their desires. The main reason for considering BDI paradigm is our need to capture beliefs about the actors' capabilities and motivations.

(3) Trust Management: there is general consensus that trust is complex and multidimensional concept [START_REF] Chopra | Trust in electronic environments[END_REF], which motivates several researchers to answer the challenging question "how can trust be constructed (built)?". However, Esfandiari and Chandrasekharan [START_REF] Esfandiari | On how agents make friends: Mechanisms for trust acquisition[END_REF] argued that constructing trust can be broadly classified under two main types: cognitive and mathematical, where in the first trust is made up of underlying beliefs (e.g., [START_REF] Abdul-Rahman | Supporting trust in virtual communities[END_REF][START_REF] Castelfranchi | Social trust: A cognitive approach[END_REF]), while in the last trust can be constructed based on some trust metrics (e.g., [START_REF] Stephen | Formalising trust as a computational concept[END_REF][START_REF] Schillo | Using trust for detecting deceitful agents in artificial societies[END_REF][START_REF] Esfandiari | On how agents make friends: Mechanisms for trust acquisition[END_REF]).

In particular, our approach adopts concepts from extended Secure Tropos [START_REF] Gharib | Modeling and reasoning about information quality requirements[END_REF] to model the system requirements in terms of the actors of the system along with their objectives, entitlements, and capabilities. However, this framework does not propose techniques for modeling nor analyzing trust requirements based on actors' capabilities and motivations. Thus, we rely on the BDI paradigm to capture actors' capabilities and motivations through their related beliefs. While, we depend on trust management to understand how different scholars have analyzed/constructed trust.

A Stock Market System Example

Our example concerns the Flash Crash, in which the Dow Jones Industrial Average (DJIA) dropped about 1000 points (about 9% of its value). Several stakeholders of the stock market system can be identified based on [START_REF] Kirilenko | The Flash Crash: The impact of high frequency trading on an electronic market[END_REF], including: stock investors are individuals or companies, who have a main goal "Make profit from trading securities".

Stock traders are individuals or companies involved in trading securities in stock markets either for their own sake or on behalf of their investors with a main goal "Make profit by trading securities". Stock traders can be broadly classified under: Market makers: traders who facilitate trading on particular security and they have the capability of trading large amount of securities; High-Frequency Traders (HFTs): traders who have the capability to trade large amount of securities with very high frequency; and small traders: traders who trade small amount of securities with low trading frequency.

Stock markets are places where traders gather and trade securities (e.g., NAS-DAQ, CME, NYSE, etc.), and they have a main goal "Make profit by facilitate security trading". Furthermore, accounting firms are specialized for providing companies with reliable information about their economic activities and the status of their assets. Moreover, auditing firms are specialized for monitoring the quality of the financial statements produced by companies. Consulting firms are specialized for providing professional advices for a fee about securities to traders and investors. Finally, credit assessment ratings firms are specialized for assessing of the credit worthiness of companies' securities.

Figure 1 shows a partial goal model of the stock market to clarify the modeling language main constructs, in which Fast trading is an agent that plays the HFT role, which is specialized from the stock trader role. A stock trader has a main goal Make profit by trading security that is Anddecomposed into Analyze the market for targeted securities and Make profit by producing the right orders, which reads Investor's orders and produces Trader's orders. A market depends on trader for the provision of Trader's orders, and a trust relation concerning such provision exist. Space Co delegates Manage company's auditing operations to Account and audit Co, and a trust relation concerning such delegation exist.

Extended Secure Tropos [START_REF] Gharib | Modeling and reasoning about information quality requirements[END_REF] is able to capture the functional and trust requirements of the system in their organizational context. However, unlike functional requirements, which are supported with various kinds of analysis mechanisms that enable for deciding whether they can be achieved or not, trust analysis did not receive such an attention. For example, in order to ensure stable trading environment, a trust relation should hold between the stock market and stock traders concerning the trading orders they provide. However, there is no existing technique that enables for analyzing trust relations based on the traders' capabilities and motivations, which form the bases of such trust, i.e., we cannot decide if such trust requirement is not conflicting with the traders' goals, intentions, etc.

A Belief-based Approach for Analyzing Trust

Our approach proposes to model and analyze trust requirements among actors strictly from sets of beliefs concerning their capabilities and motivations. In particular, an actor (trustor) may trust/distrust another one (trustee) based on beliefs related to trustee's competencies and motivations. In this section, we detail our belief-based trust approach. First, we discuss our modeling extensions that enable for analyzing trust based on actors' competencies and motivations related beliefs, and then we describe the automated reasoning support that can be used to verify the correctness and consistency of the trust requirements model. Finally, we outline the methodological process that underlies our approach.

Extended Modeling Language for Analyzing Trust Requirements

The need for trust arises when actors depend on one another either for goals to be achieved or information to be provided1 , since such dependencies might entails risk (threat) [START_REF] Chopra | Trust in electronic environments[END_REF]. Following [START_REF] Castelfranchi | Social trust: A cognitive approach[END_REF], to analyze trust we need to identify beliefs related to the trustee's competencies and motivations toward the trustum (e.g., goal achievement or information provision). However, relying only on the trustee's competencies and motivations toward the trustum might not be enough; indeed, other factors might influence the trustee's behavior. In particular, actors are intentional entities and they might have other objective(s) that its/their achievement might threaten/prevent the achievement of the trustum. We call such objectives as intentional threat [START_REF] Van Lamsweerde | Elaborating security requirements by construction of intentional anti-models[END_REF] (threat for short), since they exists only within the actors' objectives.

In addition, we classify actor's competencies toward fulfilling2 a trustum/threat under: (1) Competence, when there is belief(s) about its capability toward fulfilling the trustum/threat; and (2) Incompetence, when there is belief(s) about its incapability toward fulfilling the trustum/threat. While actor's motivations can be classified under: (1) Positively motivated, when there is belief(s) about its intentions toward fulfilling the trustum/threat; and (2) Negatively motivated, when there is belief(s) about its negative intentions toward fulfilling the trustum/threat. To this end, trust can be analyzed in the trustee from the perspective of the trustor, when there is no trustum related threat as follows:

Definition 1. Let a and b be two actors, and s be a trustum (e.g., a goal g or information i) that a aims for. Moreover, C and M are two sets of beliefs that a has about the capabilities and motivations of b, respectively. We say that a trusts b for fulfilling s

, IFF ∃ c 1 ∈ C, ∃ m 1 ∈ M | competence(fulfill, a, b, s) ∧ positively motivated(fulfill, a, b, s), and c 2 ∈ C, m 2 ∈ M | incompetence(fulfill, a, b, s) ∨ negatively motivated(fulfill, a, b, s), i.

e., a has only beliefs concerning the competency and positive motivation of b toward fulfilling s.

For example, in Figure 1 a trust relation between the Space Co and Account and audit Co for fulfilling "Manage company's auditing operations" holds, if Space Co has beliefs about the competency and positive motivations of the Account and audit Co, and there is no beliefs concerning neither its incompetency nor negative motivations toward fulfilling the goal.

While if there is a trustum related threat(s), an integrated analysis of trust and its related threat(s) is required, i.e., we also need to determine whether the trustee is competence and positively motivated toward fulfilling the related threat(s) or not, and consider such knowledge while analyzing trust. In what follows, first we define a threat to trustum, and then we show how trust in the trustee can be analyzed when there is a trustum related threat(s). Definition 2. Let s be a trustum and t is a threat, we say that t is a threat to s, IFF the fulfillment of t threaten the fulfillment of s.

For example, the Space Co can define "Biasing the audit information" as a threat to the goal "Manage company's auditing operation", where fulfilling such threat can threaten the fulfillment of the goal. Similarly, a stock market can define "Manipulate the market by providing falsified/fraud orders" as a threat to "trader's orders" information. After defining trustum related threat, we can enrich the trust analysis by considering the effect of such threat(s) over the trust relation as follows: Definition 3. Let a and b be actors, s is a trustum that a aims for, t is a threat of s, and a depends on b for fulfilling s. We say that a distrust b for fulfilling s, IF a has beliefs concerning the competencies and positive motivations of b toward fulfilling t.

For example, in Figure 1 Space Co distrusts Account and audit Co for fulfilling "Manage company's auditing operations", if it has beliefs concerning the competencies and positive motivations of Account and audit Co toward achieving the trustum related threat "Biasing the audit information". Similarly, the stock market distrusts a stock trader for providing "trader's orders", if it has beliefs concerning the competencies and positive motivations of the trader toward fulfilling the trustum related threat "Manipulate the market by providing falsified/fraud orders". Threat and threaten constructs are shown in Figure 2.

Capture Actors' Competencies and Motivations Beliefs. Several belief sources can be used, Sabater and Sierra [START_REF] Sabater | Review on computational trust and reputation models[END_REF] identify three main sources of beliefs, namely: direct experiences, witness information, and sociological information. We mainly rely on sociological information that is information describes the social relations between agents and the roles they are playing in the society [START_REF] Sabater | Review on computational trust and reputation models[END_REF]. In particular, agents' capabilities can be derived from the role(s) they play, where roles' capabilities are predefined based on their different characterization in the society. Formally, this can be defined as follows: Definition 4. Let a be an agent, r is a role, s is a trustum, and t is a threat. We say that a is capable of fulfilling s/t, IFF a plays a role r that has the capability of fulfilling s/t. Otherwise, we say a is incapable of fulfilling s/t.

Based on [START_REF] Kirilenko | The Flash Crash: The impact of high frequency trading on an electronic market[END_REF], in order to fulfill the threat "Manipulate the market by providing falsified/fraud orders", a stock trader has to be capable of trading with very high frequency (e.g., HFT ), or it has to be capable of trading very large amount of securities (e.g., Market Maker ), where such activities of HFTs and Market Makers were considered as a main reason of the Flash Crash. Actor's capability/incapability toward fulfilling a threat is modeled as edges between actors and threats labeled with cap/icap respectively (Figure 2).

At the other hand, actors' motivations toward fulfilling a trustum/threat can be derived from the different interrelations among the actors own objectives and the trustum/threat, which can be captured by relying on the qualitative goal Fig. 2. A partial goal model of the stock market extended with belief-based constructs relationships [START_REF] Giorgini | Reasoning with goal models[END_REF], in which a goal can contribute positively or negatively towards the achievement of another one. In particular, an actor is positively motivated to fulfill a trustum/threat, if such trustum/threat contributes positively to at least one of its own goals. Similarly, an actor is negatively motivated to fulfill a trustum/threat, if such trustum/threat contributes negatively to at least one of its goals. Formally, this can be defined as follows:

Definition 5. Let a, b be actors, s is a trustum, t is a threat, and g is a goal that b aims to achieve. We say that a beliefs that b is positively motivated to fulfill s/t, IFF s/t contributes positively to g. And we say that a beliefs that b is negatively motivated to fulfill s/t, IFF s/t contributes negatively to g.

For example, Space Co delegates its goal "Manage company's auditing operations" to Account and audit Co that plays an auditing firm, which is capable of fulfilling the threat ("Biasing the audit information"), yet it does not have positive motivation towards fulfilling it. However, Account and audit Co plays another role that is accounting firm, which makes it positively motivated to fulfill the trustum related threat by several reasons (e.g., provides accounting services to a competing company, etc.). Positive and negative contribution among goals is modeled as edges labeled with ++ and --respectively (Figure 2).

Trust and Distrust Analysis. Previously, we have discussed how actors' competencies and motivations beliefs can be derived. Here, we show how these beliefs can be used to support trust analysis (shown in Table 1).

Trust: an actor trusts another one for a specific trustum, if it has belief(s) about the trustee's competency and positive motivations toward fulfilling the trustum, and it does not have belief(s) about the trustee's incompetency neither negative motivations toward fulfilling the trustum. Moreover, a trustor should have belief(s) about the trustee's incompetence to fulfill the trustum related threat (if any). For example in Figure 2, a stock market trusts Pro trading for

Trustum Beliefs Threat Beliefs Competence Motivation Competence Motivation

Comp Incomp Positive Negative Comp Incomp Positive Negative Trust X X X - - Distrust X - - - - - - - - X - - - - - - - - X X
"trader's orders", since Pro trading has the competencies and it is positively motivated to provide them, and it is incompetent for fulfilling the related threat.

Distrust: an actor distrusts another one for a specific trustum, (1) if it does not have belief(s) about the trustee's competency toward the trustum, and has belief(s) about the trustee's incompetency; (2) if it does not have belief(s) about the positive motivations of the trustee toward the trustum, and it has belief(s) about its negative motivations; and (3) if it has belief(s) about the trustee's competency and positive motivations toward fulfilling the trustum related threat, and it does not have belief(s) about the trustee's incompetency and negative motivations toward fulfilling the threat. For example, in Figure 2 Sarah distrusts the stock trader for fulfilling "Make profit from trading securities", since the trader might be negatively motivated to fulfill a goal that contributes negatively to one of its own goals. While a stock market distrusts both Fast trading and Secure trading for "trader's orders", since both of them have the capability and they are positively motivated toward fulfilling the trustum related threat "Manipulate the market by providing falsified/fraud orders".

Compensating the Lack of Trust. We propose two techniques to compensate the lack of trust (distrust):

Adopting can be defined as a commitment from the trustee toward the trustor that the first will behave as expected from the last toward the trustum [START_REF] Castelfranchi | Social trust: A cognitive approach[END_REF]. We use adopting when the lacks of trust is due to belief(s) about the trustee's negative motivations toward fulfilling the trustum. For example, Sarah can compensate the lacks of trust in a stock trader concerning the goal "Make profit from trading securities" by adoption, i.e., stock trader commits to Sarah to fulfill the goal as expected. Adopting is modeled as an edge labeled with A between the trustor and trustee at one hand, and the trustum at the other (Figure 2).

Monitoring can be defined as the process of observing and analyzing the performance of an actor in order to detect any undesirable performance [START_REF] Zannone | A requirements engineering methodology for trust, security, and privacy[END_REF]. We use monitoring when the lacks of trust is due to belief(s) about the trustee's competencies and positive motivations toward fulfilling the trusum related threat. For example, a stock market should monitor the "trader's orders" that are provided by both Fast trading and Secure trading to compensate the distrust in them concerning the orders they provide. Monitoring is modeled as an edge labeled with M between the trustor and trustee at one hand, and the trustum at the other (Figure 2).

Table 2. Properties of the design

Pro1 :aims(A,G), not achieved(A,G) Pro2 :-deleChain(A,B,G), not trustChain(trust,A,B,achieve,G) Pro3 :-deleChain( ,A,G), can achieve(B,G), not can achieve(A,G), not deleChain(A,B,G) Pro4 :needs(A,I), not has(A,I) Pro5 :-prvChain( ,A,I), needs(B,I), not needs(A,I), not prvChain(A,B,I) Pro6 :need(G,I), is responsible(A,G), not trusted(A,I) Pro7 :-trustReq(Type,A,B,O,S), not trust(Type,A,B,O,S) Pro8 :motivation belief(pos,A,B,achieve,G), motivation belief(neg,A,B,achieve,G) Pro9 :motivation belief(pos,A,B,achieve,G), adopt(A,B,achieve,G) Pro10 :monitor(A,B,S,O), not trust threat(A,B,S,O)

Model Analysis and Verification

In order to enable the automated reasoning support, we used disjunctive Datalog [START_REF] Alviano | The disjunctive Datalog system dlv[END_REF] to formalize all the concepts that have been introduced in the paper, along with the required reasoning axioms 3 . Moreover, we defined a set of properties (shown in Table 2) that can be used to verify the trust requirements model, i.e., the model is correct and consistent, if all of these proprieties hold.

Pro1: states that the model should not include any goal that is not achieved from the perspective of the actor, who aims for it. We rely on this property to quickly verify the requirements model, i.e., if this property holds for all goals, we can conclude that the model is correctness and consistency.

Pro2 states that the model should not include any goal delegation/delegation chain, if there is no trust/trust chain between the delegator and the delegatee, or there is at least a compensation of the lack of trust among them. This property aims to detect any delegation with no trust, since such delegation leaves the delegator with no guarantee that its goal will be achieved. For example, in Figure 1 if the trust relation did not hold between the Space Co and Account and Audit Co concerning the goal "Manage company's auditing operations", Pro2 will be able to detect such violation.

Pro3 states that goals should be delegated only to actors, who have the capability to achieve them either by themselves or they have valid delegation to an actor who has such capability. For example, in Figure 1 if Space Co delegates the goal "Manage company's auditing operations" to Star Co, which does not play the role of "Auditing firm", and it does not has a valid delegation to an actor that plays such role, Pro3 is able to detect such false delegation.

Pro4 states that actors should have all information that is required for the achievement of the goals they are responsible of, i.e., this property is specialized for detecting information unavailability related issues. Capturing information availability is not always an easy task, since goals might be interdependent on one another for information, and if a goal that produces information was not achieved (prevented), all goals that depend on its information will be prevented as well. For example, in Figure 1 if the stock trader's goal "Internal analysis of targeted securities" was not achieved due to unavailability of "securities' assessments" or "financial statements" information, it will not produce "trader suggestions" that is required by both goals "Make profit by producing the right orders" and "Analysis depending on trader", i.e., both of them will not be achieved as well.

Pro5 states that information should be only provided to actors, who require them either for achieving their goals, or they have valid provision chain to an actor who requires them. For example, in Figure 1 if "consulter suggestion" was provided to any actor but the stock trader or stock investor (e.g., stock market), Pro5 will detect such violation and notify the analyst about it.

Pro6 states that the model should not include any untrusted information provision from the perspective of its reader. In other words, there is no guarantee that information is trusted for read if no trust/trust chain holds between information reader and producer or there is a compensation of the lack of trust among them. For example, in Figure 2 trust will not hold between Fast trading and Secure trading at one hand and the stock market at the other concerning the provision of "Trader's orders". If such provision was not accompanied with a trust compensation mechanism (monitoring), Pro6 will be able to detect such situation and notify the analyst about it.

Pro7 states that the model should not include any trust/distrust relation that conflicts with the trustee's competencies and motivations. For example, in Figure 2 if the provision of "Trader's orders" between Fast trading and stock market was modeled as trust, Pro7 will notify the analyst that such trust relation is conflicting with the competencies and motivations of Fast trading toward the trustum and its related threat, i.e., it should be modeled as distrust. Similarly, if the provision of "Trader's orders" between Pro trading and stock market was modeled as distrust, Pro7 will detect such situation and notify the analyst that it should be modeled as trust, since such distrust is conflicting with the capabilities and motivations of Pro trading toward the trustum and its related threat.

Pro8 states that the model should not include actors with conflicting motivational beliefs (positively and negatively motivated) toward the same trustum/threat. We avoid having such situation, since our reasoning do not provide techniques for motivations conflict resolution yet.

Pro9 states that the model should not include an adoption relation between a trustor and a trustee, if the first beliefs that the last is positively motivated to fulfill the trustum. For example, if Space Co delegates its goal "Manage company's auditing operations" to an auditing firms, and there is also an adopting relation concerning the delegation, Pro9 will notify the analyst that such adoption relation is not required, since there is no beliefs concerning the negative motivations of the auditing firms toward fulfilling the delegated goal.

Pro10 states that the model should not include a monitoring relation between a trustor and a trustee, if the last cannot be considered as a possible threat source for the trustum. For example, if the model has a monitoring relation concerning "trader's orders" that are provided from a small trader to stock market, Pro10 is able to detect such situation and notify the analyst that such monitoring relation is not required.

Methodological Process for Analyzing Trust Requirements

Our approach is equipped with an engineering methodological process (shown in Figure 3) that is specialized for modeling and analyzing trust requirements. The process consists of two main phases; we describe them as follows:

(1) Modeling Phase: this phase aims to model the requirements of the system with special emphasis on the trust requirements; and it is composed of six steps: (1.1) Actors modeling: in which the stakeholders of the system are identified and modeled in terms of agents and roles along with their objectives, entitlements and capabilities; (1.2) Goals modeling: the stockholders' top-level goals are modeled and refined (if needed) through And/Or-decomposition until reaching their leaf goals, which might leads to new iteration of this step;

(1.3) Information modeling: in which the different relations between goals and information are modeled (e.g., produce, read, etc.); and (1.4) Social interactions modeling: aims to model the different social dependencies among actors concerning information provisions and goal delegation. In other words, based on actors' capabilities some goals might be delegated to actors, who have the capabilities to achieve them; and based on actors' needs, information is provided to them.

After step 4, the model is checked and if it needs to be refined (e.g., adding new actors, refining some goal, etc.), we restart the modeling phase again; otherwise we proceed to the next step. (1.5) Trust modeling: trust requirements among actors concerning both goal delegation and information provisions are modeled at this step; (1.6) Beliefs modeling: aims to model threats, goals contributions, and the actors' competencies and motivations beliefs toward such threats. After finishing this step, the designer proceeds to the analysis phase.

(2) Analysis Phase: the aim of this phase is to support the verification of correctness and consistency of the requirements model. In particular, we define a set of properties of the design that helps in identifying any inconsistency or conflict in the model and notify the designer about them to find proper solutions. After the analysis phase the model is check, and the process reaches its end if the model is verified, otherwise the process restart again from the beginning to address the conflicts/inconsistencies in the model that have been identified (detected) during the analysis phase.

Implementation and Evaluation

Evaluation is an important aspect of any research proposal, and it aims to demonstrate the utility and efficacy of a design artifact. To this end, we evaluated our approach on a simulation basis following [START_REF] Hevner | Design science in information systems research[END_REF], by developing a prototype tool and test its applicability with artificial data. In particular, we developed IQ-Tool4 (a screenshot of IQ-Tool is shown in Figure 4) that is a prototype tool of our framework to test its applicability and effectiveness for modeling and analyzing trust requirements. In what follows, we briefly describe the tool, discuss its applicability and effectiveness over the Flash Crash case study, and then we discuss the scalability experiments we performed. Finally, we theoretically evaluate our proposed modeling language based on the semiotic clarity principle.

Implementation: the tool consist of three main parts: (1) A Graphical User Interface (GUI) that enables for drawing the requirements model by drag-anddrop modeling elements from different palettes; (2) Model-to-text transformation mechanism that supports the translating of the graphical models into disjunctive Datalog formal specifications; and (3) automated reasoning support (DLV system5 ) takes the disjunctive Datalog specifications along with already defined reasoning axioms as an input, and then perform the required analysis to verify the trust requirements model against the properties of the design.

Applicability: to test the framework applicability, we modeled the Flash Crash case study, transformed it into disjunctive Datalog specifications, and then we run the automated analysis to test its ability in discovering violations to the properties of the design. The analysis returned several violations, including: a stock market considers orders received from any agent that plays either HFTs or Market makers roles as untrusted information, which we solved by monitoring the trustee. Space Co distrusts Account and audit Co for achieving the goal "manage company's auditing operation", which we solved by compensating the lack of trust by adopting. Moreover, the analysis detects all situations where agents became negatively motivated to fulfill a trustum, and when they became positively motivated to fulfill a threat when they play several roles that may Consulting firm roles, which influences the trust in it concerning information it produces (e.g., consulter suggestions and securities assessments). In particular, the proposed analysis techniques were able to capture all the violations to the properties of the design that we consider in this paper, which enable in turn to avoid the different vulnerabilities in the system design that led or contributed to the Flash Crash and resolve them during the early requirements phase.

Experiments on Scalability: to test the scalability of the reasoning technique, we expanded the model shown in Figure 1 by increasing the number of its modeling elements from 122 to 1716 through six steps, and we investigated the reasoning execution time at each step by repeating the reasoning execution seven times, discarding the fastest and slowest ones, and then computed the average execution time of the rest. The result is shown in Figure 5, and it is clear that the relation between the size of the model and execution time is not exponential. We have performed the experiment on laptop computer, Intel(R) core(TM) i3-3227U CPU@ 190 GHz, 4GB RAM, OS Window 8, 64-bit.

Theoretical Evaluation we evaluated our modeling language according to the principle of semiotic clarity [START_REF] Daniel | The physics of notations: toward a scientific basis for constructing visual notations in software engineering[END_REF], which helps in increasing the expressiveness and precision of the language. In this principle there should be a one-to-one mapping between semantic concepts and their corresponding constructs (Figure 6), i.e., there should be no incompleteness, overload, redundancy, or under-definition between the semantic concepts and their corresponding language constructs. Incompleteness: occurs when a semantic concept is not represented by any modeling construct. We have only one case, we did not model the actor capability/incapability toward goals as we did for threats. However, symbol incompleteness is not necessarily a bad thing, since representing only the required concepts helps in keeping the language complexity manageable [START_REF] Daniel | The physics of notations: toward a scientific basis for constructing visual notations in software engineering[END_REF]. Redundancy: occurs when multiple modeling constructs represent a single semantic concept. We did not observe any symbol redundancy in the language. Overload: occurs when a single modeling construct is used to represent multiple semantic concepts. We have the positive/negative contributions among goals and goals/threats, which can be considered as an overload. However, actors can differentiate between them easily based on the context. Moreover, we only represented actor's capability toward threats, and omitted representing its capability toward goals in order to avoid an overload. Under-definition: occurs when a modeling construct does not represent any semantic concept. There are no under-definition issues in the language.

Related Work

A large body of literature has focused on how trust can be constructed (built).

For instance, Marsh [START_REF] Stephen | Formalising trust as a computational concept[END_REF] proposes one of the earliest trust models that consider direct interaction as a main source of trust related beliefs. Schillo et al. [START_REF] Schillo | Using trust for detecting deceitful agents in artificial societies[END_REF] introduce a trust model based on probability theory, which can be used when trust among agents has a Boolean value (good or bad). While in [START_REF] Abdul-Rahman | Supporting trust in virtual communities[END_REF], trust can be build based on agents' beliefs in one another concerning their experience and reputation, and the degrees of trust range from complete distrust to complete trust. Esfandiary and Chandrasekharan [START_REF] Esfandiari | On how agents make friends: Mechanisms for trust acquisition[END_REF] propose a cognitive based trust and reputation model. In which, trust can be built based on observation and interaction. Finally, Castelfranchi and Falcone [START_REF] Castelfranchi | Social trust: A cognitive approach[END_REF] propose a cognitive trust model, in which different types of beliefs can be used to build trust. Although most of these works propose techniques for constructing trust, but they do not offer concepts or constructs for modeling or reasoning about trust requirements. At the other hand, trust is still a new research thread within the RE community. However, several RE approaches suggested concepts for modeling trust. For instance, in [START_REF] Giorgini | Filling the gap between requirements engineering and public key/trust management infrastructures[END_REF] they focus on capturing trust at the level of roles. While in [START_REF] Giorgini | Modeling social and individual trust in requirements engineering methodologies[END_REF], they capture trust at two different levels (roles and agents), and they highlighted the problem that may arise when a trusted role is played by an untrusted individual (agent). In [START_REF] Zannone | A requirements engineering methodology for trust, security, and privacy[END_REF] trust was introduced as a fundamental aspect for making decisions on security. While Asnar et al. [START_REF] Asnar | From trust to dependability through risk analysis[END_REF] introduce the notion of trust for assessing risk. Finally, Chopra et al. [START_REF] Amit K Chopra | Sociotechnical trust: an architectural approach[END_REF] introduce architectural trust that can be used to assist the trustworthiness of the overall STS. Although, most of these works propose constructs for modeling trust requirements, but none of them consider actors' competencies (capabilities), motivations, etc. as main drivers while analyzing trust requirements, i.e., they do not provide a specialized concepts nor constructs for modeling and analyzing trust requirements based on actors' competencies and motivations.

Conclusion and Future Work

We have proposed a belief-based trust approach that combines both cognitive and mathematical trust approaches, introducing concepts and constructs for modeling and analyzing trust based on sets of beliefs related to the actors' competencies and motivations toward the trustum and its related threat(s) (if any). Moreover, we have discussed the automated reasoning techniques our framework offers, and how they can be used to verify the correctness and consistency of the trust requirements model. In addition, we described the methodological process underlies our approach should be followed by designers/analysts during the system design. We evaluated our approach on a simulation basis by developing a prototype tool and test its applicability and effectiveness for modeling and analyzing trust requirements. Finally, we theoretically evaluated our proposed modeling language based on the semiotic clarity principle.

For the future work, we are exploring how to extend our approach by adding new types of beliefs that might influence the trust among actors. Moreover, we aim to enrich our approach with mechanisms to combine different kinds of beliefs while analyzing trust, and also with mechanisms for conflict resolution among different kinds of beliefs. Furthermore, we are planning to evaluate our approach with end users (e.g., designers, analysts, experts, etc.) to assess its adequacy for modeling and reasoning about trust requirements. Finally, we aim to better validate the approach by applying it to several complex case studies that belong to different domains.

Fig. 1 .

 1 Fig. 1. A partial goal model concerning the U.S stock market structure

  by providing by provide falsified/ fraud [Trader' orders]

Fig. 3 .

 3 Fig. 3. Methodological Process for Analyzing Trust Requirements

Fig. 4 .Fig. 5 .

 45 Fig. 4. Screenshot of the IQ-Tool 983 967 911 798 728 933

Fig. 6 .

 6 Fig. 6. Principle of semiotic clarity

Table 1 .

 1 Analyzing trust based on the related beliefs

We focus on the trustworthiness of the provided information, not information availability, i.e., whether information is provided or not

[START_REF] Alviano | The disjunctive Datalog system dlv[END_REF] Fulfilling is used to refer to achieving a goal/threat, or provision of information

The formalization of the concepts and axioms is omitted due to space limitation, yet it can be found at https://mohamadgharib.wordpress.com/bbta/

https://mohamadgharib.wordpress.com/bbta/

http://www.dlvsystem.com/dlv/

Acknowledgments. This research has received funding from the ERC advanced grant 267856, "Lucretius: Foundations for Software Evolution", http: //www.lucretius.eu/, and the European Unions Horizon 2020 research and innovation programme under grant agreement No 653642 -VisiOn.


Zia Babar
email: zia.babar@mail.utoronto.ca

Alexei Lapouchnian
email: alexei@cs.toronto.edu

Eric Yu
email: eric.yu@utoronto.ca

Modeling DevOps Deployment Choices Using Process Architecture Design Dimensions

Keywords: Enterprise Modeling, Software Processes, Business Process Modeling, DevOps, Goal Modeling, Adaptive Enterprise

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Enterprises are expected to continuously respond to ongoing changes and evolving environmental factors. Increasing competition and emergence of new market players from non-traditional sectors require enterprises to react and adapt to change more quickly than ever before [START_REF] Wilkinson | Designing an "adaptive" enterprise architecture[END_REF][START_REF]Organisational Agility: How Business can Survive and Thrive in Turbulent Times[END_REF]. To this end, more and more enterprises are relying on software for the development and delivery of appropriate products and services. As a result, software processes are becoming an integral part of enterprise processes. Just like business processes (BPs), software development processes can vary significantly from organization to organization due to unique enterprise characteristics; these processes can be reconfigured in multiple ways to take account of enterprise variations and behavioral peculiarities so as to fulfill high-level enterprise requirements. However, current methods of modeling software process reconfigurations are limited in their ability to consider multiple enterprise perspectives and help choose among alter-nate configurations. In this paper, we elaborate on the software process reconfigurations that are possible in the DevOps approach for the purpose of describing a Business Process Architecture (BPA) modeling technique, which allows the depiction and analysis of BP reconfigurations along multiple dimensions.

The term "DevOps" is a combination of two words "Development" and "Operations" and has been described and referred to as a phenomenon, a philosophy, a mindset, a set of techniques, a methodology, etc. DevOps is not a software tool or methodology per se, but rather an approach for rapidly and frequently delivering new software product features and service innovation. A recent Gartner news release predicted that "DevOps will evolve from a niche strategy employed by large cloud providers to a mainstream strategy employed by 25 percent of Global 2000 organizations" [START_REF] Gartner | DevOps Will Evolve From a Niche to a Mainstream Strategy Employed by 25 Percent of Global 2000 Organizations[END_REF]. Broadly speaking, DevOps attempts to introduce rapid delivery of product features, services and bug fixes to end-users through frequent release cycles, each containing a small feature set. Rapid delivery enables an enterprise to reduce the time-to-market for new products and features, provides greater customer centricity by introducing new features based on evolving customer needs, quickly resolves operational and support issues, and shows greater responsiveness to changing (internal and external) environment situations. DevOps enables the above by [START_REF] Erich | A mapping study on cooperation between information system development and operations[END_REF][START_REF] Bang | A grounded theory analysis of modern web applications: knowledge, skills, and abilities for DevOps[END_REF][START_REF] Lwakatare | Dimensions of DevOps[END_REF]:  Automating activities in the overall software development process through the introduction of software tools and custom development of scripts, thus shortening the time required for new feature development and bug fixes through reduction of manual effort. This enables software teams to deliver more frequent releases to customers and the user base.  Using feedback loops for continuously improving software development processes and development of product features through the monitoring and measurement of various software process and technical metrics. These metrics are then interpreted and utilized for overall process improvement.  Promoting a culture of collaboration and information sharing between multiple teams. The traditional approach of having organization silos with defined boundaries and handover points is discouraged, and team members are expected to collectively collaborate towards the attainment of enterprise objectives.

The above characteristics are not unique to DevOps, and indeed, are generally applicable to enterprises with respect to enterprise agility and enterprise digital transformation [START_REF] Smeds | DevOps: A Definition and Perceived Adoption Impediments[END_REF]. Looking at software processes can provide insights into a broader context, such as the development and evolution of new products and services, many of which are digitally enabled. A BPA needs to be understood through a combination of these ideas and concepts, particularly in light of enterprise requirement for greater responsiveness and adaptability, with DevOps being a suitable example for such a study. This paper is organized as follows. In Section 2, we introduce a DevOps-based motivating example that allows us to discuss the core concepts of this paper. In Section 3, we model a typical DevOps implementation using the BPA modeling technique and indicate possible areas and dimensions of software process variability. In Section 4, we refer to the related work, while in Section 5 we outline future directions of this research. Section 6 concludes this paper.

Motivating Example

DevOps is an interesting challenge for enterprise modeling for a number of reasons. As described above, DevOps involves diverse considerations from the viewpoints of process design, systems and tools development and deployment, and social and organizational issues. Continuous Integration (CI) and Continuous Deployment (CD) of product functionality and infrastructure setup are outcomes of DevOps [START_REF] Lwakatare | Dimensions of DevOps[END_REF]. The general area of continuous software engineering, CI and CD has been covered in both academic and industry literature with numerous published case studies [START_REF]Continuous Software Engineering[END_REF]. Through CD, "companies could benefit from even shorter feedback loops, more frequent customer feedback, and the ability to more accurately validate whether the functionality that is developed corresponds to customer needs and behaviors" [START_REF]Continuous Software Engineering[END_REF]. Studying all facets of the DevOps approach is thus best done through the enterprise modeling lens enabling a multi-perspective understanding of the various considerations.

Analyzing and deciding between various DevOps process reconfigurations can be done by considering enterprise objectives and benefits, which can be interpreted as functional requirements (FRs) and non-functional requirements (NFRs) from a process design perspective. The use of NFRs (represented by softgoals) in the requirements engineering discipline to evaluate and decide between variations and reconfigurations is well established [START_REF] Lapouchnian | Requirements-driven design and configuration management of business processes[END_REF]. Some of the NFRs, as present in a typical DevOps adoption, would be:

 Agility and Adaptability: Rapidly adapting to changing circumstances such as evolving customer behavior, regulatory environment, emerging technologies, etc.  Responsiveness: Quickly responding to user feedback and change requests in the form of new product features and bug fixes.  Speed and Frequency: Delivering new product features and bug fixes faster as well as having a high deployment frequency.  Efficiency: Improvement in software process execution by automating key process segments and increasing collaboration between team members for greater information flow.  Customizability: Being able to customize the behavior of the software development lifecycle based on changing contextual and situational needs.

Fig. 1 shows a simple BPMN [START_REF]Business Process Model and Notation[END_REF] process model indicating the primary participants and the major activities in a typical DevOps-inspired software process. We have developed this context by referencing published literature from multiple sources, such as [START_REF]Continuous Software Engineering[END_REF][START_REF] Ståhl | Modeling continuous integration practice differences in industry software development[END_REF][START_REF] Paasivaara | Using scrum in distributed agile development: A multiple case study[END_REF][START_REF] Fitzgerald | Continuous software engineering and beyond: trends and challenges[END_REF][START_REF] Schwaber | Agile software development with Scrum[END_REF], with the intention of highlighting how the various process activities in DevOps can be better configured to serve a variety of enterprise FRs and NFRs. In DevOps, the development of product features can be done using different development methodologies while adhering to different practices and policies specific to an enterprise adoption; in this context we assume the use of the Scrum project management methodology [START_REF] Schwaber | Agile software development with Scrum[END_REF]. However, this general DevOps context is not intended to be an exhaustive depiction of variations in DevOps adoption in an enterprise setting, but rather is meant to illustrate variability in software process configurations. We consider four scenarios of variable behavior in this contextual setting, which correspond to the numbered annotations in the BPMN diagram:

1. QA Testing: Any developed feature has to be functional tested before it goes through the CD process. This testing can be carried out by QA engineers in at least two ways: they can retrieve the committed code from the code repository and test it on a test environment, or alternatively, they can collaborate with the software engineer to quickly validate the functionality before the codebase is committed to the code repository. 2. Release Planning: The enterprise is assumed to have periodic and fixed release cycles of appropriate duration. A release planning activity is carried out at release initiation that results in a release backlog; this artifact is then used to plan out individual sprint iterations. Two of the possible alternatives are 1) the release backlog is produced once and remains static throughout the release duration and 2) the release backlog is revisited at the beginning of every sprint and "groomed" (i.e. reordered and re-estimated) based on on-going change in circumstances and priorities. 3. Automated Testing: In order to reduce product delivery durations, some product testing can be automated by developing test plans that are then scripted for execution as part of the CI process. The test scripts can be developed once and reused for subsequent CI activities or they can be developed every time to serve specific testing needs based on the product feature being tested. 4. Tool Usage for Automation: DevOps is characterized by the usage of third-party tools for CI and CD, server configuration, infrastructure provisioning, deployment management, etc. These tools are configured for use repeatedly without requiring the knowledge of their inner working. This is depicted in Fig. 1 as a separate Automation Engineer pool to visually differentiate it from the on-going DevOps Engineer activities.

The BPMN model in Fig. 1 allows a visual understanding of the sequencing of process activities and the flow of information between them. However, BPMN process modeling is lacking in terms of the selection and evaluation of alternative DevOps configurations. In any enterprise, there would exist multiple process levels, with processes at one level feeding into those at an upper level. The multiple levels of process-driven dynamics and the relationships between the process levels are not apparent in the BPMN model nor are boundaries between these process levels obvious. Multiple BPs may come together to provide some feature functionality (for example, the development of test plans and their execution are part of two separate BPs), but the nature of their relationship is not explicit in the model. While process activities can be shown, along with the changes in their sequencing, the implications of any activity reordering cannot be determined. Similarly, enterprises rely on sense-and-respond loops to continuously improve their operational processes [START_REF] Haeckel | Adaptive Enterprise: Creating and Leading Sense-And-Respond Organizations[END_REF]. While the BPMN model in Fig. 1 does show such feedback loops, the full range of attributes associated with them (for example, the multitude of timescales present in the loop or the execution frequency of the sensing and responding parts) are not evident.

Modeling Process Reconfigurations

The BPA modeling framework was introduced in [START_REF] Lapouchnian | Re-designing process architectures towards a framework of design dimensions[END_REF][START_REF] Lapouchnian | Towards Variability Design for Business Process Architecture[END_REF] for assisting with the modeling of BPs, their relationships, and the flexibility afforded by various BPA configurations. We use this framework to evaluate various DevOps reconfigurations and to choose among them. Fundamental concepts in the BPA framework are that of Process Element (PE), Variation Point (VP), Stage and Phase [START_REF] Lapouchnian | Re-designing process architectures towards a framework of design dimensions[END_REF].

 A PE is defined as "an activity that produces some output or outcome. It may also include the act of making decisions".  A VP is referred to "the point in a process where multiple options exist. Variation points may appear anywhere in a process".  PEs are grouped together in process Stages if they are executed together as part of the same execution cycle. A stage boundary exists between two stages and PEs can be moved across stage boundaries as required while considering different tradeoffs.  A stage may contain one or more Phases, which are sections of a stage that are the "portions of a process such that placing a PE under consideration anywhere within a phase produces the same result…However, moving PEs across phase boundaries may affect the quality of decisions and the outcome of actions".

A PE can be repositioned along four dimensions in any process architecture. These four dimensions include, (1) the temporal dimensionpositioning a PE either before or after other PEs (with respect to sequence of execution), ( 2) the recurrence dimensionpositioning a PE in a stage that is executed more frequently or less frequently compared to other stages, (3) the plan-execution dimensionpositioning a PE in a stage that either is responsible for planning or responsible for the execution of that plan, (4) the design-use dimensionpositioning a PE in a stage that either is responsible for designing a tool, capability or artifact, or responsible for using the output of that design stage. These dimensions are discussed in more detail in the subsequent sub-sections. Fig. 2 shows a BPA model for the DevOps approach with multitudes of process elements, stages, phases and the relationships among them. The model visualizes the key aspects of software development and operational support processes that are commonly present in the DevOps approach starting from the Product Management stage to the Operational Support stage. For the sake of comprehension and understandability, we conceptually divide the model into multiple sections and consider them individually with regards to the overall DevOps approach as follows:

 Product Management: Product FRs and NFRs are elicited and gathered from a variety of sources (such as User Input and Business Need) and consolidated together. This is then used to develop a Product Backlog, which is frequently groomed for estimating and prioritizing individual Product Backlog Items (PBIs).

The grooming exercise is a periodic process that runs at a higher recurrence than the requirements elicitation activity, which is denoted by the recurrence relationship between the two stages. is the breaking down of silos between the development and operational teams, thus fostering a culture of collaboration. The BPA models do not show process participants, so the collaborative aspect of DevOps is not visible. However, the Operational Support stage (along with the monitoring and measurement of operational metrics) is visually apparent, including the incorporation of software metrics into the product backlog (through a feedback loop) for ongoing software process lifecycle improvement.

The positioning of certain PEs in the DevOps approach are described in subsequent sub-sections along with the criteria for deciding among the options. Enterprises may want to analyze alternate positioning of PEs based on their FRs and NFRs. For this purpose, goal modeling can be used for representing the variations and helping select the appropriate alternative. NFRs are represented as softgoals and alternate methods of achieving a goal are represented as OR decompositions. Selection of a suitable alternative is made based on the positive and/or negative contribution(s) that the alternative would have on the NFRs (softgoals). The four scenarios described in the previous section (which also correspond to each of the four process architecture dimensions) are presented, with goal models shown alongside the BPA model snippets.

In all goal model examples, the root goal can be achieved through two alternate subgoals. The choices are limited to just two for brevity and space reasons. A real-world situation could contain many possible choices, as well as many competing and complementary NFRs. Also, the goals are shown at a PE level and decomposed down to just one level. In the general case, the goal model would start from enterprise-level goals, with multiple levels of goal refinement and alternatives until PE level sub-goals are reached [START_REF] Lapouchnian | Requirements-driven design and configuration management of business processes[END_REF].

The Temporal Dimension

The particular temporal placement of a PE can bring about certain benefits. A PE can either be advanced (and be executed) before other PEs or postponed after those PEs. Postponing a PE provides the benefit of executing it with the latest context and information available, thus reducing the risk and uncertainty that are inherent in any BP. The alternative is to advance the PE relative to other PEs, which reduces the complexity and cost as less effort is required to process the limited contextual information available at that instant. Uncertainty is also reduced. Therefore, the placement of any PE should be carefully considered with regards to various NFRs, subject to inherent temporal constraints among the PEs. The testing of a product feature by a QA engineer illustrates the trade-offs between advancing and postponing a PE (Fig. 3). The QA engineer can verify the developed feature (Perform QA Testing) after the software engineer checks in the code to the code repository (Commit Code Changes) or before the code is checked in by working directly with the software engineer. As shown by the goal model, the latter approach has the benefit of being collaborative in nature and encouraging both the software engineer and QA engineer to work together to solve the problem quickly. The former approach is more methodological and allows for the proper (and independent) validation of the feature and the tracking of testing issues. The appropriate order of the Perform QA Testing PE is determined based on the organization's prioritization between the softgoals.

The Recurrence Dimension

A recurrence relationship exists between the two stages of a process when the output of one stage can be used repeatedly (and without change) by the subsequent stage. A PE can be moved from a stage with a lower recurrence to one with a higher recurrence (and vice versa). Such a movement of the PE can change the non-functional properties of the BP in various ways. For example, reducing the PE recurrence saves cost as the same PE does not have to be executed repeatedly. Conversely, increasing the PE recurrence can assist with flexibility and adaptability as the PE is executed based on updated and current information.

In the DevOps approach, a product can be developed by having periodic and multiple product releases with many development sprints (within each release) required for attaining the release objectives (Fig. 4). Depending on the situation, an enterprise can create (Create Release Backlog) and groom a release backlog (Groom Release Backlog) once, which is then used for subsequent sprint planning. Alternatively, the enterprise can reassess the release objectives every time it starts a new sprint [START_REF] Fitzgerald | Continuous software engineering and beyond: trends and challenges[END_REF]. The former is a more methodological approach and ensures that the enterprise is aligned to what the release deliverable is going to be, whereas the latter enables the enterprise to adapt to changing priorities by constantly reviewing the release delivery items. The enterprise can decide to go with either approach based on NFRs such as methodicalness, stability, cost, adaptability, flexibility, etc., by moving the Groom Release Backlog between the Sprint Cycle and Release Planning stages.

The Plan-Execute Dimension

A BP can be considered to have two distinct segments, where one segment is responsible for creating a plan, which the other segment would then execute one or many times. Here, a plan-execute relationship exists between the two segments of the process. In the BPA modeling technique, each segment is modeled as a stage, with the stage producing the plan being the planning stage and the stage executing it being the execution stage. PEs can also be moved from an execution stage to a planning stage (and vice versa) based on the goal-driven analysis of their contribution to the relevant NFRs. Such movements create variations in the plan-execute behavior and allow either increased pre-planning (by moving a PE to the planning stage) or shifting more responsibility to the execution side (by moving a PE to the execution stage). Typically, testing plans are created (Create Testing Plan) for enabling automated testing. They are then coded up (Create Testing Scripts) in the form of testing scripts by the DevOps engineer and repeatedly executed (Execute Testing Scripts). As shown in Fig. 5, there are two possibilities with respect to the creation of the testing scripts. One is to create the testing scripts for every instance of automated testing so that the scripts are customized to the particular feature being tested (Create Testing Scripts PE is part of the Continuous Integration stage), whereas the other is to have a consistent and standard set of testing scripts that would allow testing coverage irrespective of particular product features being developed (Create Testing Scripts PE is part of the Testing Plan stage). The trade-offs would be between customized behavior and efficiency; on the one hand, the repeated creation of testing scripts would allow specific and customized testing, while in the other case, the development lifecycle automation would be higher. Enterprises would have to choose the appropriate configuration based on their situational and contextual needs.

The Design-Use Dimension

A BP can result in the creation of a tool, capability or artifact that can be repeatedly used. Just like the plan-execute dimension, such BPs can be considered as having two distinct stages, with one stage being responsible for designing the artifact and the other stage for using that artifact repeatedly. Thus, a design and use relationship exists between these segments of the process. In the BPA modeling framework, the stage producing the artifact is called the design stage and the stage using the artifact is called the use stage. The use stage uses the artifact repeatedly without necessarily being aware of the inner working of that artifact. PEs can also be moved from a design stage to a use stage (and vice versa), with such a repositioning either leading to an increased design/artifact sophistication/automation or to trading the design effort for run-time usage control/customizability. The DevOps approach emphasizes greater automation of the software development lifecycle through the use of tools. A number of third-party tools are available (e.g., Jenkins 1 for CI, Chef 2 for deployment management, Github 3 for source repository and Splunk 4 for application monitoring etc.), which provide such automation of process activities. These tools are configured (designed) for use in any particular DevOps implementation and thus enable a move from manual methods of product deployment (shown by the Manual Deployment stage in Fig. 6) to more automated and CD cycles (shown by the Environment Setup design stage and the Continuous Deployment use stage). However, the introduction of any artifact in the design-use dimension should be evaluated against the NFRs (as shown by the goal model).

Related Work

CI and CD are well understood concepts in continuous software engineering where the objective is to deliver ongoing software product improvement and enhancements in less time and greater frequency through improved process automation and introduction of suitable software tools [START_REF]Continuous Software Engineering[END_REF]. Generally, any organization would have multitudes of software processes to handle different project development situations; appropriate software processes are selected based on situational needs and business context [START_REF] Alegría | Building software process lines with CASPER[END_REF]. Software process tailoring refers to the customization of standard software planning, development and operational processes [START_REF] Pedreira | A systematic review of software process tailoring[END_REF] in situations where organizations need an enterprise-level assessment on how environmental factors, product and project goals, and other organizational aspects influence software process configurations. Commonalities and variabilities exist between these software processes and, as such, these software processes can be tailored to meet specific enterprise business and operational goals and objectives using different techniques for decision making [START_REF] Martıınez-Ruiz | Modelling software process variability: an empirical study[END_REF][START_REF] Martínez-Ruiz | Managing process diversity by applying rationale management in variant rich processes[END_REF]. Several software process modeling techniques exist and are primarily based on process modeling languages (such as BPMN), Unified Modeling Language (UML) or Software & Systems Engineering Metamodel (SPEM) [START_REF] García-Borgoñon | Software process modeling languages: A systematic literature review[END_REF]. Apart from a few (such as [START_REF] Cares | Goal-driven agent-oriented software processes[END_REF][START_REF] Washizaki | Deriving project-specific processes from process line architecture with commonality and variability[END_REF]), most of the software process modeling frameworks do not provide support for modeling variability in software process configurations and the ability to reason about them while taking enterprise-and process-level NFRs into consideration.

Enterprises attempt to reduce development effort and increase the range of product features offered through software product lines (SPLs). SPLs can be used to support multiple software products through the development of common software architecture(s) and code components. SPLs rely on variation points to support software product variability [START_REF] Van Gurp | On the notion of variability in software product lines[END_REF]. Delaying decisions during the development cycles of these SPLs provides the benefit of allowing the optimization of technical and business goals (e.g., increased code reuse) across multiple products, possibly at the expense of other goals (e.g., simpler architecture). Extending the idea of SPLs to processes results in the notion of Software Process Lines (SPrL) [START_REF] Rombach | Integrated software process and product lines[END_REF], which is based on a similar premise: similarities and differences between a set of software processes could be scoped for determining customized software process configurations as per unique software project conditions. In [START_REF] Washizaki | Building software process line architectures from bottom up[END_REF], the idea of (software) Process Line Architectures (PLA) is introduced. A PLA is described as "a process structure which reflects the commonality and variability in a collection of processes that make up a process line from the perspective of overall optimization". Like a BPA, a PLA also represents the existence of VPs in (software) processes. However, it does not support the placement of a process element along the four dimensions as described in this paper.

Previous research on BPAs largely focused on the nature of the relationships among their BPs. Various relationship types were proposed (e.g., [START_REF] Dumas | Fundamentals of Business Process Management[END_REF][START_REF] Eid-Sabbagh | Business process architecture: use and correctness[END_REF]), such as sequence, reference, composition, etc. Unlike most BPA approaches, we focus on systematically analyzing multiple BPA alternatives along the four variability dimensions with the aim at finding the one that best matches the properties of the domain.

Another relevant domain is BP variability modeling that focuses on representing customizable BP models and deriving custom variants from them (see [START_REF] Rosa | Business process variability modeling: A survey[END_REF] for an overview), with the key element being a VP, which is used to represent and bind variability. Overall, these approaches deliberate about variability only at the process level (within a single process) and do not support reasoning about BPAs. In dealing with BP flexibility, Weber et. al [START_REF] Weber | Change Patterns and Change Support Features -Enhancing Flexibility in Process-Aware Information Systems[END_REF] propose four dimensions of change, including the one focusing on the recurrence of activity execution. While somewhat similar to our approach, it neglects trade-offs among the various options and does not cover flexibility in BPAs. Feature models [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF] are sometimes employed as a useful abstraction to help guide BP customization (i.e., selecting or deriving a BP variant from a customizable process model). While a viable option, feature models (unlike goal models used here) lack the ability to represent selection criteria and support trade-off analysis among configuration alternatives.

Future Work

In future iterations of this work we plan to study the following:

 Many enterprises are becoming critically dependent on software and software processes to create and deliver value to their stakeholders in the form of products and services. Successfully introducing software process reconfigurations in response to changing business models or strategic direction may impact the ongoing delivery of value, product and services [START_REF] Esfahani | Strategically balanced process adoption[END_REF]. We aim to link the impact of software process reconfigurations to business goals and value in order to exploit synergies and mitigate negative consequences.  We wish to understand the possible forms of software process reconfigurations with the intention of identifying key points of process variations and the influencing factors that contribute towards these process reconfigurations. Requirements for software process reconfiguration are usually developed in response to shifting enterprise objectives, adaptability requirements and emerging digital technologies in the enterprise context. The relationship between these requirements and their influence on variation points for software processes would need to be understood.  Processes are executed by participants or actors in any enterprise. Changes in organizational structure and team dynamics would invariably influence process configurations (and vice versa). For example, any process reconfiguration would possibly shift the boundaries of actor influence with some actors gaining responsibility and other actors losing responsibility or power. Conversely, changing an actor's boundary of influence may also require the selection of an alternate process configuration to successfully attain the same set of goals. The association of operational process level concerns and social organizational considerations needs to be studied and developed by combining the BPA technique (for process representation) with a social actor modeling framework, such as i* [START_REF] Yu | Social Modeling for Requirements Engineering[END_REF].  Enterprises take advantage of software metrics to routinely and incrementally improve on software processes. While software metrics are well documented [START_REF] Fenton | Software metrics: rigorous & practical approach[END_REF], illustrating and analyzing the integration and usage of these software metrics for ongoing software process improvements, through the use of enterprise modeling techniques, is not well covered. The BPA can be continuously refined through use of software metrics and data analytics in all stages of the feedback loopi.e., sensing, interpreting, deciding and acting.

We are exploring methods and techniques from diverse areas, including software engineering, requirements engineering, system dynamics, and management literature, to contribute towards a framework for the management of enterprise software process variability. We are developing a meta-model and an ontology to understand the nature of software process variability and to extend existing enterprise modeling techniques to incorporate attributes and constructs for denoting variability and flexibility in software processes. Finally, we aim to validate such a proposed framework by conducting case studies for various types of enterprises.

Conclusions

Every enterprise relies on various BPs for proper functioning, which can take many forms and can include operational, transactional, strategic, recurring, design processes, etc. Having uniform and static processes is no longer an option for enterprises dealing with a multitude of dynamically changing situations that require periodic adjustment of process configurations [START_REF] Yu | Enterprise architecture for the adaptive enterprise -A vision paper[END_REF][START_REF] Yu | Architecting the enterprise to leverage a confluence of emerging technologies[END_REF]. A recent report from Gartner mentions that "by 2017, 70 percent of successful digital business models will rely on deliberately unstable processes designed to shift as customer needs shift" [START_REF] Spender | Top 10 Strategic Technology Predictions for 2015 and Beyond, Gartner Research[END_REF]. In this paper, we considered the possible dimensions of software process reconfigurability using the DevOps approach as a motivating example. Limitations of current process modeling languages, such as BPMN, in illustrating multiple aspects of process architecture were discussed, with the BPA modeling technique being used to describe four dimensions of PE positioning, namely, temporal, recurrence, plan-execute, and design-use, in a typical DevOps implementation. Goal models were used for evaluating alternate software process reconfigurations by assessing the satisfaction of enterprise NFRs.

Fig. 1 .

 1 Fig. 1. A simple BPMN model representing a typical DevOps approach

Fig. 2 .

 2 Fig. 2. Business Process Architecture (BPA) for a DevOps approach

Fig. 3 .

 3 Fig. 3. QA testing alternatives (A1) As a separate phase from product feature implementation, (A2) As part of the product feature implementation phase. (B) Analyzing the temporal placement of QA testing process element based on NFRs.

Fig. 4 .

 4 Fig. 4. Release backlog grooming alternatives (A1) As part of the Sprint Cycle stage with no recurrence, (A2) Moved to the Release Planning stage with a multi-recurrence dimension between both stages. (B) Analyzing the recurrence arrangement of the release backlog grooming and sprint planning stages based on NFRs.

Fig. 5 .

 5 Fig. 5. Test scripts creation placement alternatives (A1) As part of the continuous integration stage with increase customizability of testing, (A2) As part of the testing plan stage leading to greater efficiency and reuse. (B) Analyzing the placement of test script creation along the planexecute dimension while considering trade-offs for NFRs.

Fig. 6 .

 6 Fig. 6. Deployment of product release alternatives (A1) Manual deployment without the use of automated tools, (A2) Through the design and use of configured third-party tools. (B) Analyzing the need for having a design-use dimension for product release deployment.

   Development: The model depicts the Scrum project management methodology with the various rituals and iterations shown as part of the Release Planning and Sprint Cycle stages. Evidence of recurrence is apparent in the usage of the Product Backlog over multiple Release Planning iterations. The Perform QA Testing process element can be used to demonstrate the temporal dimension as the testing can be done either before the code is committed to the source repository or after. Both options have different consequences as shall be seen in the section 3.1.  Automated Testing: The DevOps approach promotes the usage of tools and scripts for automating the testing of product features. For this, test plans and test scripts are created and are then used to automate the testing effort, whereas test plans are implemented through test scripts. The test plans and test scripts are created in the Testing Plan stage and the test scripts are executed through the Execute Test Scripts PE (part of the Continuous Integration stage); these are illustrative of the plan-execute dimension.  Ongoing Deployment: As with testing, the deployment of the developed product feature is ongoing, immediate and automated while factoring in the variable and multiple environments that the product would have to run on. The software deployment is automated through deployment scripts that are executed by various deployment tools; these scripts are developed by the DevOps engineers and executed as part of the Continuous Deployment stage that gets triggered on the successful completion of the Automated Testing and Continuous Integration stages.  Operational Support: A major contribution of DevOps to software development

https://jenkins-ci.org/

https://www.chef.io/

https://github.com/

http://www.splunk.com/