PLAN DE DIRECCION DEL PROYECTO GUÍA TURÍSTICA CON GESTIÓN DE RESERVAS Y PAGOS VÍA WEB

8/19/2019 PLAN DE DIRECCION DEL PROYECTO GUÍA TURÍSTICA CON GESTIÓN DE RESERVAS Y PAGOS VÍA WEB

1/37

PLAN DE DIRECCIÓN DE PROYECTO

1.0.R01 Versión: 1.0 Fecha: 26/03/2015

GGUUÍA A TTUURRÍSSTTIICC A A CCOONN GGEESSTTIIÓÓNN DDEE RREESSEERRVV A ASS YY

PP A AGGOOSS VVÍÍ A A WWEEBB

PLAN DE DIRECCIONDEL PROYECTO

GGUUÍÍ A A TTUURRÍÍSSTTIICC A A CCOONN GGEESSTTIIÓÓNN DDEE RREESSEERRVV A ASS YY

PP A AGGOOSS VVÍÍ A A WWEEBB

Universidad Continental -Versión 1.0

Actualizado aMarzo del 2015


2/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 2 de 37

HISTORIAL DE LAS REVISIONES

Item Versión Fecha Autor Descripción EstadoResponsable de

Revisión y/o Aprobación

1 0.1 28/03/2015 Victor Quispe Versión inicial En Revisión Pedro CastañedaVargas


3/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 3 de 37

TABLA DE CONTENIDO

1. INTRODUCCIÓN .................................................................................................... 4 1.1. PROPÓSITO DEL PLAN .................................................................................................. 4 1.2. TERMINOS, ACRONIMOS Y DEFINICIONES ................................................................. 4 1.3. REFERENCIAS ..................................................................... ¡Error! Marcador no definido. 2. RESUMEN EJECUTIVO ........................................................................................ 5 3. ANTECEDENTES .................................................................................................. 6 4. OBJETIVO DEL PROYECTO ................................................................................ 6 4.1. OBJETIVO GENERAL ..................................................................................................... 6 4.2. OBJETIVO ESPECIFICO ................................................................................................. 7 5. ALCANCE .............................................................................................................. 7 5.1. DESCRIPCION DE LOS PROCESOS DE NEGOCIO ...................................................... 8 5.2. ALCANCE DEL PRODUCTO ........................................................................................... 9 5.3. ALCANCE DEL PROYECTO ........................................................................................... 9 5.4. FUERA DE ALCANCE ................................................................................................... 10


4/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 4 de 37

1. INTRODUCCIÓN

1.1. PROPÓSITO DEL PLAN

El presente documento describe los lineamientos a seguir para el desarrollo e

implementación de “Guía turística con gestión de reservas y pagos vía web.”,

estableciendo los objetivos, alcance, recursos, actividades y responsabilidades, lo

cual permitirá luego de su aprobación dar inicio a las etapas de Ingeniería del

proyecto.

1.2. TERMINOS, ACRONIMOS Y DEFINICIONES

Término Definición

APACHE Es programa de servidor HTTP Web de código abierto (opensource).

HOST Servidor que nos provee de la información que requerimos pararealizar algún procedimiento desde una aplicación cliente

HOSTING

El servicio de Web Hosting consiste en el almacenamiento de

datos, aplicaciones o información dentro de servidores diseñadospara llevar a cabo esta tarea.

RESPONSIVEEs una filosofía de diseño y desarrollo cuyo objetivo es adaptar laapariencia de las páginas web al dispositivo que se estéutilizando para visualizarla

BASE DE

DATOSEs un conjunto de datos pertenecientes a un mismo contexto yalmacenados sistemáticamente para su posterior uso

ANDROID Es un sistema operativo basado en el kernel de Linux diseñadoprincipalmente para dispositivos móviles con pantalla táctil.

Acrónimo Definición

HTML Es un lenguaje para crear documentos de hypertextopara uso en el www

PHP Hypertext Preprocessor. Lenguaje de script diseñadopara la creación de páginas web activas

POOProgramación Orientada a Objetos - una serie denormas de desarrollo que aseguren y faciliten lamantenibilidad y reusabilidad del código


5/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 5 de 37

2. RESUMEN EJECUTIVO

El proyecto “Guía turística con gestión de reservas y pagos vía web”, es una aplicación

que consiste en el uso de tecnología virtual a través de aplicaciones móviles las cuales

están basadas en ANDROID y funcionan a través de una previa conexión a internet.

Consiste en Mostrar a los turistas y público en general la variedad de lugares turísticos

para visitar, con una nueva forma de interacción y brindarles la opción de gestionar sus

reservas y compras.

El desarrollo del sector turístico es un fenómeno que se ha disparado últimamente como

consecuencia de toda una serie de factores, entre los que cabe destacar la creciente

globalización, los cambios en la demanda, la flexibilidad en los trámites de fronteras, el

descanso creciente retribuido, el aumento de la competencia o la aceleración del

desarrollo y difusión de nuevas tecnologías, entre las que se encuentran las de

información y comunicación.

Esa evolución va acompañando con el creciente desarrollo y significación de las

tecnologías informáticas en este sector.

Por lo tanto es que este proyecto se basa en la necesidad que surge en los turistas de

