Archivo para la categoría Artefactos

Definimos Terminos de Referencia como…

De tanto en tanto nos vamos a encontrar con que la organización que requiere el desarrollo elabora para nosotros un documento de requisitos, en formato libre, al que llaman no sin cierto orgullo “Términos de Referencia”. La práctica viene de otras áreas de la ingeniería donde una petición simple de parte del cliente puede ser analizada y convertida en un trabajo completo, con un razonable nivel de calidad.

Sin embargo, en Ingeniería del Software los términos de referencia no pueden ser utilizados con buenos resultados. Típicamente son documentos incompletos, que mezclan requisitos con análisis e incluso con diseño, cuya existencia es señal de acceso limitado a los stakeholders por parte de la organización de desarrollo. En otras palabras: si nos dan Términos de Referencia tendremos problemas más adelante.

El acto de especificar un sistema de software a demostrado repetidamente ser difícil. Es necesario indicar un gran número de aspectos distintos, mantener la diferencia entre requisito y solución, actuar primero a lo ancho, capturar valor de negocio, entre otros puntos que son propios de nuestra profesión y que resultan incompatibles con las premisas detrás de un documento de términos de referencia.

Veamos algunos de estos puntos en detalle. Comencemos por la definición:

Términos de Referencia: Documento elaborado por el cliente con indicaciones de las especificaciones requeridas al sistema de software por desarrollar.

En otras palabras: en un documento de Términos de Referencia el cliente ha querido ahorrarnos a nosotros el trabajo de especificación. Muy amable de su parte, pero si la organización de desarrollo no interviene en la especificación entonces nos enfrentamos a varios problemas:

  • Se ha asumido un modelo de ciclo de vida en cascada. Los modelos actuales son iterativos, repitiendo múltiples veces el paso de especificación. Un esquema más rígido, como el cascada, suele incrementar el riesgo de fracaso del proyecto.
  • Si el cliente siente que ya ha desarrollado los requisitos a satisfacción puede verse renuente a dedicar esfuerzos nuevos en este asunto. Tendríamos entonces problemas al presupuestar horas para actividades de elicitación de requisitos.
  • El documento en si mismo es un problema. Su estructura es necesariamente ad-hoc, independiente de la metodología que se vaya a seguir en el desarrollo. Puede ser difícil de analizar y haber dejado puntos importantes por fuera.

Si solo fuera para tener una idea del proyecto, básicamente cualquier documento o carta es bueno. Sin embargo los términos de referencia vienen con intenciones más amplias: sustituir la especificación profesional por un único documento, valido para el desarrollo así como para el cálculo de la oferta económica. No importa como lo vea, los términos de referencia son un problema.

Sin embargo, los Términos de Referencia son también un hecho. En algunas situaciones incluso son lógicos: en las licitaciones se distribuyen especificaciones para acto seguido requerir ofertas de costo cerrado. Si esto funciona bien en tantos sectores distintos, el cliente puede pensar que ha de valer también para sus proyectos de software.

Por lo anterior será inevitable que nos topemos con estos documentos. Tendremos que desarrollar entonces alguna técnica para sacar el mayor provecho de los mismos, sin importar cuan diferentes sean de caso en caso y de cliente en cliente. A fin de cuentas ellos son el cliente, y uno no puede ser tan descortez de desachar los resultados de su trabajo.

Finalmente me gustaría recordar que todos sin excepción hemos luchado con los términos de referencia de nuestros profesores y preparadores. ¿Cuantas veces en nuestros estudios tuvimos que llevar a cabo un proyecto a partir de un breve enunciado carente de toda norma de calidad? Así como entonces fue difícil producir un programa autenticamente útil a partir de dichas especifiones, aquí nos va a costar mucho trabajo en conseguir satisfacer el cliente si nos atenemos unicamente a lo dicho en los malvados, digo, en los variables Términos de Referencia.

Anuncios

, , , , , , , ,

3 comentarios

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

Tipos de Diagramas en UML

Grandes clásicos conocidos por todos, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación de los diagramas.

La siguiente figura UML muestra los tipos de diagramas:

Fig. 1 – Tipos de diagramas en UML2

En su momento detallaré cada uno de los tipos de diagramas, lo importante por ahora es señalar que existen dos grandes grupos: estructurales y de comportamiento; esto conforme a lo dicho sobre la presentación de modelos en UML.

Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como de las instancias u objetos que lo integran.

Por otra parte, en la figura se ve que hay tres tipos de diagramas señalados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. También aspiro a tener una descripción de ellos en los días por venir.

