ABSTRACT

In recent years, agile methodologies have been consolidated and extended in organizations that develop software in Web environments. For this reason, the development methodology of these organizations will not only be related to Services, but also to the Web Engineering paradigm. These organizations are heading for incorporating software development methodologies whose paradigm can allow integration, naturally and in the earlier stages of Web applications develop with the services of the organization that described and published in the Services Portfolio. The aim of this study will be to analyze the current state of the art in the process of discovering services in early stages of agile software development with focus on those identified requirements that could be covered with the services included in the Service Portfolio. We have identified 20 relevant papers through conducting a double systematic literature review (SLR). It is concluded that no study has been found that can solve the entire process of discovering candidate services within an organization that cover the requirements of a new application developed with agile methodologies. At the same time, guidelines have been found to formalize the solution to this problem and fill in that gap of knowledge by proposing in a single process, the formalization of a requirement based on agile techniques, which can be managed against a Services Portfolio.

Keywords:

Systematic Literature Review, Services, Requirements Engineering, Service-Oriented Architecture, Agile Software Development, Web Engineering, Scrum, E-Government

1. Introduction

Services represent one of the basic forms of providing value in relationships [1] in the current information society. The way these services are given is deeply related to the World Wide Web, which is nowadays the preferred online tool to communicate with the different organizations that supply them.

For this reason, the development methodology of these organizations may not only be linked to Services, but also to the Internet, which is associated at the same time with the Web Engineering paradigm. These organizations will necessarily have to include software development methodologies whose paradigm may allow, in a natural way, and in the earliest stages, the use of Web applications that those Services offered by the organization will request [2] .

Agile methodologies and Web development are closely associated and have become extended, in the last years, to organizations that develop software in Web environments [3] .

At the end, part of the functionality offered by this type of organizations will be contained in those services that provide a solution for most of the organization’s functional requirements, which appear described and published in its Catalog of Services. Due to this reason, the process of searching for functionality that already appears in these organizations is sometimes complex and manual, with its success being dependent on the will of those who participate in that process. This represents a serious problem for reusing software, services and knowledge, so it directly interferes in effectiveness and efficiency, either by providing services or by developing such applications. This paper seeks to provide, through the study of state-of-the-art, a solution to discovering services in early stages of agile software development that can be used by these organizations.

This paper is organized into the following sections. Section 2 presents the method followed to carry out the study, describing the guidelines to conduct a systematic literature review. Then, Section 3 conducts the study of topic “discovering of services” and sees its results, Sections 4 and 5 repeat this method dividing the main topic into two subareas, the agile requirements and SOA paradigm. To finish, whereas Section 6 describes limitations of these studies, Section 7 summarizes the conclusions taken out and proposes possible future lines of work.

2. Scope and Method

Method

For carrying out this investigation, we will follow the guidelines proposed by Kitchenham and Charters, known as Systematic Literature Review (SLR), since they are the most widely accepted in the field of Software Engineering. This method allows the identification, evaluation and interpretation of all the existing data concerning a research question (RQ) in a specific area [4] . There exists a series of improvements about this proposal focused on the optimization of search processes, as these are greatly conditioned by the results we may get:

· In 2011, Zhang et al. [5] proposed the improvement of searches by adding those studies that were not known or found directly in the manual search (concept defined as “quasi-gold standard”, QGS), as well as an improvement in the search effectiveness evaluation (“quasi-sensitivity”). Two years later, the same authors [6] defended the importance of SLRs in an empirical way, even though they warned about the necessary balance between following a method rigorously and the crucial effort for guaranteeing that all the potential works had been included.

· In 2013, another proposal was recommended in order to improve the search method; Wholin and Prikladniki [7] suggested following an approach called “snowballig”. First, Kitchenham’s approach is executed. Then, from the papers found, the cited works in those papers, should be reviewed and included them for the study. This process could be repeated, recursively, to find new related works that have not been found in the original search.

This way, after analyzing all the improvement proposals received, in 2013 Kitchenham and Brereton [8] made a review of the guidelines and suggested new improvements; one of them comprised not using structured search strings. Instead, primary research obtained from other searches had to be added.

The fact that the aim of this study is very specific has made us start the research from the guidelines proposed by Kitchenham and, in case we get relevant results, we will apply the improvements regarding the inclusion of related articles to get the “snowball” effect described in this section so as to increase the search field. The next stages will be followed through the document according to what has been exposed before:

· Scheduling, in which the foundation of what we pursue will be laid, as well as the way it will be achieved and represented.

