archivo

Archivo de la etiqueta: CASE

Los requisitos funcionales y no funcionales de un sistema de información determinan el mapa inicial de lo que los usuarios esperan del sistema. Se trata de una predicción sobre lo que que quieren y que después tendrán que constrastar con el producto final.

Lo normal es que exista una diferencia entre una versión de un producto y lo que se esperaba de ella, por lo que después son necesarios mecanismos de ajustes que disminuyan esa distancia a unos umbrales razonables o que la eliminen. Lo ideal es que esa diferencia sea la menor posible y los analistas funcionales y orgánicos y los responsables de codificar el proyecto intenten que así sea, sin embargo los proyectos de desarrollo de software están sometidos a muchos factores que afectan negativamente a ese objetivo.

En cualquier caso, los requisitos representan necesidades y expectativas de los usuarios y es necesario, por tanto, conocerlos y tenerlos en cuenta como referencia en el desarrollo del producto software.

Por tanto, este área de proceso requiere que los requisitos estén perfectamente identificados y, además, sean conocidos y entendidos por todos los implicados en el proyecto (equipo de proyecto, usuarios, responsable técnicos del cliente, etc…).

Otro de los requerimientos de este área es que se tenga control sobre el cambio en los requisitos, para ello es necesario que solo un grupo reducido de personas tengan la capacidad de decidir en ese sentido.

Esto no quiere decir que cualquier usuario no pueda proponer cambios, antes al contrario, cualquier aportación debe ser acogida de forma positiva, el matiz en este caso, es que esas propuestas deben ser analizadas por unos pocos (que se entienden que son designados como expertos del proceso o procesos que se informatizan) y que con el asesoramiento de los técnicos software (sería lo más recomendable) toman la decisión sobre qué cambios realizar, cuáles no y en definitiva, cuáles son las prioridades.

Ante una decisión de cambio en los requisitos, este área de proceso tiene el requerimiento de que el resto de artefactos/entregables del proyecto se mantengan consistentes.

Por este motivo hay que tener mucho cuidado a la hora de definir los entregables documentales de un proyecto, ya que cuántos más y más complejos sean, mayor será el esfuerzo necesario para ponerlos consistentes. Es importante apoyarse en herramientas CASE para facilitar la consecución de este objetivo.

Otro requerimiento es la trazabilidad bidireccional y sobre esto habría mucho que hablar. Si se toma al pie de la letra quiere decir que debería poder conocer todos los componentes de ingeniería del software y del producto software (a nivel de clase) asociados a un requisito y también en el sentido contrario, es decir, que partir de una clase se sepa a qué requisito o requisitos puede afectar un cambio en la misma. El objetivo de esto es poder realizar un análisis de impacto y servir también de soporte para la detección de inconsistencias entre los requisitos y los productos derivados del proyecto (incluido el propio sistema de información).

Sin embargo, esta trazabilidad bidireccional resulta costosa de conseguir y no resultaría aconsejable su aplicación en determinados tipos de proyectos (se estaría matando moscas a cañonazos) y en otros, llegar a nivel de clase en el código no aportaría mucho ya que la organización en capas, de las clases, etc… viene condicionada por el generador de código utilizado y el framework.

Para poder respectar en lo posible este objetivo, es importante definir un nivel de entregables documentales acordes a la naturaleza del proyecto (maś entregables, más complejidad, así que hay que tener cuidado con esto) y tener un conocimiento del framework de desarrollo y de la arquitectura de la aplicación, de manera que se sepa de manera rápida donde hay que mirar para conocer el impacto de la modificación de determinados requisitos (lo que se hace es mirar de más arriba la codificación de la aplicación y no entrar a un detalle a nivel de clase). También resulta fundamental un código lo más claro y limpio posible.

Sobre la trazabilidad lo importante, entiendo que debe ser quedarse con el espíritu de la misma y tener unos procedimientos en el proyecto que permitan hacer un análisis de impacto y análisis de consistencia en un tiempo razonable. Hay que recordar que CMMI establece un modelo de referencia, determina el qué pero no el cómo.

En el anterior artículo comencé con el análisis del primero de los cuatro principios o valores que componen el manifiesto ágil. Ahora le toca el turno al segundo principio:

Principio 2: Valorar el software que funciona, por encima de la documentación exhaustiva.

La finalidad última de todo desarrollo de software es obtener un producto que satisfaga las necesidades de quienes los vayan a utilizar. Todo lo demás está uno o varios escalones por debajo.

