Paolo Ciancarini
email: paolo.ciancarini@unibo.it

Daniel Russo
email: daniel.russo@cs.aau.dk

The Strategic Technical Debt Management Model: an Empirical Proposal

Keywords: Technical Debt, Strategic Management, Empirical Software Engineering

Increasing development complexity in software applications raises major concerns about technical debt management, also in Open Source environments. A strategic management perspective provides organizations with an action map to pursue business' targets with limited resources. This article presents the Strategic Technical Debt Management Model (STDMM) to provide practitioners with an actionable roadmap to manage their technical debt properly, considering both social and technical aspects. To do so, we pursued a theoretical mapping, exploiting a set of interviews of 124 carefully selected and well-informed domain experts of the IT financial sector.

Introduction

Software development is a complex social task, undertaken by groups of people who have to cope with existing legacy requirements, which need to evolve according to market expectations. Software is rarely developed from scratch, and its design integrity is shared among different people; moreover it changes in time, according to new and unpredictable requirements.

A primary concern of each organization which uses software is typically related to the maintenance of its assets, and the evolution of its products to deal with market competition [START_REF] Khadka | How do professionals perceive legacy systems and software modernization?[END_REF]. This is the most common situation were shortcuts are undertaken for several reasons, typically related to budget or schedule constrains. Long-term software maintainability is often neglected, and a short-term perspective is pursued. Architectural layering and code smells are the typical results of such management, which drifts to poor software quality. This kind of pattern is well-known: it was named by Cunningham as Technical Debt (TD) [START_REF] Cunningham | The WyCash portfolio management system[END_REF]. A growing community holds that software quality practices to improve systems' sustainability (e.g., refactoring) is ultimately a business decision [START_REF] Kruchten | Technical Debt: Reducing Friction in Software Development[END_REF]. Even in the domain of open source software there is a trend into exploiting the concept of technical debt as intentional, hence strategic: see for instance the study on self-admitted technocal debt found in [START_REF] Huang | Identifying self-admitted technical debt in open source projects using text mining[END_REF].

A support model is needed to allow developers and managers to make choices, i.e., whether or not to refactor [START_REF] Tempero | Barriers to refactoring[END_REF]. The idea itself of debt, taken from finance, implies to manage with limited resources and make the best out of it. This has the following implications.

Firstly, it relates to a rational trade-off between quality and budget. This idea is deeply rooted in software managers. Maturity models (e.g., CMMI) are valuable frameworks to predict software quality according to the minimal software process requirements. Typically, for critical software, a CMMI level of 4 or 5 is required by contract. It should assure the customer that the software house undertakes full refactoring. Accordingly, the price per LOC incorporates this effort, increasing the value of software. On the contrary, to secondary software systems, which will be replaced soon, will be devoted less budget. Indeed, there is no economic rationality to assign the same relevance to a system's application or component. Thus, in a situation of limited resources, ones have to make choices and assign priorities. This means that not all software components will receive the same amount of resources, leading to different levels of quality within the same information system. Hence, it needs to be adequately managed, making such choices rational. Technical debt may arise from random processes and poorly managed development. Therefore, a management model helps to identify the sources of technical debt, so to assign them the respective priority.

Secondly, it is quantifiable. Once you take a bank loan, you have to repay it with interest rates. Interests are not always negative when the need is to deploy some secondary code good-enough-to-work and focus on strategic applications. Nevertheless, it should also be clear that, at a certain point in time, one has to repay the debt with its interests.

Thirdly, it permits to make investments. We do not always have enough budget or time to implement all requirements. However, if stakeholders consider one application of strategic value to exploit competitive advantages, organizations need to make investments. So, they will earn much more than they have to pay for interests. Subsequently, software houses are willing to deploy some applications, also with high technical debt, since the earnings from their use will fully repay their later refactoring, letting make them profit.

Fourth, debt management needs to be considered. Issuing any debit note has its cost because it implies some operations which have to be undertaken to grant the loan. Typically, the investment needs to be planned, the debt traced, repaid, and managed. It is the same for software projects. Once the need for investments emerges, what does it mean in terms of technical debt management? So, questions like where is the debt, how and when are we going to repay it, and who should do that -have to be taken into great care.

In our research journey, we experienced all those issues in highly complex banking information systems [START_REF] Russo | Software quality concerns in the italian bank sector: the emergence of a meta-quality dimension[END_REF][START_REF] Russo | A meta model for information systems quality: a mixed-study of the financial sector[END_REF]. Also, we modeled those concerns in an ontology to make such knowledge representation inter-operable with other similar systems [START_REF] Ciancarini | Squap-ont: an ontology of software quality relational factors from financial systems[END_REF].

It is quite usual for a large organization to exploit different software houses for the evolution and maintenance of the information systems. This is a typical situation were technical debt emerges for several reasons:

-Architectural stratification as a consequence of a lack of conceptual integrity.

-Applications become rapidly outdated, afflict by high maintenance cost, and difficult to evolve. -Market competition pushes for new applications.

-Core System Optimization is costly, and the skills to evolve old mainframes are lacking.

The management of an information system's quality is, with such a setting, a challenging effort. Still, it is a pivotal task.

From a software management perspective, the four outlined financial implications suggest that the literature about technical debt [START_REF] Letouzey | Managing technical debt with the sqale method[END_REF][START_REF] Kruchten | Technical Debt: From Metaphor to Theory and Practice[END_REF] is unable to provide enough explanatory power of this phenomenon since the social part is missing. The reason is that technical debt is a socio-technical matter, and as such comprehensive handling is needed to address its complexity. In the end, managing technical debt means to control people.

To get a deep understanding of this crucial issue, we developed an innovative research design and involved 13 top managers of the IT banking industry for the items identification and 124 IT banking domain for the item validation and construct definition. We asked them to outline the most relevant software quality concerns related to banking information systems. We obtained 28 unique factors through the Delphi-like research design, which we mapped in the proposed managerial model.

The main contribution of our paper is the Technical Debt Management Model, gathered by highly relevant empirical research to provide the practitioner's community with a valuable tool to manage technical debt in a structured way.

In the rest of this paper, we will contextualize the metaphor of technical debt through the Agile triangle in Section 2. Moreover, we will briefly explain how we elicited software quality concerns by a high-level panel of banking industry experts in Section 3. After mapping the items, we propose a model to manage technical debt in Section 4. Finally, we conclude our study in Section 5.

The Technical Debt Triangle

The idea of technical debt is not a radically new one. In software engineering, we are well aware of software deterioration problems, where the complexity of software raises along with its evolution [START_REF] Lehman | Program evolution: processes of software change[END_REF], and reuse [START_REF] Ciancarini | A guided tour of the legal implications of software cloning[END_REF][START_REF] Ciancarini | Reverse engineering: a European IPR perspective[END_REF]. Similarly, software ages when it is not able to cope with new requirements due to irreconcilable technology paradigms [START_REF] Parnas | Software aging[END_REF].

