archivo

Archivos diarios: marzo 27, 2011

También recibe el nombre de ciclo de vida de Boehm (Barry Boehm describió este modelo en 1988). Este modelo es de carácter evolutivo, de manera que la versión final del producto se obtiene mediante la realización de diversas iteraciones y tiene como principal característica la realización de un análisis de riesgos en cada iteración (estudio de alternativas de solución y selección de aquella que más convenga al proyecto).

Cada iteración se divide en cuatro fases:

– Definición de objetivos: Especificación del alcance del producto que se obtendrá al final de la iteración (catálogo de objetivos y requisitos), se identificarán riesgos y se determinarán posibles alternativas de solución.

– Análisis del riesgo.

– Desarrollar y probar: Comprende las actividades de análisis, diseño, construcción e implantación de la versión del producto.

– Planificación: Se realiza una estudio de la situación actual del sistema y del proyecto, se determina la necesidad o no de una nueva evolución y en el caso de que sea necesaria se realiza la planificación de la misma.

La principal crítica que tiene este modelo es que es tan ideal que es complicado de llevar a cabo. Se considera costoso, ya que su enfoque se basa en construir el sistema poco a poco y además en cada evolución no solo se tienen en cuenta evoluciones propias de un incremento del producto sino evoluciones y correcciones resultado del trabajo con los usuarios con la sección del producto que está en producción.

Por otro lado, en muchos casos se considera complicado la realización del análisis de riesgos, ya que en función del sistema de información resulta muy complejo definir alternativas de solución y determinar con claridad cuál de ellas es la más apropiada (además, introduce un overhead en el proyecto, que tiene consecuencias tanto en el esfuerzo necesario para realizar el proyecto y el tiempo necesario para liberar cada versión).

Todas estas iteraciones y el conjunto de actividades que hay que realizar en las mismas, hace que el tiempo necesario para obtener una versión “final” del producto sea superior que al de otros ciclos de vida (el sistema se obtiene poco a poco y con mucho cuidado).

Es complicado realizar una planificación global del proyecto, ya que eso dependerá de cómo evolucione el proyecto, producto y usuarios en las distintas iteraciones. Se puede establecer una planificación inicial, con una serie de evoluciones, pero existe una cierta incertidumbre en cuanto hasta dónde se podrá llegar con el presupuesto inicial.

Su principal ventaja es que reduce el tiempo en que el usuario puede tener una versión usable del producto (aunque con funcionalidades limitadas) y se acerca más a la realidad de lo que es un proyecto de desarrollo de software en la realidad y su mantenimiento.

Este enfoque del desarrollo de software ha sido el más utilizado y en la actualidad, pese a la aparición de metodologías ágiles, sigue siendo la solución predominante, si bien, en cada organización o en cada de proyecto se puede llevar a cabo con ciertas variantes.

Además, en función del autor, las fases en que se divide el ciclo de vida clásico, pueden ser diferentes. Para este artículo voy a utilizar las que estableció Roger Pressman (no obstante para la descripción del alcance de las mismas voy a basarme principalmente en Métrica V.3, pero adaptándome a esta clasificación), si bien otras muchas alternativas podrían ser válidas:

– Análisis: Esta fase comprendería desde la posible obtención de unos objetivos o requisitos iniciales para determinar la viabilidad del sistema y escrutar las distintas alternativas de solución, pasando por la elaboración del catálogo de requisitos, hasta la realización de casos de uso, prototipado de pantallas e informes, como una primera especificación del plan de pruebas.

– Diseño: El análisis describe el sistema sin entrar en características propias de la implementación, es en esta fase donde se adapta ese análisis generalista a la solución concreta que se quiere llevar a cabo, definiéndose la arquitectura general del sistema de información, su división en subsistemas de diseño, el modelo de datos lógico, el modelo de clases (en el caso de un diseño orientado a objetos), la especificación detallada del plan de pruebas, etc…

– Codificación: En esta fase se realiza la construcción del sistema de información y las pruebas relacionadas con dicho proceso, como son las unitarias, integración y de sistema, así como otras actividades propias de las etapas finales de un desarrollo como es la realización de la carga inicial de datos (si bien en muchos casos se deja esto para cuando el producto está en producción) y/o la construcción del procedimiento de migración.

– Pruebas: En esta etapa se realizaría la instalación del sistema en un entorno de pruebas lo más parecido posible al de producción (entorno de preproducción) donde se realizarían las pruebas de implantación (que verifican principalmente aspectos no funcionales) y las de aceptación, donde los usuarios validan que el sistema hace lo que realmente esperaban (sin que se deba olvidar que los límites los establecen los modelos realizados previamente y que han debido ser validados). Por último se realizaría la implantación del sistema en el entorno de producción.

– Mantenimiento: Una vez que el sistema se encuentra en producción, se realizarán sobre el mismo diversas tareas de mantenimiento, que en función de su naturaleza se clasifican en correctivos, evolutivos, adaptativos y perfectivos. Estas tareas de mantenimiento serán consecuencia de incidencias y peticiones reportadas por los usuarios y los directores usuarios.

En el ciclo de vida clásico en función de las modificaciones y/o correcciones que se realizan en una etapa será necesario la vuelta a fases previas para hacer coherente el proceso de desarrollo y los modelos.

El principal inconveniente que se le ha achacado siempre a este tipo de ciclo de vida es que los usuarios tardan demasiado en ver los resultados, lo que hace que el tiempo transcurrido desde que se define el sistema hasta que está disponible sea lo suficientemente amplio como para que hayan ocurrido muchas cosas: desde que no estén la mayoría de las personas que participaron en la especificación, como cambios en los procesos, cambios de criterio, etc…, lo que provoca a hacer replantemiento de los requisitos en etapas más tardías del desarrollo con el coste que eso conlleva (un refinamiento de los requisitos es razonable siempre y cuando no se superen unos límites) y a que muy probablemente el sistema finalmente disponible esté alejado de lo que realmente quiere el conjunto de usuarios en estos momentos que es distinto a lo que querían hace meses y a lo que querrán dentro de otros tantos.

Otro inconveniente ligado con el anterior es que al tratarse el sistema como un todo, los modelos generados (catálogo de requisitos, casos de uso, etc…) serán lo suficientemente grandes como para no poder ser revisados y comprendidos en toda su magnitud, sobre todo por personal no informático. Esto crea una incertidumbre sobre los requisitos del sistema que más adelante traerá problemas.

No todo es malo en este modelo, ya que describe un procedimiento racional y ordenado de desarrollo de software, la clave para su éxito o su fracaso es como se gobierne el mismo y las circunstancias que rodeen al proyecto en el momento de su ejecución. Además, existen variantes que ofrecen una mayor flexibilidad al mismo y que permite reducir sus riesgos.