· Execution, in which the searches will be carried out, as well as the selection, registration and research analysis process following the SLR methodology.

· Reports, in which the current stage of research about a certain field will be formally documented.

As Figure 1 shows, the steps for carrying such out an SLR will be listed below:

1) Definition of research questions for the purpose proposed.

2) Identification of sources and definition of terms for conducting the systematic search.

3) Definition of including and excluding criteria for filtering the previous search results.

4) Definition of the quality standards necessary for the searches previously executed and their application to those searches.

5) Analysis of the studies achieved in the previous stages and presentation of obtained results.

3. Discovering the State of the Art of Services

The purpose of this research is to propose a formalization of a Web requirement, based on agile techniques, which may be managed against a Service Catalog. We tend to identify what Services within the context of the organization are likely to be included in the development of a new application so as to offer a solution to such a requirement. Consequently, a continued SLR will be performed according to the methodology previously exposed.

3.1. Research Questions

Since the goal of this research responds to a very specific point, just a unique research question will be presented in Table 1.

In accordance with the aforementioned goal, we would also aim to respond to the subsequent research questions:

· What processes of service discovering for agile requirements have been proposed?

· What is the degree of formalization of these processes?

· Are these processes related to some agile methodology of common use in the development of applications?

· Are these activities registered in the earliest stages of development?

· Are these processes designed to be used in a certain context or organization?

3.2. Research Strategy

This chapter will detail the approach that has been used for conducting an exhaustive search in the main digital libraries with the intention to locate those articles in journals, congresses, conferences and meetings that may help us define the current state of the art of the topic or field that we are working with.

Due to the fact that the terms of the search condition to a large extent the nature of results we will get, a corpus of terms has been combined and some searches have been executed for analyzing, in an empirical way, those results obtained and selecting the best key words that can optimize the manual search and balance a rigorous method with the necessary effort.

Table 2 displays the relation of terms used to get accurate concepts that will

participate in RQ1. It shows, in the first column, the concept that belongs to the domain of the question, and in the second one, the terms used to deeply define such concept.

As listed in the previous table, after this preliminary study the search terms for setting RQ1 have been selected. These terms refer to processes for discovery of services by using agile techniques. The chosen terms are (in English):

· “service”, a term that will be the reference in SOA to Service paradigm. It will be the widest term and the one that can provide us with the largest possible search spectrum.

· “agile”, a term that has removed any reference to methodology or technique, even though there is the risk that agility be understood out of the context in which we have used it in this work. This fact, however, allows gathering any reference to this methodological field.

· “requirement”, in the same way and due to part of the core of this research have consisted in modeling requirements, the search terms have been relaxed and reduced to just requirements, without taxonomically qualifying them as a Web or agile requirement. This point gives this concept of requirement a wider meaning in this search.

· “discovery”, a term that has been chosen since it is frequent in service-oriented architectures for referring to Services searches.

The general query presented below about the different sources has been generated with the aforementioned terms, as Expression 1 shows:

Expression 1. Expression for the query about a goal proposed.

ST = ((service*) AND (agile) AND (requirement*) AND (discovery*))

Since the criteria for conducting our search, that is, working with fields where those terms must be found, will also condition results, as well as the fact that the different searchers included in digital libraries do not offer the same elements for filtering results, these terms have been configured for each searcher with the purpose of minimizing the risk of initially excluding relevant works. As a rule, the query has been made for finding terms in the whole article, including summary or title, summary and keywords when results are too wide. If results are not obtained, some of the less significant terms will be excluded.

Table 3 shows results by using the previous expression in each of the sources. It was carried out in the fourth quarter of 2016.

Once this volume of studies has been gathered, we can step into the third phase of the proposed methodology.

3.3. Inclusion and Exclusion Criteria

One of the steps in the guidelines deals with setting up objective criteria to select, from the primary candidate studies, those that are comprised to perform the analysis of the state of the art. The search method is empirical; thus, it will be necessary to manually shift with the aim to deepen and detect whether or not each study can contribute to the ongoing systematic review work. With this regard, Table 4 shows the inclusion and exclusion criteria.

Once the results have been studied, this search has not shown any conclusive results, even though we have obtained combinations that do not belong to the field of Software Engineering.

After getting results, it has not been possible to continue using the rest of the steps proposed by Kitchenham, nor to carry out the “snowball” process proposed by Wohlin and Prikladniki. It has neither been feasible to execute the quality assurance process, due to the lack of research to work on. Therefore, we will analyze and present these results directly.