To better explain the concurrent drivers of technical debt, we elaborate on the idea of the Agile Triangle [START_REF] Highsmith | Agile project management: creating innovative products[END_REF]. The three different dimensions of technical debt are budget, time, and scope. They are conflicting since it is not feasible to develop high-quality software with a low budget in a short time. This assumption is the baseline for any strategic software development model since you typically have to deal with limited resources. In an ideal situation, where resources are unlimited, there is no need for any strategic management effort, since strategic choices are simply not necessary. So, if we are focused on one corner, we are going to weaken the other two. If we are concerned about the scope, the relevant budget must be planned and sufficient time should be devoted to the project.If we need some new functionalities in a short time, it will have a high cost (since unplanned tasks require the organization to reschedule the work-flow), and quality will suffer from necessary fine-tuning before deployment, e.g., minor bug fix or refactoring. Finally, in case of a low budget, the project will last reasonably for an extended period, since few people can work on it. Moreover, the quality will also probably decrease since the most skilled (and paid) developers will work on other projects. These last two cases, which are the most frequent ones, typically lead to technical debt. Often, technical debt is beneficial because it permits to make investments in case of a project's budget, which is lower than that effectively needed. It is a continuous trade-off between long and short term perspectives. However, it needs to be a strategic (i.e., rational) decision. Often, technical debt is caused by subsequent uncontrolled, unplanned, and irrational tasks, which led to an explosion of its interests. At that point, organizations typically struggle because they feel to be on a sinking ship, were new applications just increase the debt, and no exit strategy is planned because they often do not know where to start to repay it [START_REF] Russo | Software quality concerns in the italian bank sector: the emergence of a meta-quality dimension[END_REF].

A strategic management model is a roadmap, where any organizations, according to its internal and external constraints, plan the (i) what, (ii) how, (iii) when, and (iv) where the technical debt should be managed.

Several mapping studies of the literature have been pursued, to identify and analyze the elements required to manage technical debt [START_REF] Fernández-Sánchez | Identification and analysis of the elements required to manage technical debt by means of a systematic mapping study[END_REF]. These studies have proposed some taxonomies, which could be useful to understand the most impelling issues while dealing with technical debt. However, a taxonomy is not a management model.

Other scholars introduced a maturity model for technical debt management, where they identified three levels of awareness in software factories; see for instance [START_REF] Yli-Huumo | How do software development teams manage technical debt?-an empirical study[END_REF]. Still, a proposal for a strategic management model is missing.

Research Design

Defining technical debt is hard [START_REF] Kruchten | Technical Debt: Reducing Friction in Software Development[END_REF]. In our research we identified the proxyconstruct of Software Quality Concern. Our domain experts were able to express openly, in a structured scientific procedure, all concerns regarding the software quality of the information systems they were working on.

To do so, we first identified 13 top managers of the IT financial industry to cover in, a representative way, the entire the addressed problem. Those experts were able to elicit several concerns, and, using the Delphi methodology, they were able to reach full consensus about the solicited items. Afterward, we identified other 124 domain experts through a stratified random sampling technique and asked them to express their level of agreement with the proposed items and to add personal opinions on every single item.

In that way, we were able to identify the 28 concerns, namely: For a better understanding of the concerns and the research design, refer to [START_REF] Russo | Software quality concerns in the italian bank sector: the emergence of a meta-quality dimension[END_REF][START_REF] Russo | A meta model for information systems quality: a mixed-study of the financial sector[END_REF].

After the elicitation and validation of the relevant concerns, we mapped them within an established technical debt management taxonomy [START_REF] Li | A systematic mapping study on technical debt and its management[END_REF]. Interestingly, Fig. 2. Software Quality Concerns the technical one has already been explored and led to the development of the SQALE method [START_REF] Letouzey | Managing technical debt with the sqale method[END_REF]. Indeed, SQALE identifies several technical sub-dimension and their related software metrics. However, we did not find in the scientific literature any similar framework addressing the social dimension. Therefore, we proposed a comprehensive managerial model. We pursued a theoretical mapping of the items within their related sub-dimensions. The outcome of the theoretical mapping for both technical and social dimensions is listed in Table 1. Finally, we were able to relate the empirically gathered items within a relevant managerial concept, which is the base of our Strategic Technical Debt Management Model, described in the next section.

Social

Strategic Technical Debt Management Model

The essential elements of any strategic management model are: situation analysis, strategy formulation, strategy implementation, and evaluation & control [START_REF] Wheelen | Strategic management and business policy[END_REF]. Such a model is typically non-linear since the surrounding environment changes more or less rapidly according to exogenous market-related factors. Consequently, we build our STDMM on such assumptions, fine-tailoring the evaluation and control phase, as represented in Figure 3. Thus, to strategically manage technical debt means to take into account:

1. Situation analysis (Environmental Scanning). The first step should raise awareness within the organization about its external and internal environment. Benchmarking competitors is always a good idea since there is no such absolute baseline. Indeed, markets that experience continuous requirements adaptations at high velocity may generate more TD concerning those who have to follow standardized quality processes (e.g., CMMI). Therefore, identifying External Opportunities & Threats supports effectively management decisions. This enables an organization to position itself to the market. Relevant questions might be: how does the market manage TD? Or where do competitors invest their debt? Afterward, Internal Strengths & Weaknesses have to be analyzed. In particular: how good is my organization in managing TD, or where go my investments, are fundamental questions to scan the internal environment. Typically, the first quantification of the already existing debt happens in this phase.

2. Strategy Formulation. After the assessment phase, the organization should draw its strategy to manage technical debt. Each strategy has four main pillars [START_REF] Wheelen | Strategic management and business policy[END_REF]. To make it self-evident, we propose key questions, useful to draw a strategy:

-Mission: why should an organization exploit TD? -Objective: which results do we want to accomplish, and by when? -Strategy: which plan do we define to achieve mission & objectives? -Policies: which internal guidelines for TD decision making do we want to have? Of course, these are high-level questions, which need to be tailored to any organization. However, they provide good-enough fit for every organization which aim is to manage its TD strategically. 3. Strategy Implementation. Once the planning activity has been concluded, the strategy should carry on.

