| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Modelos de desarrollo iterativos"
Uno de los factores más importantes para el éxito de un proyecto de software es realizar una correcta gestión del proyecto. Este artículo explica los diferentes modelos de desarrollo que pueden aplicarse para esta gestión y explica sus ventajas e inconvenientes.
Artículo "Modelos de desarrollo iterativos" (continuación)
2.PROYECTOS CON MODELO DE DESARROLLO EN CASCADA. Si la empresa realmente aplica un modelo de desarrollo, es probable que utilice un modelo en cascada (waterfall model), ya que éste ha sido el modelo de desarrollo dominante en el área informática durante muchos años. La figura 1 muestra un esquema simplificado de este modelo. Para los no versados en Ingeniería del Software, diremos que el análisis (más propiamente, “análisis de requerimientos”) es una descripción de lo que debe hacer el sistema, el diseño son los “planos” del sistema y la programación es el proceso de construir el sistema acabado. Una vez realizada la programación, es necesario probar el programa para detectar los posibles errores y corregirlos, etapa que se denomina con el nombre de “Pruebas”. Figura 1. El modelo de desarrollo en cascada En un modelo en cascada, primero se realiza el análisis. Cuando se tiene un análisis acabado se comienza a desarrollar el diseño. Cuando el diseño está acabado, se lleva a cabo la programación. Cuando la programación está acabada se realizan las pruebas. A primera vista, este orden parece lógico, pues el diseño se basa en el análisis, de la misma manera que la programación se basa en el diseño y las pruebas en la programación. Además, esto es análogo a lo que sucede en las otras ingenierías. Usando la analogía anterior, es evidente que no se empieza a construir un edificio hasta que los planos estén totalmente acabados. Sin embargo, como hemos dicho, los programas informáticos son mucho más complejos y abstractos que un edificio o que cualquier producto resultante de otra ingeniería. Es por esto que este modelo no se adecua bien al desarrollo de sistemas. Sus principales defectos son los siguientes: Rigidez y poca adaptabilidad. En un mundo perfecto, los clientes y los desarrolladores tendrían claros los requerimientos (lo que debe hacer el sistema) desde un principio y estos requerimientos no cambiarían durante el proceso de desarrollo. Sin embargo, la realidad es que los requerimientos cambian constantemente, bien porque el cliente se da cuenta de necesidades que ignoraba, bien porque el mercado o la tecnología evolucionan o bien porque los desarrolladores se dan cuenta de requisitos técnicos que no habían previsto en un principio. Un estudio realizado ([2]) revela que los requerimientos no anticipados en el comienzo del proyecto pueden suponer un 25% del total para proyectos de desarrollo medios y hasta un 50% para proyectos grandes (similares resultados se presentan en el artículo [3]). El modelo en cascada no permite acomodar estos cambios, ya que los requerimientos quedan fijados desde el comienzo, no pudiendo ser modificados con posterioridad. Baja mitigación de riesgos. Con el modelo en cascada no ess hasta el final del proyecto cuando se pueden hacer pruebas y determinar la viabilidad o eficiencia de nuestra arquitectura. Así, los elementos más riesgosos (como la viabilidad de la arquitectura del sistema) se determinan al término del proceso de desarrollo, cuando es más difícil y costoso modificarlos, además de que se ha perdido valioso tiempo y recursos diseñando una arquitectura que al final se revela como no viable. Falta de retroalimentación. Es bien conocido que, la mayoría de las veces, el cliente comienza con una idea aproximada y vaga de lo que quiere y, sólo cuando ve el programa funcionando, comienza a comprender en detalle lo que realmente necesita. Sin embargo, en el modelo en cascada, sólo se tiene un ejecutable del sistema hasta el final del proyecto. En este punto, los cambios son caros o poco posibles ya que la estructura del sistema está firmemente establecida. Como consecuencia, el modelo de desarrollo en cascada es demasiado rígido para un proceso tan dinámico como es el desarrollo de software. Es por eso que adoptarlo es contraproducente para la correcta ejecución del proyecto de software. De hecho, en un estudio de dos años sobre proyectos de desarrollo exitosos que se publicó en [4], se determinó que el primer factor de éxito para un proyecto de desarrollo es adoptar un modelo de desarrollo diferente del modelo en cascada.
Ir a la página: 1 2 3 4 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |