Metodología para la gestión de proyectos

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

Documento: GUIA_INICIO.docx 1/6 Versión: 1.0


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

Descripción 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. ......................................................................................... 4

Gestión de la seguridad informática. ......................................................................................... 4

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. ......................................................................................... 4

Gestión de la seguridad informática. ......................................................................................... 5

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



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.



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.

Descripción 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.



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.



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.



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

GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES

Documento: GUIA_DESARROLLO.docx 1/16 Versión: 1.0

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 ......................................................... 10

HERRAMIENTAS A USAR............................................................................................................... 11

ANEXO1: DEFINICIÓN DEL PROCESO DE DESARROLLO DE APLICACIONES EN PEGASUS ................ 12



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 Documentación a

Generar

Plantilla Localización de la

Documentación

Carácter Tarea

Definición del proyecto

Doc Definición del Proyecto

PLA_PROY_DEF.dotx PROY\ANA Obligatoria

Toma de Requisitos funcionales

Doc Requisitos Proyecto PLA_PROY_REQ.dotx PLA_ACTA.dotx

PROY\ANA Obligatoria

Especificación de requisitos técnicos

Doc Req Tec PLA_PROY_REQTEC.dotx PROY\ANA Obligatorio si lo requiere la aplicación

Diseño de procesos

Docum Casos Uso/BPMN

PROY\ANA Opcional

Planificación de Tareas

Elemento Nuevo proyecto

Elementos Tareas

Project Server Opcional

Definición de la base de datos

Diagrama de Tablas PROY\DIS Obligat si se modifican Tablas

Generación de los cuadernos de carga

Cuaderno Carga/Gregal PROY\DIS Opcional

Definición de pruebas

Completar Cuaderno Carga

PLA_CCARGA.dotx PROY\DIS Opcional

Programación y pruebas unitarias

Módulos del Programa PROY\SRC\Según_Tecnología

Obligatorio

Pruebas de integración

Incidencias Herramienta Ticketing Opcional

Generación del manual de la aplicación

Manual de la Aplicación PLA_MANUAL.docx APLIC\DOCUMENTACION\MANUALES

Opcional

Entrega piloto al usuario y aceptación

Opcional

Implantación de aplicación

Opcional

Monitorización Tests a pasar por Nagios Test en PIOLIN Opcional

Formación Material Formación PLA_PRESENTACION.potx PROY\USUARIOS Opcional



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

Descripción

Descripción 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.

Documentación a Generar

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

Procedimiento

Generación documento Word según plantilla PLA_PROY_DEF.DOTX.

Envío por email 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:

Á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_v2010.01, ALU_POLIFORMAT_v2.6.01

Toma de Requisitos



Descripción

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.

Procedimiento

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

Descripción del Requisito

Importancia

Dejar en PROY\ANA

Otra documentación:



• Actas de Reuniones.

• Documentación de Normativas, etc

Especificación de requisitos técnicos para enviarlos ASICSyR (Obligatorio si lo requiere la aplicación)

Descripció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.

Procedimiento

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 )

Descripción

Documentación y descripción detallada de los principales procesos de la aplicación.

Procedimiento

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

Descripción

A partir de todos requisitos y procesos que se deben implementar se debe elaborar el EDT (Esquema de Descomposición de Tareas)

Procedimiento

Recopilar las tareas necesarias para el desarrollo de la aplicación.



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

Descripción

Consiste en la creación de las tablas, vistas y objetos necesarios en la Base de Datos.

Procedimiento

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

Descripción

Descripción detallada de los detalles de implementación de cada uno de los módulos de desarrollo de la aplicación.

Procedimiento

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.




Gregales asociados a las tareas

Documentos de Cuaderno de Carga de alguna de las tareas con nombre

DIS_CCARGA_xxxx.docx (Siendo xxxxx un alias del documento)

Definición de pruebas

Descripción

Identificar las pruebas que de se deben hacer en cada uno de los módulos.

Procedimiento

Identificación y descripción de los casos de prueba.


Esta documentación se puede incluir en el propio cuaderno de carga o gregal.


Descripción

Es la tarea propiamente dicha de programación

Procedimiento

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

Descripció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.

Procedimiento

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.



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