In particular, specific programs and activities needed to manage effectively, TD has also to be outlined and followed. Continuous code inspection with quality metrics is a valuable example of this step. These kinds of plans have a price, which needs an ad hoc budget. Notably, every activity with no budget is poorly effective; thus, every organization should allocate enough resources. Otherwise, an STDMM is rather useless. Finally, procedures, intended as a sequence of steps needed to manage TD, are also part of the model. The aim is to leverage on TD to finance urgent software development needs or to repay it. However, how to manage these decisions in a complex organization is not trivial. Therefore, internal procedures guide both developers and management to use TD strategically. 4. Evaluation & Control. The last phase accounts for the continuous follow up of the strategy. Although the technical dimension of TD is a well known one [START_REF] Li | Architectural technical debt identification based on architecture decisions and change scenarios[END_REF], we introduced here also social aspects, which are equally important for an effective management strategy. We were able to elicit and validate through or research journey [START_REF] Russo | Software quality concerns in the italian bank sector: the emergence of a meta-quality dimension[END_REF][START_REF] Russo | A meta model for information systems quality: a mixed-study of the financial sector[END_REF] relevant social dimension regarding TD management, which is described in Table 1.

In particular, staffing and seniority impacts on TD, since a right mix of senior and junior developers enhances code quality. Moreover, the project team should be as stable as possible in time, as also suggested by Brook's law. Skilled developers on ongoing training are educated to deal with new complex tasks and technologies. For example, the presence of a training plan is a positive software quality indicator. Risk mitigation through contracts, which transfer TD to contractors (like Service Level Agreement), is a common practice for most organizations. These aspects poorly relate to technical assessment techniques of TD, although they have an impact on organizations. Thus, to effectively manage TD means to include risk and contracts within the strategy. Finally, any software is a collective product, which can be developed in different ways (e.g., internally or externally to the company). The involvement of stakeholders, especially outsources is a key quality issue. Continuous interaction is an effective way to have a complete overview of the development process and the use of TD. This is even more important for an outsourced project, where the customer typically has poor visibility about what is happening.

Conclusions

To conclude, this paper provides three main contributions. Firstly, it maps the social dimension of TD. Secondly, it proposes a strategic approach to manage TD. Finally, STDMM is a first attempt to include the social dimension of TD within a strategic technical debt management model. Future works will focus on the extension and validation of the proposed model.

Fig. 1 .

 1 Fig. 1. Technical Debt Triangle

  (1) Module interfaces complexity, (2) Interfaces architectural complexity, (3) Custom software quality, (4) Increase of maintenance costs, (5) Quality vs. Time & Budget, (6) Quality vs. System analysis, (7) System analysis vs. Documentation, (8) Documentation vs. Time & Budget, (9) New packages functionalities vs. complexity, (10) Packages vs. Documentation, (11) Packages documentation vs. System analysis, (12) Application & Maintenance contracts vs. Documentation, (13) International applications vs. Quality & Maintainability, (14) Domestic applications vs. Quality & Maintainability, (15) Measurement of software quality, (16) Lower developers' expertise and professionalism, (17) Contracting & Skills, (18) Lacking tools & Methodologies, (19) Establishment of internal and external development processes, (20) Developer's professionalism vs. Skills, (21) Developer's professionalism vs. Rates, (22) Web technologies vs. Methodologies, (23) Quality vs. Requirements, (24) Requirements vs. Methodologies, (25) Requirements vs. Technical jargon, (26) Data analysis vs. Functional analysis, (27) Functional analysis vs. Data modeling, (28) Documentation standards and tools.

Fig. 3 .

 3 Fig. 3. Strategic Technical Debt Management Model

Table 1 .

 1 Technical Debt type mapping

	Technical [13]

Acknowledgments

This work was partially funded by the Institute of Cognitive Sciences and Technologies (ISTC) of the Italian National Research Council (CNR), and the Consorzio Interuniversitario Nazionale per l'Informatica (CINI).


Paolo Ciancarini
email: paolo.ciancarini@unibo.it

Marcello Missiroli

Francesco Poggi
email: francesco.poggi@unimore.it

Daniel Russo
email: daniel.russo@cs.aau.dk

An open source environment for an agile development model

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.

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 [START_REF] Osterweil | Software Processes are Software Too[END_REF], 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 [START_REF] Ambriola | Declarative Specification of the Architecture of a Software Development Environment[END_REF][START_REF] Cugola | Software Processes: a Retrospective and a Path to the Future[END_REF].

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 [START_REF] Naik | Learning Agile Scrum Methodology Using the Groupware Tool Trello Through Collaborative Working[END_REF]. Even the concept of Definition of Done can be partially automated [START_REF] Diebold | What Do Practitioners Vary in Using Scrum?[END_REF] 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. [START_REF] Arseni | Role of the Design Authority in Large Scrum of Scrum Multi-teambased Programs[END_REF] 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.

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 [START_REF] Messina | Adapting Scrum to the Italian Army: Methods and (Open) Tools[END_REF]. A C2 system in this domain includes functional military areas to cope with humanitarian assistance, stability operations, counterinsurgency operations, and combat operations [START_REF] Messina | A new Agile Paradigm for Mission Critical Software Development[END_REF]. 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 [START_REF] Ciancarini | Agile Knowledge Engineering for Mission Critical Software Requirements[END_REF].

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 [START_REF] Messina | Adapting Scrum to the Italian Army: Methods and (Open) Tools[END_REF]. Table 1 shows how the Agile principles5 have been embedded in iAgile. iAgile has been introduced in order to develop LC2EVO, a military C2 system, aiming at shortening the "time-to-the-field" of new functions [START_REF] Messina | The Italian Army C2 evolution: From the current SIAC-CON2 land command & control system to the LC2EVO using agile software development methodology[END_REF] Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage iAgile systematically developed new incremental versions which were immediately tested on the field [START_REF] Messina | A new Agile Paradigm for Mission Critical Software Development[END_REF] Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Sprints lasted 4 weeks + 1 for certification [START_REF] Benedicenti | iAgile: Mission Critical Military Development[END_REF] Business people and developers must work together daily throughout the project.

Developers and users worked daily together [START_REF] Arseni | Role of the Design Authority in Large Scrum of Scrum Multi-teambased Programs[END_REF] Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. iAgile has been quite successful, exploting the enthusiasm of both civil and military developers [START_REF] Benedicenti | Improved Agile: A Customized Scrum Process for Project Management in Defense and Security[END_REF] The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Daily meetings and physical shared taskboard were used systematically [START_REF] Aslam | Affordance Theory Applied to Agile Development: A Case Study of LC2EVO[END_REF] Working software is the primary measure of progress.

The LC2EVO project executed about 30 sprints, each delivering a working increment [START_REF] Galantini | Software Requirements Complexity Analysis to Support the "Advisory Network in to the Nation Fforces Build-Up[END_REF] Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The project lasted 18 months, produced several releases with a string reduction of development costs [START_REF] Chang | How Agile Development Can Transform Defense IT Acquisition[END_REF]. Continuous attention to technical excellence and good design enhances agility. iAgile requires excellent technical capabilities [START_REF] Cotugno | Managing Increasing User Needs Complexity within the ITA Army Agile Framework[END_REF]. Simplicity-the art of maximizing the amount of work not done-is essential.

