Entradas etiquetadas como plantillas rup

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

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

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)

, , , , , , ,

5 comentarios

Plantillas: Documento de Arquitectura del Sistema

La mejor forma de documentar la arquitectura de un sistema intensivo en software es la combinar en un mismo documento, tanto los detalles del diseño en UML como los detalles relacionados con la implementación en código del proyecto. Aspectos tales como la vista del modelo de datos o el esquema de paquetes pertenecen al primer grupo, en tanto que el lugar donde se puede conseguir el código y la estructura de directorios que se genera con este, son puntos a tratar en el segundo bloque.

Por otra parte, es necesario enlazar con los requisitos, de ser posible con los casos de uso, ya que de esta forma se deja en claro que parte del sistema se ha cubierto con la arquitectura que se pretende documentar.

Y de primero claro, podemos discutir el posicionamiento de la arquitectura, quizás indicando los principios de diseño que guiaron el desarrollo.

Finalmente, adjunto la plantilla del Documento de Arquitectura del Sistema:

Arquitectura del Sistema(Plantilla)

Si tiene problemas con esta plantilla y quiere tener algunas sugerencias sobre características deseables en un documento de arquitectura del sistema, tengo un post sobre la lista de Michael Stal que le puede resultar útil.

, , , , , , , , ,

1 comentario

Plantilla: Glosario del Sistema

Ya había comentado sobre la importancia de mantener un documento llamado Glosario, que sirva para capturar el vocabulario en uso en un proyecto. No solo para la muy vital misión de tener un vocabulario común con el cliente, sino también para otras tareas, como el análisis gramatical y la construcción de un Modelo de Dominio.

Similar en su estructura a un diccionario, el glosario contiene entradas con sus acepciones así como las relaciones de interés entre palabras; notablemente: los sinónimos y los homónimos.

Siendo como es, un documento muy sencillo, la plantilla que presentamos aquí tiene solo seis páginas. Donde cinco de ellas son heredadas de la estructura definida por la plantilla Documento del Proceso y solo una es propiamente el esquema para construir nuestro glosario.

Ahora bien, recordemos que todos los documentos del proceso tienen un anexo llamado Glosario, es preciso explicar que las definiciones con sus detalles solo las hacemos en este documento expresamente destinado a recoger el vocabulario del proyecto, en tanto que en aquellas secciones de los demás documentos podemos hacer un extracto de las definiciones aquí contenidas. Este extracto puede incluso, prescindir de las acepciones y en tal caso, nos llevaríamos solo las palabras que es preciso interpretar en forma especial; es decir, las palabras que hay que buscar en el Glosario.

Por otra parte, es posible hablar de un Glosario de Requisitos por oposición a un Glosario de Diseño o un glosario de cualquier otro aspecto del proyecto. Esto surge cuando hemos desarrollado documentos separados para cada aspecto, algo que tiene sentido en algunos proyectos grandes.

Glosario del Sistema(Plantilla)

, , , , , , , , , ,

1 comentario

Plantillas: Documento de Visión del Sistema

Uno de los primeros objetivos de todo proceso de desarrollo, no importa cuan formal o informal puede ser, es el de desarrollar una visión clara sobre el producto deseado, el proceso en si, y las necesidades que se van a cubrir con el proyecto. Esto es, una de las primeras tareas es la de Desarrollar una Visión del Sistema.

El producto básico de esta tarea es un documento bastante concreto y bien conocido por todos: El Documento de Visión del Sistema; cuya plantilla adjuntamos aquí.

La versión que presento es apropiada para proyectos de tamaño pequeño. Si bien tiene la típica estructura de un documento de visión (identificación de stakeholders, necesidades, macro características, características) no se queda ahí, sino que presenta suficientes secciones de requisitos adicionales como para poner en duda la utilidad de un documento separado de Requisitos Suplementarios.

Por lo mismo también, es apropiada para proyectos grandes: entre todas sus secciones se cubren todas las bases; permitiendo que no quede angulo del proyecto sin ser considerado. Por otra parte claro, para aquellas secciones donde el soporte no sea suficiente, siempre nos es posible desarrollar un documento más detallado más adelante en el proceso; por ejemplo, un Plan de Control de Calidad más detallado.

Recuerde desarrollar también un Glosario y naturalmente, alguna forma de capturar sus requisitos más en detalle. Si tiene dudas, siempre puede revisar mi selección de artefactos para la disciplina de requisitos.

Visión del Sistema (en PDF)

Visión del Sistema (en iScribd)

, , , , , , , , ,

6 comentarios

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.