Descripción

Generación de un manual que describa el funcionamiento de la aplicación.

Procedimiento

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)

Descripción

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.

Procedimiento

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.



Implantación de aplicación

Descripción

Paso a los servidores de explotación de todo lo necesario para empezar a trabajar con la aplicación.

Procedimiento

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

Descripción

Definir los tests que deberán pasarse a la aplicación para asegurarse constantemente que se encuentra funcionando correctamente.

Procedimiento

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

Descripción

Identificar y preparar e impartir la formación necesaria para los usuarios de la aplicación.

Procedimiento

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 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



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: http://project2007/pwa Manual rápido para empezar: ..\GrupoHerramientas\MicrosoftProjectWebAccess\GUIA_PROJECT_WEB.docx



ANEXO1: DEFINICIÓN DEL PROCESO DE DESARROLLO DE APLICACIONES EN PEGASUS

GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES

Documento: GUIA_MATNOPLAN.doc 1/8 Versión: 1.0

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 ASICA04. ...................................................................................... 8



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 Documentación a Generar 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

Documentación en Código

(Obligatorio el Nº Gregal

Obligatorio

Documentar Cambios Realizado Tarea en Gregal y/o Documentos

de la aplicación

Opcional

Registro de la solución elegida Tarea en Gregal Obligatoria

Programación y pruebas unitarias Opcional

Pruebas de Regresión Opcional

Modificación del manual de la aplicación Opcional



Comunicación al usuario y aceptación Opcional

Implantación del cambio Obligatoria

Detalle de las Tareas

Registro de la incidencia

Descripción

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.

Procedimiento

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



asigna personal informático o se decide planificar resolución en

nueva versión de la aplicación.

� Por ejemplo, error en cualquier aplicación que sólo afecta

a un número reducido de casos y que el usuario subsana

haciendo puntualmente la tarea a mano.

o Petición Urgente: La aplicación en explotación requiere cambios

imprescindibles a muy corto plazo. Se debe asignar personal

urgentemente para su realización lo antes posible.

� Por ejemplo, cambio en requerimientos por publicación

de un decreto de normativa.

o Peticiones No urgentes: La aplicación en explotación requiere

nueva funcionalidad. Estas peticiones son susceptibles de

planificarse en nueva versión de aplicación o, si el volumen de

trabajo es inferior a 3 días, se planifica el cambio a corto plazo y

se asigna personal informático.

� Por ejemplo, una modificación en la presentación de un

report.

Registro de la solución elegida

Descripción

Definición de la solución. Incluye el estudio de la solución realizada para la petición/incidencia en los sistemas afectados. Mediante este análisis se valoran las tareas de los procesos de desarrollo (Análisis, Diseño, Construcción e Implantación) .


Entrada: Petición/Incidencia de gregal. Elementos afectados por la Petición/Incidencia.

Salida: o Gregal: Registro de solución. o (Opcional) Documentos de cambios. o (Opcional): Actualización de manuales.

Procedimiento

Determinar la lista de cambios necesarios para solucionar el problema. Identificar

todos los componentes afectados (programas fuentes, modelo de datos,

paquetes, librerías, etc.) y comprobar la viabilidad del cambio necesario.

En este punto quedarán registrados, de la forma que se considere más conveniente siguiendo la metodología, los cambios en los elementos (modelos, pantallas, informes, módulos, programas fuentes, programas objetos, archivos de datos, manuales de usuario...) implicados en cada petición/incidencia.



Describir a la persona, o empresa encargada de hacer la corrección, el problema concreto y de la solución necesaria, indicando modificaciones necesarias en cada modulo/form/pantalla, etc y tiempo estimado para su corrección.

Modificación de la base de datos

Descripción

Realizar el cambio de la base de datos si la petición o incidencia lo requiere.

Procedimiento

Modificación de la estructura de Base de Datos usando la herramienta SqlDataModeler. Actualización del Diagrama de Tablas. Generación de las modificaciones en la Base de Datos de Desarrollo.


Diagrama de Tablas Actualizado de la aplicación. Carga de nuevo código DDL en sistema de control de versiones. (Pendiente de especificar cómo realizarlo)


Descripción

Realizar la programación que genera la incidencia o petición.

Procedimiento

Se lleva a cabo la programación y se comprueba que cada petición/incidencia de modificación queda atendida, resulta y probada y que los diferentes componentes funcionan correctamente.

Entregables

Módulos de programación generados o modificados.

Registro de Cambios Realizados

Descripción

Documentación de los cambios realizados en los elementos afectados (forms, reports, código, etc. ).

Procedimiento

Se apuntará en GREGAL la información necesaria que permita averiguar el alcance de los cambios realizados por esta incidencia. El registro de la lista de elementos modificados de cada petición se podrá realizar en el propio gregal y en los documentos ya existentes afectados por el cambio, opcionalmente, en un documento de cambios. Se intentarán extraer conclusiones de la modificación para mejorar la atención al usuario en caso que la incidencia se repitiera en el futuro. Esta información se utiliza para optimizar la atención al próximo grupo de incidencias por parte de CAU en niveles 1 y 2. Estas conclusiones se documentarán en Gregal ( u otros medios que disponga el CAU como Wikis, FAQs, etc. ).




Se podrá utilizar alguna de estas alternativas

• Se apuntará en gregal directamente los cambios realizados.

• Se apunta en gregal sólo el commit de SVN que contienen los cambios.

• Se apunta en gregal el documento que contiene los cambios.

Pruebas de Regresión

Descripción

Es necesario comprobar que los cambios que se lleven a cabo en los componentes afectados no produzcan otros efectos negativos sobre el mismo u otros componentes.

Procedimiento

Comprobar que los cambios provocados por una petición/incidencia no introduzcan un comportamiento no deseado o errores adicionales en otros componentes no modificados.

Modificación del manual de la aplicación

Descripción

Realizar las modificaciones que procedan en el manual de la aplicación reflejando las modificaciones efectuadas.

Procedimiento

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.

Entregable

Manual de la aplicación modificado.

Entrega al usuario y aceptación (por el usuario)

Descripción

Modificación de la aplicación en el entorno de producción.

Procedimiento

Paso de los módulos correspondientes a producción. Recepción de incidencias / Feedback del usuario.

Organización de la Documentación 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:

En estructura de ficheros P:\alumnado

ALU_RIOS

Plantillas de Documentos Documento de Control de cambios

• Debe servir como cuaderno de carga para la entidad encargada de la corrección (

programador de la casa o empresa externa)

• Debe incluir fechas de notificación del problema y fecha de aceptación de la solución por

parte del analista responsable. La fecha de aceptación implica que el analista ha realizado

pruebas de como mínimo, que el problema original ya no ocurre.

• Debe incluir la descripción del problema de forma completa de modo que la entidad

correctora sea capaz de reproducir el problema.

• Debe incluir la descripción de la solución.

Modelo <pincha aquí>



ANEXO I.- PROCESOS PEGASUS ASICA04.

Tabla de pegasus del proceso de mantenimiento no planificado.

PANTILLAS DE

DOCUMENTOS

Título del Documento

Proyecto: Plantilla

Fichero: PLA_ACTA.docx Versión: 1.0

Fecha Actualización:

22 de noviembre de 2011 Pág. 1 de 1

Tí tulo del Documento

Acta de Reunión Proyecto: Fecha:

Lugar: Horario: << inicio – fin >>

Asistentes

Nombre Organización / Departamento

Orden del día, Temas a tratar << REDACTAR AQUÍ ANTES DE LA REUNION LA RELACION DE TEMAS A TRATAR>>

Puntos Abordados / Decisiones Tomadas Describir los temas tratados en la reunión

Observaciones Apuntar las observaciones y conclusiones finales

Nota: Debe redactarse este modelo teniendo en mente que el acta debe servir para:

1) Poner al día a alguien que no pudo asistir a la reunión para que pueda saber qué decisiones se tomaron, cuál fue el proceso, conclusiones de la reunion, etc.

