PDF de programación - Niveles de calidad: el agujero en las metodologías de software

Imágen de pdf Niveles de calidad: el agujero en las metodologías de software

Niveles de calidad: el agujero en las metodologías de softwaregráfica de visualizaciones

Publicado el 26 de Diciembre del 2018
190 visualizaciones desde el 26 de Diciembre del 2018
278,8 KB
16 paginas
Creado hace 7a (18/02/2013)
Niveles de calidad: el agujero en las
metodologías de software



Abraham Otero Quintana (abraham.otero@gmail.com)
Francisco Morero Peyrona (peyrona@gmail.com)

1. Introducción

Hace aproximadamente seis años uno de los autores de este documento comenzó de modo
prácticamente simultáneo dos proyectos de software diferentes. Uno consistía en desarrollar una
aplicación de escritorio orientada al procesado de señal cuya funcionalidad debía poderse extender
mediante plugins. La herramienta debía presentar un API a los plugins, para facilitar su construcción.
En este proyecto iban a participar varios desarrolladores. El segundo proyecto consistía en realizar
un análisis de sensibilidad de un modelo de reconstrucción tridimensional de imágenes. Para ello era
necesario desarrollar un software que invocase al modelo (un programa) con múltiples variaciones de
sus parámetros sobre una amplia colección de bases de datos de imágenes, y realizar un análisis de
estos resultados empleando varias herramientas (otros programas ya existentes).

Ambos proyectos se llevaron a cabo con éxito. El primero se desarrolló en Java y sigue siendo
mantenido y extendido en la actualidad. Ha comenzado a usarse fuera de la organización donde se
creó, y previsiblemente dentro de diez años todavía se seguirá usando. El segundo tomó la forma de
un script de Python de aproximadamente trescientas líneas. Se ejecutó una vez con éxito (en ello
tardó unos seis días en una máquina fuera de serie en aquellos momentos) y proporcionó los
resultados que se esperaban de él. En estos momentos, el autor no conserva una copia de ese
programa.

La pregunta que pretende contestar este documento es: ¿Tiene sentido emplear el mismo proceso de
desarrollo de software en ambos proyectos? Obviamente, no. No es lo mismo un proyecto diseñado
para ser extendido, que se prevé que se usará (y por tanto mantendrá) durante bastantes años y en el
cual van a participar varios desarrolladores, que un "proyecto" que consiste en desarrollar un script
que sólo se va a ejecutar una vez, va a ser desarrollado por una única persona, no va a ser extendido
y no va a ser necesario mantener. Desde el punto de vista del retorno de inversión ¿qué sentido tiene
invertir tiempo en hacer ese script más legible y mantenible si cuando se ejecute una vez con éxito
ha terminado su vida útil?

Ese script fue el primer programa en Python que yo (Abraham) y escribía. Tomé muchos atajos y el
código era horrible. Cuando conseguí hacerlo funcionar, automáticamente entré en modo
"refactoring", y comencé a usar mi editor de texto para dar mejores nombres a las variables e intentar
estructurar el código en funciones. Al cabo de un rato una pregunta comenzó a atormentarme: ¿Para
qué estaba haciendo todo eso? Mi instinto de desarrollador me decía que debía escribir software
legible y fácil de mantener. Sin embargo, en realidad estaba perdiendo el tiempo. No tenía sentido
invertir más esfuerzo en esa pieza de software. Lo único que tenía que hacer ahora era lanzarlo y
esperar seis días para obtener el resultado.

1

1.1. El elefante blanco en la habitación de las metodologías

de desarrollo software

No todo el software que desarrollamos requiere la misma calidad. No es lo mismo desarrollar un
software que sólo se va a ejecutar una vez, que un software que probablemente nunca va a ser
necesario modificar salvo para corregir bugs, que un software que esperamos que se emplee durante
muchos años y se continúe extendiendo. No es lo mismo desarrollar un software que se va a emplear
de modo aislado, que un software que se va a tener que integrar con otras aplicaciones, que un
software que debe exponer una API sobre la cual se va a construir más software. La cantidad de
esfuerzo y recursos que hay que emplear para desarrollar un framework que pensamos hacer público
no es la misma cantidad de esfuerzos y recursos que se necesitan para desarrollar una aplicación web
de Intranet. Incluso aunque el framework y la aplicación web tengan el mismo número de líneas de
código. El primer desarrollo debe tener una calidad más alta, y por tanto requerirá más recursos y
tiempo.

El contenido del párrafo anterior es una auténtica trivialidad. Cualquier desarrollador con experiencia
sabe lo que se cuenta en él. Pero siendo esto así ¿Por qué ninguna metodología de desarrollo de
software tiene esto en cuenta? Todas las metodologías de desarrollo de software, tanto las ágiles
como las más tradicionales, tienden a definir un proceso que está orientado a conseguir un software
de la máxima calidad posible. Pero no siempre se desea obtener la máxima calidad posible. Tiempo y
recursos, siempre limitados, dictan que un framework público y una aplicación web simple de
Intranet no requieren la misma calidad y, por tanto, no deberían usar el mismo proceso de desarrollo.

