Las herramientas de modelado UML

Andamos liadillos con el diseño y, a pesar de haber decidido la herramienta a utilizar en la Oferta, se nos ocurre la idea de escribir un post acerca de este tema. Existen en el mercado multitud de suites para realizar diagramas UML, pero en casi todas hemos encontrado alguna pega.

Las principales taras van desde que el no soportar UML 2.x a realizar diagramas muy poco atractivos desde el punto de vista visual, pasando por mil pequeños detalles que a unos gustan más, y a otros, menos. Vamos a hablaros un poco de aquellas que hemos ido usando todos estos años y comentando un poco nuestras impresiones.

Por ejemplo, Altova UModel, una herramienta que soporta UML 2.x, que crea unos diagramas de componentes y de clases bastante atractivos visualmente, pero que no permite introducir componentes en el diagrama de clases (sólo deja paquetes) y los diagramas de Casos de Uso son realmente feos a la vista.

Por otro lado, dTinf Cake Studio, que no soporta UML 2.x, que es bastante pesado de manejar, por el control sobre relaciones, para mover entidades dentro de los diagramas, etc, pero éstos resultan bastante atrayentes.

Microsoft Visio. No sabemos si se podría introducir aquí, porque realmente no se basa en estándares UML, aunque permite realizar diagramas con tal lenguaje. A su favor tiene la gran facilidad de manejo, pues es muy intuitiva y no requiere apenas familiarización previa.

Rational Rose es quizá la herramienta más famosa y potente para modelado UML, es de IBM y tiene una gran aceptación a nivel mundial. La única pega que se le puede poner es que requiere de un conocimiento del entorno bastante avanzado para tener un manejo ágil del mismo.

Finalmente, nosotros nos hemos decidido por Enterprise Architect, que permite UML 2.x, sus diagramas son bastante atractivos y es moderadamente sencilla de manejar.

Por último, citar que existen muchas otras, como Telelogic, VisualParadigm, etc., que podréis usar, nosotros sólo os damos pistas para que probéis y, finalmente elijáis la que más os satisfaga.

El infierno llegó

Comienza la parte, en nuestra humilde opinión, más dura de la asignatura: la fase de diseño. Cuando comenzamos a trabajar el ella nos dimos cuenta de lo complicado que es plasmar toda esa información que tenemos en lenguaje natural en un conjunto de diagramas que sirvan para describir la arquitectura del sistema.

Esta fase no consiste sólo realizar un diagrama de clases que refleje todas aquellas entidades que serán necesarias para que la descripción del sistema sea completa, sino que, comenzando a un alto nivel, será necsaria una definición de los distintos subsistemas que conformarán CLICKR, la comunicación entre ellos, sus características, etc. El pasado martes aquello parecía un hervidero. Primeramente se discutió sobre el patrón arquitectónico que emplear, que si un MVC tradicional, que si uno de capas... Luego, una vez que creíamos que teníamos solucionado un poco el asunto, llegó lo peor.

Y es que un diseño de bajo nivel no es algo trivial. Primeramente, y partiendo de la base de que la tecnología usada será Java, hemos de comentar que existen multitud de herramientas, librerías o tecnologías para implementar los distintos módulos, y desde aquí recomendamos encarecidamente que, a menos de que se conozca muy bien la citada tecnología, se desista de su uso, porque se va a perder un tiempo precioso en aprender algo que, probablemente luego pueda estar mal.

Nos volvimos locos en un mar tecnológico: que si JSP o JSF para la capa de presentación, que si Hibernate para el mapeo objeto-relacional, que si DAO para el acceso a la capa de datos, que si Struts para la implementación del Modelo-Vista-Controlador, que si Spring o EJB para la lógica del negocio, que si usar patrones de diseño tradicionales como Handler o Singleton, que si no usar nada de eso...

Lo dicho, mucha suerte y evaluad bien todas las alternativas antes de decantaros por ninguna, porque hay cosas realmente interesantes que pueden ahorrar bastante trabajo a la hora de implementar (nuestro enfoque tradicional), pero que pueden ser un suplicio para diseñarlas (nuestro enfoque actual).

¡Ánimo!

La importancia de... la gestión de los requisitos

Tras el post anterior, y un poco fastidiados por algunos cambios que tuvimos que hacer en el DAS provocados por modificaciones en el EVS, hemos estado buceando por Internet y hemos descubierto algo que antes nos parecía un horror y que ahora vemos como una ayuda bastante interesante y a tener en cuenta: las Herramientas de Gestión de Requisitos.

