GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV.

Transcripción

1 GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. Contenido INTRODUCCIÓN... 2 Qué es una guía Metodológica... 2 Objetivos de esta guía... 2 Alcance... 2 Beneficios... 2 SOBRE EL ASIC DE LA UPV... 3 Carta de Servicios del ASIC... 3 TIPOS DE PROYECTO / TRABAJO... 3 e Identificación de los tipos de trabajo... 3 Desarrollo de nuevas aplicaciones y módulos... 3 Mantenimiento NO Planificado. Correctivo / Adaptativo... 3 Mantenimiento Planificado. Mejoras y Ampliaciones de las aplicaciones... 3 Integración de aplicaciones... 4 Estudios de viabilidad de soluciones Gestión de la seguridad informática Detalles de los tipos de trabajo... 4 Desarrollo de nuevas aplicaciones y módulos... 4 Mantenimiento NO Planificado. Correctivo / Adaptativo... 4 Mantenimiento Planificado. Mejoras y Ampliaciones de las aplicaciones... 4 Integración de aplicaciones... 4 Estudios de viabilidad de soluciones Gestión de la seguridad informática GUÍAS METODOLÓGICAS DE CADA TIPO DE TRABAJO... 5 Que encontramos en las guías... 5 Guías Detalladas... 5 ORGANIZACIÓN DE LA DOCUMENTACIÓN... 5 Documento: GUIA_INICIO.docx 1/6

2 GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. HERRAMIENTAS DE APOYO A LA METODOLOGÍA... 5 Herramienta de Toma de Requisitos... 6 Herramienta de Diagramación para la comunicación Visual... 6 Herramienta de Diagramación de Bases de Datos... 6 Herramienta de Gestión de Proyectos... 6 Herramienta de Repositorio Documental... 6 CONTROL DE CALIDAD... 6 La necesidad de un Control de Calidad... 6 Mecanismo de Control de Calidad... 6 INTRODUCCIÓN Qué es una guía Metodológica Definiremos guía metodológica como el documento técnico que describe el conjunto de normas a seguir en los trabajos relacionados con los sistemas de información. Objetivos de esta guía Ayudar en la definición e identificación de los diferentes trabajos de Desarrollo, Mantenimiento e Integración de aplicaciones realizados en el ASIC-A. Identificar los diferentes grupos de tareas que se realizan en cada uno de los proyectos. Establecer aquellos documentos que deben generarse como resultado de las tareas realizadas en los proyectos. Asegurar una mínima documentación de los trabajos y por consiguiente de los sistemas de información existentes. Alcance Este documento y los que hace referencia va orientado a los Técnicos y Analistas de aplicaciones del ASIC. Aunque el documento no va orientado a los programadores, si es interesante que ellos la conozcan para saber donde encontrarán la documentación. Beneficios Homogenización de la metodología de trabajo de todos los miembros del ASICA. Facilitar la adaptación de los nuevos miembros del ASIC. Documento: GUIA_INICIO.docx 2/6

3 GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. SOBRE EL ASIC DE LA UPV Carta de Servicios del ASIC El ASIC de la UPV al igual que todos los servicios definió bajo el proyecto pegasus una carta de los servicios que presta a la universidad. Esta carta de servicios puede encontrarse en: Los procesos que se describen en pegasus están diseñados para mostrar de una forma muy general y gráfica todas las posibles tareas que se realizan en la gestión de Sistemas de Información, no especificando que tareas son obligatorios u optativas ni la documentación que se genera. TIPOS DE PROYECTO / TRABAJO Todos los trabajos que realiza el personal del ASICA pueden ser catalogados en 6 tipos distintos de trabajo o proyectos. Y que son: Desarrollo de nuevas aplicaciones y módulos Mantenimiento NO Planificado. Correctivo / Adaptativo Mantenimiento Planificado. Mejoras y Ampliaciones de las aplicaciones Integración de aplicaciones Estudios de viabilidad de soluciones. Gestión de la seguridad informática. e Identificación de los tipos de trabajo Desarrollo de nuevas aplicaciones y módulos Definición: Llevar a cabo el análisis, diseño, programación e implantación de nuevas aplicaciones informáticas. Mantenimiento NO Planificado. Correctivo / Adaptativo Definición: Solución de incidencias de aplicaciones en explotación, realización de pequeños cambios y explotación de la base de datos. Identificación: Malfuncionamiento de la aplicación, problemas que impiden al usuario realizar su trabajo tal y como se pensó en la aplicación, cambios que puedan realizarse en menos de 3 días de trabajo. Mantenimiento Planificado. Mejoras y Ampliaciones de las aplicaciones Definición: Atender las solicitudes de cambio de las aplicaciones en explotación. Identificación: Añaden funcionalidad a la aplicación. Son cambios en la aplicación que cuestan más de 4 días. Documento: GUIA_INICIO.docx 3/6

