metodología para la gestión de proyectos
Post on 02-Jan-2017
235 Views
Preview:
TRANSCRIPT
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
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
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
GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV.
Documento: GUIA_INICIO.docx 2/6 Versión: 1.0
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.
GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV.
Documento: GUIA_INICIO.docx 3/6 Versión: 1.0
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.
GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV.
Documento: GUIA_INICIO.docx 4/6 Versión: 1.0
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.
GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV.
Documento: GUIA_INICIO.docx 5/6 Versión: 1.0
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.
GUÍA METODOLÓGICA PARA EL DESARROLLO, MANTENIMIENTO E INTEGRACIÓN DE APLICACIONES DEL ASIC-A DE LA UPV.
Documento: GUIA_INICIO.docx 6/6 Versión: 1.0
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
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 2/16 Versión: 1.0
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
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 3/16 Versión: 1.0
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
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 4/16 Versión: 1.0
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.
Documentación a Generar
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:
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 5/16 Versión: 1.0
• 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.
Documentación a Generar
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.
Documentación a Generar
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.
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 6/16 Versión: 1.0
Identificar los recursos disponibles. Identificar pre-post condiciones en las tareas
Documentación a Generar
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.
Documentación a Generar
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.
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 7/16 Versión: 1.0
Documentación a Generar
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.
Documentación a Generar
Esta documentación se puede incluir en el propio cuaderno de carga o gregal.
Programación y pruebas unitarias
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.
Documentación a Generar
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.
Documentación a Generar
Incidencias de programación de un módulo.
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 8/16 Versión: 1.0
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)
Documentación a Generar
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.
Documentación a Generar
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.
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 9/16 Versión: 1.0
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.
Documentación a Generar
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
Documentación a Generar
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.
Documentación a Generar
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
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 10/16 Versión: 1.0
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
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 11/16 Versión: 1.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
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 12/16 Versión: 1.0
ANEXO1: DEFINICIÓN DEL PROCESO DE DESARROLLO DE APLICACIONES EN PEGASUS
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 13/16 Versión: 1.0
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 14/16 Versión: 1.0
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 15/16 Versión: 1.0
GUIA METODOLÓGICA PARA PROYECTOS DE DESARROLLO DE APLICACIONES
Documento: GUIA_DESARROLLO.docx 16/16 Versión: 1.0
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
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 2/8 Versión: 1.0
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
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 3/8 Versión: 1.0
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.
Documentación a Generar
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
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 4/8 Versión: 1.0
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) .
Documentación a Generar
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.
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 5/8 Versión: 1.0
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.
Documentación a Generar
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)
Programación y pruebas unitarias
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. ).
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 6/8 Versión: 1.0
Documentación a Generar
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:
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 7/8 Versión: 1.0
• 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í>
GUIA METODOLÓGICA PARA MANTENIMIENTO DE APLICACIONES
Documento: GUIA_MATNOPLAN.doc 8/8 Versión: 1.0
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
Fecha Actualización:
22 de noviembre de 2011 Pág. 1 de 2
IdTarea: NombreTarea
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:
IdTarea: NombreTarea
Proyecto: Fichero: PROY_REQUISITOS Versión: 1.0
Fecha Actualización:
22 de noviembre de 2011 Pág. 2 de 2
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>
Título del Documento
Proyecto:
Fichero: PLA_PROY_DEF.docx Versión: 1.0
Fecha Actualización:
22 de noviembre de 2011 Pág. 1 de 2
Tí tulo del Documento
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:
Participantes Comité Dirección:
Miembros equipo trabajo:
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.
(Borrar este comentario de la versión final de este documento)
Este proyecto cumplirá con los siguientes objetivos:
Objetivo 1
Objetivo 2
Objetivo 3
Título del Documento
Proyecto:
Fichero: PLA_PROY_DEF.docx Versión: 1.0
Fecha Actualización:
22 de noviembre de 2011 Pág. 2 de 2
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í.
(Borrar este comentario de la versión final de este documento)
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.
(Borrar este comentario de la versión final de este documento)
Título del Documento
Proyecto:
Fichero: PLA_PROY_REQ.docx Versión: 1.0
Fecha Actualización:
22 de noviembre de 2011 Pág. 1 de 2
Tí tulo del Documento
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:
Participantes Comité Dirección:
Miembros equipo trabajo:
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.
(Borrar este comentario de la versión final de este documento)
Este proyecto cumplirá con los siguientes objetivos:
Objetivo 1
Objetivo 2
Objetivo 3
Título del Documento
Proyecto:
Fichero: PLA_PROY_REQ.docx Versión: 1.0
Fecha Actualización:
22 de noviembre de 2011 Pág. 2 de 2
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í.
(Borrar este comentario de la versión final de este documento)
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.
(Borrar este comentario de la versión final de este documento)
Requisitos Técnicos
Proyecto: Fichero: PLA_PROY_REQTEC.docx Versión: 1.0
Fecha Actualización:
22 de noviembre de 2011 Pág. 1 de 1
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
top related