Desarrollo de software. Ciclo de vida iterativo incremental

Este modelo de ciclo de vida es el que más de moda se encuentra de un tiempo a esta parte ya que es utilizado en diferentes metodologías relacionadas con la programación extrema y con estrategias ágiles de desarrollo de software.

El concepto es simple, el producto software se desarrolla por incrementos en el que cada iteración (incluida la primera) obtiene una versión funcional del producto, de esta forma el sistema se desarrolla poco a poco y obtiene un feedback continuo por parte del usuario.

En este modelo, en cada incremento se realizan las diferentes etapas de desarrollo de software, empezando por el análisis y terminando con la implantación y aceptación del sistema.

Tiene cierta similitud con el espiral, con la diferencia de que en este caso no se hace hincapié en el análisis de riesgos y si tomamos como referencia la variante Win & Win de Boehm, no tiene explícito el proceso de negociación bajo un prisma Ganar – Ganar entre las diferentes partes implicadas en el proyecto.

Las iteraciones no tienen por qué realizarse de manera secuencial, pudiendo haber varias ejecutándose simultáneamente siempre y cuando no existan incompatibilidades entre ellas (básicamente que se encuentren en fases distintas del proceso de desarrollo).

Este modelo de ciclo de vida es mi favorito, creo en él ya que estoy convencido que es el que más se aproxima a la realidad de un proyecto de desarrollo de software y sus contingencias. Tiene sus inconvenientes, como el hecho de que tal vez obtener una primera versión que se pueda considerar completa del producto puede tardar más en obtenerse y costar más que por ejemplo con un ciclo de vida en cascada, ya que en cada iteración se tiene en cuenta el feedback del usuario por lo que además de nuevas funcionalidades habrá modificaciones sobre lo de desarrollado en iteraciones anteriores.

No quiero decir con esto que el software necesariamente vaya a costar más de esta manera, ya que lo que hace es repercutir en el proceso de desarrollo parte del coste del mantenimiento, que recordemos que un autor como Robert Glass lo estima entre el 40 y el 80% del coste total del software.

Lo que sí se necesita son usuarios involucrados en el proyecto durante bastante tiempo y de manera constante, algo que no siempre es sencillo encontrar.

Pese a que es mi modelo favorito, sí que considero que es interesante tener una visión inicial del producto software más allá de las primeras iteraciones, ya que independientemente de que se definan una serie de metas intermedias creo que es interesante desde el inicio saber más o menos a dónde se quiere llegar.

Desarrollo de software. Ciclo de vida en espiral Win & Win

Barry Boehm, años después realizó una variante o actualización del ciclo de vida en espiral que definió en 1988.

Con la variante trata de ajustarse más a la realidad de lo que es un proyecto de desarrollo de software, en el cual el resultado final no es exactamente la implementación del catálogo de requisitos, sino que una vez definido se renegocia el alcance del mismo, incluso en diversas partes del proyecto, entre cliente y proveedor con el objetivo de intentar que ambas partes queden satisfechas (aunque en la mayoría de los casos, cada parte solo se mire su ombligo).

La variante se basa en la inclusión de tres etapas o regiones al principio:

1.- Identificar las partes interesadas (stakeholders) para esta nueva iteración del producto: Es necesario definir los interlocutores que serán de áreas que se verán afectadas por el resultado final de la nueva versión. Estos interlocutores serán del área del cliente (puede haber más de uno) y del proveedor.

2.- Identificar las condiciones de victoria de las partes interesadas en el proyecto: Se concreta cuáles son las condiciones que requiere cada parte para que se sienta satisfecha una vez realizada esta versión.

3a.- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales para la versión y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar hasta dónde realmente se va a llegar y cómo, intentando llegar a una solución en la que todos ganen (cliente y proveedor).

Las siguientes etapas tienen una correspondencia con algunas variantes, con la versión inicial del ciclo de vida en espiral:

3b.- Establecer los objetivos, restricciones y alternativas del siguiente nivel: Teniendo en cuenta los objetivos y acuerdos de las fases anteriores, se definirían los requisitos de esta versión, además de especificarse diversas alternativas en el caso de que existan.

4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos: Se realizaría el análisis del riesgo típico de los modelos en espiral.

5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completaría el proceso de análisis y realizaría el diseño y la construcción.

6.- Validar las definiciones del producto y del proceso: Comprendería la implantación y aceptación de la versión, verificándose si el resultado de la iteración satisface el alcance indicado.

7.- Revisión y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción de las partes, el nivel de cumplimiento de objetivos con el objetivo sobre todo de intentar aprender de los errores para mejorar en versiones sucesivas y de detectar correcciones y mejoras a realizar en el producto.