Por tanto si una aplicación funciona tal y como quería el cliente, de manera que pueda realizar su trabajo de manera eficiente y productiva se habrá conseguido un éxito…¿o no?.

Es un éxito hoy, pero mañana puede suponer una fuente de problemas.

Entregar un software sin errores es muy complicado (no digo que sea imposible), de hecho es tal el esfuerzo que habría que hacer por parte de los que lo revisan y tal el esfuerzo que tendría que hacer por parte del desarrollador para que un software se entregue sin errores, que no resulta rentable llegar a ese extremo (salvo que se trate de un software que por sus características específicas y criticidad requiera la realización de ese esfuerzo, el cual, para que sea efectivo debe ser tenido en cuenta en el presupuesto del proyecto), esto requerirá tareas de mantenimiento correctivo, que no deberían ser muchas ni complicadas, porque si así fuera no deberíamos considerar que el software que se ha entregado funciona.

Los requisitos cambian y el software se tiene que adaptar a esos cambios, lo que hace que los sistemas de información requieran de tareas de mantenimiento evolutivo.

La realización de tareas de mantenimiento correctivo y evolutivo (como también ocurriría con el mantenimiento adaptativo y perfectivo) implica trabajar con el código fuente de la aplicación. Si la codificación no es buena: dificultad en la legibilidad y comprensión del código, alto acoplamiento, baja cohesión, el mantenimiento del sistema se puede convertir en una tortura, cuyo coste será proporcional a la deuda técnica existente.

No basta solo con que el software que se entregue funcione, la calidad del código es importante de cara a futuros mantenimientos.

En este principio se pone en una balanza el funcionamiento del sofware sobre la existencia de una documentación exhaustiva y es algo en lo que estoy totalmente de acuerdo.

El software cambia, por lo que si la documentación no cambia con él (y no me estoy refiriendo solo a la que se encuentra recogida en ficheros ofimáticos, herramientas CASE o la compuesta por los propios comentarios que aparecen en el código), tenemos documentación que cada vez servirá para menos, hasta que llegue a un punto de que más que ayudar a la comprensión del sistema, le perjudique.

Mi visión sobre la documentación (salvo las actas que se quieran elaborar de reuniones o documentación adicional que se quiera elaborar, como por ejemplo, esquemas de interfaz de usuario, etc….) es que se realice sobre herramientas CASE, ya que facilita la trazabilidad de los diferentes componentes documentales y que sea la justa y necesaria para el proyecto en el que se está trabajando, es decir, ni más, ni menos.

La documentación debe servir para que los programadores sepan qué funcionalidad es la que tienen que desarrollar, por lo que la misma debe ser concisa y sin ambigüedades. Todo lo que sea ambiguo tenderá a ser rellenado en la mayoría de los casos por la interpretación que del problema haga el programador, la cual además será errónea en la mayor parte de los casos y no porque el programador sea bueno o malo sino porque lo más habitual es que el contacto entre usuario y programador haya sido escaso o nulo, y por tanto difícilmente ha podido captar sus necesidades y sensaciones.

Por tanto, documentación, la necesaria, de calidad y actualizada (debiéndose mantener actualizada toda aquella que no se pueda obtener por ingeniería inversa). Si además a partir de ella se puede generar código pues mucho mejor.

¿Tiene la documentación alguna misión más que la de servir de apoyo al proceso de desarrollo? Si tenemos un sistema de información grande en el cual hemos podido tener diferentes proveedores trabajando y se quiere sustituir un proveedor por otro, lo mejor es que haya un soporte documental técnico que facilite la compresión del nuevo proveedor lo antes posible (también lo podría hacer interpretándolo a partir del código, pero puede resultar complejo si el mismo no es muy bueno y si el sistema es de gran tamaño).

Además, si desarrollas un producto tener ciertas partes documentadas vende (y no es ya cuestión de lo que puedas pensar como desarrollador de la utilidad de la documentación) sino de lo que pueda pensar quien te va a comprar la aplicación.

En resumen, lo primordial es que el sistema de información que se ha desarrollado se ajuste lo máximo posible a las necesidades del usuario con el menor número de errores posible pero sin olvidar que también debe ser desarrollado con un código de calidad y se ha debido generar una documentación que debe ser la mínima necesaria para la realización y comprensión del sistema, que también debe ser de calidad y actualizarse, salvo aquellas partes que se puedan obtener de forma rápida y sencilla mediante ingeniería inversa.

