Buscar en Gazafatonario IT

lunes, febrero 14, 2005

Desarrollo de Software por Iteraciones

Introducción
Una de las prácticas que más inquieta a los productores de software, una de las llamadas Mejores Prácticas, es esta de las Iteraciones en un proyecto. Una Iteración, para empezar, puede ser vista como un mini-proyecto, sin que el prefijo “mini” quiera decir que el proyecto está inconcluso o es de mala calidad, No. De hecho, esta práctica ha demostrado que el producto final es de mejor calidad que el elaborado mediante metodologías tradicionales como Cascada.
Formalmente, una Iteración abarca el desarrollo de actividades que conducen a la liberación de un producto –una versión ejecutable y estable de un producto, junto con cualquier otro elemento periférico necesario para usar esta versión, como la documentación respectiva, para citar un caso. Desde este punto de vista, en una Iteración se hace un paso completo por todas las etapas del desarrollo de software, desde el análisis de requisitos, hasta la programación y, quizás, puesta en producción, pasando por análisis y diseño, pruebas y control de cambios. Si se quiere es como un proyecto pequeño realizado “en cascada”.
Pero alrededor del concepto de las Iteraciones hay involucrados muchos aspectos de relevancia: cuántas iteraciones tiene un proyecto? Cuánto tarda una iteración? Todas las iteraciones tardan lo mismo? Qué es la Liberación de un producto? Cómo se seleccionan los requisitos a implementar en una iteración? Y muchas otras.
Beneficios
Antes de tratar algunas de esas cuestiones, insistiré en los motivos por los cuales debemos iterar:
Ø Puesto que una iteración es un proyecto pequeño completo, hay un mejor control de los recursos, el talento humano asignado al proyecto, la calidad del producto implantado y los cambios en requisitos que se puedan producir durante el tiempo total del proyecto.
Ø Disminución en los riesgos de un proyecto. Hablo de riesgos tecnológicos, de riesgos administrativos y hasta del entorno. Por ejemplo, es posible que para implementar un requisito, o un conjunto de ellos, un equipo seleccione las herramientas y/o la técnica y/o la plataforma equivocada. Y de esto no se dan cuenta hasta que el producto (la versión a liberar en esa iteración) no está listo o casi listo. Por ejemplo, los tiempos de respuesta no son adecuados, la seguridad de los datos no se puede garantizar, el manejo de concurrencia no es aceptable, entre muchos otros aspectos. En un proyecto tradicional, estos hechos solo se ven al final del mismo, cuando ya no hay tiempo de hacer correcciones, de buscar alternativas, cuando se perdió la oportunidad (el costo de oportunidad), etc. Sin embargo, en un proyecto iterativo, muy probablemente todavía habrá tiempo (luego de buscar a los culpables y de elogiar a los no participantes!) de hacer algo. Cómo qué? Se define otra iteración, con otra técnica, con otras herramientas, con otra plataforma, lo que sea necesario, para asegurar que esta vez el requisito sí va a ser bien implantado.
Ø Las iteraciones relajan los nervios. Hablo de las expectativas que tienen los usuarios, los patrocinadores (llamados en lenguaje metodológico stakeholders), los desarrolladores; hablo también del producto que se libera o entrega en cada iteración. Cuando aquellos ven este, verifican la funcionalidad (los casos de uso), la calidad (desempeño, seguridad, estándares, entre otros), se forjan nuevas ideas de lo que ha sido, es y será el producto final (por supuesto están los “yaques” –ya que hiciste el cálculo de la retefuente, por qué no generas un informe que se envíe por Mail en formato Excel al gobierno?) En mi caso, validan la capacidad (de respuesta) del proveedor, comprueban que obtuvieron lo que compraron y los usuarios comienzan a hablar de las siguientes fases del proyecto, sin haber terminado esta. Recuerden, se terminó una iteración, no el proyecto. En cualquier instancia, los usuarios, sobre todo, no tienen que esperar meses o años para ver su producto, preguntándose todo el tiempo si estos chicos de Sistemas van a entregar y cuándo y que será lo que están haciendo y si habrán entendido lo que querían decir.
Ø Hay otros beneficios técnicos, como que la reusabilidad se facilita y se mejora. Esto es claro, porque una vez terminado un producto, o parte de el, sus componentes ya están ampliamente probados y documentados y se podrán usar en las iteraciones sucesivas donde seguramente serán sometidos a incrementos graduales. También se puede aprender en el camino: me refiero a que los desarrolladores pueden no solo aprender de sus errores pasados, sino de las nuevas técnicas a utilizar durante la iteración; también, las competencias y especialidades que se necesitan para una iteración específica son mejor utilizadas, es decir, es posible emplear desarrolladores diferentes en cada una de las iteraciones del proyecto.
Cómo Iterar
Ahora sí, trataré de resolver algunos de los temas que planteé antes.
Ya sabemos que el desarrollo de un proyecto debe hacerse teniendo como punto de partida y como conductor los casos de uso. Una vez que hayamos elaborado el documento de Especificación de Requisitos (Funcionales y No Funcionales), se escriben las descripciones de todos los casos de uso del sistema (hablo de Nombre del Caso de Uso, Actor, Descripción General y cualquier otra información que se tenga al momento de elaborar las Especificaciones.)
Con esta lista, procedemos a “calificar” los casos de uso. Esta calificación la hacemos de acuerdo al grado de importancia y de criticidad, en cuanto a riesgo de implementación se refiere, de cada caso de uso.
Respecto a su importancia, un caso de uso, como veremos en un artículo próximo sobre el tema, puede clasificarse en: Requerido, Importante o Adicional. Los primeros son aquellos sin los cuales el sistema no puede funcionar. Los casos de uso Importantes son aquellos sin los cuales el sistema puede funcionar, al menos, durante algún tiempo, pero que debemos implementar tan pronto como sea posible. Mientras tanto, los casos de uso Adicionales son aquellos no obligatorios para el sistema (los “yaques” que mencionaba antes), los Buenos, Bonitos y Baratos, como decimos popularmente. Por supuesto, la implementación de estos últimos debe hacerse siguiendo los mismos delineamientos metodológicos y técnicos que los demás; el que sean Adicionales, no los hace de menos calidad o incompletos o no sujetos al mismo proceso de pruebas que los otros.
En relación a su Criticidad, los casos de uso se califican de 1 a 5, por ejemplo, donde 1 es de menor riesgo, 3 es de riesgo aceptable y 5 es de riesgo muy alto. Este riesgo se refiere a la implementación del caso de uso y se debe medir a la luz de varios criterios:
Ø Conocimiento del tema (del negocio) por parte de los usuarios y de los desarrolladores. Hay usuarios que desconocen parte de lo que quieren resolver a través de un sistema (porque la legislación o las políticas son nuevas, o porque son nuevos en la compañía, etc.) También hay desarrolladores que creyeron entender algo del usuario pero no fue así, sobre todo los noveles que, al momento de una entrevista con el usuario, están pendientes de cómo resolver el problema y no de escuchar y comprender todo lo que les quisieron decir.
Ø Habilidad y/o experiencia de los desarrolladores en el uso de la plataforma, herramientas y técnicas utilizadas para llevar a cabo la implementación. Qué se requieren Web Services, que la plataforma .Net, que XML, que UML, que C# (léase C Sharp), que J2EE, que…, en fin, un gran universo de siglas de las que les hablaré en otra ocasión. En todo caso, estos son apenas los medios, algo en lo que se supone somos especialistas, sin embargo, algunas veces no es así. Visto así, un caso de uso que en la práctica es fácil de programar, podría tener un alto riesgo de implementación debido a la poca experiencia del programador.
Ø Y otras como Tiempo de Desarrollo, Número de Analistas y de Programadores, calidad de los requisitos en cuanto a su precisión, compromiso del personal externo necesario para llevar a cabo una implantación (que la gente de Seguridad, que la gente de Calidad, que la gente de Capacitación).
Ya con los casos de uso listados y clasificados, con el tiempo límite del proyecto en mente, con el número de desarrolladores establecido, podemos hacer un Plan de Iteraciones. Este es un conjunto de actividades y tareas secuenciadas en el tiempo, con talento humano asignado y con el conocimiento de las dependencias entre tareas, para cada iteración; un plan bien detallado. Normalmente, siempre hay dos planes activos: uno para la iteración actual y uno en construcción para la siguiente iteración. El plan incluye actividades de Análisis de Requisitos, Análisis y Diseño, Programación, Pruebas y Afinación, y Puesta en Marcha; también, control de cambios, documentación y capacitación.
Las primeras iteraciones deben planearse para implementar los casos de uso Requeridos y de Criticidad Máxima (5). Les dejo una inquietud: existen sistemas que no tengan casos de uso de criticidad 5?
Cuántos casos de uso por iteración? Depende del número total de casos de uso y del número de casos de uso Requeridos y Más Críticos, y además del número de desarrolladores dispuestos para la implementación. Una iteración podría implementar solo un par de casos de uso, o 10 de ellos, o quizás 20 o más. En el artículo de casos de uso exploraré más este tema.
El tiempo, la duración, de las iteraciones es otro factor importante. No está dicha la última palabra a este respecto. En un proyecto pequeño (de pocos meses –dos o tres, quizás), con pocos desarrolladores (dos o tres tal vez–o hasta uno), iteraciones de dos semanas son aceptables. En un proyecto mediano (seis meses, hasta cinco desarrolladores), iteraciones de tres o cuatro semanas son bienvenidas. En un proyecto grande (más de seis meses, más de seis desarrolladores), iteraciones de hasta seis semanas son bien vistas.
Debo anotar que esta clasificación del tamaño de los proyectos de acuerdo a la duración y al número de desarrolladores es un poco arbitraria, soportada en la trayectoria de quien les escribe y de algunos colegas con quienes he discutido el tema. Hablo de nuestro medio. La literatura que nos llega de otras latitudes se refiere a algo totalmente distinto, donde un proyecto pequeño tarda un año y tiene 10 desarrolladores, por ejemplo.
En mi columna anterior decía que una iteración no debería tardar más de un mes. Este asunto de las iteraciones de mes y medio que menciono arriba también es viable si se tiene un buen control del proyecto. Recuerden que este es uno de los grandes beneficios del desarrollo iterativo, el control del proyecto, obtención rápida de resultados, mitigación de riesgos.
Ahora bien, aunque es bueno que todas las iteraciones tarden lo mismo, en la práctica es posible que esto no se dé. Hay iteraciones que por su simplicidad pueden tardar dos semanas, otras pueden tardar cuatro. Lo importante es que los recursos estén disponibles al momento de iniciar cada iteración y se tenga claridad sobre los requisitos que se van a implementar.
Sobre Versiones y Entregas
La Liberación de un producto puede ser Interna o Externa. Es Interna cuando solo será usada por el grupo de desarrolladores durante la ejecución de otras iteraciones en las que se completará un producto propiamente dicho. Y es Externa cuando se trata de un producto de software completo, funcional, que se puede poner en producción.
Ambos tipos de entrega van acompañados de pruebas y afinación, documentación, capacitación y todos los artefactos necesarios para que el proyecto pueda seguir su marcha. Si es un entregable externo, debe tratarse como el mismísimo producto final.
También, las dos especies de producto están sujetos a versionamiento. Sea un componente, la base de datos o una porción de la misma, un grupo de páginas ASP.NET o el producto de software en su completitud, incluyendo los documentos asociados, siempre debemos conocer su versión. Les recomiendo un versionamiento simple: Versión Mayor y Versión Menor; por ejemplo: 1.1, 2.5, 4.0. Creo que no es necesario utilizar las convenciones de las grandes casas productoras (que 8.04.003.185 Build 4321 o cosas así.)
Lo que sí deberíamos incluir, cuando sea del caso, son las Revisiones. Estas son pequeñas modificaciones o ajustes que quizás exigieron compilar y empaquetar de nuevo el software, pero nada más: la documentación es la misma, la funcionalidad no cambió, el impacto no se notó. Las cosas así, podríamos tener una versión 2.5 revisión 3 o una versión 4.0 revisión 2. Por supuesto, el número de revisiones es pequeño (máximo 5). De hecho, un conjunto de revisiones pequeñas quizás dan pie a una nueva versión menor (de la 2.5 a la 2.6).
Conclusión
Las Iteraciones constituyen una técnica apropiada, una mejor práctica, para la construcción de software. Se requieren nuevas habilidades en el manejo de proyectos, coordinación de equipos, documentación de software, desarrollos en tiempos más pequeños pero más especializados, equipos multidisciplinarios y compromiso de parte de todos los involucrados en el proyecto. Pero funciona, sin duda, en cualquier tipo de proyecto, con cualquier número de desarrolladores, sea cual fuere su complejidad.
Los invito entonces a que pongan en práctica este nuevo “arte” de Iterar, sin importar si usan o no una metodología estricta como RUP o una ágil. Seguramente, muy pronto verán los beneficios.
Y también los invito a que compartan conmigo y con todos en AAII sus comentarios acerca de este artículo. Me pueden escribir a lucho.salazar@gmail.com.
Luis Antonio Salazar Caraballo
Medellín, Octubre 15 de 2003

