wordpress.com · web view2016/05/01 · nombre del entregable e2: documentos de la administración...

UNIVERSIDAD FRANCISCO DE PAULA SANTANDERPROGRAMA DE INGENIERIA DE SITEMA

GRUPO “GIDIS”PROYECTO “ ”

PLAN DE GESTION DE PROYECTO -PGP

IDENTIFICACIÓN: AD-PGP-01FECHA

EMISIÓN:Versión: 1.0

Elaborado: <Indique nombre del responsable del documento>

Aprobado: <Persona que revisó y aprobó el formato> Fecha: <Fecha revisado>






Tabla de contenido

Tabla de contenido1. Plan de gestión de alcance

1.1. Definir entregables y sub-entregables del proyecto

1.2. Estructura desglosada de trabajo

1.3. Recopilar requisitos

1.4. Actores y casos de uso del sistema








INTRODUCCIÓN

Propósito

Este documento, tiene como finalidad entregar las pautas y definir la estrategia que se seguirá para llevar a cabo el Plan de Gestión de Proyecto PGP del sistema de información para el control y gestión de reliquidación de la matrícula académica para los estudiantes de la Universidad Francisco de Paula Santander

Objetivo del Plan

Establecer la cronología y condiciones para para que se cumpla con los plazos pactados, y las estrategias diseñadas para el desarrollo y entrega del sistema de información de reliquidación de la matrícula académica para los estudiantes de la Universidad Francisco de Paula Santander en el tiempo señalado.








1. PLAN GESTION DE ALCANCE

1.1 DEFINIR ENTREGABLES Y SUBENTREGABLES DEL PROYECTO

Nombre del Entregable E1: SIGCME-UFPSId Sub-

EntregableSub-Entregable Descripción Criterio de

AceptaciónFecha de entrega

Responsable

E1.1 Modulo final de la aplicación

Aplicación web completamente funcional, junto con la respectiva documentación.

Equipo de desarrollo.

Nombre del Entregable E2: Documentos de la administración del proyectoId Sub-


AceptaciónFecha de entrega

Responsable

E2.1 Documentos de la planificación Son los documentos que tratan sobre el establecimiento del personal, PGP, metodología.

E2.2 Documentos del control y seguimiento

Son los documentos que se encargara del control de las actividades.

E2.3 Documentos de la ejecución Son los documentos que se encarga de la manera como se ejecutarán todos los procesos del análisis, diseño, desarrollo e implementación.

E2.4 Documentos del cierre Es la documentación cuando ya se haya realizado todo los procesos de análisis, diseño, desarrollo e implementación.








Nombre del Entregable E3: Modelado del negocioId Sub-


AceptaciónFecha

de entrega

Responsable

E3.1 Documento del modelado del negocio

Información respecto a la problemática que se presenta, y en la forma en que se aborda para desarrollar el trabajo.

E3.2 Diagramas de actividades Documento con las actividades que se realiza los diferentes actores dentro del sistema de información.

E3.3 Diagramas y especificación de los casos de uso

Documento con los diferentes casos de uso que tiene la aplicación con su debida información de la funcionalidad de cada uno.

E3.4 Requerimientos funcionales Documento con todos los requerimientos y descripción para la completa funcionalidad de la aplicación.

E3.5 Diagrama de robustez Documento con los diagramas de robustez o también llamados diagramas de secuencia.

E.3.6 Modelo de datos Documento con el modelo de datos o MER








y la debida especificación

Nombre del Entregable E4: DOCUMENTO SOPORTE TECNICO Id Sub-


AceptaciónFecha de Entrega

Responsable

E4.1 Manual del usuario Manual que se entrega para poder tener conocimiento de cómo funciona el software.

E4.2 Manual del sistema Descripción de las características de los equipos de cómputo para su correcto funcionamiento.

Ficha técnica del software Información del producto SICME.








1.2 EDT DEL PROYECTO








1.3 RECOPILAR REQUISITOS

REQUISITOS DE USUARIO

1. ESPECIFICACIÓN DETALLADA DE REQUISITOS.

No. Descripción del requisito1 El sistema debe permitir el ingreso a los estudiantes de la UFPS

2 El sistema debe permitir a los estudiantes de la UFPS diligenciar el formulario de solicitud de reliquidación de la matrícula académica

3 El sistema debe permitirle al trabajador social el ingreso al sistema