3.4. Analysis and Presentation of Results

It should be noted that once this search is conducted, the problem for the systematic study in this case lies in the intersection of both paradigms through a process that produces the discovery of the Candidate Services in the early stages of development with agile methodologies.

As a result of previous searches and after carrying out a manual screening of these works, it has been found out that there is a direct relationship between both paradigms only in two of them, linking requirements and services coherently and systematically. [9] [10] use agile techniques, but not for identifying Services in the construction of applications in the requirements phase, but for the deduction of Services in the design of service-oriented architectures from the requirements.

Hence, it can now be determined that no work has been identified in the current literature related to the discovery or search of services within a context using agile methodologies so as to support a given set of requirements.

For this reason, in the following chapters we will focus on conducting a study about those constitutive elements of this goal, in order to review the existing literature:

· Regarding Agile Requirements Engineering, the formalization through a metamodel of the elements that make up the agile requirement and that are the result of applying the most common agile methodologies and techniques.

· In relation to the SOA paradigm, the formalization of the Service Catalog, through a metamodel of an organization that provides Services. Within that modeling, not only the basic elements of a service and its interface should be included, but also the minimum elements of the organization's context must also be collected since they are necessary to incardinate that service in a specific environment.

4. State of the Art of Agile Requirement Formalization

Research on agile requirements is very advanced in the IWT2 research group. In consequence, the SLR in this partial aspect will focus on the SLR carried out by this group [11] . It presents a detailed state of the art study of Agile Requirements Engineering based on the involvement and interaction of stakeholders and users in the process of taking requirements within the field of user-guided design, with valuable contributions to the participation of users, techniques and artifacts used, documentation and non-formal requirements. It includes in turn, the revision of the SLRs of the following works:

· [12] whose main objective was to review the existing literature that copes with the challenges and agile practices in Requirements Engineering, including a good discussion about the related work. They aimed to understand how the traditional problems in Agile Requirements Engineering are solved. In conclusion, they provided 17 commonly used practices as well as practical challenges that agile teams had to face. Among the most used and accepted practices user stories, prioritization of the requirement, management of changes, modeling of requirements, management of requirements, review meetings and acceptance tests, matching for the analysis of requirements, retrospectives and continuous planning were included.

· [13] that combined a review of the literature with an exploratory study. The difficulties were analyzed when working with requirements in an agile environment, especially the causes that can lead to the lack of documentation (e.g. insufficient or incomplete requirements). This work contributed to an important research topic: the fact that documentation in ASD is often inadequately addressed. The authors defined ten difficulties that arise when identifying and managing agile requirements.

These studies uncovered a series of repeated key factors that should be kept in mind in order to formalize agile requirements in a meta model:

· User History is one of the main techniques endorsed by all the studies and that is becoming a de facto standard within agile methodologies. It will therefore be necessary that the formalized requirement be based on User History, because it is currently the most commonly utilized technique in the field of Requirement Engineering [11] .

· The set of requirements has to be as complete as possible, that is, it must cover the maximum number of possible requirements. Previous studies let us realize that the agile artifact called “Product Backlog” (product stack) is the one frequently used to represent User Stories and manage them.

· The set of requirements must be prioritized. In this study, “Scrum” is highlighted as a methodology that, due to its flexibility, allows integrating User Stories within its processes, as well as the product stack and other agile techniques for estimation, based on the comparison and “Wideband-Delphi” methods. One of the fundamental premises of “Scrum” is the prioritization of the elements of such stack. Amongst the aforementioned research, the most common way to prioritize focuses on value, which is consistent with the approach taken by the Agile Requirement Engineering, which enables the granularity of the requirements to be oriented towards the delivery of value. This is a fundamental characteristic for the later comparison with Services.

As a result of the state of the art shown by the previous studies, there is no approximation that integrates all these characteristic elements in the same proposal, so that, at the time of formalizing an agile requirement to be used in the identification of Services, the following elements must be integrated into the same design:

· User Stories, as a fundamental agile technique when representing the definition of requirements, due to its greater adoption by the community [14] [15] .

· “Scrum”, as a process for organizing User Stories, since it is the most flexible technique with the greatest implementation in agility [16] .

· The support of “Wideband-Delphi” techniques, based on experts’ judgment and estimation by comparison, such as “Planning Poker”, in the prioritization of requirements, to find the gained value. The reason is that the cost for estimating the value with these techniques is minimized, making them be more efficient [3] [17] .

