ARIS Community - We Love BPM

Modeling social aspects of (software) processes

jcabot's picture
by Jordi Cabot in ARIS BPM Blog posted on 2010-10-04

The introduction of a new software process in an organization is a difficult and often risky proposition. This is especially true when adopting agile processes like Scrum that usually imply radical departures from traditional team structures, cooperation styles and relationships.

Unfortunately, descriptions of software processes (like this BPM-based view of SCRUM) focus on the sequence of process activities and on the artefacts generated in each activity but they mostly ignore the social aspects of the process, such as:

  • What are the skills required to perform each role?
  • Which are the most critical roles? What are the consequences if they don’t perform?
  • Which other actors do I depend on in order to succeed in my goals? What do I depend on them for?

We believe this kind of knowledge is key to facilitate the adoption of a software process and, even more, to let software companies assess the chances of successfully enacting the process by checking (prior to process adoption) whether the social aspects of the process will be a good fit for the current team members structure and organization.

To explicitly represent these details of the software process we propose to complement existing process modelling approaches with a new perspective aimed at describing and analyzing the social and human aspects of the process. Our approach (see H. Chiniforooshan, J. Cabot, E. Yu: Adopting Agile Methods. Can Goal-Oriented Social Modeling Help?. 4th Int. Conf. on Research Challenges for Information Systems (RCIS’10)) makes use of thei* modelling framework for visualizing and analyzing relationships among social actors, particularly how they depend on each other to achieve individual and team goals.

The i* framework consists of two main models: the SD (Strategic Dependency) and SR (Strategic Rationale) model. Simply put, the first one focuses on the dependencies between the different actors/roles of the process while the second one looks at the internals of each actor to see how the actor fulfils the goals that have been assigned to him/her in the SD model. There are two kinds of goals: hard goals (or simply goals) representing the functional objectives, and soft goals, expressing qualitative objectives. Analysing this information helps to answer questions about the social aspects of the software process, as the ones mentioned above.

As an example, a (very simplified) SD model for SCRUM could be this one:

With this diagram, it is easy to see who the main roles of the process are (to simplify, in this case we just show the three main ones) and the dependencies between them. For instance, the team is in charge of developing the product increments but depend on the product owner for the prioritization of the product backlog and on the scrum master for the guidance and management necessary to properly follow the Scrum process. If a given actor does not deliver, all the other actors depending on them will be negatively affected and may not be able to accomplish their goals.

Once the SD is done we refine it to create the SR model. An excerpt of the SR model for the Scrum Master actor is the following.

Here we see a decomposition of the “Team to be managed” responsibility assigned before. As part of the decomposition we indicate the qualities (expressed as soft goals) that will help the Scrum Master fulfil the goal.

Again, representing this knowledge facilitates the evaluation of the adequacy of this process for the company.  For instance, any company willing to adopt Scrum should first check:

  1. If there is somebody in the company that can play the role of Scrum Master (and the same for the other roles)
  2. If that person has the qualities required to play that role successfully (does she have good relationship with the product owner? does she have good communication skills? ...)
  3. Be prepared to invest the required time/money to cover the gaps found in the analysis of 1 and 2 or at least be aware of their consequences (cascade problems triggered by not satisfying the expectations of the other actors shown as dependencies in the SD model). E.g. a bad Scrum Master may fail at properly managing the team which then may cause the team to fail at delivering the incremental product updates, even if the Product Owner does a good prioritization of the backlog.

In this blog post we just scratched the possibilities of i* models for defining social and organizational aspects of (software) systems but hopefully you get an idea of the kind of “view” of the system/process these models can provide and the benefits of taking into account these aspects when thinking about adopting a new development process.

16812 Views
0 Likes
9 Comments
Tags
There are no attachments
Jordi Cabot posted on 2010-10-04

For information on other aspects of (software) modeling you can follow me on my Modeling Languages portal http://modeling-languages.com

Evellin Cardoso posted on 2010-10-07

Hi Dr. Cabot,

It is a very interesting post.

It seems our ideas have converged to the same point since I worked with a goal-oriented perspective of BPM in my master thesis. In particular, i studied how to align goal models with the other viewpoints of the enterprise architecture (business process models, organizational chart models and so forth). The goal models have been developed in the Tropos language (an i* variation) and the process models in the ARIS toolset.

Further, my research group also works in correlated aspects in strategic modeling, business process modeling, MDD, ontological evaluation of modeling languages, among others.

If you're interested in sharing ideas, feel free to contact me.

Evellin

Jordi Cabot posted on 2010-10-07

Sure, maybe you can contact me by email? (easy to find in the portal or here http://jordicabot.com)

Paulo Santos Jr. posted on 2010-10-07

Hi Dr. Cabot,

In addition to Evellin's post, I must comment that we have a paper entitled as "Semantic Integration of Goal and Business Process Modeling using Ontologies" which presents ideas to integrate tropos and aris languages through a semantic foundation.

Further, in a recent future, we hope to finalize a tool to allow this integration. In this tool, a modeler will be able to develop goal models (in the tropos language) and process models (in the epc language) in a integrated manner.

In the case of any question or comment, do not hesitate to contact me.

Paulo Sérgio

 

 
In addition to Evellin's post, I must comment that we have a
paper entitled as "Semantic Integration of Goal and Business Process Modeling using Ontologies" 
which presents ideas to integrate tropos and aris languages through a semantic foundation
further, in a recent future, we hope to finalize a tool to allow this integration. 
In this tool, a modeler will be able to develop goal models (in the tropos language) 
and process models (in the epc language) in a integrated manner.
 
 
In the case of any question or comment, do not hesitate to contact me
 
Paulo Sérgio
Ivo Velitchkov posted on 2010-10-07

Evellin, Paulo

I'm very interested in the topics you mentioned as I've doing some work in a similar field. Could please share some links to articles or other sources. Thank you!

Ivo

Paulo Santos Jr. posted on 2010-10-12

 

Hi  Mr. Ivo,
 
You can find some of our publications at http://nemo.inf.ufes.br/en/publications.
 
If you want some paper that has not link, please contact me.
 
Paulo Sérgio

 

 

 

Etienne Venter posted on 2011-02-11

Very interesting and I think the ARIS communications diagram could work well to depict the concepts?

Jordi Cabot posted on 2011-02-12

@Etienne I´m not familiar with the ARIS communication diagram. Can you point me to some public online resource that explains it?

In the end, any kind of diagram that includes the concepts of actor, role, goal, dependency,... could be used to model these concepts

Paulo Santos Jr. posted on 2011-02-12

Mr. Etlenne Vender,

Sorry, but I did not understand your last post. 

Could you give me more details about ARIS Communication Diagram? 

What is the functionality of this diagram?  In other words, what is this diagram intended to decipt?