Plantillas: Cierre de Iteración

Si el Plan de Iteración es la planificación de un periodo corto de tiempo dentro del proyecto, entonces el Cierre de Iteración es el informe del cumplimiento de dicho plan.

El documento de cierre de iteración es una presentación de las actividades realizadas, los recursos dedicados, los hitos, los riesgos concretados, así como cualquier otro evento o información de la que queramos dejar constancia.

He de comentar que el Cierre de Iteración que presento aquí tiene una característica adicional: el control de evaluación de los artefactos. La idea es que en el Plan de Aseguramiento de Calidad se indiquen los criterios que deben ser evaluados en cada artefacto, para que luego entre el Plan de Iteración y el Cierre de Iteración se siga la pista de la evolución de estas calificaciones.

Es una característica un poco engorrosa, pero si se cuenta con recursos para mantener un equipo de control de calidad entonces se va a poder llevar a cabo este control, con miras a mejorar la ejecución del proyecto en su conjunto.

En cualquier caso, acá esta la plantilla del artefacto Cierre de Iteración:

Cierre de Iteración (en PDF)

Cierre de Iteración (en iScribd)

, , , , , , , , , , ,

3 comentarios

Definimos retrabajo como…

La elaboración de un diseño o producto, conforme a unas especificaciones conocidas, da lugar a la posibilidad de fallar en el cumplimiento de lo requerido. Toda diferencia entre lo que se nos pidió y lo que estamos entregando como resultado de nuestro trabajo es considerado un fallo de calidad y se le suele llamar inconformidad.

Si la inconformidad es muy grave y compromete la aceptación del producto por parte del cliente, es necesario dedicar esfuerzos adicionales en lograr que el producto sea conforme a lo especificado. A este esfuerzo adicional es a lo que llamamos retrabajo.

Técnicamente como para el glosario:

Inconformidad. Fallo de calidad definido como la desviación del producto de su especificación.

Y también:

Retrabajo. Esfuerzo adicional necesario para la corrección de una inconformidad en algún producto.

El problema que surge con el retrabajo es obvio: es un esfuerzo adicional que no puede en buena lid ser cobrado al cliente, pero que es necesario para que este quede conforme con lo que hemos hecho para él. La idea es entonces minimizar la cantidad de retrabajo en el que incurramos, objetivo deseado pero dificil de lograr sin un adecuado sistema de gestión de calidad.

, , , , , , , ,

Deja un comentario

Aniversario y renovación

Ya con poco más de un año en funcionamiento, es hora de una renovación en el blog. Básicamente esto ha significado el cambio del tema Ambiru que tan buen servicio me prestó siempre, por algo nuevo con características que al menos para mí, son novedosas.

En primera aproximación he adoptado el tema Albeo por Elena G, lo que permite disponer de dos columnas y con esto mismo, activar algunos widgets.

La idea es facilitar la navegación por el sitio, al disponer de enlaces y listas de posts populares o recientes, ahora en un lugar más prominente. Espero que esto signifique una mayor permanencia de los lectores dentro del blog y la promoción de algunos posts importantes pero que ya sea por su título o tematica, no son directamente a los que caen quienes llegan por Google o desde la Wikipedia.

Además y como bono, el cambio de tema ha resulto el problema de la suscripción por RSS. No sé la razón, pero de de un tiempo para acá los enlaces RSS habían dejado de funcionar y aunque tampoco sé la razón, parece ser que ahora con el cambio de tema, han vuelto a trabajar correctamente.

Ya con cuarenta mil visitas acumuladas y con un nivel de nuevos hits de poco más de tres mil a la semana, espero que los cambios con motivo al aniversario del blog sean bienvenidos por todos, tanto los lectores regulares como los de ocasión.

Entre los pendientes del primer año de operación me queda el tratar temas como los patrones de diseño, libros recomendados o las consabidas evaluaciones de software; esto junto con mis preocupaciones de siempre como las prácticas o el soporte al proceso de desarrollo. Sinceramente encuentro muy satisfactorio el mantener el blog y espero poder continuar enriqueciendolo por mucho más tiempo aún. Sé que por temas no voy a quedarme corto, ya que la profesión sigue siendo muy amplia y de momento siento que solo he rascado un poco la superficie de la misma.

2 comentarios

Todo requisito debe ser preciso y legible