2) Dejar constancia y servir de recordatorio futuro para quienes sí asistieron, sobre los temas tratados y decisiones acordadas.

IdTarea: NombreTarea

Proyecto: Fichero: PROY_REQUISITOS Versión: 1.0




Identificación de la Tarea

Descripción de la Tarea **********

Trabajo a Realizar

< ELIMINAR DEL DOCUMENTO DEFINITIVO:

Detallar cada una de las acciones que tiene que hacer el desarrollador. Especificar

claramente las modificaciones que se deben hacer sobre :

Modelo de datos

Paquetes PL/SQL de BD

Clases Java.

Developer.

Reports

Manual de usuario

Otras modificaciones

Para cada modificacion, debe explicarse de forma precisa y clara que se ha de hacer, sin

ambigüedades y al nivel de detalle necesario para que sea perfectamente entendible por

el desarrollador.

Sobre el documento original entregado por el analista, el programador irá modificando el

texto para que sirva de diario de trabajo. Cualquier añadido o enmienda del contenido

original debe incluir obligatoriamente la fecha y el nombre de la persona que hace el

cambio.

Al acabar el encargo, este documento sirve de registro de todo cuanto se hizo, sin

menoscabo de cualquier otra documentacion que se haga en gregal, código, requisitos,

etc.>

