# An Open Source Environment for an Agile Development Model

Paolo Ciancarini, Marcello Missiroli, Francesco Poggi, Daniel Russo

<figure><img src="image_1.png" /></figure>

## To cite this version:

Paolo Ciancarini, Marcello Missiroli, Francesco Poggi, Daniel Russo. An Open Source Environment for an Agile Development Model. 16th IFIP International Conference on Open Source Systems (OSS), May 2020, Innopolis, Russia. pp.148-162, 10.1007/978-3-030-47240-5_15. hal-03647279

HAL Id: hal-03647279

https://inria.hal.science/hal-03647279

Submitted on 20 Apr 2022

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An open source environment for an agile development model

Paolo Ciancarini¹,², Marcello Missiroli¹, Francesco Poggi³, and Daniel Russo⁴

¹ DISI, University of Bologna, Italy
{paolo.ciancarini}@unibo.it

² Innopolis University, Russian Federation

³ DCE, University of Modena and Reggio Emilia, Italy
francesco.poggi@unimore.it

⁴ Dept. Computer Science, Aalborg University, Denmark
daniel.russo@cs.aau.dk

**Abstract.** Tools are of paramount importance in automating software engineering tasks; although the Agile Manifesto prefers "individuals and their interactions over processes and tools", some agile development activities make no exception and can be automated effectively and successfully. In process frameworks like Scrum or similar ones some activities are in fact quite structured and need specific tool support. Hence, it is interesting to study the combination of specific agile practices with OSS tools.

In this paper we introduce the Compositional Agile System (CAS), an environment created to support iAgile and automate some of its tasks using OSS tools. iAgile is a Scrum-like model designed to develop critical systems in the military domain.

# 1 Introduction

The relationship between a development method and the tools which compose its programming environment has been debated for a long time. In a seminal paper Osterweil introduced the idea that software processes should be programmed just like applications [27], since they "*are software, too*". This idea is powerful and had the consequence to foster the study of the so called "process engines", namely environments programmed in order to support specific development methods [2, 15].

The Agile era inaugurated by the Agile Manifesto gave less importance to tools, in fact the first of the four Agile values says: "(...we have come to value...) *Individuals and interactions over processes and tools*".

However the development of modern, complex software needs a lot of careful effort; several specific activities can and should be automated. For instance, the management of the product backlog in Scrum is well supported by digital taskboards like Trello [26]. Even the concept of *Definition of Done* can be partially automated [16] using for instance some tool for checking the quality of code and measuring the technical debt, like SonarQube. Moreover, the globalization
of the software industry has fostered the development of collaborative platforms - like Jira - in multi-site environments to reduce costs and increase productivity.

Thus, it is still interesting to study what are the most appropriate approaches and tools to support agile developments. Another, complementary, question is if the interactions necessary to any team-based software development method suggest to design specific ad-hoc platforms.

In this paper we introduce the Compositional Agile System (CAS in short), an environment created to support iAgile, an improved agile development model introduced to develop critical systems in the military domain.

The structure of this paper is the following: in the next Section 2 we describe the iAgile method for developing critical systems in specific domains; in Sect. 3 we discuss the requirements of CAS, an open source development environment supporting a Scrum-like model called iAgile; in Sect. 4 we describe the CAS architecture. In Sect. 5 we compare CAS with other environments and services for agile developments. Finally, in Sect. 6 we describe our future plans and draw our conclusions.

## 2 iAgile: an improved Agile development model for the military domain

Eisenhower is attributed the following quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable". This applies to Agile approaches like Scrum, where planning the overall project is forbidden, however planning sprint-by-sprint is mandatory. iAgile is a model for empirical project management of software developments. Inspired by the Agile Manifesto, it has been derived from Scrum, and has been especially tailored for Command and Control (C2) critical systems in the military domain [23]. A C2 system in this domain includes functional military areas to cope with humanitarian assistance, stability operations, counterinsurgency operations, and combat operations [25].

The transition to Agile was needed to support faster adaptation to changes to operational needs and quality and security requirements but was also mandated by a drastic reduction in the budgets experienced in Italian public administration. The continual evolution of the operational environment in conflict theaters generates instability of the C2 requirements; this means that their developers have to work at all times with unstable and unconsolidated mission needs. Thus, planning a C2 system using the old, strongly planned, waterfall approach became unsuitable [9].

