Archivos para 27 junio 2008

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)

, , , , , , , , ,

7 comentarios

Definimos Pruebas de Ciclo de Negocio como…

La mayor parte de los sistemas de información modernos son concebidos como un apoyo para un proceso de negocio bien definido de la organización. Por lo mismo, en ocasiones es necesario reproducir un ciclo de negocio completo para poner a prueba la funcionalidad de un sistema. El reto surge cuando el ciclo de negocio a probar es extenso en el tiempo, digamos que debido a que ciertas fases de él solo se ejecutan en ciertas épocas del año. Un ejemplo de esto sería un sistema de administración o contabilidad, el cual solo emitirá planillas de pago de impuesto una vez al año.

En tales circunstancias, es necesario crear un procedimiento de prueba que abarque el ciclo de negocio completo, pues de otro modo no será posible cubrir el sistema entero.

Los procedimientos de pruebas de ciclo de negocio deben necesariamente venir acompañados de conjuntos de datos completos, preparados por expertos en el área relacionada, de manera de poder alimentar al sistema apropiadamente a lo largo del periodo simulado.

Veamos entonces la definición ya un poco más formal, de prueba de ciclo de negocio:

Prueba de Ciclo de Negocio Procedimiento de prueba que evalúa el sistema a lo largo de todo un ciclo completo de negocio, generalmente un año fiscal u otra unidad de tiempo similar. Se acompaña con todos los procedimientos necesarios para evaluar en poco tiempo lo que de normal ocurre a lo largo de un periodo de tiempo extenso.

Por otra parte, dado que como parte del procedimiento de pruebas se puede llegar al punto de alterar la fecha de los sistema de computo, es necesario que en la especificación del ambiente de prueba se hayan señalado recursos para la restauración de estos, ya que en su mayoría, las computadoras no aceptar bien el tener una fecha en el futuro hoy y mañana tenerla en el pasado. Los licenciamientos y el seguimiento de fechas de diversos sistemas no directamente relacionados con el sistema que probamos pueden presentar problemas y hacer más difícil de interpretar los resultados de las pruebas.

, , ,

Deja un comentario

Selección de Artefactos de Requisitos

Dado que son muchos los posibles artefactos a incluir en un proyecto, es imperativo el desarrollar una visión de conjunto que nos permita escoger solo aquellos que son realmente capaces de otorgar valor al desarrollo. Esto es, necesitamos tener una visión o mapa estructural de todos los artefactos, para luego saber cual incluir en el desarrollo y cual dejar por fuera.

En este artículo analizaremos los artefactos de la disciplina de requisitos.

Primero tenemos los documentos básicos: El Documento de Visión del Sistema y El Glosario de Requisitos. Estos documentos son tan importantes que simplemente los tendremos siempre en nuestros desarrollos. En ellos tendremos el vocabulario del cliente así como la captura de las necesidades y las características de alto nivel de la solución propuesta. Ambos forman una suerte de paraguas que cobija a los restantes artefactos del proceso, tanto si son de requisitos como si son de otras disciplinas.

Para el resto de los artefactos de requisitos tenemos tres enfoques: el tradicional, los casos de uso y el dual o mixto.

El enfoque tradicional esta representado por el documento de Especificación de Requisitos del Sistema, que contiene los requisitos en un formato estilo “el sistema debe…”. En este enfoque, no dividimos los requisitos en funcionales y no funcionales, por lo que nos basta con un solo documento.

Por otra parte, en el enfoque de casos de uso, es necesario contar con algún tipo de documento para capturar los requisitos no funcionales, ya que los casos de uso como es sabido por todos, solo nos ayudan con los requisitos funcionales. El rol del documento de Requisitos Suplementarios es justamente este: complementar los casos de uso y documentar cualquier requisito no funcional al lado de cualquier requisito funcional que sea general a todo el sistema.

El ultimo enfoque es el dual. Es simplemente mantener tanto un documento tradicional de requisitos como un modelo de casos de uso. En este enfoque surge un nuevo artefacto: El Cruce de Requisitos; con cuya ayuda mantendremos el control de la duplicidad de cada requisito: una vez en el documento de especificación y otra en el modelo de casos de uso.

El siguiente diagrama muestra las relaciones entre estos artefactos, organizados en lo que llamamos un Artifacflow o Flujo de Artefactos. En este diagrama vemos la forma en que la información viaja desde la visión hacía los restantes documentos. Los rombos representan las decisiones que tomamos durante la creación del Caso de Desarrollo y el criterio de decisión.

Fig. 1 – Flujo de Artefactos de la Disciplina de Requisitos