4 El sistema debe permitirle al trabajador social verificar si el estudiante ya realizo el procedimiento de reliquidación anteriormente

5 El sistema debe permitirle al trabajador social registrar una nueva solicitud de reliquidación

6 El sistema debe permitirle al trabajador social listar a los estudiantes por comunas

7 El sistema debe permitirle al trabajador social diligenciar el formulario de visita domiciliaria

8 El sistema debe permitir al jefe de Bienestar Universitario asignar clave a los trabajadores sociales para su ingreso al sistema

9 El sistema debe permitirle al jefe de Bienestar Universitario controlar las fechas de inicio y fin de proceso de reliquidación

10 El sistema debe permitirle al jefe de Bienestar Universitario consultar y verificar las actividades que realiza el trabajador social

11 El sistema debe permitirle al jefe de Bienestar Universitario enviar una respuesta a los estudiantes que hacen la solicitud de reliquidación

12 El sistema debe permitir generar reportes de la visita domiciliaria.

13 El sistema debe permitir generar un reporte con la información estadística o cuantificada de las solicitudes y sus respectivas respuestas.

14 El sistema debe permitirle el ingreso a la jefe de la División de servicios asistenciales y de la salud








15 El sistema debe permitirle el ingreso a las trabajadoras sociales

1.4 ACTORES Y CASOS DE USO DEL SISTEMA

Actores:

Estudiante

Trabajador Social

Jefe de Bienestar

Casos de Uso

Llenar formulario solicitud de reliquidación

Ver respuesta de solicitud

Verificar que un estudiante haya realizado el proceso de solicitud

Asignar los estudiantes por comunas

Iniciar un nuevo caso de solicitud

Llenar formulario visita domiciliaria

Enviar respuesta de solicitud








1.5 RESUMEN DE LA METRICA








2. PLAN GESTION DE TIEMPO

2.1 DEFINIR ACTIVIDADES

< En este proceso se procede a numerar la lista de actividades, y realizar la pregunta, sí se considera que la lista de actividades son las suficientes para cumplir con los entregables identificados.>

Id actividad Descripción o nombre de la Actividad

2.2 SECUENCIA DE ACTIVIDADES

< Se define la relación que existe entre las actividades. Se recomienda que defina, si va a trabajar con predecesora ó sucesora, al final se debe diseñar gráficamente el Modelo de Ruta Crítica – CPM.

Id actividad Nombre de la Actividad

PREDECESORA








2.3 ESTIMACIÓN DE RECURSOS:

< Determinar el tipo, cantidad y disponibilidad de los recursos (personas, equipos o materiales) para ejecutar las actividades del proyecto >


Tipo de Recurso Descripción del Recurso

Cantidad

2.4 ESTIMACIÓN DE DURACIÓN DE LAS ACTIVIDADES: Elaborado: <Indique nombre del responsable del documento>