The initial idea was to experiment an in-house development of some novel functions of an established, waterfall-based, C2 system. The results using Scrum with some developers rented for specific enhancements were encouraging, however the stakeholders felt that some productivity analysis was necessary. In fact, some aspects of Scrum were not satisfactory for the context of C2 systems developed and operated in-house.

The introduction of an Agile approach in the development of critical software required the solution of many problems and the construction of a solid structure
based on four principles: user community governance, specific Agile training, new Agile CASE tools and custom Agile development doctrine.

Thus for the new developments a method called iAgile was introduced [23]. Table 1 shows how the Agile principles<fnref n="5" /> have been embedded in iAgile.

<table><caption>**Table 1.** iAgile embeds agile principles</caption><thead><tr><td>Agile principles</td><td>iAgile</td></tr></thead><tbody><tr><td>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.</td><td>iAgile has been introduced in order to develop LC2EVO, a military C2 system, aiming at shortening the "time-to-the-field" of new functions[24]</td></tr><tr><td>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage</td><td>iAgile systematically developed new incremental versions which were immediately tested on the field [25]</td></tr><tr><td>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.</td><td>Sprints lasted 4 weeks + 1 for certification [6]</td></tr><tr><td>Business people and developers must work together daily throughout the project.</td><td>Developers and users worked daily together [3]</td></tr><tr><td>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.</td><td>iAgile has been quite successful, exploiting the enthusiasm of both civil and military developers [7]</td></tr><tr><td>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.</td><td>Daily meetings and physical shared taskboard were used systematically [4]</td></tr><tr><td>Working software is the primary measure of progress.</td><td>The LC2EVO project executed about 30 sprints, each delivering a working increment [17]</td></tr><tr><td>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.</td><td>The project lasted 18 months, produced several releases with a string reduction of development costs [8].</td></tr><tr><td>Continuous attention to technical excellence and good design enhances agility.</td><td>iAgile requires excellent technical capabilities [14].</td></tr><tr><td>Simplicity—the art of maximizing the amount of work not done—is essential.</td><td>The "lean" approach implicit in iAgile shortened the workflow necessary to implement critical requirements [18].</td></tr><tr><td>The best architectures, requirements, and designs emerge from self-organizing teams.</td><td>The quality of the final system is high and is still being used [17].</td></tr><tr><td>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.</td><td>Projects based on iAgile used systematically retrospectives [14].</td></tr></tbody></table>

<footnote n="5">⁵ https://agilemanifesto.org/iso/en/principles.html</footnote>
## 3 Requirements of a development environment for iAgile

The project we were involved consisted in defining a development environment supporting the iAgile development model. For security reasons we could not use commercial software online in the cloud. The target of the project was to develop an open source development environment suitable to be deployed either on a private network or in a hybrid cloud keeping complete control on its implementation and extensions.

We identified the following user stories (or epics) for CAS:

1. As a stakeholder, I am interested in estimating and monitoring the effort required by a new function to be added to the system, in order to know how many people are necessary and their productivity.

2. As a Product Owner during the project I need to check productivity data in order to predict when a release will be possible, so that *delivery on time* is ensured.

3. As a developer or stakeholder I need to communicate easily, fast, and safely with all other developers or stakeholders.

4. As a PO I need to check the code delivered by the team with respect to the Product Backlog (*percentage of adopted work*), including the Definition of Done.

5. As a developer I need tool support for asymmetric pair programming in order to get help from senior developers or domain experts.

6. As a developer I need tool support to check the quality of my code in order to satisfy the Definition of Done.

7. As a developer I need tool support to monitor defects in libraries and open source components.

8. As a PO I need to track how the user stories of the Product Backlog evolved into code in order to plan the next release.

These User Stories do not cover the whole spectrum of iAgile roles and activities, however we have found them useful as an initial reference that now can be expanded.

### 3.1 Mapping the requirements on open source components

The above user stories were suggested by interviewing the stakeholders involved in the development of a critical system. In particular, the introduction of the COSYSMO estimation framework [28] was suggested by some military stakeholders who were interested in matching system engineering estimation with agile development of software-intensive components.