· Formalization of all this functionality in a metamodel in a Unified Modeling Language (UML), as it is worldwide known by almost all the members of a software development team. All the artifacts involved in the description of the requirement must be modeled in a UML and not just a few of them [18] [19] .

· Interaction of the stakeholders with the development team [11] .

5. State of the Art of Agile Requirement Formalization

As previously stated, according to the structure set to achieve the purpose of this research, this section will deal with the SLR, within the SOA architecture, in the formalization of the Service Catalog through a metamodel in an organization that provides Services. Not only the basic elements of a service and its interface must be defined in this modeling, but also the minimum elements of the organization context necessary to incardinate that service in a specific environment, that is to say, to model Services from the point of view of functionality (which would leave out the metamodels of a technological nature or those linked to a specific implementation) and that metamodel was oriented to present these services as a Service Catalog from a functional point of view, facing the discovery of these services.

From now on, to go deeper into the second partial research of this study, we will follow the steps proposed by Kitchenham’s guidelines in order to find a rigorous answer for the raised research questions.

5.1. Research Question

The purpose of this section is to do a research on what Service identification can be managed against a Service Catalog within the context of an organization. This is a partial objective in which a research question that will respond to this problem will be posed, as Table 5 shows.

Regarding the above objective we would like to subdivide this question as follows:

· Are Service metamodels proposed?

· Do metamodels involve the functional description of Services?

· Do metamodels include the context of the organization?

· Are metamodels oriented to Service identification?

· Do metamodels reflect the Service Catalog of the organization?

5.2. Search Strategy

In this section, we will detail the method that has allowed an extensive search in the main digital bookstores to locate those articles in magazines, congresses, conferences and workshops that could help assess the state of the art of the subject we are dealing with.

Table 6 displays the list of terms used to narrow down each of the concepts

that become part of RQ2. The first column shows the concept belonging to the domain of the question and the second one shows the terms used to refer to such concept.

After this preliminary study of terms presented in Table 6, the search terms are selected to frame RQ2. They refer to a Service metamodel within an organization that presents its Service Catalog from a technical and functional point of view. The chosen terms are (in English):

· “metamodel”, since we are looking for a metamodel, it will be necessary that this term be present.

· “portfolio”, since we are looking for a metamodel that will formalize the Service Catalog within an organization too, this term must also be present.

· “service”, since this term, within the SOA paradigm, includes the widest possible spectrum in the search, it must also be present.

· “discovery”, since it is a common term within service-oriented architectures for referring to the search of Services, and therefore it will provide us with a wider range in our search spectrum, this term must also be present.

A generic query of terms about the different sources has been generated with the terms above, as shown in Expression 2.

Expression 2. Expression for the generic query of terms for RQ2.

ST = ((metamodel*) AND (service*) AND (portfolio) AND (discover*))

As a general rule, the query is launched to find all the terms in the whole content of the article by adding the restriction either by the summary or by the title, summary and keywords together when the results are too long. Otherwise, in the absence of results, we have decided to eliminate some terms according to their importance, so as to expand the search range in these digital libraries.

Table 7 shows the results in terms of the previous expression in each of the sources. It was carried out in the fourth quarter of 2016.

Once this volume of studies has been gathered, we will step into the third phase of the proposed methodology.

5.3. Inclusion and Exclusion Criteria

The third of the steps recommended in Kitchenham’s guidelines deals with setting

some objective criteria to select, from the primary candidate researches, those that are included to analyze the state of the art. Since the search method is empirical, it is necessary to manually screen for deepening and identifying, if each research can contribute to the ongoing systematic review work. For this purpose, Table 8 displays the inclusion and exclusion criteria.

With these inclusion and exclusion criteria and based on the research found, the process that has been carried out to review these studies is described below:

1) There is a screening on the title, summary and key words, categorizing the articles as follows:

a) Yes, that study is included in the ongoing systematic review.

b) No, that study is excluded from the ongoing systematic review.

c) Partial, there are doubts about its inclusion.

2) Those works with “Partial” result in the previous step, undergo a manual screening again, but this time on the complete text, thus in this case they are definitely evaluated as:

a) Yes, that study is included in the ongoing systematic review.

b) No, that study is excluded from the ongoing systematic review.

Figure 2 describes this process graphically.

Once the process has finished, the new search is performed on the set of studies

that have been analyzed considering the complete text. The aim is to find out the references to them, that is, that subsequent research that cited the previous ones and possible new works with the same proposals or by the same authors. The selection process represented in Figure 2 is launched again with this set of studies according to the same filtering criteria.