Las decisiones son simples de plantear, aunque no necesariamente fáciles de contestar. ¿Debemos utilizar casos de uso o un enfoque tradicional? ¿Quizás debamos optar por el enfoque mixto? Finalmente, de utilizar casos de uso ¿vale la pena mantener un documento de requisitos suplementarios? ¿No es todo esto simplemente mucho trabajo?

La verdad es que si es un proyecto pequeño, tomar todos los artefactos es demasiado. De hecho, en un proyecto pequeño lo mejor es aprovecharse de un detalle interesante: en ciertas condiciones los artefactos se pueden combinar.

Un ejemplo de esto es el Documento de Visión. Dado que este incluye secciones suficientes para documentar requisitos no funcionales y considerando también que podemos hacer un anexo que cubra el glosario, es simple obtener un conjunto de artefactos combinados que resulten apropiados para un proyecto pequeño.

La situación es planteada en el siguiente diagrama:

Fig. 2 – Flujo de Artefactos de la Disciplina de Requisitos
para un Proyecto Pequeño

En el caso planteado, es de esperar que los costos de construir y mantener estos artefactos sean mucho menores que en el caso de tener documentos separados. Así que han de resultar mucho más adecuados para un proyecto de pequeñas dimensiones.

, , , , , ,

2 comentarios

El Ciclo de Vida: Objetivos de Fase

Cada Fase del Ciclo de Vida debe terminar cuando se alcanzan un conjunto bien identificado de objetivos, definidos en términos de productos concretos o eventos acordados con los stakeholders. Según lo que se haya indicado en la planificación del proyecto durante la Fase de Concepción.

Esto es, llamamos Objetivos del Ciclo de Vida a las metas concretas que marcan el éxito de una fase, según lo que se haya planificado inicialmente.

Según la fase del proyecto en la que nos encontremos, los objetivos van a ser diferentes. Algunos ejemplos son:

  • Objetivos del Ciclo de Vida de la Fase de Concepción: Documento Visión, Modelo de Casos de Uso, Documento de Requisitos Suplementarios.
  • Objetivos del Ciclo de Vida de la Fase de Elaboración: Documento de Arquitectura del Sistema, Prototipo de Interfaz de Usuario, Prototipo Técnico de la Arquitectura del Software.
  • Objetivos del Ciclo de Vida de la Fase de Construcción: Versión Beta del Software en ejecución en ambiente de pruebas, Documentación de Usuario, Soporte de Entrenamiento de Usuarios, etc.

Un objetivo del ciclo debe ser concreto, verificable, planificado de antemano, bien conocido y aceptado por todos los stakeholders del proyecto. Veremos cada criterio uno a uno:

Concreto: Cada objetivo del ciclo de vida debe estar bien enunciado. No se aceptar definiciones vagas o que no se comprendan plenamente por todos los stakeholders involucrados. Se tienen por concreto a los artefactos del proceso cuando estos son aprobados por el cliente y este entiende el significado y rol técnico del producto que esta aprobando.

Verificable: Tanto el cliente como el equipo de Control de Calidad del Software van a estar interesados en comprobar que el objetivo se ha alcanzado. Esto es, la ocurrencia del evento debe poder ser observada por terceros de forma así de garantizar que el éxito en alcanzar el objetivo del ciclo de vida no es resultado de una evaluación subjetiva más sujeta al capricho o la premura que a la realidad.

Planificado: El objetivo de ciclo de vida es una meta; por lo que no puede ser alcanzado solo por casualidad. El objetivo ha de haber sido señalado como meta desde un principio y no puede en ningún caso, ser presentado como aquello que se ha salvado de un proceso malogrado de desarrollo. La planificación también es importante para permitir con el suficiente tiempo, la elaboración de estrategias de evaluación que permitan la verificación del objetivo.

Bien Conocido: El objetivo del ciclo de vida debe ser un artefacto o evento reconocido en el sector de desarrollo, de forma tal que exista un acuerdo profesional sobre lo que este significa y de los eventuales criterios de aceptación y demás características del objetivo. Por ejemplo, el Documento de Visión es bien conocido ya que esta difundido en la profesión el contenido esperado de este documento así como en el propósito que persigue.

Aceptado: Todos, tanto los clientes como los desarrolladores, deben haber aceptado el objetivo del ciclo de vida y sentir compromiso por conseguirlo. El objetivo de ciclo de vida debe ser aceptado como un elemento que señala un avance significativo del proyecto que aporte valor real al desarrollo y que debe ser apoyado y buscado con energías. Esto debe ser algo sincero, ya que un objetivo del ciclo de vida no puede ser percibido como un alcabala o requisito burocrático: muy por el contrario, debe ser un artefacto o evento de valor para todos los involucrados.

, , ,

1 comentario

Definimos Caso de Uso como…