obtener información correcta y detallada acerca de los principales destinos turísticos de la

región, así como también de realizar compras on-line de productos en disposición.


6/37


7/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 7 de 37

4.2. OBJETIVO ESPECIFICO

4.2.1. Demostrar que la implementación de este nuevo sistema mejorar

notablemente la afluencia de turistas nacionales y extranjeros en la región

Junín.

4.2.2. Demostrar que esta aplicación pueda gestionar la información turística de

importancia relevante en los principales destinos turísticos de Junín

4.2.3. Incrementar el uso de estas herramientas tecnológicas en los dueños delas agencias de turismo.

4.2.4. Mostrar mediante indicadores, que la información turística puede ser

fácilmente administrable.

5. ALCANCE


8/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 8 de 37

5.1. DESCRIPCION DE LOS PROCESOS DE NEGOCIO

La Agencia de Turismo Adrenalina Tours Agencia de Viajes y Turismo E.I.R.L. es una

pequeña empresa que consta de 3 áreas fundamentales que son: administración,

tesorería/contabilidad y equipos de viaje. Los principales procesos que suceden en esta

empresa son:

Planeamiento de rutas e itinerario: Consiste en la planificación de las rutas que serán

seguidas por el equipo de guías y turistas en los horarios trazados generalmente por los

equipos de viaje en conformidad con la administración.

Captación de Clientes: Consiste en la atracción de turistas eventuales a la ciudad de

Huancayo presentes en zonas comerciales como el centro de la ciudad o diferentes

parques concurridos.

Fin de Transacción: Los clientes remuneran el servicio ofrecido a los guías y estos

rendirán cuentas en tesorería.

Reunión deinteresados

Planeamiento de rutas

Captacion declientes

Aceptación deltours

Pago porservicios

Fin

Si

No

Redefinir los planes o

promociones


9/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 9 de 37

5.2. ALCANCE DEL PRODUCTO

El aplicativo se mostrar en los diferentes dispositivos móviles y ordenadores quesoporten navegación web, ya sean ordenadores, móviles, tablets, Smart tv, esto

debido a que el aplicativo será desarrollado con el uso de responsive design.

A. Consultas de agencias y paquetes

El usuario podrá realizar una consulta de todas las agencias disponibles en la

región Junín, con sus respectivos paquetes turísticos y elegir el que más le

convenga.

B. Registro de agencias

El administrador del sistema podrá registrar a las diferentes agencias de turismo

de la región que deseen formar parte de este proyecto.

C. Registro de reservas

El usuario podrá realizar una reserva de una agencia en particular, por medio de

un pago realizado por depósito bancario. A la cuenta de la agencia seleccionada.

El usuario tendrá un límite de tiempo de 2 horas luego de la reserva para realizarel pago de lo contrario se le anulara dicha reserva.

D. Registro del usuario

Para poder realizar una reserva de cualquier paquete la persona deberá primero

registrarse a la plataforma del aplicativo, ingresando toda su información general

y así poner realizar una reserva de manera segura.

5.3. ALCANCE DEL PROYECTO

El alcance del proyecto se resume en los siguientes puntos:

Desarrollo y puesta en producción de la Guía turística con gestión de reservas y pagosvía web de acuerdo a las especificaciones enviadas por el cliente

Informe semanal de avance

Comité de Analistas: 2 veces por semana.

Comité de Sistemas : semanal

Comité Gerencial: mensual

Capacitación a nivel de administrador y usuario a 15 personas en equipos de a 3personas.

Manual de Usuario y Manual de Sistemas y Administración


10/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 10 de 37

5.4. FUERA DE ALCANCE

Fuera del AlcanceObservaciones

Capacitaciones extras y/o fuera de horario a losusuarios.

Las capacitaciones serán programadas yen caso de algún futuro cambio depersonal del negocio se tendrá queaportar un monto adicional.

Sincronización de datos con Sistemas Alternos de laempresa

La información presente en otrossistemas web o de escritorio de laempresa no será tratada de algunaforma por la aplicación.

5.5. SUPUESTOS

Item Supuestos

1El cliente estará dispuesto a ofrecer la información que sea necesaria para unabuena obtención de requisitos del sistema.

2Las empresas interesadas en promocionar sus productos o servicios seráncapacitados para hacer uso de la herramienta

3El acceso que las empresas interesadas tendrán en el sistema será verificado y

controlados por el Cliente de la Aplicación.4

La empresa asumirá todos los costos de cambio que incurra el proyecto previas asu lanzamiento

5Las fechas del cronograma serán cumplidas por parte del cliente como de losdesarrolladores.

6 Los entregables y/o prototipos serán entregados en el plazo fijado.

5.6. RESTRICCIONES

Item Restricciones

1El inicio del desarrollo de software debe ser el 08 de octubre a más

tardar.

2 El presupuesto asignado para el producto no debe exceder la sumade s/. 5000.0

5.7. ESTRUCTURA DETALLADA DE TRABAJO


11/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 11 de 37

5.7.1. ENTREGABLES DE GESTION

5.7.2. ENTREGABLES DE INGENIERIA


12/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 12 de 37


13/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 13 de 37

6. REQUERIMIENTOS DEL PROYECTO

6.1. REQUERIMIENTOS DE PERSONALLos Requerimientos del Personal para el desarrollo del proyecto GUÍATURÍSTICA CON GESTIÓN DE RESERVAS Y PAGOS VÍA WEB son lossiguientes:

Nro. dePersonas

Cargo / Rol Fecha de InicioProgramada

Fecha de FinProgramada

% deAsignación

01 Gerente de Proyecto 30/09/2014 23/12/2014 100%

01 Analista de sistemas Senior 30/09/2014 23/12/2014 100%

01 Desarrollador Senior 07/10/2014 23/12/2014 100%

02 Desarrollador Junior 07/10/2014 23/12/2014 80%

02 Tester 09/12/2014 23/12/2014 100%02 Documentador 30/09/2014 23/12/2014 100%

6.1. REQUERIMIENTOS DE INFRAESTRUCTURA TECNOLÓGICA

6.1.1. REQUERIMIENTO DE SERVIDORES

6.1.1.1. REQUISITOS DE SOFTWARE

Nombre del

ServidorRequisitos de Software

Apache PHP 5

MySQL MySQL 5.1

6.1.1.2. REQUISITOS DE HARDWARE

Nombre del

ServidorRequisitos de Hardware

Hosting-Apache Capacidad: 10GB. libres

MySQL

Memoria: 2GB. Mínimo

Capacidad: 10Gb libres

Velocidad: 3GHZ mínimo

Ítem Descripción del Servidor Cantidad Fecha en que serequiere

1 Hosting - Apache 1 08/11/2014


14/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 14 de 37

6.1.2. REQUERIMENTO DE CONECTIVIDAD

6.1.2.1. REDES Y COMUNICACIONES

6.1.3. REQUERIMIENTOS DE ESTACIONES DE TRABAJO

Ítem Descripción CantidadFecha en quese requiere

1 PC’ personal 2 25/10/2014

2 Laptop 2 25/10/2014

3 Dispositivos móviles – Android 1 25/10/2014

6.1.3.1. REQUISITOS DE SOFTWARE

Ítem Descripción CantidadFecha en que se

requiere

1 Apache 1 25/10/2014

2 Navegadores web 25/10/2014

3 Sublime4 Php stud

6.1.3.2. REQUISITOS DE HARDWARE

Tipo de Estación

de TrabajoRequisitos de Hardware

PC Personal /

Laptop

Memoria: 3 GB mínimo

Disco Duro: 640 GB

Velocidad: 3GHz mínimoConexión a internet.

6.2. INFRAESTRUCTURA Y MOBILIARIO

Ítem Descripción Cantidad Fecha en que serequiere

1 Escritorios 2 04/10/2014

2 Sillas 2 04/10/20143 Pizarra 1 04/10/2014

Ítem Descripción CantidadFecha en que se

requiere

1 Conexión a internet s/n 25/09/2014


15/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 15 de 37

7. ESTRATEGIA DE EJECUCION DEL PROYECTO

7.1. ETAPAS DEL PROYECTO

7.2. FASES E ITERACIONES DEL PROYECTO

Fase

Número

de

Iteración

Fecha Inicio Fecha Fin Resumen

Incepción 1 07/10/2014 18/10/2014

Elaboración 1 18/10/2014 30/10/2014

PLAN DE CORTO PLAZO

Modulo de Registro de Empresas de turismo.

Modulo de Inclusion de paquetes turisticos.

Modulo de Admonistracion del sistema

PLAN DE CORTO PLAZO

Modulo de Registro de Turistas.

Modulo de busqueda de paquetes turisticos.

Modulo de Reserva de servicios

Modulo de pagos

ETAPAI

ETAPAII


16/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 16 de 37

2 30/10/2014 07/11/2014

Construcción

1 07/11/2014 18/11/2014

2 19/10/2014 27/11/2014

Transición 1 28/11/2014 23/12/2014

7.2.1. FASE DE INCEPCION - ITERACION 1

Términos DefiniciónTipo de Iteración Incepción

ObjetivoEn esta fase se conoce a la empresa y recopilanrequerimientos

Pre-condición 1Supuestos

1El proceso de iteración iniciaría en la fechaindicada

2La fase de iteración no tendrá retraso algunoen sus actividades

Restricciones1

Principales actividades 1 Modelamiento de la empresa2 Recopilación de requisitos

Entregables 1 Documento Visión2 Diagramas de caso de uso3 Especificación de Requisitos4 Diagrama de Requisitos

7.2.2. FASE DE ELABORACION - ITERACION 1

Términos DefiniciónTipo de Iteración Elaboración1

ObjetivoEn esta fase se diseña los requerimientos y semodela la implementación orientada a laconstrucción.

Pre-condición 1 Fase de IncepciónSupuestos

1El proceso de Elaboración iniciaría en lafecha indicada


Restricciones1

Principales actividades 1 Desarrollar la base del diseño

2 Encerrar los flujos de trabajo derequerimientos


17/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 17 de 37

Entregables 1 Vista Lógica2 Diagrama de clases3 Modelo E-R

4 Vista de Implementación5 Diagrama de Secuencia6 Diagrama de estados7 Diagrama de Colaboración8 Vista Conceptual9 Modelo de dominio

10 Vista física

11Mapa de comportamiento a nivel de

hardware12 Diseño y desarrollo de casos de uso

13Pruebas de los casos de uso

desarrollados

7.2.3. FASE DE ELABORACION - ITERACION 2

Términos DefiniciónTipo de Iteración Elaboración 2

ObjetivoEn esta fase se diseña los requerimientos y semodela la implementación orientada a laconstrucción.

Pre-condición 1 Fase de Elaboración 1Supuestos

1El proceso de Elaboración iniciaría en la

fecha indicada2

La fase de iteración no tendrá retraso algunoen sus actividades

Restricciones1

Principales actividades1

Encerrar los flujos de trabajo derequerimientos

Entregables 1 Vista Lógica2 Diagrama de clases3 Modelo E-R4 Vista de Implementación5 Diagrama de Secuencia

6 Diagrama de estados7 Diagrama de Colaboración8 Vista Conceptual9 Modelo de dominio

10 Vista física

11Mapa de comportamiento a nivel de

hardware12 Diseño y desarrollo de casos de uso

13Pruebas de los casos de uso

desarrollados

7.2.4. FASE DE CONSTRUCCION - ITERACION 1


18/37


19/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 19 de 37

Términos DefiniciónTipo de Iteración Transición 1

Objetivo En esta etapa se busca garantizar que se tiene unproducto preparado para entregar al usuario

Pre-condición 1 Construcción 2Supuestos

1El proceso de iteración iniciaría en la fechaindicada


Restricciones1

Principales actividades2

Se realiza una pequeña cascada por cadaciclo

Entregables 1 Pruebas finales de aceptación2 Puesta en producción3

Estabilización

7.3. HITOS DEL PROYECTO

N° Proceso Hito Fecha1 Gestión Recibi r Project Charter 30/09/2014

2 Gestión Envío de Plan de Dirección delProyecto

01/10/2014

3 Gestión Envío del Plan de Pruebas 01/10/2014

4 Gestión Envío del Plan de Implantación 28/10/2014

5 Gestión Envío del Plan de Capacitación 30/10/2014

6 Gestión Envío del Plan de Monitoreo 01/11/2014

7 Gestión Envío del Informe de Cierre delProyecto

20/12/2014

8 Gestión Envío de Acta de Cierre del Proyecto 23/12/2014

9 Ingeniería Inicio 07/10/2014

10 Ingeniería Documento Visión 07/10/2014

11 Ingeniería Diagramas de caso de uso 09/10/2014


20/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 20 de 37

12 Ingeniería Especificación de Requisitos 10/10/2014

13 Ingeniería Diagrama de Requisitos12/10/2014

14 Ingeniería Elaboración 07/10/2014

15 Ingeniería Vista Lógica 09/10/2014

16 Ingeniería Diagrama de clases 12/10/2014

17 Ingeniería Modelo E-R 15/10/2014

18 Ingeniería Vista de Implementación 17/10/2014

19 Ingeniería Diagrama de Secuencia 20/10/2014

20 Ingeniería Diagrama de estados 23/10/2014

21 Ingeniería Diagrama de Colaboración 27/10/2014

22 Ingeniería Vista Conceptual 30/10/2014

23 Ingeniería Modelo de dominio 02/11/2014

24 Ingeniería Vista física 05/11/2014

25 IngenieríaMapa de comportamiento a nivel de

hardware 07/11/2014

26 Ingeniería Diseño y desarrollo de casos de uso 08/11/2014

27 IngenieríaPruebas de los casos de uso

desarrollados12/11/2014

28 Ingeniería Construcción 13/11/2014

29 Ingeniería Especificación de requisitos faltantes 07/11/2014

30 Ingeniería Diseño y desarrollo de casos de uso y/oflujos de acuerdo con la planeación iterativa

07/11/2014

31 Ingeniería Pruebas de los casos de uso desarrollados,y pruebas de regresión según sea el caso 30/11/2014

32 Ingeniería Transición 01/12/2014

33 Ingeniería Pruebas finales de aceptación 05/12/2014

34 Ingeniería Puesta en producción 12/12/2014

35 Ingeniería Estabilización 23/12/2014


21/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 21 de 37

7.4. LISTA DE PROCESOS UTILIZADOS

A continuación detallamos los diferentes Procesos involucrados en el presente Plan de Dirección delProyecto:

Procesos Utilizados

Proceso Artefactos Ruta

Gestión

Proceso deGestión

7.3.2.02Proceso de

gestión paradesarrollo

$/02.Rep_Baselines_Procesos/01.Libreria_Procesos/03.Desarrollo/01.Gestion/7.3.2.02 Proceso de gestión para desarrollo

Proceso deRequerimie

ntos

7.7.5.2.01Proceso degestión derequerimientos paradesarrollo

$/02.Rep_Baselines_Procesos/01.Libreria_Procesos/03. Desarrollo/03.Requerimientos/7.7.5.2.01 Proceso de gestión de requerimientos

para desarrollo

Proceso deEstimacione

s

7.7.6.3.01Proceso deestimacione

s

$/02.Rep_Baselines_Procesos/01.Libreria_Procesos/03. Desarrollo/04.Estimaciones/7.7.6.3.01 Proceso de estimaciones

