Keywords

1 Introduction

The SW development methodologies are diverse and software projects are becoming ubiquitous in terms of application areas. Additionally, technologies are rapidly evolving and project managers are faced with the necessity of rapidly deciding on SW methodologies with little or no specific information. Furthermore, there is a lack of scientific documentation that reflects development processes and their activities [1, 7].

The objective of this research is to analyse and propose a model that guides decision making in adopting a SW development methodology. The proposed model is based on matrix multiplication, intensive operation of fundamental calculation used in many algorithms in scientific computation [2].

Operations with matrices are used in different areas, specifically in computing they are widely applied in coding, digital signal processing, image processing, graphics, and robotics, various algorithms and control models, among others. The matrices and the operations that can be performed with them are in fact the central engine of several algorithms [2].

The model we propose in this paper starts by defining a set of criteria (characteristics of SW development methodologies) quantified per methodology, constituting the first matrix. The second matrix is the result of the evaluation of several criteria related to the requirements/needs of the specific project to be carried out. Hence, it is advisable to carry out this evaluation with the project leader or project manager to get full knowledge about the project. Finally, the multiplication of the two previously obtained matrices is carried out. Once these values are obtained, the total vertical sum of the values (per column) is executed. The totals obtained from the sum for each column, allow visualizing the methodologies that are better accommodated to what the project requires, with the highest score being mainly recommended. Subsequently, the definition of criteria that allow the quantitative qualification by SW development methodology is carried out.

This study also contributes to better understanding the SW development methodologies selected, since it requires a previous analysis of them, in order to synthesize their important and relevant characteristics, and then quantify them.

2 Related Work

In this section, we present the studies that have approached the use of models to select a SW development methodology.

Verma et al. [3] proposed a rule based expert system as a base for software engineers in the selection of the best software development methodology for a project. The proposed systems is block-based. The first block represents the software development methodologies. The next block represents selection criteria, final score, dynamic priority allocation and results. The result block present blocks with check boxes and the priorities can be assigned between 0 and 10. After making the entire selection, a “Decide” button is pressed and the result is displayed in the result text box with the selected model. The “View Heuristic Report” button gives the entire report with situational analysis. Their future work will include more software development methodologies and more selection parameters.

Mahapatra and Goswami, identified in [4] different project characteristics that influence the decision of selecting the most appropriate software development methodology for a specific project, based on the literature review of different software development methodologies (i.e. waterfall, prototype, iterative, spiral, RAD, XP). The selection of the project characteristics is based on requirement analysis, status of development team, users’ participation, project type and associated risk.

In [5], an analysis of factors that influence the decision of choosing the most suitable software development methodology for a project is presented. Three popular software development methodologies are considered: RUP, XP, and RAD. The findings of the analysis provide information regarding which methodology is best to be used depending on the level of each factor for a specific project.

In the following, we present a model proposed, which makes use of matrices, the product between them and specific qualifications of a project to be evaluated given by the representative of the organization that will develop the SW, to guide which software development methodology is best suitable to a specific project.

3 Methodology

We propose a model with the objective of selecting a SW development methodology that meets the requirements of the SW project to be developed. We start by introducing the definition criteria: development methodologies and selection criteria.

3.1 Definition Criteria

In this section, the analysis of the criteria to be considered for the selection of a development methodology is carried out, allowing to make the best use of the available resources for the realization of a SW project [5].

  1. i.

    Development Methodologies

The selection of the methodologies to be evaluated was carried out under the results obtained in the case of study carried out in “Mobile application development process: A practical experience” [1], in which the following methodologies were used in academic and industry contexts: RUP, RAD, SCRUM, and XP.

  1. ii.

    Selection Criteria