The "lean" approach implicit in iAgile shortened the workflow necessary to implement critical requirements [START_REF] Gazzerro | Capturing User Needs for Agile Software Development[END_REF]. The best architectures, requirements, and designs emerge from self-organizing teams.

The quality of the final system is high and is still being used [START_REF] Galantini | Software Requirements Complexity Analysis to Support the "Advisory Network in to the Nation Fforces Build-Up[END_REF]. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Projects based on iAgile used systematically retrospectives [START_REF] Cotugno | Managing Increasing User Needs Complexity within the ITA Army Agile Framework[END_REF].

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.

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 [START_REF] Valerdi | The Constructive Systems Engineering Cost Model (COSYSMO)[END_REF] 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 [START_REF] Ciancarini | Preferred Tools for Agile Development: A Socio-Cultural Perspective[END_REF]. 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. 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 [START_REF] Holzner | Eclipse Cookbook[END_REF] or IntelliJ IDEA [START_REF] Krochmalski | IntelliJ IDEA essentials[END_REF].

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 [START_REF]Agile Software Architecture[END_REF].

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. The integration of each client consists of an original plug-in we developed for collecting developers data, in order to monitor productivity [START_REF] Coman | A case-study on using an automated in-process software engineering measurement and analysis system in an industrial environment[END_REF], 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 IntelliJ IDEA (it was once known simply as IntelliJ) is an integrated development environment for the Java programming language. It has been developed by JetBrains and is available in both Apache and commercial proprietary editions. The first version of IntelliJ 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, IntelliJ IDEA, NetBeans and JDeveloper 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 IntelliJ IDEA 7 . IntelliJ IDEA has two editions: Community Edition (OSS) and Ultimate Edition (which is the proprietary version).

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 or IntelliJ.

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.

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 [START_REF] Magana | Version Control with Git and GitHub[END_REF]. 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 IntelliJ 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.

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.

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 avaialable. 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.

Fig. 1 .

 1 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.

Fig. 2 .

 2 Fig. 2. Configuring CAS

Table 1 .

 1 iAgile embeds agile principles

	Agile principles	iAgile
	Our highest priority is to satisfy the customer
	through early and continuous delivery of valuable
	software.

Table 2 .

 2 Mapping the user stories and main iAgile roles on some open source tools

	#	User Story	Tool	iAgile roles
	US1 Estimating and monitoring COSYSMO, COCOMO AD
	US2	Checking the team produc-tivity	Taiga, GitInspector, log-ger plug-in	PO, SM, team, AD
	US3	Supporting communication among all stakeholders	Mattermost	team, PO, AD
	US4 Check the code	Taiga, Git (GitLab CE), Junit	PO, team
	US5	Asymmetric remote pair programming	Saros (plugin Eclipse)	team, SM
	US6	Check code quality and technical debt	SonarQube server	team, SM, (PO)
	US7	Issue tracking and library monitoring	Bugzilla, SonarLint (plu-gin Eclipse)	team, (PO, AD)
	US8	Track user stories into code and releases	Taiga	PO, team

https://agilemanifesto.org/iso/en/principles.html

www.infoworld.com/article/2683534/infoworld-review-top-java-programmingtools.html.

[START_REF] Benedicenti | Improved Agile: A Customized Scrum Process for Project Management in Defense and Security[END_REF] www.venturebeat.com/2014/12/08/google-releases-android-studio-1-0-the-firststable-version-of-its-ide.

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.

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.

Conclusions and future works

The CAS environment has been developed in four months, and is currently used in research projects [START_REF] Ciancarini | Improving bug predictions in multicore cyber-physical systems[END_REF][START_REF] Ciancarini | Analyzing and predicting concurrency bugs in open source systems[END_REF] 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 [START_REF] Benedicenti | iAgile: Mission Critical Military Development[END_REF][START_REF] Benedicenti | Improved Agile: A Customized Scrum Process for Project Management in Defense and Security[END_REF]. We now offer a new discussion after having built CAS. 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 [START_REF] Larman | Large-Scale Scrum: More with LeSS[END_REF] using Taiga.

Another important issue is the combination of OSS licenses. The tools we have used have the licenses listed in Tab.4. We note that all these licenses are different, so we have to study their composition [START_REF] Alspaugh | Analyzing software licenses in open architecture software systems[END_REF].

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.


Laurent Barbiéro
email: barbiero@dakar.orstom.sn

Brigitte Van Vliet-Lanoe

The alkali soils of the middle Niger Valley Origins, formation and present evolution

Keywords: non-saline alkali soils/sodic soils, soil genesis, de-alkalization, Sahel, Niger

In Niger Republic, the regional development of irrigation along the river Niger is confronted with an large extension of alkali soils. The study of one of these areas, on the Liptako bedrock, reveals a concentric soil distribution: in a zone of brown soil with abrupt textural change and alkaline in depth (stagnic Solonetz), appears a ring of brown steppe soils (cambic Calcisol), and zones of alkali soils (Solonetz). These alkali soils are not saline but their soil solution is more concentrated than in brown steppe soils. The study of the abrupt contact between brown steppe soils and alkali soils shows morphological and geochemical changes, due to calcite and fluorite precipitation.

The detailed study of this contact demonstrates a present transformation of alkali soils into brown steppe soils. Therefore, it appears that soil alkalization is no longer in process on the terraces of the river Niger. The formation of brown steppe soils and alkali soils may be explained by the existence of a former pond. This hypothesis is supported by aerial pictures and microscopic observations. It is also consistent with a recent study of the hydrology of sahelian ponds and with considerations on the chemical quality of the runoff.

Introduction

In the semi arid area of the middle Niger valley (Niger Republic), irrigation techniques had been developed to respond to aridity and increasing population (fig. 1). Initially, the agricultural practices most suitable for the region have been tested on a few trial areas. Often, the main threat to sustainable agriculture is the reduced fertility associated to alkali soils existing prior to irrigation. [START_REF] Bozza | Mise en valeur hydro-agricole des terrasses du fleuve Niger. Bilan des deux premières années d'expérimentation-développement[END_REF] observed that up to 70% of the area of some irrigated perimeters were covered by non saline alkali soils.

These alkali soils develop always in contact with the non alkaline brown steppe soils (Barbiéro and Berrier, 1994). The contact between the two soil types is always so abrupt that in the all West-Africa surveys, this two units were represented as associated soil unit [START_REF] Gavaud | Les grands traits de la pédogenèse au Niger méridional[END_REF][START_REF] Maignien | Notice explicative de la carte pédologique du Sénégal au 1:1 000 000. 63 p. + Carte[END_REF]. Such soil distribution has been observed along the river Falémé in Sénégal [START_REF] Chauvel | Carte pédologique du Sénégal Oriental au[END_REF] and also in semi-arid Pakistan [START_REF] Choudhri | Calcareous soils in West Pakistan[END_REF]. However, this pattern differs clearly from what exists in the Niger valley in Mali, where a shallow water table is responsible for present alkalization [START_REF] N'diaye | Evaluation de la fertilité des sols de l'Office du Niger (Mali)[END_REF], Valles et al., 1989a, Bertrand et al., 1993, 1994).

This specific distribution of soil units observed in the Niger valley in Niger Republic leads to the question of their origin; it is the first objective of this paper. The main difference between the two soil types (alkali soil and brown steppe soil) is the soil solution being more concentrated in alkali soils although alkali soils are non-saline. Therefore, two hypothesis are proposed to explain soils genesis: (i) soil alkalization is induced by the concentration by evaporation of accumulated dilute solutions; (ii) the absence of soil alkalization where brown steppe soils are observed result from localised percolation of dilute water.

The second objective of this paper is to explain the present evolution of alkali soils, i.e., does the alkalization, corresponding to such distribution of soil units, progress or regress, which is essential for a sound management of irrigation in these areas using local waters.

Materials and Methods

The study was located at «Lossa»-Niger (13°54N 1°35E) in the 90 ha domain under irrigation (fig. 1). This irrigated area lies at the bottom of a small 10 km²-catchment on the left side of the river Niger. The northern part of the domain (15 ha) was survied in detail (fig. 2).

The climate belongs to the type III semi-arid of the African zonation [START_REF] Griffiths | Climates of Africa[END_REF], with a short rainy season from June to September (400 mm rainfall). The annual potential evapotranspiration is 2400 mm. During the 8 months of the dry season, dry winds are blowing from the northeast. The mean annual temperature is about 33°C with maximum around 47°C recorded. The water table located at 30 to 40 meters deep is not subject to evaporation process.

The soil has a sandy clay texture and develops from an alkaline gneiss with biotite. This parental material, locally call « Liptako bedrock », is part of the regional Birrimian substract. The regolith (i.e. weathered parental material) of this crystaline bedrock appears between 1 and 1.2 metre depth. Preliminary studies of the whole catchment shown three major differenciations in the sandy clay soil properties (Barbiéro, 1995): 1 -a non-saline alkali soil (pH s = 8.5 to 9.8 (s = on saturated paste), EC s = 0.22 to 0.32 dSm -1 , S.A.R. = 12 to 28 (mmolL -1 ) 1/2 , E.S.P. = 5 to 40 %); 2a non-alkaline brown steppe soil (pH s < 8.4, EC s = 0.07 to 0.22 dSm -1 , E.S.P. = 0.5 to 2%), which is much more fertile; 3 -a brown soil with abrupt textural change alkaline in depth (in depth: pH s = 9.1 to 9.3, EC s = 0.15 to 0.25 dSm -1 )

Soil survey

A detailed soil pH survey of the 15 ha north of the irrigated domain was conducted on a 10 metre squared grid. Soil were collected with an auger at a depth of 40 cm. PH value was measured in the laboratory on saturated pastes. Soil morphology was observed and described in 18 pits inside and outside the irrigated area (fig. 2). PH datas combined with morphological observations were used to delimit the soil units. Two soil types were observed in the 15 ha irrigated area: the nonsaline alkali soil and the non-alkaline brown steppe soil. Evidence of brown soil with abrupt textural change alkaline in depth was found at the limit of the area. Therefore, the survey was extended outside the irrigated area to cover all the catchment bottom and to understand the soil distribution.

An aerial picture of the catchment was used to complete the observations (I.G.N., 1975, phot. 4).

Morphology and geochemistry

A 7 m length and 1.2 m deep trench was dug across an abrupt contact between brown steppe soils and alkali soils (fig. 2) localised by the soil survey. The trench have been show to be chemically and morphologically representative of the two soil types characteristics. The pedological layers were identified, described and sampled for laboratory characterisation and geochemistry (fig. 3). Air dry soil block were impregnated with a polyesther resin and vertical thin sections (70 x 110 mm) were made and described according to [START_REF] Brewer | Fabric and mineral analysis of soils[END_REF]. Precipitation forms of the calcite in calcareous concretions were observed using a SEM (XL 20 Philips at 15 kV) with a LINK Analytical eXL energy dispersive X-Ray system.

Over one face of the trench, in situ pH values were measured (on saturated paste) on a regular grid (0.1 m deep x 0.2 m wide) to locate in detail the variation of geochimical characteristics. To define and measure the general geochemical soil characteristics along the trench, 72 soil samples were also taken according to a coarser regular grid (0.1 m deep x 0.95 m wide , fig 3). Saturated paste extract were analysed by ion chromatography (Dionex). The quantified elements were : Na + , K + , Ca ++ , Mg ++ , NH 4 + , Cl -, SO 4 --, F -, NO 3 -, NO 2 -, PO 4 ---, acetates, formates and oxalates. To distinguish and quantify fluoride from small organic anions (acetates and formates) a second analysis was performed using the sodium tetraborate as eluant. Althrough, sample volumes were too small for titration of the Carbonate alkalinity (i.e., (HCO 3 -) + (CO 3 2-)), which constitues the major anionic compound, its value was derived from the ionic balance of the solution. An acid titration (Gran method, 1952) was performed on three samples giving similar results as the estimation by the ion balance. Silica was quantified by colorimetry (Na-molybdate method at pH 1.6 (Charlot, 1961)). Equilibrium's computations were performed using the « Aqua » software package (Vallès and De Cockeborne, 1992), derived from the « Gypsol » model (Vallès and Bourgeat, 1988).

Using the same procedure, an analysis of the geochemical content of surface runoff water was undergone. Runoff water was collected on the upslope of the studied area after rain in four different puddles. The chemical quality of the runoff water, regarding the risk of alkalization, was estimated using the concept developed by Vallès et al. (1991).

Results

soil distribution in the landscape

Figure 2 show the extension of the three soil units in the studied area. Three « concentric domains » are delimited:

-In the centre of the area, a large zone (3 ha) of high pH-values (> 8.5) is observed. Smaller alkaline zones are also found. The increase of pH-values is abrupt at the edge of these zones. They correspond to alkali soils. Due to its prismatic structure and natric horizon, this soil belong to Solonetz.

-These alkaline zones are surrounded by a larger area where pH-values range from 7 to 7.5. It corresponds to non alkaline brown steppe soils (cambic Calcisol).

In the outermost part of this area, another domain of high pH-values (7.5 to 8.5) in contact with the non alkaline brown steppe soils was found. However the transition between this domains is progressive. This large zone correspond to brown soil with abrupt textural change, alkaline in depth. This third soil unit observed correspond to the stagnic Solonetz.

Soil morphology