Hay que tener en cuenta, que cada diagrama sirve para documentar un aspecto distinto del sistema; el criterio para usarlos es el de tener algo que decir, una historia sobre nuestro sistema que debe ser contada; el tipo de diagrama que utilizaremos será el que nos dé mayor poder expresivo y solo muy difícilmente, la construcción de una serie de diagramas puede ser explicitamente ordenada por un método de desarrollo. Algunos sistemas simples serán bien documentados con pocos diagramas, en tanto que algunos sistemas grandes bien podrían beneficiarse de un conjunto mayor.

Entonces que valga la advertencia: no hacemos diagramas porque un método nos lo ordene, hacemos diagramas para contar algo importante de nuestro modelo, por lo que indicar que en un sistema haya que hacer tantos de tal o cual diagrama es una declaración objetable.

, , , , , , , , , ,

23 comentarios

Plantillas: Plan de Iteración

El Plan de Iteración recoge la planificación detallada de un periodo corto de tiempo dentro del proyecto – una iteración. Entre otras cosas, debe identificar las actividades, los riesgos involucrados, los artefactos a actualizar o crear, las necesidades de adquisición de bienes o servicios y los hitos esperados durante la iteración.

Adicionalmente, esta plantilla contiene los rudimentos para la evaluación regular y controlada de la calidad de los productos y del proceso: las pautas de evaluación indicadas en el plan de iteración sirven para este fin. Se complementa esto con los detalles de la evaluación contenidos en el artefacto de Cierre de Iteración.

El documento es una variación de la plantilla de reportes, por lo cual no contiene número de versión y se identifica solo por la fecha de emisión.

Finalmente, he aquí la plantilla:

Plan de Iteración(en PDF)

Plan de Iteración(en Scribd)

, , , , , , , , , , ,

2 comentarios

Modelo de Dominio

Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física.

Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el análista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir.

El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterraneo de una ciudad cualquiera.

Fig. 1 – Ejemplo de Modelo de Dominio de un sistema de subterráneo

En este diagrama se ve que un Usuario del Metro tiene cero o más boletos, comprados estos en una maquina de Venta de Boletos; dicha maquina “crea” los boletos los cuales son consumidos en un viaje, el cual tiene una estación de origen y otra de destino. Finalmente se ve que una estación tiene una o más maquinas de venta así como empleados de limpieza, seguridad y operaciones.

Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuanto detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseñando y esto demanda una cantidad distinta de detalles cada vez.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.

En la aproximación llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce como Modelo Independiente del Computador o CIM, por sus siglas en inglés. El CIM es el que da inicio al proceso de desarrollo y ocupa el rol, tanto de modelo de requisitos como de modelo análisis.

Por otra parte, cuando se sigue una aproximación Centrada en Casos de Uso como RUP/UP, el modelo de dominio es utilizado como entrada en la tarea análisis de los casos de uso en la construcción de los llamados escenarios de análisis.

Es decir, y con esto quiero concluir, que el modelo de dominio ocupa un rol protagonico en el desarrollo moderno de software y constituye un artefacto que vale la pena tener en nuestros proyectos.

, , , , , , , , ,

29 comentarios

Características que debe tener un Documento de Arquitectura