5.4. Quality Assurance

To evaluate the quality of the selected studies in order to meet the objective set out in this state of the art, a questionnaire has been established that must be filled in for each of the studies. Particularly for RQ2 evaluation, two different points must be assessed: 1) whether each proposal considers the work carried out so far to justify the extent to which the current investigation has reached and what gap each of them intends to fill in; and 2) the description of the Service meta-model, which is associated with quality assurance (QA) questions, QA1 and QA2, as presented in Table 9 and Table 10, respectively.

We must also know if a metamodel is incorporated to any organization or if it is purely theoretical without having been instantiated at a specific organization. This quality aspect will be reflected in the QA3 question shown in Table 11, which includes the following range of values:

5.5. Analysis and Presentation of Results

For the presentation of results obtained in this last phase of the study, an information

schema is defined as a record in which the information concerning each of the studies included in this SLR has been collected, so as to facilitate the process of analyzing the gathered data. Table 12 shows the data of the record for each research.

JabRef tool [20] has been used to facilitate the management of references. It must be added that it has been selected against other alternatives due to its ability to import references from multiple formats [21] .

The quantitative results of this study of the art are presented below. Figure 3 shows the included and excluded works, both for the search phase and for the subsequent phase, by using the refinement technique and adding previous and subsequent research, what has finally involved the inclusion of one more study.

Equally, and once the quality assurance management has taken place in all the included studies, results obtained in relation to this quality evaluation are shown in Figure 4.

As the main conclusion of the evaluation of the quality assurance management that this study has undergone, it is observed that although the research is generally well motivated and the previous works are framed, the definition of the metamodels is not complete in all cases. Similarly, it stands out especially in regard to validation that the vast majority of research does not provide any implementation and those studies that do provide it are usually theoretical validations on real problems, except for some cases in which the metamodel has been implemented in a real environment.

Therefore, it is difficult to incorporate these metamodels to real environments that hinder the quality of the research presented, although from the theoretical point of view they are correct and complete.

Below, Table 13 outlines the summary of the studies in the quantitative analysis described in the previous paragraphs. The first column corresponds to the reference, the second column includes the title of the work and the three following columns stand for the evaluation of quality assigned to each research, with the P value being the representation of the “Partially” evaluation scale.

Once the quantitative analysis has been completed, a qualitative analysis of this work is carried out. The most relevant studies that tend to provide information that responds to the RQ2 have been selected below. They enumerate those important characteristics in relation to the current study in progress:

· [42] shows a proposal to describe, discover and build services within a business context, with services being considered as incardinated within an organization and in a particular context. However, although it offers a model in a descriptive way, it neither formalizes any metamodel in a UML to be utilized nor presents any UML profiles that can be used in a real production environment.

· [32] and [38] present a metamodel and taxonomy to adapt services that are sensitive to the context. According to the authors, companies are incorporating service-oriented architectures to respond to rapid changes in the market. Although there are outstanding tools and frameworks for the implementation of service-oriented architectures as well as the development of services, the latest adaptation to the context has not yet been adequately addressed. Current approaches focus mainly on the resolution of context-sensitive issues for Web applications, particularly looking at the adaptation to the customer side. Nevertheless, there is a clear lack of taxonomy led to the organization itself. These proposals present a metamodel that, despite being addressed to multiple contexts and having a series of interesting elements, it is not concerned from a functional point of view, but from a technological one.

· [27] makes an interesting comparison between various service metamodels that comprise context as part of them from the structural, behavioral and technological point of view, placing too much emphasis on the last one. They conclude that the metamodel must combine the structural and functional parts with a certain degree of abstraction, that is, without being extremely conditioned by technology. This research does not end with the formal proposal, in any language, of this metamodel.

The rest of studies remain out of the direct scope of this paper since they are:

· Looking at metamodels of SOA architectures that offer metamodels trying to metamodel the SOA architecture [34] or Information Systems as Services [23] , thus not matching with the object of study in this section.

· Based on meta-models, but focused on a degree of technological depth closer to Web Services, such as [25] [43] or [40] . As it happens with the previous point, they are beyond the scope of this chapter because they address to particular technological solutions for meta-modeling services from a technological and non-functional perspective.

As a result of this analysis, we can state that for the discovery of Candidate Services, it will be essential to define a service meta-model that meets the following characteristics:

· It must be abstract, technology-independent, but flexible enough to describe its structural characteristics from the point of view of service construction.

· It must integrate the functional characteristics of services through various taxonomies.