Once the methodologies to be evaluated are defined, the following criteria are considered:

  1. (a)

    Budget: the available budget with which a project for its development has a direct influence on the methodology to be selected, since those large-scale projects require a greater number of resources. The ideal of this criterion of selection is that it does not demand excessive expenses.

  2. (b)

    Delivery time: ideally, every project should be carried out and delivered as soon as possible; however, there are activities inherent to the methodologies, such as the delivery of formal documentation, the holding of periodic meetings, among others, which may extend or shorten times. This is why the delivery time of the project is decisive as to the methodology to be selected. Agile methodologies, as its name suggests, are known to have cycles or fast phases, so they are considered ideal when carrying out a project that presents a limited time.

  3. (c)

    Documentation: Formal documentation can be generated in both agile and traditional methodologies; however, for the latter, the rigor or extension of documents surpasses those presented in agile methodologies. Although documentation may be omitted for certain projects, according to their development team and the conditions agreed with the client, others cannot leave aside having documented supports.

  4. (d)

    Human resource: In addition to the number of people who make up a development team, it is important to consider the role of each one of the members. Furthermore, within a project, according to the methodology, not only the presence of the development team but also the customer and even end users may be necessary. Being recommendable the presence of all the parts for all phases of project activity. Therefore, it is advisable to identify the availability of personnel that is required in the short and long term, how important it is and in this way to be able to select which methodology allows covering these particularities.

  5. (e)

    Project dimension: Identifying the dimension of a project immediately may not be a simple task, however, it is vital to know its dimension, so that it can align several criteria, such as resources that are required both human and time, to its time the budget, among others; and thus opt for the methodology that corresponds to the identified. In this criterion, to a greater dimension of the project, greater need of resources, reason why the “ideal” are projects of medium or small dimension.

  6. (f)

    Adaptability: It is important to mention that in the course of the development of a project, significant changes may occur, and much depends on the project so that the adaptability that a methodology has to those changes is considered important. Although every project is susceptible to improvement, certain projects within its development present constant changes, for which the flexibility that the methodology can provide is of paramount importance.

3.2 Development of Criteria for SW Development Methodologies

The methodologies selected have multiple characteristics which, when deployed under different factors, may become advantages as well as disadvantages. Then, we present the differences that stand out in each of the development methodologies according to previously defined criteria (Table 1, 2, 3, 4, 5, 6 and 7) [5].

Table 1. SW development methodologies and budget available
Full size table
Table 2. SW development methodologies and delivery time
Full size table
Table 3. SW development methodologies and time boxing
Full size table
Table 4. SW development methodologies and adaptability
Full size table
Table 5. SW development methodologies and documentation
Full size table
Table 6. SW development methodologies and human resource
Full size table
Table 7. SW development methodologies and project dimension
Full size table

In this section, each methodology was characterized according to previously established criteria, and based on these qualitative characteristics, we will obtain the quantitative ones that will give rise to the first matrix that is required. Then, based on the behaviour that each methodology presents against each criterion, will be carried out respective quantification.

3.3 Quantification of Criteria by SW Development Methodology

In the present section, the obtained matrix allows to visualize the degree of compliance of each methodology with respect to each criterion, the qualification being values between 1 and 5. The lower value (min. 1) represents a poor or undesired fulfilment of certain criterion, while the highest value (maximum 5) constitutes the best or ideal fulfilment of said criterion (Table 8).

Table 8. Quantitative criteria in relation to methodologies
Full size table

3.4 Evaluation of the General Requirements of the Project

In this phase of the proposed model, it is fundamental the participation of the project leader, who will be in charge of evaluating characteristics of the SW project to carry out, even for which a SW development methodology is required, regarding the criteria established. Before the questions that cover the criteria to be evaluated, we obtain affirmative and negative answers, assigning a value of one and zero respectively, according to the needs that the project presents (Table 9).

Table 9. Evaluative criteria: application case
Full size table

3.5 Matrix Multiplication

Matrices are instruments of algebra that facilitate the ordering and handling of data, and appear in situations specific to the Social, Economic and Biological Sciences [6]. In the proposed model, once the necessary data are obtained from the two matrices, a product of these matrices is made, between the matrices A and B, quantitative criteria and evaluative criteria (numerical results of Tables 8 and 9), respectively.

figure a

3.6 Obtaining Results

Once the matrix multiplication described in the previous point is performed, the resulting values are summed, column by column; obtaining in this way the score of each software development methodology based on the criteria established by the project leader or project leader. With the values obtained, sorted in ascending order, is possible to visualize which methodology presents the highest value, being this one that is better adapted to the project to be carried out and for which the methodology is sought. In addition, if one could not opt for the best rated methodology; the following values are available, which the higher the value the better the adaptation will present.

4 Implementation