Continuemos con el análisis de los principios del manifiesto ágil.

Con respecto a los casos de uso, soy un converso, hasta hace poco tiempo pensaba que eran un trámite más en el proceso de desarrollo de software y que no aportaban nada. Ahora pienso todo lo contrario y, como la mayoría de los conversos, defiendo al máximo la realización de este entregable del proceso de análisis del sistema de información, ya que efectivamente, contribuye al ajuste del catálogo de requisitos y sirve de complemento idóneo al mismo en el sentido de que describe el comportamiento del sistema de información desde el punto de vista de la interacción entre el mismo y los diferentes actores, ya sean personas u otros sistemas.

Los requisitos y la descripción de casos de uso, van de la mano, si bien es importante tener una primera versión del catálogo de requisitos bastante sólida antes de comenzar a realizar los diagramas de casos de uso y lo más importante, la descripción de los mismos y de sus diferentes escenarios.

Cuando se estén definiendo los casos de uso saldrán dudas que permitirán aclarar o mejorar determinados requisitos y probablemente salgan a la luz nuevas funcionalidades o necesidades no tenidas en cuenta. Por ese motivo es esperable y deseable la modificación del catálogo de requisitos tanto en el proceso de definición de los casos de uso como en la obtención de su versión definitiva.

Es importante que una vez completados los casos de uso se verifique que cuadran con los requisitos, de manera que no haya casos de uso que hagan referencia a requisitos y requisitos que no se vean reflejados en casos de uso. Para ello es necesario realizar una matriz casos de uso/requisitos que ayude a la realización de esta actividad.

Una buena descripción de los casos de uso, guía el proceso de desarrollo, en cuanto a que describe el comportamiento del sistema, descompuesto en subsistemas de análisis (es un proceso previo a la realización de los casos de uso y que permite dar a la aplicación una división por grandes niveles funcionales o procesos de negocio) y a su vez descompuesto por funcionalidades específicas que se describen como una secuencia de pasos en los que interviene el sistema y los actores o agentes externos al mismo pero que interactúan con él. Es decir, a partir de los casos de uso, con mayor o menor detalle se especificará cómo se realizarán determinadas funcionalidades sin entrar en aspectos concretos de implementación.

En muchos casos una buena definición de casos de uso, acompañada por un diseño de interfaz de usuario y navegación aprobado por los usuarios y del modelo de datos, puede resultar suficiente para la construcción con ciertas garantías de un sistema de información.

Otra de las ventajas de los casos de uso es que a partir de ellos se pueden obtener otros productos de interés para el proyecto sin esfuerzo adicional (haciendo uso de herramientas CASE), como por ejemplo diagramas de actividad (que son otra forma de representar los caminos de un caso de uso, en la cual se pasa de la descripción textual a una representación de carácter gráfico) o la obtención de una buena parte del conjunto de casos de prueba del sistema.

También pueden ser utilizados como una técnica para la estimación del coste del proyecto, aplicando la estrategia de estimación por puntos de casos de uso (conceptualmente parecida a la técnica de puntos función, pero más simple).

La implantación de procedimientos dentro de un departamento de desarrollo de software produce beneficios y por tanto un retorno de la inversión.

El principal inconveniente que encuentra es la reticencia del personal a cumplirlos ya que en su mayoría piensan que toda esa burocracia es una pérdida de tiempo.

El primer error es pensar que se trata de burocracia o por lo menos en el sentido negativo en el que se suele entender ese término, obligarte a seguir una serie de pasos para realizar determinadas acciones no es burocracia, son procedimientos. Esto no quita que el diseño de los procedimientos deba ir acorde con las posibilidades que tiene el departamento, si se va más allá de lo que se puede abarcar, estamos ante una situación contraproducente (no se terminarán por seguir los procedimientos y además se producirá una reducción de la eficiencia).

No es necesario empezar a procedimentarlo todo de la noche a la mañana. Lo mejor es ir poco a poco, que el personal se vaya acostumbrando a esta otra forma de trabajar, más ordenada, que permite, por todos, una mayor control de las acciones que se realizan.

Los procedimientos irán acompañados de herramientas (o por lo menos es aconsejable). En mi organización los procedimientos internos del departamento de desarrollo y nuestra interacción con el resto de departamentos del área TIC se realizan básicamente con 5 herramientas:

– Un Service Desk como componente que integra todo el conjunto de incidencias y peticiones en producción.
– Redmine como sistema de gestión de proyectos: planificación de tareas e interfaz con el repositorio documental (en nuestro caso Alfresco, aunque perfectamente se podría haber utilizado la propia herramienta como gestor documental).
– Alfresco, como repositorio documental.
– Mantis para el reporte de incidencias en la fase de pruebas de la aplicación.
– Una software de agenda compartida, para la gestión de nuestras citas y reuniones.

Como comenté antes, no se trató de implantar un conjunto de procedimientos de la noche a la mañana, sino que se hizo paulatinamente, asimismo no todas las herramientas se implantaron a la vez, ni el grado de uso de las mismas fue intenso desde el primer momento. Ha sido el tiempo y también determinadas decisiones de los responsables de informática los que han consolidado los procedimientos y las herramientas.

No son las únicas herramientas que utilizamos en el departamento de desarrollo ya que la realización de determinados procesos, requieren de otras herramientas complementarias que nos aportan, además una serie de ventajas:

– Subversion: Como sistema de gestión de fuentes y sus versiones.
– Artifactory: Como repositorio de librerías dependientes.
– Hudson: Para la automatización del proceso de compilación, generación del desplegable e interacción con Sonar (tenemos previsto próximamente el uso de Hudson para realizar el despliegue completo de una aplicación).
Sonar: Para el análisis estático de código.
– Enterprise Architect: Diseño de modelos (requisitos, casos de uso, etc…) y de documentación a partir de los mismos.

Como he comentado antes, los procedimientos requieren herramientas y las herramientas procedimientos, los unos sin los otros no terminan por producir buenos resultados.

Los procedimientos deben estar por escrito y ser dados a conocer por quienes los tienen que cumplir y se debe hacer un seguimiento de su implantación, por lo menos hasta que se consiga que la organización asimile la nueva dinámica de funcionamiento.