Ingeniería

Proceso deIngeniería

7.7.1.2.2.01Proceso

ingenieríade

desarrollo

$/02.Rep_Baselines_Procesos/01.Libreria_Procesos/03. Desarrollo/02.Ingenieria/7.7.1.2.2.01 Proceso ingeniería de desarrollo

8. ORGANIZACIÓN DEL PROYECTO

8.1. ORGANIGRAMA


22/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 22 de 37

Gerente del

proyecto

Analista de sistemas

Senior

Desdarrollador

SeniorTester

Desarrollador

Junior

Documentar

8.2. ROLES Y RESPONSABILIDADES DEL CLIENTE

Rol Responsabilidad Nombre

SupervisorVerificar si el aplicativo cumple con losrequisitos solicitados

Thalia Flores Camacho

Usuario Líder Revisión de la información Victor Mendoza

Usuario experto Registrar o actualizar la información Luna Samaniego

8.3. ESTANDARES DEL ENTORNO DE TRABAJO

Los estándares del entorno de trabajo son los que actualmente se tienen implementadosmedidad de seguridad para los desarrolladores y administrativos.


23/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 23 de 37

9. CRONOGRAMA DE ACTIVIDADES


24/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 24 de 37

10. ACTIVIDADES DE SOPORTE EN LA ADMINISTRACION DEL PROYECTO

10.1. GESTION DE RIESGOS

Numero Categoria Nombre del riesgo Impacto Probabilidad

r-001 ClienteCliente cambia los requerimientos.

Serio Probable

r-002 Personal

Falta de experiencia del desarrollador en

nuevas herramientas de trabajo. Moderado Muy improbable

r-003 OrganizacionalMayor cantidad de usuarios de lo esperado

Tolerable Muy improbable

r-004 OrganizacionalAsignación insuficiente de personal a cargo.

Serio

Relativamente

probable

r-005 TiempoCronograma mal definido

Serio

Relativamente

probable

r-006 OrganizacionalIncumplimiento del sponsor con los recursos.

Moderado Probable

r-007 Tecnico

Daño del servidor de desarrollo tiempo

costos Serio Muy improbable

r-008 OrganizacionalCambio de gerente del proyecto

Moderado Muy improbable

r-009 Comunicación

Omitir actividades de los procesos de

desarrollo del proyecto. Serio

Relativamente

probable

r-010 Planificacion

La fecha de entrega es modificada s in ajuste

correspondiente al alcance del producto o a

los recursos disponibles Serio Muy improbable

r-011 Control

Incumplimiento de tareas desencadenantes a

otras. Catastròfico

Relativamente

probable

r-012 Personal

Despidos eventual e inesperado de personal

reducen la capacidad del equipo. Serio Muy improbable

r-013 Organizacional

Gerencia toma decisiones que afectan la

motivación del equipo del proyecto Serio

Relativamente

probable


25/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 25 de 37

10.2. GESTION DE COMUNICACIONES

¿Qué

comunicamos?¿Por qué?

Remitente/Destin

atario

Método de

Comunicación

Responsabilidad Tiempo

Preparación Envío Retroalim

entación

Fecha Inicial Frecuencia

Lista DeRequerimientoQue Debe TenerEl Programa

Para tener una metaclara de proyecto que seva a realizar y conocertodo los elementosa utilizar para sucreación y no tenerproblemas en la entrega

LosStakeholders/Jefede proyecto, Jefede Analistas

Reunión depresentación delproyecto.Focus Grupal

(FORMAL)

Analista deSistemas

el jefe deproyecto

el jefe deproyecto

primer mesdel proyecto

solo una vez

avances delproyecto

Para monitorear eldesarrollo ycumplimiento de lasmetas.

el jefe deproyecto/losstakeholders

Informes escritosy vía correoelectronico(INFORMAL)

Jefe deanalistas.

el jefe deproyecto

el jefe deanalistas.

Desde elarranque delproyecto.

Eventualmentesegún serequiera

avances deimplementacióndel software

para conocer cómo sedebe implementar elsoftware dentro de laempresa

jefe dedesarrolladores/los stakeholders

Informes escritosy muestrapresencial.

(FORMAL/INFOR

MAL)

el jefe dedesarrolladores

el jefe deproyecto

el jefe deproyecto

a partir delinicio deimplantación

semanales

análisis delsoftware

para poder validar eltrabajo realizado yacreditar de nuestrosoftware es de calidad

Jefe de testeo / al jefe de proyecto

Reunión depresentación yescrita.(INFORMAL)

analista analista analista desde el iniciodel desarrollodel software

Eventualmente

contrato depersonal

conocer que personalserá necesario pararealizar el trabajo

analista y jefeprogramación /al jefe de proyecto

reunión depresentación

(FORMAL)

analista y jefe deprogramación

analista analista al inicio delproyecto

primerassemanas

formulación dedocumentacióndel proyecto

para mantener un buenregistro final delproyecto

el jefe deproyecto/losstakeholders

Informes escritosy vía correooficialesSemanales,Bimensuales, ySemestrales

(FORMAL)

todas lasgerencias

el jefe deproyecto

el jefe delproyecto

