Keywords

1 Introduction

In the field of software engineering, a growing advance has been perceived in research on methodologies and good practices of software development, which allows the efficient management and optimization of processes and resources, reduces conflicts in the assignment of routines and knowledge of the complexity of the projects [1, 2]. In this context, software development methodologies such as Agile and Lean are implemented depending on the characteristics of an organization. In fact, the authors in [3,4,5] discuss that the Agile methodology emerged in 2001 as an “Agile Manifesto” focused on reducing the concern about the inefficiency of iterative cycles, customer feedback, workflow visualization, which led to the evaluation of new practices to establish principles for the correct manufacturing of software products.

However, Agile was aimed at small working groups, so a new “Lean” concept was introduced. It was firstly aimed at the industrial sector and then adopted, and parameters were established to enable organizations to scale up in the software product market focusing on three bases: design thinking, Lean production, and Agile development; This reduces the waste of unnecessary processes and increases the organizational culture within the team [19, 21].

Indeed, the Agile and Lean methods have made it possible to examine aspects and factors involved in the analysis prior to the selection of methodologies. To support this approach, ontologies are constructed. They include a common and unambiguous vocabulary for a given domain. In the context of software development, their use provides organizations with an adjustment to the extent of validating their implementation because they are generally selected and adopted incorrectly due to ignorance of their principles, implying delay in the management of processes in software projects. In this sense, studies [18, 36] they emphasize that there are different ontologies focused on evaluating the Software development cycle, the processes or the communication between those involved, for the development of Agile Software and for Software development in general. Likewise, recent studies include ontologies for Agile software development methodology, but not for Lean and/or the link between the two in the Software life cycle processes and within the work team.

Therefore, the need arises for an ontology aimed at the selection of Agile or Lean Software development methodologies in the banking sector, which responds to the analysis of aspects of these two approaches. This research considers the characteristics and requirements of the methodologies for the construction of an ontology with the information supplied from the two banking organizations in Panama. In this way, the study provides organizations with a recommendation on the type of methodology to be selected for their software department and indicates the risks or points to be improved.

The general structure of this study includes: Sect. 2 presents the background that covers the Agile and/or Lean Software development methodologies; Sect. 3 describes the proposed Ontology (development and construction); Sect. 4 presents results; Sect. 5 the discussion and Sect. 6 the conclusions and future work.

2 Background

In organizations, it is essential to consolidate a stable organizational environment, and effectiveness in the delivery of the Software product. In this context, the studies related to Agile/Lean software development methodologies in organizations include characteristic aspects, advantages and risks present during the software product development cycle. Likewise, the approach of Agile and Lean are based on continuous integration and design focused on user feedback [8, 11, 29]. Indeed, Agile and Lean are related to the variables of requirements, productivity, process, and communication between team members. In addition, the authors at [2, 5, 15, 24, 26, 29, 33, 39] mention that these parameters explain that there must be organizational culture to reduce inventory operating costs, and obtain a return on investment from the use of resources, contributing to the flow of quality, and maximizing customer value. Therefore, from the IEEE 1074–1995 standard to achieve the progress of a project, the monitoring, and control of the processes must be reviewed and measured; in addition, this standard assesses the background and risk analysis, contingency planning, project management, and the record-keeping [17]. In turn, Table 1 presents in detail the aspects of the Agile and Lean approaches that are involved in the software development process. It shows the main terms, and, according to both approaches, a description is provided.

Table 1. Descriptive aspects of the Agile and Lean approaches to software development
Full size table

The information presented in Table 1 describes the key elements for both approaches (Agile and Lean) and offers an overview for the construction and development of ontology.

2.1 Ontological Language (OWL)

The ontological language [22] processed for years has been transferred to the evolution of applications in the areas of software engineering. Therefore, the ontologies developed in [7, 16, 32, 40] are implemented in the sub-parts of the DS in general, which include: collaboration, workflow, process evaluation, cooperative design, and remediation. In agreement with [22, 23], the ontologies developed to ensure the traceability of the requirements in the DSA; Whereas, in [38] consider the types of requirements and their options for evaluating the time and cost of entering the data on traceability, the difference between traceability, the existence of points of view of practical benefits, problems in the organization and support of trade trusts. On the other hand, the ontology for requirements allows giving an intelligence support guide of the techniques to be used and an evaluation of the quality metrics of the traceability requirements. In essence, for [14, 36] the ontologies developed in the DSA, are used as a medium to identify the changes between external clients and the SD equipment; allow permission to improve fundamental communication in the organization and the capacity to meet the requirements Meanwhile, the [1, 21, 34, 37] risk management is focused and these were classified by levels. In this context, according to [17] the IEEE 1074 standard provides that the types of risks involved in organizations can be processed or activities, where each process derives an activity in the development of the Software.

3 Material and Methods: Proposed Ontology