¿Por dónde se empieza? Supongamos que ya tenemos definida una dinámica de trabajo en cuanto al propio proceso de codificación de software, si no es así, ese debe ser el inicio (es decir, habría que establecer un framework de desarrollo, la selección de un IDE, de un sistema de gestión de versiones, una herramienta de integración continua, etc…, unos entornos de preentrega, un sistema de atención interna de dudas, sugerencias, etc… en el proceso de desarrollo (así como la persistencia de aquellas que sean más interesantes, para permitir la consulta futura), etc…

A partir de ahí, el siguiente paso debe ser controlar hacia dónde se enfoca la dedicación de los empleados, lo que hace necesario la existencia de una herramienta de imputación horaria. Esta gestión de incurridos es fundamental si la función principal de tu organización es la prestación de servicios a terceros. En el caso de mi organización no tenemos ninguna herramienta de esas características porque somos principalmente clientes de los trabajos (lo que ha hecho que no sea algo prioritario).

A continuación se debe trabajar en la gestión de las entradas de incidencias y peticiones por parte de terceros, así como su planificación. De esta forma se consigue dar un orden al trabajo, saber qué esta haciendo cada cual en cada momento y poder planificar los recursos humanos en el tiempo, de manera que se reduzca el número de tiempos muertos y cada persona se utilice, en la medida que sea posible, en aquellos proyectos y actividades donde se pueda aprovechar de mejor manera su potencial.

Lo comentado en el párrafo anterior se puede hacer en paralelo, con la obligación de que cada reunión con un cliente tenga como resultado final un acta (siguiendo en la medida de lo posible un mismo formato y que se almacena de la misma forma para todos los proyectos), que además debe ser enviada a los mismos. Como podéis ver, estos procedimientos que no requieren gran esfuerzo implantarlos, producen beneficios innegables. Solo requiere pequeños cambios en algunas de las rutinas de los empleados (el desarrollo de software es mucho más que tener abierto Eclipse toda la jornada laboral).

Una vez llegado a este punto resulta recomendable integrar el sistema de imputación horaria con el sistema de planificación de proyectos para tener el tiempo real que se ha invertido en cada tarea.

Sabemos cuánto se ha presupuestado cada proyecto, cuánto se lleva invertido en cada uno y aproximadamente el grado de avance en los mismos. Con esas variables es posible conocer el estado de los costes de cada proyecto, algo fundamental para detectar desviaciones a tiempo y tomar medidas (de nada sirve detectar que hay problemas si no se toman decisiones al respecto).

¿Por dónde se sigue? A partir de aquí, entrarán en juego, las preferencias personales. En mi caso, yo potenciaría el establecimiento de una normativa documental en los desarrollos apoyada en una herramienta CASE. Los desarrolladores odian documentar, principalmente porque no se sabe documentar (duele, pero es la verdad) y porque no se tiene un procedimiento, técnica y mecánica para hacer que ese proceso “insufrible” sea menos doloroso, es decir, que haga que el proceso de documentación sea más eficiente y productivo. Si con documentación vas a tener problemas con el cliente de todas maneras, ya sabemos todos los problemas que se tiene cuando se carece de ella, donde al final el cliente meterá casi tantos goles por la escuadra como quiera, ya que él dispone de todas las cartas y tú de ninguna. Además, la documentación puede guiar el proceso de desarrollo, cuestión de acostumbrarse a trabajar con ella y además permite dar un acabado a los proyectos que puede dar lugar, en muchos casos, a marcar la diferencia entre un proveedor y otro.

¿No crees en los procedimientos? Prueba a implantar alguno, hazle un seguimiento y mide los resultados, lo mismo cambias de opinión.

Lo tengo visto y comprobado, si existen dos tareas, una es la principal y otra se considera auxiliar y falta tiempo, sobra trabajo o ambas cosas, se terminará priorizando la tarea principal, dejando en segundo plano o abandonando la auxiliar.

Eso pasa con la documentación de los proyectos de desarrollo de software, donde la línea principal es la construcción del producto y la creación de la documentación una línea secundaria que si se puede se hace mejor o peor y si no se puede pues se deja un lado.

Para evitar este asunto hay que integrar el proceso de generación de la documentación dentro de la línea principal, es decir, la construcción y eso se puede conseguir de una manera bastante racional haciendo uso de herramientas CASE, donde además resulta bastante sencillo realizar un mantenimiento de los diferentes modelos con los que se esté trabajando.

Va a existir documentación que se generará extra-CASE y que se tendrá que hacer por los medios tradicionales, como por ejemplo, las actas de las reuniones, los manuales de usuario, etc…, pero al integrarse el esfuerzo documental en la línea central del desarrollo de software, asumir este tipo de documentación adicional resulta mucho menos pesado.

En mi departamento seguimos dando pasos pequeños, pero firmes para tener una infraestructura de desarrollo de software en condiciones.

– El uso de Subversion ya es generalizado, por lo que tenemos un control absoluto sobre los fuentes de las aplicaciones.
– El uso de Artifactory también es generalizado, por lo que también tenemos un control absoluto sobre las librerías que se utilizan y las tenemos en un espacio distinto a los fuentes.
– El uso de maven para las entregas e implantación también es generalizado y se está generalizando la implantación mediante Hudson.
– Tenemos un libro blanco de desarrollo que de un tiempo a esta parte ha orientado los desarrollos a una arquitectura y una tecnología común, lo que facilita la reutilización y el mantenimiento. En la actualidad se está retocando dicho libro para actualizarlo tecnológicamente, acotar un poco más el abanico de posibilidades y soluciones a utilizar y modificar drásticamente la forma de documentar los proyectos, basándonos en una herramienta CASE (independientemente de que haya documentación extra-CASE).
– La metodología de peticiones de entregas y de comunicación de incidencias en las pruebas con las empresas desarrolladoras también se está generalizando.
– La documentación de los proyectos está centralizada en un ECM (en nuestro caso Alfresco), con una estructura de carpetas por proyectos. Esta forma de organizar la documentación va a variar con la nueva versión del libro blanco que como he comentado se va a basar en el uso de una herramienta CASE.
– Se ha terminado de implantar una herramienta para gestionar los proyectos de manera que no tengamos la gestión en diversas herramientas y soluciones. A partir de ahora vamos a tratar de que la gestión de todos los proyectos esté centralizada en Redmine. Probablemente más adelante “truquemos” Redmine para comunicarlo con Alfresco, para añadirle alguna característica como la gestión de incurridos, etc…

Todavía nos queda mucho camino por recorrer, pero creo que la dirección que hemos tomado es adecuada. Mi único mérito en todo este asunto ha sido escuchar y dejarme aconsejar por gente que sabe mucho, muchísimo de lo que es el proceso de desarrollo de software. También hay que destacar la acogida que ha tenido esta infraestructura entre mis compañeros porque sin su colaboración nada hubiera sido posible.