software methodologies
Abraham Otero Quintana (abraham.otero@gmail.com)
Francisco Morero Peyrona (peyrona@gmail.com)
1. Introduction
About six years ago one of the authors of this document started
practically simultaneous two different software projects. One was to develop a
desktop application oriented to signal processing whose functionality should be able to be extended
through plugins. The tool had to present an API to the plugins, to facilitate its construction.
In this project several developers were going to participate. The second project consisted in carrying out
a sensitivity analysis of a three-dimensional image reconstruction model. For this it was necessary
to develop software that invoked the model (a program) with multiple variations of
its parameters on a wide collection of image databases, and perform an analysis of
these results using several tools (other existing programs).
Both projects were carried out successfully. The first was developed in Java and remains
maintained and extended today. It has begun to be used outside the organization where it was
created, and it is foreseen that it will continue to be used in ten years' time. The second took the form of
a Python script of approximately three hundred lines. It was executed once successfully (in it
it took about six days in a machine out of series at that time) and provided the
results that were expected of him. At this time, the author does not keep a copy of that
program.
The question that seeks to answer this document is: Does it make sense to use the same process of
software development in both projects? Obviously not. It is not the same as a project designed
to be extended, which is expected to be used (and therefore will be maintained) for many years and in
which will involve several developers, a "project" consisting of develop a script
that is only going to be executed once, it will be developed by a single person, it will not be extended
and it will not be necessary to maintain it. From the point of view of the return on investment, what is the point of
investing time in making this script more readable and maintainable if its successful use has been completed once it has been executed successfully
?
That script was the first program in Python that I (Abraham) wrote. I took many shortcuts and the
code was horrible. When I got it working, I automatically went into mode
"refactoring", and started using my text editor to give better names to the variables and try
to structure the code into functions. After a while a question began to torment me: For
what was doing all that? My developer instinct told me to write software
readable and easy to maintain. However, I was actually wasting my time. It made no sense
to invest more effort in that piece of software. All he had to do now was throw it and
wait six days to get the result.
1
1.1. The white elephant in the room of the methodologies
of software development
Not all the software that we develop requires the same quality. It is not the same to develop a
software that is only going to be executed once, that a software that probably will never be
necessary to modify except to correct bugs, that a software that we expect to be used during
many years and continue to spread. It is not the same to develop a software that is going to be used
in an isolated way, that a software that is going to have to integrate with other applications, that a
software that must expose an API on which it is going to build more software The amount of
effort and resources that must be used to develop a framework that we plan to publish
is not the same amount of effort and resources that are needed to develop a web application
of Intranet. Even though the framework and the web application have the same number of lines of
code. The first development must have a higher quality, and therefore it will require more resources and
time.
The content of the previous paragraph is an authentic triviality. Any experienced developer
knows what is counted in him. But this being so, why does not any software development methodology
take this into account? All software development methodologies, both agile
and the more traditional ones, tend to define a process that is aimed at achieving software
of the highest possible quality. But you do not always want to obtain the highest possible quality. Time and
resources, always limited, dictate that a public framework and a simple web application of
Intranet do not require the same quality and, therefore, should not use the same development process.
We argue that from the beginning of a software development process, it should
try to define in an explicit way the level of quality that makes sense that is reached and that
this influences the development process . We want to make it perfectly clear that this is not
we are looking for excuses to develop software of poor quality. Perhaps in an ideal world everything
the developed software would have a maximum quality (often, this seems to be the objective that they try
to reach the methodologies of software development). But in the real world this is not the case; and
software development methodologies should assume this reality by defining different processes
to achieve different levels of quality.
It might seem an elementary reflection, but since we had this perception, we started
to approach the software projects in a different way. Define explicitly from the beginning
what level of quality you want to achieve, and based on that which techniques and tools will be used
to try to get there has changed our way of dealing with software projects. Actually, the
developers, before undertaking a software project, carry out this analysis in their head, and in
they base a series of decisions that will guide the development. However, this process in
today is quite informal, implicit and not usually documented, in the same way that
twenty years ago the good developers did refactoring, but it was not a formal process.
We argue that this process should be something formal, should be done explicitly,
should be documented and maybe even should be part of a business contract for the
development of an application.
Formalizing these tasks that we all do informally will allow us to share in a more efficient way
knowledge about how to try to reach different levels of quality within a project.
In the same way as formalizing the concept of refactoring allowed to create a common vocabulary
to talk about refactoring, which facilitated the sharing of knowledge about this practice and the
creation of a set of tools to support in these Homeworks.
2
1.2. Good practices
The central idea of this document is that the definition of the global level of quality to be achieved in a
software project must be one of the explicit steps in the analysis stage of the project. And that
the level of quality that you want to achieve must influence the software development process.
This is the most important message we want to convey. Then we will reflect on
the different factors that impact on the level of quality that a project requires. After
we will expose a series of recommendations (which serve us, but which each one will have
to adapt to their reality) to reach different quality levels corresponding to different
project categories. Like almost any good practice in the world of software development,
these recommendations should be taken with caution and adapted to the context in which they are going to
apply. These recommendations are only "good practices" that have worked for us.
Possibly others in the future share their own good practices. And should this
occur, we are sure that you will not agree in part or totally with the samples. There will never be
a consensus in this sense, just as there is currently no consensus on what the software development methodology to be used is
. We believe that the details are not as important
as the general concept itself.
2. Factors that impact the level
We will distinguish two different types of factors: intrinsic and external. The former have to do
only with the nature of the project itself, while the latter are related to the particular environment
where it will be developed.
2.1. Intrinsic factors
2.1.1. How much code will depend on our code?
The first intrinsic factor that influences the level of quality required is how much code goes to
depend on this project ?. As a general rule, the more code you are going to use (depend on)
our project, the more quality the latter should have.
Suppose, for example, that the piece of code for which we wish to establish a level of
quality is a library that we hope to reuse internally within our company in several
projects. If the library has failures, it will impact all the projects that use it. If any of the
projects that use it have failures, not from the library, they will only affect that project and the
from Nettech Post http://bit.ly/2SrVXNa
No hay comentarios:
Publicar un comentario