Desde elarranque delproyecto:

Semanales,Bimensuales, ySemestrales

impacto de la

implantación delsoftware en laempresa

A fin de identificar las

áreas que son afectadaspor el software

tester/la jefe del

proyecto ystakeholders

reunión de

presentación yescrita

(FORMAL)

tester tester tester al finalizar el

proyecto

semanal

10.2.1. IDENTIFICACIÓN DE LOS GRUPOS DE INTERÉS

Grupo deinterés

ClasificaciónRol

Nombre CorreoElectrónico

Teléfono(Anexo)

Adrenalina

Cliente Supervisor

UsuariosAnalista de Sistemas


26/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 26 de 37

10.2.2. REUNIONES DE CONTROL Y COORDINACION

A continuación, las reuniones definidas para la comunicación externa:

Reunión Propósito Asistentes Frecuencia

ComitéInterno

En este comité participan todoslos integrantes del equipo detrabajo.

Alumnos del equipo Semanal

ComitéOperativo

Se realiza el seguimiento de lasactividades del proyecto.Se Informa los riesgos y/oproblemas, y se acuerdan lasacciones a tomar.Se establecen acuerdos sobretemas relevantes a losproyectos.

Docente Cliente

Alumnos del equipoQuincenal

Actas dereunión

de trabajo

Las reuniones serán

documentadas a través deActas de Reunión, anotándosetodos los acuerdos entre elcliente y proveedor. Las actasde reunión de trabajo mostraránla siguiente información:participantes, agenda, ,resultados de la reunión,acuerdos y documentosadjuntos al acta

Cualquier rol segúnsea requerido.

Según searequerido.

10.2.3. LINEAS DE COMUNICACIÓN

Los medios formales de comunicación establecidos para el proyecto sonlos siguientes:

- Agenda de Reunión

- Actas de Comité

- Cronograma de Avance del Proyecto

- Correo Electrónico

- Actas de Reunión de Trabajo

10.2.4. MATRIZ DE COMUNICACIONES

Parte Interesada / Flujos deinformación

A c t a s d e

C o n s t i t u c i ó n d e l

P l a n d e D i r e c c i ó n

d e l p r o y e c t o

A c t a d e r e u n i ó n d e

t r a b a j o

A c t a d e c o m i t é d e

s i s t e m a s

A c t a

d e C i e r r e d e

P r o y e c t o

Docente Cliente

Alumno * * * * *


27/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 27 de 37

Las versiones preliminares de estos documentos podrán presentarse por correo

electrónico, los cuales serán impresos para ser formalizados.

Leyenda:

@ Correo Electrónico

Documento Impreso

* Quien crea el Correo / Documento.

10.3. GESTION INTEGRADA DE PROYECTOS

Las relaciones e integración del presente proyecto, con los involucrados relevantestanto a nivel de personas, áreas, proyectos y/o planes, se definen a continuación:

10.3.1. INTERDEPENDENCIAS DIRECTAS E INDIRECTAS

Dependencias con Involucrados Principales

Nº Nombre/Entidad Cargo/Rol Empresa Área/Dpto. Dependencia

1 Cardenas Salas Jorge Jefe de Tesorería Adrenalina Finanzas Usuario del Sistema

2 Cerron Huaman David Jefe de Contabilidad Adrenalina Contabilidad Usuario del sistema

3 Quinte Vergara Paty Jefe de RRHH Adrenalina RR HH Usuario del Sistema

4 Segura Mercado Cris Jefa de Planeamiento Adrenalina Gestión turisti Usuario del Sistema

5 Landeo Rupay KarenGerente de laempresa

Adrenalina Administración Usuario del Sistema


28/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 28 de 37

10.3.2. INTERDEPENDENCIAS CON OTROS PROYECTOS Y/OPLANES

El proyecto GUÍA TURÍSTICA CON GESTIÓN DE RESERVAS Y PAGOS VÍA WEB no presente interdependencia con algún proyecto y/o plan.

10.4. GESTION DE DATOS

- Se almacenará toda la documentación del proyecto en su repositorio interno de

trabajo llamado Google Drive, Los principales documentos a almacenar son :

o Plantilla de los entregables.

o Entregables generados en el Proyecto.

o Actas de Reunión de Trabajo.

o Actas de Comité.

- Estos documentos estará compartida para todos los integrantes del proyecto.

- Para el tema de código fuente, éste residirá en el SVN.

10.5. GESTION DE LA CONFIGURACION

10.5.1. NOMENCLATURA

Nomenclatura del Sistema

Nº Sigla deSistema

Descripción de Sistema Prefijo

1GTGRPW

Guía Turística Con Gestión DeReservas Y Pagos Vía Web

Proyecto

Nomenclatura de los documentos

La nomenclatura de los documentos está definida en el documento Excel

“Historial de Revisiones” que genera de forma automática, la nomenclatura

de cada documento.

Ejemplo:

Para el Acta de Constitución del Proyecto la nomenclatura definida será

ActaConstitucionProyecto_v0.2_20140911


29/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 29 de 37

Nomenclatura de las Actas de Reunión

La nomenclatura de los documentos está definida en el documento Excel

“Historial de Revisiones” que genera de forma automática, la nomenclatura