5 comentarios:

  1. Muy bueno el documento. He aprendido algo más, seguiré leyendo las otras entradas.

    ResponderBorrar
  2. Este comentario ha sido eliminado por el autor.

    ResponderBorrar
  3. Miguel, gracias por el comentario. Sobre iteraciones te recomiendo mi artículo Gerencia de Proyectos Iterativos: De cómo el software se puede construir por incrementos.
    Lo encuentras en la revista Project Management Iberoamericano de la Asociación Española de Profesionales en Dirección de Proyectos.
    Lo encuentras en:
    http://issuu.com/aepdp/docs/revista_aepdp_iv_-marzo_2012/35?zoomed=&zoomPercent=&zoomX=&zoomY=&noteText=&noteX=&noteY=&viewMode=magazine&goback=%2Egmr_3123613%2Eanp_3123613_1347191489551_1%2Egde_3123613_member_102951341

    O en:

    http://aepdp.es/project-management-iberoamericano

    ResponderBorrar
  4. Cuando es un proyecto grande, que esta compuesto por módulos ejemplo un sistema administrativo financiero, se puede realizar el proceso del RUP por cada modulo? que sugiere en su experiencia?

    ResponderBorrar
    Respuestas
    1. Lo que hacíamos era usar RUP para todo el proyecto, no para cada módulo. Sin embargo, hoy día usamos enfoque ágil, pensamiento Lean para hacer este tipo de cosas y acudimos a marcos de trabajo como Scrum y muchas otras prácticas ágiles para hacerlo.Te recomiendo estos artículos más recientes:
      http://www.gazafatonarioit.com/2014/11/agil-necesita-ser-tanto-iterativo-como.html (traducción de un artículo de Mike Cohn)
      https://www.linkedin.com/pulse/iterativo-e-incremental-luis-antonio-salazar-caraballo/, en donde pongo de manifiesto mi enfoque Iterativo e Incremental y de Valor.

      Borrar