INVENTARIO DE LOS DOCUMENTOS QUE SOPORTAN LOS PROCESOS DE LA GUÍA METODOLÓGICA Autores: JOHN EDDIE DÍAZ AGUDELO JUAN FELIPE OLAYA FIGUEROA Dirección: MARIA CONSUELO FRANKY PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2010
TABLA DE CONTENIDO 1. INTRODUCCIÓN... 4 2. DOCUMENTOS DE LOS PROCESOS QUE FORMAN PARTE DE LA GUÍA METODOLÓGICA... 5 2.1. PROCESO 1: ANÁLISIS DE REQUERIMIENTOS Y CASOS DE US0... 6 2.1.1. DIAGRAMA DE CASOS DE USO... 6 2.1.2. FORMATO HACER&USOS... 7 2.2. PROCESO 2: PLANEACIÓN DEL DESARROLLO DEL PROYECTO... 7 2.2.1. CONTRATO SEGUNDA FASE DEL PROYECTO... 7 2.2.2. SPMP - SOFTWARE PROJECT MANAGEMENT PLANS (Versión )... 8 2.3. PROCESO 3: ARQUITECTURA Y DISEÑO... 8 2.3.1. SAD - SOFTWARE ARCHITECTURE DESCRIPTION (Versión )... 8 2.4. PROCESO 4: DESARROLLO... 9 2.4.1. ESPECIFICACIÓN DE UN CASO DE USO... 9 2.4.2. ENTREGA PARA PRUEBAS... 9 2.4.3. PLAN DE PRUEBAS FUNCIONALES... 9 2.4.4. REPORTE DE DEFECTOS E INCIDENTES EN LAS PRUEBAS FUNCIONALES... 10 2.5. PROCESO 5: PRUEBAS Y PROCESO DE INTEGRACIÓN... 10 2.5.1. PLAN DE PRUEBAS DE INTEGRACIÓN... 10 2.5.2. REPORTE DE DEFECTOS E INCIDENTES EN LAS PRUEBAS DE INTEGRACIÓN... 11 2.6. PROCESO 6: ENTREGA AL CLIENTE Y PRUEBAS POR PARTE DEL CLIENTE... 11 2.6.1. FORMATO DE LOS REQUERIMIENTOS ASOCIADOS A LOS CASOS DE USO ENTREGADOS... 11 2.7. PROCESO 7: BUGS... 11 2.7.1. FORMATO DE DESCRIPCIÓN DEL BUG... 11 2.8. PROCESO 8: EXTENSIONES... 12 2.8.1. FORMATO DE DESCRIPCIÓN DE LA EXTENSIÓN... 12 2.9. PROCESO 9: PUESTA EN OPERACIÓN... 12 2.9.1. PLAN DE CAPACITACIÓN... 12 2.9.2. MANUAL DE INSTALACIÓN... 13 2.9.3. MANUAL TÉCNICO... 13 2.9.4. MANUAL DE USUARIO... 13
LISTA DE TABLAS Tabla 1 - Estructura de los nombres de los documentos... 5 Tabla 2 - Abreviaturas de los documentos... 6 Tabla 3 - Ubicación del diagrama de casos de uso... 6 Tabla 4 - Ubicación de la plantilla HACER&USOS... 7 Tabla 5 - Ubicación del contrato de la segunda fase... 7 Tabla 6 - Ubicación del SPMP... 8 Tabla 7 - Ubicación del SAD... 8 Tabla 8 - Ubicación de la plantilla de los casos de uso... 9 Tabla 9 - Ubicación de la plantilla entrega para pruebas... 9 Tabla 10 - Ubicación del plan de pruebas funcionales... 10 Tabla 11 - Ubicación del reporte de los defectos... 10 Tabla 12 - Ubicación del plan de pruebas de integración... 10 Tabla 13 - Ubicación de la plantilla de los requerimientos asociados... 11 Tabla 14 - Ubicación de la plantilla de la especificación del bug... 12 Tabla 15 - Ubicación de la plantilla de la especificación de la extensión... 12 Tabla 16 - Ubicación del plan de capacitación... 13 Tabla 17 - Ubicación del manual de instalación... 13 Tabla 18 - Ubicación del manual técnico... 13 Tabla 19 - Ubicación del manual del usuario... 14
1. INTRODUCCIÓN En la guía : Guía metodológica para la gestión de proyectos de software basados en metodologías ágiles, utilizando a GForge como ambiente de desarrollo colaborativo, se propone un modelo de gestión dividido en nueve procesos, los cuales administran su correspondiente tracker definido en GForge. En este documento se indicará y se explicará de forma general, cada uno de los documentos que se necesitan tener en cuenta durante la ejecución de cada uno de los procesos definidos en, con el fin de registrar los resultados obtenidos al llevar a cabo cada una de las actividades que se necesitan durante el desarrollo de un proyecto de software basado en metodologías ágiles.
2. DOCUMENTOS DE LOS PROCESOS QUE FORMAN PARTE DE LA GUÍA METODOLÓGICA A continuación se presentará la descripción general de cada uno de los procesos definidos en el documento, con el fin de orientar al lector en la búsqueda del documento del que desea profundizar en sus detalles. Para cada uno de los procesos se indicarán los documentos que se necesitan tener en cuenta, especificando su correspondiente código, descripción y ubicación en el CD de. En cuanto al código de los documentos que se tendrán en cuenta, se les ha definido la siguiente estructura: Nombre de la abreviatura Número del proceso documento Abreviatura del nombre del documento Descripción Indica el proceso al cual el archivo hace referencia, el cual tiene un solo carácter de tipo numérico entre 1 y 9. Se identifica a través del carácter consecutivo al número del proceso, el cual sólo contiene un sólo carácter, con la restricción de ser E ó P. En caso de ser E, se trata de un documento ilustrativo del proyecto TiggerRummy, y en el caso contrario, se trata de la plantilla para llenar el documento. Esta abreviatura consiste de dos caracteres para los nombres de los documentos que hacen parte de la guía metodológica; la abreviatura se escribe después del tipo de documento. A excepción de los documentos: Especificación del caso de uso, Formato de la descripción del bug, y Formato de la descripción de la extensión, en cuyos casos a su abreviatura se le agrega el carácter: +, seguido del identificador del componente que hacen referencia, el cual puede ser un caso de uso, un bug o una extensión. Tabla 1 - Estructura de los nombres de los documentos Las abreviaturas de cada uno de los documentos que soportan la guía metodológica, se explican a continuación. Nombre del documento Diagrama de casos de uso Hacer&Usos Contrato de la segunda fase del proyecto Abreviatura en el nombre CU HU C2
SPMP SAD Especificación del caso de uso Entrega para pruebas Plan de pruebas funcionales Reporte de defectos e incidentes en las pruebas Plan de pruebas de integración Formato de los requerimientos asociados a los casos de uso entregados Formato de la descripción del bug Formato de la descripción de la extensión Plan de capacitación Manual de instalación Manual técnico Manual del usuario Tabla 2 - Abreviaturas de los documentos SP SA EC+ID (Donde ID corresponde al identificador del caso de uso correspondiente) EP PF RD PP FR FB+ID (Donde ID corresponde al identificador del bug) FE+ID (Donde ID corresponde al identificador de la extensión) PC MI MT MU 2.1. PROCESO 1: ANÁLISIS DE REQUERIMIENTOS Y CASOS DE US0 Este proceso inicia con la formulación de un contrato entre el cliente con el gerente del proyecto, para definir la ejecución de la primera fase del proyecto, en donde se realizará el levantamiento de los requerimientos y la especificación de los casos de uso del proyecto, por parte de los analistas y el arquitecto de software. 2.1.1. DIAGRAMA DE CASOS DE USO En este documento, se muestran los casos de uso con sus correspondientes relaciones entre si y sus actores involucrados, de acuerdo a las reglas definidas por UML. Como ejemplo, se tiene el diagrama de casos de uso del proyecto TiggerRummy, con las siguientes características: Ejemplo 1ECU - TiggerRummy (Diagrama de Casos de Uso).jpg 1ECU Tabla 3 - Ubicación del diagrama de casos de uso \Guia\Trackers\1 Requerimientos\
2.1.2. FORMATO HACER&USOS En este documento se define la documentación para cada uno de los casos de uso y los requerimientos del proyecto, especificando también su correspondiente relación y modelo de trazabilidad, junto con la descripción de los actores involucrados. A continuación, se muestran las propiedades tanto para la plantilla como para el ejemplo ilustrativo del proyecto TiggerRummy que se desarrolló para este tipo de documento en especial. 1EHU - TiggerRummy ( HACER USOS(v3-2009)).xls 1EHU Tabla 4 - Ubicación de la plantilla HACER&USOS \Guia\Trackers\1 Requerimientos\ 2.2. PROCESO 2: PLANEACIÓN DEL DESARROLLO DEL PROYECTO Al inicio de este proceso, el cliente junto con el gerente del proyecto se reúnen para definir la ejecución de la segunda fase del proyecto, en donde se encuentra la iteración principal de la guía metodológica de, con el fin de desarrollar cada caso de uso, hasta el punto de integrarlos y probarlos tanto en el ambiente de desarrollo como en el ambiente de destino. 2.2.1. CONTRATO SEGUNDA FASE DEL PROYECTO En este documento se especifican los costos, los tiempos y los recursos que se necesitarán durante la ejecución de la segunda fase del proyecto, el cual debe ser firmado tanto por el cliente como por el gerente del proyecto. Como este documento no es estándar, en cuanto a su contenido y estructura, para este documento no se definió su correspondiente plantilla. Sin embargo, se ilustra su correspondiente ejemplo para el proyecto de demostración TiggerRummy con las siguientes características: 2PC2 - Contrato Segunda \Guia\Trackers\2 Fase.doc 2PC2 Especificacion\ Tabla 5 - Ubicación del contrato de la segunda fase
2.2.2. SPMP - SOFTWARE PROJECT MANAGEMENT PLANS (Versión ) En este documento se especifican los planes que se llevarán a cabo durante la ejecución de la segunda fase del proyecto, teniendo en cuenta, los procesos de gestión necesarios para el proyecto, sus responsables y el cronograma general para esta fase del proyecto. Ejemplo 2ESP - TiggerRummy (SPMP).doc 2ESP 2PSP - SPMP.doc 2PSP Tabla 6 - Ubicación del SPMP \Guia\Trackers\2 Planeacion\ 2.3. PROCESO 3: ARQUITECTURA Y DISEÑO El objetivo de este proceso, es el de especificar la arquitectura final con la que contará el sistema que se está desarrollando en el proyecto, junto con el diseño y la tecnología con la que contarán tanto los componentes de software que necesite el proyecto, como de los mecanismos de comunicación. 2.3.1. SAD - SOFTWARE ARCHITECTURE DESCRIPTION (Versión ) Con este documento, se describe desde un punto de vista general, la arquitectura de software que se va a utilizar en el sistema que se va a desarrollar, haciendo énfasis en todas las vistas arquitectónicas para describir los diferentes aspectos del sistema, como lo son los subsistemas, las interfaces, las capas y sus clases esenciales. Para este documento se seguirá la plantilla que propone el profesor Cesar Bustacara de la Pontificia Universidad Javeriana [Bustacara]. Ejemplo 3ESA - TiggerRummy (SAD).doc 3PSA - SAD.doc 3PSA Tabla 7 - Ubicación del SAD 3ESA \Guia\Trackers\3 Arquitectura\
2.4. PROCESO 4: DESARROLLO Dentro de este proceso se busca diseñar e implementar todos los casos de uso, teniendo en cuenta la arquitectura definida en el proceso anterior, tanto en sus atributos de calidad como sus correspondientes requerimientos asociados. Al finalizar esta etapa, una vez se tengan implementados todos los casos de uso, se procede a realizar las pruebas unitarias a cada uno de estos, de tal forma que los defectos que se encuentren, sean corregidos, y sus resultados obtenidos sean registrados. 2.4.1. ESPECIFICACIÓN DE UN CASO DE USO que define el diseño y la descripción del funcionamiento en detalle del caso de uso que se está implementando. Para este documento, sólo se tiene disponible la plantilla, la cual se debe utilizar para cada caso de uso que tenga el proyecto. 4PEC - Especificacion_CU.doc 4PEC Tabla 8 - Ubicación de la plantilla de los casos de uso \Guia\Trackers\4 Desarrollo\ 2.4.2. ENTREGA PARA PRUEBAS Formato que resume los resultados obtenidos en el desarrollo de un caso de uso, para que sean tenidos en cuenta en el momento de realizar los diferentes tipos de pruebas que se requieran. Para este documento, se han definido las siguientes características dentro del CD de. 4PEP - Entrega_Pruebas.doc 4PEP Tabla 9 - Ubicación de la plantilla entrega para pruebas \Guia\Trackers\4 Desarrollo\ 2.4.3. PLAN DE PRUEBAS FUNCIONALES que registra los procedimientos que se deben realizar durante la sesión de pruebas funcionales, las cuales se ejecutan sobre las clases involucradas que tiene cada caso de uso. Durante esta sesión, el diseñador define los mecanismos de pruebas que serán utilizados para cada caso de uso, con respecto a sus funcionalidades descritas en el documento de especificación del caso de uso.
4PPF - Plan_Pruebas_Funcionales. doc 4PPF Tabla 10 - Ubicación del plan de pruebas funcionales \Guia\Trackers\4 Desarrollo\ 2.4.4. REPORTE DE DEFECTOS E INCIDENTES EN LAS PRUEBAS FUNCIONALES Este documento también se utiliza en el Proceso 5: Pruebas y proceso de integración, el cual se trata de un formato que describe los defectos que se han detectado, al someter cada caso de uso a las pruebas unitarias o a las pruebas de integración, con el fin de registrar los resultados obtenidos. La plantilla de este documento dentro del CD de, tiene las siguientes características: 4PRD - Reporte_Defectos.doc 4PRD Tabla 11 - Ubicación del reporte de los defectos \Guia\Trackers\4 Desarrollo\ 2.5. PROCESO 5: PRUEBAS Y PROCESO DE INTEGRACIÓN Con este proceso se pretende lograr identificar y brindar el seguimiento a los defectos que se generen en los componentes de software implementados, una vez estos sean probados por medio de pruebas de integración, las cuales se ejecutan a medida que se van integrando los casos de uso desarrollados, al tronco del repositorio de versiones que utiliza el proyecto, para garantizar su correcto funcionamiento con los demás componentes del sistema. 2.5.1. PLAN DE PRUEBAS DE INTEGRACIÓN que describe el plan que se llevará a cabo para ejecutar las pruebas de integración sobre cada conjunto de casos de uso desarrollados. [Golazeski, Miller, Olsen, Rockstroh, & Smith, 2009]. Para este documento, se dispone de su correspondiente plantilla en el CD de con las siguientes características: 5PPP - Plan_Pruebas_Integracion.doc 5PPP Tabla 12 - Ubicación del plan de pruebas de integración \Guia\Trackers\5 Pruebas&Integracion\
2.5.2. REPORTE DE DEFECTOS E INCIDENTES EN LAS PRUEBAS DE INTEGRACIÓN Remítase a la sección: 2.4.4. Reporte de defectos e incidentes en las pruebas funcionales 2.6. PROCESO 6: ENTREGA AL CLIENTE Y PRUEBAS POR PARTE DEL CLIENTE Este proceso tiene como fin, rastrear las actividades relacionadas a las entregas parciales del proyecto de software que se está desarrollando, por medio de la entrega de un conjunto de casos de uso implementados, de tal forma que el cliente ejecute sus pruebas personalizadas sobre cada uno, y determine si se cumplen con todos los requerimientos asociados a cada caso de uso probado. 2.6.1. FORMATO DE LOS REQUERIMIENTOS ASOCIADOS A LOS CASOS DE USO ENTREGADOS Formato que evalúa si cada uno de los casos de uso entregados, cumple con sus requerimientos asociados, registrando sus correspondientes observaciones realizadas por el cliente. Para este documento, se tiene disponible su correspondiente plantilla dentro del CD de, con las siguientes características: 6PFR - Requerimientos_CU_Asociados.doc 6PFR Tabla 13 - Ubicación de la plantilla de los requerimientos asociados \Guia\Trackers\6 Cliente\ 2.7. PROCESO 7: BUGS En este proceso de busca solucionar los diferentes tipos de bugs que hayan sido reportados por el cliente una vez el sistema esté operando, con el fin de realizar sus correspondientes correcciones junto con los procesos de pruebas establecidos. 2.7.1. FORMATO DE DESCRIPCIÓN DEL BUG Este documento se trata de un formato que tiene el objetivo de registrar las descripciones referentes a un bug en específico, de tal manera que se pueda llevar a cabo su gestión, con el fin de solucionarlo lo más pronto posible. A continuación, se describen las características de la plantilla que se encuentra disponible para este formato en el CD de.
7PFB - Bug.doc 7PFB \Guia\Trackers\7 Bugs\ Tabla 14 - Ubicación de la plantilla de la especificación del bug 2.8. PROCESO 8: EXTENSIONES Con este proceso de busca la generación de funcionalidades extras propuestas por el cliente para el mejoramiento del proyecto, después de haberse cumplido con la finalización de lo pactado desde un principio con el alcance del proyecto. 2.8.1. FORMATO DE DESCRIPCIÓN DE LA EXTENSIÓN Este documento se trata de un formato que tiene el objetivo de registrar las descripciones referentes a una extensión en específico, de tal manera que se pueda llevar a cabo su gestión, con el fin de implementarla lo más pronto posible. A continuación, se describen las características de la plantilla que se encuentra disponible para este formato en el CD de. 8PFE - \Guia\Trackers\8 Extension.doc 8PFE Extensiones\ Tabla 15 - Ubicación de la plantilla de la especificación de la extensión 2.9. PROCESO 9: PUESTA EN OPERACIÓN Con este proceso se van a definir las actividades que se llevarán a cabo para dar el cierre del proyecto de software que se está desarrollando. Con esto, se busca cerrar el proceso de desarrollo del proyecto, validando cada requerimiento y cada caso de uso acordado contra el entregado, de tal forma que realicen los registros necesarios de las entregas satisfactorias. Por otra parte, también dentro de este proceso se debe especificar los mecanismos de soporte y capacitación que se les dará a los productos de software desarrollados, una vez estos salgan de su ambiente de desarrollo. 2.9.1. PLAN DE CAPACITACIÓN que detalla los pasos y procedimientos a tener en cuenta para realizar la capacitación del uso del producto de software desarrollado a sus usuarios finales. Para este
documento, se dispone su correspondiente plantilla, con las siguientes características dentro del CD de : 9PPC - Plan_Capacitacion.doc 9PPC Tabla 16 - Ubicación del plan de capacitación \Guia\Trackers\9 Operacion\ 2.9.2. MANUAL DE INSTALACIÓN que explica los procedimientos que se deben realizar para instalar el producto de software desarrollado, en el ambiente de destino. Para este documento, se dispone su correspondiente plantilla, con las siguientes características dentro del CD de : 9PMI - Manual_Instalacion.doc 9PMI Tabla 17 - Ubicación del manual de instalación \Guia\Trackers\9 Operacion\ 2.9.3. MANUAL TÉCNICO que contiene todos los documentos de las especificaciones de los casos de uso desarrollados e implementados en el proyecto, ver sección: Especificación del Caso de Uso, con el fin de brindar la correspondiente retroalimentación a los casos de uso, cuando sea necesario. Para este documento, se define una plantilla en el CD de con las siguientes características: 9PMT - Manual_Tecnico.doc 9PMT Tabla 18 - Ubicación del manual técnico \Guia\Trackers\9 Operacion\ 2.9.4. MANUAL DE USUARIO que explica los procedimientos que se deben realizar para utilizar el producto de software desarrollado en el ambiente de destino por los usuarios finales. Para este documento, se dispone su correspondiente plantilla, con las siguientes características dentro del CD de :
9PMU - Manual_Usuario.doc 9PMU Tabla 19 - Ubicación del manual del usuario \Guia\Trackers\9 Operacion\