de cada documento.

Ejemplo:

Para el Acta de Reunión Interna la nomenclatura definida será

ActaReunionInterna_v0.2_20140911

10.5.2. VERSIONAMIENTO

Los documentos cuentan con una nomenclatura de versionamiento, el mismo

que se encuentra internamente en el documento, en la sección de “Historial de

Revisiones” tal como se muestra en el siguiente cuadro:

Ítem Versión Fecha Autor Descripción Estado

Responsablede Revisión

y/o Aprobación

La versión de inicio será 0.1, las modificaciones o revisiones se versionarán como

0.2, 0.3, 0.4, etc. y la versión aprobada con la cual se tiene una versión de

publicación oficial se denotará como 1.0 ó el entero siguiente que corresponda, si

luego se requieren hacer modificaciones las versiones se denotarán como 1.1,

1.2, hasta que se tenga nuevamente la versión aprobada y oficial para publicarse,

la cual se denotará como 2.0 ó el número entero que corresponda.

10.5.3. REVISIONES DE GESTIÓN DE LA CONFIGURACIÓN.

Dentro de la ejecución del proyecto se han establecido revisiones de

gestión de la configuración hechas por el docente del curso (asumirá el

rol de Gestión de la Configuración), con el objetivo de verificar si se está

cumpliendo con el procedimiento establecido. Las revisiones se

realizarán de acuerdo al cronograma definido en el ciclo.


30/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 30 de 37

10.5.4. CARPETA COMPARTIDA DEL PROYECTO.

La carpeta compartida del proyecto, donde se colocará toda la

documentación a generar, se encuentra en la siguiente ruta del Google

Drive:

https://drive.google.com/a/continental.edu.pe/?tab=mo#folders/0B4Bujz0GW3mhOUVTUmNuLVU2ODQ

La estructura de la carpeta del proyecto se encuentra dividida en sub

carpetas de Gestión e Ingeniería, cada una de las cuales con sus propias

subcarpetas como se muestra en el siguiente gráfico:

La ubicación de los documentos se encuentra definida en el documento

Excel “Historial de Revisiones” .

10.6. GESTION DE REQUERIMIENTOS

10.6.1. ORGANIZACIÓN PARA LA GESTIÓN DEREQUERIMIENTOS

Rol Nombre Cargo Contacto

Alumno GerenteATACHAGUA BRAVONIELS

Alumno NIELS @hotmail.com

Alumno Analista deSistemas

QUISPE HUAMANVICTOR ANTO

Alumno [email protected]

Profesor ClienteCarlos Arturo RaymundoIbáñez

Docente [email protected]

Profesor GerentePedro Segundo

Castañeda Vargas


Profesor ClienteJohny William SeguraIdiáquez


10.6.2. CICLOS DE APROBACIÓN DE REQUERIMIENTOS

Primer nivel: Canal autorizado para proveer requerimientos y Analista deSistemasA este nivel se aprueba la definición de los requerimientos realizado porel Analista de Requerimientos en base a lo obtenido desde los usuarios

autorizados en este plan para proveer los requerimientos. A este nivel seaprueban los requerimientos a nivel individual.

https://drive.google.com/a/continental.edu.pe/?tab=mo#folders/0B4Bujz0GW3mhOUVTUmNuLVU2ODQhttps://drive.google.com/a/continental.edu.pe/?tab=mo#folders/0B4Bujz0GW3mhOUVTUmNuLVU2ODQhttps://drive.google.com/a/continental.edu.pe/?tab=mo#folders/0B4Bujz0GW3mhOUVTUmNuLVU2ODQhttps://drive.google.com/a/continental.edu.pe/?tab=mo#folders/0B4Bujz0GW3mhOUVTUmNuLVU2ODQhttps://drive.google.com/a/continental.edu.pe/?tab=mo#folders/0B4Bujz0GW3mhOUVTUmNuLVU2ODQ


31/37


32/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 32 de 37

Granularidad Mnemónico Descripciónrequerimientos adicionales que norepresentan una funcionalidad que

deba ser construida en el productodel proyecto, pero que puedenafectar el desarrollo, ejemplo deesto son: Requerimientos deperformance, de mantenibilidad,etc.

10.6.3.3. CODIFICACIÓN DE REQUERIMIENTOS

Cada tipo de requerimiento se codificará en la Pila de Productode manera correlativa es decir:

Para los Requerimientos de Usuario:o Sintaxis: HU-AAAA-XXXX.

Donde HU significa “Historia de Usuario” Donde “AAAA” es el año actual Donde “XXXX” es un número secuencial que va

desde el “0001” hasta que se “9999”.

Para los Requerimientos de Sistema:o Sintaxis: HS-AAAA-XXXX.

Donde HS significa “Historia de Sistema”

Donde “AAAA” es el año actual Donde “XXXX” es un número secuencial que vadesde el “0001” hasta que se “9999”.

10.6.4. MANEJO DE CAMBIOS EN REQUERIMIENTOS

10.6.4.1. COMITÉ DE MANEJO DE CAMBIOS

Rol Responsabilidad Nombre CargoAprobador decambios aRequerimientos

- Autoriza lapresentación de unasolicitud de cambio.