In the meantime in the same project we had proposed a survey to the agile community; the results of such survey are reported in [10]. According to the survey, Jira is currently the most popular tool for agile developments. Also Trello and Slack are very popular. However these tools are not adequate for the context of our project, since they are commercial and based on proprietary clouds.
<table><caption>**Table 2.** Mapping the user stories and main iAgile roles on some open source tools</caption><thead><tr><td>#</td><td>User Story</td><td>Tool</td><td>iAgile roles</td></tr></thead><tbody><tr><td>US1</td><td>Estimating and monitoring</td><td>COSYSMO, COCOMO</td><td>AD</td></tr><tr><td>US2</td><td>Checking the team productivity</td><td>Taiga, GitInspector, logger plug-in</td><td>PO, SM, team, AD</td></tr><tr><td>US3</td><td>Supporting communication among all stakeholders</td><td>Mattermost</td><td>team, PO, AD</td></tr><tr><td>US4</td><td>Check the code</td><td>Taiga, Git (GitLab CE), Junit</td><td>PO, team</td></tr><tr><td>US5</td><td>Asymmetric remote pair programming</td><td>Saros (plugin Eclipse)</td><td>team, SM</td></tr><tr><td>US6</td><td>Check code quality and technical debt</td><td>SonarQube server</td><td>team, SM, (PO)</td></tr><tr><td>US7</td><td>Issue tracking and library monitoring</td><td>Bugzilla, SonarLint (plugin Eclipse)</td><td>team, (PO, AD)</td></tr><tr><td>US8</td><td>Track user stories into code and releases</td><td>Taiga</td><td>PO, team</td></tr></tbody></table>

Thus we searched the open source market and identified a number of open source components useful to satisfy the user stories listed above. The result of our study is shown in Table 2.

We decided to include these components as services in the CAS back end. We also added a front end in the form of an IDE like Eclipse [19] or IntelliJ IDEA [20].

# 4 Architecture of CAS

The Compositional Agile System (CAS) is based on two subsystems: the *CAS server*, whose architecture is based on microservices, and the *CAS client*, a normal IDE like Eclipse or IntelliJ IDEA (we are working also on an Atom client) enriched with some plugins.

Fig.1 shows the CAS architectural stack, available on any operating system able to host dockerized services. Each CAS server service (e.g. SonarQube, Taiga, GitLab, etc.) - represented by its own logo - has its own container, which includes a locale storage system. The environment architecture is compositional in the sense that each service is separate and new services can easily be added, following the approach to *agile software architecture* suggested in [5].

## 4.1 The CAS client

By CAS client we mean any IDE that developers use as the front end of the development environment. We have integrated two IDEs with CAS: Eclipse and IntelliJ IDEA. We are also working at integrating other IDEs such as Atom, an IDE developed and integrated with GitHub.
<figure><img src="image_3.png" /><figcaption>**Fig. 1.** CAS client-server architecture: the CAS server lower layer is the operating system, then the docker layer, and finally the services, each with its own web server and storage dbms. The CAS client components (i.e. Eclipse, which is shown in the figure, or IntelliJ IDEA) and their plugins are not dockerized. They rely on CAS server components to store and analyze developers’ data.</figcaption></figure>
The integration of each client consists of an original plug-in we developed for collecting developers data, in order to monitor productivity [13], plus other plugins available for the main CAS server services and necessary to support some user story.

**Eclipse** Eclipse is an integrated multi-language and cross-platform development environment. It is designed by a consortium called the Eclipse Foundation, which includes large companies such as IBM, Ericsson, HP, Intel, SAP. Eclipse is a free and open source software distributed under the terms of the Eclipse Public License.

Eclipse can be used for the development of a huge variety of software products. It can be used as a complete IDE for several programming languages, for instance: Java Development Tools (JDT) for the Java language, C/C++ Development Tools (CDT) the C/C++ language. Similarly, through plugins it is possible to manage XML, JavaScript, PHP, as also designing graphically a GUI for a Java application (i.e., Window Builder). Eclipse is considered an environment for Rapid Application Development.

The platform is focused on the use of plugins, which are software components designed for a specific purpose. Indeed, the whole platform is a set of plugins, including the basic version, and anyone can develop and edit the different plugins. In the basic version it is possible to program in Java, taking advantage of help functions such as automatic completion (“Code completion”), suggestion of the types of parameters of the methods, direct access to git and automatic rewriting of the code (“Refactoring function”) in case of changes in the classes.