En un principio puede parecer una tarea tediosa, la de tener que introducir requisito a requisito en la aplicación, con todos los atributos que éstos tienen, las dependencias, etc. Pero muchas veces un requisito mal definido, una funcionalidad mal interpretada o, simplemente un cliente "especial", pueden hacer que se tenga que volver hacia atrás y haya que modificar el Estudio de Viabilidad, con los consiguientes trastornos que ello acarrea, porque un error en una fase crece exponencialmente conforme va avanzando el proyecto, y es entonces cuando te das cuenta de la dimensión del problema.

Este tipo de herramientas permiten realizar variaciones entre requisitos de software y de usuario, estableciendo la trazabilidad entre ambos, y manteniendo la consistencia, sin que la eliminación de uno pueda suponer una catástrofe en el resto. Así mismo se permite una gestión de los mismos, pudiendo variar sus atributos conforme va avanzando el proyecto, puesto que, por ejemplo, la estabilidad en un momento puede ser media y, con el tiempo, pasar a alta. Otro aspecto muy interesante a tratar es el del control de las matrices de trazabilidad, que se realizan y actualizan de manera automática con la simple inserción del requisito de usuario fuente con respecto al de software, lo cual evita una actividad bastante aburrida, ya que no sólo se ha de realizar la primera vez, sino que también la gestión y mantenimiento de la misma puede llegar a resultar exasperante. También existen herramientas que permiten visualizar el posible impacto que puede tener un cambio en el resto del proyecto, siendo tarea del Jefe del Equipo el evaluar si esa modificación es realmente asumible o el coste que va a tener implícito puede ser mayor que el beneficio de provoque.

Por último, citar algunas de estas herramientas, algunas de ellas de libre distribución, que pueden ser útiles para este tipo de trabajo: Caliber-RM, DOORS, SoftREQ, ReuseStudio, RTM Workshop, Requisite Pro, etc., y citar la aplicación desarrollada para tal fin por nuestro compañero Marcos en su PFC de ITIG: Requirements Management Tool. Una aplicación, desarrollada en formato Web, que es capaz de competir con gran cantidad de las suites existentes en el mercado.

Recomendaciones para el Análisis

Una vez prácticamente finalizada la fase de análisis (a falta de un par de modificaciones en el DAS), queremos plasmar cuáles son nuestras impresiones, así como dar algunos consejos que puedan ser útiles de cara a futuros Análisis de Sistemas de Información. Lo primero que queremos comentar es que, a pesar de que pueda resultar algo trivial, o incluso banal, esta fase es fundamental para nuestro proyecto, pues todo lo que hagamos ahora será la base del futuro sistema, con lo cual las decisiones que tomemos habrán de ser consistentes, pues un pequeño cambio en este punto puede suponer un cambio inasumible en fases posteriores.

A continuación os vamos a mostrar algunas de las recomendaciones que distintos miembros del equipo dan en base a su experiencia como Analistas:

"Realizad un gráfico de bajo nivel que contemple las distintas funcionalidades que posee el sistema, de tal forma que, posteriormente, la extracción de los distintos Casos de Uso resulte notablemente más sencilla y, por extensión, esto se vea reflejado también en la fase de obtención de requisitos."

"Revisad la descripción de los requisitos. Por un lado es fundamental comprobar que ésta describe correctamente la funcionalidad que se pretende plasmar, y por otro, se ha de intentar definir cualquier término que pueda presentar ambigüedad, con el fin de hacer que el cliente tenga una comprensión clara de lo que se dice y que tenga la sensación de que realmente se está entendiendo lo que él desea."

"Centrad el diseño conceptual en las funcionalidades básicas de la aplicación, sin preocuparse demasiado por las posibles variaciones que podría tener el diseño según la tecnología utilizada. Es muy importante que el diseño de clases (modelo conceptual) sea adaptable a cualquier tecnología."

"Se debe dedicar una gran cantidad de tiempo en realizar un análisis en profundidad de los requisitos, cubriendo todas las funcionalidades que se describieron en la oferta y que el cliente querrá que estén reflejadas en el futuro sistema."

"Sentaos tranquilamente y revisad que los distintos módulos del Análisis son consistentes. El trabajo en paralelo es fundamental, pero muchas veces cada uno interpreta las cosas de una manera y pueden aparecer errores que a la postre pueden resultar fatales. No es necesario mucho tiempo, pero sí estar seguros de que nuestra parte concuerda con las demás."

Bueno, esperamos que estos consejillos puedan seros de ayuda y que os eviten alguna versión de más.

Sobre la Gestión de la Configuración

Trabajando en el Plan de Gestión de Configuración nos hemos dado cuenta de que no es un proceso banal, tal y como pudiera parecer en un principio, sino que el documento que se genera va a tener una importantísima repercusión en todo el trabajo que desarrollemos en el futuro. El principal objetivo de este Plan es el de mantener la integridad de nuestro producto a lo largo de todo el ciclo de vida del producto software, habida cuenta de las numerosas modificaciones que va a sufrir a lo larto de todo el proceso de trabajo a causa de reuniones con el cliente, malentendidos en el funcionamiento, etc. Todo esto infiere, de una forma irremediable en el siguiente plan a tratar, el de calidad.