Desde mi punto de vista, lo más interesante del modelo es que se especifique de forma explícita la necesidad de que las partes negocien para llegar a un acuerdo satisfactorio para todos, por eso esta variante recibe el nombre de Win Win. Aunque es complicado alcanzar un equilibrio en el que ambas partes ganen a un 50%, sí que es fundamental que independientemente de si uno es un poco más ganador que el otro, todas las partes estén convencidas en que el acuerdo es bueno.

En cualquier caso sigue sin ser absolutamente realista con respecto al transcurso normal de un proyecto de desarrollo de software, donde la negociación se extiende en muchos proyectos hasta el mismo proceso de construcción del sistema de información, no obstante, si los incrementos no son muy grandes no tendría por qué extenderse tanto la negociación, no obstante, como en este tipo de modelos de ciclo de vida, en cada iteración (incluida la primera) se intenta tener un producto funcionando, salvo que éste sea trivial, las primera etapa por lo menos tendrá tamaño suficiente para que en muchos casos nos encontremos con casos donde se estén negociando aspectos del proyecto hasta el final.

Buscando respuestas

Cuántas preguntas tenemos y cuántas siguen sin respuesta, tanto de hechos pasados como presentes. La vida es así, un universo de esquinas.

Seguiremos buscando respuestas porque el ser humano es así, trata de comprender lo que no entiende, trata de entender lo que no comprende.

Muchas de nuestras respuestas están dentro de nosotros mismos pero también de nosotros nacen todas nuestras preguntas.

No todo el mundo tiene idéntica respuesta para una misma pregunta porque cada uno tiene una percepción distinta de la vida, del mundo, del universo. Precisamente esas características individuales que nos hace diferentes han sido la que ha permitido a nuestra especie evolucionar hasta lo que somos.

Respuestas diferentes no tienen por qué ser contradictorias, todo suma incluso cuando se puede estar equivocado.

Seguiremos lanzando al aire preguntas y el viento no nos traerá la respuesta, pero, ¿qué sería de la vida si realmente encontrásemos la respuesta a todo?.

Desarrollo de software. Ciclo de vida en espiral con 6 regiones

Este modelo de ciclo de vida supone una variante del que vimos en el artículo anterior que se basaba en cuatro regiones.

La diferencia principal es que se ha querido dar más relevancia a determinadas tareas asignándoles una región específica.

En este caso la división es la siguiente:

– Comunicación con el cliente: Obtención de los objetivos, requisitos y otra información de interés para esta evolución del sistema.

– Planificación: Una vez que se conoce que se conoce a dónde se pretende llegar y desde donde partimos se realiza la estimación de tiempo y recursos.

– Análisis del riesgo: Evaluación de alternativas y selección de la solución.

– Ingeniería: En función de la solución elegida. Se completa el análisis y se realiza el diseño del sistema.

– Construcción y entrega: Comprende la construcción del sistema de información, la realización de las diversas pruebas, la implantación y aceptación del sistema y actividades relacionadas con los usuarios y la puesta en marcha de aplicaciones y nuevas versiones, como por ejemplo, formación, elaboración de manuales, etc…

– Evaluación del cliente: El objetivo debe ser la satisfacción del cliente, de los usuarios. En esta etapa se recoge el feedback del usuario respecto al producto visto de una manera global (no centrándose solo en lo desarrollado en la iteración). Servirá de base para la mejora continua del proceso y del producto y sienta las bases para una posterior versión.

Conceptualmente es muy parecido al modelo original de Boehm, lo que se ha pretendido con esta variante es hacer un mayor hincapié en determinadas tareas que en el modelo original estaban englobadas en tareas de mayor peso. Por otro lado, la definición de más regiones y la división de las etapas propias del desarrollo en dos regiones, permite obtener una mayor precisión en las planificaciones y facilitar el cierre de entregables.

Desarrollo de software. Ciclo de vida en espiral

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.

Desarrollo de software. Ciclo de vida clásico o en cascada

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.

Desarrollo de software. Ciclo de vida por prototipos

Esta estrategia de desarrollo de software se basa en la construcción de un prototipo preliminar que se utilizará como apoyo para la toma de requisitos del sistema.

Para que el proyecto se mantenga dentro de los parámetros económicos y plazos establecidos, la construcción del prototipo tiene que ser rápida y en el caso de sistemas de información de gran tamaño, se debe de centrar en aquellos aspectos donde resulta más complicado obtener los requerimientos por parte del usuario y en aquellas funcionalidades que sean más críticas.