Finally, since Eclipse has been written in Java, it is portable and available for Linux, macOS, Windows and other platforms.

**IntelliJ IDEA** IDEA (it was once known simply as IntelliJ) is an integrated development environment for the Java programming language. It has been developed by BRAINS and is available in both Apache and commercial proprietary editions. The first version of IDEA was the first IDE to integrate features such as code navigation and *code refactoring*. In a 2010 ranking, IntelliJ received the highest test score among the four most popular Java programming tools: Eclipse, IDEA, NetBeans and JDeveloper<fnref n="6" />.

In December 2014, Google announced version 1.0 of Android Studio, an open source IDE for developing Android apps, based on the Community edition of IDEA. IDEA has two editions: Community Edition (OSS) and Ultimate Edition (which is the proprietary version).

<footnote n="6">⁶ www.infoworld.com/article/2683534/infoworld-review-top-java-programming-tools.html.</footnote>

<footnote n="7">⁷ www.venturebeat.com/2014/12/08/google-releases-android-studio-1-0-the-first-stable-version-of-its-ide.</footnote>
## 4.2 Extending a CAS client

One of the main reasons for choosing Eclipse/IntelliJ is the large amount of plugins existing for both environments. The main examples are *saros*, *egit* and *sonarlint*.

Another reason is that every developer can build specific plugins in order to add new functions to her IDE. For example, we have introduced a keylogger plugin to record data concerning the actions performed by the developers.

The *saros* plugin allows remote pair programming, and supports synchronous text editing on a document shared by up to five devlopers.

The *egit* plugin integrates either GitLab or GitHub directly inside Eclipse orelliJ.

The *sonarlint* plugin allows to analyze the quality of the source code and it reports any problems during the editing.

The *logger* plugin helps developers to record and then to monitor and summarize their actions. Accordingly, the PO can analyze the productivity of the team or individual developers.

## 4.3 CAS services

**GitLab:** Git is an open source Version Control System (VCS), also used as Software Configuration Management (SCM) tool. Git allows to keep track of the changes made to the files of a project, keeping the history of all the changes made, so that it is always possible to access the different versions of the project's artifacts [22]. Git is more precisely a system for distributed version control (DVCS), since it allows a group of people to collaborate on the same file system, sharing it and keeping track of who does what.

It is always possible to restore, partially or completely, the structure of the base directory of a project so that there is a version of the files and subfolders with the changes that had been made at some time in the past.

Git is especially useful when working with plain text files, such as source code. In fact, it provides various tools to compare the different versions of a file and see what changes have been made between one version and another. Although numerous graphical interfaces are available, Git is usually used via the command line interface. For this reason it mostly suggested for software development, but could be also used in other areas. For example, it can be useful if a group of people write a book collaboratively using Microsoft Word or Latex.

The CAS server includes GitLab, a Git-repository manager providing a rich set of functionalities such as tools for DevOps lifecycle support, issue-tracking, and Continuous Integration/Continuous integration Deployment (CI/CD) pipeline features.

**Bugzilla:** Bugzilla is an issue tracker, a program that creates a service to record and manage problem reports. Bugs can be submitted to the system by anyone, and will be assigned to the developer who has been associated with the bug.
Bugs can have various types of status associated with them, along with user comments and examples of the error itself.

**Mattermost:** Mattermost is a scalable messaging system for team communication. It allows both direct and group-based communication. It supports topic or meeting-based channels. It offers string search functionality in messages and channels. Mattermost facilitates communication between teams by keeping all messages in one place. Those can be easily searched within the repository and are available for every team member everywhere. It is also possible to create an own chat solution hosted on a private cloud service.

In CAS, Mattermost is the main communication system, useful for the various iAgile ceremonies, especially if they are performed remotely and e.g., the PO is not co-located with the team such as in some sprint planning, daily meeting, sprint review or retrospective events.

**SonarQube** An important issue in iAgile - just like in Scrum - is the concept of Definition of Done. We have introduced in iAgile the concept of *Definition of Done* based on a tool for checking the quality of code. The tool we have chosen is SonarQube.

Traditional approaches to software quality management tend to postpone code testing until after its completion, and to complete it at the end of the development of the entire software. This kind of approach, at best, generates delays and the need to review the whole work, when even the smallest bug is found. In the worst case scenario, on the other hand, it pushes the delivery of low quality software with several defects, and difficult to maintain. To address this issue, Continuous Inspection is the goal of SonarSource, a company that focuses on software quality analysis, which goal is to enhance software quality along the entire development process. Accordingly, the tool SonarQube which is a service for the ongoing management of the technical debt has been developed to support Continuous Inspection.