4 GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. Integración de aplicaciones Definición: Trabajos para la implantación en los servicios UPV de aplicaciones externas. Identificación: La aplicación es externa al ASIC y se realizan diversos trabajos de asesoría, hosting de BD, integración de datos. Estudios de viabilidad de soluciones. Definición: Realización de un estudio de alternativas de SW para dar solución a las necesidades de los serviciosupv. Identificación: Asesoramiento a servicios. El proyecto acaba cuando se toma la decisión. Gestión de la seguridad informática. Definición: Dar apoyo en el proceso de la declaración de ficheros. Identificación: Informes necesarios para cumplir con LOPD. Detalles de los tipos de trabajo Desarrollo de nuevas aplicaciones y módulos Definición: Llevar a cabo el análisis, diseño, programación e implantación de nuevas aplicaciones informáticas. Mantenimiento NO Planificado. Correctivo / Adaptativo Definición: Solución de incidencias de aplicaciones en explotación, realización de pequeños cambios y explotación de la base de datos. Identificación: Malfuncionamiento de la aplicación, problemas que impiden al usuario realizar su trabajo tal y como se pensó en la aplicación, cambios que puedan realizarse en menos de 3 días de trabajo. Mantenimiento Planificado. Mejoras y Ampliaciones de las aplicaciones Definición: Atender las solicitudes de cambio de las aplicaciones en explotación. Identificación: Añaden funcionalidad a la aplicación. Son cambios en la aplicación que cuestan más de 4 días. Integración de aplicaciones Definición: Trabajos para la implantación en los servicios UPV de aplicaciones externas. Identificación: La aplicación es externa al ASIC y se realizan diversos trabajos de asesoría, hosting de BD, integración de datos. Estudios de viabilidad de soluciones. Definición: Realización de un estudio de alternativas de SW para dar solución a las necesidades de los serviciosupv. Identificación: Asesoramiento a servicios. El proyecto acaba cuando se toma la decisión. Documento: GUIA_INICIO.docx 4/6

5 GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. Gestión de la seguridad informática. Definición: Dar apoyo en el proceso de la declaración de ficheros. Identificación: Informes necesarios para cumplir con LOPD. GUÍAS METODOLÓGICAS DE CADA TIPO DE TRABAJO Que encontramos en las guías En estas guías se encontrará una definición de los pasos a realizar para cada uno de los trabajos. Se definen los documentos que son producidos por cada una de las tareas. Se definen cuales de los documentos producidos es obligatoria su generación y cuales son opcionales. Guías Detalladas Desarrollo y Mantenimiento Planificado: GUIA_DESARROLLO.docx Mantenimiento de Aplicaciones: ORGANIZACIÓN DE LA DOCUMENTACIÓN En las diferentes tareas realizadas en cada uno de los trabajos se generarán numerosos documentos e información en base de datos que es necesaria recopilar y organizar de una forma adecuada y uniforme. La organización se basa en el siguiente paradigma: Cada proyecto pertenece necesariamente a una aplicación, y por lo tanto toda la documentación del proyecto colgará de la aplicación. La documentación que se genera con un proyecto pertenece al mismo pero puede ser de utilidad general para la aplicación por lo que es posible se duplique en los directorios de documentación de la aplicación. HERRAMIENTAS DE APOYO A LA METODOLOGÍA Para facilitar el desarrollo de los diferentes proyectos y cumplir con las necesidades de documentación descritas en las guías específicas de cada tipo de trabajo, es necesaria la utilización de herramientas específicas. No es posible el uso de una herramienta única que permita el uso de una forma global para todos los tipos de proyectos, fases y documentos a generar. Es por esto que para cada una de las fases y documentos es necesario la utilización de una herramienta específica. Documento: GUIA_INICIO.docx 5/6

