La construcción de un software es un ejercicio de trabajo y tiempo considerable, de gran complejidad incluso en sus formas más simples y que debe permanecer activo en el tiempo con una importancia cada vez más grande en la sociedad actual.
Por ello la generación de aplicaciones informáticas por la metodología de ASM (A Salto de Mata) no solamente es negativa sino que implica riesgos inasumibles para las empresas que se dedican al desarrollo. Aunque demasiadas de ellas aún no le dan la importancia que tiene.
Así, al menos desde la década de los años 70 del siglo pasado, ha ido evolucionando la idea de ALM. Que son las fases que todo proyecto deberá superar para intentar conseguir ese objetivo tan resbaladizo como es el éxito.
En esta serie que empiezo, voy a desgranar el ecosistema que tenemos en .Net para gestionar las necesidades de cualquier metodología que utilicemos para gestionar el ALM de nuestras aplicaciones, pero desde el punto de vista del desarrollador. Y con un importante componente de la filosofía Agile en los artículos.
Descripción general de ALM
Al igual que en el resto de las ingenierías, el Ciclo de Vida de una aplicación (ALM) se puede dividir a grandes rasgos en las siguientes agrupaciones:
Análisis: Se realiza la toma de requisitos que conforman las funcionalidades esperadas por los usuarios finales del sistema.
Diseño: Deducción de la arquitectura de los diferentes componentes que constituyen la aplicación. Como puede ser el esquema de datos, la capa de negocio o el interfaz de usuario. Y en donde se define el lenguaje o lenguajes de programación y las necesidades IT que requiera el software.
Codificación: Lo que hacemos todos los días. Picar el código de la aplicación y realizar su construcción.
Pruebas: Construir y ejecutar las pruebas necesarias para poder asegurar que la aplicación realiza las tareas esperadas y devuelve las respuestas correctas. En resumen, que sea de útil para sus usuarios.
Documentación: Trata sobre transmitir el conocimiento generado durante todo el Ciclo de Vida del software, a actores que no han participado en la construcción o que lo han hecho pero en otra fase o en otro momento temporal y a futuros actores que requieran del conocimiento producido. Es de señalar que esta documentación es la base de la gestión de los proyectos.
Algunos tipos de metodologías
Partiendo de estas fases tan genéricas, nos encontramos con que se han desarrollado diferentes tipos de metodologías para definir el cuándo, el cuanto y el cómo de la construcción de las aplicaciones. A continuación, voy a describir las más importantes de forma resumida.
Desarrollo en Cascada.
Como indica su nombre, las fases se van cumplimentando una detrás de otra (en algunas de las implementaciones esto no es necesariamente así) esperando el final de una para iniciar la siguiente. Es con mucho la metodología más utilizada ya que da una sensación de previsión y robustez en los resultados muy importante. Lo cual a su vez es su máxima debilidad ya que el desarrollo de software ha demostrado ser todo menos previsible. Además son muy costosos los cambios en estadios finales de la construcción.
El nexo de unión entre las fases es la documentación escrita.
Desarrollo en Espiral.
El núcleo de esta forma de construir software es el riesgo inherente que todo desarrollo implica. Dependiendo del riesgo detectado, así se define los ciclos o iteraciones de trabajo que se van a realizar. Es una metodología robusta orientada a grandes y complejos proyectos pero con una capacidad pobre de predicción.
Requiere personal expertos en gestión de riesgos.
Desarrollo iterativo y creciente.
Partiendo de la realidad de los inconvenientes de la metodología en cascada, se define este tipo de construcción en donde se parte de un implementación simple de los requerimientos del sistema para ir evolucionando iterativamente la aplicación hasta su implementación completa. Esta forma de desarrollar es tolerante a los cambios en cualquier momento del ciclo de vida pero tiene el inconveniente que es poco predictiva y puede llegar a ser confusa su gestión.
Requiere un cliente o usuario final muy comprometido y dispuesto a implicarse plenamente en tiempo y esfuerzo junto con el equipo de desarrollo.
Hay una multitud de metodologías que extraen lo que consideran lo mejor de cada una de las otras para componer formas de Ciclos de Vida más ajustados a las ideas o necesidades de los diferentes autores. Además tenemos que bajar al nivel de la implementación y entonces entramos en una miríada de acrónimos que indican los diferentes sabores que se proponen como son RUP, Scrum, XP, DSDM, RAP, Metrica 3, PMI, Prince, etc.
Me he mantenido a un nivel de ingeniería de software para que se perciba que somos una industria muy joven que aún está buscando, en sus primeros balbuceos, la forma de realizar de una forma ordenada la unión de un proceso industrial con los procesos intelectuales y artísticos que implica la programación de sistemas informáticos.
Ecosistemas
¿Pero que es un ecosistema de desarrollo de software?
Básicamente son las herramientas o conjunto de ellas que nos permiten iniciar, ejecutar, gestionar y reproducir el Ciclo de Vida del desarrollo de nuestro software.
Es decir, que al menos nos permita realizar las siguientes acciones:
-
Gestión y justificación del proyecto: Métricas, costes, planificación, riesgos, etc.
-
Herramientas de construcción del software: IDE de programación, Diseño gráfico, Framework de Pruebas, etc.
-
Almacenamiento y versionado del código.
-
Gestión documental de toda la información generada: actas, propuestas, prototipos, análisis, etc.
Es crítico en la implementación de cualquier metodología las herramientas a utilizar. Ya que es totalmente cierto que una mala herramienta destruye a la mejor metodología ya que, finalmente, quienes las usamos somos las personas.
Esto lo he vivido en mis carnes en una empresa que obtuvo el nivel 3 de CMMI con una suite de herramientas propias que implicaban una sobrecarga de trabajo a todos los actores en el ciclo de vida de las aplicaciones tal que llevo, finalmente, a una regresión. Y a una merma importante de la productividad.
El ejemplo contrario es una simple pizarra de Kanban, que es el primer interfaz con el que inicio a los nuevos equipos que vienen de trabajar en ASM puro y que dan los primeros pasos en metodologías Agiles. Y que permite comprender fácilmente conceptos como flujo de trabajo, cuellos de botella o responsabilidad colectiva.
Ecosistema TFS 2010 con Scrum 1.0
En esta serie voy a tratar sobre el ecosistema que utilizo a diario y que está comprendido en la enorme familia de productos Microsoft, con su punto de unión en el Team Foundation Server 2010, el alma del ALM. Como este producto admite prácticamente cualquier implementación, he escogido la metodología incremental con la que más a gusto me siento que es SCRUM. Específicamente la versión 1.0 para TFS 2010.
Al ser un framework de desarrollo de producto, la documentación y las métricas están orientadas a los miembros del equipo y a los actores involucrados en la aplicación a desarrollar, y así me permite mostrar la potencia del ecosistema por medio de ejemplos sencillos y de poca complejidad.
Espero que me sigas en la continuación.
Más información | Análisis, Diseño y Mantenimiento del Software (UNED), A Spiral Model of Software by Barry W. Bohem, Visual Studio Development Center
