Desarrollar software es difícil - Metodologías de Software

Desarrollar software es difícil
Por Ing. Dalia Trujillo MSc.
www.magis.com.co
Uno de los primeros temas que me parece importante tocar en este blog, es crear la
conciencia que hacer ingeniería de software es altamente complejo y riesgoso.
Riesgoso en términos de no cumplir los presupuestos, no cumplir los tiempos y al
final obtener software de calidad baja que le genere al negociodificultades dados
los errores de producción.
En qué consiste la dificultad del desarrollo de software?
Puedo resumir la dificultad del desarrollo de software en las siguientes causas raíz:
El software es un intangible difícil de medir en términos de avance y
cumplimiento de expectativas. Cuando se está mandando hacer una obra civil, sea
una casa o un puente, como usuario puedo ver cómo estáavanzando la estructura y
la obra en sí. Si existe una relación o un cambio de estructura es más fácil de
visualizar con todos los implicados. En software el avance es difícil de medir: una
pantalla no necesariamente demuestra el avance o la dificulta que hubo en
generarla.
El software está lleno de relaciones difíciles de controlar, por su cantidad o
por su sutilidad. Los requerimientos estánrelacionados entre sí, de forma que es
muy difícil de mantener en mente, ni mucho menos en la vista. El diseño está
relacionado entre sí, y las líneas de código también tienen sus propias relaciones.
Las relaciones son fuertes y sutiles, dando siempre la posibilidad que un cambio en
requerimientos, diseño o código lleve a consecuencias que no se podían prever.
Esto también causa dificultad paraprobar el software.
La base del desarrollo es la comunicación entre diferentes personas de
distintos perfiles: cliente, usuarios, analistas de requerimientos, arquitectura,
diseñadores y desarrolladores, probadores, analistas de pruebas, personas de
soporte y operación. La comunicación coloquial tiene tanta variabilidad que hay
posibilidad de ambigüedades y diferencias de interpretacióndependiendo del
paradigma que cada uno tenga en la cabeza.

El desarrollo es muy difícil de estimar por la cantidad de variables incluidas:
interpretaciones de requerimientos, retos tecnológicos, cambios en los
requerimientos por desconocimiento, por modificaciones en el negocio o por
entendimiento del negocio.
La probabilidad de cambio de los requerimientos es muy alta, dado que los
negociosson cambiantes lo que ocasiona que las prioridades y las características
del software
Todo esto se agrava entre más grande sea un proyecto porque hay más
requerimientos (con sus relaciones) y más personas involucradas.

Y las metodologías realmente ayudan?
Las metodologías recogen de forma organizada mejores prácticas demostradas en
la industria para su correcta aplicación. Sin embargo, aveces son tomadas como
balas de plata o como la realización de una serie de documentos.
En particular, quiero mencionar dos casos: Para el cambio de año 2000, en un
proyecto de una entidad financiera, se acompañó cada programa modificado con
una página de documentación que siempre decía como descripción del cambio: “Se
cambió año 2000”. Había documentación, pero no servía para nada. De igualforma, en algunos proyectos se esmeran profundamente en el mantenimiento de la
documentación, incluso de los formatos y plantillas de esta documentación. El
esfuerzo para mantener esta documentación, en algunas ocasiones, es
extremadamente alto.
Esto hace que desafortunadamente se encuentre que en algunas organizaciones
haya desconfianza ante las metodologías, como las soluciones teóricas queno son
realizables en la práctica, o como la forma de hacer las cosas de forma organizada
pero lenta.
El otro fenómeno que ocurre es el implantar la metodología como “la bala de
plata”. Generalmente, sucede cuando hay alguna persona o grupo de personas que

estudian alguna metodología en capacitaciones o por autoaprendizaje por libros, y
están convencidos que con ella ahora los proyectos...