¿EN QUÉ CONSISTE EL MODELO DE ENTREGA POR ETAPAS?

    Es un modelo de ciclo de vida en el que el software se muestra al cliente en etapas refinadas sucesivamente. La entrega por etapas es un modelo de ciclo de vida en e que el software se desarrolla por etapas, desarrollando normalmente primero las capacidades más importantes.
La entrega por etapas no reduce el tiempo necesario para construir un producto de software, pero reduce sustancialmente los riesgos implícitos en su construcción, y también proporciona signos tangibles de progreso que son visibles para el cliente y útiles para la directiva en la evaluación del estado del proyecto.

    La entrega por etapas es un modelo de ciclo de vida en donde el software se desarrolla en etapas sucesivas, y bien se muestra al cliente o se entrega al final de cada etapa.
    La entrega por etapas se pasa por los pasos de definición del concepto del software, análisis de requerimientos y creación del diseño de la arquitectura del modelo en cascada. Luego se procede a hacer el diseño detallado, codificación, depuración y prueba con cada etapa, creando un producto para entregar al final de cada etapa.
La entrega por etapas mejora  más la planificación percibida que la planificación real.
 

A continuación se presenta el modelo de ciclo de vida de entrega por etapas. La entrega por etapas permite entregar un producto en etapas, tras desarrollar inicialmente los requerimientos y el diseño de la arquitectura de forma tradicional.
 
 

    La entrega por etapas también contribuye mucho a eliminar el tiempo administrativo empleado por los desarrolladores en crear informes sobre el progreso y otros informes de seguimiento tradicionales.

   La entrega por etapas evita el problema de la mala estimación entregando pronto y frecuentemente. En vez de hacer una gran estimación para el proyecto completo, es posible hacer varias estimaciones pequeñas para muchas entregas más pequeñas.

  Un riego común en los proyectos software consiste en la dificultad de integrar componentes que se desarrollaron por separado.  Cuando se entrega el software pronto y frecuentemente, como se hace por entrega por etapas, la integración también debe realizarse pronto y frecuentemente. Esto minimiza los posibles problemas de integración.
 
 

USO DE LA ENTREGA POR ETAPAS

    En la entrega por etapas, se comienza con una idea clara del producto que finalmente se entregará. Al seguir un modelo de ciclo de vida en cascada, no es necesario comenzar a planificar su uso hasta después de que se haya finalizado el análisis de requerimientos y el diseño de la arquitectura.
Una vez finalizado el diseño de la arquitectura, para utilizar la entrega por etapas se debe planificar una serie de entregas. Dentro de cada etapa se realiza un ciclo completo de diseño detallado, construcción y prueba, y al final de cada etapa se entrega un producto funcionando.

    La planificación de la primera entrega es única en el sentido de que necesita incluir algunas ideas globales de la arquitectura. Las entregas siguientes añaden más posibilidades, de una forma planificada con mucho cuidado. El producto final se entrega en la última etapa.

    Para utilizar el método de la entrega por etapas, no se tiene que entregar cada versión al cliente, y se puede implementarla en un nivel de responsabilidad técnica. Se podría utilizar la entrega por etapas como una ayuda para seguir el proceso, coordinar los cambios para asegurar la calidad, o reducir el riesgo de problemas de integración.
 

  Dependencias Técnicas.

En una sola entrega larga, el orden de la entrega de los componentes no importa mucho. Muchas entregas pequeñas de un producto requieren mayor planificación que una única entrega grande, y tiene que asegurarse de que no ha pasado por alto ninguna dependencia técnica de la planificación.
 

  Trabajo centrado del desarrollador.
    La entrega por etapas requiere que cada desarrollador cumpla la fecha de entrega para cada etapa. Si un desarrollador se pasa de una fecha de entrega, la entrega completa puede retrasarse. Es necesario asegurarse de que los desarrolladores han asumido el plan de entrega y se comprometen a trabajar de acuerdo con él. La mejor forma de asegurar el compromiso del desarrollador es implicar íntimamente a los desarrolladores en la creación del plan.
 

  Entrega por temas.
    Una buena forma de definir las etapas consiste en utilizar temas para cada entrega incremental. La definición de entregas puede provocar negociaciones a prestación por prestación, que pueden llevar mucho tiempo. El uso de temas eleva esas negociaciones a un nivel superior. Estos temas facilitan la decisión sobre las entregas en que se incorpora una característica en particular.
    Cuando se utilicen temas, se debe planificar el dar prioridad a los temas por orden de importancia y luego se deben entregar los temas en orden de prioridad.
 

  Tipos de proyectos.
    La entrega por etapas funciona mejor para los sistemas que se conocen bien. Es necesario conocer el producto lo suficientemente bien para planificar las etapas cuando se termine el diseño de la arquitectura.
    La entrega por etapas es también un método apropiado para proyectos muy grandes. planificar una serie de cuatro proyectos de 9  meses es considerablemente menos arriesgado que planificar un único proyecto de 3 años.
    La entrega por etapas sólo funciona bien en sistemas en los que se puede desarrollar independientemente subconjuntos útiles del producto.
    Algunos tipos de sistemas incorporados, y otros tipos de productos podrían no ser utilizables sin una funcionalidad completa o casi completa; para esos tipos de sistemas, la entrega por etapas no es apropiada.
 
 
 