Figure 3 present the soil transect along the 7 m trench in the transition zone (fig. 2). The alkali soil are located on the left end of the trench and the brown steppe soil in the right end. The alkali soil show a shallow grey (10YR6/1) sandy and coherent superficial horizon (around 0.05 m) overlying a grey (10YR5/2) sandy clay and hardly coherent material (around 70 cm depth) with a large prismatic structure (from 0.5 to 1.2 m wide) and a massive substructure (fig. 4). The weathered bedrock below this prismatic layer presents various lime (CaCO 3 ) patterns: nodules, soft powdery volumes of 0.05 to 0.10 m, and CaCO 3 pseudo-mycelia. The calcareous nodules present a white indurated cortex and a grey compact centre (fig. 5a). These nodules are solid and impossible to break under finger pressure. The calcite crystals in the nodules do not present any corrosion patterns (phot. 1). The weathered bedrock with undisturbed petrographic structure appears near 1 m deep.

Althought, the brown steppe soils had a similar soil texture as the alkali soil, large differences in the soil structure are observed. The superficial sandy horizon is generally thicker. It overlies a brown (10YR5/5) sandy clayed horizon with prismatic structure (0.1m) and cubic substructure (cubes ranging from 0.01 to 0.02m not represented in fig. 3). The weathered bedrock presents fewer calcareous precipitates than in the alkali soil. They include friable nodules, soft powdery volumes (from 0.02 to 0.05 m) and pseudomycelia veiling. These calcareous nodules are very fragile (fig. 5b). A remaining cortex is observed and the centre of the nodule is generally composed of soft powdery calcite. The calcite precipitates as irregular spherules (phot. 2), sometimes rhomboid as those observed by Bouzigue et al. (1992) in a vertisol of Cuba. The weathered bedrock with undisturbed petrographic structure also appears near 1 m deep.

In the brown soil with abrupt textural change, alkaline in depth, the superficial sandy horizon is 0.25 m thick. Its color is 10YR6/2 and locally bleached (10 YR7/1) in the lower part of the horizon. An abrupt horizontal and regular transition leads to a brown (10YR5/4 to 5/5) sandy clay horizon, 0.3 to 0.4 m thick with subangular polyedric structure. Near 0.6 m depth, a significant change is observed in the color (10 YR5/2), in the structure (massive) and in the cohesion (hardly coherent). The weathered bedrock appears at 0.9 m depth, including lime: nodules and pseudomycelia veiling. The weathered bedrock with conserved petrographic structure appears near 1.1 m deep.

Thin section observations under an optic microscope of the alkali soils and brown steppe soils reveal many microscopical structures of pond organisms: i.e. sponges spicules, diatoms, cyanophyceae shells. These structures do not appear in brown soils with abrupt textural change, alkaline at depth.

3.3

Chemistry of alkali soils and brown steppe soils.

The soil solutions show distinct chemical facies, from a calcic bicarbonate type in the brown steppe soil to a sodic bicarbonate type in alkali soil. The changes in the chemical facies along the 7m length trench are presented in fig. 6 and8. A similar behaviour of sodium, fluoride, carbonate, alkalinity and T.D.S. is observed, opposite to the behaviour of calcium and magnesium. Fluoride concentration are particularly high and were found to be a major component (fig. 6d).

The chemical analysis data were sorted according to their sodium amount and presented in concentration diagrams (fig. 7). In these diagrams, the concentration factor is defined as CF = [Na]/ [Na] 0 where [ ] denote molality and [Na] 0 refers the lower Na molality at the origin of the concentration diagram.

Soil solutions are more concentrated in alkali soils than in brown steppe soil. Fluoride amount and carbonate alkalinity increase consistently but less rapidly than sodium concentration; calcium, magnesium and potassium amount decrease. An initial approximately constant silica molality is followed by an increase at elevated concentration factors. The pH-value of soil solution increases with sodium concentration. Chloride and sulfate varie similarly. However, their amounts are low, their relation with sodium is more scattered and they do not present a particular repartition along the large pit.

Morphological and geochemical transition between alkali soils and brown steppe soils

The bedrock does not show any lateral variations of facies in the 7m lenght trench. The morphological transition between the alkali soil and the brown steppe soil is highlighted by a latteral change in the grey (10YR5/2) sandy clayed matrix of the alkali soil. Centimetric brown (10YR5/5) volumes appear progressively in the matrix and become predominant at x = 4 m in fig. 3. This defines the morphological transition between the two soil types. The changes from a wide prismatic massive structure to a finer prismatic cubic structure indicate a transition in the same place.

Close to this transition, the strength of the calcareous nodules is intermediate between the two former descriptions (fig. 5c). They can be crushed on a knife blade. Two types of calcite precipitates are observed in these nodules. Crystals of calcite similar to those described in the alkali soil are observed, though with many dissolution patterns (phot. 3). Such dissolution patterns of the calcite in basic solutions were described by [START_REF] Delmas | Corrosion patterns of the calcite: typology and evolutive sequences[END_REF]. Calcite similar to the spherules observed in the brown steppe soils are also found in the same nodules.

The geochemical transition can be located using the distribution of Total Dissolved Substances (T.D.S.) of the saturated paste extracts (fig. 8). This geochemical transition is offset of 1 m to the left, compared to the morphological transition (fig. 9).

Quality of the Runoff waters

The chemical analysis of the runoff waters are reported in the table I. The runoff waters are very dilute (T.D.S. ranges from 1.2 to 4.8 meq.L -1 ) but present a positive Calcite Residual Alkalinity (ARG calcite = Alkalinity -(Ca)) ranges from +0.4 to +1.1 meq.L -1 (Van Beek and Van Breemen, 1973) and therefore belong to the carbonate alkaline familiy [START_REF] Valles | Invariant criteria for irrigation water quality assesment in arid and semi arid regions. in Genesis and control of fertility of salt affected soils[END_REF]. Such waters evolve in a carbonate alkaline way by concentration.

IV discussion