Id Tarea/Gregal: Pr:

Proyecto: Fecha:

Nombre: : Requisito: 1

Módulos Afectados:


Proyecto: Fichero: PROY_REQUISITOS Versión: 1.0



1. Subtarea 1

2. Subtarea 2

Validación/Pruebas < ELIMINAR DEL DOCUMENTO DEFINITIVO: EN ESTA SECCIÓN SE DEBEN INCLUIR LAS PRUEBAS UNITARIAS QUE DEBE PASAR EL MÓDULO O LA FORMA DE VALIDAR QUE EL TRABAJO ESTÁ TEMINADO CORRECTAMENTE>

Documentación a Generar < ELIMINAR DEL DOCUMENTO DEFINITIVO: SI LA TAREA REQUIERE GENERAR DOCUMENTACIÓN O ACTUALIZAR DOCUMENTACIÓN EXISTENTE SE DEBE ESPECIFICAR EN ESTA SECCIÓN>


Proyecto:

Fichero: PLA_PROY_DEF.docx Versión: 1.0




Código y nombre del proyecto (Describir los antecedentes y el contexto del proyecto y por qué se decidió llevar a cabo.)

Organización del proyecto Es importante entender quienes son los jugadores principales en el proyecto. Un organigrama funciona muy bien. Otra manera de hacerlo es listar los roles principales del proyecto y la gente que estará ocupando cada uno de ellos.

(Borrar este comentario de la versión final de este documento)

Una estructura organizacional apropiada es esencial para alcanzar el éxito. La siguiente

lista muestra la organización propuesta para el proyecto:

Rol Responsable

Promotor:

Jefe Proyecto ASIC:



Objetivos del proyecto Los objetivos son declaraciones que describen lo que este proyecto alcanzará y entregará. Los objetivos deben ser “Metas” Mesurables Específicos restringidos por el Tiempo, Alcanzables y Sensatos o realistas. Para ser específicos y concretos, los objetivos deben estar basados en entregables. La obtención de un objetivo debe ser evidente a través de la creación de uno o más entregables. Si la declaración es de alto nivel y no implica la creación de entregables, puede tratarse de una meta o un fin. Si la declaración es de muy bajo nivel y describe características y funciones, puede ser una declaración de requerimientos.


Este proyecto cumplirá con los siguientes objetivos:

Objetivo 1

Objetivo 2

Objetivo 3


Proyecto:

Fichero: PLA_PROY_DEF.docx Versión: 1.0



Aplicaciones involucradas en el Proyecto Especificar las áreas o grupos afectados por, o que pueden participar en, el proyecto. Esta sección debe ser extensa pero de alto nivel. No deben aparecer nombres de individuos, pero las organizaciones que éstos representan se incluyen aquí.


El impacto de este proyecto en otras organizaciones necesita ser determinado paras

asegurar que la gente adecuada y las áreas funcionales correspondientes son

involucradas y la comunicación es dirigida de manera apropiada.

Aplicación ¿Cómo se ve afectada o de que forma participa en el proyecto?