SonarQube is an open-source program for continuous analysis of code quality. It is able to perform automatic static analysis of code to detect bugs, code smells, and security vulnerabilities on several programming languages. It offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities. It also integrates with Eclipse and Intelligence IDEA through the SonarLint plug-in.

A way to enrich a Definition of Done is via coding rules, namely rules that developers have to follow when writing their code. There are two ways to extend coding rules in SonarQube. The first is by writing coding rules using Java via a SonarQube plugin; the second is by adding XPath rules directly through the SonarQube web interface. The Java API is richer than the XPath one.

SonarQube might therefore be considered as a reference tool for analyzing the quality of software both continuously during development and postmortem at the end of the project.
The tool can be used both as a cloud service (i.e., SonarCloud) and as an open source package that can be hosted on own proprietary servers. In CAS we used the open source version, that has been included as a component of the CAS server. One of the most interesting advantages of SonarQube is the ability to track the evolution of a project's quality metrics over time. Every time an inspection is performed, users have a visual representation of the project's quality. It provides a snapshot of the code quality, including lagging indicators (problems already present) and leading indicators (problems that may arise in the future). Furthermore, it also provides services to address future issues, such as the code-review tools.

**Taiga:** Taiga is a free and open-source project management system able to host a product backlog and the related items of agile processes, like sprint backlogs and burndown charts. Backlogs are shown as a running list of all User Stories and related tasks belonging to the project. It is released under GNU AFFERO General Public License.

Taiga tracks the progress of a project using a taskboard whose template can be either Kanban or Scrum, or both. For iagile we use the Scrum template.

Taiga integrates chats and video conferencing functions with the use of third party services. The on-premise version of Taiga can be downloaded from its github repositories and used for free. This project management system can interface with web-based version control repositories like GitHub and Bitbucket. Taiga also provides several importers to facilitate migration from other proprietary software platforms, like Trello.

The project template can be configured using the following modules: Epics, Backlog, Kanban, Issues, Wiki, Meet Up. For Scrum active are: Backlog, Issues and Wiki; for Kanban the Kanban Board suffices. Combining the Backlog module and the Kanban Board we get a valid template for Scrumban.

The roles supported are: Product Owner, UX, Design, Front, Back, Stakeholder, External User. All roles except External User must be registered users. Each role gets specific access privileges: Epics, Sprints, User story, Tasks, Issues, Wiki. Access rights are read-only, new-item, modify-item, comment-item, delete-item.

## 4.4 CAS administration

Currently, the CAS administration consists mainly in controlling accesses to CAS services. Each service in CAS has its own access protocol. We plan to overcome this weakness in the next version.

Fig.2 shows the configuring process for CAS. First the server settings are defined, then a CAS View is added to the IDE Eclipse, then a new CAS instance can be used.
<figure><img src="image_4.png" /><figcaption>Fig. 2. Configuring CAS</figcaption></figure>

# 5 Comparison

We can compare CAS to other tools chosen by agile teams for software developments. The main contender is Jira, that is arguably the most comprehensive and popular tool used in software project management.

**Jira** Jira is a comprehensive issue tracking and project management system. It is, however, neither free nor open source.

It can be accessed either as a cloud service or installed locally. Jira provides a variety of services and, on top of it, one can add a series of tightly integrated tools to further expand. To have a meaningful comparison, we chose the Jira+Helpdesk offer, the one that maps CAS services more precisely.

Given the tight integration and the single sign-on features, installation and setup is far easier and straightforward with respect to CAS, which currently requires separate access configurations for the various services.

**Taiga vs Jira** Like Taiga, Jira also offers both Kanban and Scrum taskboard support. It is possible to setup User Stories, estimate them, assign them to specific persons. Thereafter, it is possible to start a Sprint or the Kanban board. It also offers a "Roadmap" page that presents a higher level of abstraction (Epics, for example). Several reporting options are available. However, Taiga got inspiration from Trello. Both value simplicity and creativity and require low learning effort from the users. Moreover Taiga supports interactions via its telephone app for iOS, Android, and Windows devices.

**GitLab vs. Bitbucket** Bitbucket is one of the main Git-based service for cooperative source management recommended for Jira; its features match closely those of GitLab and other similar services. It can be integrated in Jira using a single sign-on mechanism, though the integration is not very tight.
**Bugzilla vs Jira** Jira's name is a corruption of bugzilla, which was used by the Jira team before they produced Jira. In fact, originally Jira was a ticking service, and therefore this section is very mature and well integrated with the project management section compared to bugzilla.

**Sonarqube and Mattermost vs Jira** These services have no direct equivalent in the Atlassian platform. Sonarqube can be configured to work with Jira, using procedures similar to CAS, but no tight integration is possible. After discontinuing its internal instant communication services (Hipchat) Atlassian suggests to use Slack, arguably the most famous and mature service of its kind which is however not open source or free.

## 6 Conclusions and future works

The CAS environment has been developed in four months, and is currently used in research projects [11, 12] and by groups of students. So it has been tested for a very short time: the preliminary evaluations by the students are encouraging.

An important question that we should answer closing this paper is: which is the difference between iAgile and Scrum, and which impact has on development tools? This is a relevant question that has been already partially answered in [6, 7]. We now offer a new discussion after having built CAS.

<table><caption>**Table 3.** Comparing Scrum vs iAgile/CAS</caption><thead><tr><td>Scrum</td><td>iAgile</td></tr></thead><tbody><tr><td>Roles: PO, SM, team</td><td>New roles: Requirement Owner, Operative PO, PO team, expert in cybersecurity.</td></tr><tr><td>ScrumMaster</td><td>Military Facilitator.</td></tr><tr><td>Self organizing team</td><td>Team with both civil and military personnel, including at least one cybersecurity expert.</td></tr><tr><td>Contract: free</td><td>Contract: in-house or outsourced.</td></tr><tr><td>Simple user stories</td><td>Structured user stories.</td></tr><tr><td>Most popular tool: Jira (commercial)</td><td>Main tool: CAS (open source).</td></tr><tr><td>Shared physical taskboard</td><td>Digital taskboard (Taiga).</td></tr><tr><td>Face to face communication</td><td>Digital channels (Mattermost).</td></tr><tr><td>Metrics: chosen by the team</td><td>COSYSMO + development metrics.</td></tr><tr><td>Definition of Done: defined by the PO</td><td>Definition of Done including SonarQube analysis.</td></tr><tr><td>Various scalability models</td><td>LeSS-based scrum of scrums.</td></tr><tr><td>Product certification: difficult</td><td>Product certification in each sprint.</td></tr></tbody></table>

Tab.3 shows a comparison between Scrum and iAgile. After we built CAS we have appreciated how strongly connected are a development model and its
environment. For instance, we have yet to solve the problem of supporting scrums of scrums according to the LeSS model [21] using Taiga.

Another important issue is the combination of OSS licenses. The tools we have used have the licenses listed in Tab.4.

<table><caption>**Table 4.** OSS licenses used in CAS</caption><thead><tr><td>Component</td><td>License</td><td>version</td><td>link</td></tr></thead><tbody><tr><td>Eclipse</td><td>EPL</td><td>4.10</td><td>www.eclipse.org/eclipse/news/4.10/</td></tr><tr><td>Taiga</td><td>GNU AGPL v3</td><td>4.0.0</td><td>github.com/taigaio/</td></tr><tr><td>GitLab</td><td>MIT</td><td>11.11</td><td>about.gitlab.com/releases/</td></tr><tr><td>Egit</td><td>BSD</td><td>5.3</td><td>www.eclipse.org/egit/</td></tr><tr><td>Gitinspector</td><td>GPL v3</td><td>0.4.4</td><td>github.com/ejwa/gitinspector/releases</td></tr><tr><td>Mattermost</td><td>Apache 2.0</td><td>5.11</td><td>docs.mattermost.com/administration/changelog</td></tr><tr><td>Saros</td><td>GNU v2</td><td>15.0</td><td>www.saros-project.org/releases/</td></tr><tr><td>SonarQube</td><td>LGPL v3</td><td>7.7</td><td>www.sonarqube.org/downloads/</td></tr><tr><td>bugzilla</td><td>GPL (MPL)</td><td>5.0.6</td><td>www.bugzilla.org/releases/</td></tr><tr><td>PostGres</td><td>PostgreSQL</td><td>9.5/9.6</td><td>dev.mysql.com/doc/relnotes/mysql/8.0/</td></tr><tr><td>docker</td><td>Apache 2.0</td><td>18.09.6</td><td>docs.docker.com/engine/release-notes/</td></tr></tbody></table>

