1. Control de Versiones
A continuación se recoge la forma en que controlaremos las diversas versiones de los documentos que generemos.
El control de versiones del proyecto se efectuará de la siguiente forma:
- La primera versión de cada documento se nombrará 1.0
- Cuando exista un cambio que implique una revisión completa del documento, el número de versión pasará al número entero superior al último existente.
- Cuando se trate de pequeños cambios sobre los documentos se sumará 0.1 o 0.01 (dependiendo de la importancia del cambio) a la última versión conocida del documento.
La plantilla a utilizar será la siguiente:
Nombre de Documento | |||
---|---|---|---|
Parte | Nº Versión | Autores | Revisión |
XXX | X.X | XXX | XXX |
XXX | X.X | XXX | XXX |
XXX | X.X | XXX | XXX |
XXX | X.X | XXX | XXX |
Fecha de Creación: | XX / XX / XXXX | Fecha de Modificación: | XX / XX / XXXX |
La columna parte corresponde con la parte del documento que se modificará. La columna Nº Versión corresponde con la versión correspondiente a cada parte del documento. Los autores corresponden con las personas que han realizado cada parte. Por último la revisión, son las personas que han realizado dicha revisión al documento.
2. Control de Cambios
A continuación se recoge la forma en que controlaremos los diversos cambios realizados en los diferentes documentos, el motivo de dicho cambio y la nueva solución adoptada.
El control de cambios del proyecto se efectuará de la siguiente forma:
- Nombre del Documento afectado.
- Nombre del Proyecto.
- Elemento afectado en el cambio.
- Fecha del cambio.
- Fecha en la que se descubrió el problema y una pequeña descripción de explique dicho problema.
- Mostraremos el impacto producido dicho cambio sobre la planificación y sobre otros elementos de configuración del software.
- La solución adaptada para dicho cambio.
- Documentos en los que se encuentra dicha modificación debido al mismo problema.
La plantilla a utilizar será la siguiente:
Documento de Control de Cambios | |
---|---|
Nombre del Documento - Versión | Nombre del Proyecto |
XXX | XXX |
Elemento de Configuración del software afectado | Fecha Actual |
XXX | XX / XX / XXXX |
Fecha de detección del problema: XX / XX / XXXX | |
Breve descripción del problema: XXX | |
Impacto del problema sobre la planificación y otros ECS: XXX | |
Solución de cambio adoptada: XXX | |
Anexos a este documento: XXX |
3. Tipos de Documentos
Los tipos de documentos que vamos a entregar son:
- Documento de planificación
- Documento de especificación inicial
- Documento de especificación de requisitos
- Documento de Modelado estático
- Documento de Modelado dinámico
- Documento de pruebas
Documento de planificación.
Este documento contendrá los siguientes puntos:
- Declaración del alcance
- Objetivos
- Funciones
- Rendimiento
- Fiabilidad
- Interfaces
- Restricciones
- Determinación de recursos
- Recursos humanos
- Recursos software
- Recursos hardware
- Estimación de costos
- Basándose en hechos históricos
- Basándose en descomponer en subtareas
- Planificación organizativa
- Planificación temporal
- Documentos y control de versiones
Documento de especificación inicial.
Este documento contendrá los siguientes puntos:
- Entrevista con el cliente
- Recursos funcionales
- Recursos no funcionales.
Podrán entregarse todos en un mismo documento, o bien separando las distintas entrevistas.
Documento de especificación de requisitos.
Este documento contendrá los siguientes puntos:
- Recursos funcionales del prototipo.
- Recursos no funcionales del prototipo.
- Identificación de actores y acciones.
- Diagrama de casos de uso.
- Especificación de casos de uso.
- Diagramas de secuencia.
Documento de Modelado estático.
Este documento contendrá los siguientes puntos:
- Lista de principales clases y atributos.
- Diagrama de clases inicial.
Documento de Modelado dinámico.
Este documento contendrá los siguientes puntos:
- Operaciones del sistema.
- Contratos de operaciones del sistema.
- Diagramas de colaboración.
- Diagramas de Transición de Estados.
Documento de pruebas.
Para llevar el control de las pruebas e intentar depurar y eliminar el mayor número de errores de nuestra aplicación, se genera este documento que tendrá la estructura:
- Introducción
- Objetivos.
- Descripción de las pruebas a realizar.
- Pruebas de conexión con la base de datos.
- Inspecciones del software.
- Pruebas basadas en requerimientos.
- Pruebas de particiones.
- Pruebas estructurales.
- Pruebas reales.
4. Estandarización de la Documentación
Los documentos creados a lo largo de todo el proyecto seguirán un estándar, manteniendo todos ellos la siguiente estructura:
- La primera página de cada documento contiene la portada que estará compuesta por el nombre del proyecto, el nombre del documento correspondiente y los miembros que realizan el proyecto.
- La siguiente página se corresponde con el documento de versiones. En ella se indica la versión de cada una de las partes del documento.
- Las siguientes páginas corresponden con los documentos de control de cambios. En cada uno de los documentos se indican las modificaciones, inserciones y eliminaciones que se producen a lo largo de todo el documento. Se muestra el problema, el impacto sobre la planificación, los cambios realizados y los ficheros modificados. Esta parte podrá estar, o no, separada del resto en otro documento aparte.
- La página que continúa es el índice. En él se hace referencia a los epígrafes más importantes del documento mostrando la página donde se encuentran para una localización más rápida.
- Las siguientes páginas ya representan al documento en sí.
Los documentos se componen de varias partes o temas que iremos nombrando a través de un número.
Por ejemplo:
3. Diagrama de Casos de Uso.
4. Casos de uso detallados y Diagramas de Secuencia.
Cada parte se puede dividir en varias subpartes, que las iremos nombrando a través de un número decimal que contiene el número de la parte y el número de la subparte.
Por ejemplo:
4.1 Caso de Uso y diagrama de Secuencia Abrir sistema.
4.2 Caso de Uso y diagrama de Secuencia Cerrar sistema.
La letra utilizada en los títulos de las partes y las subpartes es la “Century” y dependiendo del nivel del título, el tamaño de letra variará.
En caso de que sean necesarias más divisiones en partes, los títulos se realizarán con otro tipo de letra (“Viner Hand ITC”) y poniendo las letras en mayúscula.
En caso de que sea necesario desarrollar estructuralmente algún punto en concreto (como por ejemplo pueden ser los casos de uso detallados o los contratos), éste utilizará tanto para el título como para el cuerpo la letra “Courier New”.
El cuerpo de cada una de las partes, subpartes, etc. están escritas con la letra “Times New Roman”.
Todas las páginas irán numeradas empezando desde la portada con el número 1.
Estandarización de Casos de Uso
Los casos de uso que se realicen se amoldarán a la siguiente plantilla:
CASO DE USO: Nombre del caso de uso.
IDENTIFICADOR: Identificador corto y único del caso de uso.
ACTORES: Actores que interactúan con el caso de uso.
VERSIÓN: Número de versión actual.
DESCRIPCIÓN: Descripción de lo que representa el caso de uso.
ESTADO: Estado del caso de uso: en desarrollo, preparado para revisión, revisado, etc.
FRECUENCIA: Frecuencia de uso: muy alta, alta media, baja o muy baja.
PRECONDICIONES: Lista de precondiciones que se cumplirán para la realización del caso de uso.
CASOS DE USO QUE EXTIENDE / ES EXTENDIDO POR: Casos de uso con los que tiene relación “extend”.
CASOS DE USO QUE INCLUYE: Casos de uso con los que tiene relación “incluye”.
SUPOSICIONES: Cualquier suposición que se haya realizado cuando se redactó el caso de uso, ya sea del sistema o del entorno (externas al sistema).
CURSO NORMAL DE EVENTOS: Lista en orden cronológico de los eventos que genera el caso de uso.
CURSO ALTERNATIVO DE EVENTOS: Lista de los eventos alternativos a algún evento del curso normal de eventos.
POSTCONDICIONES: Estado de interés en el que queda el sistema.
HISTÓRICO DE CAMBIOS: Detalles sobre quién modificó el caso de uso, cuando y porqué.
En caso de que algún apartado esté vacío, éste no se mostrará.