Encontré en el blog de Angel “Java” Lopez, una traducción de la lista de características de un buen documento de arquitectura del sistema que es traducción del trabajo de Michael Stal, bávaro de origen, quien nos dice las siguientes características:

  • Describa la arquitectura de arriba a abajo: presente la visión general primero, y luego vaya tratando cada uno de los puntos más en detalle, ya sea de diseño o implementación.
  • Agregue un glosario: algo que podemos olvidar, pero muchos términos serán desconocidos o confusos, o peor, serán mal entendidos por alguien que tenga un contexto distinto al nuestro.
  • Cada vez que introduzca un término que se conoce por una sigla, no presuma que todo el mundo sabe qué significa: coloque la sigla, y las palabras completas que describe.
  • Que no exceda las 50 páginas: si es más extenso, no será leído en detalle. Recuerde que muchas personas que lo lean serán personas con cargos de responsabilidad, que pueden no tener todo el tiempo del mundo para leer su obra maestra.
  • Todos los documentos de arquitectura que entregue, deben usar la misma plantilla: distintos tipos de letras y formatos entre documentos, confunden a los lectores. La estructura debe ser la misma para todos: si usa una tabla de contenido, un resumen, una conclusión en un documento, deberá usarse en todos.
  • Si usa diagramas, úselos consistentemente. Si para explicar un concepto usa UML, cuando tenga que exponer un concepto similar siga con ese tipo de diagrama. Y use los mismos elementos: si en un diagrama UML usó algunos estereotipos, siga usándolos cuando sean necesarios, con las mismas notaciones e íconos.
  • Agregue referencias a otros documentos que pueden ser importantes para entender algún concepto o explicitar una fuente consultada.
  • Explique siempre cómo la arquitectura descrita cumple con los requerimientos que se quieren alcanzar. Debe haber una trazabilidad desde los requerimientos a la arquitectura definida.
  • Coloque al comienzo un resumen: sea gentil con el lector, prepárelo para lo que va a encontrar. Por lo mismo, si un documento lleva varias páginas y abarca varios temas, incluya un índice. Si es necesario, describa los prerrequisitos que debe cumplir de antemano un lector que quiera entender el documento.
  • Si tiene que entregar varios documentos, estructure el conjunto como un árbol. El documento raíz describirá la arquitectura desde un punto de vista alto, estratégico. Desde ahí, los documentos nodos hijo irán explicando los subsistemas relevantes, y los elementos que atraviesan los demás, como seguridad y escalabilidad.
  • Describa la especificación de la arquitectura, y cómo esa especificación puede ponerse a prueba, como cuando programamos “unit tests”.
  • Compruebe que el documento acompañe, describa la implementación actual del sistema. Sino, será una pérdida de tiempo para quien lo lee, y hasta puede provocar errores, al tomar decisiones sobre una especificación que no corresponda con el producto actual.
  • Describa las decisiones de diseño en detalle, que no quede solamente la descripción de la decisión tomada, debe quedar claro que hubo una decisión en ese punto, por ejemplo, mencionando alguna alternativa.
  • Relacionado con lo anterior, no sólo describa el “cómo” sino también el “por qué”. Es importante que otra persona entienda las razones que llevaron a tomar un camino en el diseño.
  • Si se refiere a algún software entregado con el documento, o a utilizar, incluya la versión del mismo: no presuma que será evidente cuál es la versión a la que se refiere.
  • Agregue diagramas y dibujos para explicar las decisiones de diseño tomadas. Los diagramas llevan tiempo de armado, pero el resultado vale la pena.
  • Explique los diagramas: una imagen vale más que mil palabras, pero también hay que entenderla.
  • Pida que otras personas revisen el documento. Uno siempre escribe desde su propio contexto, y tal vez lo que a nosotros nos parece claro, para otro no lo sea. Trate que sea una persona que no esté en el mismo proyecto, para probar si el documento es entendible para alguien que no está al tanto de los conceptos tratados.
  • Use un sistema de control de versiones: no pierda la historia del documento.
  • Escriba los nombres del autor o autores, y forma de contactarlos, en caso de ser necesario. Incluya fecha y hora de versión.
  • No tiene que escribir todo el documento desde el principio al fin: vaya utilizando otros documentos menores que haya producido durante el proceso de discusión y diseño de arquitectura, pero asegúrese su consistencia. Recuerde: ¿cómo se come uno un elefante? Bocado a bocado.
  • No necesita explicar el sentido de cada patrón usado: remita su descripción a la literatura especializada.
  • Como en todo documento, sea consistente en el uso de los tiempos verbales, el uso o no de la forma pasiva, la forma de usar pronombres, si “dialoga” o no con el lector, el uso de la primera o tercera persona.

Pienso que muchas de estas características valen también para los restantes documentos del proceso. Después  de todo, la claridad, la consistencia, el formato legible, el buen uso del lenguaje, el buen uso del UML, entre otras cosas son puntos que se toman en cuenta durante una Revisión de Forma y definitivamente tiene impacto en la calidad del documento.

Para ser justo con mis propios documentos, aprovecho para apuntar que ya varios de estos consejos se habían considerado en la progresión de documento en blanco y documento del proceso (véa también la segunda parte), por lo que hasta donde puedo ver, mi propia plantilla de arquitectura del sistema cumple con estas ideas.

, , , , , , ,

1 comentario

Plantillas: Plan de Desarrollo de Software

Técnicamente, el Plan de Desarrollo de Software es un compendio de los distintos planes que son necesarios para ejecutar un proceso de desarrollo. Es decir, que en proyectos de tamaño pequeño o mediado, este documento tendrá muchas secciones con información sobre la gestión del proceso, en tanto que en un proyecto grande, lo que tendrá será muchas referencias a todos los planes independientes que se hayan desarrollado.

Ahora bien, que dado que el documento en si mismo esta bien documentado y lleno de comentarios, considero que basta con colocar la plantilla para que se entienda su propósito. Con todo, es posible mencionar aquí que este documento es el centro de la práctica Planificación de Proyectos y junto con los planes de iteración, de la práctica Seguimiento y Control de Proyectos.

Finalmente, como ya había dicho, la plantilla del documento:

Plan de Desarrollo de Software(en PDF)

Plan de Desarrollo de Software(en iScribd)

, , , , , , ,

6 comentarios