We note that all these licenses are different, so we have to study their composition [1].

Another issue that we have to study is how the evolution of the different services proceeds smoothly under Docker and with respect the other services included in the CAS. For instance, SonarQube evolves rapidly and its API changes.

**Acknowledgements** We thank prof. gen. Angelo Messina (rit.) for the interviews and the lively constructive discussions we had concerning iAgile. We thank for the support obtained with the project PNRM AMINSEP from CINI and from CNR/ISTC.

## References

1. Alspaugh, T.A., Asuncion, H.U., Scacchi, W.: Analyzing software licenses in open architecture software systems. In: ICSE Workshop on Emerging Trends in Free/Libre/Open Source Software Research and Development. pp. 54–57. IEEE (2009)

2. Ambriola, V., Ciancarini, P., Corradini, A.: Declarative Specification of the Architecture of a Software Development Environment. Software: Practice and Experience 25(2), 143–174 (1995)

3. Arseni, G.: Role of the Design Authority in Large Scrum of Scrum Multi-team-based Programs. In: Ciancarini, P., Sillitti, A., Succi, G., Messina, A. (eds.) Proc. 4th Int. Conf. on Software Engineering for Defence Applications (SEDA2015). Advances in Intelligent Systems and Computing, vol. 422, pp. 181–190. Springer-Verlag, Berlin (2016)

4. Aslam, H., Brown, J., Messina, A.: Affordance Theory Applied to Agile Development: A Case Study of LC2EVO. In: Ciancarini, P., Mazzara, M., Messina, A.,
Sillitti, A., Succi, G. (eds.) Proc. 6th Int. Conf. in Software Engineering for Defence Applications (SEDA2018). Advances in Intelligent Systems and Computing, vol. 925, pp. 24–35. Springer-Verlag, Berlin (2020)

5. Babar, M., Brown, A., Mistrik, I. (eds.): Agile Software Architecture. Morgan Kaufmann (2014)

6. Benedicenti, L., Messina, A., Sillitti, A.: iAgile: Mission Critical Military Development. In: Proc. IEEE Int. Conf. on High Performance Computing and Simulation. pp. 545–552. Genoa, Italy (2017)

7. Benedicenti, L., Ciancarini, P., Cotugno, F., Messina, A., Sillitti, A., Succi, G.: Improved Agile: A Customized Scrum Process for Project Management in Defense and Security. In: Mahmood, Z. (ed.) Software Project Management for Distributed Computing: Life-Cycle Methods for Developing Scalable and Reliable Tools, pp. 289–314. Springer (2017)

8. Chang, S., Messina, A., Modigliani, P.: How Agile Development Can Transform Defense IT Acquisition. In: Ciancarini, P., Sillitti, A., Succi, G., Messina, A. (eds.) Proc. 4th Int. Conf. on Software Engineering for Defence Applications (SEDA2015). Advances in Intelligent Systems and Computing, vol. 422, pp. 13–26. Springer-Verlag, Berlin (2016)

9. Ciancarini, P., Messina, A., Poggi, F., Russo, D.: Agile Knowledge Engineering for Mission Critical Software Requirements. In: Nalepa, G., Baumeister, J. (eds.) Knowledge Engineering and Software Engineering - Methods, tools, and case studies, Advances in Intelligent Systems and Computing, vol. 626, pp. 1–21. Springer-Verlag, Berlin (2018)

10. Ciancarini, P., Missiroli, M., Sillitti, A.: Preferred Tools for Agile Development: A Socio-Cultural Perspective. In: Proc. Int. Conf. on Objects, Components, Models and Patterns (TOOLS). Lecture Notes in Computer Science, vol. 11771, pp. 43–58. Springer-Verlag, Berlin (2019)

11. Ciancarini, P., Poggi, F., Rossi, D., Sillitti, A.: Improving bug predictions in multicore cyber-physical systems. In: Proc. 4th Int. Conf. on Software Engineering for Defence Applications (SEDA). pp. 287–295. Springer-Verlag, Berlin (2016)