6 GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV. Herramienta de Toma de Requisitos Herramienta de Diagramación para la comunicación Visual Herramienta de Diagramación de Bases de Datos Herramienta de Gestión de Proyectos Herramienta de Repositorio Documental CONTROL DE CALIDAD La necesidad de un Control de Calidad Mecanismo de Control de Calidad Documento: GUIA_INICIO.docx 6/6

7 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Contenido AMBITO DE APLICACIÓN... 2 PREREQUISITOS... 2 TAREAS A REALIZAR EN EL PROYECTO... 2 Visión General de las Tareas... 2 Detalle de las Tareas... 3 Definición del proyecto... 3 Toma de Requisitos... 3 Especificación de requisitos técnicos para enviarlos ASICSyR (Obligatorio si lo requiere la aplicación)... 5 Diseño de procesos (Opcional pero Recomendable )... 5 Documento planificación de Tareas... 5 Definición y creación de la base de datos... 6 Generación del Cuaderno de Carga... 6 Definición de pruebas... 7 Programación y pruebas unitarias... 7 Pruebas de integración... 7 Generación del manual de la aplicación... 8 Entrega piloto al usuario y aceptación (por el usuario)... 8 Implantación de aplicación... 9 Monitorización de la aplicación... 9 Formación... 9 PLANTILLAS DE DOCUMENTOS... 9 ORGANIZACIÓN DE LA DOCUMENTACIÓN DEL PROYECTO HERRAMIENTAS A USAR ANEXO1: DEFINICIÓN DEL PROCESO DE DESARROLLO DE APLICACIONES EN PEGASUS Documento: GUIA_DESARROLLO.docx 1/16

8 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES AMBITO DE APLICACIÓN Esta guía debe ser aplicada a todos los trabajos que cumplan alguna de estas condiciones: Nuevas aplicaciones para la automatización de procesos no automatizados. Sustitución de aplicaciones que se han quedado obsoletas. Ampliación de aplicaciones con un volumen superior a los 5 días de trabajo. PREREQUISITOS Los trabajos incluidos en el ámbito de aplicación cumplen el prerrequisito de haber pasado por un proceso previo de estudio de viabilidad donde ya se han considerado las posibles alternativas y donde se ha decidido que es necesario empezar un proyecto de desarrollo de software. No se está por tanto realizando un análisis de mercado ni probando alternativas, etc. En este momento se tiene constancia de la aplicación que se debe desarrollar, se tiene identificado al cliente y el alcance está más o menos determinado. TAREAS A REALIZAR EN EL PROYECTO Visión General de las Tareas Tarea Definición del proyecto Toma de Requisitos funcionales Especificación de requisitos técnicos Diseño de procesos Planificación de Tareas Documentación a Generar Doc Definición del Proyecto Doc Requisitos Proyecto Plantilla Localización de la Carácter Tarea Documentación PLA_PROY_DEF.dotx PROY\ANA Obligatoria PLA_PROY_REQ.dotx PLA_ACTA.dotx PROY\ANA Obligatoria Doc Req Tec PLA_PROY_REQTEC.dotx PROY\ANA Obligatorio si lo requiere la aplicación Docum Casos PROY\ANA Opcional Uso/BPMN Elemento Nuevo Project Server Opcional proyecto Elementos Tareas Diagrama de Tablas PROY\DIS Obligat si se modifican Tablas Cuaderno Carga/Gregal PROY\DIS Opcional Definición de la base de datos Generación de los cuadernos de carga Definición de Completar Cuaderno PLA_CCARGA.dotx PROY\DIS Opcional pruebas Carga Programación y Módulos del Programa PROY\SRC\Según_Tecnolo Obligatorio pruebas unitarias gía Pruebas de Incidencias Herramienta Ticketing Opcional integración Generación del Manual de la Aplicación PLA_MANUAL.docx APLIC\DOCUMENTACION\ Opcional manual de la MANUALES aplicación Entrega piloto al Opcional usuario y aceptación Implantación de Opcional aplicación Monitorización Tests a pasar por Nagios Test en PIOLIN Opcional Formación Material Formación PLA_PRESENTACION.potx PROY\USUARIOS Opcional Documento: GUIA_DESARROLLO.docx 2/16

