Requirements management is one of the cornerstone activities in software development. Agile methodologies use dedicated methods, techniques and artifacts in order to implement this activity. Remarkably, Backlog Grooming is the activity of managing and welcoming changing requirements in SCRUM. However, current industrial practices in agile development still tend to render this process in the shape of a list of statements, features and bug fixes that often leads to a blurred view of the goals of the project, the underestimation of client's needs and the decrease of the ability to respond to changes. In this paper we outline an approach that uses goal and agent oriented modelling techniques in order to fill in this "intentional" gap that current industrial approaches lack.Peer ReviewedPostprint (published version

Colomer, Daniel

Franch Gutiérrez, Javier

Information Technology and Nanotechnology

English

UPCommons. Portal del coneixement obert de la UPC

StarGro: Building i* Metrics for AgileMethodologiesColomer, Daniel1 and Franch, Xavier21 Collins GmbH, Hamburg, Germanydncolomer32@gmail.com2 Universitat Polite`cnica de Catalunya (UPC) c/Jordi Girona, 1-3, E-08034Barcelona, Spainfranch@essi.upc.eduAbstract. Requirements management is one of the cornerstone activi-ties in software development. Agile methodologies use dedicated meth-ods, techniques and artifacts in order to implement this activity. Re-markably, Backlog Grooming is the activity of managing and welcomingchanging requirements in SCRUM. However, current industrial practicesin agile development still tend to render this process in the shape of a listof statements, features and bug fixes that often leads to a blurred viewof the goals of the project, the underestimation of client’s needs and thedecrease of the ability to respond to changes. In this paper we outlinean approach that uses goal and agent oriented modelling techniques inorder to fill in this “intentional” gap that current industrial approacheslack.1 IntroductionAgile methodologies are nowadays adopted by most of the software develop-ment industrial sectors. These methodologies usually define an artifact and/ormethodology that helps organisations in managing their project requirements.Nevertheless, industrial practices tend to render this process in the shape of alist of statements, features and bug fixes that often leads to a blurred view ofthe project goals, the underestimation of the client’s needs and might severelyaffect the capability of a team to react to changes.The root of these problems can often be traced down to a misinterpretationof the Agile Principle of “Individuals and Interactions over processes and tools”.Based on that principle, organizations tend to focus on development and reducethe activity of requirements management to the point in which the goals ofthe project get blurred, lost and only visible by the Product Owner but neverreaching the development team.In this paper we present an approach that uses i* as a way to capture theintentionality that is lost during the activity of requirements management. Ourcurrent work has the following objectives:– To define a set of guidelines that will compose a base approach for buildingand using metrics in requirements engineering activities focused on agilemethodologies.– To define a set of guidelines that will compose a base approach for imple-menting metric repositories.– To implement a public repository of i* metrics to be used as an example andbase for metrics driven requirements engineering in agile methodologies.– To implement an industry ready, open source and metrics-aware i* modellingtool.The paper is structured as follows: First, we take a detailed look at the pre-viously stated problem using a real industry case extracted from the Germanweb development market executed between 2012 and 2014. Then, we follow bypresenting StarGro, a set of guidelines to help implement metric repositories andwe give some insights on a sample set of metrics that is being build using thisapproach. Finally, we discuss the first observations after using a prototype im-plementation of the suite and we close the paper by presenting a brief discussionand future work.2 Case Study: Press Distribution SystemA press distribution organization based in Hamburg, Germany, started a projectwith the goal of moving its current management system to the web. The projectwas defined as a complete reimplementation of the system in the shape of a webplatform.Initial Settings The initial set of requirements was given in a single 88 pageslong document describing the functionality of the system divided in 9 differentmodules. This documentation was complemented with a set of screenshots of theoriginal application. The project was planned to run 6 months and the initialdevelopment team configuration was of 1 lead developer, 4 senior developers, 1junior developer and 1 front-end designer.Project Results & Retrospectives The Project was never fully finished bythe original team and it was transferred to another organization. The deadlinewas delayed more than 2 years.During the development new resources were introduced such as a runningcopy of the original system which gave the developers some insights on how theoriginal solution looked like. Customer collaboration was active in a daily basisthroughout the whole project timespan.Lessons Learned The following lessons were derived by the original team afterassessing the retrospectives of the failed project:– The need of tracking stakeholders and their goals and making this knowledgeproject-wide available.– The need of systematically refining and prioritizing requirements.– The need of tracking the project evolution and progress in order to predict,welcome and minimize changes better.The Need of Metrics Metrics as a progress tracking and prediction tool werehighlighted as potential solution to the need of welcoming changes and trackingthe evolution of requirements.In order to cope with all these problems, we explore in this paper the use ofi*. This adoption can lead to keeping track and making the domain knowledgeand intentionality project-wide available. Once we have a model that representsour domain from an intentional point of view and a set of metrics to evaluate itwe can then evaluate different prioritization approaches.In order to combine i* and metrics we propose the usage of iMDF [1], amethod for defining metrics in i* which is mainly focused on the analysis ofthe target domain and the metrics themselves. The iMDF Framework can besummarized in 4 steps:1. Domain Analysis: The goal of this step is to gain understanding about thedomain whilst establishing the mapping from concepts in that domain ontothe i* framework.2. Domain Metrics Analysis: This step aims at analysing the departing suiteof domain metrics before its formalization is tackled.3. i* Metrics Formulation: This step makes operative the metrics in termsof i* constructs.4. iMDF Update: This step includes eventually updating statistics, the lan-guage of patterns and the metrics catalogue.3 StarGro: Building Metrics for Agile MethodologiesThe following lines describe StarGro. The aim of Stargro is to help individualsand organizations improve requirements management activities by means of us-ing metrics designed and specially tailored for Agile Methodologies on top of i*models. This approach can be applied both to individual organizations as wellas to a particular domain (e.g., web applications).The approach can be summarized in the following guidelines:1. The users of the approach need to apply the 4 steps defined by iMDF ontheir target domains during the set up of a project in order to identify andclarify the domain of action and possible needed metrics.2. Metrics will be organized and available in repositories for future reuse. Teamscan reuse existing metric, add new ones or tailor existing metrics.3. For applicability purposes, repositories should be based on a single i* meta-model and all the metrics belonging to that repository must be compatiblewith that meta-model.4. A team can use more than one repository at a time as long as they are alldefined on compatible meta-models.5. The technology and means used to implement or represent metrics are notrestricted by this approach.6. Metrics will be executed as the i* models used in the project change. Theresults of the execution can be observed and interpreted during backloggrooming sessions or at any moment in order to track the evolution of theproject, get better insights on how to proceed and being able to react fasterto change.7. Feedback after using certain metrics is relevant specially for the 4th step ofiMDF.8. There are no restrictions on how to use metrics. Suggestions on the usage ofa metric should always be available to the end user. Metrics can be used forexample as a prioritization tool, as an elicitation help, etc.4 Applying StarGroFollowing the guidelines presented in the previous section we started implement-ing a public repository of i* metrics to be used as an example and base for metricsdriven requirements engineering in agile methodologies.The formal specification and an XQuery 3 implementation of the suite arework in progress. The source code of the current state is available online 4 packedas an Eclipse Project ready to be executed 5. The Project contains iStarML [2]files as well as openOME 6 (.ood) resources to use as examples.The full specification of the metrics and the details of applying StarGro areavailable online. 74.1 The MetricsThe following is a list of the metrics included in the suite accompanied with abrief description.– Change Proneness: This metric is defined as the number of both direct andindirect outgoing dependencies an element has. This metric is an adaptationof the Behavioural Dependency Measurement (BDM) presented in [3]. Bydefinition, two elements connected by a dependency -directly or indirectly-in i* are intentionally dependent. Changes in an intentional element mayoccur by modifications to the element itself or by changes propagated fromother related elements. Changes applied directly to an intentional elementare difficult to predict in i* models, therefore we will consider for our pro-totype specification the changes occurred by propagation. We will base themeasurement on intentional dependencies.– Intentional Bottleneck: This metric is defined as the amount of directlyincoming dependencies of an element. This metric uses the amount of incom-ing dependencies both at an actor and intentional element level. We assumethe more incoming dependencies an element has the more critical it is for the3 http://www.w3schools.com/XQuery/4 http://www.dncolomer.net/resources/distar.zip5 http://www.dncolomer.net/resources/distar-tutorial.pdf6 https://se.cs.toronto.edu/trac/ome/7 http://www.dncolomer.net/resources/applying-stargro.pdfsuccess of a project. The rational behind this assumption is that the moreincoming dependencies an element has the more propagations a change islikely to cause.– Epicness: This metric is defined as the proportion of unrefinable elementsan element is decomposed into. This metric explores SR graphs’ leaves inorder to help determining whether an intentional element is refined enough.We assume that the bigger proportion of tasks and resources the leafs of anintentional element are decomposed into, the more refined this element is.The rational behind this assumption is the fact that only goals and softgoalsrepresent an intentional desire. The exploration of leaves is done ignoringthe SR-Link type.4.2 ObservationsWe present in this section the first observations of experimenting with the pro-totype implementation of the suite. We applied the metrics to a real ongoingproject called “Outfit Creator”. The Outfit Creator is a Web Application thatenables users to graphically create fashion outfits using images and resourcesfrom an e-commerce platform.– Change proneness: We observed that the current implementation predictschange more successfully when requirements are more refined. This is dueto the fact that the we currently use the number of i* dependencies to de-termine how strong the intentional relationship between two Actors is. Themore refined a requirement is, the more dependencies we are able to iden-tify. In order to achieve a more accurate change prediction we are currentlystudying the possibility to include the exploration of SR-Links and otheri* constructs as well as giving different weights to direct and indirect de-pendencies. Furthermore we are also studying how can we explore forwardwhen a dependee is an actor and not an intentional element. In the currentprototype version the actor is considered a leaf of the explored graph.– Intentional Bottleneck: In this case we observed a similar situation than in“change proneness”. We observed that the current implementation performsbetter in stages where requirements are more refined. Nevertheless this onlyaffects us in cases where we need to compare or priroritize bottlenecks andtherefore we need better insights on the “strength” of these points. In orderto improve the accuracy of this metric we are studying the possibility toinclude the exploration and study of both depender and dependee of each ofthe incoming dependencies.– Epicness: This metric has proven to perform the worst. The main problemis the fact that simply studying the proportion of tasks and resources inthe last SR-Link level is not enough to determine with precision whether arequirement is refined enough or not. In order to achieve a more accuratemeasurement we are studying the possibility to include the SR-Link type asa relevant factor. We are studying the possibility to consider not only theproportion of tasks and resources but also patterns of proportion evolutionfrom level to level and the number of leaf elements as well as its evolution.5 Discussion & Further WorkIn this paper we sketched StarGro: a set of guidelines to help individuals andorganisations build metrics for Agile Methodologies. We started building a suiteof metrics to be used as a base and example.We did not specify whether the approach presented in this paper should beapplied at an industry level, therefore enabling a global repository of metrics,or at an organization level, therefore supporting the existence of many privaterepositories that belong exclusively to concrete groups, organizations or teams.Nevertheless we encourage a mixed solution. The existence of repositoriesboth public and private favour all levels. That is why we define later in thisdocument a reduced public Dependency Based Prediction Metrics Suite that canbe used as a base for any private or public entity and will be further extendedin the future.A natural next step is for us to study and define a repository containing thesuite of metrics. We are also planning to add new guidelines to StarGro regardingthe generic implementation of i* metrics repositories.As a future work we are planning to further refine the suite of metrics andto publish a public and open source version. Parallel to that we are planning toadd more metrics to the suite and to develop a web application that can handlei* modeling together with metric definition and execution.We are currently exploring the possible usage of XQuery, iStarML and MetricRepositories in order to define model and dependency aware filters for i* models.The aim of such filters targets the automatic generation of i* diagram viewsthat contain elements satisfying a provided filter criteria. The potential usage offilters is tightly related to the need of requirements management features in i*modeling tools. If we aim at enabling i* to be used as a requirements engineeringframework in the industry we must provide a way for developers, business, andother potential industrial users to search and filter requirements in an i* diagramor set of diagrams for that is a really common use case in such toolsReferences1. Xavier Franch: A Method for the Definition of Metrics over i* Models.CAiSE 2009:201-2152. Carlos Cares, Xavier Franch, Anna Perini, Angelo Susi: iStarML: An XML-basedModel Interchange Format for i*. iStar 2008: 13-163. Ah-Rim Han, Sang-Uk Jeon, Doo-Hwan Bae, and Jang-Eui Hong: Behavioral De-pendency Measurement for Change-proneness Prediction in UML 2.0 Design Mod-els. COMPSAC 2008: 76-83

StarGro: Building i* metrics for agile methodologies

https://upcommons.upc.edu/bitstream/2117/26442/1/Franch.pdf

StarGro: Building i* metrics for agile methodologies

Abstract

Similar works

Full text

Available Versions

UPCommons. Portal del coneixement obert de la UPC