GESTION DE LOS RIESGOS DE LA ENTREGA POR ETAPAS.

    El mayor riesgo asociado a la entrega por etapas es el riesgo de cambio de prestaciones. Cuando los clientes comienzan a utilizar la primera entrega del producto, probablemente van a querer cambiar lo que han planificado para las demás entregas.
    La mejor forma de gestionar este riego es no utilizar la entrega por etapas si no se está seguro de las prestaciones que se necesitan desarrollar. La entrega por etapas funciona mejor cuando se tiene un consenso amplio y profundo sobre lo que debe incluir el producto.
    Si se decide utilizar la entrega por etapas, es posible reservar tiempo en la planificación para acomodar las prestaciones desconocidas. Se podría definir la última etapa como la etapa para hacer cambios de última hora.
 

EFECTOS SECUNDARIOS DE LA ENTREGA POR ETAPAS.
 

    Además de su efecto positivo en la planificación de proyectos, la entrega por etapas puede beneficiar muchas otras características del proyecto.
 

  Distribución más uniforme de los recursos de desarrollo y prueba.
    Los proyectos que utilizan la entrega por etapas constan de varios mini-ciclos de planificación, análisis de requerimientos, diseño, codificación y prueba.

  Mejora de la calidad del código.
    En los enfoques tradicionales se sabe que "alguien" tendrá que leer el código y mantenerlo. Con la entrega por etapas, se sabe que se necesitará leer y modifcar el código muchas veces. Esto proporciona  una motivación concreta para escribir un buen código, lo cual es un incentivo más fuerte.

  Mayor probabilidad de terminar el proyecto.
    Un proyecto de entrega por etapas no se abandonará tan fácilmente como un proyecto con el modelo en cascada.

  Apoyo para trabajar ajustándose a un presupuesto.
    La premisa de la entrega por etapas es que hay que entregar algo útil tan pronto como sea posible. Al final de cada estado el analista y sus clientes pueden examinar el presupuesto y determinar si se puede afrontar  el siguiente estado. Si el dinero se acaba al llegar al 90 por 100, los clientes estarán más felicen con un producto funcionando en su mayor parte que si se hubiera utilizado el modelo de ciclo de vida en cascada pura ( y "90 por 100  terminado" significara "0 por 100 operativo").
 
 

INTERACCIONES DE LA ENTREGA POR ETAPAS CON OTROS MÉTODOS.

    La entrega por etapas no es una forma de prototipado. El prototipado es exploratorio, y la entrega por etapas no. Su objetivo es hacer visible el progreso, o poner software útil en manos de los clientes con más rapidez. A diferencia del prototipado, se conoce el resultado final cuando se comienza el proceso.
    Si el método de entrega por etapas le proporciona al analista menos flexibilidad de la que necesita, probablemente pueda utilizan en su lugar la entrega evolutiva o el prototipado evolutivo.
    Si el analista conoce la naturaleza general del sistema que se está construyendo, pero aún tiene dudas sobre algunos aspectos significativos, no se debe utilizar la entrega por etapas.
    El éxito del desarrollo de un conjunto de entregas por etapas depende del diseño de una familia de programs. Cuanto más se siga este método de diseño, se podrá evitar mejor el desastre si los requerimientos resultan menos estables de lo que se pensaba.
 
 

PUNTOS CRUCIALES DE LA ENTREGA POR ETAPAS.

    La base del funcinameinto de la entrega por etapas es que, aunque no reduce el tiempo de desarrollo necesario para construir un producto software, reduce el riesgo que conlleva la construcción de un producto, y proporciona señales tangibles de progreso, que pueden ser tan importantes para el desarrollo rápido como lo es el propio tiempo de desarrollo.
 
 

          

                                                             Inicio        Página Siguiente

---