Nosotros argumentamos que desde el principio de un proceso de desarrollo de software, debería
tratar de definirse de un modo explícito el nivel de calidad que tiene sentido que se alcance y que
éste influya en el proceso de desarrollo. Queremos dejar perfectamente claro que con esto no
estamos buscando excusas para desarrollar software de mala calidad. Quizás en un mundo ideal todo
el software desarrollado tendría una calidad máxima (a menudo, éste parece ser el objetivo que tratan
de alcanzar las metodologías de desarrollo de software). Pero en el mundo real esto no es así; y las
metodologías de desarrollo de software deberían asumir esta realidad definiendo distintos procesos
para alcanzar distintos niveles de calidad.

Podría parecer una reflexión elemental, pero desde que tuvimos esta percepción, comenzamos a
abordar los proyectos de software de un modo diferente. Definir explícitamente desde el principio
qué nivel de calidad se desea alcanzar, y en base a eso qué técnicas y herramientas se van a emplear
para intentar llegar allí ha cambiado nuestra forma de afrontar proyectos software. En realidad, los
desarrolladores, antes de emprender un proyecto de software realizan este análisis en su cabeza, y en
base a eso toman una serie de decisiones que van a guiar el desarrollo. Sin embargo, este proceso en
la actualidad es bastante poco formal, implícito y no se suele documentar, del mismo modo que
hace veinte años los buenos desarrolladores hacían refactoring, pero no era un proceso formal.
Nosotros defendemos que este proceso debería ser algo formal, debería realizarse de modo explícito,
debería ser documentado e incluso quizás debería formar parte de un contrato empresarial para el
desarrollo de una aplicación.

Formalizar estas tareas que todos realizamos de modo informal permitirá compartir de un modo más
eficaz conocimiento sobre cómo tratar de alcanzar distintos niveles de calidad dentro de un proyecto.
Del mismo modo que formalizar el concepto de refactoring permitió crear un vocabulario común
para hablar sobre refactoring, lo cual facilitó el compartir conocimiento en torno a esta práctica y la
creación de un conjunto de herramientas para apoyar en estas tareas.



2

1.2. Las buenas prácticas

La idea central de este documento es que la definición del nivel global de calidad a alcanzar en un
proyecto de software debe ser uno de los pasos explícitos en la etapa de análisis del proyecto. Y que
el nivel de calidad que se desea alcanzar debe influir en el proceso de desarrollo de software.

Éste es el mensaje más importante que queremos transmitir. A continuación reflexionaremos sobre
los distintos factores que impactan en el nivel de calidad que requiere un proyecto. Después
expondremos una serie de recomendaciones (que a nosotros nos sirven, pero que cada cual tendrá
que adaptar a su realidad) para alcanzar distintos niveles de calidad correspondientes con distintas
categorías de proyectos. Como casi cualquier buena práctica en el mundo del desarrollo de software,
estas recomendaciones deben ser tomadas con prudencia y adaptadas al contexto en el cual se van a
aplicar. Estas recomendaciones son sólo "buenas prácticas" que a nosotros nos han funcionado.
Posiblemente otros en el futuro compartan sus propias buenas prácticas. Y en caso de producirse
esto, estamos seguros que no estarán de acuerdo en parte o totalmente con las muestras. Nunca habrá
un consenso en este sentido, del mismo modo que en la actualidad no hay un consenso sobre cuál es
la metodología de desarrollo de software a usar. Creemos que los detalles no son tan importantes
como el concepto general en sí.

2. Factores que impactan el nivel

Distinguiremos dos tipos de factores diferentes: intrínsecos y externos. Los primeros tienen que ver
sólo con la naturaleza del propio proyecto, mientras los segundos están relacionados con el entorno
particular donde se va a desarrollar.

2.1. Factores intrínsecos

2.1.1. ¿Cuánto código va a depender de nuestro código?
El primer factor intrínseco que influye en el nivel de calidad requerido es ¿Cuánto código va a
depender de este proyecto?. Como regla general, cuanto más código vaya a emplear (dependa de)
nuestro proyecto, más calidad deberá tener este último.

Supongamos, por ejemplo, que la pieza de código para la que deseamos establecer un nivel de
calidad es una librería que esperamos reutilizar internamente dentro de nuestra empresa en varios
proyectos. Si la librería tiene fallos, impactará a todos los proyectos que la usan. Si alguno de los
proyectos que la usa tiene fallos, no provenientes de la librería, sólo afectarán a ese proyecto y el
  • Links de descarga
http://lwp-l.com/pdf14675

Comentarios de: Niveles de calidad: el agujero en las metodologías de software (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios
Es necesario revisar y aceptar las políticas de privacidad