This section presents the construction of an ontology focused on the selection of software development methodologies (SDM) through language-semantic web axis (OWL). This facilitates the decision-making from the analysis of the domain knowledge and gives an answer to the problem [13, 30]. The synthesis of previous studies provides support for the construction of the ontology.

This allows you to use a specific vocabulary and domain to analyze the information from two organizations in the banking sector in Panama. It also provides you with a recommendation on the most appropriate one and draws conclusions on those aspects that need to be improved.

In this manner, the seven steps that the ontology to be built must include are presented. Figure 1 shows the classification of these in two stages: the first includes the description and definition of the domain and the second the construction and results of the ontology; shown in the following diagram:

Fig. 1.
figure 1

Model with the steps to build the ontology

Full size image

3.1 Description and Definition of the Domain

The first stage includes the description and definition of the domain, in which the identification of the organization’s needs is presented with respect to the survey applied to the two Panamanian organizations in the banking sector. Likewise, Table 2 shows these 18 questions distributed as follow: questions 4 to 11 evaluate the Agile Software development methodology and from 11 to 18, the Lean approach.

Table 2. Survey to find out the existing level or situation of the organization
Full size table

Indeed, the information obtained from the two organizations was classified according to the key questions in Fig. 1; while, from these, the purpose of this study is answered through 5 research questions to classify the information. Thus, Table 3 presents an ID for each research question, discussed later in Sect. 5.

Table 3. Research questions (RQ) of ontology
Full size table

On the other hand, the results obtained from the mapping of terms, set out in Sect. 2, have been classified by the characteristics, risks and advantages of both approaches (Agile and Lean). Thus, the main terms to use are the following: requirements, organizational culture, communication, process, productivity and quality, flexibility, and feedback loop.

4 Results: Construction of the Ontology

This section presents the formal definition of the aspects with which the “Protégé” software tool works. Initially, a representative class diagram is defined for the ontology and the relations between them. Therefore, Fig. 2 shows the terms and their relations using the UML (Unified Modeling Language) representation of the ontology domain.

Fig. 2.
figure 2

UML representation of elements for the ontology

Full size image

Therefore, for the ontology construction process, there are 8 named classes: methodology, risks and characteristics of Agile and Lean; recommendations, rule arguments and the organization with the subclass (teamwork).

Each of these classes constitutes the domain of the ontology, and its relations, restrictions, Object properties, Data properties and Data Types. In fact, all classes are bound to the base class < owl.Thing >, which contains the knowledge in which the information is analyzed. Thus, Fig. 3 shows the general scheme of the ontology. A short description is presented in a yellow box about the selected class and overview of the content in OWL.

Fig. 3.
figure 3

Scheme overview of relationships of the ontology components.

Full size image

5 Discussion

As an initial result of the survey, it states that 71% of teams use MDS while 29% it does not use them. Consequently, the 42.9% uses the Agile methodology, the 14.3% uses another type of alternative methodology, and the rest do not use any. This reveals that the Lean methodology is not used in the Software departments. On the other hand, the defined ontology analyzes theoretical knowledge through Individuals (organization’s information) to generate the results through the verification queries; and using SPARQL Query check that each subject (subclass) would correspond to class (object), through the expression: SELECT? subject-object WHERE {?subject rdfs: subClassOf?object}. For example, the logical reasoner HermiT, which incorporated Protégé, was used to analyze the entered knowledge. The analysis is implemented for 7 banking facilities. This presents in a visual way the inference by each team. Figure 4 presents two of the generated results (Left: organization 1; right: organization 2):

Fig. 4.
figure 4

Results for organization 1 and organization 2

Full size image

From all the results inferred by the ontology, the information is synthesized in Table 4. This presents the organizations (teams), methodology to be used or maintained, as well as the suggestion of aspects to improve within the Software Development department. For its part, in the items (Name: Recommendation and fundamentals to improve) they are considered the most critical points for each organization; that is, the risks and characteristics whose level of acceptance are subject to immediate changes in the Software Development work process, and need to be improved and properly applied. Table 4 substantiates the information as follows:

Table 4. Recommendations to organizations in the selection of Agile and / or Lean
Full size table

The results provide conclusive support to the onto-logy proposal for the selection of the Agile or Lean methodology based on the questions. Thus, this synthesis of the information describes that organizations face challenges and risks where choosing the correct methodology becomes the greatest investment in terms of benefits for the work team and the use of resources. Therefore, the results described in this section allowed inferring in 5 questions to answer the ontology, which are discussed below:

RQ1: The proposal provided a solution window to these organizations through the knowledge inferred through the semantic web language (OWL) to consult and evaluate the profiles of the organizations before implementing a Software development methodology. In fact, the constructed ontology allows to know those weak points of the software development process and to suggest the type of methodology that should be selected. Thus, if it is implemented by the team, to indicate the aspects that represent a risk factor in its development process.