- Autoriza la solicitudde un cambio

Carlos Arturo RaymundoIbáñez

Docente

Proveedor deCambios aRequerimientos

- Solicita cambios alos requerimientosacordados.- Solicita nuevosrequerimientos sobreaquellos que están encurso.- Resuelve consultasacerca de los cambiosen requerimientos quesolicita.

Atachagua Bravo Niels Alumno

10.6.4.2. PROCESO DE MANEJO DE CAMBIOS EN

REQUERIMIENTOS


33/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 33 de 37

Se definirá el Proceso de Manejo de Cambios enRequerimientos.

10.6.4.3. MANEJO DEL EFECTO DE LOS CAMBIOS

Los cambios en los requerimientos o la solicitud de nuevosrequerimientos se pueden realizar en cualquier fase delproyecto.

El Analista de Sistemas presenta el estudio del impacto delcambio al Aprobador de Cambios a Requerimientos, estedecidirá la incorporación de los cambios en requerimientos enel alcance del proyecto. Si los cambios son aceptados se firmaun acta genérica que refrenda la conformidad de ambas partesy se procede a incorporar los cambios solicitados.

10.6.4.4. TIPIFICACIÓN DE LOS CAMBIOS

- Cambio menorEl cambio solicitado se encuentra enmarcado en el alcancedel proyecto y en términos de costo y tiempo, el impacto nosignifica más del 10% de desviación en relación al Tiempoy/o Costo total de ejecución del proyecto establecido en elcronograma base (línea base de tiempo y costo).

- Cambio mayorEl cambio implica un aumento o reducción en el costo,pudiendo este encontrarse o no enmarcado dentro delalcance del proyecto. Si bien puede aparecer como uncambio de alcance el cambio debe estar alineado con losobjetivos establecidos para el proyecto en el Project Charter(Acta de Constitución). En términos porcentuales, el impactono debe significar más del 20% de desviación en relación altiempo y/o costo total de ejecución del proyecto establecidoen las líneas base.

- Cambio estructuralEl cambio asociado no puede ser manejado como uncambio menor o mayor o se haya excedido la barrera de20% de desviación acumulada debido a que puede generarmodificaciones contractuales en el servicio y/o cambios quesignifican más del 20% de desviación acumulada en relaciónal tiempo y/o costo total de ejecución del proyectoestablecido en las líneas base.


34/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 34 de 37

10.7. GESTION DE LA CALIDAD

10.7.1. CONTROL DE LA CALIDAD DEL PRODUCTO

Como parte del aseguramiento de la calidad en los entregables del

presente proyecto se han establecido tareas de revisiones entre los que

destacan las revisiones de pares y las revisiones del calidad.

Los documentos que serán parte de la revisión se encuentran definidos

en el documento Excel “Historial de Revisiones” .

10.7.2. ASEGURAMIENTO DE LA CALIDAD DEL PROCESO

Se ha determinado que el aseguramiento de calidad del Proceso serealizará en la última iteración de cada fase.

10.8. GESTION DEL SEGUIMIENTO DEL PROYECTO

El seguimiento y control del proyecto se realiza a lo largo del ciclo de vida del

proyecto bajo un esquema de reuniones.

Los riesgos, métricas, problemas, pendientes y en general cualquier tema que los

integrantes del equipo de proyecto definan como relevante, son revisados en las

reuniones de comités internos (del equipo del proyecto) y comité derenuniones con cliente (a nivel de proyectos).

10.9. GESTION DEL CRONOGRAMA

El cronograma se actualizará con una frecuencia semanal, de tal forma de ir

viendo el avance del proyecto.

10.10. GESTION DE LA CAPACITACION DEL PERSONAL DELPROYECTO

La capacitación está definida en las currículas de estudio de la Universidad

Continental.

10.11. ACEPTACION DE PRODUCTO

10.11.1. CRITERIOS PARA LA ACEPTACIÓN DELPRODUCTO (PLAN DE PRUEBAS)

Se dará por aceptado el Producto una vez que los usuarios hayanprobado y aceptado las Historias de Usuario. Para ello se definirá un


35/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 35 de 37

conjunto de casos de prueba (Criterios de Aceptación) por cada Historiade Usuario. El usuario entregará previamente el conjunto de datos sobreel que se definirán los casos de prueba. Un caso de uso podrá tener uno

o más casos de prueba, dependiendo de la complejidad y el número deescenarios. Esto se plasmará en el documento Historias de Usuario.

10.11.2. ESTRATEGIA DE PRUEBAS

Se realizará en cada entrega de producto.


36/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

Rev.: 1.0 Pág. 36 de 37

11. ANEXOS

11.1. ANEXO I: ARQUITECTURA Y PLATAFORMA

Servidor

HOSTING

APACHE

MYSQL

Servidor Web


37/37


1.0 R01 Versión: 1.0 Fecha: 18/09/2014

PLAN DE DIRECCION DEL PROYECTO GUÍA TURÍSTICA CON GESTIÓN DE RESERVAS Y PAGOS VÍA WEB

Documents

Transcript of PLAN DE DIRECCION DEL PROYECTO GUÍA TURÍSTICA CON GESTIÓN DE RESERVAS Y PAGOS VÍA WEB