< Consiste en tomar información del alcance y los recursos del proyecto y con base en esta información estimar la duración de las actividades…> Se recomienda copie los datos obtenidos del punto (Secuencia de Actividades) y el Diagrama CPM, y junto con los recursos asignados, identifique el tiempo de duración para realizar la actividad. (Entre las herramientas para la estimación del tiempo se cuenta con juicio de expertos y el análisis de proyectos similares a través de la información histórica, ahora en los proyectos de Desarrollo de Software se cuenta con métricas como la de “Puntos de casos de uso”.


Predecesora Duración (Semanas /

Días)

Anexar el CPM del proyecto

< se debe ilustrar gráficamente el Modelo de Ruta Crítica, indicar en color la ruta o rutas críticas que puede presentarse>

2.5 DESARROLLO DEL CRONOGRAMA:

< El desarrollo del cronograma significa determinar las fechas de inicio y terminación de las actividades del proyecto. >..”. Se recomienda hacer uso de una herramienta informática como el Ms-Project.


Predecesora Duración (Semanas /

Días)

Fecha de Inicio

Fecha Final








3.PLAN GESTION DE COSTOS

3.1 DETERMINAR EL PRESUPUESTO

RECURSO HUMANO:

<En esta parte del presupuesto se puede entregar de manera clasificada>

COSTOS OPERACIONALES:

COSTOS ORGANIZATIVOS:

COSTOS DE INVERSION

RESUMEN PRESUPUESTO








4. PLAN DE GESTION DE RIESGOS

EDR (Estructura Desglosada de Riesgos)








4.1 IDENTIFICACIÓN DE RIESGOS.

PROCESO EN EL QUE ESTA INVOLUCRADO EL RIESGO (1)COD. (1)

Riesgo(2) CAUSAS (Factores Internos y externos, agente generador) (3)

EFECTOS (CONSECUENCIAS) (4)

WBS (5) (ESE RIESGO COMO IMPACTA AL CRONOGRAMA)

1 Cambio del Jefe de la división de Servicios Asistenciales y de Salud

Traslado a otra dependencia de la Universidad

Terminación del contrato durante el desarrollo del sistema

Hay que solicitar nuevas reuniones para presentación y explicación del sistema

Esperar posibles cambios por parte del nuevo Jefe

Atraso 8 días o más y se puede presentar en cualquier parte del proyecto.

2 Compañeros de desarrollo del proyecto renuncian

Falta de tiempo

Cancelación de semestre

Aumento de tareas o actividades a los demás integrantes del grupo

Atraso 10 días o más que se puede presentar en el momento que el compañero se retire del proceso.

3 El servidor para la Base de Datos solicitado no ejecuta la versión con la que fue desarrollada el proyecto

Falta de recursos para la obtención de un Servidor de B.D en la UFPS

No se tienen los recursos o licencias propias de actualización

Se origina retrasos durante el tiempo que demore la obtención de las nuevas versiones y/o actualizaciones

Retraso durante el periodo de pruebas

4 Falta de cableado La Universidad no haya Espera hasta que se Atraso en el Elaborado: <Indique nombre del responsable del documento>







en las oficinas de Bienestar Universitario al momento de implementar el proyecto

aprobado el cableado necesario para Bienestar Universitario a la hora de implementar el sistema.

La red cableada no es compatible para la instalación del sistema

obtenga una red instalada y compatible con el sistema

periodo de pruebas e implementación del sistema

5 Poca colaboración de parte de administrativos de Bienestar Universitario con el traspaso de los formatos y procesos que debe abarcar el sistema

No conocen a cerca de la implantación del nuevo sistema.

Incertidumbre por parte de los desarrolladores a cerca de los procesos que debe realizar el sistema

Se originan retrasos en la captura de requerimientos

Recolección de información errónea o desactualizada

Retraso en lafase de análisisy diseño del sistema.

6 Aplazamiento de las reuniones con la Doctora Consuelo Suarez, Jefe de división de Servicios Asistenciales y de Salud

Constantes reuniones de mayor prioridad de parte de la Jefe para con la Universidad

Poca disposición de tiempo por parte del equipo de desarrollo

Atraso en la obtención de requerimientos

Retraso en lafase de análisisy diseño del sistema.

(1) Código: identificación del riesgo de acuerdo con la EDR y al proceso, debe llevar un número consecutivo para enumerar los que se presenten del mismo tipo, el cual servirá para seguimiento y control a lo largo del proyecto.

(2) Riesgo: describir el riesgo el cual representa la posibilidad de ocurrencia de un evento que pueda entorpecer el normal desarrollo del proyecto y afectar el logro de sus objetivos.








(3) Causas (factores internos o externos): Son los medios, las circunstancias y agentes generadores de riesgo. Los agentes generadores que se entienden como todos los sujetos u objetos que tienen la capacidad de originar un riesgo.

(4) Efectos (consecuencias): Constituyen las consecuencias de la ocurrencia del riesgo sobre los objetivos del proyecto.

(5) WBS: Localización del riesgo dentro de la WBS del proyecto.

4.2 ANÁLISIS DE RIESGOS.

<Completar la matriz calculando la probabilidad, impacto y el valor total del riesgo y luego clasificarlo dependiendo de los colores de escala del riesgo para priorizarlos. Los riesgos de color rojo deben quedar de primero por lo que son los riesgos que se deben resolver con prioridad>.

Para la medición del impacto se utiliza las mediciones de la siguiente matriz de definición de riesgos:

Análisis de impacto:

Impacto Escala Definición de Categorías

Catastrófico 5

Un evento, si ocurre, causaría fallas en el proyecto (inhabilita el

alcance de los requerimientos mínimos aceptables).

Mayor 4

Un evento, si ocurre, causaría incrementos severos en el costo y el

tiempo. Requerimientos secundarios pueden no ser alcanzados.

Moderado 3

Un evento, si ocurre, causaría incrementos moderados en el costo y el

tiempo, pero los requerimientos importantes pueden aún lograrse.

Menor 2

Un evento, si ocurre, causaría incrementos bajos en el costo y el

tiempo. Los requerimientos pueden ser alcanzados.

Insignificante 1 Un evento, si ocurre, no tendría efecto en el proyecto.








Análisis de probabilidad:

La medición de la probabilidad es un elemento netamente estadístico. Si no se cuenta con datos

estadísticos se puede recurrir al juicio de expertos. De lo contrario podemos trabajar con los siguientes

valores para los proyectos de TI, acordes con el documento guía de administración del riesgo..

Criterio Probabilidad

Casi certeza 5

Probable 4

Moderada 3

improbable 2

raro 1

Matriz de Probabilidad e impacto:

Impacto Muy Bajo Bajo Moderado Alto Muy AltoProbabilidad 1 2 3 4 5

5 5 10 15 20 254 4 8 12 16 203 3 6 9 12 152 2 4 6 8 101 1 2 3 4 5








Clasificación del RiesgoRango de

PXI Riesgo bajo 1-4 Riesgo Moderado 5-11 Riesgo Alto 12-25

Puntuar cada uno de los riesgos del proyecto de acuerdo con el análisis de probabilidad por impacto completando la matriz de identificación de riesgos.

ANALISIS Y CLASIFICACION DE LOS RIESGOS DEL PROYECTO

Código(1) Riesgo(2) Probabilidad(6) Impacto(7) Total(8)

6 Aplazamiento de las reuniones con la Doctora Consuelo Suarez, Jefe de división de Servicios Asistenciales y de Salud

4 3 12

4 Falta de cableado en la oficina de Bienestar Universitario al momento de implementar el proyecto

3 3 9


3 3 9


2 2 4

5 Poca colaboración de parte de administrativos de Bienestar Universitario con el traspaso de los formatos y procesos que debe abarcar el sistema

2 2 4

3 El servidor para la Base de Datos solicitado no ejecuta

2 2 4








la versión con la que fue desarrollada el proyecto

(6) Probabilidad: entendida como la posibilidad de ocurrencia del riesgo

(7) Impacto: consecuencias que puede ocasionar al proyecto la materialización del riesgo.

(8) Total: Resultado de multiplicar probabilidad por impacto.

En esta parte se deben clasificar los riesgos colocando de primero los riesgos altos, para continuar con la etapa de planificación de riesgos.

4.3 PLANIFICACIÓN DE LA RESPUESTA A RIESGOS.

<Se define lo que se hará con los riesgos para tratarlos, pero a medida que avance el proyecto se debe realizar las actividades de identificar, analizar y luego planificar los riesgos. En esta parte de la planificación tener en cuenta:

Se definen los planes de mitigación apropiada y/o planes de contingencia de acción.

Se discute sobre los riesgos que pueden ser considerados sensibles o confidenciales y, en su caso, consulte con Jurídicos. Se revisan los riesgos recientemente identificados.

Se establece un rango relativo entre los riesgos existentes y revisar el riesgo en combinación con otros riesgos.

Se deben ajustar las asignaciones de recursos, planes de acción, o cualquier otra prioridad del proyecto para asegurar el riesgo es tratado adecuadamente>.

PLANIFICACION DE LOS RIESGOS DEL PROYECTO








Código (1) Riesgo (2) Total (8) Acciones (9)

Responsable (10) Cronograma (11) Indicador (12)

6 Aplazamiento de las reuniones con la Doctora Consuelo Suarez, Jefe de Bienestar

12 Firmar una carta con el compromiso de asistencia, autorizada por

el UGAD

Andrés Ariza

Cambios en el cronograma máximo de 4

días

Se realizan las entrevistas

necesarias y se deja acta por escrito para

evitar al máximo este riesgo


9 Instalar una aplicación que preste los servicios apropiados como servidor local.

Heiner Villamizar

Cambios en el cronograma máximo de 3

días

Se quiere mitigar el riesgo

usando un servidor local en

caso de que la red no este

instalada en el momento de la implementación


9 Repartir las tareas del

excompañero a los integrantes que quedan de

una manera equitativa

Gladys Carrillo

Cambios en el cronograma en el

momento que renuncia o se

retira un compañero


6 Realizar ua reunión para explicar las

funciones del sistema y recolectar

requerimientos

Andres Ariza

Cambios en el cronograma en la fase de Análisis

y diseño, máximo 10 días.

Se presenta ante el nuevo jefe el proyecto con sus respectivas pruebas y se replantean los requerimientos necesarios para que el cliente quede satisfecho

5 Poca colaboración de parte de

4 Solicitar a la Gladys Cambios en el Si se llega a








administrativos de Bienestar Universitario con el traspaso de los formatos y procesos que debe abarcar el sistema

jefe una carta para que los

administrativos puedan

colaborar con informacion

necesari

Carrillo cronograma en la fase de Análisis

y diseño, máximo 5 días

presentar el riesgo de gestiona un plan de pruebas con los administrativos de Bienestar Universitario y se les dé a conocer el sistema que se quiere realizar


4 Actualizar el servidor con

las aplicaciones requeridas

Heiner Villamizar

Cambios en el cronograma en la fase de pruebas, máximo 3 días

Se gestiona una reunión con los administradores de la BD para presentar el

riesgo y poder mitigarlo

(9) Acciones: es la aplicación concreta de las opciones de manejo del riesgo que entrarán a prevenir o a reducir el riesgo y harán parte del plan de manejo del riesgo, se debe indicar si la acción está orientada a mitigar/transferir/aceptar el riesgo. Las acciones preventivas de los riesgos deben hacer parte de la línea base del cronograma, por lo tanto del alcance del proyecto.

(10) Responsable: encargados dentro del proyecto de adelantar las acciones propuestas.

(11) Cronograma: son las fechas establecidas para implementar las acciones por parte del grupo de trabajo.

(12) Indicadores: se consignan los indicadores diseñados para evaluar el desarrollo de las acciones implementadas.








4.4 MONITOREO DE LOS RIESGOS.

< El seguimiento, monitoreo y control de los riesgos sirve para determinar como el riesgo está progresando así como cualquier estrategia de mitigación/contingencia que haya sido ejecutada. Cuando el riesgo cambia, se debe repetir el proceso de identificar, analizar y planear. Se deberá modificar el plan de acción existente para cambiar el planteamiento en caso que no se esté logrando el efecto deseado>.

MONITOREO DE LOS RIESGOS DEL PROYECTOCódigo (1) Riesgo (2) Estado (13) Descripción de la situación a la fecha (14) Fecha(15) Firma (16)

6 Aplazamiento de las reuniones con la Doctora Consuelo Suarez, Jefe de la división de Servicios Asistenciales y de Salud

Seguimiento Se han realizado 3 reuniones para verificar los posibles cambios que pueda tener el sistema y así poder afirmar y/o asegurar que no se presenten cambios en los requerimientos en tiempo futuro.

10/03/16


Activo En la última reunión se observó que la dependencia no cuenta con los puntos de red a internet necesarios para la instalación de nuevos equipos, por lo que se acordó realizar un oficio para entregar al departamento de redes haciendo la solicitud de dicha instalación

10/03/16


Seguimiento En las reuniones de control, seguimiento y desarrollo del proyecto se ha acordado que los 3 integrantes del grupo continuaran hasta el final del proyecto independientemente de sus demás interés u obligaciones

10/03/16

1 Cambio del Jefe de la división de Servicios Asistenciales

Seguimiento Hasta la fecha, no se han visualizado cambios en el personal de la división de Servicios Asistenciales y de Salud; sin embargo se estará en constante monitorio con el fin de verificar que el personal sea el mismo

10/03/16








y de Salud5 Poca

colaboración de parte de administrativos de Bienestar Universitario con el traspaso de los formatos y procesos que debe abarcar el sistema

Retirado Hasta el momento todas las personas encargadas de brindar información a cerca del proceso son conscientes del beneficio del sistema y han colaborado con la información necesaria.

10/03/16


Seguimiento Hasta la fecha se ha usado un servidor local para hacer las pruebas; pero se le informo a los encargados del servidor (Sandbox) para en caso de presentarse este riesgo, se pueda solucionar los más pronto posible

10/03/16

(13) Estado: Activo - Seguimiento - Retirado

(14 ) Descripción de la situación a la fecha: Indicar brevemente en que va el riesgo.

(15) Fecha: colocar fecha de estudio del riesgo.

(16) Firma: el responsable del riesgo debe firmar








5. PLAN DE GESTION DE LOS RECURSOS HUMANOS

5.1 ESTRUCTURA ORGANIZACIONAL DEL PROYECTO.

Luego de identificar los conocimientos y habilidades necesarias para realizar el proyecto, se determinó

el equipo necesario, el cual se presenta mediante el siguiente diagrama organizacional, el cual incluye

las personas y las dependencias que se tomarán en cuenta para realizar las actividades.

(realizar la estructura de mandos….patrocinador, equipo de dirección y equipo de trabajo)

5.2 ROLES Y RESPONSABILIDADES

Patrocinador del proyecto: Inversionista del proyecto, brindará los recursos necesarios

para la ejecución del proyecto, dará visto bueno a los avances del proyecto, además

trabajará en diversos aspectos que serán requeridos en la ejecución del proyecto.

Director del proyecto: Es un Ingeniero Industrial con Conocimientos técnicos en el área de

metrología y calibración de equipos. Es el principal responsable de que el proyecto sea

realizado con éxito y acorde con los requerimientos del patrocinador.

Representante en Morgan Hill: Será la persona responsable del proyecto en Morgan Hill,

además, coordinará todo lo que tenga relación con el proyecto en los Estados Unidos.

Técnico de calibraciones de equipos de MH: Será la persona responsable de realizar los

entrenamientos y ejecutar la mayoría de actividades a realizar en la planta ubicada en

California.








Equipo de proyecto: Este equipo tendrá la particularidad que estará ubicado en dos lugares

geográficamente distantes (Costa Rica y Morgan Hill). Será el encargado de dar el soporte

necesario al director para que el proyecto sea realizado con éxito y acorde a los requisitos

del patrocinador. Este equipo incluye un asistente del Director del Proyecto, el cual puede

ser el Técnico Líder de Calibración de equipos, además de este asistente se tiene un técnico

de calibraciones de equipos, así como un Supervisor de calidad y uno de Manufactura de las

áreas impactadas por este proyecto.

Una de las herramientas que más ayudan a planear y logran una integración entre los roles y responsabilidades del equipo de trabajo es la matriz de roles y funciones, la cual permite confirmar con los involucrados clave donde se requiere que apliquen sus conocimientos y habilidades con el fin de lograr el mejor aprovechamiento del equipo. El Cuadro 2. Matriz de Roles y Responsabilidades muestra el detalle

Cuadro 2. Matriz de Roles y Responsabilidades.

E Ejecuta, P Participa, C Coordina, R Revisa, A Autoriza

Matriz de Roles y Responsabilidades para el proyecto de Análisis, Diseño e Implementación de un sistema de información para la administración y gestión de las salas y equipos del departamento de sistemas

Patr

ocin

ador

Ger

ente

Coo

rdin

ador

de

Ana

lista

s

Coo

rdin

ador

de

Dis

eñad

ores

Ana

lista

-1

Ana

lista

-2

Ana

lista

-3

Dis

eñad

or-1

Dis

eñad

or-2

Des

arro

llado

r-1

Des

arro

llado

r-2

Des

arro

llado

r-3

Inge

nier

o de

pru

ebas

Inicio

Elaboración de Acta de ConstituciónR/A E

Lecciones Aprendidas E








Planeación Construcción del Cronograma E/R Elaboración de Presupuesto E/R Planeación de Recursos E/R

Elaboración del Plan de Capacitación del personal R/A E Lecciones Aprendidas E Análisis del Software Modelado del negocio

Elaboración de Diagrama de Actores del Negocio R/C E Realización de Diagramas BPMN del negocio R/C E

Realización de los Diagramas Actividades de los procesos del negocio

R/C E

Realización del Diagrama Dominio de Problema R/C E Modelado de Analisis

Levantamiento de Requerimientos Funcionales del Proyecto Mediante una Encuesta R/C/A E/R/C

Analisis de los Resultados obtenidos de el levantamiento de los requerimientos R E

Realizacion del Diagrama de Actores del sistema

R/C E

Elaboracion de el Diagrama Conceptual de los Casos de Uso del software R/C E








Construccion de los Diagramas Extendidos de los Modulos del software

R/C/A E lecciones aprendidas P P P Diseño del Software Levantamiento del Prototipo de Diseño de GUI E/C/R Modelado del Diseño

Creacion del Diagrama de Clases del Software R/C E

Eleccion de la Arquitectura del Sistema

E/R/C Elaboracion del Modelo Entidad Relacio (MER) del Software R/C E Elaboracion de los Diagramas de Secuencias de los modulos del softare R/C E E Lecciones Aprendidas P P P Implementacion

Desarrollo e Implementacion de Codigo por modulos E E E R/C

Elaboracion de Pruebas funcionales E/R/C E/R/C E/R/C

Lecciones Aprendidas P P P Pruebas Del Software

Desarrollo de Pruebas de Rendimiento

R E

Desarrollo de Pruebas de stress R E








Desarrollo de Pruebas de Seguridad y control de acceso R E

Desarrollo de Pruebas de Regresion R E

Desarrollo de Pruebas de Caja Blanca

R E

Desarrollo de Pruebas de Humo R E

Desarrollo de Pruebas de Desempeño R E

Desarrollo de Pruebas de Volumen R E

Desarrollo de Pruebas de recuperacion y tolerancia de fallas

R E

Desarrollo de Prueba de Estilo R E

Desarrollo de Prueba de Aceptacion

R E Seguimiento y control

Solicitud Informe de avance 1 R/C E P P P

Control de Cronograma / Presupuesto-1 E/R/C Solicitud Informe de avance 2 R/C E P P P

Control de Cronograma / Presupuesto-2 E/R/C










Solicitud Informe de avance 12 R/C E E P P P P P






Solicitud Informe de avance 15 R/C E P P








Solicitud Informe de avance 19 R/C E P P P P P E









Solicitud Informe de avance 20 R/C E P P P P P E


Solicitud Informe de avance 21 R/C P P P E




























Control de Cronograma / Presupuesto-47 E/R/C Lecciones Aprendidas P P P P Cierre

Elaboracion del Acta de AceptacionR/A E

Elaboracion del Acta de Cierre R/A E Lecciones Aprendidas P

5.3 HORARIO DE TRABAJO








5.4 EVALUACIÓN DEL DESEMPEÑO DEL EQUIPO








6. PLAN DE GESTION DE COMUNICACIONES

6.1 USO DE HERRAMIENTAS TECNOLÓGICAS

E-rooms: provee un espacio de trabajo virtual, donde la gente que se encuentra en diferentes

locaciones pueden colaborar en actividades comunes proyectos, y / o alcanzar metas. A través de la

creación de grupos de trabajo con diferentes privilegios se puede compartir, archivos, reportes,

fotos, etc.

Webex: Es una herramienta que permite de una manera fácil, compartir ideas con cualquier

persona en cualquier lugar. Es una combinación que permite compartir información y una

conferencia telefónica al mismo tiempo con personas en cualquier parte del mundo. Por medio

de esta herramienta las personas pueden ver la misma información a través de una computadora

y al mismo tiempo estar hablando a través de conferencia telefónica.

6.2 MATRIZ DE COMUNICACIONES

Periodicidad de ReporteInvolucrado

Semanal Quincenal Mensual Trimestre semestre Anual

Gerente de ProyectoLideresArquitectoDesarrollador








Tipo de informe SímboloCorreo electrónico @Reporte escrito ¡

6.3 INFORMAR EL DESEMPEÑO

Informes de Avance del Proyecto

Hacer referencia al informe de avances

Minutas de Reuniones

Hacer referencia al formato de minuta de reuniones








7. CONTROL DE CAMBIOS

7.1 CONTROL INTEGRADO DE CAMBIOS.

El Control Integrado de Cambios busca apoyar los requisitos de calidad del proyecto. De acuerdo a su tipo, los cambios se clasifican en:

Modificación en el alcance

Modificación en el presupuesto

Modificación en el cronograma

Modificación en las adquisiciones

Modificación en los Recursos

Modificación en las Comunicaciones

Modificación en los Riesgos

Otros

El proceso de Control Integrado de Cambios está integrado por las fases: Solicitud, Autorización, Preparación, Prueba, Implantación y Cierre.

Las etapas de de Solicitud, Autorización y Preparación dan inicio al proceso de Control Integrado de Cambios.

7.1.1 Solicitud. El Solicitante registrará la solicitud del cambio en el documento Solicitud de Cambios, especificando:

Nombre de la persona(s) que solicita(n) la modificación y fecha. Tipo de cambio Razón de la modificación Efecto en el costoElaborado: <Indique nombre del responsable del documento>







Efecto en el cronograma Observaciones, si son necesarias

Se propone la plantilla PS-01 para diligenciar la solicitud de cambios.

Una vez generada la solicitud, será enviada al Director del Proyecto, quien se encargará de estudiar la viabilidad de la misma.

7.1.2 Autorización. En esta fase, el Director del Proyecto registra el documento Solicitud de Cambios, asignando un número consecutivo y procederá a revisar el motivo del cambio solicitado.

Si el cambio es viable, asignará el Status de Aprobada a la solicitud, en caso contrario, el Status será de Rechazada y se notificará vía correo electrónico a las personas involucradas en la solicitud para que se le hagan los respectivos ajustes y vuelva a ser estudiada en la etapa de Autorización.

Luego de ser aprobada la solicitud, será archivada en un portafolio de Control de Cambios y se enviará una notificación vía correo electrónico a las personas involucradas en la solicitud.

7.1.3 Preparación. El objetivo de la etapa de Preparación es la revisión de la documentación. Al término de la revisión de los documentos, el responsable de la Preparación completará la fecha de revisión de documentos y observaciones, al cabo del cual se continuará con la fase de Prueba del cambio.








CUADRO 7.1 Plantilla Solicitud de cambios.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER GRUPO DE INVESTIGACION Y DESARROLLO DE INGENIERIA DEL

SOFTWARE “GIDIS”

SOLICITUD DE CAMBIOS

IDENTIFICACIÓN: FECHA


IDENTIFICACION DEL PROYECTOProyecto: No:

SOLICITUD DE CAMBIOSFecha de solicitud:Nombre de quien solicita el cambio:Tipo de cambio:Razón de la modificación:Posibles efectos en el costo del Proyecto:Posibles efectos en el cronograma del Proyecto:Observaciones:








7.1.4 Fase de Prueba. Permite verificar la funcionalidad del cambio realizado, registrar la fecha de la prueba, las observaciones y el estatus que se le dará al cambio, ya sea de Aprobado o Rechazado.

7.1.5 Fase de Implantación. Consiste en migrar el cambio al ambiente productivo. Una vez que el cambio fue probado exitosamente, el Director del Proyecto asignará un responsable de la implantación del cambio, al cual se le enviará una notificación.

7.1.6 Fase de Cierre. En esta fase el Patrocinador verificará que la modificación ha sido implantada satisfactoriamente en el ambiente de Producción. Finalizada la verificación, procederá a diligenciar el formato de Control de Cambios en la sección de Cierre. En el caso de que el Patrocinador apruebe el cambio introducido, el Director del Proyecto firmará el documento y colocará el sello de “Procesada” a la Solicitud que generó el cambio y procederá a archivarla y en caso contrario, el control de cambio retornará a la fase de Implantación o será archivada en el caso de que en la etapa de Preparación, el responsable de la misma ha rechazado la solicitud del cambio y el Director del Proyecto avala la decisión, previo diligenciamiento de las observaciones y evidencias que soportan el rechazo del cambio.

En caso de que la solicitud no cumpla con los requisitos de documentación establecidos, el responsable de la Preparación anotará los comentarios sobre la solicitud y los enviará al Director del Proyecto, quien se encarga de analizar los comentarios y avalará la decisión.

En la Figura 7.2 se explica mediante un diagrama de flujo el proceso de Control Integrado de Cambios.








Cuadro 7.2 Plantilla Control integrado de cambios.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER GRUPO DE INVESTIGACION Y DESARROLLO DE INGENIERIA DEL

SOFTWARE “GIDIS”SOLICITUD DE CAMBIOS IDENTIFICACIÓN:

FECHA EMISIÓN:

Versión: 1.0IDENTIFICACION DEL PROYECTO

Proyecto: No:SOLICITUD DE CAMBIOS

FASE FECHA OBSERVACIONESESTATUS

RESPONSABLENOMBRE ROL

Solicitud Indique la fecha en la que se inciio la fase

Registre la evidencia que soporta el cambio Aprobado Rechazado

Indique el nombre del responsable

Indique el rol del responsable

AutorizaciónPreparaciónPruebasImplantaciónCierre

FECHA DE ELABORACIONDD/MM/AA

ELABORADO PORNombre firma

Nombre del director del Proyecto Firma del director del Proyecto






Figura 7.2 Diagrama de flujo - Control integrado de cambios.

Fuente: Sara María Romero. 2011

wordpress.com · web view2016/05/01 · nombre del entregable e2: documentos de la administración...

Documents