La especificación de un sistema es un trabajo retador. En él participan no solo los desarrolladores de aplicaciones, sino también los clientes. Esto significa que la especificación de requisitos, ya sea como casos de uso o como declaraciones tradicionales tipo “el sistema debe…” ha de ser entendida a la vez, por lo clientes y por los desarrolladores. Dicho en otras palabras: la especificación contiene detalles técnicos que los clientes luchan por entender, a la vez que incluye información sobre el negocio que es nueva y potencialmente confusa para los desarrolladores.

Esta situación nos obliga a luchar por dos atributos básicos en todo nuestro sistema de requisitos: la claridad y la precisión.

Precisión de un requisito. Un requisito es preciso cuando indica sin ambigüedad lo que se desea especificar. Debe ir directo al punto y evitar todo adorno en el lenguaje. Debe documentar solo un aspecto del sistema y lo debe de hacer en forma exacta.

Y también

Claridad o legibilidad de un requisito. Un requisito es legible cuando el lenguaje en el que esta escrito es fácil de entender, tanto por los clientes como los analistas. La legibilidad se extiende no solo a la especificación escrita, sino también a los formalismos gráficos como los diagramas de casos de uso.

Es curioso observar que en los cursos universitarios sobre el tema, los profesores tengan la presión de explicar métodos y técnicas avanzadas, como las relaciones de extensión e inclusión de casos de uso, forzando al estudiante a adoptar estar técnicas en forma demasiado temprana. Esto causa una deformación profesional en el estudiante, quien sale del curso con la creencia que es mejor una especificación sofisticada que haga uso de todo lo visto en el curso, en lugar de una aproximación más informal y relajada que puede en verdad ser entendida por el cliente.

El lugar correcto para la extensión y la inclusión, así como para todas las técnicas de modelado de requisitos más sofisticadas, es en aquellos dominios de aplicación donde los requisitos reales sean muy complejos. Es decir por lo tanto, que en la práctica el analista ha de hacer esfuerzos por mantenerse sencillo, normalmente no vale la pena la complejidad del modelo de requisitos.

También es de hacer notar, que en mi experiencia la mayoría de los clientes intentan hacer otro tanto. Ellos suelen expresar lo que necesitan en la forma más directa que tienen disponible, sin embargo dado que los clientes son a su vez profesionales en un área especifica, la forma correcta en la ellos se expresan suponen tensión a los desarrolladores, quienes deben luchar por desarrollar un vocabulario común con el cliente para poder comprender sin errores lo que este pide.

En conclusión: lo sencillo se entiende más y la especificación de un sistema ha de entenderse bien. Cuan sofisticado hagamos nuestro modelo de casos de uso o nuestro documento de especificación, no es ni de lejos lo que en verdad importa. Es mucho mejor un caso de uso sencillo pero que captura valor de negocio, que uno sofisticado que haga un uso abundante de las técnicas más esotericas de modelado.

, , , , , , , , , , ,

2 comentarios

Diagramas de Clase

De entre todos los tipos de diagramas UML, el más común y conocido es el diagrama de clases. Dicho diagrama ilustra una vista de los componentes estáticos del sistema, ya sean estos clases o módulos, indicando las relaciones entre estas y los atributos (datos) de las clases, así como sus métodos (código).

El diagrama de clases puede ser utilizado para presentar la vista estática del modelo de dominio, del modelo de diseño, o bien, del detalle de la implementación de un sistema en un lenguaje de programación orientado a objeto, como Eiffel, Java o C++. Para todos estos usos, lo que se desea es expresar las unidades en que el código se organiza -las clases- así como algunas características de estas, notablemente como dije antes, sus relaciones, atributos y métodos.

Es valido combinar los diagramas de clase con paquetes, dando lugar a un diagrama que muestra simultáneamente clases y paquetes. Dicha práctica ayuda a documentar elementos que estén en distintos paquetes pero que guarden alguna relación, aún cuando la especificación de UML habla de diagramas de tipos diferentes para los paquetes y las clases.

En este blog se encuentran muchos ejemplos de diagramas de clase, ya que se han incluido en los post que lo requieren como parte del asunto tratado. Algunos de estos son:

Por lo anterior, si se queiren ver ejemplos de un diagrama de clases, basta con dar un paseo por el blog, seguro encontrará muchos ejemplos apropiados.

, , , , ,

2 comentarios

Diagrama de definición de Elemento: UML::Classes::Kernel::Root