· It must combine the characteristics of the context of the organization in which the service is incardinated. Thus, the structure of the organization can help define that service, as it will be used in a specific organization and will be therefore, a governed service. In consequence, the elements indicated by the OMG (e.g. stakeholders, policies or service level agreements, among others.) must be included in that metamodel.

6. Limitations of the Review

Despite the fact that we have followed the best guidelines and practices proposed to carry out an SLR, we are aware that this research entails a series of limitations that are outlined below:

· First, the number of search engines included limited the results obtained. Since the application could be very diverse in the field of service-oriented architectures, it was decided to search in the main databases, in particular in Google Scholar, Science Direct, Springer link, Web of Science, IEEEXplore and ACM Digital Library, instead of identifying specific conferences and journals. Even though we considered that they were a very representative sample of the databases of existing publications, it is evident that expanding the search to other databases could have enlarged the candidate research.

· Second, another activity that limited the results obtained was related to the established criteria to include or not the potential works in the review. On the one hand, it was decided to incorporate only works published in English, so any proposal in a language other than English was excluded. Nonetheless, after the analysis developed, it is considered that this limitation is minor and that no work was left out for this reason. On the other hand, the lack of access to the complete text was a key reason to exclude some works, something that happened with two percent of the potential initiatives.

· Third, to evaluate the quality of the included studies, a series of questions were proposed to allow us to analyze whether or not they provided us with sufficient information to answer the research questions we wondered. Each question was evaluated with a “Yes”, “Partially” or “No”, what supposed a certain degree of subjectivity that could limit this study.

· Finally, the process followed to evaluate the different works was itself a limitation, because the first phase of inclusion concerned the title, summary and key words. Extending this first filtering activity to the full text could generate the inclusion of a new research in which its content was not well summarized and expressed in the previous fields. However, although it presented a limitation, the relationship between stringency and effort was adapted in that way.

7. Conclusions and Future Work

From the preceding sections, once the SLR has been carried out, it is concluded that no research has been found that resolves the Candidate Service discovery process that may cover the requirements of a new application, within the development with agile methodologies and whose services are governed within an organization and specified in its Service Catalog. In consequence, we deem it necessary to propose such a discovery process.

Similarly, and once the SLR on the relationship of the two paradigms involved in this discovery process and based on the results obtained has been set, this paper proposes two interrelated metamodels to run the discovery process of Candidate Services.

Regarding the metamodel of agile requirements:

· It must include User Stories as a fundamental agile technique when representing the definition of requirements, due to its greater utilization.

· It should have “Scrum” for the process of organizing User Stories, as it is the most widespread technique with the greatest influence on agility.

· It must incorporate “Wideband-Delphi” techniques, based on the experts’ judgment and on comparison estimation as well as on the prioritization of requirements, in order to find out the value gained. The fact that the investment for value estimation with these techniques is minimized, makes them be more efficient.

· It must formalize all this functionality in a UML metamodel, as it is worldwide known by almost all members of a software development team. All the artifacts involved in the description of the requirement must be modeled in a UML.

· It should integrate the interaction between stakeholders and the development teams (agile team).

Regarding the Services metamodel:

· It should integrate both the functional characteristics of the services through various taxonomies and the characteristics of the context of the organization in which the service is incardinated.

· It must be abstract, that is to say, independent of technology, but flexible enough to include the basic structural characteristics from the point of view of service construction.

· It must be formalized in a UML metamodel, since it is worldwide known by almost all members of a software development team.

In addition, another work will be oriented to find an algorithm that we are able to match agile requirement with services. The future works are toward to recommend a UML formalization of an agile requirement based on a user story metamodel, which can be managed against a Services Portfolio in which the services are metamodeled, too. In addition, another work will be oriented to find an algorithm that allows us to match the agile requirements with the services that cover them.

Acknowledgements

We would like to thank the Andalusian Regional Ministry of Culture and Sports for allowing us to issue this kind of data.

Support

This research has been supported by the POLOLAS project (TIN2016-76956-C3- 2-R) of the Spanish Ministry of Economy and Competitiveness.

Conflicts of Interest

The authors declare no conflicts of interest regarding the publication of this paper.

Cite this paper

Sedeño, J., Vázquez, G., Escalona, M.J. and Mejías, M. (2019) The Systematic Discovery of Services in Early Stages of Agile Developments: A Systematic Literature Review. Journal of Computer and Communications, 7, 114-134. https://doi.org/10.4236/jcc.2019.77012

References