En lo que a nosotros se refiere, va a marcar las directrices para múltiples aspectos de nuestro proyecto:

• Identificación de los documentos: se especificará cuál será la nomenclatura de los distintos productos generados a lo largo de las distintas actividades del mismo (documentos de desarrollo, actas de reuniones, actas de gestión de cambios, etc.).
• Establecimiento de las bibliotecas de almacenamiento del sistema: en ellas se crearán múltiples directorios para ir almancenando los distintos productos generados, ya sean versiones beta, definitivas, copias de seguridad, control de tiempos,etc., tales como biblioteca maestra, de backup, de seguimiento...
• Gestión de cambios: se diseñarán los formatos de las hojas de control de estado de los documentos, de las solicitudes de cambios, de los informes, de las certificaciones de aceptación, etc., así como una definición de cuál será el proceso que sigue un cambio desde que se propone hasta que se acepta/rechaza.

Una vez explicado cómo se ha de hacer, es interesante ver que este plan realmente tiene ventajas y que puede aportar un valor añadido a nuestro producto.

• Mantenimiento integral de la integridad de los distintos elementos del proceso, en una atmósfera de cambio continuo.
• Control de la evaluación y ejecución de los cambios.
• Visión objetiva y concreta acerca de la creación y evolución del producto.
• Robustez ante auditorías y revisiones, pues se muestra el estado del avance real del proyecto.
• Reducción de costes de desarrollo, manteniendo una estabilidad en el proyecto.
• Aseveración de la integridad del producto en la operación, actualización y consistencia de toda la documentación generada.
• Incremento en la eficiencia y efectividad de la administración.

Por todo ello podemos asegurar que, a pesar de ser un documento no excesivamente extenso, sí es fundamental para un mejor proceso de desarrollo del proyecto y creemos que seguirlo fielmente puede ayudarnos a ser más eficientes en nuestro trabajo.

Métricas para el Control

A raíz de encontrarnos inmersos en la primera sesión de control del proyecto, se nos ha ocurrido investigar algo sobre métricas o métodos para la mejora del control de los proyectos, de la planificación de los mismos y del rendimiento de los trabajadores. Con este post se pretende dar una visión global de dos de estas métricas: PSP (Personal Software Process) y TSP (Team Software Process). Éstas surgen por la necesidad de poder aplicar un modelo de madurez (CMM) a proyectos pequeños, yendo desde el ingeniero de software como entidad hasta el equipo de desarrollo; de ahí la primera P (Personal) de PSP y la T (Team) de TSP.

PSP

Fue definido por Watts S. Humphrey, y tiene como principios:

• Cada ingeniero es diferente, por lo que debe planificar su trabajo en base a su propia trayectoria profesional.
• Para mejorar, los ingenieros deben usar procesos personales bien definidos y cuantificados.
• Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos, que no es fruto del azar, sino del esfuerzo por hacer un trabajo de calidad.
• Cuanto antes se detecten y corrijan los errores, menos esfuerzo será necesario.
• Es más efectivo evitar los defectos que detectarlos y corregirlos.
• Trabajar bien es la forma más rápida y económica de trabajar.

Así mismo, el ingeniero, como profesional, debe:

• Planificar el trabajo.
• Esforzarse por cumplir la planificación.
• Esforzarse por obtener productos de calidad.
• ... y esto en un contexto de mejora continuo.

Actividades de PSP:

• Planificación: estimar errores, creación de una planificación del proyecto, estimación de tamaño y recursos.
• Diseño de Alto Nivel: diseño del componente y creación de prototipos.
• Revisión de diseño de Alto Nivel: verificar errores en el diseño.
• Desarrollo: generar el código, revisarlo, compilarlo y corregir errores.
• Análisis de Resultados: medir la efectividad del proceso en base a todas las mediciones tomadas durante el mismo.