9 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES APLIC: Hace referencia al directorio de la aplicación PROY: Hace referencia al directorio del proyecto ANA: Hace referencia al directorio ANALISIS del proyecto. DIS: Hace referencia al directorio DISEÑO del proyecto. Detalle de las Tareas Definición del proyecto detallada del proyecto. Decidir a que aplicación pertenece este proyecto y generación del código de proyecto. Documentar el promotor y los participantes/usuarios reales en el proyecto. Documento Definición del Proyecto (Obligatorio) Nombre: PROY_DEF_xxxxxxxxx.DOC (Siendo xxxxx el alias del documento) Datos a Incluir: Código y nombre del proyecto Promotor: Jefe Proyecto ASIC: Participantes Comité Dirección: Miembros equipo trabajo: Objetivos del proyecto Aplicaciones involucradas en el Proyecto Plazo de realización previsto Dejar en PROY\ANA Generación documento Word según plantilla PLA_PROY_DEF.DOTX. Envío por al promotor con acuse de recibo. (Registro del proyecto en la herramienta de gestión de proyectos y en el repositorio de la documentación. =>Anulado de momento) Código del proyecto El código consta de: Área+Aplicación(Subsistema)+Versión Siendo: Toma de Requisitos Área: Una de las 5 áreas de trabajo del ASICA (ALU/BIB/COD/SEG/DWH) Aplicación(Subsistema): Puede ser la aplicación Maestra o el Subsistema dentro de una aplicación maestras. Versión: Puede ser la versión de la aplicación o un orden secuencial de proyecto por año. Ejemplos: ALU_VINCONVAL_v , ALU_POLIFORMAT_v Documento: GUIA_DESARROLLO.docx 3/16

10 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Consiste en la toma de requisitos de Negocio/Cliente/Funcionales que debe cumplir la aplicación. La forma de obtención de los requisitos se basará en las entrevistas con los usuarios y responsables de los procesos de negocio de las unidades involucradas. La toma de requisitos debe acabar con una validación de los mismos por parte del usuario que encargó el proyecto. Planificación y realización de Entrevistas. Generación del listado de requisitos que deberán inventariarse en la Herramienta de Toma de Requisitos (). Para la toma de requisitos se puede seguir la GUIA_Requisitos.docx. Validación de requisitos por el promotor. La forma de conseguir la aceptación por parte del usuario puede hacerse mediante el simple formalismo de envío de un correo al usuario con el listado de requisitos y guardar la respuesta del mismo. Caso de no encontrar respuesta por parte del promotor se le mandará un correo similar a este: Estimado compañero: El presente correo lleva anexado un documento con la especificación de requisitos del proyecto de software solicitado por tu unidad. Sirva este correo como justificante de entrega de los citados requisitos. Ruego consideres el documento y quedo a la espera de tus modificaciones y comentarios. Si transcurridas 2 semanas desde la fecha actual no he recibido contestación alguna, consideraré que el documento es conforme a tus necesidades. Recibe un cordial saludo. El analista responsable. Documento de Requisitos (Obligatorio). Utilizar la plantilla PLA_PROY_REQ.DOTX Nombre: PROY_REQ_xxxxxxxxxx.DOC (Siendo xxxxx un alias del documento) Datos a Incluir: Código del Proyecto Tipo de Requisito (Negocio-General / Funcional-detallado) Código Numérico de Requisito del Requisito Importancia Dejar en PROY\ANA Otra documentación: Documento: GUIA_DESARROLLO.docx 4/16