12. Ciancarini, P., Poggi, F., Rossi, D., Sillitti, A.: Analyzing and predicting concurrency bugs in open source systems. In: Proc. Int. Joint Conf. on Neural Networks (IJCNN). pp. 721–728. IEEE (2017)

13. Coman, I.D., Sillitti, A., Succi, G.: A case-study on using an automated in-process software engineering measurement and analysis system in an industrial environment. In: Proc. 31st Int. Conf. on Software Engineering. pp. 89–99. IEEE (2009)

14. Cotugno, F.: Managing Increasing User Needs Complexity within the ITA Army Agile Framework. In: Ciancarini, P., Sillitti, A., Succi, G., Messina, A. (eds.) Proc. 4th Int. Conf. on Software Engineering for Defence Applications (SEDA2015). Advances in Intelligent Systems and Computing, vol. 422, pp. 1–12. Springer-Verlag, Berlin (2016)

15. Cugola, G., Ghezzi, C.: Software Processes: a Retrospective and a Path to the Future. Software Process: Improvement and Practice 4(3), 101–123 (1998)

16. Diebold, P., Ostberg, J.P., Wagner, S., Zendler, U.: What Do Practitioners Vary in Using Scrum? In: Proc. Int. Conf. on Agile Software Development. Lecture Notes in Business Information Processing, vol. 212, pp. 40–51. Springer (2015)

17. Galantini, L., Messina, A., Ruggiero, M.: Software Requirements Complexity Analysis to Support the “Advisory Network in to the Nation Fforces Build-Up”. In: Ciancarini, P., Mazzara, M., Messina, A., Sillitti, A., Succi, G. (eds.) Proc. 6th Int. Conf. in Software Engineering for Defence Applications (SEDA2016). Advances in Intelligent Systems and Computing, vol. 925, pp. 24–35. Springer (2020)
18. Gazioero, S., Marsura, R., Messina, A., Rizzo, S.: Capturing User Needs for Agile Software Development. In: Ciancarini, P., Sillitti, A., Succi, G., Messina, A. (eds.) Proc. 4th Int. Conf. on Software Engineering for Defence Applications (SEDA2015). Advances in Intelligent Systems and Computing, vol. 422, pp. 307–320. Springer-Verlag, Berlin (2016)

19. Holzner, S.: Eclipse Cookbook. O'Reilly (2004)

20. Krochmalski, J.: IntelliJ IDEA essentials. Packt Pub (2014)

21. Larman, C., Vodde, B.: Large-Scale Scrum: More with LeSS. Addison-Wesley, Boston (2016)

22. Magana, A., Muli, J.: Version Control with Git and GitHub. Packt (2018)

23. Messina, A., Cotugno, F.: Adapting Scrum to the Italian Army: Methods and (Open) Tools. In: Proc. 10th Int. Conf. on Open Source Systems (OSS). IFIP Advances in Information and Communication Technology, vol. 427, pp. 61–69. Springer-Verlag, Berlin, San Josè, Costa Rica (2014)

24. Messina, A., Fiore, F.: The Italian Army C2 evolution: From the current SIAC-CON2 land command & control system to the LC2EVO using agile software development methodology. In: Proc. Int. Conf. on Military Communications and Information Systems (ICMCIS). pp. 1–8. Brussels, Belgium (2016)

25. Messina, A., Fiore, F., Ruggiero, M., Ciancarini, P., Russo, D.: A new Agile Paradigm for Mission Critical Software Development. Crosstalk - The Journal of Defense Software Engineering 29(6), 25–30 (2016)

26. Naik, N., Jenkins, P., Newell, D.: Learning Agile Scrum Methodology Using the Groupware Tool Trello Through Collaborative Working. In: Barolli, L., Hussain, F., Ikeda, M. (eds.) Proc. Int. Conf. on Complex, Intelligent, and Software Intensive Systems. Advances in Intelligent Systems and Computing, vol. 993, pp. 343–355. Springer-Verlag, Berlin (2019)

27. Osterweil, L.: Software Processes are Software Too. In: Proc. 9th IEEE Int. Conf. on Software Engineering. pp. 2–13 (1987)

28. Valerdi, R.: The Constructive Systems Engineering Cost Model (COSYSMO). Ph.D. thesis, University of Southern California (2005)