PSP es un método que puede proporcionar una gran mejoría en el rendimiento del Ingeniero de Software y, para ello, se centra en una serie de aspectos en los que incide para lograr tal mejoría. El primero de ellos es el Control del tiempo, que infiere en que el Ingeniero ha de medir el tiempo que dedica a cada una de las tareas, teniendo en cuenta posibles interrupciones y anotando aquellas fases que se concluyan. En este punto entran en liza el Resumen Semanal de Actividades y la Tabla de Registro de Tiempos, formularios en los que se anotan las horas dedicadas a cada actividad por día. Ello permite ver en qué tareas se dedica más tiempo y establecer unas planificaciones futuras más ajustadas. Otro aspecto es la Planificación, que tiene como pilar el punto anterior, puesto que en base al recuento de tiempos veremos qué actividades necesitan mayor dedicación y cuales menos. El Tamaño del producto es otro punto importante. Aquí entra en juego el Resumen de Plan de Proyecto, documento que recoge las estimaciones tanto de tamaño como de posibles errores, así como los datos reales, de tal forma que nos dan una visión clara de cómo de bien planificamos o en qué fallamos más. Todo esto también afecta al punto de la Planificación, que es el epicentro de PSP.

Como conclusión, a pesar de ser un proceso muy costoso, que puede hacer que el profesional pierda motivación, sí que se ha demostrado que las personas que emplean este método consiguen una mejoría notable, con unos datos, en un periodo de tiempo razonable, netamente superiores a los de un Ingeniero que trabaja sin métrica de control alguna.

TSP

Al igual que PSP, fue creado por Humphrey. Su idea es la de ajustar los principios de PSP al trabajo en equipo, algo fundamental en nuestros días. Propone que los datos ofrecidos por los ingenieros capacitados en PSP pueden ser utilizados para administrar equipos de desarrollo de software.

Proporciona directrices para que el equipo pueda establecer unos objetivos realistas y pueda planificar los procesos en los que se ve involucrado, con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y dar lugar a productos eficientes, fiables y de calidad.

Fases del ciclo TSP:

• Lanzamiento: revisión de objetivos, formación de equipos de trabajo y describir las necesidades del cliente.
• Estrategia: diseño conceptual, elaboración de estrategia de desarrollo, identificación de riesgos y estimación de tamaño del producto y del esfuerzo requerido.
• Plan: estimación del tamaño de los componentes, identificación de tareas y establecimiento del plan de calidad.
• Requisitos: análisis de las necesidades, establecimiento de requisitos y plan de pruebas.
• Diseño: de alto nivel, especificando cada componente, establecimiento de estándares de codificación y plan de integración.
• Implementación: diseño detallado, implementación, revisión, compilación y pruebas unitarias.
• Pruebas: integración y pruebas globales del sistema.
• Postmortem: análisis del producto desarrollado y documentación.

La principal pega que tiene esta métrica es que añade un trabajo extra al propio del PSP, y esto, en un equipo de trabajo acosado por plazo de entrega inviables, cantidades ingentes de trabajo, etc., puede resultar una tarea que, en vez de sumar, reste.

A pesar de todo, y de que es mucho más reciente y, por lo tanto, menos maduro, que PSP, se trata de un método que, si se elabora de una forma estricta y constante puede dar lugar a mejores prácticas de ingeniería y un aumento del rendimiento de los equipos de trabajo.

Primeras impresiones

Parece que nos hemos salvado de la quema... por lo menos por ahora.

Esta mañana nos han corregido la oferta, el primer documento a entregar del proyecto de IS3, y salvo algunos errores tontos (calificados como "de Barrio Sésamo") y cosillas fácilmente modificables, no hemos salido muy mal parados, o al menos esa es la sensación que nos ha quedado.

Esta semana pasada nos ha servido para ir dándonos cuenta, a escala bastante reducida, de lo que va a significar esta asignatura a lo largo de todo un cuatrimestre: muchas reuniones, muchas horas de trabajo, y sobre todo la dificultad de coordinar a 7 personas a la vez para que se pongan de acuerdo (aunque sólo sea para elegir un día de reunión). De todas formas lo afrontamos con optimismo y vitalidad, por lo menos ahora, ya veremos cómo estamos en noviembre...

Es gracioso comprobar cómo, al igual que pasa en los grupos de amigos y en otros conjuntos más o menos reducidos de personas, es complicado ponerse de acuerdo hasta para elegir la tontería más insignificante (quién no se habrá pasado discutiendo con los colegas durante 2 horas para decidir a qué garito nos vamos de copas... como si eso importase). Pues eso, nosotros somos capaces de tirarnos una hora delante de la pantalla de un ordenador intentando decidir qué nombre le ponemos a nuestro producto, llegando al extremo de consultar un generador automático de nombres (bastante pésimo, por otra parte). En fin, qué sería de nosotros sin esos momentos de dispersión.

Y hablando de momentos de dispersión, nuestro proyecto se basa en "Twitter.com" (para entenderlo, hay que verlo hasta el final, como las buenas pelis):



Y nada más, como punto final hay que felicitar a nuestro compañero de equipo Marcos, que tras mucho esfuerzo y sacrificio se ha sacado una merecida Matrícula en su PFC de la Ingeniería Técnica. Esperamos que te vaya todo igual de bien en esta etapa.