Hoy en día los casos de uso son la principal forma de capturar los requisitos de los proyectos de desarrollo de software; y de ahí por tanto que sean el lugar de inicio más común para los libros que explican métodos de desarrollo. Sin embargo son también quizás, el concepto peor entendido de todos, probablemente por su sencillez y por estar enfocado a su tarea de modelar requisitos pero dejar poco lugar para nada más.

Formalmente, para el glosario:

Caso de Uso Escenario que narra la interacción entre un sistema y una entidad externa a la que se le provee una funcionalidad. Los casos de uso son principalmente cuerpos de texto de definición de requisitos funcionales aunque por medio de extensiones pueden ser utilizados por fuera de este ámbito.

El lenguaje UML incluye en su especificación el soporte para los casos de uso, permitiendo representar por medios visuales diversas características de estos; complementando así lo indicado en las especificaciones en formato texto de cada caso de uso.

Considerando que los sistemas de información modernos son altamente interactivos, tanto por su relación con múltiples operadores humanos como por su necesidad de integrarse e interactuar con otros sistemas, es necesario entonces que los requisitos sean capturados respetando esta naturaleza interactiva. Es decir, si bien antes nos bastaba preguntar qué debe hacer el sistema ahora es necesario agregar para cada uno de sus usuarios.

Por sencillez, llamaremos actor a cada operador externo, tanto si es un sistema aparte del nuestro como si se trata de un operador humano.

Con el enfoque de los casos de uso, el sistema luce diferente para cada uno de sus actores. A unos, la funcionalidad que ofrece serán la que se corresponde con su trabajo, en tanto que a otros, será la que corresponda con la necesidad de estos. Esta organización de la funcionalidad según el punto de vista de cada actor es clave para poder capturar rápida y efectivamente, los requisitos funcionales de un sistema altamente interactivo.

En su conjunto, los casos de uso constituyen el llamado Modelo de Requisitos Funcionales el cual puede ser complementado con documentos que detallen Requisitos No Funcionales en una forma más tradicional. Es responsabilidad del Analista de Requisitos el construir y el mantener estos artefactos.

El Modelado de Casos de Uso es hoy por hoy, la principal técnica de captura de requisitos funcionales, y es una pieza central en los procesos de desarrollo de pruebas, de la interfaz hombre-maquina, de la documentación de usuario y manuales así como de guiar el análisis y diseño de la solución técnica del desarrollo. Es decir, que el proceso de desarrollo se encuentra centrado en casos de uso.

Si bien los casos de uso pueden ser manejados en forma gráfica, con ayuda de los diagramas de caso de uso del lenguaje UML, la información total que estos contienen va mucho más allá. Entre las propiedades de los casos de uso se encuentran los flujos de eventos, las pre condiciones, los puntos de extensión y muchos más elementos, solo posibles de ser representados con ayuda de un documento de texto. En este blog, podrá encontrar un ejemplo completo.

, , , , , , ,

11 comentarios

Prácticas: Seguimiento y Control de Proyectos

El propósito del Seguimiento y Control de Proyectos es el de proveer una visión objetiva del estado actual del proyecto y determinar las posibles desviaciones a fin de tomar las correcciones del caso. Es en este sentido en el cual le llamamos Seguimiento a la evaluación rutinaria del estado en tanto que llamamos Control a la toma de los correctivos.

Esta práctica guarda intima relación con la Planificación de Proyectos tal como cabe esperar, ya que solo donde la planificación se encuentra correctamente documenta es posible verificar su cumplimiento.

El producto mínimo de esta práctica es el Cierre de Iteración, un documento o artefacto, donde anotamos los resultados de la evaluación de una iteración; de momento sin decir las correcciones a tomar.

Una vez determinada las desviaciones, es necesario que el equipo determine oportunamente la corrección requerida y la lleve a cabo durante la siguiente iteración o en el momento en que sea oportuno. Finalmente es necesario que la corrección planteada sea a su vez, objeto de seguimiento – lo que implica que la planificación debe ser actualizada para que refleje las acciones que se han determinado necesarias para corregir la desviación.

A la hora de realizar las reuniones de seguimiento del proyecto, es útil contar con unos momentos para discutir y revisar el Plan de Riesgos, a fin de verificar la ocurrencia de alguno de estos eventos negativos; además – si bien es una práctica avanzada – debe considerarse la posibilidad de calcular alguna forma de medida o métrica que aplicada al proyecto de desarrollo sirva de indicador sobre el estado del mismo. Esto con el objeto de obtener una evaluación lo más completa y objetiva posible de la salud del proyecto.

Otros factores que deben ser objeto de seguimiento incluyen el presupuesto en tiempo y dinero del proyecto y el cumplimiento de los hitos señalados como objetivos del ciclo de vida.

, , , , , ,

7 comentarios