English (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
I. INTRODUCTION
Since the appearance of computer engineering as an academic discipline, models, frames and methodologies that describe the "basic steps" or ideals to adequately carry out software development projects have been proposed. Nevertheless, the lack of homogeneity on factors such as development styles, working teams, and resources, among others, have resulted in the existence of many methodologies, mainly focused on team work (i.e., two or more people). Additionally, the students interested in this discipline, during their academic formation, are continually compelled to conduct individual projects, mostly without orientation or a methodology. Therefore, during this process, the students continuously encounter problems and make mistakes that are not detected until the resulting product is turned in
Current methodologies used to develop software (eXtreme Programming -XP, Cascade, and Iteractiv, among others) propose the conformation of teams with at least 5 people, which constitutes the major difficulty to apply them to individual projects. Moreover, in these methodologies, each team person complies with very specific functions, and in several phases there are not transversal communications among them. On the other hand, the delivery time is usually 15-30 days per delivery, which means an estimated of 90-120 days to have the final product; however, students do not have that long in an academic project, since they are given only 30 to 60 days to complete these projects. Furthermore, a significant investment in financial and physical resources is required, which is not taken into account in most of the software development academic projects.
Based on expert opinions, it can be deduced that an individual software development methodology must count with all the quality and efficiency aspects of a product developed by a team. Such methodology should provide the necessary phases and tools to offer the versatility of the traditionally used methodologies, complying with deadlines, objectives, and defined scopes of the project.
With this motivation, in this paper, we formulate a methodological proposal to develop software, called "DeSoftln", which allows, mainly computer engineering students, to have a reference point when they have to work individually. To achieve this, initially, we searched for current theories, and compared the most used methodologies, which is explained in the next chapter; subsequent chapters describe the developed methodological proposal, the evaluation of such proposal, and the conclusions and recommendations.
II. METHODOLOGY
To develop this research, we defined three main phases: 1) literature search to elaborate the state of the art of the research topic; 2) selection and comparison of the current most used methodologies, based on widely known cases where they have been used, plus experiences of professionals in the area; and 3) proposal of a methodology to individually develop software, application of such methodology in a study case, and evaluation using the 4-DAT (4-Dimensional Analytical Tool) method.
In the first phase, we carried out a systematic study on the investigations conducted during the past five years, focused on software development methodologies and their applications in different contexts; for this, we searched articles in different indexes, indicators, and scientific data bases, such as Re0dalyc and IEEE Xplore. After gathering the articles, we read those that had more citations, with the objective to select the ones most closely related to the objective of our study. The most relevant selected articles are presented in
Table 1 Literature revision
| Title | Year | Reference |
|---|---|---|
| Propuesta pedagógica: Una metodología de desarrollo de software para la enseñanza universitaria | 2011 | [2] |
| Propuesta metodológica para desarrollo de software educativo en la Universidad de Holguín | 2016 | [3] |
| Taxonomía de los modelos y metodologías de desarrollo de software más utilizados | 2012 | [4] |
| Propuesta de metodología de desarrollo de software para objetos virtuales de aprendizaje -MESOVA- | 2011 | [5] |
| Metodología ágil para equipos pequeños usando plataformas Microsoft | 2011 | [6] |
| Análisis de alternativas metodológicas para el desarrollo de software educativo | 2014 | [7] |
| El desarrollo de software dirigido por modelos en los repositorios institucionales | 2014 | [8] |
| Proceso para gestionar riesgos en proyectos de desarrollo de software | 2013 | [9] |
| Reflexiones acerca de la adopción de enfoques centrados en modelos en el desarrollo de software | 2011 | [10] |
In the second phase, we selected and categorized the software development methodologies, particularly those known as agile, searching in the selected literature and interviewing professionals in the area; this with the goal of establishing a comparison that would allow us to detect failures in those methodologies when applied to the projects individually developed.
Once we identified the advantages and disadvantages that the selected developing methodologies have when applied to individual projects, we extracted their most relevant characteristics, and those with the best reception among developers; thanks to this, we were able to propose a methodology supported by experiences, successful cases, and expert opinions. This methodological proposal was applied in a study case, with the aim to evaluate its performance in relation to methodologies with longer trajectory and success; additionally, it was evaluated by the 4-DAT method.
III. METHODOLOGICAL PROPOSAL "DESOFTIN"
In this section, we formulate the methodological proposal, explaining the necessaries phases, roles, abilities, and skills necessary to successfully accomplish the individual projects.
A. Phases
1) Planning and analysis: The main action to be accomplished in this phase is the definition of the project scope, which should be accompanied with the analysis of requirements, in order to establish or estimate times, as well as to evaluate the required knowledge on tools, technics, and technologies to be used.
In order to plan and control the time, it is important to differentiate in the analysis between what it should be done and what can be achieved, since it is necessary to take into account the customer limitations and restrictions, mainly at the resources level. Once this is clear, the activities that will be carried out in each one of the sprints are defined, according to their prioritization. These activities will be represented on a timeline that, taking into account the "Last Planner System" 11, is revised backwards from end to beginning, with the goal of supplying and disposing the required resources beforehand, and thus, avoiding waiting until the last minute to search for such resources. Posteriorly, a deadline to complete the development must be set, which should include the necessary time to get qualified or to learn any of the required aspects that are not yet mastered by the developer.
It is important to include, like in any development, risk planning, in order to identify those responsible to apply the defined answers for each risk during the application development. Lastly, the requirements should be a priority, so that the design can begin with those that are the most important and transversal to the whole project; this will allow to have, after the first delivery, a functional product.
It should be pointed out that the requirements, contrary to the proposal for the documentation of the rest of the methodologies, are not presented with the traditional forms; instead, we propose to use a checklist of the customer required functionalities, linking them to the system roles (Fig 1). In the checklist, those users that intervene in a specific functionality are marked with an X, which simplifies for the developer the unified control over the permissions, roles, and functionalities of the project.
The planning and analysis phase is not compulsory taken as incremental, due that, by nature, the academic projects determine from the beginning all the requirements. In case of including new requirements during the project development, it is suggested to end the initially defined requirements, and then to include an iteration of this phase to introduce them.
2) Design: Once the requirements are defined (previous phase), they are gradually included in each design delivery, according to their priorities. Also, in this phase, the necessary information for the optimum implementation of the requirements must be compiled and complemented.
To make the different diagrams, we suggest to use the BPMN (Business Process Model and Notation); nevertheless, it is left to the designer's judgment the elaboration of a diagram that provides a global vision of the business. Additionally, the interphase prototypes should be made in this phase, so they can be validated with the customer, and can be approved and improved to pass to the next phase.
3) Development: The development phase is the one that implies the major responsibilities within the interactive phases, because in this one, the approved requirements should be "coded", in order to obtain a functional result; likewise, in this phase the developer's self-criticism and expertise are tested.
After the first delivery, or first sprint if it gets associated with SCRUM, additional recommendations made by the consultant or the client, as well as the requirements to be developed in each one of the deliveries are included. Both in the design and in the development, the form shown in figure 1 can be used, including a color range that indicates the progress of the fulfillment of each requirement. In figure 2, the color green indicates a developed requirement that has been approved by the client; orange, a requirement that is in evaluation phase; yellow, a requirement that is in development; and red, those functionalities that have not yet been initiated.
4) Implementation: Once development is complete, the prototype must be applied, validated, and tested. In these three processes, attention should be paid to the recommendations and suggestions found in norms and standards on software quality models, such as ISO/IEC 15504 12. Likewise, regarding the testing process, guidance from standards and norms on information security, such as the ISO 27000, is suggested.
Additionally, in this phase, the functionalities developed at each delivery must be integrated, and the respective quality and integration tests must be carried out. It is important to include in this phase the issues related with risk management, in order to establish monitoring and control strategies. Also, the impact of every established risk should be taken into account, which requires great ability and knowledge from the developer, along with notable communication skills to alert the customer about such risks without causing alarm.
On the other hand, in case the developed software needs to be integrated into other system, the corresponding integration tests should be conducted during each one of the iterations, with their respective developed functionalities.
5) Evaluation: At the end of each phase, which should not take longer than 10 days, a joint evaluation between the developer "team" and the customer should be carried out, in order to evaluate whether the developed and implemented product complies with the planned. Also, a meeting with the consultant or adviser is suggested, with the aim to obtain opinions, from a technical point of view, about the quality of the product that will be turned in. Figure 3 shows the flow among the described phases.
B. Roles
Given that the projects are developed individually, it is not clear to talk about the roles; nevertheless, two roles are proposed within this methodology: the project team (a one-person team) and the consultant.
1) Project equipment: In the development of the methodology proposed here, the project team is composed by one person, who is responsible for all the different proposed duties, as the project leader, developer, tester, and architect, among others; additionally, he/she has the responsibility to decide how to organize the fulfillment of the proposed objectives for each iteration.
2) Consultant: Although the methodology is proposed as individual, it is suggested to have an external collaborator with specific knowledge on the project subject. This is included because the methodological proposal is oriented, firstly to undergraduate developments, in which the consultant labor can be performed by the student's advisor. Such consultant may contribute with ideas and experiences that would enrich the product, and since his/her work is less active, the dedication need is minimum.
C. Abilities and dexterities
This aspect presents the major difficulty for the methodological proposal because the same person should have too many abilities, both technical and personal. Among the main abilities that should stand out in those persons applying the methodology are the following:
Active and patient communications skills to be able to abstract and retain the information given by the client during the requirements phase. Also, the person should be able to explain every decision made throughout the process, in order to clearly explain the obtained results.
Ability to work individually without supervision, since the person should be able to challenge himself and control his own time, which demands a high level of discipline.
Excellent formation and knowledge regarding the tools and technics to be used. Furthermore, the person should have a quick and effective learning capacity or "curve", in case there is a need for making adjustments or changes in a technology that was not contemplated at the beginning of the project.
Knowledge on tests and software quality and safety tests. This ability is key in the methodological proposal, and the difficulty in its application consists in that is the same developer who conducts most of the evaluation to find errors and failures, both at code and functionalities levels, which may generate personal conflicts of interest.
Capacity to determine, manage, and control risks in different environments, including, at the code level, natural disasters, and attacks, among others.
D. Devices and tecniques
Below, we present the techniques and devices that complement the forms presented in figures 1 and 2.
1) Sprints from 3 to 10 days: By using short sprints, it is possible to make quicker changes, and to have at the beginning small functional versions that allow the customer to have an idea of the product's direction. Additionally, the delivery time is defined in this lapse, since the time limit is shorter for individual developments in the academy (less than two months). It is convenient and relevant to use continuous deliveries, to allow a permanent control by either the advisor or the customer.
2) Breaks between Sprints: Taking into account that the development will be carried out by only one person, it is convenient to define breaks between deliveries; this with the goal of giving some rest to the developer, so he/she can neutrally look at the development in process, and does not get overloaded with responsibilities. In these pauses, it is suggested to include or alternate the resting time with courses that allow acquiring new abilities to apply in the project.
3) Logbook: The developer should have a diary or logbook with the tasks that are being completed in the application. Because the developer is not interacting with other people, a logbook is the best way of efficiently control the changes and inclusions that are being done in the project, in addition to be the best way to evaluate the actions and fulfillment of tasks throughout the project flow.
4) CRC Cards: The CRC cards (Class-Responsibility-Collaborator) allow to control the assignment of responsibilities and the collaboration with other objects. Usually, there is one card per class, which summarizes the class responsibilities and the list of objects with which it collaborates to function [13].
5) Meetings: Once a deliver is finalized, first, a meeting with the customer should take place, followed by a meeting with the consultant, in order to either finish the sprint or plan the necessary adjustments. In both the meetings and the project planning, the dedication should be estimated.
6) Estimation of the dedication: Given that both roles, project leader and developer, fall under the responsibility of the same person, she/he is subject to an elevated level of discipline. Therefore, she/he should clearly differentiate between available work hours, and dedication hours, being the main difference between the two, the leisure hours. For this reason, it is suggested to take into account the formula (1) proposed in 13:
Where DHD is the available days -man; FD, the dedication factor; and VE, the estimated advance speed of the project. The dedication factor is an estimation; in the case of individual development, it refers to the concentration level of the project developer; if this factor is low, it means that the person is susceptible to distractions and impediments (including familiar and personal distractions, among others) that would delay the project delivery time.
E. Tools
Despite most methodologies and metholodological proposals suggest the use of particular tools to control and manage the project, the present methodological proposal leaves this to the developer's own judgment; this with the goal of avoiding any bias in his criterion, and allowing him/her to use the tools he/she is already familiar with and feels more comfortable using, hence preventing him/her to invest time in learning new tools.
IV. EVALUATION OF "DESOFTIN" WITH 4-DAT
The 4-DAT method evaluates, among other aspects, whether a software developing methodology has taken into account the principles of the agile manifesto, in other words, whether it prioritizes people, has a communication orientation, is flexible (easy adaptability), fast (quick and iterative with functional versions of the product), efficient (short time and good quality), adaptable (proper reaction to changes), and has learning capacities (it can be improved during and after the development) 14.
The analysis of the results showed that one of the failures of the methodological proposal corresponds to the efficiency, underlining that the study case presented the most pessimistic values in this regard, that is, assuming that the person who will develop the project needs to learn some of the tools that will be used for it. Furthermore, when averaging the grades presented in Table 2, we obtained the values shown in in Table 3. Finally, Table 4 shows the obtained values when comparing the methodology proposal, XP, and Scrum 15.
Taking into account the results shown in Table 4, even if DeSoftIn obtains a better grade than SCRUM, it is convenient to reiterate that this is a framework, which implies a low grade in the phases' part. Regarding the practices, SCRUM excels notably, and XP is superior to DeSoftIn, which implies that the proposed projected practices should be included or improved.
Although the grade obtained for the methodological proposal, based on dimension 2 of the 4-DAT method, is high, it is noticeable the low efficiency level obtained, which is due to the pessimistic panorama chosen when evaluating the methodology. These faults are complemented by the lack of control provided by an academic peer, and the need of higher dedication and commitment from only one person.
V. CONCLUSIONS
Despite we only present here a software development methodological proposal, and are aware it still needs to be tested under different environments to be improved, we can conclude the following regarding the "DeSoftIn" application:
Minus is more: This is one of the proposal premises, due that it is based on having only the necessary documentation, without the use of the rigid and unnecessary forms, in some cases.
The use of traditional methodologies and models is becoming inefficient due to small work teams, or the work at small scale, particularly because of the amount of forms, designs, and other artifacts that require a lot of time for their elaboration.
Additionally, the use of complex, or even technical, language occasionally hampers the documentation understanding by third parties or by people in the team who did not participate in its writing. Therefore, the use of a logbook that records all the actions that take place in the project will allow a more simplified control.
Quantity is not quality: In reference to the development teams, having big teams hinders communication, whereas within small teams, comprehension and understanding among its members is better. Therefore, although it could be risky that this proposal relies on only one person, when considering individual projects, this person tends to show more responsibility and personal commitment; additionally, in this methodology, we suggest the recurrent advise of an expert, which guides the developer about the actions that must be taken.
Does the client always have the reason? Despite this is a well-known concept within the commercial circle, in the software development area, experts and professionals suggest the contrary: most of the customers do not really know what they want, and therefore, it is necessary to explain them what is possible, and help them to be realistic with their expectations.
DeSoftIn answers to this necessity, and because it does not include the Planning and Analysis phase within the development cycle, it avoids the occurrence of abrupt changes in the requirements; nevertheless, it is possible to consider the client's opinions and criteria on the functionality designs obtained in the requirement analysis.
Continuous learning: When the technologies and tools are imposed by the client, and the developer does not know them, it is necessary the decisive interest of the developer to learn them quickly; this, besides helping him to widen his knowledge on tools and techniques, encourages the continuous practice and update when no projects are under development.
Development of qualities: One of the most criticized factors in the computation area is their professionals' insensibility; nevertheless, this methodological proposal achieves a great sense of responsibility and commitment in the developer, due that his/her reputation "is in play", which additionally allows to value the team work.
Prioritization of simple and short functionalities, and continuous deliveries: This premise gives the developer a sense of increasing productivity, and allows a constant approximation between the client and the system, facilitating the client's contributions and opinions that will prompt the success of the final product.
Risks reduction: When the deliveries are far apart, the difference between the client's expectations and the developed product may be quite distant. Therefore, when the deliveries are set to be closer in time, the product can be realigned in real time, and therefore, the control and management of risks can be agilely determined. Although short times are an advantage in all agile methodologies, using continuous delivery practices reduce the time from 15 to 5 days, and even less, under the throwing modality.
This paper contributes to emphasize that DeSoftIn may become an academic formation element for computing students, given that, contrary to the rest of the methodologies, models and frameworks proposed for software development, it is centered in an academic context.
