Desarrollo de Software por Iteraciones

(3030 palabras totales en este texto)

Introduccin
Una de las prcticas que ms inquieta a los productores de software, una de las llamadas Mejores
Prcticas, es esta de las Iteraciones en un proyecto. Una Iteracin, 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 prctica ha demostrado que el producto final es de mejor calidad
que el elaborado mediante metodologas tradicionales como Cascada.
Formalmente, una Iteracin abarca el desarrollo de actividades que conducen a la liberacin de un
producto -una versin ejecutable y estable de un producto, junto con cualquier otro elemento
perifrico necesario para usar esta versin, como la documentacin respectiva, para citar un caso.
Desde este punto de vista, en una Iteracin se hace un paso completo por todas las etapas del
desarrollo de software, desde el anlisis de requisitos, hasta la programacin y, quizs, puesta en
produccin, pasando por anlisis y diseo, pruebas y control de cambios. Si se quiere es como un
proyecto pequeo realizado "en cascada.
Pero alrededor del concepto de las Iteraciones hay involucrados muchos aspectos de relevancia:
cuntas iteraciones tiene un proyecto? Cunto tarda una iteracin? Todas las iteraciones tardan lo
mismo? Qu es la Liberacin de un producto? Cmo se seleccionan los requisitos a implementar en
una iteracin? Y muchas otras.
Beneficios
Antes de tratar algunas de esas cuestiones, insistir en los motivos por los cuales debemos iterar:
Puesto que una iteracin es un proyecto pequeo 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.
Disminucin en los riesgos de un proyecto. Hablo de riesgos tecnolgicos, 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 tcnica y/o la plataforma
equivocada. Y de esto no se dan cuenta hasta que el producto (la versin a liberar en esa iteracin)
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 todava habr tiempo
(luego de buscar a los culpables y de elogiar a los no participantes!) de hacer algo. Cmo qu? Se
define otra iteracin, con otra tcnica, 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 metodolgico stakeholders), los desarrolladores; hablo
tambin del producto que se libera o entrega en cada iteracin. Cuando aquellos ven este, verifican
la funcionalidad (los casos de uso), la calidad (desempeo, seguridad, estndares, entre otros), se
forjan nuevas ideas de lo que ha sido, es y ser el producto final (por supuesto estn los "yaques -
ya que hiciste el clculo de la retefuente, por qu no generas un informe que se enve 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 iteracin, no el proyecto.
En cualquier instancia, los usuarios, sobre todo, no tienen que esperar meses o aos para ver su
producto, preguntndose todo el tiempo si estos chicos de Sistemas van a entregar y cundo y que
ser lo que estn haciendo y si habrn entendido lo que queran decir.
Hay otros beneficios tcnicos, 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 estn ampliamente
probados y documentados y se podrn usar en las iteraciones sucesivas donde seguramente sern
sometidos a incrementos graduales. Tambin se puede aprender en el camino: me refiero a que los
desarrolladores pueden no solo aprender de sus errores pasados, sino de las nuevas tcnicas a
utilizar durante la iteracin; tambin, las competencias y especialidades que se necesitan para una
iteracin especfica son mejor utilizadas, es decir, es posible emplear desarrolladores diferentes en
cada una de las iteraciones del proyecto.
Cmo 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 Especificacin 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, Descripcin General y cualquier otra
informacin que se tenga al momento de elaborar las Especificaciones.)
Con esta lista, procedemos a "calificar los casos de uso. Esta calificacin la hacemos de acuerdo al
grado de importancia y de criticidad, en cuanto a riesgo de implementacin se refiere, de cada caso
de uso.
Respecto a su importancia, un caso de uso, como veremos en un artculo prximo 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 algn 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 implementacin de estos ltimos debe hacerse siguiendo los
mismos delineamientos metodolgicos y tcnicos que los dems; el que sean Adicionales, no los
hace de menos calidad o incompletos o no sujetos al mismo proceso de pruebas que los otros.
En relacin 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
implementacin 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 travs de un sistema (porque la
legislacin o las polticas son nuevas, o porque son nuevos en la compaa, etc.) Tambin 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, estn pendientes de cmo 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
tcnicas utilizadas para llevar a cabo la implementacin. Qu se requieren Web Services, que la
plataforma .Net, que XML, que UML, que C# (lase C Sharp), que J2EE, que., en fin, un gran
universo de siglas de las que les hablar en otra ocasin. 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 prctica es fcil de programar, podra tener un alto riesgo de
implementacin debido a la poca experiencia del programador.
Y otras como Tiempo de Desarrollo, Nmero de Analistas y de Programadores, calidad de los
requisitos en cuanto a su precisin, compromiso del personal externo necesario para llevar a cabo
una implantacin (que la gente de Seguridad, que la gente de Calidad, que la gente de
Capacitacin).
Ya con los casos de uso listados y clasificados, con el tiempo lmite del proyecto en mente, con el
nmero 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 iteracin; un plan bien detallado.
Normalmente, siempre hay dos planes activos: uno para la iteracin actual y uno en construccin
para la siguiente iteracin. El plan incluye actividades de Anlisis de Requisitos, Anlisis y Diseo,
Programacin, Pruebas y Afinacin, y Puesta en Marcha; tambin, control de cambios,
documentacin y capacitacin.
Las primeras iteraciones deben planearse para implementar los casos de uso Requeridos y de
Criticidad Mxima (5). Les dejo una inquietud: existen sistemas que no tengan casos de uso de
criticidad 5?
Cuntos casos de uso por iteracin? Depende del nmero total de casos de uso y del nmero de
casos de uso Requeridos y Ms Crticos, y adems del nmero de desarrolladores dispuestos para la
implementacin. Una iteracin podra implementar solo un par de casos de uso, o 10 de ellos, o
quizs 20 o ms. En el artculo de casos de uso explorar ms este tema.
El tiempo, la duracin, de las iteraciones es otro factor importante. No est dicha la ltima palabra a
este respecto. En un proyecto pequeo (de pocos meses -dos o tres, quizs), 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 (ms de seis meses, ms de seis desarrolladores),
iteraciones de hasta seis semanas son bien vistas.
Debo anotar que esta clasificacin del tamao de los proyectos de acuerdo a la duracin y al
nmero 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 pequeo tarda un
ao y tiene 10 desarrolladores, por ejemplo.
En mi columna anterior deca que una iteracin no debera tardar ms de un mes. Este asunto de
las iteraciones de mes y medio que menciono arriba tambin 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, obtencin rpida de resultados, mitigacin de riesgos.
Ahora bien, aunque es bueno que todas las iteraciones tarden lo mismo, en la prctica 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 estn disponibles al momento de iniciar cada
iteracin y se tenga claridad sobre los requisitos que se van a implementar.
Sobre Versiones y Entregas
La Liberacin de un producto puede ser Interna o Externa. Es Interna cuando solo ser usada por
el grupo de desarrolladores durante la ejecucin 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 produccin.
Ambos tipos de entrega van acompaados de pruebas y afinacin, documentacin, capacitacin y
todos los artefactos necesarios para que el proyecto pueda seguir su marcha. Si es un entregable
externo, debe tratarse como el mismsimo producto final.
Tambin, las dos especies de producto estn sujetos a versionamiento. Sea un componente, la base
de datos o una porcin de la misma, un grupo de pginas ASP.NET o el producto de software en su
completitud, incluyendo los documentos asociados, siempre debemos conocer su versin. Les
recomiendo un versionamiento simple: Versin Mayor y Versin 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 deberamos incluir, cuando sea del caso, son las Revisiones. Estas son pequeas
modificaciones o ajustes que quizs exigieron compilar y empaquetar de nuevo el software, pero
nada ms: la documentacin es la misma, la funcionalidad no cambi, el impacto no se not. Las
cosas as, podramos tener una versin 2.5 revisin 3 o una versin 4.0 revisin 2. Por supuesto, el
nmero de revisiones es pequeo (mximo 5). De hecho, un conjunto de revisiones pequeas
quizs dan pie a una nueva versin menor (de la 2.5 a la 2.6).
Conclusin
Las Iteraciones constituyen una tcnica apropiada, una mejor prctica, para la construccin de
software. Se requieren nuevas habilidades en el manejo de proyectos, coordinacin de equipos,
documentacin de software, desarrollos en tiempos ms pequeos pero ms 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 nmero de desarrolladores, sea cual fuere su
complejidad.
Los invito entonces a que pongan en prctica este nuevo "arte de Iterar, sin importar si usan o no
una metodologa estricta como RUP o una gil. Seguramente, muy pronto vern los beneficios.
Y tambin los invito a que compartan conmigo y con todos en AAII sus comentarios acerca de este
artculo. Me pueden escribir a lsalazar@aaii.org.co o en
http://www.aaii.org.co/html/modules.php?name=Forums.
Luis Antonio Salazar Caraballo
Medelln, Octubre 15 de 2003


Nota :
Articulo Publicado Originalmente en :
http://www.aaii.org.co/html/modules.php?name=Sections&op=viewarticle&artid=30








www.WillyDev.Net