11 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Actas de Reuniones. Documentación de Normativas, etc Especificación de requisitos técnicos para enviarlos ASICSyR (Obligatorio si lo requiere la aplicación) Con los requisitos recopilados en el punto anterior se debe determinar cuáles son las necesidades que se van a tener de Sistemas y Redes, con el fin de comunicarlas lo antes posible. Revisar los requisitos tomados para evaluar las necesidades de Sistemas. Enumerar los recursos necesarios tanto para desarrollo como preproducción y explotación. Completar la información en el mismo documento de requisitos. Comunicar a sistemas/redes el documento con las necesidades. La sección de Requisitos de Sistemas/Redes del documento de requisitos Nombre: PROY_REQTEC_xxxxx.DOC (Siendo xxxxx un alias del documento Diseño de procesos (Opcional pero Recomendable ) Documentación y descripción detallada de los principales procesos de la aplicación. Analizar en detalle cada uno de los principales procedimientos necesarios para la aplicación. Documentar de manera gráfica preferiblemente el proceso. Describir cada una de las fases de las que consta el proceso. Se deberán relacionarán los requisitos relacionados con cada uno de los procesos. Diagramas BPMN (Bussiness Process Management Notation) o documentos Word con la descripción de los procedimientos. Para estos diagramas se utilizará la herramienta Visio. Se generarán documentos con nombre ANA_PROC_xxxxx.docx. (Siendo xxxxx un alias del documento/nombre del proceso) Documento planificación de Tareas A partir de todos requisitos y procesos que se deben implementar se debe elaborar el EDT (Esquema de Descomposición de Tareas) Recopilar las tareas necesarias para el desarrollo de la aplicación. Documento: GUIA_DESARROLLO.docx 5/16

12 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Identificar los recursos disponibles. Identificar pre-post condiciones en las tareas Se deberá crear un nuevo proyecto en la herramienta de Gestión de Proyectos (Microsoft Project). El fichero si se guarda en local se debe llamar ANA_EDT_xxx.mpp (Siendo xxxxx un alias del documento) en el directorio de Análisis del proyecto. Se deberán crear también en la herramienta las tareas a realizar asignando una previsión de fechas. Si es posible se asignarán a las tareas los recursos que se van a utilizar en el proyecto. Definición y creación de la base de datos Consiste en la creación de las tablas, vistas y objetos necesarios en la Base de Datos. Definición de la estructura de Base de Datos usando la herramienta SqlDataModeler. Se considerará obligatorio cumplimentar las descripciones de las tablas y de los campos. Generación del Diagrama de Tablas. Generación de las Tablas en la Base de Datos. Diagrama de Tablas de la aplicación. Generado en el directorio DIS y con nombre DIS_TABLAS_xxxxx.XXX (Siendo xxxxx un alias del documento). Generación del Cuaderno de Carga detallada de los detalles de implementación de cada uno de los módulos de desarrollo de la aplicación. Todas las tareas existentes en Project deberán estar reflejadas necesariamente en GREGAL. Se podrá crear un gregal por cada tarea o se podrán agrupar varias tareas en un único gregal si el analista así lo estima. Cuando la tarea tenga complejidad o entidad suficiente para requerir más explicaciones que las que se pueden dar en un gregal, se podrá anexar un documento de Cuaderno de carga, basado en la plantilla PLA_CCARGA.dotx Para mantener la trazabilidad con la Tarea, mientras no exista una forma automática de hacerlo, se deberá incluir en el gregal el identificador del proyecto y el id de la tarea de project. Documento: GUIA_DESARROLLO.docx 6/16

13 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Gregales asociados a las tareas Definición de pruebas Documentos de Cuaderno de Carga de alguna de las tareas con nombre DIS_CCARGA_xxxx.docx (Siendo xxxxx un alias del documento) Identificar las pruebas que de se deben hacer en cada uno de los módulos. Identificación y descripción de los casos de prueba. Esta documentación se puede incluir en el propio cuaderno de carga o gregal. Programación y pruebas unitarias Es la tarea propiamente dicha de programación Los programadores reciben el gregal y/o el cuaderno de carga con las características del módulo de programación a realizar. Se desarrolla el módulo siguiendo las especificaciones. Se realizan las pruebas unitarias. Se realizan pruebas de integración que afecten a este módulo. Módulo de Programación. Según la tecnología el módulo deberá ser incluido en un punto u otro. Para Forms deberá situarse en APLIC\FORMS o APLIC\REPORTS. Para Objetos del núcleo en el esquema correspondiente. Para Java deberá incluirse en APLIC\SRC. Pruebas de integración Basándose en los requerimientos y los procesos descritos para la aplicación, el analista debe realizar pruebas que corroboren que la aplicación cumple con los requisitos. Revisión de cada uno de los requisitos de la aplicación. Comprobación en la aplicación que el requisito se cumple tal y como indica el procedimiento. Generación de Incidencias por cada funcionalidad no cubierta por la aplicación. Incidencias de programación de un módulo. Documento: GUIA_DESARROLLO.docx 7/16

14 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES El Analista responsable cambiará el estado del requisito a terminado indicando la fecha en el documento de requisitos. Se actualizarán los documentos de prueba de los requisitos de la aplicación si se detectan casos de uso no descritos anteriormente. Generación del manual de la aplicación Generación de un manual que describa el funcionamiento de la aplicación. Revisión de los procesos cubiertos por la aplicación. Extracción de las pantallas de la aplicación. Generación del documento que contiene el manual de usuario. Envío del documento al CAU para su revisión (Por revisar) Manual de la aplicación (por determinar si se hace el wiki o en word) Nombre del documento: MANUAL_xxxxx.DOC (siendo xxx el nombre de la aplicación y la versión) Plantilla: (Nos envían el cau) Entrega piloto al usuario y aceptación (por el usuario) Preparación de la instancia de preproducción de la aplicación para que el usuario final pueda hacer pruebas sin peligro de estropear nada. Preparación del entorno de preproducción. Preparación de la Base de Datos de preproducción. Copia de los programas desde desarrollo a preproducción. Generación de los datos básicos y/o de prueba necesarios. Formación mínima al usuario para que pueda hacer las pruebas. Recepción de incidencias / Feedback del usuario. Comunicación al usuario de que la aplicación está disponible para probar. Gregales del usuario con las no conformidades o errores detectados. Aceptación de los requisitos por parte del usuario. Si el usuario no acepta formalmente los requisitos se le enviará un correo con un plazo máximo para rechazar el requisito, de lo contrario el requisito se dará por aceptado. Como ejemplo de este correo se puede usar: Estimado compañer@: La funcionalidad [REQUISITO] que usted solicitó de la aplicación [APLICACION] se encuentra disponible para su validación. Documento: GUIA_DESARROLLO.docx 8/16

15 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Implantación de aplicación Paso a los servidores de explotación de todo lo necesario para empezar a trabajar con la aplicación. Preparación del entorno de producción. Preparación de la Base de Datos de producción. Copia de los programas desde desarrollo a preproducción. Generación de los datos básicos y/o de prueba necesarios. Opcionalmente se generará un manual de despliegue, o información de Infraestructura o se documentará en la wiki. Monitorización de la aplicación Definir los tests que deberán pasarse a la aplicación para asegurarse constantemente que se encuentra funcionando correctamente. Identificación de los elementos de SW/HW susceptibles de monitorizar. Definición de los test a ejecutar, con los parámetros necesarios Inclusión de los tests en PIOLIN Conjunto de test a incluir en PIOLIN Formación Identificar y preparar e impartir la formación necesaria para los usuarios de la aplicación. Identificar las necesidades de formación. Preparar la documentación necesaria para el curso/seminario/presentación. Material de formación. Presentaciones: Basado en PLA_PRESENTACION.pptx PLANTILLAS DE DOCUMENTOS Las plantillas de documento a usar son Acta de Reunión: PLA_ACTA.dotx Documento definición del proyecto: PLA_PROY_DEF.dotx Documento: GUIA_DESARROLLO.docx 9/16

16 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Documento de Requisitos: PLA_PROY_REQ.dotx Documento de Requisitos Técnicos: PLA_PROY_REQTEC.dotx Cuaderno de Carga: PLA_CCARGA.dotx Manual de la Aplicación: PLA_MANUAL.dotx Presentaciones de la Aplicación: PLA_PRESENTACION.pptx ORGANIZACIÓN DE LA DOCUMENTACIÓN DEL PROYECTO Deberá generarse una carpeta raíz para el proyecto que incluya toda la información relativa. Esta carpeta colgará de la aplicación a la que pertenece el proyecto. La estructura de carpetas será la siguiente: ANA: Documentos de Análisis y documentación DIS: Documentos de Diseño de la aplicación SRC: Documentos programas, scripts, etc necesarios Al finalizar el proyecto se deberá actualizar la información necesaria en los directorios de la aplicación. Ejemplo de estructura de una aplicación con forms. En estructura de ficheros P:\alumnado ALU_RIOS DOCUMENTACION ANALISIS DISEÑO MANUALES OTROS SRC SQL FORMS REPORTS PROYECTOS ALU_RIOS_1.0 ALU_RIOS_1.2 ALU_RIOS_1.5 ANA DIS SRC ALU_RIOS_1.5.2 ALU_RIOS_2.0 Documento: GUIA_DESARROLLO.docx 10/16

17 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES HERRAMIENTAS A USAR Para la gestión del proyecto se utilizarán las siguientes herramientas. Herramienta de Toma de Requisitos. Nombre: Acceso: Manual Uso: Herramienta de Diseño de Casos de Uso Nombre: Visio Acceso:\\izar2\ms\Aplicaciones\Visio 2007 Professional Manual Uso: Herramienta de Diseño de Tablas Nombre: SqlDataModeler Acceso: Instalable localmente desde..\grupoherramientas\designer- DataModeler Manual Uso:..\GrupoHerramientas\Designer- DataModeler\SQLDeveloperDataModeler_TechReview.pdf Herramienta de Gestión de Proyectos Nombre: Microsoft Proyect Web Accesss 2007 Acceso: Manual rápido para empezar:..\grupoherramientas\microsoftprojectwebaccess\guia_project_web.docx Documento: GUIA_DESARROLLO.docx 11/16

18 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES ANEXO1: DEFINICIÓN DEL PROCESO DE DESARROLLO DE APLICACIONES EN PEGASUS Documento: GUIA_DESARROLLO.docx 12/16

19 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Documento: GUIA_DESARROLLO.docx 13/16

20 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Documento: GUIA_DESARROLLO.docx 14/16

21 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Documento: GUIA_DESARROLLO.docx 15/16

22 GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES Documento: GUIA_DESARROLLO.docx 16/16

23 GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES GUIA METODOLÓGICA PARA MANTENIMIENTO NO PLANIFICADO DE APLICACIONES Contenido AMBITO DE APLICACIÓN... 2 PREREQUISITOS... 2 TAREAS A REALIZAR... 2 Visión General de las Tareas... 2 Detalle de las Tareas... 3 Registro de la incidencia... 3 Registro de la solución elegida... 4 Modificación de la base de datos... 5 Programación y pruebas unitarias... 5 Registro de Cambios Realizados... 5 Pruebas de Regresión... 6 Modificación del manual de la aplicación... 6 Entrega al usuario y aceptación (por el usuario)... 6 Organización de la Documentación... 6 Plantillas de Documentos... 7 ANEXO I.- PROCESOS PEGASUS ASICA Documento: GUIA_MATNOPLAN.doc 1/8

24 GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES AMBITO DE APLICACIÓN Esta guía debe ser aplicada para el mantenimiento correctivo / adaptativo, es decir a todos los trabajos que cumplan estas condiciones: Solución de incidencias de aplicaciones en explotación por malfuncionamiento de las mismas o por problemas que impiden al usuario realizar su trabajo tal y como se pensó en la aplicación. Realización de pequeños cambios y explotación de la base de datos que, en general, impliquen un volumen de trabajo inferior a los 5 días. PREREQUISITOS Los trabajos incluidos en el ámbito de aplicación de esta guía cumplen el prerrequisito de haber sido registrados en Gregal, bien directamente por el usuario final o bien por el personal informático si la comunicación del problema llegó por teléfono u otra vía distinta a Gregal. En este momento se tiene constancia de: la aplicación en explotación en la que se da el problema. se tiene identificado al usuario final que plantea el problema. una descripción exacta del problema y con datos suficientes para que pueda ser reproducida. el alcance está más o menos determinado. TAREAS A REALIZAR Visión General de las Tareas Tarea Carácter de la Tarea Registro de la incidencia Tarea en Gregal Obligatoria Generación Cuaderno Carga Cuaderno Carga Opcional Modificación de la base de datos Diagrama de Tablas Obligatorio si se modifican Tablas Cambios en paquetes, librerías y formularios Documentar Cambios Realizado Documentación en Código (Obligatorio el Nº Gregal Tarea en Gregal y/o Documentos de la aplicación Obligatorio Opcional Registro de la solución elegida Tarea en Gregal Obligatoria Programación y pruebas unitarias Pruebas de Regresión Modificación del manual de la aplicación Opcional Opcional Opcional Documento: GUIA_MATNOPLAN.doc 2/8

25 GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES Comunicación al usuario y aceptación Implantación del cambio Opcional Obligatoria Detalle de las Tareas Registro de la incidencia Si bien es prerrequisito de esta guía que este registrado ya en Gregal el problema, se verificará que tal registro existe, de lo contrario se procederá a realizarlo. Entrada: Petición/Incidencia de gregal o vía telefónica o cualquier otra vía (reunión, superior, etc.). Salida: Registro en Gregal a nombre de la persona que hace el encargo. Clasificación de la incidencia/petición. Registro en gregal de la petición o incidencia si no se había registrado previamente. Se acompañará el registro de toda la información necesaria para que el personal informático o empresa encargada del mantenimiento pueda reproducir, en entorno de desarrollo, la situación que provoca el problema, esto es, identificadores de personas afectadas, secuencias de navegación, logs de servidores, etc.. Se comprobará que la tarea de GREGAL está calificada correctamente como Petición o Incidencia. Se añadirá la información de clasificación del problema mediante la asignación de la categoría correspondiente de GREGAL. Si es un cambio que necesita una aprobación por el responsable del proyecto, se apuntará esto en la incidencia. Aclaraciones La clasificación de las tareas pueden ser: Tipo de Problema: o Incidencia Urgente: La aplicación en explotación no da servicio en absoluto. Se debe asignar personal urgentemente para su solución lo antes posible. Por ejemplo, no funciona la auto matrícula en absoluto. o Incidencia No urgente: La aplicación en explotación sigue dando servicio al usuario tal y como está o se esta dando servicio de forma alternativa. O se planifica su resolución a corto plazo y se Documento: GUIA_MATNOPLAN.doc 3/8