El prototipo puede ser modificado si con eso se ayuda a seguir perfilando los requisitos.

Una vez catalogados los requisitos y se tenga clara la operativa de funcionamiento de la aplicación, se iniciaría el desarrollo del sistema de información desde su fase de análisis, desechando el prototipo que quedará simplemente a modo de recordatorio, por si hay algunos aspectos que considera de interés recordar.

Este tipo de ciclo de vida tiene como principal ventaja que es más sencillo obtener las especificaciones de los usuarios si ven algo en funcionamiento (aunque no tenga todas las funcionalidades implementadas, se hayan descuidado algunos aspectos del diseño o tengan algunos errores).

También presenta varios inconvenientes:

– Se puede caer en la tentación de realizar la construcción del sistema utilizando el prototipo, realizando evoluciones sobre el mismo. Hay que tener en cuenta que si el prototipo se ha desarrollado de forma rápida, muy probablemente se hayan descuidado bastantes aspectos relacionados con la calidad del software, esto implica que el producto final heredará muy probablemente muchos de esos defectos.

– Puede crear falsas expectativas al cliente u usuario del sistema, ya que en un tiempo razonablemente corto, ven un sistema funcionando (aunque sea parcialmente y con errores) y una vez terminado el propósito de los prototipos, tardan bastante tiempo en ver una primera versión utilizable del producto.

– Si el prototipo es modificado varias veces, se incrementará el riesgo de caer en el primer inconveniente descrito o de salirse de la estimación de tiempo y esfuerzo prevista inicialmente.

Tus objetivos siempre presentes

El día a día es el principal obstáculo para conseguir nuestros objetivos. Estar apagando fuegos nos hace perder nuestra perspectiva.

Dado que es prácticamente inevitable dejar a un lado los tareas que surgen en nuestros proyectos todos los días es necesario dejar un hueco para evaluar el grado de cumplimiento de las metas que te permiten llegar a tus objetivos, así como para simplemente recordar a dónde quieres llegar.

Para conseguir los objetivos es necesario tenerlos presentes siempre, independientemente de las circunstancias laborales o personales que te ocupen en cada momento.

Cita de Zig Ziglar sobre la importancia de la actitud

Hilary Hinton «Zig» Ziglar es un conocido autor y conferenciante americano. Es autor de numerosas citas, de las cuales voy a seleccionar una de ellas:

«Es tu actitud y no tu aptitud, la que determina tu altitud».

El talento sin actitud no es nada, es como tener una importante suma de dinero en el banco y no utilizarlo. Con unos niveles de aptitud que superen el umbral a partir del cual se pueda realizar adecuadamente una actividad profesional, una buena actitud puede hacer que personas que lo mismo tienen menos talento consigan unos resultados excepcionalmente mejores que otros que tienen mejores aptitudes y además tendrán un crecimiento que les permitirá reducir las distancias con quienes ya tienen un determinado nivel de talento e incluso superarlos.

El teorema del punto gordo va en contra de la productividad

En muchas ocasiones cuando hemos señalado un punto en un mapa hemos optado por poner un punto gordo, para señalar la posición aproximada de un elemento en el mismo, es decir, hemos buscado una solución basada en la generalización que si bien puede resultar de utilidad en algunos casos, puede resultar inútil y contraproducente en otros, ya que por ejemplo, la utilidad del punto gordo se reduce en función del tamaño del mismo y de la escala en que se dibujo.

Muchos gestores utilizan esta misma estrategia para tratar a sus recursos humanos, aplican el punto gordo, generalizan y aplican una determinada política a un conjunto de personas que ni por asomo han tenido un comportamiento similar en términos de productividad y resultados.

¿Qué circunstancias les hace aplicar el teorema del punto gordo? Principalmente el desconocimiento real de lo que hace cada cada persona y porque para ellos es lo más fácil, ya que creen que es justo tratar a todo el mundo por igual y eso lo es en algunos aspectos, pero no lo es en muchos otros.

Si te esfuerzas en el trabajo, aplicas estrategias para intentar se lo más productivo posible, obtienes resultados y sin embargo te tratan igual (o peor) que otros que no tienen ni tu compromiso, ni tu dedicación, ni tus logros, terminas tarde o temprano por desmoronarte y tiene consecuencias en tu trabajo (te cansas de hacer el canelo y se reduce tu productividad o directamente buscas otros horizontes profesionales) y/o en en ti mismo (aguantas tu nivel en el trabajo, a cambio de tener al angelito malo recordándote todos los días, ¿por qué narices te implicas si tu organización no lo hace contigo?).

Políticas generalistas van en contra de lo productividad y sin embargo son las más extendidas. Así nos va.