Next, the proposed model is developed within a possible scenario. To begin the development of the model, a project leader was contacted, responsible for carrying out the development of a mobile application, which, when answering questions about his project, allowed us to define the evaluative criteria of the software product, which become the initial or basic requirements.

The project leader will develop a mobile application that allows online purchases (e-commerce), with the following particularities. The project itself is extensive, has a limited budget, and the delivery time of it is not limited. However, they would be willing to leave behind the development of extra features or non-essential complementary to meet the times/schedule of the project. Robust documentation, the presence of the client, and the adaptability of the methodology to be adopted in this project are totally required and necessary. While, you do not need a robust and large development team, nor is it critical with iterations in the process of developing the mobile app (Table 9).

Once the evaluative data of the project are obtained, the product of matrices is carried out, based on the quantitative criteria defined by development methodology in the proposed model and the evaluative criteria (Tables 8 and 9, matrices A and B respectively). Finally, after the matrix product (matrix C) and the vertical summation of the values by methodology, the resulting values are obtained (Table 10).

Table 10. Quantitative criteria in relation to methodologies
Full size table
figure b

In the present scenario, we have as a result: SCRUM: 23, AUP: 22, RAD: 21 and XP: 18. It is thus evident:

  • It is a question of the development team and/or leader of the project, the selection of a methodology or another, who should take into account that the higher the score presents a methodology, the greater the coupling to the requirements of the project will have. Therefore, the totals of the methodologies function as indicators of their coupling with the evaluated project.

  • The methodology that mostly covers the requirements of the described project (application case) is SCRUM, and although this methodology may or may not be adopted by the development team. An additional list of methodologies is given with a respective order, allowing visualizing which are coupled of best to not so recommended way, being in this case punctual: AUP, RAD and XP.

  • The strengths of the methodology recommended in the first instance can be highlighted. Scrum allows a short delivery time, does not require excessive expenses, and is achieved with an affordable budget for the project. Additionally, Scrum performs time boxing, and adapts to changes at any point in the SW development process, being flexible in its entirety.

5 Discussion

In this section, we present the main finding of the study and highlight the limitations that may threaten the validity of the study and examine the implications for research in this field.

The main finding in the present research is that although the proposed model may be a reference for the selection of a software development methodology, it is worth mentioning that there are other influential factors when selecting a methodology. Such factors may be specific needs not included in the criteria presented in the proposed model, given that technological projects possess qualities that are inherent to the environment in which they are developed.

The main challenge of the study is the evaluation of a limited number of methodologies, so that in the future adding methodologies and/or methods would allow a favourable variety to be used for those who use this proposed model, obtaining a wide range of recommendations.

Furthermore, a major challenge of the proposed model is to have a limited number of evaluative criteria, as well as SW development methodologies. A greater number of criteria are required and these are as specific as possible, so that the evaluation of the methodologies is greater and complete. Likewise, increasing and improving the evaluation criteria of the project to be developed, qualified by the project leader or project manager, would help to give results that are even more complete.

Moreover, the finding mentioned above can be considered as a possible future research topic, and better, if more methodologies and a greater number of evaluation criteria are considered for them, so that the range of options is larger and therefore more complete.

The first ambitious implication is the formalization of the proposed model, making it possible for the model to be used by those who wish to guide the methodology that is appropriate for the development of their project based on the main and outstanding characteristics of the project.

A second implication is the investigation of mobile applications characteristics, in order to find criteria that are related to this type of software with the development methodologies. In order to guide in the selection of a methodology for the development of mobile applications specifically, taking advantage of the features and functionalities of mobile devices such as screen size, sensors, GPS, cameras, among others.

6 Conclusions

Since there are many development software methodologies, one of the challenges faced by software developers is to decide which methodology to apply in each specific software project. In our present work, we present an approach to help with this issue by comparing four different software development methodologies based on project specific characteristics. The methodologies selected were the result of a previous research case study, in which the units of analysis, both in industrial and academic contexts, used them as base for implementation.

It is not possible to determine a particular methodology as better than all others for all purposes. A methodology of software development will be advisable and better adapted to a project according to the characteristics of the project. Selecting the methodology depends on different project characteristics. Therefore, although the model may guide the selection of a methodology, an expert, considering the factors that the model does not contemplate and still may have importance in the organization or in the project to be developed, should take the final decision.