The geochemical data suggest that carbonated alkalinity an fluoride are controlled by a geochemical process. Calcium and magnesium are also clearly controlled. Calcite precipitate are observed in alkali soil and brown steppe soil and the equilibrium with respect to calcite is reached. Moreover, fig. 10 shows that the soil solutions are also in equilibrium with respect to fluorite (CaF 2 ) in the alkali soil. The precipitation of fluorite in the alkali soil is concomitant with that of calcite, although the presence of fluorite could not be verified by XRD due to its low contents. Calcite and fluorite precipitation explains the major change in the chemical facies between brown steppe soils and alkali soils. Calcite precipitation is an usual mechanism in alkalization processes. However, fluorite precipitation, well known in saline alkali soils or alkaline brines (Darragi et al., 1983[START_REF] Gueddari | Géochimie et thermodynamique des évaporites continentales. Etude du lac Natron en TANZANIE et du Chott el Jerid en TUNISIE[END_REF][START_REF] Chernet | Preliminary observations concerning the genesis of hight fluoride contents in the Ethiopian Rift[END_REF] and suspected by [START_REF] Jacks | Geochemistry of calcic horizons in relation of hillslope processes, Southern India[END_REF] in south India, has never been reported in non saline alkali soils (Barbiéro et al., 1995). It amplifies the geochemical control of calcium which is initiated by the calcite formation. Microanalysis conducted on the calcareous precipitates indicate a Mg 2+ content of 2% in the calcite. This phenomenum cannot explain the control of Mg 2+ observed in the soil solutions. Magnesian silicate formation occurs probably simultaneously (Barbiéro, 1995[START_REF] Marlet | Field study and simulation of geochemical mechanisms soil alkalinisation in the sahelian zone of Niger[END_REF] as observed in other sahelian regions such as Mali (Valles et al., 1989b) and Chad [START_REF] Gac | Geochemical behaviour of silica and magnesium during the evaporation of waters in Chad[END_REF]. All these precipitations use up the bivalent cations and induce a significant increase in the Sodium Adsorption Ratio (S.A.R.).

The alkaline and sodic environment induces clay dispersion, decrease in aggregate stability and an important decrease of soil hydraulic conductivity. The soil becomes very compact and the resistance to penetration increases drastically. A very hard crust appears at the soil surface after rainfall (Barbiéro, 1995). These physical consequences of alkalization are a well-known phenomena (Sheinberg and Letey, 1984;Abu Sharar et al., 1987;[START_REF] Sumner | Sodic soils ", new perspectives[END_REF].

Origin of the soil geochemistry.

The main difference between the two soil types is the soil solution being more concentrated in alkali soils which result in the precipitation of calcite and fluorite. Therefore, two hypothesis are proposed to explain soils genesis: (i) soil alkalization is induced by the concentration by evaporation of accumulated solutions; (ii) the absence of soil alkalization where brown steppe soils are observed results from localised percolation of dilute water.

None of this hypothesis is exclusive; the two mechanismes can occurs at the same time depending of hydrological regime zonal distribution. Indication of the former hydrological environment that will explain the soil formation was researched in the present features of the studied area.

The soil units show a concentric distribution. On the aerial picture (phot. 4), structures associated with former pond limits are observed in the valley bottom, in the presently irrigated area of «Lossa». The limits of the pond outlined in phot. 4, and that intersect successively, show clearly that former pond had moved several time southwards. The formation of this pond is explained by the presence of the dune and the sandy bank of the river Niger blocking the runoff of water northward and north-westward. Nowadays, the bank is discontinuous and the catchment is open on the Niger alluvial valley.

Indices of this former endoreic behaviours of the «Lossa» catchment are found in the soil. The numerous structures of aquatic microscopical organisms, observed in alkali soils and brown steppe soils support the existence of an old pond on top of the two soils.

The water in the former pond originates from local runoff. The runoff water collected up slopes from the site show ambiguous chemical characteristics. They are dilute waters, undersaturated with respect to calcite, fluorite and magnesian silicate. Such water can leach soluble salts of the soil by percolation. However, their alkalinity is higher than their calcium amount. They evolve in an carbonate alkaline way by concentration if they evaporate (Van Beek and Van Breemen, 1973, Cheverry, 1974, Droubi et al., 1980[START_REF] Valles | Invariant criteria for irrigation water quality assesment in arid and semi arid regions. in Genesis and control of fertility of salt affected soils[END_REF]. The fate of soil in contact with this type of solution depends on the balance between evaporation and percolation.

The zonation of two constrasted hydrological regimes had been described by [START_REF] Desconnet | Typologie et caractérisation hydrologique des systèmes endoréiques en milieu sahélien (Niger Degré carré de Niamey[END_REF] in actual sahelian ponds. During and after rainfall, the pond fills up with runoff up to a « high level ». When the water supply stops, a consequent drainage is observed down to a « low level ». From then on, the drainage is blocked and the remaining water only evaporates. The shift from a drainage to an evaporation process is associate to the presence of a clay carpet in the center of the pond, that reduces considerably infiltration.

All these observations and remarks match and allow to put forth a model of soil genesis in the study area (fig. 11). Initially the catchment bottom was probably cover by brown soil, alkaline in depth resulting from the bedrock weathering in semiarid conditions. Alkali soils and brown steppe soils proceed from two contrasted hydrological regimes in an old pond, supplied by dilute but alkalinizing runoff water. The percolation of the water between the high and the low level of the pond has probably transformed the brown soil alkaline in depth into brown steppe soil. In constrast, evaporation and concentration of water under the low level intensified alkalization and led to alkali soils in the centre of the pond.

Present evolution of the soil.

The endoreic feature explains the soil origin by redistribution of alkalization in the valley bottom. Nowadays, since the pond has disappeared, the present dynamic of these two soil units has to be considered. The contact between brown steppe soil and alkali soil is abrupt and shows a significant inclination from the vertical (fig. 3). Such contact between two very contrasted soil units, from a chemical and morphological point of view, appears like a lateral transformation. The inclination of the contact suggests a transformation of alkali soil into brown steppe soil if the evolution is downwards [START_REF] Fritsch | A structural approach to the regolith. Identification of structures, analysis of structural relationships and interpretation[END_REF]. However, it suggests an alkalization if the transformation is upwards under the influence of evaporation. Small grey volumes are observed in the brown matrix and brown volumes are observed in the grey matrix. These volumes can be interpreted as precursors or as remnants; they do not give any information about the direction of the transformation. A decisive hint is provided by the structure and aspect of calcareous nodules (fig. 5 a, b, c; phot. 1, 2 and 3). The nodules are compact and stable in the alkali soil, composed of calcite and quartz. The cortex is continuous. They are weakened near the contact zone and disappear in the brown steppe soil. The remaining cortex which is observed in the brown steppe soil is discontinuous, does not correspond to a structure in formation, and indicates a degradation of these nodules along the trench. The nodules can only be formed in the alkaline environment and are destroyed when the grey matrix of alkali soil is invaded by brown matrix of brown steppe soils. The disaggregation of the nodules is confirmed by the dissolution patterns of calcite observed near the transition zone. Intact nodules being attributed to alkali soils, this dynamic of the calcite shows a regression of alkali soils.

The detailed study of the contact demonstrates a natural transformation of alkali soils into brown steppe soils. The gap of 1 meter (fig. 9) observed between morphological transition (changes in colour, structure, compactness, fig. 3 and4) and geochemical transition (increase in the TDS on the « saturated paste extract », fig. 8) shows that the alkali soil lost its geochemical properties before acquiring the morphology of brown steppe soils. This gap shows that the transformation is in process.

The transformation generates an abrupt boundary between alkaline and brown steppe soils. It probably results from a "funnel effect" due to the hydrodynamic properties of the soils. At each rainfall, the water runs over the surface of the alkali soil, which is hardly permeable. It percolates through the more permeable brown steppe soil (Barbiéro, 1995).

The boundary between brown steppe soils and brown soils with a abrupt textural change is more diffuse because this zone is located on the edge of the old pond and was rapidly dried off after the rain, and the amount of percolated water is low.

V. Conclusion

Brown steppe soil and alkali soils are two associated soil units frequently observed in the West-African Sahelian zone. One of this association was studied here in the middle valley of the river Niger (in Niger Republic) to understand the origins and the present evolution of alkali soils.

The soil distribution probably results from a former pond which induced brown steppe soils and alkali soils by zonation of two contrasted hydrological regimes. From a geochemical point of view, alkalization is caused by concentration of the soil solution, which evolves in an carbonate alkaline way, and by precipitation of calcite, fluorite and probably magnesian silicates. The studied area of «Lossa» appears representative of the regional soil alkalization. Soil units distribution and geochemical processes similar to the «Lossa» site were observed in other sites, even on alluvial deposits downslope (for example «Sona» (13°58N 1°34E), [START_REF] Guero | Organisation et propriétés fonctionnelles des sols de la vallée du moyen Niger[END_REF][START_REF] Bozza | Mise en valeur hydro-agricole des terrasses du fleuve Niger. Bilan des deux premières années d'expérimentation-développement[END_REF][START_REF] Valet | Approche statistique et prédiction du comportement et du fonctionnement hydrique des sols[END_REF]. Nevertheless, pond inducing alkaline features in soils can not be generalised to the whole Sahelian zone. More often, the development of acid gley is observed below sahelian pond [START_REF] Gavaud | Les grands traits de la pédogenèse au Niger méridional[END_REF]. Such difference are probably due to opposite water quality and drainage conditions. The studied case differs from the interior delta in Mali, where a shallow water table is observed and where alkalization is in process [START_REF] N'diaye | Evaluation de la fertilité des sols de l'Office du Niger (Mali)[END_REF], Bertrand et al., 1993, 1994).

The « Lossa » catchment is presently opened on the alluvial valley of the river Niger and the soils are no longer in equilibrium with the local environmental conditions. The transformation of alkali soils into brown steppe soil expresses an evolution towards a new equilibrium. This natural evolution opens up the possibility of accelerating de-alkalization of certains areas suitable for agriculture. This natural de-alkalization, fast at a soil formation time scale, was furthered to improve the soils by proper management of irrigation and crop (Barbiéro et al., 1995(Barbiéro et al., , 1997)). However, in spite of the natural trend towards de-alkalization, the irrigation with water of the river Niger may well lead to secondary alkalization. The restoration of a chemical environment favouring a stable structure, is necessary for a long lasting improvement of alkali soils.

Abu Sharar TM, Bingham FT, and Rhoades JD, 1987 Reduction in hydraulic conductivity in relation to clay dispersion and disaggregation. Soil Sci. Soc. Am. J., 51: 342-346. Barbiéro L, 1995 Les sols alcalinisés sur socle dans la vallée du fleuve Niger. Origines de l'alcalinisation et évolution des sols sous irrigation. Trav. Docum. Microf. Orstom, n°138, 209p. Barbiéro L. and Berrier J., 1994. Mise en évidence d'une désalcalinisation naturelle de sols en milieu tropical -Transformation de sols alcalins en sols bruns subarides sur un bas fond Sahélien au Niger. C. R. Acad. Sci. Paris, t 319, série II, pp. 659-665. Barbiéro L., Valles V. and Regeard A., 1995. Précipitation de la fluorine et contrôle géochimique du calcium dans des sols alcalins du Niger. Conséquences pour une estimation quantitative de l'évolution géochimique des sols. C.R. Acad. Sci., Paris, t 321, série II, pp. 1147-1154. Bertrand R., N'Diaye M.K. and Keita B., 1994. L'alcalinisation/sodisation, un danger pour les périmètres irrigués sahéliens. Sècheresse n°3, vol. 5: 161-171. Bertrand R., Keita B. and N'Diaye M.K., 1993. La dégradation des sols des périmètres irrigués des grandes vallées sud sahariennes (Cas de l'Office du Niger au Mali). Cahiers Agriculture, 2: 318-329. Bouzigue R., Favrot J.C., Herrera J. and CID G., 1992. Valeur diagnostique des caractères hydromorphes de vertisols de la vallée du Cauto à Cuba. Application à l'évaluation des besoins en drainage agricole. Cah. Orstom,Ser. Pédol.,vol. XXVII,.

Fig. 1 -

 1 Fig. 1 -Location of the study site. Fig. 2 -pH survey of the 15 ha and concentric distribution of the soils in the studied zone. Fig. 3 -Distribution of the horizons close to the contact zone: alkali soils/brown steppe soils. 1 Weathered layer with parent-rock structure; 2 Calcareous weathered horizon; 3 Grey sandy clay loam horizon; 4 Brown sandy clay loam horizon; 5 Superficial sandy horizon; + Chemical analysis sampling points ; Thin sections. Fig. 4 -Distribution of the macro structure (main cracks) close to the contact zone: alkali soils/brown steppe soils. Fig. 5 -Morphology of the calcareous nodules: a: Alkali soil, b: brown steppe soil, c: transition zone (1 white indurated cortex, 2 grey calcareous (with Quartz) matrix, 3 soft calcareous powder). Fig. 6 -Spatial distribution of the chemistry close to the contact zone: alkali soils/brown steppe soils (meq/l on the saturated paste extract). Fig. 7 -Concentration diagrams. Fig. 8 -Distribution of the Total Dissolved Substances values close to the contact zone: alkali soils/brown steppe soils (meq/l on the saturated paste extract). Fig. 9 -The gap of 1 meter between the morphological (A) and the geochemical (B) transition. Fig. 10 -Saturation with respect to fluorite of paste extracts from alkali soils and brown steppe soils Fig. 11 -Hypothetic model of alkali soil and brown steppe soil genesis under the former pond (A: Brown soil with abrupt structural change, alkaline in depth -B: non-alkaline brown steppe soil -C: non-saline alkali soil -1: dune or sandy bank -2: crystaline bedrock -3: alkaline horizons -4 and 5: high and low level of the former pond. 6: infiltration and soil leaching -7: evaporation. Phot. 1 -precipitation forms of calcite in the nodules of alkali soils. Phot. 2 -precipitation forms of calcite in the nodules of brown steppe soils. Phot. 3 -precipitation forms of calcite in the nodules close to the contact zone. Phot. 4 -aerial picture of "Lossa" catchment and indices of a former pond in the valley bottom.Table I -Chemistry of the runoff waters.