RQ2: In perspective to the scope of the ontology, it is important to highlight that the focus of this study was to initially identify the most outstanding characteristics of Agile and Lean for the two banking organizations, described in Sect. 2:

  • The findings allowed them to be categorized into two groups: Agile characteristics: difference in communication, low performance, lack of knowledge of principles, scarcity of tools, functionality, monitoring and control of processes, flexibility and a team of less than 7 people.

  • Characteristics of Lean: Assumption before requirements, response to change, collaboration with the customer, design thinking and the team is more than 7 people.

The analysis of the results supports the importance of these characteristics in the ontology and infers a pattern for both organizations in the seven work teams: the groups are less than 7 people. They lack the applicability of the principles and the organizational culture presents difficulties. Even the establishment of the requirements is one of the key tasks. They also present low attention from the software developers.

RQ3: This raises the question of indicating the risks for the two banks, where the following should be considered for the organization 1: improving risk analysis and requirements planning, failure background and maintenance of the requirements register, communication differences, monitoring and control of functions. While, for organization 2, an additional risk was identified and indicates the distribution of roles.

RQ4: The preceding analysis from the conceptualization of characteristics to the recommendation generated by the ontology shows that both Panamanian banking organizations are suggested to select the Agile Software development methodology, because the characteristics and risks of greater incidence are adjusted both in the number of people per team, as well as, in its principles. This implies that when implementing Agile, it must offer both organizations some advantages, such as:

  • Better collaboration and interaction between team members and customers, task distribution, remote communication, improved organizational culture and reduced time distance.

  • Continuous project progress and optimization of communication efficiency and provides support guidance.

  • Improved evaluation of adaptability to changes and a reduced documentation time.

  • In practical terms, the ontology inference used a knowledge domain manager of the team’s characteristic aspects in the software development process.

RQ5: The two banking organizations can improve the weak points previously addressed and increase the team’s productivity, reducing the process execution time and the practices that can be adopted afterwards. This implies that it helps in the efficiency, better planning of the requirements and fulfilling not only what is requested by the client. Also, through the ontology inference, the organizations are provided with those aspects that are within the Lean context, but that can be improved to automate and minimize risks in the Software development process execution time.

6 Conclusions and Future Work

The ontologies provide a common and unambiguous vocabulary to refer to the terms in the applied area, being able to share or reuse these among different applications that make use of the Ontology. This is the case of software agents (in the field of Web technologies), which can adequately recognize the elements of an ontology as long as the previous conditions are met. As a consequence of this, it is worth mentioning that the ontology in the framework of software development allowed the identification of:

In addition to a common vocabulary, they specify a taxonomy or inheritance of concepts that establish a categorization or classification of the domain entities. A good taxonomy is simple and easy to remember. It separates its entities in a mutually exclusive way and defines groups and subgroups without ambiguity.

The vocabulary and taxonomy represent a Conceptual Framework for the analysis, discussion or consultation of information from a domain.

An ontology includes a complete generalization/specification of its classes and subclasses, which are formally specified (including their relationships and instances) ensuring consistency in the deductive processes.

Ontologies are implemented in specific Ontology representation languages so that the specification of their classes, relations between them and their restrictions will depend on the characteristics of that language.

In consideration, the findings of our research as mentioned in Sect. 4, through the ontology in the domain of software development methodologies, have shown that the Agile approach in the banking sector solves:

It allows each of the banking institutions to identify some aspects that are fundamental during the life cycle of the software product development.

The recognition of the inference of the most outstanding characteristic risks of both organizations, reduces the incidence to failures in the establishment of requirements, communication between team members, efficiency and time of execution of the processes.

It provides team managers with an overview of the current situation in contrast to the benefits offered by the correct implementation of the Agile methodology in their projects.

Likewise, this research differs from the studies presented in Sect. 2.1, in essence, because it has a scope at the level of the selection of the most appropriate methodology, using an OWL, where the knowledge analyzed covers the phase prior to the implementation of a methodology; that is, the ontology, through the knowledge of the case study infers as a main advantage to offer, in the context of software engineering, a previous analysis to improve the failures and provide suggestions for good practices to the organizations. On the other hand, as future work, it is proposed to carry out validity by investigating specific points where a risk assessment (requirements and organizational culture) was reported from the point of view of data analysis and working with other non-banking organizations, and their evolution process at the time of implementing the methodology suggested through this study. In parallel, currently in this line of the Agile Software development methodology, we are working on the analysis of requirements, and the initial phase of the construction of an ontology that includes a general domain language for any organization based on its characteristics, offering a set of suggestions of the type of practice within Agile to be implemented.

7 Authors Contribution.

Conceptualization I.M, B.B, M.V.; methodology I.M, M.V.; formal analysis I.M, B.B, M.V; research, I.M, M.V.; original-writing I.M, M.V.; writing—review and edition I.M, B.B, M.V.; Corresponding author, M.V.