UML es un lenguaje de modelado capaz de describir sistemas como conjuntos de elementos y relaciones. Esta forma de describir sistemas es lo suficientemente potente como para poder describir las nociones del propio lenguaje UML como un conjunto de elementos y relaciones.

Como ejemplo de lo anterior podemos tomar el diagrama UML::Classes::Kernel::Root, parte del metamodelo de UML, en el cual se describe la noción de Elemento, en termino de sus relaciones con otros conceptos. Dicha descripción se presenta como un diagrama de clases convencional.

Fig. 1 – Descripción del concepto “Elemento” de UML
(Diagrama UML::Classes::Kernel::Root del metamodelo de UML)

Esta forma de definir los conceptos del lenguaje UML recurriendo a los propios mecanismos del lenguaje es conocido como Metamodelado y es uno de los puntos fuertes del lenguaje UML. Ahora, con el diagrama en mano, podemos ver los detalles del concepto de elemento simplemente leyendo las relaciones presentadas en el diagrama.

Por ejemplo, se deja ver en el diagrama que:

  • Un elemento puede tener cualquier número de comentarios. Cero, uno o más.
  • Un elemento puede o no, tener un dueño. En caso que lo tenga será único.
  • Un elemento puede ser dueño de cualquier número de elementos.
  • Las relaciones y comentarios son elementos a su vez.
  • Las relaciones tienen un tipo especializado: las relaciones dirigidas. Estas tienen un elemento de origen y otro de destino.
  • El origen y el destino de una relación dirigida puede ser el mismo elemento.

Entre otros posibles puntos mostrados en el gráfico.

, , , ,

3 comentarios

Casos de Uso: Flujos de Eventos

Un caso de uso es un escenario de interacción entre el sistema y un ente externo; es decir: es la descripción de una funcionalidad del sistema, visto desde el punto de vista de un ente externo que demanda dicha funcionalidad.

Al ente externo le llamamos actor por cuanto un caso de uso puede ser visto también como un guión, que a la manera de los guiones de una obra de teatro, dice paso a paso lo que el actor ha de hacer.

Es mucho lo que podemos decir de un caso de uso: nombre, descripción, pre condiciones, etc. Sin embargo, el aspecto más interesante de un caso de uso luego de la descripción del mismo es sin duda el flujo de eventos.

Al flujo de eventos lo podemos relacionar con un dialogo. Línea a línea, el flujo de eventos indica quien habla y qué dice. La secuencia se suele iniciar con algo dicho por el actor, y se continua intercalando sucesivamente lo hecho por el sistema con lo dicho por el actor. A cada una de estas líneas o indicaciones, le podemos llamar paso.

Un buen flujo de eventos recoge con detalle la identidad de quien realiza el paso, expresando sin ambigüedad la acción realizada. Es decir, que un buen paso ha de ser siempre una oración con sentido completo, escrita en voz activa, iniciando con el nombre del actor o bien del sistema que realiza la acción e indicando exhaustivamente los elementos de información que se intercambian.

Dichas oraciones con sentido completo, sin ambigüedad y demás características ya mencionadas, no son difíciles de redactar. Son de hecho la forma más directa de decir lo que hay que decir. Y es que a la hora de redactar un flujo de eventos debemos evitar recurrir a formas de redacción en prosa típicas de nuestros textos comunes. No vale sustituir el nombre del actor por un pronombre o demostrativo que le haga referencia. A la larga, dicha omisión del nombre del actor va a ser una fuente de ambigüedad y nos puede traer problemas.

Si bien para quienes acostumbran a redactar con estilo, estas normas para los flujos de eventos pueden sonar extrañas, son normas muy comunes para cuando queremos redactar documentos de requisitos. Básicamente estamos aplicando aquí los mismos consejos que se dan para redactar bien un requisito tradicional, del estilo “el sistema debe…” por lo que en Internet abundan los detalles sobre este particular.

Finalmente, la prosa tiene su refugio en la descripción breve de un caso de uso; y dado que es esta descripción breve la parte más importante del caso de uso, podemos decir que a la final todos vamos a poder estar contentos. Quienes quieren una redacción con estilo van a encontrar lo que buscan en la descripción breve y quienes necesitan los detalles operativos del caso de uso lo van a encontrar en los pasos del flujo de eventos.

, , , , , , , , ,

5 comentarios