Plazo de realización previsto (Puede ser indeterminado) Las horas estimadas de esfuerzo y los costos del proyecto pueden ser presentados de diversas formas, incluyendo los costos por cada miembro del equipo, costos por entregable, costos por cada hito o costos por categoría (mano de obra, proveedores, viáticos, capacitación, suministros, etc.). También incluye una gráfica presentando la fecha de inicio del proyecto, los hitos principales y la fecha de término del proyecto. Los entregabeles incluidos en la gráfica de hitos, deben coincidir con los que se han descrito en este documento en la sección correspondiente.



Proyecto:

Fichero: PLA_PROY_REQ.docx Versión: 1.0




Código y nombre del proyecto (Describir los antecedentes y el contexto del proyecto y por qué se decidió llevar a cabo.)

Organización del proyecto Es importante entender quienes son los jugadores principales en el proyecto. Un organigrama funciona muy bien. Otra manera de hacerlo es listar los roles principales del proyecto y la gente que estará ocupando cada uno de ellos.


Una estructura organizacional apropiada es esencial para alcanzar el éxito. La siguiente

lista muestra la organización propuesta para el proyecto:

Rol Responsable

Promotor:

Jefe Proyecto ASIC:



Objetivos del proyecto Los objetivos son declaraciones que describen lo que este proyecto alcanzará y entregará. Los objetivos deben ser “Metas” Mesurables Específicos restringidos por el Tiempo, Alcanzables y Sensatos o realistas. Para ser específicos y concretos, los objetivos deben estar basados en entregables. La obtención de un objetivo debe ser evidente a través de la creación de uno o más entregables. Si la declaración es de alto nivel y no implica la creación de entregables, puede tratarse de una meta o un fin. Si la declaración es de muy bajo nivel y describe características y funciones, puede ser una declaración de requerimientos.


Este proyecto cumplirá con los siguientes objetivos:

Objetivo 1

Objetivo 2

Objetivo 3


Proyecto:

Fichero: PLA_PROY_REQ.docx Versión: 1.0



Aplicaciones involucradas en el Proyecto Especificar las áreas o grupos afectados por, o que pueden participar en, el proyecto. Esta sección debe ser extensa pero de alto nivel. No deben aparecer nombres de individuos, pero las organizaciones que éstos representan se incluyen aquí.


El impacto de este proyecto en otras organizaciones necesita ser determinado paras

asegurar que la gente adecuada y las áreas funcionales correspondientes son

involucradas y la comunicación es dirigida de manera apropiada.

Aplicación ¿Cómo se ve afectada o de que forma participa en el proyecto?

Plazo de realización previsto (Puede ser indeterminado) Las horas estimadas de esfuerzo y los costos del proyecto pueden ser presentados de diversas formas, incluyendo los costos por cada miembro del equipo, costos por entregable, costos por cada hito o costos por categoría (mano de obra, proveedores, viáticos, capacitación, suministros, etc.). También incluye una gráfica presentando la fecha de inicio del proyecto, los hitos principales y la fecha de término del proyecto. Los entregabeles incluidos en la gráfica de hitos, deben coincidir con los que se han descrito en este documento en la sección correspondiente.


Requisitos Técnicos

Proyecto: Fichero: PLA_PROY_REQTEC.docx Versión: 1.0



Requisitos Te cnicos

Datos Proyecto Proyecto: Versión:

Cliente: Fecha:

Responsable ASIC:

Descripción Breve descripción del proyecto para poner en contexto a los técnicos

Recursos de Bases de Datos Usuario/bbdd: DESA:S/N PRE:S/N PRO: S/N

Descripción:

Espacio(Mb): Inicial: XXXX Previsión Anual: XXXX

DBLINKS:

Permisos:

Observaciones:

Copiar la tabla si se necesita más de un usuario

Servidores de aplicaciones Tipo: Weblogic/Tomcat…. DESA:S/N PRE:S/N PRO: S/N

Máquina: Usuario ftp: Versiones: SO: Servidor Aplicaciones:

Copiar la tabla si se necesita más de un servidor

Estimaciones de Carga Nº Usuarios concurrentes:

Estacionalidad: Horario Uso: Tamaño Aplicación:

Otros recursos

Recurso Descripción y Otros datos necesarios

Ej: Recurso de Red

Ej: Espacio en Subversion

Metodología para la gestión de proyectos

Documents

Transcript of Metodología para la gestión de proyectos