ProyectoEstructuca Final

March 1, 2018 | Author: Carel Kaper Alarcon Anyoza | Category: Software Engineering, Software, Business, Economies, Technology
Share Embed Donate


Short Description

Download ProyectoEstructuca Final...

Description

UNIVERSIDAD ALAS PERUANAS FACULTAD DE INGENIERÍAS Y ARQUITECTURA ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS E INFORMÁTICA

TESIS SISTEMA WEB DE PRODUCTOS EXPORTABLES DE LA REGION ICA

PRESENTADO POR EL ALUMNO: PABLO FERNANDO BOHORQUEZ MURGUIA

PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE SISTEMAS E INFORMÁTICA

LIMA – PERÚ 2013

i

DEDICATORIA: El siguiente trabajo de investigación está dedicado a mi madre, abuelo y tipo puesto que me brindaron apoyo y fortaleza en el desarrollo y transcurso de este, ayudándonos a concluir satisfactoriamente nuestro proyecto. Dedico a Dios puesto que nos brinda sabiduría, amor y paciencia, nos ayuda en los elementos más difíciles brindándonos valores que nos fortalecen como persona familia y en especial a mis padres por su apoyo y por su aliento constante, el mismo que me da la confianza para seguir esforzándome y superándome día a día.

ii

AGRADECIMIENTOS Agradezco a los profesores que me brindaron su sabiduría en varios campos del conocimiento ayudándome así en varios aspectos que requerí para el desarrollo del proyecto.

iii

INTRODUCCION La Región Ica ha tenido un desarrollo notable desde comienzos de los 90, como consecuencia del aumento de la inversión privada en la producción agroindustrial y textil vinculada a la exportación. El cambio que se ha observado en la región Ica gracias a la integración al mercado mundial es significativo. Un entorno de estabilidad macroeconómica, el aprovechamiento de las preferencias arancelarias en Estados Unidos y Europa, así como una legislación favorable para la actividad agrícola y la exportación no tradicional, fueron sin duda condiciones necesarias que permitieron el surgimiento de empresas modernas capaces de insertarse competitivamente a nivel internacional. No es nuevo decir que en la sociedad actual cada vez nos son más familiares los conceptos: globalización, internacionalización, apertura de mercados y términos similares. Las Empresas de la Región de Ica han estado mucho tiempo operando en el mercado nacional, excepto en algunos casos y haciendo únicamente operaciones esporádicas con otros países o con unos pocos clientes en concreto. La problemática que enfrentan las empresas de nuestra región de Ica es que los compradores extranjeros no sepan de su existencia. Esto ocasiona que las Empresas no puedan expandirse y permanezcan estancadas en el mercado nacional. Esta herramienta nos ayudaría a facilitar el encuentro entre la demanda externa potencial y la oferta exportable local, lo cual implica favorecer el contacto entre potenciales clientes foráneos y los productores y comercializadores de bienes y servicios que la región posee. Por consiguiente, el objetivo de esta tesis es diversificar y consolidar la presencia de las empresas, productos y servicios peruanos en los mercados de destino priorizados a través de la aplicación SisExport.

iv

INDICE ii iii iv v

DEDICATORIA AGRADECIMIENTO INTRODUCCION

Contenido CAPITULO I: ANALISIS DE LA ORGANIZACION ..................................................................... 1 Fines de la Organización .................................................................................................... 2

1.1.

1.1.1.

Visión ............................................................................................................................. 2

1.1.2.

Misión ........................................................................................................................... 2

1.1.3.

Valores ......................................................................................................................... 2

1.1.4.

Objetivos Estratégicos............................................................................................. 3

1.1.5.

Unidades estratégicas de Negocio ....................................................................... 3

CAPITULO II: MARCO TEORICO DEL NEGOCIO Y DEL PROYECTO ............................... 5 2.1.

Marco Teórico del Negocio ......................................................................................... 6 Antecedentes .......................................................................................................... 6

2.1.1. 2.2.

Marco Teórico del Proyecto ....................................................................................... 8 Gestión del Proyecto ............................................................................................ 8

2.2.1. 2.2.1.1.

PROYECTO ......................................................................................................... 8

2.2.1.2.

¿Qué es la Administración de Proyectos? ...................................................... 9

2.2.2.

Ingeniería del Proyecto ...................................................................................... 13

CAPITULO III: INICIO Y PLANIFICACION DEL PROYECTO ............................................... 16 2.3.

Gestión del Proyecto .................................................................................................. 17

2.3.1. A.

Iniciación ............................................................................................................... 17 Nacimiento del Proyecto ....................................................................................... 17

Problemática ......................................................................................................................... 17 Diagrama de Ishikawa .......................................................................................................... 18 Objetivos Específicos ........................................................................................................ 19 B.

Justificación ............................................................................................................. 19

C.

Importancia ............................................................................................................... 19

v

Acta de Constitución del Proyecto ..................................................................... 20

D.

PROJECT CHARTER ........................................................................................................... 20 E.

Identificación de los interesados ............................................................................ 23

REGISTRO DE STAKEHOLDERS............................................................................... 24 ESTRATEGIA DE GESTION DE STAKEHOLDERS............................................. 25 CLASIFICACIÓN DE STAKEHOLDERS ......................................................................... 26 - MATRIZ INFLUENCIA VS PODER – ............................................................................ 26 LISTA DE STAKEHOLDERS ............................................................................................. 26 - POR ROL GENERAL EN EL PROYECTO – .................................................................. 26 2.3.2. A.

Planificación ......................................................................................................... 27 Alcance ...................................................................................................................... 27

PLAN DE GESTIÓN DE ALCANCE .................................................................................. 27 SCOPE STATEMENT ....................................................................................................... 30 DOCUMENTACIÓN DE REQUISITOS ............................................................................ 32 PLAN DE GESTIÓN DE REQUISITOS ............................................................................ 35 WBS DEL PROYECTO......................................................................................................... 36 B.

Tiempo........................................................................................................................ 37

PLAN DE GESTIÓN DE SCHEDULE ............................................................................... 37 IDENTIFICACIÓN Y SECUENCIAMIENTO DE ACTIVIDADES ................. 42 ESTIMACIÓN DE RECURSOS Y DURACIONES ................................................ 53 C.

COSTO ......................................................................................................................... 60

PLAN DE GESTIÓN DE COSTOS ............................................................................... 60 PRESUPUESTO DEL PROYECTO .............................................................................. 63 - POR FASE Y POR ENTREGABLE – ................................................................................... 63 PRESUPUESTO DEL PROYECTO .................................................................................... 64 - POR FASE Y POR TIPO DE RECURSO - ................................................................................ 64 D.

Recursos Humanos ................................................................................................ 65

DESCRIPCIÓN DE ROLES ................................................................................................. 65 DIRECTORIO DEL EQUIPO DE PROYECTO ....................................................... 69 ORGANIGRAMA DEL PROYECTO............................................................................ 66 PLAN DE RECURSOS HUMANOS ............................................................................. 66 E.

Comunicaciones .......................................................................................................... 67

PLAN DE GESTIÓN DE COMUNICACIONES....................................................... 67

vi

F.

Riesgos .......................................................................................................................... 70

IDENTIFICACIÓN Y EVALUACIÓN CUALITATIVA DE RIESGOS ........................... 70 PLAN DE GESTION DE RIESGOS .................................................................................. 73 3.2.

Ingeniería del Proyecto .............................................................................................. 75

3.2.1.

Modelamiento de requerimientos ................................................................... 75

A.

Requerimientos Funcionales ............................................................................... 75

B.

Requerimientos No Funcionales ......................................................................... 76

3.2.2. 3.3.

Diseño .................................................................................................................... 76

Soporte del proyecto .................................................................................................. 76

3.3.1.

Planificación de la calidad ................................................................................ 76

PLAN DE GESTIÓN DE LA CALIDAD .................................................................... 76 3.3.2.

Identificación de estándares y métricas ....................................................... 84

PLANTILLA DE MÉTRICA DE CALIDAD ............................................................... 84 3.3.3.

Diseño de formatos de aseguramiento de calidad ..................................... 87

MATRIZ DE ACTIVIDADES DE CALIDAD ........................................................... 87 LÍNEA BASE DE CALIDAD ............................................................................................... 90 CAPITULO IV: EJECUCION Y CONTROL DEL PROYECTO ............................................... 92 4.1. Gestión del Proyecto ......................................................................................................... 93 4.1.1. Ejecución ..................................................................................................................... 93 ACTA DE ACEPTACIÓN DE FASE ............................................................................. 93 ACTA DE REUNIÓN DE COORDINACIÓN DEL PROYECTO......................... 94 1.1

ASISTENTES ................................................................................................................ 94

CRONOGRAMA DEL PROYECTO .................................................................................... 96 B.

Estructura de descomposición del trabajo WBS .......................................... 115

DICCIONARIO WBS (simplificado) ................................................................... 115 DICCIONARIO WBS (completo) .......................................................................... 119 INFORME DE PERFORMANCE DEL PROYECTO ....................................................... 136 D.

Riesgos del Proyecto ........................................................................................... 138

INFORME DE MONITOREO DE RIESGOS .......................................................... 138 E.

Solicitud de Cambios ............................................................................................... 140

PLAN DE GESTIÓN DE CAMBIOS ................................................................................. 140 4.2.

Ingeniería del Proyecto ............................................................................................ 142

A.

Concepción ............................................................................................................. 142

vii

a.

Modelamiento del Negocio ..................................................................................... 142

Diagrama General del Negocio ...................................................................................... 143 o

Solicitar información de Productos Exportables.............................................. 143

o

Solicitar Registro de Empresa ............................................................................... 145

Diagrama Casos de Uso con el Sistema ..................................................................... 146 o

Caso de Uso Solicitar Información ....................................................................... 147

Caso de Uso Llenar de Información ............................................................................. 149 B.

Elaboración ............................................................................................................. 151

C.

Construcción .......................................................................................................... 151

D.

Transición................................................................................................................ 151

4.3.

Soporte del Proyecto ................................................................................................ 151

4.3.1.

Gestión de la Configuración........................................................................... 151

PLAN DE GESTIÓN DE LA CONFIGURACIÓN ................................................. 151 INFORME DE AUDITORÍA DE CALIDAD .................................................................... 153 4.3.3.

Medición del Valor Ganado............................................................................. 155

CHECKLIST DE PRESENTACIÓN PARA REUNIÓN DE KICK OFF ........ 155 4.3.4.

Métricas de Evaluación de desempeño ....................................................... 157

LOG DE CONTROL DE POLÉMICAS ............................................................................ 157 CAPITULO V: CIERRE DEL PROYECTO .............................................................................. 158 5.1.

Gestión de Proyecto ................................................................................................. 159

5.1.1.

Cierre .................................................................................................................... 159

5.2.

Ingeniería del Proyecto ............................................................................................ 165

5.3.

Soporte del Proyecto ................................................................................................ 165

5.3.1.

Gestión de la Configuración........................................................................... 165

PLAN DE GESTIÓN DE LA CONFIGURACIÓN ................................................. 165 5.3.2.

Aseguramiento de la Calidad ......................................................................... 167

INFORME DE AUDITORÍA DE CALIDAD .................................................................... 167 5.3.3.

Métricas y Evaluación del Desempeño........................................................ 169

CAPITULO VI: CONCLUSIONES Y RECOMENDACIONES ............................................... 171 6.1.

Conclusiones.............................................................................................................. 172

6.2.

Recomendaciones..................................................................................................... 172

GLOSARIO DE TERMINOLOGÍA DEL PROYECTO .................................................. 173 BIBLIOGRAFICA ......................................................................................................................... 175

viii

1.

ANEXOS .................................................................................................................................. 177

ix

CAPITULO I: ANALISIS DE LA ORGANIZACION

1

1.1.

Fines de la Organización

1.1.1. Visión La Dirección Regional de Comercio Exterior y Turismo tiene por Visión, promover

la

competitividad

empresarial,

desarrollando

políticas

e

instrumentos de fomento y supervisión que estimulen mejoras de productividad, el crecimiento sostenible de las exportaciones diversificadas y empleo, altos estándares de calidad, innovación tecnológica, protección ambiental, calificación continua de mano de obra, desde la micro empresa hasta las empresas grandes en los sectores de Comercio, Artesanía y Turismo. (DIRCETUR) 1.1.2. Misión La Dirección Regional de Comercio Exterior y Turismo, tiene por Misión, mantener su liderazgo a nivel nacional, con diversificación, innovación de sus productos con acceso amplio a mercados externos por la reconocida calidad de los bienes y servicios que exportamos los cuales contribuyen de manera sostenida al crecimiento y desarrollo de la Región a través del empleo e ingresos que estos generen. (DIRCETUR) 1.1.3. Valores Nuestros valores son servir a la comunidad, a la sociedad y al beneficio de todos los miembros de la empresa. 

Responsabilidad: Es la respuesta que se debe dar a la obligación contraída, actitud que se asume ante los resultados de la labor que se realiza y por lo que tiene que responder ante los demás.



Respeto: Valorar a los demás considerando su dignidad. El respeto se acoge a la verdad, no tolera bajo ninguna circunstancia la mentira y repudia la calumnia y el engaño.



Honestidad: Cumplir su deber, obrar correctamente y de acuerdo con la moral, especialmente el respeto a la propiedad ajena, la transparencia en los negocios.

2



Cooperación: Realización de una actividad con varias personas bajo un mismo fin.

1.1.4. Objetivos Estratégicos 

Direccionar los procesos de la DIRCETUR, en cumplimiento a las normas administrativas, civiles y penales.



Ejecutar las actividades técnico-administrativas en concordancia con el Plan Estratégico de Desarrollo Concertado y optimizar la Gestión y el Desarrollo Institucional, en el marco del Plan Operativo y las normas de Transparencia.



Fortalecer las Instituciones y recursos humanos vinculados a la actividad de comercio exterior.



Promover actividades de capacitación, provisión de información y transferencia tecnológica.



Promover las exportaciones regionales.



Fortalecer las Instituciones y recursos humanos vinculados a la actividad turística.



Fortalecer la conciencia turística a nivel regional, así como promover la protección del medio ambiente.

1.1.5. Unidades estratégicas de Negocio Las Unidades Estratégicas de Negocios, UEN, son un grupo de servicios o productos que comparten un conjunto común de clientes, un conjunto común de competidores, una tecnología o enfoque común, lo mismo que factores claves comunes para el éxito. Se puede entender la empresa, por tanto, como un conjunto de varias unidades estratégicas (UEN), cada una ofreciendo oportunidades de rentabilidad y crecimiento distintas, y/o requiriendo un planteamiento competitivo diferente. Las ideas básicas del concepto de UEN son: 

Múltiples actividades o negocios que llevan a una posición competitiva en cada actividad, en lugar de la posición competitiva global.



Entorno competitivo específico que requiere competencias distintas, planteando situaciones de decisión y acción diferente en cada actividad. 3



Existe la posibilidad de reagrupar actividades similares a fin de buscar las posibles sinergias, reduciendo el trabajo de los directivos.

La identificación de las UEN se puede realizar a partir de las tres siguientes dimensiones: - Grupos de clientes: Que atiende al tipo de clientela al cual va destinado el producto o servicio. - Funciones: Necesidades cubiertas por el producto o servicios. - Tecnología: Forma en la cual la empresa cubre a través del producto o servicio la necesidad de la clientela.

4

CAPITULO II: MARCO TEORICO DEL NEGOCIO Y DEL PROYECTO

2.

S

5

2.1.

Marco Teórico del Negocio

2.1.1. Antecedentes Para la actual investigación se han buscado trabajos similares, para poder tomarlos como antecedentes bibliográficos: 2.1.1.1.

DESARROLLO DE UN SOFTWARE WEB Y MOVIL PARA LA

GESTION

DE

INFORMACION

DE

CAMPO

DE

CULTIVOS AGRICOLAS (AgrocomM) Colombia como un país primordialmente agrícola, se enfrenta a los retos de la globalización, en especial al firmar acuerdos comerciales internacionales que exigen un alto nivel de competitividad externa en los sectores tradicionalmente importantes comercialmente como es el caso del sector agrícola. Por tal razón, los cultivadores y productores agrícolas colombianos han detectado la necesidad de optimizar sus procesos de pre cosecha, cosecha, recolección y distribución de productos derivados del campo. Por este motivo se plantea el desarrollo de un software que utilice los más recientes avances en tecnologías móviles y de internet, como herramienta para la gestión de información en campo de cultivos agrícolas, con la hipótesis de que se pueden optimizar el tiempo, la exactitud de la información y los costos del proceso de campo agrícola cuando apoyamos esa labor con una solución informática Web y móvil que ofrece las ventajas de la movilidad de los dispositivos de mano y la ubicuidad de las aplicaciones Web. La metodología que se empleó utilizó lo mejor de las técnicas de la metodología clásica de software, realizando una mezcla entre RUP (Rational Unified Process) y XP (ExtremeProgramming). La solución fue implantar AgroComM que es un software para la gestión de información de campo agrícola, que permite la asignación y control de actividades a través de valoraciones y registro de inconsistencias.

6

2.1.1.2.

Sistema Web de BIOCOMERCIO

El Perú ofrece un interesante potencial derivado de su inmensa diversidad biológica nativa para ingresar a nuevas líneas productivas así como para consolidar su actual oferta de bienes y servicios para los mercados

locales,

regionales,

nacionales

e

internacionales.

El sitio web Biocomercio cuenta con un Directorio tanto de las empresas productoras/exportadoras de productos priorizados de Biocomercio como de proveedores de servicios. El sitio web de Biocomercio maneja desde información estadística actualizada y ligada a la base de datos del Sistema Integrado de Información de Comercio Exterior, ésta se presenta de una manera dinámica y funcional para el usuario. Además se cuenta con reportes y guías comerciales, además de fichas técnicas de los productos priorizados de Biocomercio. (Biocomercio, 2008) 2.1.1.3.

Sistema Integrado de Información de Comercio Exterior (Siicex, 2010)

Es

un

portal

que

proporciona

a

la

comunidad

empresarial,

especialmente a los exportadores peruanos, información actualizada y clasificada para fortalecer e integrar sus negocios al mundo. Posee Directorio de Compradores Extranjeros: Más de 300 mil compradores. Sistema de Oportunidades de Negocios: Demandas internacionales. 2.1.1.4.

MAPFRE

(Mapfre, 2011) realizo un relevamiento integral de los procesos, tecnologías, conocimientos tecnológicos, fortalezas y debilidades de la compañía en lo referente al desarrollo de software. Se identificaron los puntos de mejora y se recomendaron procesos y metodologías basados en estándares de calidad ISO: 9001:2000 y prácticas de dirección de

7

proyectos basadas en PMI. Se implemento un sistema de Application LifeCyle Management que integra todos los roles y procesos basadas del ciclo de proyecto. Proyecto gestionado bajo metodologías RUP y aplicando las mejores prácticas de dirección de proyectos del PMI y conto con las siguientes características: Análisis y Diseño utilizando diagramas de casos de uso, secuencia, Storyboards, diagramas de estado, DER, diagramas de componentes, diagramas de componentes, diagramas de distribución, diagramas de clases. El proyecto consistió en el desarrollo de una serie de componentes de software que fueron la base para la construcción de las aplicaciones sobre tecnologías .NET. 2.2.

Marco Teórico del Proyecto

2.2.1. Gestión del Proyecto 2.2.1.1.

PROYECTO

Según el PMI (PMBOK, 2008) “un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único”. Según (Gido & Clements, 2003): “un proyecto es un esfuerzo por lograr un objetivo específico mediante un serie especial de actividades interrelacionadas y la utilización eficiente de los recursos”. Según el libro Preparación y Evaluación de Proyectos de los autores Nassir Sapag Chain y Reinaldo Sapag Chain; "Un proyecto es la búsqueda de una solución inteligente al planteamiento de un problema tendiente a resolver, entre tantas, una necesidad humana." De las definiciones anteriores se rescatan las siguientes características de lo que realmente define a un proyecto:

8



Los proyectos siempre tienen un cliente, quien es el que asigna o determina los recursos, además los proyectos siempre tendrán un grado de incertidumbre.



Para otros autores un Proyecto es un instrumento de decisión que se vale de un conjunto de herramientas que pretende conseguir la asignación de recursos con criterios de racionalidad, de previsión de hechos, de fijación de metas coherentes y coordinadas.



Crean un producto, un servicio o un resultado único, algo que no ha sido hecho antes, aún cuando la categoría a la que pertenezca el proyecto

sea

amplia.

Es decir,

que

cada

proyecto

posee

características y funciones específicas y en donde las circunstancias en las cuales se lleva a cabo. (Chauman, 2003) Podemos definir un proyecto a través de tres factores: 

Factores humanos: socios, trabajadores, y colaboradores, que tienen unas funciones y personalidades concretas



Factores Técnicos: maquinaria, herramientas infraestructura y, sobre todo, conocimiento.



Factores Financieros: capital, prestamos, créditos, etc

Descrito en forma general, un proyecto es la búsqueda de una solución inteligente al planteamiento de un problema tendente a resolver, entre muchas,

una

necesidad

humana.

En esta forma, puede haber diferentes ideas, inversiones de diverso monto, tecnología y metodologías con diverso enfoque, pero todas ellas destinadas a resolver las necesidades del ser humano en todas sus facetas, como pueden ser: educación, alimentación, salud, ambiente, cultura, etc. 2.2.1.2.

¿Qué es la Administración de Proyectos?

Según PMI (PMBOK, 2008) “La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas, técnicas a las actividades de un proyecto para cumplir con los requisitos del mismo”.

9

Según (Dixon, 2000): “La administración de proyectos es la disciplina de gestionar proyectos exitosamente, la cual puede y debe aplicarse durante el ciclo de vida de cualquier proyecto” Según Rodríguez (2002): “La administración de proyectos es la forma de planear, organizar, dirigir y controlar una serie de actividades realizadas por un grupo de personas que tienen un objetivo específico; el cual puede ser (crear, diseñar, elaborar, mejorar, analizar entre otros) un problema o cosa”. La administración de proyectos consiste en aplicar e integrar los grupos de procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento, control, y cierre (ciclo de vida del proyecto). El director de proyecto es el responsable de lograr los objetivos del proyecto. La administración de proyectos incluye: - Identificación de los requisitos. - Identificación de objetivos claros y posibles de alcanzar. - Lograr el equilibrio entre la calidad, el alcance, el tiempo y los costos. - Lograr la adaptación entre las especificaciones, los planes, y el enfoque de acuerdo a las inquietudes y expectativas de las diferentes clases de interesados. En una organización pueden realizarse uno o varios proyectos a la vez, en los cuales se deben cumplir una serie de requerimientos establecidos para su ejecución. Los beneficios obtenidos mediante la aplicación de la administración de proyectos son numerosos para la organización y para las personas involucradas, ya que generan una mayor confianza en el resultado a obtener, menos tensión en el equipo de trabajo, mayores tasas de productividad, menos desperdicio de recursos valiosos, llevando a un menor costo el gasto del proyecto. Es importante resaltar que los procesos incluidos en las áreas de conocimiento de la administración de proyectos son repetitivos debido a

10

la existencia o a la necesidad de elaborar gradualmente el proyecto durante el ciclo de vida del mismo. Conforme el director conoce más en profundidad el proyecto, puede dirigirlo con mayor nivel de detalle (PMBOK, 2008). 2.2.1.3.

Ciclo de Vida del Proyecto

Todos los proyectos siguen su propio ciclo. Existen muchas versiones acerca de lo que es el ciclo de un proyecto, diferenciadas esencialmente por el manejo de la terminología y la cronología de algunas actividades. Lo que debe tenerse en cuenta es que la comprensión del ciclo de un proyecto es un aspecto fundamental para poder ubicar la evaluación dentro del conjunto de actividades a realizar. Los Directores de Proyectos o la Organización pueden dividir los proyectos en fases. El conjunto de estas fases se conoce como ciclo de vida del proyecto. (Thompson, 2009)

Figura 5: Ciclo de vida de un Proyecto Estas

fases

tienen

distintas

particularidades

según

sean

las

características del proyecto que se está emprendiendo, (tipo de producto a obtener, duración, envergadura, importancia relativa para la empresa, etc.). En forma genérica, sin embargo, se puede realizar la siguiente descripción de las fases: 2.2.1.3.1. Fase Concepción Es la primera fase del sistema y consiste en adquirir los requerimientos por parte de los distintos usuarios y consolidar una visión única de los objetivos y alcances del sistema. Durante esta fase se establece el caso de negocios del sistema y se delimita el

11

alcance del proyecto. Para ello se identifican todas las entidades externas con las cuales interactúa el sistema (actores) y se define la naturaleza de esta interacción a alto nivel. Esto involucra la identificación de todos los casos de uso y la descripción de los más significativos. El caso de negocios incluye el criterio de aceptación, la evaluación de riesgos, una estimación de los recursos necesarios y un plan de fases mostrando fechas de los principales hitos del proyecto. (DeCarlo & Mancin, 2004) 2.2.1.3.2. Fase Elaboración El propósito de esta fase es analizar el ámbito del problema, establecer la base de la arquitectura, desarrollar el plan de proyecto y eliminar los elementos de mayor riesgo del proyecto. (DeCarlo & Mancin, 2004) Para lograr estos objetivos se debe tener una visión completa del sistema. Las decisiones de arquitectura deben ser tomadas con un entendimiento completo del sistema: su alcance, funcionalidades principales y requerimientos no funcionales como ser requerimientos de ejecución. Al finalizar esta fase en forma exitosa, se asegura que la arquitectura, requerimientos y planes son lo suficientemente estables y que los riesgos han sido mitigados a fin de que sea posible predecir el costo y cronograma del desarrollo completo. 2.2.1.3.3. Fase Construcción El propósito de la implementación es el desarrollo del sistema, en el cual se deben obtener finalmente las herramientas necesarias para resolver los requerimientos definidos en las etapas previas. (DeCarlo & Mancin, 2004) Durante esta fase se construyen todos los componentes y funcionalidades de la aplicación restantes y son integrados al 12

producto. Asimismo toda la funcionalidad es probada. La fase construcción es, fundamentalmente, un proceso de manufactura donde el énfasis está puesto en administrar recursos y controlar las operaciones para optimizar costos, cronogramas y calidad. 2.2.1.3.4. Fase Transferencia El propósito de esta fase es lograr la transición del producto de software a la comunidad de usuarios. Una vez que el producto ha sido entregado al usuario final, surgen temas que requieren del desarrollo de nuevas versiones, corregir algunos problemas, o finalizar las funcionalidades que fueron pospuestas. (DeCarlo & Mancin, 2004) Se ingresa a esta fase cuando el producto está lo suficientemente maduro para ser implementado en el entorno del usuario final. Típicamente requiere que un subconjunto utilizable del sistema haya sido completo a un nivel de calidad aceptable y que la documentación de usuario esté disponible a fin de que la transición al usuario final de resultados positivos.

2.2.2. Ingeniería del Proyecto Para la elaboración del proyecto se utilizara la metodología

Rational

Unified Process, o RUP, que es una plataforma flexible de procesos de desarrollo de software que ayuda brindando guías consistentes y personalizadas de procesos para todo el equipo de proyecto. Según (RUP, 2002) es la metodología estándar de la industria para la construcción completa del ciclo de ingeniería de software, tanto para sistemas tradicionales como para sistemas web, llamada así por sus siglas en inglés Rational Unified Process. Es un proceso de ingeniería de software, bien definido y estructurado; a la vez que es un producto que provee un marco de proceso adaptable a las necesidades y características de cada proyecto específico. (Martinez & R., 2012)

13

Alejandro & Raul (2008) afirman:”El RUP es una metodología completa y extensa que intenta abarcar todo el mundo del desarrollo software, tanto para pequeños proyectos, como proyectos más ambiciosos de varios años de duración”. Según lo que establece el RUP (DeCarlo & Mancin, 2004)los elementos del RUP son: 

Actividades, son los procesos que se llegan a determinar en cada iteración. En concreto es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.



Roles, definen el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueño de un conjunto de artefactos.



Artefactos, son un producto, es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final. Un artefacto puede ser cualquiera de los siguientes (RUP, 2002): un documento, un modelo, y un elemento del modelo.

Las siguientes fases se desarrollaran en el proyecto: INICIO 

Establece el ámbito del Proyecto y sus límites.



Estimar el coste en recursos y tiempo de todo el proyecto.



Una

visión

general

de

los

requerimientos

del

proyecto,

características clave y restricciones principales. ELABORACION 14



Analizar el Dominio del Problema.



Completar la Visión.



Desarrollar un plan del proyecto.



Demostrar que la arquitectura propuesta soportara la visión con un coste razonable y un tiempo razonable.



Eliminar los Elementos de mayor riesgo para el desarrollo exitoso del proyecto

CONSTRUCCION Y DESARROLLO 

Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba).



En esta fase todos los componentes se desarrollan e incorporan al producto

TRANSICION Y CIERRE 

Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios.



Conversión de las bases de datos operacionales.



Producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.



Se debe verificar el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

15

CAPITULO III: INICIO Y PLANIFICACION DEL PROYECTO

16

2.3.

Gestión del Proyecto

2.3.1. Iniciación A. Nacimiento del Proyecto Problemática La apertura comercial ha motivado que las empresas se interesen por las oportunidades que otros mercados ofrecen, con el fin de incrementar sus utilidades. La Dircetur Ica se encarga de promover actividades de capacitación, provisión de información y transferencia tecnológica, promover las exportaciones regionales. Actualmente el área de Comercio Exterior del GORE Ica cuenta con un software denominado MERI (Mapa Exportador de la Región Ica) elaborado en EXCEL, el cual está totalmente obsoleto ya que la información que contiene son datos del 2000-2007 y no ha sido actualizado hasta el presente año por falta de capacitación al personal y no tener a la mano un manual de cómo utilizar el software. La principal problemática detectada es la carencia

de

información

inversionista/comprador

necesaria

extranjero

que

este

para en

que

el

busca

de

oportunidades de negocio en el Perú establezca contacto con las empresas de nuestra Región de Ica, lo que conlleva a que las empresas de nuestra región siempre estén operando en el mercado nacional y no tengan una oportunidad para poder surgir en mercados internacionales. Otro inconveniente es que debido a la magnitud de productores ya existentes y los que recién están surgiendo en nuestra región, no se lleva el control adecuado de los mismos ni de las empresas del exterior que desean realizar negociaciones con los productores, ya que esta información debe ser modificada constantemente, no solo por los nuevos productores sino también por los productores que ya no estén laborando.

17

Falta de Capacitacion

Tecnología

Falta de Actualizacion Información

Tiempo

Ambiente

Software Mapa Exportador obsoleto

No saben utilizar El software

Falta de compromiso Por el personal de area

Falta de Motivacion

No se cuentan con Sistemas de Información

Personal

Deficiente almacenamiento De informacion

Conocimiento limitado del potencial Exportador de la Region

Demora en la búsqueda de productos que corresponden a cada empresa

Archivos desordenados

Diagrama de Ishikawa

18

Objetivo del Proyecto Diversificar y consolidar la presencia de empresas, productos y servicios de nuestra región Ica en los diferentes mercados internacionales. Objetivos Específicos 

Elaborar un sistema de información Web



Diagnosticar la situación actual de las exportaciones de los diferentes productos que se encuentran en el mercado regional.



Controlar los productores ya existentes y los que recién están surgiendo en nuestra región.



Disminuir el tiempo de búsqueda de los productos exportables.



Mejorar

las

condiciones

de

acceso

a

los

mercados

internaciones. B. Justificación La justificación de la presente investigación se basa en que al aplicarse la herramienta las empresas de nuestra región puedan tener mayor contacto con los compradores extranjeros y así expandirse a mercados internacionales, y así poder crear más puestos de trabajo y que nuestra región se desarrolle. Se justifica también porque permitirá que la DIRCETUR genere un diagnostico de la situación actual de las exportaciones y poder observar si las exportaciones aumentan o disminuyen. El mundo está avanzando a grandes pasos por lo que siempre debemos estar innovando y caminando junto a la tecnología puesto que la innovación tecnológica tiene un gran impacto y peso dentro de este Proyecto de negociación con los mercados Internacionales.

C. Importancia El comercio internacional y en especial el comercio exterior es muy importante para el crecimiento y desarrollo sostenido a largo plazo; más aún en la actualidad tiene un peso importante en la actividad

19

económica de los países, el mismo que es demostrado por las evidencias de los países desarrollados y las experiencias de los "países exitosos" que han logrado su crecimiento y desarrollo económico gracias al crecimiento de las exportaciones. En tal sentido, el MERI es, en última instancia, una herramienta para facilitar el encuentro entre la demanda externa potencial y la oferta exportable local, lo cual implica favorecer el contacto entre potenciales clientes foráneos y los productores y comercializadores de

bienes

y

servicios

que

la

región

posee.

D. Acta de Constitución del Proyecto PROJECT CHARTER NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO SWPE

Sistema Web de Productos Exportables

DESCRIPCIÓN DEL PROYECTO: ¿QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE? El proyecto “Desarrollo Sistema Web de Productos Exportables de la Región Ica”, consiste en elaborar un sistema web que nos permita brindar información sobre los productos exportables de la Región Ica hacia los inversionistas extranjeros. El desarrollo del proyecto estará a cargo de: 

Program Manager : Bohórquez Murguía Pablo Fernando



Sponsor

: Murguía Morón Carlos Jesús

El desarrollo cuenta con las siguientes fases: 

Iniciación



Planificación



Ejecución



Control



Cierre

El proyecto será realizado durante los meses de Marzo a Diciembre del 2013. La Gestión el Proyecto se realizara en el Gobierno Regional – Área de Comercio Exterior y Turismo

DEFINICIÓN DEL PRODUCTO DEL PROYECTO:

DESCRIPCIÓN DEL PRODUCTO, SERVICIO O CAPACIDAD A

GENERAR.

20

El “Sistema Web de Productos Exportables de la región Ica” permitirá brindar la Seguridad de ofrecer al inversionista extranjero información precisa en un tiempo oportuno y con información verdadera, además de facilitar el encuentro entre la demanda externa potencial y la oferta exportable local, lo cual implica favorecer el contacto entre potenciales clientes foráneos y los productores y comercializadores de bienes y servicios que la región posee. El diseño de la web se basa en 3 premisas: 

Claridad: La web debe ser de fácil utilización. La información debe estar presentada de manera

integrada,

es

decir,

mediante

una

interface

que

permita

al

inversionista/comprador extranjero acceder a la información relevante de manera sencilla e intuitiva y en la menor cantidad de pasos posible, por lo tanto esta información debe ser consistente y uniforme para no crear confusiones innecesarias. 

Contexto: La información ofrecida al inversionista/comprador extranjero debe incluir gráficos y tablas de fácil comprensión, que resuman tendencias y dinámicas del mercado de cada producto no solo en la región Ica, sino en el país en general.



Contacto: El objetivo final es ayudar a contactar la oferta regional con la demanda externa. Para ello, debe asociarse cada producto a aquellas empresas que lo producen o que están en capacidad de hacerlo. Asi, el inversionista/comprador extranjero puede establecer contactos directos con las empresas iqueñas relevantes.

DEFINICIÓN DE REQUISITOS DEL PROYECTO: DESCRIPCIÓN DE REQUERIMIENTOS FUNCIONALES, NO FUNCIONALES, DE CALIDAD, ETC., DEL PROYECTO/PRODUCTO.

StakeHolder

Necesidades, deseos o expectativas

Sponsor: Dir. de

El proyecto no exceda el Supervisar que el proyecto sea exitoso presupuesto estimado.

Comercio Exterior

Program Manager;

Desarrollar un sistema que cumpla las Bohórquez Murguía expectativas de Pablo los interesados

OBJETIVOS DEL PROYECTO:

Requerimientos del Proyecto

Cumplir con los acuerdos presentados en la propuesta y respetar los requerimientos del usuario

METAS HACIA LAS CUALES SE DEBE DIRIGIR EL TRABAJO DEL PROYECTO EN TÉRMINOS

DE LA TRIPLE RESTRICCIÓN.

CONCEPTO

OBJETIVOS

CRITERIO DE

ÉXITO

21

1. ALCANCE

Cumplir con la elaboración de los Aprobación de todos los siguientes entregables: entregables. Acta de constitución, perfil del producto, especificaciones técnicas, Muestras piloto, prototipo, puesta en marcha.

2. TIEMPO

El

3. COSTO

Cumplir con el Estimado.

tiempo estimado para el Cumplir con el tiempo desarrollo del sistema es de establecido. 10 meses calendario.

FINALIDAD DEL PROYECTO: EJECUTA EL PROYECTO.

Presupuesto No

exceder presupuesto proyecto.

el del

FIN ÚLTIMO, PROPÓSITO GENERAL, U OBJETIVO DE NIVEL SUPERIOR POR EL CUAL SE

ENLACE CON PROGRAMAS, PORTAFOLIOS, O ESTRATEGIAS DE LA ORGANIZACIÓN.

Diversificar y consolidar la presencia de las empresas, productos y servicios peruanos en los mercados de destino priorizados. JUSTIFICACIÓN DEL PROYECTO:

MOTIVOS, RAZONES, O ARGUMENTOS QUE JUSTIFICAN LA EJECUCIÓN DEL

PROYECTO.

JUSTIFICACIÓN CUALITATIVA

JUSTIFICACIÓN CUANTITATIVA

Generar Ingresos a la Región Ica

Flujo de Ingresos

Mejora en la satisfacción de los Inversionistas Extranjeros

Flujo de Egresos

Ganar Experiencia en la gestión de proyectos

DESIGNACIÓN DEL PROJECT MANAGER DEL PROYECTO. NOMBRE

Bohórquez Murguía, Pablo

NIVELES DE AUTORIDAD

Peña Casas Erwin REPORTA A

Quispe Salamanca, Modesto.

SUPERVISA A

Bohorquez Muguia, Pablo

Exigir Cumplimiento de las Etapas del Proyecto

CRONOGRAMA DE HITOS DEL PROYECTO. HITO O EVENTO SIGNIFICATIVO

FECHA PROGRAMADA

Inicio de proyecto

04 de Marzo de 2013

Planificación

01 de Abril de 2013

Desarrollo

06 de Mayo de 2013

Análisis y Diseño

04 de junio de 2013

22

Construcción

02 de Septiembre de 2013

Implementación y aceptación

01 de Octubre de 2013

Mantenimiento y control

15 de diciembre de 2013

ORGANIZACIONES O GRUPOS ORGANIZACIONALES QUE INTERVIENEN EN EL PROYECTO. ORGANIZACIÓN O GRUPO ORGANIZACIONAL

ROL QUE DESEMPEÑA

SUNAT

Estadísticas de Comercio Exterior

SENASA

Registro de Exportaciones

MINCETUR

( PENX, PERX y documentos afines)

Organización de la Region Ica

Gestionar

información

que

proveen

de

las

organizaciones

PRINCIPALES AMENAZAS DEL PROYECTO (RIESGOS NEGATIVOS).  Desinterés por parte de los trabajadores de la organización.  Falta de compromiso con el cambio.  No tener los entregables de producto en las fechas programadas.  Falta de Apoyo de los Directivos. Principales Oportunidades del Proyecto (Riesgos Positivos). 

Oportunidades de Negocio para las Empresas de nuestra región.

Presupuesto Preliminar del Proyecto. CONCEPTO

MONTO

Inicio

$230.00

Planificación

$610.00

Ejecución

$2500.00

Control y Seguimiento

$650.00

Cierre

$900.00

Total Linea Base

$4890.00

SPONSOR QUE AUTORIZA EL NOMBRE Carlos Murguia Moron

PROYECTO.

EMPRESA Gobierno Regional

E. Identificación

CARGO

FECHA

Director de Comercio Exterior

de

los

interesados

23

REGISTRO DE STAKEHOLDERS STAKEHOLDER (PERSONAS O GRUPOS)

Directora Regional:

EVALUACION DEL IMPACTO

INTERES EN EL PROYECTO

ESTRATEGIA POTENCIAL PARA GANAR SOPORTE O REDUCIR OBSTÁCULOS

Satisfacer al inversionista extranjero y empresas de la región.

Muy alto

Diversificar y consolidar las empresas y productos regionales hacia los distintos mercados internacionales.

Que el proyecto finalice exitosamente en el plazo y presupuesto ofertado.

Muy alto

Informar continuamente sobre el desempeño del proyecto, los problemas encontrados y solicitar soporte de ser necesario.

Muy alto

Pablo Fernando Bohórquez Murguía

Que el proyecto finalice exitosamente, cumpliendo con los objetivos para los cuales se implemento el proyecto

Informar continuamente sobre el estado del proyecto, los problemas observados, las solicitudes de cambio emitidas y los entregables completados

Empresas Agroindustriales De la Región Ica

Proveer información de forma continua

Alto

Información anual, por campañas para que los inversionistas puedan visualizar y tener un mayor conocimiento de los productos que se exporta.

Martha Moran Galindo

Sponsor: Carlos Jesús Murguía Morón

Líder del Proyecto:

OBSERVACIONES Y COMENTARIOS

24

ESTRATEGIA DE GESTION DE STAKEHOLDERS STAKEHOLDER

ESTRATEGIA POTENCIAL PARA GANAR SOPORTE O REDUCIR OBSTÁCULOS

INTERES EN EL PROYECTO

EVALUACION DEL IMPACTO

Satisfacer al inversionista extranjero y empresas de la región.

Muy alto

Diversificar y consolidar las empresas y productos regionales hacia los distintos mercados internacionales.

Que el proyecto finalice exitosamente en el plazo y presupuesto ofertado.

Muy alto

Informar continuamente sobre el desempeño del proyecto, los problemas encontrados y solicitar soporte de ser necesario.

Muy alto

Pablo Fernando Bohórquez Murguía

Que el proyecto finalice exitosamente, cumpliendo con los objetivos para los cuales se implemento el proyecto

Informar continuamente sobre el estado del proyecto, los problemas observados, las solicitudes de cambio emitidas y los entregables completados

Empresas Agroindustriales De la Región Ica

Proveer información de forma continua

Alto

Información anual, por campañas para que los inversionistas puedan visualizar y tener un mayor conocimiento de los productos que se exporta.

(personas o grupos) Directora Regional: Martha Moran Galindo

Sponsor: Carlos Jesús Murguía Morón

Líder del Proyecto:

OBSERVACIONES Y COMENTARIOS

25

CLASIFICACIÓN DE STAKEHOLDERS - MATRIZ INFLUENCIA VS PODER – PODER SOBRE EL PROYECTO BAJO

ALTO

Director de Comercio Exterior :

Pablo Fernando Bohórquez Murguía

Carlos Jesús Murguía Morón

ALTA

PROJECT MANAGER:

Área de Informática BAJA

INFLUENCIA SOBRE EL PROYECTO

SPONSOR:

PODER

Ar

Oficina Administrativa

Área de Comercio Exterior

: Nivel de Autoridad

INFLUENCIA : Involucramiento Activo

LISTA DE STAKEHOLDERS - POR ROL GENERAL EN EL PROYECTO – ROL GENERAL SPONSOR EQUIPO DE PROYECTO

STAKEHOLDERS Director de Comercio Exterior: CARLOS JESUS MURGUIA MORON PABLO FERNANDO BOHORQUEZ MURGUIA

PORTFOLIO MANAGER PROGRAM MANAGER PERSONAL DE LA OFICINA DE PROYECTOS

GERENTES DE OPERACIONES

GERENTES FUNCIONALES

Directora de Turismo:

Betty de la Cruz Palomino PABLO FERNANDO BOHORQUEZ MURGUIA

26

USUARIOS / CLIENTES

Área de Comercio Exterior

PROVEEDORES / SOCIOS DE NEGOCIOS Área de Informática

OTROS STAKEHOLDERS

Oficina Administrativa

2.3.2. Planificación A. Alcance

PLAN DE GESTIÓN DE ALCANCE

NOMBRE DEL PROYECTO Sistema web de productos exportables

SIGLAS DEL PROYECTO SWPE

PROCESO DE DEFINICIÓN DE ALCANCE:

27

El proyecto deberá contemplar los siguientes puntos: -

Claridad: Debe ser de fácil utilización. La información debe presentarse de forma integrada, es decir, mediante un interface que permita al inversionista/comprador extranjero acceder a la información relevante de manera sencilla e intuitiva y en la menor cantidad de pasos posibles. Por lo mismo, la información contenida en el sistema debe ser consistente y uniforme para no crear confusiones innecesarias.

-

Contexto: La información ofrecida al inversionista/comprador extranjero debe incluir gráficos y tablas de fácil comprensión, que resuman tendencias y dinámicas de mercado de cada producto no solo en la región, sino en el país en general. De esa manera se contextualizan los datos específicos del sistema.

-

Contacto: El objetivo final es ayudar a contactar la oferta regional con la demanda externa. Para ello, debe asociarse cada producto a aquellas empresas que lo producen o que están en capacidad de hacerlo. Así, el inversionista/comprador extranjero puede establecer contactos directos con las empresas iqueñas relevantes.

El proyecto no contemplara: -

Información de otras regiones del Perú.

PROCESO PARA ELABORACIÓN DE WBS:

El EDT será elaborado por el jefe del proyecto. El EDT será revisado y aprobado por el Director de Comercio Exterior. Los pasos que se realizaron para la elaboración del EDT son los siguientes: El EDT del proyecto será estructurado de acuerdo a la herramienta de descomposición, WBS Chart Pro, identificándose primeramente los principales entregables, que en el proyecto actúan como fases. En el proyecto se identifico 5 fases: Inicio, planificación, Ejecución, Seguimiento y control, Cierre. Luego los entregables se descomponen en paquetes de trabajo, los cuales nos permiten conocer al mínimo detalle los diversos componentes del proyecto. La herramienta a utilizar es WBS Chart Pro 4.8a , pues permite fácil diagramación y manejo de los entregables del proyecto

PROCESO PARA ELABORACIÓN DEL DICCIONARIO WBS: PROCESO PARA CREAR, APROBAR, Y MANTENER EL

DESCRIPCIÓN DETALLADA DEL

DICCIONARIO WBS. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO,

DÓNDE, Y CON QUÉ.

28

Previo a este proceso, el WBS del proyecto debe haber sido elaborado, revisado y aprobado. Es en base a la información del WBS que se elaborará el Diccionario WBS, para lo cual se realizarán los siguientes pasos: 

La elaboración del Diccionario WBS se hace mediante una plantilla diseñada por Dharma.



Se identifica las siguientes características de cada paquete de trabajo del WBS.



Se detalla el objetivo del paquete de trabajo.



Se hace una descripción breve del paquete de trabajo.



Se describe el trabajo a realizar para la elaboración del entregable, como son la lógica o enfoque de elaboración y las actividades para elaborar cada entregable.



Se establece la asignación de responsabilidad, donde por cada paquete de trabajo se detalla



quién hace qué: responsable, participa, apoya, revisa, aprueba y da información del paquete de trabajo.

PROCESO PARA VERIFICACIÓN DE ALCANCE:

DESCRIPCIÓN DETALLADA DEL PROCESO PARA LA

VERIFICACIÓN FORMAL DE LOS ENTREGABLES Y SU ACEPTACIÓN POR PARTE DEL CLIENTE

(INTERNO O EXTERNO).

DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, Y CON QUÉ.

Al término de elaboración de cada entregable, éste debe ser presentado al Sponsor del Proyecto.

PROCESO PARA CONTROL DE ALCANCE:

DESCRIPCIÓN DETALLADA DEL PROCESO PARA

IDENTIFICAR, REGISTRAR, Y PROCESAR CAMBIOS DE ALCANCE, ASÍ COMO SU ENLACE CON EL

CONTROL INTEGRADO DE

CAMBIOS. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE Y CON QUÉ.

El Project Manager se encarga de verificar que el entregable cumpla con lo acordado en la Línea Base del Alcance.

29

SCOPE STATEMENT DESCRIPCIÓN DEL ALCANCE DEL PRODUCTO REQUISITOS:

1.

El

CARACTERÍSTICAS:

sistema

soporte

comportamientos peruano

y

en

que

nuevos 1. mercado

podrían

Es flexible se adapta a los diferentes cambios del mercado.

ser

implementados en otros países. 2. El sistema permita administrar las Las consultas podrán ser visualizadas e nuevas adquisiciones del mercado.

2. impresas desde el navegador y exportadas a Excel y PDF.

3. El

sistema

permita

manejar 3. Para el uso de la aplicación basara tener

información de forma dinámica.

un explorador Web.

4. Que los usuarios del cliente cuenten con una herramienta informática que les permita ingresar, actualizar, eliminar, consultar productos y empresas de la Región Ica 5.

Se debe poder exportar e imprimir las consultas.

6. Debe ser una aplicación Web 7. Debe contemplar un Manual de usuario con las instrucciones del uso de la aplicación. 8. El usuario podrá utilizar cualquier navegador disponible en el mercado para utilizar la aplicación. CRITERIOS DE ACEPTACIÓN DEL PRODUCTO:. CONCEPTOS

CRITERIOS DE ACEPTACIÓN

1. TÉCNICOS

El proyecto debe cumplir con los estándares del pmbok.

2. DE CALIDAD

Se debe lograr un 75% de nivel de satisfacción del cliente.

30

3. ADMINISTRATIVOS

Todos los entregables debe ser aprobados Dircetur.

por la

4. COMERCIALES 5. SOCIALES

ENTREGABLES DEL PROYECTO: FASE DEL PROYECTO

PRODUCTOS ENTREGABLES

1.0 Inicio

Proyecto Iniciado.

2.0 Planificación

Entrega de Planes

3.0 Ejecución

Entrega de Modelos de datos

4.0

Mantenimiento Control

y Entrega de prototipo

5.0 Cierre

Entrega de informes de Capacitación

EXCLUSIONES DEL PROYECTO: 1. Módulos que no sean partes del alcance inicial. 2. Solución de problemas no originados por las tareas del proyecto. 3. Elaborar documentación técnica adicional a la mencionada como parte del alcance del proyecto. Restricciones del Proyecto: INTERNOS A LA ORGANIZACIÓN El proyecto debe terminarse dentro del presupuesto estimado y acordado con el

AMBIENTALES O EXTERNOS A LA ORGANIZACIÓN Toda la información que se maneja en el proyecto es de carácter confidencial.

cliente Deberá contarse con toda la infraestructura

Diez días útiles de plazo para dar respuesta a

y el ambiente de desarrollo apropiado para

las observaciones.

la realización de la construcción y pruebas del software

SUPUESTOS DEL PROYECTO: INTERNOS A LA ORGANIZACIÓN

AMBIENTALES O EXTERNOS A LA ORGANIZACIÓN

Siempre existirá disponibilidad de un área de El cliente se encargará de seleccionar al personal trabajo exclusiva para el equipo de trabajo, que participará en el programa de capacitación. donde existan suficientes nodos de acceso a internet. El cliente respetará el cronograma de capacitación presentado en la propuesta. El cliente se encarga del hosting.

31

DOCUMENTACIÓN DE REQUISITOS NECESIDAD DEL NEGOCIO U OPORTUNIDAD A APROVECHAR: DESCRIBIR

LAS LIMITACIONES DE LA

SITUACIÓN ACTUAL Y LAS RAZONES POR LAS CUÁLES SE EMPRENDE EL PROYECTO.

-

Ofrecer un buen servicio al inversionista.

-

Escasa cultura del uso de información en la toma de decisiones.

-

Obtener nuevos contactos, para los productores que la región posee.

-

Ampliación de portafolio de empresas exportadoras.

OBJETIVOS DEL NEGOCIO Y DEL PROYECTO: DEFINIR

CON CLARIDAD LOS OBJETIVOS DEL NEGOCIO Y

DEL PROYECTO PARA PERMITIR LAS TRAZABILIDAD DE ÉSTOS.

-

Promover actividades de capacitación, provisión de información y transferencia tecnológica

-

Promover las exportaciones regionales.

-

Diversificar y consolidar la presencia de las empresas, productos y servicios peruanos en los mercados de destino priorizados.

REQUISITOS FUNCIONALES: DESCRIBIR PROCESOS DEL NEGOCIO, INFORMACIÓN, INTERACCIÓN CON EL PRODUCTO, ETC

STAKEHOLDER

PRIORIDAD OTORGADA POR EL STAKEHOLDER

CÓDIGO

REQUISITOS DESCRIPCIÓN

Muy Alta

RE01

Permitir registrar productos exportables.

Alta

RE02

Permitir modificar datos existentes de empresas registradas

Muy Alta

RE03

Permitir eliminar productos que ya no están siendo exportados.

DIRECCION DE COMERCIO EXTERIOR

Muy alta

RE04

Muy Alta

RE05

Permitir eliminar empresas exportadoras

Permitir el registro de empresas de la Región Vía Web

Alta

RE06

Permitir modificar y eliminar los productos exportables

Alta

RE07

Permitir al administrador subir archivos sobre

actividades

de

capacitación,

provisión de información vía Web. Alta

RE08

Permitir

consultar

de

qué

países

provienen las personas que visiten el sistema web, para poder saber hacia qué mercado está llegando esta información. Alta

RE09

Permitir

Generar

Reporte

de

las

principales empresas exportadoras de la región.

32

Alta

RE10

Permitir

Generar

principales

Alta

RE11

Reporte

mercados

de

los

Internacionales

hacia donde se está exportando. Permitir Generar Reporte de principales

productos

que

se

los estén

exportando. REQUISITOS NO FUNCIONALES: DESCRIBIR REQUISITOS TALES CÓMO NIVEL DE SERVICIO, PERFOMANCE,SEGURIDAD, ADECUACIÓN, ETC. PRIORIDAD REQUISITOS STAKEHOLDER OTORGADA POR CÓDIGO DESCRIPCIÓN EL STAKEHOLDER El proyecto debe ser rentable y ejecutarse SPONSOR ALTO RE12 en el tiempo previsto. El diseño debe contemplar el uso óptimo de recursos tales como conexiones a la MUY ALTA

RE13

base de datos con un tiempo de respuesta de 10 segundos en promedio. Debe

contemplar

confiabilidad ALTA

RE014

DIRECCION DE

y

componentes

requerimientos

consistencia de

de

negocio

de los ante

recuperaciones, en caso de fallas de

COMERCIO

algún componente, no debe haber pérdida

EXTERIOR

de información. ALTA

RE015

Tolerancia a fallos. El sistema debe poder recuperarse ante fallos. El sistema debe ser de fácil utilización, la información

MUY ALTA

RE016

debe

ser

presentada

de

manera integrada, es decir, mediante una interface

que

permita

inversionista/comprador

al

extranjero

acceder a la información relevante de manera sencilla e intuitiva, para que no se pueda crear confusiones. ALTA

RE017

La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 días X 24 horas.

ALTA

RE018

El sistema de información que se desea implementar debe ser lo suficientemente adaptable a cualquier navegador Web sobre el que se corra la aplicación.

33

ALTA

RE19

Permitir exportar datos a herramientas suite de oficina (PDF) archivos planos, txt, bajo las especificaciones técnicas que los reportes

y

indicadas

las en

salidas los

en

archivo,

requerimientos

funcionales

REQUISITOS DE CALIDAD: STAKEHOLDER

PRIORIDAD OTORGADA POR EL STAKEHOLDER

CÓDIGO

REQUISITOS DESCRIPCIÓN Cumplir con el cronograma y presupuesto

R20

planificado.

SPONSOR: DIRECTOR DE

MUY ALTA

COMERCIO EXTERIOR CRITERIOS DE ACEPTACIÓN:

CONCEPTOS

1. TECNICOS

La

construcción

del

CRITERIOS DE ACEPTACIÓN sistema debe cumplir con todos

los

requerimientos.

2. DE CALIDAD

Se debe lograr el mayor nivel de satisfacción del inversionista extranjero y empresas de la región.

3. ADMINISTRATIVOS

Todos los entregables deben ser aprobados por el Sponsor.

4. COMERCIALES

Se debe cumplir con lo acordado en el Project Charter.

5. SOCIALES 6. OTROS REGLAS DEL NEGOCIO: REGLAS PRINCIPALES QUE FIJAN LOS PRINCIPIOS GUÍAS DE LA ORGANIZACIÓN. -

Comunicación constante entre el equipo de proyecto respecto a la ejecución del proyecto.

-

Emitir informes periódicos del rendimiento del proyecto y tomar acciones correctivas, sí se diera el caso.

-

La gestión del Proyecto se realiza de acuerdo a la Guia del PMBOK.

IMPACTOS EN OTRAS ÁREAS ORGANIZACIONALES -

Dirección de Turismo

IMPACTOS EN OTRAS ENTIDADES: DENTRO O FUERA DE LA ORGANIZACIÓN EJECUTANTE. -

Se espera que como resultado del proyecto, otras regiones consoliden sus productos y servicios, usando las diferentes Tecnologías de Información que existe en el mundo.

SUPUESTOS RELATIVOS A REQUISITOS -

El equipo del proyecto no cambiara las fechas programadas de los entregables, respetando el cronograma.

-

Se cuenta con el personal responsable asignado a cada etapa de las actividades.

-

Disponibilidad de los recursos tanto humanos como de maquinaria para realizar el desarrollo.

RESTRICCIONES RELATIVAS A REQUISITOS - Elaborar los 4 Informes Técnicos, producto del desarrollo de las fases, requeridos como parte del proyecto.

34

PLAN DE GESTIÓN DE REQUISITOS ACTIVIDADES DE REQUISITOS: -

Los requisitos son sugeridos por los principales stakeholders del proyecto, durante el proceso de iniciación y planificación del proyecto.

-

Los requisitos serán descritos en la Matriz de Trazabilidad de Requisitos.

ACTIVIDADES DE GESTIÓN DE CONFIGURACIÓN Para las actividades de cambio al producto, servicio o requisito se realizará lo siguiente: -

Cualquier Stakeholder puede presentar la Solicitud de cambio, donde se detalla el porqué del cambio solicitado.

-

El comité de control de cambios evaluará el impacto en el proyecto (a nivel de costos, tiempos y alcance) de las solicitudes de cambios presentadas, y reportará si estas son aprobadas o no al equipo de gestión del proyecto.

-

Si el cambio ha sido aprobado, se implementará el cambio.

-

Se hará un seguimiento del cambio, para ver los efectos positivos o negativos que tenga en el proyecto. DE

PROCESO DE PRIORIZACIÓN DE REQUISITOS: La priorización de los requisitos se realizará en base a la Matriz de Trazabilidad de Requisitos, de acuerdo al nivel de estabilidad y el grado de complejidad de cada requisito documentado. Este proceso será realizado por el equipo de gestión del proyecto durante la planificación del proyecto, y será aprobado por el Sponsor.

MÉTRICAS DEL PRODUCTO: El grado de satisfacción de los inversionistas/compradores extranjeros respecto a la información mostrada en el sistema web debe ser como mínimo de 4.0 sobre 5.0, caso contrario se realizará un seguimiento de las actividades y se tomarán las acciones correctivas necesarias.

ESTRUCTURA DE TRAZABILIDAD: En la Matriz de Trazabilidad se documentará la siguiente información:

-

Atributos de Requisitos, que incluye: código, descripción, sustento de inclusión, propietario, fuente, prioridad, versión, estado actual, fecha de cumplimiento, nivel de estabilidad, grado de complejidad y criterio de aceptación.

-

Trazabilidad hacia: 

Necesidades, oportunidades, metas y objetivos del negocio.



Objetivos del proyecto.



Alcance del proyecto, entregables del WBS.



Diseño del producto.



Desarrollo del producto.



Estrategia de prueba.



Escenario de prueba.

35

WBS DEL PROYECTO

36

B. Tiempo

PLAN DE GESTIÓN DE SCHEDULE PROCESO DE DEFINICIÓN DE ACTIVIDADES: A partir de la aprobación del Scope Statement, el WBS y el Diccionario WBS se procede ha realizar lo siguiente: Identificación y Secuenciamiento de Actividades 

Por cada entregable definido en el WBS del proyecto se identifica cuales son las actividades que permitirán el término del entregable. Para tal caso se da un código, nombre y alcance de trabajo, zona geográfica, responsable y tipo de actividad, para cada actividad del entregable.



Inicialmente definimos el secuenciamiento de las actividades por cada entregable.



Para este proceso utilizamos el formato de Estimación y Secuenciamiento de Actividades.

PROCESO DE SECUENCIAMIENTO DE ACTIVIDADES: Red del Proyecto 

Definimos la Red del Proyecto en base a los entregables del proyecto.



Luego por separado graficamos la red del proyecto de las actividades de cada fase del proyecto.



Para este proceso utilizamos el formato de Red del Proyecto.

PROCESO DE ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES: Estimación de Recursos y Duraciones 

En base a los entregables y actividades que se han identificado para el proyecto se procede a realizar las estimaciones de la duración y el tipo de recursos



Para este proceso utilizamos el formato de Estimación de Recursos y Duraciones.

PROCESO DE ESTIMACIÓN DE DURACIÓN DE LAS ACTIVIDADES: El proceso de estimación de la duración de las actividades se define de acuerdo al tipo de recurso asignado a la actividad: 

Si el recurso es tipo personal, estimamos la duración y calculamos el trabajo que tomará realizar la actividad.



En cambio si el tipo de recurso es material o maquinas, se define la cantidad que se utilizará para realizar la actividad.

37

PROCESO DE DESARROLLO DE SCHEDULE: DESCRIPCIÓN DETALLADA DEL PROCESO PARA DESARROLLAR EL SCHEDULE. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE Y CON QUÉ.

En base a los siguientes documentos: 

Identificación y Secuenciamiento de Actividades.



Red del Proyecto.



Estimación de Recursos y Duraciones.

Se obtiene toda la información necesaria para elaborar el Schedule del proyecto, mediante la herramienta de MS Project 2007, realizando los siguientes pasos: 

Primeramente exportamos los entregables del proyecto.



Ingresamos las actividades de los entregables del proyecto.



Ingresamos las actividades repetitivas del proyecto, y los hitos.



Definimos el calendario del proyecto.



Damos propiedades a las actividades.



Asignamos los recursos de las actividades del proyecto.



Secuenciamos las actividades y los entregables del proyecto.

El Schedule es enviado al Sponsor, el cual debe aprobar el documento para seguir con el proyecto.

PROCESO DE CONTROL DE SCHEDULE: Dentro de la Gestión del Proyecto, se han identificado el entregable Informes del proyecto, así como las Reuniones de Coordinación. Es mediante estos informes y reuniones que podemos controlar el schedule del proyecto.

MATRIZ DE ASIGNACIÓN DE RESPONSABILIDADES (RAM) ROLES / PERSONAS

ENTREGABLES

PROJECT MA SPONSOR

NA

ANALISTA

PROGRAMADOR

DIRCETUR

GE R

1.1.1 Análisis 1.1.2

A

R

V

Project A

R

V

R

V

Charter 1.1.3 Identificar A los interesado s

38

1.1.4 Reuniones

R

2.1.1

R

Plan

del A

P

P

A

Alcance 2.1.2 Desarrollo A

R

de Planes 2.1.2

Plan

de

Gestión Schudle

2.2.1

A Presupues to

2.2.2 Costeo del A

R

A

de

R

A

de

R

A

Formular

R

A

Proyecto 2.2.3

Plan Riesgo

2.2.4

Plan Calidad

3.1.1

Ambito del Proyecto 3.1.2

R Requerimi entos

de

los usuarios 3.1.3

P

R

Requerimi entos funcional del

39

sistema 3.1.4

P

R

P

R

P

R

P

R

P

R

P

R

P

R

P

R

Requerimi entos

no

funcional del sistema 3.2.1.1 Especifica ción

de

casos

de

uso 3.2.1.2 Diagrama de

casos

de uso del sistema 3.2.2

Diagrama de clases

3.2.3

Diagrama de Estados

3.2.4

Diagrama de Secuencia

3.2.5

Diagrama de Colaboraci ón

3.3.1

Diagrama Entidad-

40

Relación 3.3.2

Modelo

P

R

Físico 3.3.3

Definir

R

estándare s

de

codificació n 3.3.4

P

R

Implemen tación

de

la Base de Datos 3.3.5

Datos

R

Diccionari o

de

Datos 4.1.1

Plan

de

R

P

P

V

Pruebas 4.2.1

V Realizació n

de

Prueba 4.2.2

Informe

V

de Prueba 5.1.1 Manual del

R

Sistema 5.1.2 Manual de

R

Usuario 5.1.3 Ayuda del

R

41

Sistema 5.2.1

Plan

de

A

Capacitaci ón 5.2.2

Informe

A

de Capacitaci ón

IDENTIFICACIÓN Y SECUENCIAMIENTO DE ACTIVIDADES

42

Paquete de Trabajo

Actividad del Paquete de Trabajo

Código WBS

Nombre

Código

Nombre

1.1.

Análisis

1.1.A01

Identificación de problemas o necesidades

Analizar el negocio

Delimitación del problema o descripción de la necesidad

Redactar el problema encontrado en la empresa

1.1.A02

Alcance del Trabajo de la Actividad

Act. Predecesora Tipo de RelaciónAdelan to/Atraso

1.1.A01

Restricciones o Supuestos

Fecha Impuesta

Persona Responsabl e

Zona Geográfica

BMPF

Oficina DIRCETUR

BMPF

Tipo de Actividad

SECUENCIAMIENTO DE ACTIVIDADES DENTRO DEL PAQUETE DE TRABAJO

1.1. A 0 1

Oficina DIRCETUR

1.1.

1.1.

1.2

1.3

1.4

Project Charter

Identificar a los interesados

Reuniones

1.1.A03

Revisión de Fuentes de información relacionadas

Redactar informe con la información mas importante

1.2.A01

Reunión con el Sponsor

Reunión inicial de trabajo

1.2.A02

Elaboración de Project Charter

Redactar documento de inicio

1.3.A01

Clasificación de los StakeHolders

Se clasifican a todas las personas u organizaciones que reciben el impacto del proyecto.

1.3.A02

Lista StakeHolders

Se elabora una lista de los interesados del proyecto.

1.4.A01

Realizar reunión de Coordinación

Reunión de Coordinación Semanal del Proyecto

1.1.A02

1.2.A01

BMPF

Aula

BMPF

Oficina DIRCETUR

BMPF

Aula

BMPF

Oficina DIRCETUR

A 0 3

A 0 2

1.2.

1.2. A 0 1

A 0 2

1.3.

1.3.A01

BMPF

Aula

BMPF

Aula

1.3. A 0 1

A 0 2

43

2.1.1

Plan del Alcance

Paquete de Trabajo Código WBS 2.1.2

2.1.1.A0 1

Definición del alcance

Se indican las pautas que debe tener el proyecto.

BMPF

Aula 2.1.1

2.1.1.A0 2

Definir objetivos

Se indican los objetivos del proyecto

2.1.1.A01

BMPF

Aula

2.1.1.A0 3

WBS

Identificamos los Entregables

2.1.1.A02

BMPF

Aula

2.1.1.A0 4

Diccionario WBS

Definimos los entregables

2.1.1.A03

BMPF

Aula

Persona Responsabl e

Zona Geográfica

BMPF

Aula

Actividad del Paquete de Trabajo

Nombre

Código

Nombre

Alcance del Trabajo de la Actividad

Plan de Gestión Schudle

2.1.2.A0 1

Definir Actividades

Redactar las Actividades

Act. Predecesora Tipo de RelaciónAdel anto/Atraso

Restricciones o Supuestos

Fecha Impuesta

2.1.1 A 0 1

2.1.1

2.1.1 A 0 3

Tipo de Actividad

Secuenciar Actividades

Redactar la secuencia

2.1.2.A01

BMPF

Aula

2.1.2.A0 3

Estimar duración de Actividades

Redactar la duración de Actividades

2.1.2.A012

BMPF

Aula

2.2.1.A0 1

Estimaciones de Costo de las Actividades

Redactar las estimaciones de costo de cada actividad dentro de un paquete de trabajo.

BMPF

Aula

A 0 4

Secuenciamiento de actividades dentro del paquete de trabajo

2.1.1

2.1.2.A0 2

A 0 2

2.1.2. A 0 1

A 0 2

2.1.3.

2.2.1

Presupuesto

A 0 2

2.2.1.

2.2.1.

A 0 2

A 0 1

44

2.2.1.A0 2

Base de las Estimaciones

Detallar las estimaciones de costos que deben especificarse.

2.2.1.A01

BMPF

Aula

2.2.2

Costeo del Proyecto

2.2.2.A0 1

Estimaciones de Recursos Necesarios

Redactar los recursos que se necesitaran en la elaboración del proyecto.

BMPF

Aula

2.2.3

Plan de Riesgo

2.2.3.A0 1

Identificación de los Riesgos

Determinar cuáles serán los posibles riesgos que afectaran al proyecto, así como documentarlos.

BMPF

Oficina

2.2.3.A0 2

2.2.3.A0 3

2.2.4

Plan de Calidad

Paquete de Trabajo

Código WBS

3.1.1

2.2.4.A0 1

Análisis de Riesgos

DIRCETUR

A 0 1

Describir como se tendrán que analizar los riesgos, para determinar cuáles son los riesgos más relevantes.

2.2.3.A01

Acciones de Respuesta a los Riesgos

Redactar las diversas formas de cómo tratar los riesgos.

2.2.3.A02

Planificación de Calidad

Identificar cuales requerimientos de calidad o estándares son relevantes tanto para el proyecto como el producto

Actividad del Paquete de Trabajo

Nombre

Código

Nombre

Formular Ámbito del

3.1.1.A01

Establecer ámbitos del software

Alcance del Trabajo de la Actividad Capturar el contexto y los recursos y

2.2.3

BMPF

Oficina DIRCETUR 2.2.3. 2.2.3.

BMPF

A 0 3

A 0 2

Oficina DIRCETUR

BMPF

Oficina DIRCETUR

Act. Predeceso ra Tipo de RelaciónA delanto/At raso

Restricciones o Supuestos

Fecha Impuesta

Tipo de Actividad

Persona Responsabl e

Zona Geográfica

BMPF

Aula

(time driven, resource driven)

Secuenciamiento de actividades dentro del paquete de trabajo

3.1.1

3.1.1. A 0 1

45

A 0 2

Proyecto

3.1.2

Requerim ientos de los usuarios

restricciones más importantes hasta el punto que se puedan derivar criterios de aceptación para el producto final. 3.1.1.A02

Preparar el entorno del proyecto

Valorar el proyecto y la empresa, seleccionar herramientas, decidir las partes del proceso que deben mejorar.

3.1.2.A01

Recopilar Requerimientos

Reunir los requerimientos de los interesados.

3.1.2.A02

3.1.3

Requerim ientos funcional es del sistema

Listar los requerimientos

3.1.1.A01

3.1.1.A02

Documentar requerimientos aprobados

Elaborar un documento que certifique que está aprobado.

3.1.3.A01

Recopilar requerimientos funcionales

Reunir todos los requisitos indispensables funcionales

3.1.3.A03

Listar Requerimientos funcionales

Documentar requerimientos

BMPF

Aula

BMPF

Oficina DIRCETUR

Elaborar un listado de todos los requisitos indispensables.

3.1.2.A03

3.1.3.A02

3.1.1.A01

BMPF

BMPF

Aula

BMPF

Oficina DIRCETUR

3.1.2.A01

Elaborar un documento que

3.1.2.A02

BMPF

Aula

3.1.2. A 0 2

3.1.3. A 0 2

3.1.3 A 0 1

Oficina DIRCETUR

BMPF

A 0 1

Oficina DIRCETUR

Enumerar requerimientos funcionales para su desarrollo

3.1.2

3.1.3.

3.1.3. A 0 3

A 0 2

46

Requerim ientos no funcional es del sistema

3.1.4.A01

3.1.4.A02

funcionales aprobados

certifique la aprobación de los requerimientos

Recopilar Requerimientos funcionales

Reunir todos los requisitos del sistema

Listar los requerimientos

Enumerar y ordenar los requerimientos

3.1.3.A01

Elaborar un documento para la aprobación

3.1.3.A02

3.1.4 3.1.4.A03

Paquete de Trabajo

Código WBS

Actividad del Paquete de Trabajo

Nombre

Código

Nombre

Especific ación de casos de uso

3.2.1.1.A 01

Describir los casos de uso

3.2.1.1

3.2.1.2

Documentar requerimientos aprobados

Diagram a de casos de uso del sistema

Alcance del Trabajo de la Actividad

BMPF

Oficina 3.1.4 DIRCETUR

BMPF

Oficina

Describir el flujo de eventos

Describir lo que el sistema debe hacer.

3.2.1.2.A 01

Identificar los actores

Reconocer los roles del sistema

3.2.1.2.A 02

Identificar los casos de uso y los procesos

Identificar que procesos desarrollara el

A 0 3

3.1.4A DIRCETUR

Act. Predeceso ra Tipo de RelaciónA delanto/At raso

BMPF

Restricciones o Supuestos

Fecha Impuesta

Persona Responsabl e

0 2

Aula

Tipo de Actividad Zona Geográfica

Elaborar una descripción de los casos de uso

3.2.1.1.A 02

3.1.4. A 0 1

(time driven, resource driven)

Secuenciamiento de actividades dentro del paquete de trabajo

3.2.1.1 A 0 1

3.2.1.1.A0 1

BMPF

3.2.1.1 A 0 2

Aula 3.2.1.2

3.2.1.2.A0 1

BMPF

A 0 1

Aula

3.2.1.2

3.2.1.2 A 0 2

47

A 0 3

sistema

3.2.2

3.2.3

Diagram a de Clases

Diagram a de Estados

3.2.1.2.A 03

Desarrollar el diagrama de casos de uso

Graficar las relaciones que existen entre los actores

3.2.2.A01

Definir los Objetivos, métodos y atributos

Identificar las clases del sistema.

3.2.2.A02

Identificar las relaciones

Establecer las relaciones.

3.2.2.A03

Diagramar las clases

3.2.3.A01

Identificar los objetivos

3.2.3.A02

3.2.4

Diagram a de Secuenci a

Identificar las Acciones

Aula

BMPF

Aula 3.2.2

Aula

Elaborar el diagrama de clases.

BMPF

Aula

Indicar que eventos hacen que se pase de un estado a otro.

BMPF

Aula

3.2.2.A01

3.2.3.A02

3.2.4.A01

Identificar los objetos

Identificar los objetos del sistema. Desarrollar la secuencia entre los objetos ya identificados

0 3 0 2

A 0 1 3.2.3.A01

Representar ciclos de vida, en la que hay un estado inicial y un estado final.

3.2.2A A 0 1 3.2.2A

3.2.3

Indicar cuáles son las respuestas y acciones que se generan.

Elaborar el diagrama

Identificar la secuencialidad

BMPF

BMPF

3.2.3.A03

3.2.4.A02

3.2.1.2.A0 2

BMPF

3.2.3.

Aula

A 0 2 3.2.3A

BMPF

Aula

BMPF

Aula

0 3

3.2.4.

3.2.4.A01

BMPF

A 0 1

Aula

3.2.4. A 0 3

3.2.4 A 0 2

48

3.2.4.A3

Paquete de Trabajo

Código WBS

3.2.5

Nombre

Código

Nombre

Diagram a de Colabora ción

3.2.5.A01

Identificar los objetos

Diagram a EntidadRelación

Desarrollar el Diagrama de Secuencia

BMPF

Aula

Persona Responsabl e

Zona Geográfica

Identificar una combinación de información tomada de diagrama de clases, Secuencia y casos de uso

BMPF

Aula

Modelar las interacciones entre objetos

BMPF

Actividad del Paquete de Trabajo

3.2.5.A02

3.3.1

Elaborar el Diagrama

Secuenciar los objetos

Alcance del Trabajo de la Actividad

3.2.4.A02

Act. Predeceso ra Tipo de RelaciónA delanto/At raso

Restricciones o Supuestos

Fecha Impuesta

Tipo de Actividad

A 0 1

3.2.5A 0 2

Aula 3.2.5 A 0 3

Elaborar el Diagrama

Desarrollar el diagrama de colaboración

BMPF

Aula

3.3.1.A01

Identificar las entidades

Visualizar los objetivos que pertenecen a la base de datos.

BMPF

Aula

Describir un objeto que ha sido seleccionado para ser incluido en el modelo de

BMPF

Identificar atributos

Secuenciamiento de actividades dentro del paquete de trabajo

3.2.5

3.2.5.A03

3.3.1.A02

(time driven, resource driven)

3.3.1

3.3.1A A 0 1

Aula

3.3.1A 0 4

0 2

3.3.1A 0 3

49

análisis.

3.3.2

Modelo Físico

3.3.1.A03

Identificar las relaciones

Describir las dependencias entre entidades.

BMPF

Aula

3.3.1.A04

Elaborar Diagrama

Desarrollar el Diagrama EntidadRelación

BMPF

Aula

3.3.2.A01

Analizar Diagrama Entidad-Relación

Escribir el almacenamiento de los datos en el ordenador.

BMPF

Aula

3.3.2.A02

Elaborar el Diagrama del Modelo de Datos

Realizar diagrama de clases y diagrama de entidad relación.

BMPF

Aula

Paquete de Trabajo

Códig o WBS

Nombre

Actividad del Paquete de Trabajo

Código

3.3.2A012

Act. Predecesora Tipo de Relación Adelanto/Atraso

Nombre

Alcance del Trabajo de la Actividad

Fecha Impuesta

Persona Responsabl e

Definir 3.3.3.A01 estándares de Codificación

Detallar las líneas de Código

Documentar y describir las líneas de código.

3.3.4

Implementa 3.3.4.A1 ción de la Base de

Elaborar la implementación de la Base de datos

Documentar y elaborar un manual de la implementación

BMPF

Datos3.3.5.A01

Analizar el modelo de datos

Detectar los grupos de variables altamente relacionados entre sí.

BMPF

Documentar y describir 3.3.5.A01 toda la información a

BMPF

Diccionario de Datos 3.3.5.A02

Elaborar el diccionario de

0 1

Tipo de Actividad

Restriccio nes o Supuestos

3.3.3

3.3.5

3.3.2A

Zona Geográfica

(time driven, resource driven)

Secuenciamiento de actividades dentro del paquete de trabajo

Oficina DIRCETUR

3.3.5A

3.3.5

0 2

A 0 1

50

4.1.1

Plan de 4.1.1.A01 Pruebas

4.1.1.A02

4.1.1.A03

4.2.1

Realización 4.2.1.A01 de Prueba

datos

mayor detalle.

Definir unidades del sistema a testear

Se definen los métodos que se usaran para el testeo del sistema.

BMPF

Diseñar pruebas

Desarrollar las pruebas 4.1.1.A01 necesarias para el plan.

BMPF

Elaborar el plan de pruebas

Desarrollar el plan 4.1.1.A02 de pruebas del sistema.

BMPF

Ejecutar pruebas

Se genera y ejecuta las pruebas necesarias.

BMPF

4.1.1.

4.1.1

A 0 2

A 0 4.1.1 1 A 0 3

4.2.1 4.2.1.A02

4.2.2

Informe 4.2.2.A01 de Prueba

4.2.2.A02

Paquete de Trabajo Códig o WBS 5.1.1

Corregir Observaciones

Se realizara las 4.2.1.A01 observaciones del informe.

Identificar observaciones

Se obtienen las observaciones del informe

Desarrollar informe de pruebas

Se realizara el documento donde se detallara el informe de pruebas.

Actividad del Paquete de Trabajo

0 2

4.2.2A

4.2.2 4.2.2.A01

Act. Predecesora Tipo de Relación

Restriccione so Supuestos

Fecha Impuesta

Persona Responsable

Zona Geográfica

Aula

Nombre

Código

Nombre

Manual del Sistema

5.1.1.A0 1

Estudiar el el sistema por proceso y modulo

Comprender todos los procesos y divisiones del sistema.

BMPF

Elaborar el manual de sistema

Desarrollar y especificar 5.1.1.A02 el manual del sistema.

BMPF

Adelanto/Atraso

0 2

A 0 1

Alcance del Trabajo de la Actividad

5.1.1.A0 2

4.2.1A A 0 1

Tipo de Actividad (time driven, resource driven)

Secuenciamiento de actividades dentro del paquete de trabajo

5.1.1A

5.1.1

Aula

0 2

A 0 1

51

5.1.2.A0 1 5.1.2

5.1.3

5.2.1

Estudiar el producto

Manual del Usuario

Ayuda del Sistema

Plan de Capacitación

Analizar detalles y características del producto.

BMPF

Aula

5.1.2.A0 2

Elaborar el manual del usuario

Desarrollar y especificar 5.1.2.A01 manual de usuario.

BMPF

Aula

5.1.3.A0 1

Identificar posibles preguntas y soluciones

Definir Alternativas de preguntas y respuestas de ayuda.

BMPF

Aula

5.1.3.A0 2

Elaborar el manual de ayuda del sistema

Desarrollar y especificar 5.1.3.A01 el manual de ayuda del sistema.

BMPF

Aula

5.2.1.A0 1

Elaborar el plan de capacitación

Desarrollar y redactar el plan de capacitación.

BMPF

Oficina

5.2.2

Informe de Capacitación

5.2.2.A0 1

5.2.2.A0 2

Realizar las coordinaciones finales

Establecer los puntos 5.2.1.A01 finales a desarrollar.

Desarrollar informe de primera capacitación

Redactar un documento de primera capacitación

Desarrollar informe de segunda

Redactar un documento 5.2.2.A01 de primera capacitación

0 2

A 0 1

5.1.3A

5.1.3

DIRCETUR 5.2.1.A0 2

5.1.2A

5.1.2

BMPF

0 2

A 0 1

5.2.1A

5.2.1

0 2

A 0 1

Oficina DIRCETUR

5.2.2A

5.2.2

0 2

A 0 1 5.2.2A 0 2

Capacitación 5.2.2.A0 3

Desarrollar informe de tercera capacitación

Redactar un documento 5.2.2.A02 de primera capacitación

52

ESTIMACIÓN DE RECURSOS Y DURACIONES

Entregable

1.1 Análisis

Actividad

Tipo de Recurso: Personal

Tipo de Recurso: Materiales o Consumibles

Tipo de Recurso: Máquinas o no Consumibles.

Nombre Trabajo de (Hr Recurso Hom)

Nombre de Recurso

Nombre de Recurso

Duración (hrs)

1.1.A01 Identificación de problemas o necesidades

BMPF

3hrs –h

6 hr

1.1.A02 Delimitación del problema o descripción de la necesidad

BMPF

4hrs – h

4 hr

1.1.A03 Revisión de fuentes de información relacionadas

Cantidad

Cantidad

Forma de Cálculo

Escritorio 1 PC PC BMPF

6hrs –h

6 hr

1 Impresora

1.2.A01 Reunión con el Sponsor 1.2 Project Charter

BMPF

1.2.A02 Elaboración de Project Charter

2hrs – h

4 hr

4hrs – h

4 hr

PC 2 Impresora

1.3.A01 Clasificación de los 1.3 Identificar a StakeHolders los interesados

BMPF

BMPF

2hrs – h

4 hr

PC

1

2hrs – h

4 hr

PC

1

1.3.A02 Lista de StakeHolders

53

1.4 Reuniones

1.4.A01 Realizar reunión de Coordinación

2.1.1.A01 Definición del alcance 2.1.1.A02 Definir objetivos 2.1.1 Plan Alcance

BMPF

BMPF

2hr – h

2 hr

Escritorio

1

3hr – h

6 hr

PC

1

2hrs - h

4 hr

BMPF

PC 1 Escritorio

del 2.1.1.A03 WBS

BMPF

PC 2hr – h

4 hr

1 Impresora

2.1.1.A04 Diccionario WBS

2.1.2 Plan de Gestión de Schudle

2.2.1 Presupuesto

2.1.2.A01 Definir Actividades

BMPF

2.1.2.A02 Secuenciar Actividades

BMPF

2.1.2.A03 Estimar duración de Actividades

BMPF

2.2.1.A01 Estimaciones de Costo de las Actividades

BMPF

2.2.1.A02 Base de las Estimaciones

BMPF

2.2.2 Costeo del 2.2.2.01 Estimaciones de Proyecto Recursos Necesarios

2.2.3 Plan de Riesgo

BMPF

2.2.3.A01 Identificación de los Riesgos 2.2.3.A02 Análisis de

BMPF

BMPF

BMPF

3hr – h

6 hr

PC

1

2hr – h

4 hr

PC

1

4hr – h

4 hr

PC

1

2hr – h

4 hr

PC

1

2hr – h

4 hr

3hr – h

6 hr

4hr – h

4 hr

2hr – h

4 hr

3hr – h

6 hr

54

Riesgos BMPF 2.2.3.A03 Acciones de Respuesta a los Riesgos 2.2.4 Plan de Calidad

3.1.1 Formular Ámbito del Proyecto

3.1.2 Requerimientos de los Usuarios

3.1.3 Requerimientos funcionales del Sistema

2.2.4.A01 Planificación de Calidad

BMPF

3.1.1.A01 Establecer ámbitos del software.

BMPF

3.1.1.A02 Preparar el entorno del proyecto

BMPF

3.1.2.A01 Recopilar Requerimientos

BMPF

3.1.2.A02 Listar los requerimientos

BMPF

3.1.32.A03 Documentar requerimientos aprobados

BMPF

3.1.3.A01 Recopilar requerimientos funcionales

BMPF

3.1.3.A02 Listar Requerimientos funcionales

BMPF

3.1.3.A03 Documentar requerimientos funcionales aprobados

BMPF

3.1.4.A01 Recopilar Requerimientos 3.1.4 Requerimientos no funcionales del

BMPF

3hr – h

6 hr

4hr – h

8 hr

4hr – h

4 hr

4hr – h

4 hr

8hr – h

8 hr

2hr – h

4 hr

4hr – h

4 hr

8hr – h

8 hr

4hr – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

55

Sistema

funcionales 3.1.4.A02 Listar los requerimientos

BMPF

2hrs – h

4 hr

3.1.4.A03 Documentar requerimientos aprobados

BMPF

2hrs – h

4 hr

3.2.1.1.A01 Describir los casos de uso 3.2.1.1 Especificación de casos de3.2.1.1.A02 uso Describir el flujo de eventos

BMPF

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

BMPF

2hrs – h

4 hr

3.2.2.A03 Diagramar las clases

BMPF

2hrs – h

4 hr

3.2.3.A01 Identificar los objetivos

BMPF

2hrs – h

4 hr

3.2.3 Diagrama de3.2.3.A02 Estados Identificar las Acciones

BMPF

2hrs – h

4 hr

3.2.3.A03 Elaborar el diagrama

BMPF

2hrs – h

4 hr

3.2.4.A01 Identificar los objetos

BMPF

2hrs – h

4 hr

BMPF

2hrs – h

4 hr

2hrs – h

4 hr

4hrs – h

8 hr

3.2.1.2.A01 Identificar los actores

BMPF

BMPF

3.2.1.2 Diagrama de 3.2.1.2.A02 casos Identificar los casos de de uso del uso y los procesos sistema

BMPF

3.2.1.2.A03 Desarrollar el diagrama de casos de uso

BMPF

3.2.2.A01 Definir los Objetivos, métodos y atributos

BMPF

3.2.2 Diagrama de Clases 3.2.2.A02 Identificar las relaciones

3.2.4.A02 Identificar la secuencialidad 3.2.4 Diagrama de secuencia 3.2.4.A3 Elaborar el Diagrama

3.2.5.A01 Identificar los objetos 3.2.5 Diagrama de

BMPF

BMPF

56

Colaboración 3.2.5.A02 Secuenciar los objetos

3.2.5.A03 Elaborar el Diagrama

3.3.1.A01 Identificar las entidades 3.3.1 Diagrama 3.3.1.A02 Entida Identificar atributos dRelaci Identificar las relaciones 3.3.1.A03 ón 3.3.1.A04 Elaborar Diagrama 3.3.2.A01 Analizar Diagrama EntidadRelación 3.3.2 Modelo Físico 3.3.2.A02 Elaborar el Diagrama del Modelo de Datos

BMPF 3hrs – h

6 hr

2hrs – h

4 hr

BMPF

2hrs – h

4 hr

BMPF

8hrs – h

16 hr

BMPF

2hrs – h

4 hr

BMPF

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

8hrs – h

16 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

BMPF

BMPF

BMPF

3.3.3 Definir estándares 3.3.3.A01 de Detallar las líneas de Codificación Código

BMPF

3.3.4 Implementación 3.3.4.A1 de la Elaborar la implementación Base de Datos de la Base de datos

BMPF

3.3.5.A01 Analizar el modelo de datos 3.3.5 Diccionario de Datos 3.3.5.A02 Elaborar el diccionario de datos 4.1.1.A01 Definir unidades del sistema a testear 4.1.1 Plan de Pruebas 4.1.1.A02 Diseñar pruebas 4.1.1.A03 Elaborar el plan de pruebas

BMPF BMPF

BMPF

BMPF BMPF

2hrs – h

4 hr

57

4.2.1.A01 Ejecutar pruebas 4.2.1 Realización de Prueba Corregir Observaciones 4.2.1.A02

BMPF

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

8hrs – h

16 hr

4 hrs – h

8 hr

8hrs – h

16 hr

2hrs – h

4 hr

8hrs – h

16 hr

2hrs – h

4 hr

2hrs – h

4 hr

2hrs – h

4 hr

BMPF

4.2.2.A01 Identificar observaciones B M P F

4.2.2 Informe de prueba 4.2.2.A02 Desarrollar informe de pruebas 5.1.1.A01 Estudiar el sistema por proceso y modulo 5.1.1 Manual del Sistema 5.1.1.A02 Elaborar el manual de sistema 5.1.2.A01 Estudiar el producto 5.1.2 Manual del Usuario

BMPF

BMPF

5.1.2.A02 Elaborar el manual del usuario

5.1.3.A01 Identificar posibles preguntas y soluciones 5.1.3 Ayuda del Sistema 5.1.3.A02 Elaborar el manual de ayuda del sistema 5.2.1.A01 Elaborar el plan de 5.2.1 Plan de capacitación Capaci tación 5.2.1.A02 Realizar las coordinaciones finales 5.2.2 Informe de

BMPF

5.2.2.A01 Desarrollar informe de primera

BMPF

BMPF

BMPF

BMPF

BMPF

`

58

Capaci capacitación tación 5.2.2.A02 Desarrollar informe de segunda

BMPF 5 hrs – h

10 hr

16hrs – h

32 hr

Capacitación 5.2.2.A03 Desarrollar informe de tercera capacitación

BMPF

59

C. COSTO PLAN DE GESTIÓN DE COSTOS TIPOS DE ESTIMACIÓN DEL PROYECTO: TIPO DE ESTIMACIÓN

MODO DE FORMULACIÓN

ORDEN DE MAGNITUD

Análisis de Reserva

PRESUPUESTO

Bottom Up

NIVEL DE PRECISIÓN

-50% al + 100% -15% al + 25%

UNIDADES DE MEDIDA:. TIPO DE

RECURSO

UNIDADES DE MEDIDA

Recurso Personal

Costo/hora

Recurso Material o consumible

Unidades

Recurso

Unidades

Maquinas

o

No

Consumibles

UMBRALES DE CONTROL ALCANCE: PROYECTO/FASE/ENT

VARIACIÓN PERMITIDA

REGABLE

Proyecto Completo

+ / -5% costo planificado

ACCIÓN A TOMAR SI VARIACIÓN EXCEDE LO PERMITIDO

Investigar

variación

tomar

para acción

correctiva

MÉTODOS DE MEDICIÓN DE VALOR GANADO ALCANCE: PROYECTO/FASE/ENTRE GABLE

Proyecto Completo

MÉTODO DE MEDICIÓN

MODO DE MEDICIÓN

Valor acumulado – Reporte del Performance Semanal Curva S

del Proyecto

FORMULAS DE PRONÓSTICO DEL VALOR GANADO: TIPO DE PRONÓSTICO

FÓRMULA

MODO:

60

EAC

Variaciones AC + (BAC-EV) / CPI

Comité de Gestión de Cambios y

Tipicas

actualizaciones

emite

informes

de

según

cronograma

el

seguimiento del

proyecto.

NIVELES DE ESTIMACIÓN Y DE CONTROL TIPO DE ESTIMACIÓN DE

NIVEL DE ESTIMACIÓN DE COSTOS

COSTOS

Orden de Magnitud

Por fase

Presupuesto

Por

fase

NIVEL DE CONTROL DE COSTOS

No aplica /

entregable-fase

/ Por fase / entregable-fase /

recurso-semanalmente

recurso-semanalmente

PROCESOS DE GESTIÓN DE COSTOS: PROCESO DE GESTIÓN DE COSTOS

DESCRIPCIÓN: Se estima los costes del proyecto en base al tipo de

Estimación de costes

estimación por presupuesto. Esto se realiza en la planificación del proyecto y es aprobado por el Sponsor. Preparación de presupuesto Costes

su Se elabora el presupuesto del proyecto y las reservas de de gestión del proyecto. Este documento es elaborado por el Program Manager y revisado y aprobado por el Sponsor.

Control de Costes



Se evaluara el impacto de cualquier posible cambio del costo, informando al Sponsor los efectos en el proyecto.



El análisis de impacto deberá ser presentado al Sponsor y evaluara distintos escenarios posibles.



Toda variación final dentro del +/-5% del presupuesto será considerada como normal.

FORMATOS DE GESTIÓN DE COSTOS: FORMATO DE GESTIÓN DE COSTOS Costeo del Proyecto

DESCRIPCIÓN: Este informe detalla los costos a nivel de las actividades de cada

entregable, según el

tipo

de

recurso

que

participe.

61

Presupuesto

por

Fase

y El formato de Presupuesto por Fase y entregable informa los costos del proyecto, divididos por Fases, y cada fase

Entregable

divididos en entregables Presupuesto por Fase y por El formato de Presupuesto por Fase y por Tipo de Recurso informa los costos del proyecto, divididos por Fases, y

Tipo de Recurso

cada

fase

dividido

en

entregables.(personal,

materiales, maquinaria) Presupuesto por Semana

El formato Presupuesto por Semana informa los costes del proyecto por semana y los costes acumulados por semana

SISTEMA DE CONTROL DE COSTOS: DESCRIPCIÓN: Cada responsable del equipo de proyecto emite un reporte semanal informando los entregables realizados y el porcentaje de avance. El Project Manager se ubicar la información del equipo de proyecto en el Cronograma, actualizando el proyecto según los reportes del equipo. El

coste

del

proyecto

puede

tener

una

variación

de

+

/- 5% del total planeado, si como resultado de la re-planificación del proyecto estos márgenes son superados se necesitara emitir una solicitud de cambio, la cual deberá ser revisada y aprobada por el jefe del Proyecto y el Sponsor.

SISTEMA DE CONTROL DE CAMBIOS DE COSTOS: 

El Sponsor y el Jefe de Proyectos son los responsables de evaluar, aprobar o rechazar las propuestas de cambios.



Todos los cambios de costos deberán ser evaluados gradualmente, teniendo en cuenta para ellos los objetivos del proyecto.



Los documentos que serán afectados o utilizados en el Control de Cambios de Costos son:



o

Solicitud de Cambios

o

Acta de reunión de coordinación del proyecto

o

Plan del Proyecto

Una solicitud de cambio sobre el coste del proyecto que no exceda el +/- 5% del presupuesto del proyecto

puede

ser aprobada por el jefe del

Proyecto, un

requerimiento de cambio superior será resuelta por el Sponsor.

62

PRESUPUESTO DEL PROYECTO - POR FASE Y POR ENTREGABLE – PROYECTO

FASE INICIO

ENTREGABLE 1.1. Analisis 1.2. Project Charter 1.3. Identificacion de los Usuarios

MONTO $ 50.00 100.00 30.00

1.4. Reuniones

50.00

Total Fase PLANIFICACION

2.1.1 Plan de Alcance 2.1.2. Plan de Gestión Schedule

SISTEMA WEB DE PROD UCTOS EXPOR TABLE S

200.00 8 0 . 0 0

2.2.1. Presupuesto

150.00

2.2.2. Costeo del Proyecto

100.00

2.2.3.

Plan de Calidad

80.00

Total Fase 3.EJECUCION

3.1.1 Fase Inicial

300.00

3.1.2 Fase de Elaboración

500.00

3.1.3 Fase Construcción 3.1.4 Fase Transición

4.1. Pruebas y Testeo

4.2.1. Realización de Prueba

610.00

1000.00 700.00

Total Fase CONTROL Y SEGUIM IENTO

230.00

2500.00

200.00 300.00 150.00

4.2.2. Informe de Prueba

63

Total Fase CIERRE

5.1. Documentación del sistema

300.00

5.2 Capacitación Técnica

600.00

Total Fase

650.00

900.00

TOTAL FASES

4890.00

Reserva de Contingencia

244.5

Reserva de Gestión

244.5

PRESUPUESTO TOTAL DEL PROYECTO

5379.00

PRESUPUESTO DEL PROYECTO - POR FASE Y POR TIPO DE RECURSO TIPO DE PROYECTO

FASES

MONTO $

RECU RSO

1. Inicio

Personal

800.00

Materiales

250.00

Maquinaria

80.00

Total Fase 2. Planificación

Personal

529.00

Materiales

430.00

Maquinaria

150.00

Total Fase

Sistema Web de Productos Exportable

3. Ejecución

Personal

3500.00

Materiales

1400.00

Maquinaria

1130.0 0

1109.0 0

200.00

64

s

Total Fase Personal

4. Control y Seguimiento

1020.00

Materiales

103.40

Maquinaria

600.00

Total Fase Personal

5. Cierre

5100.0 0

1723.4 0

1230.00

Materiales

200.50

Maquinaria

800.00

Total Fase

2230.5 0

TOTAL FASES

9569.00

Reserva de Contingencia

244.5

Reserva de Gestión

244.5

PRESUPUESTO TOTAL DEL PROYECTO

10058.5

D. Recursos Humanos

DESCRIPCIÓN DE ROLES NOMBRE DEL ROL

SPONSOR OBJETIVOS DEL ROL: Es la persona que patrocina el proyecto, es el principal interesado en el éxito del proyecto, y por lo tanto la persona que apoya, soporta y defiende el proyecto. Es la persona que acompaña en toda la ejecución del proyecto. RESPONSABILIDADES:  Aprobar el Proyect Charter 

Aprobar el Scope Statement



Aprobar el Plan del Proyecto



Aprobar el cierre del Proyecto



Aprobar todos los informes de de las fases del proyecto



Revisar los informes semanales del proyecto

65

FUNCIONES: 

Iniciar el proyecto.



Aprobar la planificación del proyecto



Monitorear el estado del proyecto



Cerrar el proyecto



Pertenece al comité de control de cambio del proyecto



Asigna los recursos al proyecto



Ayuda en la solución de problemas y superación de obstáculos del proyecto

NIVELES DE AUTORIDAD: 

Decide sobre modificaciones a la línea base del proyecto



Decide sobre planos y programas del proyecto

REPORTA A: A QUIÉN REPORTA DENTRO DEL PROYECTO.



Directora de Comercio Exterior y Turismo SUPERVISA A: 

Project Manager

REQUISITOS DEL ROL: CONOCIMIENTOS:

HABILIDADES:



Gestión del Proyecto según el PMBOK

   

Comunicación Liderazgo Solución de Conflictos Motivación

EXPERIENCIA: OTROS:

NOMBRE DEL ROL

PROJECT MANAGER OBJETIVOS DEL ROL: Es la persona que gestiona el proyecto, es el principal responsable para el éxito del proyecto, y por lo tanto es la persona que asume el liderazgo y la administración de los recursos del proyecto para lograr los objetivos patrocina el proyecto, es el principal interesado en el éxito del proyecto, y por lo tanto la persona que apoya, soporta y defiende el proyecto. Es la persona que acompaña en toda la ejecución del proyecto. RESPONSABILIDADES:

66



Aprobar el Proyect Charter



Aprobar el Scope Statement



Aprobar el Plan del Proyecto



Aprobar el cierre del Proyecto



Aprobar todos los informes de de las fases del proyecto



Revisar los informes semanales del proyecto

FUNCIONES: 

Ayudar al Sponsor a iniciar el proyecto.



Planificar el proyecto.



Ejecutar el proyecto.



Controlar el proyecto.



Cerrar el proyecto.



Ayudar a Gestionar el Control de Cambios del proyecto.



Gestionar los recursos del proyecto.



Solucionar problemas y superar los obstáculos del proyecto.

: QNUÉ DECISIONES TOMAR CON IVELES DE PUEDE AUTORIDAD : RELACIÓN 

Decide sobre la programación detallada de los recursos humanos y materiales asignados al proyecto.



Decide sobre la información y los entregables del proyecto.

REPORTA A:



Sponsor

SUPERVISA A:



Equipo del Proyecto

REQUISITOS DEL ROL: CONOCIMIENTOS:

HABILIDADES:

 

Gestión del Proyecto según el PMBOK Tecnologías de Información.

   

Comunicación Liderazgo Motivación Solución de Conflicto

EXPERIENCIA: OTROS: .

67

NOMBRE DEL ROL Encargado de la Base de Datos OBJETIVOS DEL ROL: El DBA es un profesional en procesamiento de datos, crea la base de datos en sí y pone en vigor los controles técnicos necesarios para apoyar las políticas dictadas por el Analista Programador garantizando el funcionamiento adecuado del sistema y de proporcionar otros servicios de índole técnica relacionados. La responsabilidad primordial es facilitar el desarrollo y el uso de la Base de Datos dentro de las guías de acción definidas por la administración de los datos. RESPONSABILIDADES:  Administra la estructura de la Base de Datos 

Administra la actividad de los datos



Administra el Sistema Manejador de Base de Datos



Establece el Diccionario de Datos



Asegura la confiabilidad de la Base de Datos

FUNCIONES: 

Suministrar la información necesaria al Project Manager.

NIVELES DE AUTORIDAD: QUÉ DECISIONES PUEDE TOMAR CON NIVELES DE AUTORIDAD:



Decide sobre la información suministrada por la base de datos..

REPORTA A:



Project Manager.

SUPERVISA A: REQUISITOS DEL ROL: CONOCIMIENTOS:

HABILIDADES:

EXPERIENCIA:



Conocimiento de manejo en base de datos.



Manejo de sistemas como SAP.



Inteligencia emocional.



Capacidad de análisis de datos al detalle.



Motivación.



Gestión de Base de datos (2 años).

OTROS:

68

DIRECTORIO DEL EQUIPO DE PROYECTO ROL / PERSONA

SPONSOR

Project Manager

Administrador

DATOS PERSONALES

DATOS EMPRESA

NOMBRES Y APELLIDOS

Carlos Jesus Murguia Moron

NOMBRE

Gobierno Regional ICA

DIRECCIÓN

Urb. El Bosque B-22

ÁREA

Comercio Exterior

TELÉFONO

CARGO

Director de Comercio Exterior

CELULAR

TELÉFONO / FAX

238710/227287 Anexo 21

CORREO PERSONAL

[email protected]

CORREO EMPRESA

NOMBRES Y APELLIDOS

Pablo Fernando Bohorquez Murguia

NOMBRE

DIRECCIÓN

Urb. El Bosque B-22

ÁREA

TELÉFONO

CARGO

CELULAR

956227112

TELÉFONO / FAX

CORREO PERSONAL

[email protected]

CORREO EMPRESA

NOMBRES Y APELLIDOS

Jorge Espinoza Miranda

NOMBRE

Gobierno Regional Ica

DIRECCIÓN

ÁREA

Comercio Exterior

TELÉFONO

CARGO

Administrador

CELULAR

TELÉFONO / FAX

238710/227287 Anexo 21

CORREO EMPRESA

[email protected]

CORREO PERSONAL

[email protected]

69

ORGANIGRAMA DEL PROYECTO SPONSOR Dir. Carlos Jesús Murguía Morón Comité de control de Cambios

Asesor Gerente de Operacion es

Ing. Erwin Peña Casas

Project Manager Pablo Fernando Bohórque z Murguía

PLAN DE RECURSOS HUMANOS CAPACITACIÓN, ENTRENAMIENTO, MENTORING REQUERIDO: 1. El Jefe del Proyecto se encargar la lista de temas a dictar. 2. Se realizara una evaluación al final de la capacitación. 3. Los resultados de la evaluación final se tomaran en cuenta para posibles cambios en el área. SISTEMA DE RECONOCIMIENTO Y RECOMPENSAS

66

1. Recursos Humanos y Comunicaciones elabora y controla un Sistema de Incentivos y Sanciones que evalúa el cumplimiento de las actividades y asistencias del personal

a las reuniones, semanalmente entrega un

informe al Jefe del Proyecto. 2. Realiza consultas (auto evaluativas y observaciones al equipo, jefes u otros) y se entrevista con los jefes de las áreas para tratar posibles problemas con el personal acerca de la participación en el trabajo y su modo de integración como área. CUMPLIMIENTO DE REGULACIONES, PACTOS, Y POLÍTICAS: 1. Todo el personal que participa del proyecto será controlado por el sistema de Incentivos y Sanciones elaborado por el área de Recursos Humanos y Comunicaciones, y por la evaluación personal del Jefe del Proyecto. 2. La nota resultado de este proceso será entregado al Sponsor en sobre cerrado por el jefe del Proyecto.

REQUERIMIENTOS DE SEGURIDAD: 

El traslado de equipos (laptos) hacia y desde los locales de reunión o programación, genera riesgo o robo o asalto para el personal que traslada el equipo, por tanto se fija como requerimiento de seguridad que cualquier traslado de equipos debe ser hecho por un mínimo de dos personas(nunca solo), y con movilidad(taxi).



Los periodos de descanso en laos intermedios de las reuniones generan un riesgo de robo de los equipos del proyecto (laptops).

E. Comunicaciones

PLAN DE GESTIÓN DE COMUNICACIONES PROCEDIMIENTO PARA TRATAR POLÉMICAS: DEFINA EL PROCEDIMIENTO PARA PROCESAR Y RESOLVER LAS POLÉMICAS, ESPECIFICANDO LA FORMA DE CAPTURARLAS Y REGISTRARLAS, EL MODO EN QUE SE ABORDARÁ SU TRATAMIENTO Y RESOLUCIÓN, LA FORMA DE CONTROLARLAS Y HACERLES SEGUIMIENTO, Y EL MÉTODO DE ESCALAMIENTO EN CASO DE NO PODER RESOLVERLAS.

67

1. Se captan todas las polémicas presentadas durante las reuniones formales del equipo de proyecto. 2. Se codifican y registran las polémicas en el log de Control de polemicas considerando el siguiente formato: Log de Polémicas Código de

Enfoque de Descripción

Involucrados

Polémica

Solución

Acciones de Solución

Responsable

Fecha

Resultado Obtenido

3. Antes de cada reunión, los responsables de Comunicación proceden a revisar el Log Control de Polémicas con el fin de: A) Verificar la existencia de polemicas para determinar las posibles soluciones con el equipo de Gestión del Proyecto. B) Realizar un seguimiento a las soluciones programadas que se están aplicando. C) Revisar si las soluciones han sido efectivas y si la polémica a sido resuelta

PROCEDIMIENTO PARA ACTUALIZAR EL PLAN DE GESTIÓN DE COMUNICACIONES: DEFINA EL PROCEDIMIENTO PARA REVISAR Y ACTUALIZAR EL PLAN DE GESTIÓN DE COMUNICACIONES.

1. Identificación y clasificación de stakeholders. 2. Determinación de requerimientos de información 3. Elaboración de la Matriz de Comunicaciones del Proyecto. 4. Actualización del Plan de Gestión de las Comunicaciones. 5. Aprobación del Plan de Gestión de las Comunicaciones. 6. Difusión del nuevo Plan de Gestión de las Comunicaciones.

GUÍAS PARA EVENTOS DE COMUNICACIÓN:

DEFINA GUÍA PARA REUNIONES, CONFERENCIAS,

CORREO ELECTRÓNICO, ETC.

Guias para Reuniones: Todas las reuniones deberían seguir las siguientes pautas: 1. Se debe emitir un Acta de Reunion la cual se debe repartir por medio del correo electrónico, a los participantes. 2. Debe fijarse la agenda con anterioridad, la cual esta presente en las actas de reuniones. 3. Debe coordinarse e informase la fecha, hora y lugar con los participantes. 4. La puntualidad, tomandose como referencia para evaluar a los miembros del grupo.

68

GUÍAS PARA DOCUMENTACIÓN DEL PROYECTO:

DEFINA LAS GUÍAS PARA CODIFICACIÓN,

ALMACENAMIENTO, RECUPERACIÓN, Y REPARTO DE LOS DOCUMENTOS DEL PROYECTO.

Guías para Recuperación y Reparto de documento 1. El reparto de documentos digitales estará a cargo del Area de comunicaciones la cual usara el correo electrónico de l equipo como medio de comunicación. 2. El reparto de documentos físicos para los interesados, estará a cargo del area de RRHH y Comunicaciones la cual usará el correo electrónico del equipo como medio

de

comunicación

GUÍAS PARA EL CONTROL DE VERSIONES:

DEFINA GUÍAS PARA REGISTRO Y CONTROL ORDENADO DE

LAS VERSIONES DE LOS DOCUMENTOS DEL PROYECTO.

1.

Los documentos de Gestión de Proyectos presentados al Sponsor están sujetos al Control de versiones, dicho Control de versiones se encuentra ubicado en la cabecera de cada documento y tiene el siguiente formato. CONTROL DE VERSIONES

Código de

Aprobada Hecha por

Versión

Fecha

Revisada por

Motivo

por

2. Cada vez que se emite una versión del documento se llena una fila en la

cabecera, anotando la versión, quien emitió el documento, quien lo reviso, quien lo aprobó, a que fecha corresponde la versión y porque motivo se emitió dicha versión.

69

F. Riesgos

IDENTIFICACIÓN Y EVALUACIÓN CUALITATIVA DE RIESGOS PROBABILIDAD

VALOR NUMÉRICO

Muy Improbable Relativamente Probable Probable Muy Probable Casi Certeza

CÓDIGO DEL

RIESG O

R001

0.1 0.3 0.5 0.7 0.9

IMPACTO

Muy Bajo Bajo Moderado Alto Muy Alto

VALOR

NUMÉRICO 0.05 0.10 0.20 0.40 0.80

DESCRIPCIÓN

R I SGO

PROBABILIDAD

X

Mayor a I 0.50 MPACTO Menor a 0.50 Menor a 0.30 menor a 0.10 Menor a 0.05

ESTIMACIÓN

DEL

RIES

TIPO DE Muy Alto Alto Moderado Bajo Muy Bajo

CAUSA RAÍZ

GO

TRIGGER

ENTREGABLES AFECTADOS

Falta de Falta de información información específica para la específica para la definición del definición del alcance del proyecto alcance del proyecto

1.2 Project Charter

DE

PROBABILID

OBJETIVO

ESTIMACIÓN PROB DE IMPACTO

AD

AFECTADO

0.5

Alcance 0.7 Tiempo Costo Calidad TOTAL PROBABILIDAD

1.3 Scope Statement

X

TIPO DE

IMPACTO RIESGO Alto

X

0.35

IMPACTO

R002

Incumplimiento de las tareas asignada s a cada personal

Desinterés o Actividad no irresponsabilidad culminada a dealgunos miembros tiempo del equipo

Todo el proyecto

0.5

Alcance 0.5 Tiempo 0.6 Costo 0.6 Calidad TOTAL PROBABILIDAD

0.25 0.30 0.30 X

Muy Alto

0.85

IMPACTO

70

CÓDIGO DESCRIPCIÓN DEL RIESGO DEL RIESGO

R003

R004

Finalización de los entregables fuera de la fecha establecida

Información desactualizada de los costos incurridos

ENTREGABLES AFECTADOS

CAUSA RAÍZ

TRIGGER

Desorganización por los equipos de trabajo y poca comunicación entre sus miembros y el lider

Retraso en Todo el Proyecto presentación de entregable a cliente

Ineficiencia en Informes de los Presupuestos procedimientos de la gestión de cambios y costos

ESTIMACIÓN DE PROBABILIDAD 0.4

OBJETIVO AFECTADO

ESTIMACIÓN DE PROB X IMPACTO IMPACTO

Alcance 0.4 Tiempo 0.6 Costo 0.2 Calidad 0.4 TOTAL PROBABILIDAD

0.16 0.24 0.08 0.16 X

TIPO DE RIESGO

Alto

0.64

IMPACTO Plan general del Proyecto Mediciones del rendimiento del costo

0.3

Alcance Tiempo Costo 0.8 Calidad TOTAL PROBABILIDAD

Bajo 0.24 X

0.24

IMPACTO

71

R005

Documentación Poca Informalidad al ineficiente disponibilidad momento de relacionada a la de información desarrollar el metodología del de apoyo para producto trabajo el equipo del proyecto

Planificación del Proyecto

0.3

Construcción

Alcance 0.8 Tiempo Costo Calidad 0.4 TOTAL PROBABILIDAD

0.24

Bajo

0.12 0.36

X

IMPACTO

R006

Combinación de Debido que los Complejidad de diversos programadores integración lenguajes par el contratados no modular desarrollo del cuentan con software los mismos conocimientos

4.0 Construcción

0.3

Alcance Tiempo 0.4 Costo 0.3 Calidad 0.5 TOTAL PROBABILIDAD

Bajo

X

0.12 0.09 0.15 0.36

IMPACTO CÓDIGO DEL DESCRIPCIÓN RIESGO DEL RIESGO

R007

R008

Que se presente un desastre natural: Terremoto o Tsunami

CAUSA RAÍZ

TRIGGER

Desorganización Que se de el por los equipos movimiento de trabajo y

poca comunicación Telúrico. entre sus miembros y el Que se de la lider alerta al Tsunami Información Ineficiencia en Informes de desactualizada los Presupuestos de los costos procedimientos incurridos de la gestión de cambios y costos

ENTREGABLES AFECTADOS Todo el Proyecto

ESTIMACIÓN DE PROBABILIDAD 0.10

OBJETIVO AFECTADO

ESTIMACIÓN DE IMPACTO

Alcance Tiempo 0.80 Costo 0.80 Calidad TOTAL PROBABILIDAD

PROB X IMPACTO

TIPO DE RIESGO

Alto 0.08 0.08 X

0.16

IMPACTO Plan general del Proyecto Mediciones del rendimiento del costo

0.3

Alcance Tiempo Costo 0.8 Calidad TOTAL PROBABILIDAD

Bajo 0.24 X

0.24

IMPACTO

72

PLAN DE GESTION DE RIESGOS METODOLOGÍA DE GESTIÓN DE RIESGOS

Proceso Planificación de

Descripción

Herramientas

Fuentes de Informac Sponsor, Equipo de ión

Elaborar el plan de Gestión PMBOK

Gestión de

de Riesgos

Riesgos Identificación de Identificar que riesgos pueden afectar el los riesgos proyecto y documentar sus características. Análisis

Proyecto Recopilación de información mediante tormenta de ideas.

Sponsor, Equipo del Proyecto

Priorizar los riesgos y evaluar la probabilidad de ocurrencia y el Planificación de impacto de Desarrollar opciones y Estrategia de Equipo el dichos riesgos. acciones para respuesta para Proyecto Respuesta a los incrementar las contingencias Riesgos oportunidades y reducir las amenazas a los Monitoreo y Implementar planes objetivos del de Reevaluación de los Sponsor, Jefe de Control de respuesta a los riesgos proyecto, Proyecto. Riesgos riesgos. Equipo del Reuniones sobre el Proyecto Identificar nuevos estado del ROLES Y RESPONSABILIDADES DE GESTIÓN DE RIESGOS riesgos proyecto. Cualitativo de Riesgos

Proceso

Roles

Personas

Responsabilidades

Planificación de Sponsor Gestión de Riesgos

CJMM

Revisar y Aprobar el Plan

Identificación de los riesgos

Jefe de Proyecto

CJMM PFBM

Liderar laelejecución proceso del de plan identificación de Riesgos.

deProyecto Usuario Jefe de Análisis Cualitativo Líder de Riesgos

PFBM

Liderar el proceso de análisis.

Líder de Usuario

Identificar Riesgos actuales y Realizar el análisis Potenciales. cualitativo.

73

Planificación de

Jefe de Proyecto

PFBM

Dirigir la planificación de la ejecución de las respuestas.

PFBM PFBM

Dirigir Realizarla laimplementación aplicación de ylas mediciones.

Respuesta a los Riesgos

Equipo de Proyecto

Jefe de Proyecto Monitoreo y Control de Riesgos Equipo de Proyecto PERIODICIDAD DE LA GESTIÓN DE RIESGOS Proceso

Momento de Ejecución

Planificación de Al inicio del Proyecto Gestión de Riesgos

Ejecutar lasamediciones respuestas los riesgos y analizar los identificados PFBM Entregable del WBS Periodicidad resultados de Ejecución Plan del proyecto Una Vez (plan de gestión de riesgos)

Identificación de Al inicio del Proyecto los riesgos En cada reunión del equipo del proyecto

Plan del proyecto (plan de gestión de riesgos)

Una Vez

Análisis Cualitativo de Riesgos

Plan del proyecto (plan

Una Vez

Al inicio del Proyecto En cada reunión del equipo del proyecto

Planificación de Al inicio del Proyecto

de gestión de riesgos) Plan del proyecto (plan de gestión de riesgos)

Respuesta a los En cada reunión del equipo del proyecto Riesgos Monitoreo y En cada fase del proyecto Plan del proyecto Control de (plan Riesgos de gestión de PFBM riesgos) FORMATOS DE LA GESTIÓN DE RIESGOS

Semanal

Semanal Una Vez

Semanal Semanal

Planificación de Gestión de los Riesgos Plan de Gestión de Riesgos Identificación de los Riesgos Análisis Cualitativo de Riesgos Planificación de respuesta de los Riesgos

Informe de resultados Identificación y Evaluación cualitativa de de prueba Riesgos Al inicio del Proyecto En cada reunión del equipo del proyecto Al inicio del Proyecto En cada reunión del equipo del proyecto

74

3.2.

Ingeniería del Proyecto

3.2.1. Modelamiento de requerimientos A. Requerimientos Funcionales REQF1: Permitir registrar productos agroindustriales exportables. REQF2: Permitir modificar datos existentes de empresas registradas. REQF3: Permitir eliminar productos que ya no están siendo exportados. REQF4: Permitir eliminar empresas exportadoras. REQF5:

Permitir

registrar,

modificar,

y eliminar

los

productos

agroindustriales exportables y empresas de nuestra región. REQF6: Permitir al administrador subir archivos sobre actividades de capacitación, provisión de información vía Web. REQF7: Permitir el registro de empresas de la Región vía Web. REQF8: Se debe asociar cada producto a aquellas empresas que lo producen o que están en capacidad de hacerlo. REQF9: Permitir que las empresas puedan enviar cualquier corrección a los datos existentes y proveer información adicional

sobre, por

ejemplo, producción anual, campañas, que pueda ser incluida en el sistema REQF10: Permitir consultar de que países provienen las personas que visiten el sistema web, para poder saber hacia qué mercado está llegando esta información. REQF11: Permitir Generar Reporte de las principales empresas exportadoras de la región. REQF12: Permitir Generar Reporte de los principales mercados Internacionales hacia donde se está exportando. REQF13: Permitir Generar Reporte de los principales productos que se

75

estén exportando. REQF14: Permitir que la información que se muestre esté en castellano e ingles. B. Requerimientos No Funcionales REQ1: Tolerancia a fallos. El sistema debe poder recuperarse ante fallos. REQ2: El sistema debe ser de fácil utilización, la información debe ser presentada de manera integrada, es decir, mediante una interface que permita al inversionista/comprador extranjero acceder a la información relevante de manera sencilla e intuitiva y en la menor cantidad de pasos posibles. REQ3: La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 días X 24 horas. REQ4: El sistema de información que se desea implementar debe ser lo suficientemente adaptable a cualquier navegador Web sobre el que se corra la aplicación. REQ5: El sistema debe presentar mensajes de error que sean de fácil comprensión. REQ6: Permitir exportar datos en presentación PDF bajo las especificaciones técnicas que los reportes y las salidas en archivo, indicadas en los requerimientos funcionales. 3.2.2. Diseño 3.3.

Soporte del proyecto

3.3.1. Planificación de la calidad

PLAN DE GESTIÓN DE LA CALIDAD POLÍTICA DE CALIDAD DEL PROYECTO:

ESPECIFICAR LA INTENCIÓN DE DIRECCIÓN QUE FORMALMENTE

TIENE EL EQUIPO DE PROYECTO CON RELACIÓN A LA CALIDAD DEL PROYECTO

.

76

El presente proyecto debe cumplir con los requisitos de calidad planteados por la DIRCETUR, es decir acabar dentro del tiempo y el presupuesto planificado, asimismo debe cumplir con los requisitos de calidad del Líder de Usuario. LÍNEA BASE DE CALIDAD DEL PROYECTO: PROYECTO

Factor de Calidad Relevante

Objetivo de Calidad

CPI>=0.95

Métrica a utilizar

Frecuencia y momento de medición

Frecuencia y momento de reporte





CPI= Cost Perfor mance  Index Acum.

Frecuencia: Cada

frase

finalizada.

Cada

fase finalizada. 

Reporte:

Al

Medición: El día

siguiente

de

que culmine la

mediación.

día la

última actividad

Performance del

Frecuencia:

de

cada fase.

Proyecto



Cada

SPI=Schedule mance

 fase

finalizada

Perfor SPI>=0.95

Frecuencia:



Index

Frecuencia:

Cada

fase finalizada. 

Reporte:

Al

Medición: El dia

siguiente

de

que culmine la

mediación.

día la

última

Acum.

actividad

de

cada fase. X=Grado de Satisfacción del Líder

X>=4

Usuario



Medición:

El 

Reporte:

Al de

Satisfa

momento

de

siguiente

cción

medición

se

mediación.

del

manejara

Líder

día la

internamente.

Usuari o PRODUCTO FACTOR DE CALIDAD RELEVANT E

OBJETIVO DE CALID AD

MÉTRICA A

FRECUENCIA Y

UTILIZA

MOMENTO DE

R

MEDICIÓN

FRECUENCIA Y MOMENTO DE REPORTE

77

X= Índice de  Conformidad con requerim

X= 0.8 Proyecto

CPI = Cost

Frecuencia Mensual.

Performance

Medición, miércoles en Medición, el primer día

Index

la mañana.

Frecuencia Mensual.

hábil del mes.

Acumulado. Performance del SPI >=

SPI =

Frecuencia

Frecuencia

Proyecto.

Schedule

Mensual.

Mensual.

Performance

Medición, miércoles en Medición, el primer día

0.95

Index

Satisfacción del Usuario

la mañana

Nivel de

Acumulado. Nivel de

De acuerdo con las

satisfacción

Satisfacción

Capacitaciones.

>= 4.0

medidos del 1

hábil del mes.

De acuerdo con el programa de capacitaciones se hará mensual.

al 5

91

CAPITULO IV: EJECUCION Y CONTROL DEL PROYECTO

92

4.1. Gestión del Proyecto 4.1.1. Ejecución A. Acta de aceptación de entregables a aprobar

ACTA DE ACEPTACIÓN DE FASE NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

SISTEMA WEB DE PRODUCTOS EXPORTABLES

SWPE

NOMBRE DEL CLIENTE O SPONSOR DIRCETUR Declaración de la Aceptación Formal Por la presente se deja constancia que el Proyecto Sistema Web de Productos Exportables de la Región Ica, damos constancia por la presente que el proyecto ha sido concluido exitosamente. Observaciones Adicionales El Proyecto Comprendia en la entrega de los siguientes entregables: 1.0 Inicio 1.1 1.2 1.3 1.4

Analisis Project Charter Indentificar a los interesados Reuniones

2.0 Planificación 2.1 Plan de Gestión del Proyecto 2.2 Desarrollo de Planes 3.0 Ejecución 3.1 Fase Inicial 3.2 Fase Elaboración 3.3 Construcción 3.4 Transición 4.0 Control y Seguimiento 4.1 Pruebas y Testeo 4.2 Ejecución de Pruebas 5.0 Cierre 5.1 Documento del Sistema 5.2 Capacitación Técnica

El proyecto fue iniciado el 10 de setiembre del 2012 y termino el 4 de marzo del 2013.

ACEPTADO POR NOMBRE DEL CLIENTE, SPONSOR U OTRO

DISTRIBUIDO Y ACEPTADO FECHA

NOMBRE DEL STAKEHOLDERS

FECHA

93

FUNCIONARIO

Carlos Jesus Murguia Moron

4/03/2013

Martha Moran Galindo

4/03/2013

Jorge Espinoza Miranda

4/03/2013

Empresas Exportadoras de La Región Ica

4/03/2013

B. Acta de reunión de Equipo

ACTA DE REUNIÓN DE COORDINACIÓN DEL PROYECTO Proyecto SISTEMA WEB DE PRODUCTOS EXPORTABLES Fecha y hora Lugar Objetivo

11/09/13 Oficina DirCetur

Convocada por

CM

Facilitador

CM

Revisar el estado de Avance del proyecto

1.1 PERSONA

ASISTENTES CARGO/ÁREA

EMPRESA

Pablo Fernando Bohorquez Murguia

Project Manager

Carlos Jesus Murguia Moron

Director de Comercio Exterior

Gobierno Regional Ica

Jorge Espinoza Miranda

Administrador

Gobierno Regional Ica

DOCUMENTACIÓN qué se debe leer previamente

responsable

Ninguna qué se debe presentar en la reunión

responsable

94

Informe de Performance

PF

Schedule Actualizado

PF

AGENDA Actividad

Responsable

Tiempo

Informar el estado del Proyecto

PF

10 min

Acordar las actividades a realizar

PF

10 min

CONCLUSIONES 01 El Project manager manifestó la renuncia de un miembro de su equipo. Para el dia 23 de septiembre de 2013, este miembro será reemplazado. 02 El Project manager asegura que se va a contratar un nuevo miembro para apoyar en la construcción del sistema web, esto es como consecuencia de haber definido nuevas funcionalidades que han sido validas.

C. Cronograma del Proyecto

95

CRONOGRAMA DEL PROYECTO

96

97

98

99

100

D. Hoja de Costos

Tipo de Recurso: Personal entregabl e

1.1ANALISIS

1.2 Project Charter

Actividad

nomb re del recur so

Unida Cantidad des

Tipo de Recurso: Materiales o Consumibles

costo unitario

costo total

nombre del recurso

unid a

cantidad

des

1.1.A01 Identificación de problemas o necesidades

BMPF

HR-H

2

15.00

15.00

Otros

1

1.1.A02 Delimitación del problema o descripción de la necesidad

BMPF

HR-H

2

10.00

10.00

Otros

1

1.1.A03 Revisión de Fuentes de información relacionadas

BMPF

HR-H

2

12.00

12.00

Impresión

5

costo total

nombre del recurso

unida Cantidad des

PC

1

Impresora

1

BMPF

HR-H

1

30.00

30.00

Otros

BMPF

HR-H

1

20.00

20.00

Impresión

5

Pc

1

Escritorio

1

Impresora

1

1.2.A01 Reunión con el Sponsor 1.2.A02 Elaboración de

costo unitario

Tipo de Recurso: Máquinas o No consumibles

costo unitario

101

costo total

Project Charter 1.3.A01 Clasificación de los StakeHolders

BMPF

HR-H

1

15.00

15.00

Escritorio

1

PC

1

1.3.A02 Lista StakeHolders

BMPF

HR-H

2

20.00

20.00

Escritorio

1

PC

1

1.4 Reuniones

1.4.A01 Realizar reunión de Coordinación

BMPF

HR-H

1

30.00

30.00

Otros

PC

1

2.1.1 Plan del Alc an ce

2.1.1.A01 Definición del alcance

BMPF

HR-H

1

35.00

35.00

Otros

PC

1

2.1.1.A02 Definir objetivos

BMPF

HR-H

1

15.00

15.00

Otros

PC

1

2.1.1.A03 WBS

BMPF

HR-H

2

25.00

25.00

Otros

PC

1

2.1.1.A04 Diccionario WBS

BMPF

HR-H

2

20.00

20.00

Otros

PC

1

1.3 Identificar a los interesados

BMPF

102

Tipo de Recurso: Personal entrega

activi

ble

dad

nombre del recurso

Tipo de Recurso: Materiales o Consumibles

unida

canti

des

dad

costo unitario

costo total

nombre del recurso

unida

canti

des

dad

costo unitario

Tipo de Recurso: Máquinas o No consumibles costo total

nombre del recurso

unida

canti

des

dad

2.1.2.A01 Definir Actividades

BMPF

HR-H

1

34.00

34.00

Otros

PC

1

00202.1.2.A02 Secuenciar Actividades

BMPF

HR-H

1

19.00

19.00

Otros

PC

1

2.1.2.A03 Estimar duración de Actividades

BMPF

HR-H

2

13.00

13.00

Otros

PC

1

2.2.1.A01 Estimaciones de Costo de las Actividades

BMPF

HR-H

2

24.00

24.00

Otros

PC

1

2.2.1 2.2.1.A02 Base de las Presupuest Estimaciones o

BMPF

HR-H

2

12.00

12.00

Otros

PC

1

2.2.2 Costeo del Proyecto

2.2.2.A01 Estimaciones de Recursos Necesarios

BMPF

HR-H

1

24.00

24.00

Otros

PC

1

2.2.3.A01 Identificación de los Riesgos

BMPF

HR-H

3

14.00

14.00

Otros

PC

1

2.2.3.A02 Análisis de Riesgos

BMPF

HR-H

2

30.00

30.00

Otros

PC

1

BMPF

HR-H

2

40.00

40.00

Impresión

5

PC

1

Escritorio

1

2.1.2 Plan de Gestión Schudle

2.2.3. Plan de Riesgos

2.2.3.A03 Acciones de Respuesta a los Riesgos

costo unitario

103

costo total

2.2.4. 2.2.4.A01 Plan Planificación de Calidad de Calidad

BMPF

HR-H

1

15.00

15.00

Tipo de Recurso: Personal entrega

Activi

ble

dad

nombr e del recurs o

unida

canti

des

dad

BMPF

HR-H

BMPF

3.1.23.1.2.A01 Recopilar Requerimiento Requerimientos s de los usuarios

Otros

PC

Tipo de Recurso: Materiales o Consumibles

Tipo de Recurso: Máquinas o No consumibles

unida

canti

des

dad

des

dad

nombre del recurso

2

23.00

23.00

Otros

PC

1

HR-H

2

21.00

21.00

Otros

PC

1

BMPF

HR-H

2

32.00

32.00

Otros

PC

1

3.1.2.A02 Listar los requerimientos

BMPF

HR-H

1

36.00

36.00

Otros

PC

1

3.1.2.A03 Documentar requerimientos aprobados

BMPF

HR-H

1

36.00

36.00

Otros

PC

1

3.1.3 3.1.3.A01 Recopilar Requerimiento requerimientos s funcionales funcionales del sistema

BMPF

HR-H

4

14.00

14.00

Otros

PC

1

3.1.3.A02 Listar Requerimientos funcionales

BMPF

HR-H

2

14.00

14.00

Otros

PC

1

3.1.1.A02 Preparar el entorno del proyecto

nombre del recurso

canti

costo total

3.1.1.A0 1 Establecer ámbitos del software

costo total

unida

costo unitario

3.1.1Formular Ámbito del Proyecto

costo unitario

1

costo unitario

104

costo total

3.1.3.A03 Documentar requerimientos funcionales aprobados

BMPF

HR-H

2

14.00

14.00

Otros

PC

1

3.1.4 3.1.4.A01 Recopilar Requerimiento Requerimientos s no funcionales funcionales del sistema 3.1.4.A02 Listar los requerimientos

BMPF

HR-H

1

13.00

13.00

Otros

PC

1

BMPF

HR-H

2

13.00

13.00

Otros

PC

1

3.1.4.A03 Documentar requerimientos aprobados

BMPF

HR-H

2

13.00

13.00

Otros

PC

1

3.2.1.1 3.2.1.1.A01 Describir los Especificación casos de uso de casos de uso

BMPF

HR-H

1

18.00

13.00

Otros

PC

1

BMPF

HR-H

1

18.00

Otros

PC

1

Tipo de Recurso: Materiales o Consumibles

Tipo de Recurso: Máquinas o No consumibles nombre del recurso

3.2.1.1.A02 Describir el flujo de eventos

Tipo de Recurso: Personal entrega ble

activi dad

3.2.1.2 3.2.1.2.A01 Diagrama de Identificar los casos de uso actores del sistema 3.2.1.2.A02 Identificar los

nombr e del recurs o

costo unitario

costo total

nombre del recurso

2

12.00

12.00

otros

PC

1

1

11.00

11.00

Otros

PC

1

unida

canti

des

dad

BMPF

HR-H

BMPF

HR-H

unida

canti

des

dad

costo unitario

costo total

unida

canti

des

dad

costo unitario

105

costo total

casos de uso y los procesos 3.2.1.2.A03 Desarrollar el diagrama de casos de uso

BMPF

HR-H

2

33.00

33.00

Impresión

5

PC

1

Escritorio

1

Impresora

1

BMPF

HR-H

2

17.00

17.00

Otros

PC

1

3.2.2.A02 Identificar las relaciones

BMPF

HR-H

1

13.00

13.00

otros

PC

1

3.2.2.A03 Diagramar las clases

BMPF

HR-H

2

25.00

25.00

Impresión

5

PC

1

Escritorio

1

Impresora

1

3.2.3 3.2.3.A01 Diagrama de Identificar los Estados objetivos

BMPF

HR-H

1

16.00

16.00

Otros

PC

1

3.2.3.A02 Identificar las Acciones

BMPF

HR-H

1

12.00

12.00

otros

PC

1

BMPF

HR-H

2

35.00

35.00

Escritorio

1

PC

1

Impresión

5

Impresora

1

3.2.2 3.2.2.A01 Diagrama de Definir los Clases Objetivos, métodos y atributos

3.2.3.A03 Elaborar el diagrama

.4 Diagrama de Secuencia

3.2.4.A01 Identificar los objetos

BMPF

HR-H

2

14.00

14.00

Impresión

5

PC

1

3.2.4.A02 Identificar la secuencialidad

BMPF

HR-H

1

23.00

23.00

Impresión

8

PC

1

3.2.4.A3 Elaborar el

BMPF

HR-H

2

32.00

32.00

Impresión

5

PC

1

106

Escritorio

Diagrama

Tipo de Recurso: Personal entrega

Activi

ble

dad

unida

canti

des

dad

BMPF

HR-H

3.2.5.A02 Secuenciar los objetos

BMPF

3.2.5.A03 Elaborar el Diagrama

BMPF

3.2.5 3.2.5.A01 Identificar Diagrama de los objetos Colaboración

3.3.1 Diagrama EntidadRelación

Tipo de Recurso: Materiales o Consumibles

unida

canti

des

dad

costo unitario

Tipo de Recurso: Máquinas o No consumibles

costo total

nombre del recurso

unida

canti

des

dad

costo unitario

costo total

nombre del recurso

1

8.00

8.00

Impresión

4

PC

1

HR-H

2

7.00

7.00

Impresión

8

PC

1

HR-H

1

13.00

13.00

Impresión

5

PC

1

Escritorio

1

3.3.1.A01 Identificar las entidades

BMPF

HR-H

2

15.00

15.00

Impresión

4

PC

1

3.3.1.A02 Identificar atributos

BMPF

HR-H

1

16.00

16.0

Impresión

5

PC

1

3.3.1.A03 Identificar las relaciones

BMPF

HR-H

2

11.00

11.00

Impresión

6

PC

1

BMPF

HR-H

1

23.00

23.00

Impresión

5

PC

1

Escritorio

1 PC

1

PC

1

3.3.1.A04 Elaborar Diagrama

3.3.1 Modelo Físico

nom bre del recu rso

1

3.3.2.A01 Analizar Diagrama EntidadRelación

BMPF

HR-H

2

45.00

45.00

3.3.2.A02 Elaborar el Diagrama del Modelo

BMPF

HR-H

1

30.00

30.00

Impresión

5

Escritorio

1

costo unitario

107

costo total

de Datos 3.3.3 Definir estándares de Codificación

3.3.3.A01 Detallar las líneas de Código

BMPF

HR-H

2

70.00

70.00

Escritorio

1

PC

2

3.3.4 plementación de la se de Datos

3.3.4.A01 Elaborar la implementación de la Base de datos

BMPF

HR-H

1

60.00

60.00

Escritorio

1

PC

2

3.3.5.A01 Analizar el modelo de datos

BMPF

HR-H

2

30.00

30.00

PC

1

3.3.5.A02 Elaborar el diccionario de datos

BMPF

HR-H

1

22.00

22.00

PC

2

3.3.5 Diccionario de Datos

Tipo de Recurso: Personal Entrega

Activi

Ble

dad

nomb re del recur so

unida

canti

des

dad

Impresión

4

Escritorio

1

Tipo de Recurso: Materiales o Consumibles

costo unitario

costo total

nombre del recurso

unida

canti

des

dad

costo unitario

Tipo de Recurso: Máquinas o No consumibles

costo total

nombre del recurso

unida

canti

des

dad

3.4.1 3.4.1 A01 Diseñar el prototipo Prototipos de de la interfaz interface de usuarios 3.4.1 A02 Diseñar el prototipo de la interfaz unificado.

BMPF

HR-H

1

13.00

13.00

BMPF

HR-H

2

15.00

15.00

CD

1

PC

2

4.1.1 Plan de Pruebas

4.1.1.A01 Definir unidades del sistema a testear

BMPF

HR-H

1

30.00

30.00

Impresión

4

PC

2

Escritorio

1

Impresora

1

4.1.1.A02 Diseñar pruebas

BMPF

Impresión

4

PC

2

Escritorio

1

Impresora

1

HR-H

2

60.00

60.00

costo unitario

108

costo total

4.1.1.A03 Elaborar el plan de pruebas

4.2.1 4.2.1.A01 Ejecutar pruebas Realización de Prueba

5.1.1 Manual del Sistema

5.1.2 Manual del Usuario

5.1.3 Ayuda del Sistema

BMPF

HR-H

HR-H

3

2

25.00

34.00

25.00

34.00

Escritorio

1

CD

1

Hojas

10

Escritorio

1

Impresión

3 1

BMPF

HR-H

2

25.00

25.00

Escritorio

4.2.2.A01 Identificar observaciones

BMPF

HR-H

3

12.00

12.00

Impresión

4.2.2.A02 Desarrollar informe de pruebas

BMPF

HR-H

2

32.00

32.00

CD

1

Impresión

10

Escritorio

1

4.2.1.A02 Corregir Observaciones 4.2.2 Informe de Prueba

BMPF

5.1.1.A01 Estudiar el sistema por proceso y modulo

BMPF

HR-H

3

19.00

19.00

5.1.1.A02 Elaborar el manual de sistema

BMPF

HR-H

3

34.00

34.00

5.1.2.A01 Estudiar el producto

BMPF

HR-H

3

12.00

12.00

5.1.2.A02 Elaborar el manual del usuario

BMPF

HR-H

3

32.00

32.00

5.1.3.A01 Identificar posibles preguntas y soluciones

BMPF

5.1.3.A02 Elaborar el manual de ayuda del

BMPF

HR-H HR-H

3

3

21.00

38.00

21.00

38.00

PC

2

PC

1

PC

1

PC

Impresión

40

Escritorio

1

CD

1

PC

1

PC

1

PC

1

PC

1

Impresión

40

PC

1

Escritorio

1

Impresora

1

CD

1

Impresión

4

PC

1

Impresora

11

PC

1

CD

2

109

sistema

Tipo de Recurso: Personal entrega ble

Activi dad

5.2.1.A01 Elaborar el plan de capacitación

5.2.1 Plan de Capacitaci 5.2.1.A02 Realizar las ón coordinaciones finales

5.2.2 Informe de Capacitaci ón

nombr e del recurso

unida

canti

des

dad

BMPF

HR-H

BMPF

HR-H

5.2.2.A01 Desarrollar informe de primera capacitación

BMPF

5.2.2.A02 Desarrollar informe de segunda

BMPF

HR-H

HR-H

Tipo de Recurso: Materiales o Consumibles

Tipo de Recurso: Máquinas o No consumibles nombre del recurso

costo unitario

costo total

nombre del recurso

3

30.00

30.00

Impresión

10

PC

1

4

15.00

15.00

Impresión

10

PC

1

Escritorio

1

Impresión

10

PC

2

Escritorio

1

Impresión

10

PC

2

Escritorio

1

Impresión Es cri to rio

10

PC

2

1

1

20.00

20.00

20.00

20.00

unida

canti

des

dad

costo unitario

costo total

unida

canti

des

dad

costo unitario

Capacitación 5.2.2.A03 Desarrollar informe de tercera capacitación

BMPF

HR-H

1

20.00

20.00

1

110

costo total

4.1.2. Seguimiento y Control A. Matriz de Trazabilidad de requerimientos

TRAZABILIDAD HACIA: CÓDIGO

DESCRIPCIÓN

SUSTENTO DE SU INCLUSIÓN

PROPIETARIO

ESTADO ACTUAL (AC, CA, DI, PRIORIDAD VERSIÓN AD, AP)

RE01 El sistema debe Solicitado permitir registrar por: productos que se estén exportando en la Dirección región. de Comercio Exterior

Dirección de Comercio Exterior

RE02 El sistema debe permitir modificar datos existentes de empresas registradas.

Dirección de Comercio Exterior

Muy Alta

Dirección de Comercio Exterior

Muy Alta

RE03 El sistema debe permitir eliminar productos que ya no están siendo exportados.

Solicitado por: Dirección de Comercio Solicitado Exterior por: Dirección de Comercio Exterior

NIVEL DE ESTABILIDAD (A, FECHA DE M, B) CUMPLIMIENTO

GRADO DE COMPLEJI DAD (A, M, B)

Muy Alta 1.0

AC

A

A

1.0

AC

A

A

1.0

AC

A

A

CRITERIO DE ACEPTACIÓN

NECESIDADES, OPORTUNIDADE S, METAS Y OBJETIVOS DEL NEGOCIO

OBJETIVOS DEL PROYECTO

ALCANCE DEL PROYECTO /ENTREGABLE DEL WBS

(2.1)

DISEÑO DEL PRODUCTO

DESARROLLO DEL PRODUCTO

ESTRATEGIA DE PRUEBA

ESCENAR IO DE PRUE BA

REQUERIMIENTO DE ALTO NIVEL

Ofrecer al usuario una facilidad al momento de Aprobación utilizar la del Project aplicación. Charter

Cumplir con el Alcance del proyecto

Se ha Es una No Aplica No considera herramient Aplica do todo a para Plan de Cumplir con Gestión referido al facilitar la todo lo Project demanda del requerido. Proyecto Charter externa y la oferta exportable local.

Aprobación Ofrecer un del Plan del buen servicio Proyecto al inversionista extranjero

Cumplir Todo el con el Proyecto Alcance del proyecto

No Aplica No Cumplir con el Aplica Plan del Proyecto

Aprobación Ofrecer un del Plan del buen servicio Proyecto al inversionista extranjero

Cumplir Todo el con el Proyecto Alcance del proyecto

No Aplica No Cumplir con el Aplica Plan del Proyecto

111

RE04 El sistema debe permitir eliminar empresas ya registradas.

RE05 El sistema debe permitir el registro de empresas Vía Web RE06 Permitir modificar y eliminar los productos exportables

RE07 Permitir al administrador subir archivos sobre actividades de capacitación, provisión de información vía Web.

RE08 Permitir consultar de qué países provienen las personas que visiten el sistema web, para poder saber hacia qué mercado está llegando esta información.

Solicitado por: Dirección de Comercio Exterior

Solicitado por: Dirección de Solicitado Comercio por: Exterior Dirección de Comercio Solicitado Exterior por: Dirección de Comercio Exterior

Solicitado por: Dirección de Comercio Exterior

Dirección Alto de Comercio Exterior

Aprobación Ofrecer un del Plan del buen servicio al Proyecto inversionista extranjero 1.0

AC

A

Dirección de Comercio Muy Exterior Alta

Cumplir con el No Aplica No Aplica Plan del Proyecto

Cumplir Todo el con el Proyecto Alcance del proyecto Cumplir Todo el del Plan del buen servicio con el Proyecto Proyecto al Alcance inversionista del extranjero proyecto

No Aplica No Cumplir con el Aplica Plan del Proyecto

Aprobación Ofrecer un del Plan del buen servicio Proyecto al inversionista extranjero

Cumplir Todo el con el Proyecto Alcance del proyecto

No Aplica No Cumplir con el Aplica Plan del Proyecto

Aprobación Ofrecer un del Plan del buen servicio Proyecto al inversionista extranjero

Cumplir Todo el con el Proyecto Alcance del proyecto

No Aplica No Cumplir con el Aplica Plan del Proyecto

A

Dirección Alto de Comercio Exterior Dirección Alto de Comercio Exterior

Cumplir Todo el con el Proyecto Alcance del proyecto

Aprobación Ofrecer un del Plan del buen servicio Proyecto al inversionista Aprobación extranjero Ofrecer un 1.0

AC

A

A

1.0

AC

A

A

1.0

AC

A

A

Dirección de Comercio Exterior Alto 1.0

AC

A

No Aplica No Cumplir con el Aplica Plan del Proyecto

M

112

RE09 Permitir Generar Reporte de las principales empresas exportadoras de la región.

Solicitado por: Dirección de Comercio Exterior

RE010 Permitir Generar Reporte de los principales mercados Internacionales hacia donde se está exportando.

Solicitado por:

RE011 Permitir Generar Reporte de los principales productos que se estén exportando.

Solicitado por:

RE012 El Proyecto debe ser rentable y ejecutarse en el tiempo previsto

Solicitado por:

Alto

Dirección de Comercio Alto El Sponsor Exterior

Dirección de Comercio Exterior

1.0

1.0

AC

AC

A

Aprobación Ofrecer un del Plan del buen servicio Proyecto al inversionista extranjero

Cumplir con el alcance del proyecto

Aprobación Ofrecer un del Project buen servicio Charter al inversionista extranjero

Cumplir Todo el con el Proyecto Alcance del Proyecto

A

A

M

Satisfacer al inversionista extranjero

Dirección de Comercio Exterior Muy Alta Muy

1.0

AC

A

A

1.0

AC

A

A

Alta

Aprobación del informe Aprobación Final del Project Charter

Sponsor Solicitado por:

RE013 El diseño debe contemplar el uso optimo de recursos tales como conexiones Dirección a la base de datos con de un tiempo de respuesta Comercio de 10 segundos en Exterior promedio RE014 Debe contemplar Solicitado requerimientos de confiabilidad

Dirección de Comercio Exterior

por: Dirección de Comercio Exterior

Alta

1.0

AC

A

M

Aprobación del Project Charter

Alta

1.0

AC

A

A

Aprobación del Project Charter

(3.1.1.2) Se ha Mostrara un Verificació No Cumplir con considera interface n del aplica todo lo alcance requerido. Gestión do todo didáctica referido al básicament de los e de Requerimi Project Charter. organizació entos n de información

Cumplir con el alcance del proyecto

Cumplir con el Alcance del Cumplir Proyecto con el Alcance del Proyecto

No aplica No Cumplir con aplica todo lo requerido

Se ha Se ha Informe Audito Cumplir con los considera considerado de rio acuerdos con la do todo todo Capacitaci empresa. referido al referido al ón Project Project Charter. Charter. Todo el Proyecto

No aplica

Cumplir con todo lo requerido.

Todo el Proyecto

Cumplir con todo lo requerido.

Cumplir Todo el con el Proyecto Alcance del Proyecto

Cumplir con todo lo requerido.

113

RE015 Tolerancia a fallos. El Solicitado sistema debe poder por: recuperarse ante fallos. Dirección de Comercio RE016 El sistema debe ser de Solicitado Exterior fácil utilización por: Dirección de Comercio Solicitado Exterior por:

RE017 La disponibilidad del sistema debe ser continua con un nivel de servicio para los Dirección usuarios de 7 días X 24 de horas. Comercio Exterior RE018 El sistema de Solicitado información que se desea implementar debe ser lo suficientemente adaptable a cualquier navegador Web sobre el que se corra la aplicación. RE019 Permitir exportar datos

Alta

1.0

AC

A

A

Aprobación del Project Charter

Cumplir Todo el con el Proyecto Alcance del Proyecto

Cumplir con todo lo requerido.

Alta

1.0

AC

A

M

No aplica

Cumplir Todo el con el Proyecto Alcance del Proyecto

Cumplir con todo lo requerido.

Muy Alta

1.0

AC

A

M

No aplica

Cumplir Todo el con el Proyecto Alcance del Proyecto

Cumplir con todo lo requerido.

Alta

1.0

AC

A

M

No aplica

Cumplir Todo el con el Proyecto Alcance del Proyecto

Cumplir con todo lo requerido.

Alta

1.0

AC

A

A

Aprobacion Satisfacción del Project del usuario Charter

Cumplir con el Alcance del Proyecto

por: Dirección de Comercio Exterior

Solicitado a herramientas suite de por: oficina (PDF) archivos planos, txt, bajo las Dirección especificaciones de técnicas que los Comercio reportes y las salidas Exterior en archivo, indicadas en los requerimientos

Plan de gestión de Proyectos s

Document o de especifica ciones

Elaborar pruebas

Ambie Cumplir con nte de todo lo prueba requerido. unitarias y s de propor Integració cionad o por n. la DirCet ur

114

B. Estructura de descomposición del trabajo WBS

DICCIONARIO WBS (simplificado) NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Sistema Web de Productos Exporable

SWPE

ESPECIFICACIÓN DE PAQUETES DE TRABAJO DEL WBS DEFINIR EL OBJETIVO DEL PDT, DESCRIPCIÓN DEL PDT, DESCRIPCIÓN DEL TRABAJO Y ASIGNACIÓN DE RESPONSABILIDADES.

El punto de partida de un proyecto es la existencia de un problema o necesidad real 1.1.1

Identificación de problemas o necesidades

que se quiere resolver o cubrir. Por ello, el primer paso para la elaboración de un proyecto

será

la

identificación

de

ese

problema o necesidad. 1.1 Análisis

Se trata de definir el problema que da origen

1.1.2 Descripción del problema

al proyecto o la necesidad a la que va a dar respuesta de forma clara y concreta.

FASE 1: Inicio

1.1.3

Revisión de Fuentes de Información

Al tiempo que se ha definido el problema, se habrán

planteado

ya

algunas

posibles

soluciones y formas de abordarlo

Documento que detalla: la definición del proyecto, definición del producto, requerimiento de los stakeholders, necesidades del 1.2 Project Charter

negocio, finalidad justificación del proyecto, cronograma de hitos, organizaciones que intervienen, supuestos, restricciones, riesgos, y oportunidades del proyecto.

1.3 Identificar a Se clasifican a todas las personas u organizaciones que reciban los interesados el impacto del proyecto. Reunión Semanal del equipo de proyecto, en las oficinas de la 1.4 Reuniones DIRCETUR, para informar el avance del proyecto, y presentar los informes de la semana.

115

En este Documento se detallara la definición 2.1.1 2.1 Plan de Gestión del Proyecto 2.1.2

Plan del del Alcance, sus objetivos general y Alcance específicos, WBS, Diccionario WBS En

este

documento

se

definirá

las

Plan de actividades, secuenciamiento de actividades, Gestión las estimaciones de recursos y duración de Schedule las actividades.

FASE 2: Planificación

Este documento consiste en sumar los costos 2.2.1 Presupuesto

estimados de las Actividades para establecer una línea base de costos autorizados. Documento el cual se redactan los recursos

2.2.2 2.2 Desarrollo de Planes

Costeo del que se necesitaran en la elaboración del Proyecto proyecto. Documento el cual se identifican los requisitos de calidad y/o normas para el proyecto y el

2.2.3

Plan Calidad

de producto, y se documenta la manera en que el proyecto demostrará el cumplimiento con los mismos. En

este

Documento

se

recopilara

los

Fase 3: Ejecución

3.1.1 Requerimientos requerimientos de los interesados y se de los elaborara un listado de los requisitos Usuarios indispensables. 3.1 Gestión de los 3.1.2 Requeri mientos

Requerimientos En este Documento se enumera aquellos funcionales requerimientos funcionales para su desarrollo. del sistema

3.1.3 Requerimientos Reunir todos los requisitos del sistema y No elaborar un Documento para los funcionales requerimientos que ya fueron entregados del sistema

116

Identificamos los requerimientos y casos de 3.2.1 Modelamiento uso del Sistema luego se elabora una de Casos de descripción de los casos de uso, describir lo Uso

del que el sistema debe hacer, reconocer los

sistema

roles del sistema y graficar las relaciones que existen entre los autores.

3.2.2

Diagrama

de

Clases

definir

los

atributos

luego

establecemos

relaciones.

3.2 Modelo del Sistema 3.2.3

Identificar las clases del sistema, así como

Diagrama

de

Secuencia

Identificar los objetos del sistema y desarrollar la

secuencia

entre

los

objetos

ya

identificados.

3.2.4

Diagrama

de

Colaboración

Identificar una combinación de información entre los diagramas de clases, secuencia y casos de uso.

3.2.5.

Diagrama

de

Estados

Indicar que eventos hacen que se pase de un estado a otro. Visualizar los objetos que pertenecen a la

3.3.1.Diagrama EntidadRelación

base de datos, describir las dependencias entre entidades.

3.3.2. Diagrama 3.3 Modelo de modelo Datos Datos

del de

3.3.3.

de

Realizar diagrama de clases y de entidadrelación. Detectar los grupos de variables altamente

Diccionario datos

relacionados entre si, documentar y describir toda la información a mayor detalle

3.4 Prototipos de Este paquete comprende en recopilar información específica Interface acerca de los requerimientos de información de los usuarios. de Usuarios

117

Control y Seguimiento

FASE 4:

4.1 Plan de Pruebas

4.1.1 Definir

Se definen los métodos que se usaran para el

Unidades

testeo del sistema.

4.1.2

Desarrollar las pruebas necesarias para el

Diseñar pruebas plan. 4.1.3 Elaborar Plan de Pruebas 4.2.1.1

Desarrollar el plan de pruebas del sistema.

Se genera y ejecuta las pruebas necesarias.

Prueba de Interface grafica 4.2.1Realización de usuarios de Prueba

4.2.1.2 Ejecutar Pruebas 4.2.2 Informe de Prueba

Se realizara las observaciones del informe.

Se obtienen las observaciones del informe y Se realizara el documento donde se detallara el informe de pruebas. 5.1.1 Manual del Este paquete comprende todos los procesos y Sistema divisiones del sistema y así poder desarrollar

Cierre

FASE 5:

5.1 Documen tación 5.1.2 Manual del del Usuario Sistema

5.2 Capacitación Técnica

el manual. Analizar

detalles

y

características

del

producto y así poder desarrollar el manual

5.1.3 Ayuda del Sistema

Definir alternativas de preguntas y respuestas

5.2.1

Desarrollar y Redactar plan de capacitación y

Plan de Capacitac ión

5.2.2 Informe de Capacitac ión

de ayuda.

establecer los puntos finales a desarrollar Desarrollar

una

serie

de

informes

con

observaciones de progreso de los usuarios.

118

DICCIONARIO WBS (completo) NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Sistema Web de Productos Exportables CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

SWPE

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

1.1.

Análisis

OBJETIVO DEL PAQUETE DE TRABAJO:

Analizar el negocio

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Analizar por completo la empresa e identificar las necesidades y redactar el problema encontrado en la empresa.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

Actividades a realizar: - Identificación de problemas o necesidades

CÓMO SE VA A ELABORAR EL PDT.

- Delimitación del problema o descripción de la necesidad - Revisión de Fuentes de información relacionadas Responsable: Bohórquez Murguía Pablo Fernando Participa: Apoya: ASIGNACIÓN DE RESPONSABILIDADES:

Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Interesados del Proyecto Hitos importantes:

FECHAS PROGRAMADAS:

Stakeholder que acepta:

CUÁNDO SE VA A ELABORAR EL PDT.

Requisitos que deben cumplirse: Forma en que se aceptará:

CRITERIOS DE ACEPTACIÓN:

El director del proyecto deberá identificar las

QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

necesidades del negocio Requisitos que deben cumplirse: Que la Organización no nos brinde información

Personal: Sponsor

119

SUPUESTOS: SITUACIONES QUE SE El

Sponsor brindara la información necesaria para elaborar el entregable

TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA

EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA Que

el entregable no sea aprobado

IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y COSTOS: QUÉ RECURSOS SE NECESITAN PARA ELABORAR EL PDT, DE QUE TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE

Materiales o Consumibles: Impresión Equipos y Maquinas: PC

Y

SUBSECUENTE TIENE EL PDT.

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

1.1.2

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

PROJECT CHARTER

OBJETIVO DEL PAQUETE DE TRABAJO:

Iniciar el proyecto

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

Documento que detalla: la definición del proyecto, definición del producto, requerimiento de los stakeholders, necesidades del negocio, finalidad y justificación del proyecto, cronograma de hitos, organizaciones que intervienen, supuestos, restricciones, riesgos, y oportunidades del proyecto.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): Actividades a realizar: CÓMO SE VA A ELABORAR EL PDT.

- Reunión con el Sponsor. - Elaborar el Project Charter. - Revisar el Project Charter.

Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADESParticipa: : QUIÉNES INTERVIENEN, Y QUE ROL DESEMPEÑAN EN LA ELABORACIÓN.

Apoya: Revisa:Ing. Peña Casas Erwin Pablo Aprueba: Sponsor

120

Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓN: Stakeholder que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Requisitos que deben cumplirse: El equipo del proyecto debe recibir una copia en versión digital del Project Charter Forma en que se aceptará: Reunión de equipo del proyecto

SUPUESTOS: SITUACIONES QUE SE El Sponsor brindará la información necesaria para elaborar el Project TOMAN COMO VERDADERAS, Charter. REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA Que el Project Charter no sea aprobado. IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y COSTOS Personal: : Sponsor QUÉ RECURSOS SE NECESITAN Materiales o Consumibles: PARA ELABORAR EL PDT, DE QUE TIPO, EN QUE CANTIDADES, Equipos o Máquinas: Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes Y del pdt: Análisis SUBSECUENTE TIENE EL PDT.

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

1.1.3

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Identificar a los interesados

OBJETIVO DEL PAQUETE DE TRABAJO:

Clasificar y listar los interesados

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

Documento que detalla: la definición del proyecto, definición del producto, requerimiento de los stakeholders, necesidades del negocio, finalidad y justificación del proyecto, cronograma de hitos, organizaciones que intervienen, supuestos, restricciones, riesgos, y oportunidades del proyecto.

121

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): CÓMO SE VA A ELABORAR EL PDT.

Actividades a realizar: - Reunión con el Sponsor. - Elaborar el Project Charter. - Revisar el Project Charter.

Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADES : Participa: QUIÉNES INTERVIENEN, Y QUE ROL Apoya: DESEMPEÑAN EN LA ELABORACIÓN.

Revisa:Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Requisitos que deben cumplirse: El equipo del proyecto debe recibir una copia en versión digital del Project Charter Forma en que se aceptará: Reunión de equipo del proyecto

SUPUESTOS: SITUACIONES QUE ElSE Sponsor brindará la información necesaria para elaborar el TOMAN COMO VERDADERAS, Project Charter. REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

RIESGOS: EVENTOS CUYA

PDT.

Que el Project Charter no sea aprobado.

OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas:

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes del pdt: Project Charter Y SUBSECUENTE TIENE EL PDT.

122

NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Sistema Web Exportables

de

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

1.1.4

SWPE Productos

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Reuniones

OBJETIVO DEL PAQUETE DE TRABAJO:

Coordinar Semanalmente las actividades del proyecto

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

Reunión de Coordinación Semanal, del equipo de proyecto, en las oficinas de la DIRCETUR, para informar el avance del proyecto, y presentar los informes de la semana.

DESCRIPCIÓN DEL TRABAJO A Actividades a realizar: REALIZAR - Realizar reunión de coordinación del proyecto. (ACTIVIDADES): CÓMO SE VA A ELABORAR EL PDT. Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADES : Participa: QUIÉNES INTERVIENEN, Y QUE ROL Apoya: DESEMPEÑAN EN LA ELABORACIÓN.

Revisa:Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Requisitos que deben cumplirse: Documentar la reunión de coordinación, a través de un Acta de Reunión. Forma en que se aceptará: Reunión de equipo del proyecto

SUPUESTOS: SITUACIONES QUE ElSE Sponsor brindará la información necesaria para elaborar el TOMAN COMO VERDADERAS, Project Charter. REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD,

123

DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: Escritorio SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas: PC

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes del pdt: Identificar a los interesados Y SUBSECUENTE TIENE EL PDT.

NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Sistema Web Exportables

de

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

2.1.1

SWPE Productos

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Plan del Alcance

OBJETIVO DEL PAQUETE DE TRABAJO:

Describir y Planificar el proyecto

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Documento donde se detalla la definición del alcance, definición de objetivos, WBS, Diccionario WBS

QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR Actividades a realizar: (ACTIVIDADES): - Elaborar Definicion del Alcance CÓMO SE VA A ELABORAR EL PDT.

- Definir objetivos - Elaborar WBS -Elaborar Diccionario WBS. Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADES : Participa: QUIÉNES INTERVIENEN, Y QUE ROL Apoya: DESEMPEÑAN EN LA ELABORACIÓN.

Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

124

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y Requisitos que deben cumplirse: El plan debe ser factible y ACEPTADO EL PDT. deseable

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE ElSE Project charter han sido aprobados. TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA

La no identificación de los entregables necesarios para elaborar el plan del proyecto.

OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: Escritorio SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas: PC

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes del pdt:Project Charter Y SUBSECUENTE TIENE EL PDT.

Despues del pdt: Plan de Gestión Schudle

NOMBRE DEL PROYECTO Sistema Web Exportables CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

SIGLAS DEL PROYECTO de

SWPE Productos

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

2.2.

Desarrollo de Planes

OBJETIVO DEL PAQUETE DE TRABAJO:

Planificar proyecto

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Documento donde se detalla el presupuesto del proyecto, el costeo y el plan de calidad.

QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

125

DESCRIPCIÓN DEL TRABAJO A REALIZAR Actividades a realizar: (ACTIVIDADES): -Presupuesto CÓMO SE VA A ELABORAR EL PDT.

-Costeo del Proyecto - Plan de calidad

Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADES : Participa: QUIÉNES INTERVIENEN, Y QUE ROL Apoya: DESEMPEÑAN EN LA ELABORACIÓN.

Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y Requisitos que deben cumplirse: El plan debe ser factible y ACEPTADO EL PDT. deseable

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE ElSE Project charter ha sido aprobados. TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

RIESGOS: EVENTOS CUYA

PDT.

La no identificación de los entregables necesarios para elaborar el plan del proyecto.

OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: Escritorio SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas: PC

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Y SUBSECUENTE TIENE EL PDT.

Antes del pdt: Plan de Gestión Schedule Después del pdt: Fase inicial

126

NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Sistema Web Exportables

de

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

3.1.1

Productos

SWPE

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Fase Inicial

OBJETIVO DEL PAQUETE DE TRABAJO:

Analizar y describir los requerimientos del usuario y del sistema.

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Documento donde se detalla el ámbito del proyecto y los requerimientos de los usuarios y del sistema.

QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR Actividades a realizar: (ACTIVIDADES): - Formular Ámbito del Proyecto. CÓMO SE VA A ELABORAR EL PDT.

-Requerimientos de los usuarios. -Requerimientos funcionales del Sistema. -Requerimientos no funcionales del Sistema.

Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADES : Participa: QUIÉNES INTERVIENEN, Y QUE ROL Apoya: DESEMPEÑAN EN LA ELABORACIÓN.

Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y Requisitos que deben cumplirse: Esta fase debe redactarse de ACEPTADO EL PDT. forma objetiva y clara.

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE SE TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

127

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: Escritorio SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas: PC

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes del pdt: Desarrollo de Planes Y SUBSECUENTE TIENE EL PDT.

Despues del pdt: Fase Elaboracion

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

3.1.2

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Fase Elaboración

OBJETIVO DEL PAQUETE DE TRABAJO:

Describe el modelado del proyecto

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

Documento que detalla el Modelamiento de Casos de Uso, Diagrama de Clases, Diagrama de Colaboración, Diagrama de Secuencia, Diagrama de Estado

DESCRIPCIÓN DEL TRABAJO A REALIZAR Actividades a realizar: (ACTIVIDADES): - Elaborar Diagrama de Casos de Uso del Sistema CÓMO SE VA A ELABORAR EL PDT.

- Elaborar Diagrama de Clases - Elaborar Diagrama de Colaboración - Elaborar Diagrama de Secuencia - Elaborar Diagrama de Estado Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE RESPONSABILIDADES : Participa: QUIÉNES INTERVIENEN, Y QUE ROL Apoya: DESEMPEÑAN EN LA ELABORACIÓN.

Revisa:Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

128

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y Requisitos que deben ACEPTADO EL PDT. comprensible.

cumplirse:

El

contenido

debe

ser

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE LaSEfase de Inicio debe de ser aprobada TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: Escritorio SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas: PC

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes del pdt: Fase de Inicio Y SUBSECUENTE TIENE EL PDT.

Después del pdt: Fase de Construcción

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

3.1.3

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Fase Construcción

OBJETIVO DEL PAQUETE DE TRABAJO:

Definir estándares de codificación

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Documento que detalla los estándares de Codificación e implementación de la base de Datos al sistema.

QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR Actividades a realizar: (ACTIVIDADES): Elaborar el modelo físico CÓMO SE VA A ELABORAR EL PDT. Elaborar Diagrama Entidad-Relacion. Definir Estandares de Codificacion Implementacion de la Base de Datos Diccionario de Datos Responsable: Bohórquez Murguía Pablo Fernando ASIGNACIÓN DE

129

Participa: RESPONSABILIDADES : Apoya: QUIÉNES INTERVIENEN, Y QUE ROL DESEMPEÑAN EN LA

Revisa: Ing. Peña Casas Erwin Pablo

ELABORACIÓN.

Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓNStakeholder : que acepta: Carlos Jesús Murguía Morón QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y Requisitos que deben cumplirse: La oficina de la DIRCETUR debe ACEPTADO EL PDT. tener todo lo necesario para la implementación del

Sistema. Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE LaSEfase de Inicio y elaboración debe de ser aprobada TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y Personal: Sponsor COSTOS: QUÉ RECURSOS Materiales o Consumibles: Escritorio SE NECESITAN PARA ELABORAR EL

PDT, DEEquipos QUE o Máquinas: PC

TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Antes del pdt: Fase de Elaboración Y SUBSECUENTE TIENE EL PDT.

Después del pdt: Fase de Transición

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

3.1.4

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Fase Transición

OBJETIVO DEL PAQUETE DE TRABAJO:

Poner en marcha el Sistema

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE,

Documento que detalla el prototipo de interface de usuarios, las configuraciones de las cuentas, y la puesta en marcha del sistema.

130

CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): CÓMO SE VA A ELABORAR EL PDT.

Actividades a realizar: - Prototipos de Interface de Usuarios - Configuraciones de la Cuenta de Usuario -Puesto en Productivo del Sistema

ASIGNACIÓN DE RESPONSABILIDADES:

Responsable: Bohórquez Murguía Pablo Fernando Participa:

QUIÉNES INTERVIENEN, Y QUE ROL Revisa:Ing. Peña Casas Erwin Pablo DESEMPEÑAN EN LA

Aprueba: Sponsor

ELABORACIÓN.

Da información: Sponsor

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

Hitos importantes: CRITERIOS DE ACEPTACIÓN: QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Stakeholder que acepta: Carlos Jesús Murguía Morón Requisitos que deben cumplirse: El contenido debe ser comprensible. Forma en que se aceptará: Reunión de equipo del proyecto.

SUPUESTOS: SITUACIONES QUE SE TOMAN COMO VERDADERAS,

La fase de Inicio, elaboración y construcción deben de ser aprobada.

REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y COSTOS: QUÉ RECURSOS SE NECESITAN PARA ELABORAR EL

PDT, DE QUE

TIPO, EN QUE CANTIDADES, Y

Personal: Sponsor Materiales o Consumibles: Escritorio Equipos o Máquinas: PC

CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Y SUBSECUENTE TIENE EL PDT.

Antes del pdt: Fase de Construccion Despues del pdt: Pruebas y Testeo

131

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

4.1.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

Pruebas y Testeo

OBJETIVO DEL PAQUETE DE TRABAJO:

Se elabora pruebas y testeo del sistema

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): CÓMO SE VA A ELABORAR EL PDT.

Documento que detalla la elaboración del Plan de Pruebas, el diseño de pruebas y define las unidades del sistema a testear.

Actividades a realizar: - Elaborar el plan de Pruebas - Diseñar Pruebas - Definir unidades del sistema a Testear

ASIGNACIÓN DE RESPONSABILIDADES: QUIÉNES INTERVIENEN, Y QUE ROL DESEMPEÑAN EN LA

Responsable: Bohórquez Murguía Pablo Fernando Participa: Revisa:Ing. Peña Casas Erwin Pablo Aprueba: Sponsor

ELABORACIÓN.

Da información: Sponsor

FECHAS PROGRAMADAS:

Hitos importantes:

CUÁNDO SE VA A ELABORAR EL PDT.

CRITERIOS DE ACEPTACIÓN:

Stakeholder que acepta: Carlos Jesús Murguía Morón

QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Requisitos que deben cumplirse: EL redactarse de forma objetiva y clara.

informe

debe

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE SE TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y

Personal: Sponsor

132

COSTOS: QUÉ RECURSOS

Materiales o Consumibles: Escritorio

SE NECESITAN PARA

Equipos o Máquinas: PC PDT, DE QUE TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS. ELABORAR EL

DEPENDENCIAS: QUÉ PRECEDENTE Y SUBSECUENTE TIENE EL PDT.

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

Antes del pdt: Fase de Transición Después del pdt: Ejecución de Pruebas

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

4.1.2

Ejecución de Pruebas

OBJETIVO DEL PAQUETE DE TRABAJO:

Describe la ejecución de pruebas

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Documento que detalla la ejecución de pruebas, informe de pruebas

QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): CÓMO SE VA A ELABORAR EL PDT.

ASIGNACIÓN DE RESPONSABILIDADES: QUIÉNES INTERVIENEN, Y QUE ROL DESEMPEÑAN EN LA ELABORACIÓN.

Actividades a realizar: -

Realización de Pruebas Corregir Observaciones Desarrollar informe de Pruebas Identificar Observaciones

Responsable: Bohórquez Murguía Pablo Fernando Participa: Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Hitos importantes:

CUÁNDO SE VA A ELABORAR EL PDT

CRITERIOS DE ACEPTACIÓN: QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Stakeholder que acepta: Carlos Jesús Murguía Morón Requisitos que deben cumplirse: redactarse de forma objetiva y clara

el

informe

debe

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE SE TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA

133

PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y COSTOS: QUÉ RECURSOS SE NECESITAN PARA ELABORAR EL

PDT, DE QUE

TIPO, EN QUE CANTIDADES, Y

Personal: Sponsor Materiales o Consumibles: Escritorio Equipos o Máquinas: PC

CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Y SUBSECUENTE TIENE EL PDT.

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

Antes del pdt: Fase de Inicio Después del pdt: Fase de Construcción

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

5.1.1

Documentación del Sistema

OBJETIVO DEL PAQUETE DE TRABAJO:

Describe el desarrollo del sistema

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: QUÉ CONTIENE, EN QUÉ CONSISTE, CÓMO ES, DIMENSIONES, COTAS, ETC.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): CÓMO SE VA A ELABORAR EL PDT.

Documento que detalla el Modelamiento de Casos de Uso, Diagrama de Clases, Diagrama de Colaboración, Diagrama de Secuencia, Diagrama de Estado

Actividades a realizar: - Elaborar Manual del Sistema - Elaborar Manual de Usuario - Elaborar Ayuda del Sistema

ASIGNACIÓN DE RESPONSABILIDADES: QUIÉNES INTERVIENEN, Y QUE ROL DESEMPEÑAN EN LA ELABORACIÓN.

Responsable: Bohórquez Murguía Pablo Fernando Participa: Apoya: Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

134

FECHAS PROGRAMADAS:

Inicio:

CUÁNDO SE VA A ELABORAR EL PDT. Fin:

CRITERIOS DE ACEPTACIÓN: QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Hitos importantes:

Stakeholder que acepta: Carlos Jesús Murguía Morón Requisitos que deben cumplirse: El contenido debe ser comprensible. Forma en que se aceptará: Reunión de equipo del proyecto

SUPUESTOS: SITUACIONES QUE SE

La fase de Inicio debe de ser aprobada

TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y COSTOS: QUÉ RECURSOS SE NECESITAN PARA ELABORAR EL

PDT, DE QUE

TIPO, EN QUE CANTIDADES, Y

Personal: Sponsor Materiales o Consumibles: Escritorio Equipos o Máquinas: PC

CON QUE COSTOS.

DEPENDENCIAS: QUÉ PRECEDENTE Y SUBSECUENTE TIENE EL PDT.

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS

Antes del pdt: Ejecución de Pruebas Después del pdt: Capacitación Técnica

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL

WBS

5.2.1

Capacitación Técnica

OBJETIVO DEL PAQUETE DE TRABAJO:

Describe el plan de Capacitación

PARA QUE SE ELABORA EL PDT.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Documento que detalla el plan e informe de Capacitación

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

Actividades a realizar: - Plan de Capacitación - Informe de Capacitación

ASIGNACIÓN DE

Responsable: Bohórquez Murguía Pablo Fernando

135

RESPONSABILIDADES: QUIÉNES INTERVIENEN, Y QUE ROL DESEMPEÑAN EN LA ELABORACIÓN.

Participa: Apoya: Revisa: Ing. Peña Casas Erwin Pablo Aprueba: Sponsor Da información: Sponsor

FECHAS PROGRAMADAS:

Hitos importantes:

CUÁNDO SE VA A ELABORAR EL PDT.

CRITERIOS DE ACEPTACIÓN: QUIÉN, Y CÓMO SE DARÁ POR VALIDO Y ACEPTADO EL PDT.

Stakeholder que acepta: Carlos Jesús Murguía Morón Requisitos que deben cumplirse: El informe debe ser comprensible y objetivo.

Forma en que se aceptará: Reunión de equipo del proyecto SUPUESTOS: SITUACIONES QUE SE TOMAN COMO VERDADERAS, REALES, O CIERTAS, PARA EFECTOS DE LA PLANIFICACIÓN DEL

PDT.

RIESGOS: EVENTOS CUYA OCURRENCIA IMPACTARÁ LOS OBJETIVOS DEL ALCANCE, TIEMPO, COSTO, O CALIDAD, DEL

PDT.

RECURSOS ASIGNADOS Y COSTOS: QUÉ RECURSOS

Personal: Sponsor

SE NECESITAN PARA

Materiales o Consumibles: Escritorio

PDT, DE QUE TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

Equipos o Máquinas: PC

ELABORAR EL

DEPENDENCIAS: QUÉ PRECEDENTE

Antes del pdt: Documentación del Sistema

Y SUBSECUENTE TIENE EL PDT.

Después del pdt:

C. Informe de estado externo

INFORME DE PERFORMANCE DEL PROYECTO NOMBRE DEL PROYECTO Sistema Web de Productos Exportables

SIGLAS DEL PROYECTO SWPE

PERIODO Control y Seguimiento

FECHA DE CORTE 22/11/2013

136

Estado Actual del Proyecto: Como está el proyecto a la fecha de corte del periodo 1.- SITUACIÓN DEL ALCANCE

El proyecto se está realizando con total normalidad, no se ha presentado ningún retraso en el desarrollo de los entregables. Hasta el momento los objetivos propuestos de costos y calidad han sido logrados. 2.- EFICIENCIA DEL CRONOGRAMA

El cronograma se a cumplido según lo previsto. 4.- CUMPLIMIENTO DE OBJETIVOS DE CALIDAD

Todos los entregables fueron aceptados y aceptados por el Sponsor.

PROBLEMAS Y PENDIENTES: POR TRATAR. Mejora continua en los entregables. Cambio de Cultura tecnológica en la Organización Asistencia en las capacitaciones sobre el sistema Web SWPE

PROBLEMA / PENDIENTE:

RESPONSABLE FECHA

PROGRAMADOS PARA RESOLVER . Elaborar el informe de cierre de Fase

Project Manager

22/11/2013

Elaborar Informe de Cierre del Proyecto

Project Manager

22/11/2013

OTROS COMENTARIOS U OBSERVACIONES Resolver Pendientes antes de la fecha límite del Proyecto. No exceder de la fecha límite. No excederse en los costos.

137

D. Riesgos del Proyecto

INFORME DE MONITOREO DE RIESGOS RIESGOS ACTUALES POTENCIALES REVISIÓN DE TRIGGERS PARA LOS RIESGOS IDENTIFICADOS INICIALMENTE 

No hay coherencia en todas las especificaciones del módulo que indica el solicitante en comparación con el formato de levantamiento de información.



No hay informe de calidad para la etapa de verificación a tiempo.



Inconsistencia en la información de la Base de Datos para las pruebas funcionales de los usuarios.

REVISIÓN

Y

CONFIRMACIÓN

DE

PROBABILIDAD

E

IMPACTO

ESTIMADOS

INICIALMENTE



La falta de levantamiento de información más específica, aumentó su probabilidad de impacto a 0.50



Retraso en el inicio de la ejecución de pruebas en las fechas planificadas por parte del analista de calidad, disminuyó su probabilidad de impacto a 0.3



Retraso en la ejecución de pruebas con los usuarios en las fechas planificadas, mantiene su probabilidad de impacto en 0.35



Data desactualizada para realizar pruebas en desarrollo, disminuyó su probabilidad de impacto a 0.30.

REVISIÓN DE ADECUACIÓN DE RESPUESTAS PLANIFICADAS PARA LOS RIESGOS IDENTIFICADOS INICIALMENTE



El refuerzo en el levantamiento de información no fue suficiente para minimizar la incoherencia en las especificaciones del módulo descriptor del beneficio.



La reprogramación del personal de calidad y la asignación de un personal back up en casos de inasistencia imprevista logró disminuir la probabilidad del impacto.



Los usuarios aun no se alinean a las fechas planificadas para realizar las pruebas al funcionamiento del software en sus fases 1 y 2.



La re-validación de la información ingresada a la Base de Datos disminuyó la probabilidad de impacto a un nivel moderado.

138

REVISIÓN DE PLANES DE CONTINGENCIA PARA LOS RIESGOS IDENTIFICADOS INICIALMENTE



El Plan de contingencia para reforzar el levantamiento de información con una reunión adicional con los usuarios se complementará con la aplicación de un nuevo check list más técnico.



El Plan de contingencia de tener un analista de calidad de otra área como back up adicional en caso de ausencia imprevista logró disminuir la probabilidad de impacto.

VERIFICACIÓN DE EJECUCIÓN DE RESPUESTAS PLANIFICADAS 

Para la “Falta de información específica para la definición del alcance del proyecto” se aplicó la respuesta planificada y adicionalmente un plan de contingencia adicional.



Para el “Retraso en el inicio de la ejecución de pruebas en las fechas planificadas por parte del analista de calidad” se aplicó la respuesta planificada de reprogramación de la analista de calidad y de mantener un personal con las mismas competencias y conocimientos de otra área como back up o reemplazo ante imprevistos.



Para el “Retraso en la ejecución de pruebas con los usuarios en las fechas planificadas” se aplicó la respuesta planeada de hacer participar en la certificación al Gerente del área Comercial, y adicionalmente revisar las prioridades de las actividades de los usuarios.



Para el riesgo de “Data desactualizada para realizar pruebas en desarrollo” se aplicó la respuesta de la “re-validación” de la información de la base de datos.

RIESGOS ACTUALES SUCEDIDOS Valoración de Impacto Real vs Impacto Estimado 

El Riesgo “No disponibilidad de Hardware adecuado para el nivel de software a implementar”, inicialmente presentó un impacto estimado de 0.12, y el impacto real fue 0.20.



El Riesgo “Falta de alineación entre la información de la base de datos de Gotcard y la BD de los establecimientos asociados”, inicialmente el impacto estimado fue 0.12 y el impacto real fue 0.24.



El Riesgo “Incompatibilidad de herramientas de interface entre Gotcard y los establecimientos asociados”, inicialmente el impacto estimado fue 0.12 y el impacto real fue 0.28

Revisión de Planes de Contingencia

139



Para el riesgo “No disponibilidad de Hardware adecuado para el nivel de software a implementar “se definió:

Realizar la solicitud de compra de Hardware para el nivel de tecnología a implementar ya que la información que se administrará requerirá de velocidad para las transacciones de consultas asi como generación de reportes. 

Para el Riesgo “Falta de alineación entre la información de la base de datos de Gotcard y la BD de los establecimientos asociados” se definió :

Validar las bases de datos y alinear las diferencias. 

Para el Riesgo “Incompatibilidad de herramientas de interface entre Gotcard y los

establecimientos asociados” se definió: Validar las interfaces y alinear el nivel de tecnología entre Gotcard Manager y los establecimientos asociados. NUEVOS RIESGOS DETECTADOS EVALUACIÓN CUALITATIVA Y CATEGORIZACIÓN DE RIESGOS 

Virus en la Data

DEFINICIÓN DE RESPUESTAS PLANIFICADAS 

Instalar antivirus

DEFINICIÓN DE PLANES DE CONTINGENCIA 

Verificar que la data de la Dircetur este libre de Virus

PROGRAMACIÓN DE EJECUCIÓN DE RESPUESTAS PLANIFICADAS 

Se ejecuto la verificación de existencia de virus en la data de la DirCetur

E. Solicitud de Cambios

PLAN DE GESTIÓN DE CAMBIOS ROLES DE LA GESTIÓN DE CAMBIOS: ROLES QUE SE NECESITAN PARA OPERAR LA GESTIÓN DE CAMBIOS NOMBRE PERSONA DEL ROL ASIGNADA Sponsor

RESPONSABILIDADES CM

NIVELES

DE

AUTORIDAD

Discutir las decisiones otorgada Total sobre el proyecto. por el comité de cambio

140

Project

PB

Evaluar

Manage

las Hacer recomendaciones sobre los cambios.

Aprobar Solicitudes de Cambio. CM, JE

Decidir qué cambios se

Control de Stakeholders Cambio

de

Solicitudes de Cambio.

r Comité de

impactos

Autorizar, rechazar solicitudes de

aprueban, rechazan. Cualquiera

cambio.

Solicitar cambio cuando lo crean Solicitar cambios.

s

conveniente y oportuno

TIPOS DE CAMBIOS: DESCRIBIR LOS TIPOS DE CAMBIOS Y LAS DIFERENCIAS PARA TRATAR CADA UNO DE ELLOS. 1.

ACCIÓN CORRECTIVA:

Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución.

2. ACCIÓN PREVENTIVA: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución.

3. REPARACION DE DEFECTO: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en su lugar el Inspector de Calidad tiene la autoridad para aprobarlo y coordinar su ejecución.

4. CAMBIO AL PLAN DE PROYECTO: Este tipo de cambio pasa obligatoriamente por el Proceso General de Gestión de Cambios, el cual se describe en la sección siguiente.

PROCESO GENERAL DE GESTIÓN DE CAMBIOS: DESCRIBIR

EN DETALLE LOS PROCESOS DE LA GESTIÓN DE

CAMBIOS, ESPECIFICANDO QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE.

SOLICITUD DE CAMBIOS:



al

Stakeholders

y

levanta

información

detallada sobre lo que desea.

Captar las solicitudes y preparar el documento en forma adecuada y precisa.

Entrevista



El Project Manager se contacta con el Stakeholders cada vez que capta una iniciativa de cambio.

VERIFICAR SOLICITUD DE CAMBIOS:



información que se necesita para hacer una evaluación

Asegurar que se ha provisto toda la información

de impacto integral y exhaustivo.

necesaria para hacer la evaluación.

EVALUAR IMPACTOS:

Verifica que en la Solicitud de Cambios aparezca toda la



Completa la Solicitud de Cambio si es necesario.



El Project Manager evalúa los impactos integrales del cambio en todas las líneas base del proyecto,

Evalúa los impactos integrales de los cambios.



Describe en la Solicitud de Cambio los resultados de los impactos que ha calculado.

141

TOMAR DECISIÓN Y REPLANIFICAR:



El Comité de Control de Cambios evalúa los impactos

Se toma la decisión a la luz de los impactos,

calculados por el Project Manager y toma una decisión

(dependiendo de los niveles de autoridad), se

sobre la Solicitud de Cambio: aprobarla, rechazarla,

re planifica según sea necesario.

total o parcialmente.

IMPLANTAR EL CAMBIO:



Project

Manager replanifica

el

proyecto para

implantar el cambio aprobado.

Se realiza el cambio, se monitorea el progreso, y se reporta el estado del cambio.

El



Comunica los resultados de la replanificación a los stakeholders involucrados.

CONCLUIR EL PROCESO DE CAMBIO:



cambio se haya seguido correctamente.

Asegura que todo el proceso haya sido seguido correctamente, se actualizan los registros.

El Project Manager verifica que todo el proceso de



Actualiza todos los documentos, registros, y archivos históricos correspondientes.

PLAN DE CONTINGENCIA ANTE SOLICITUDES DE CAMBIO URGENTES: El único autorizado para utilizar y ejecutar personalmente este Plan de Contingencia es el Project Manager:

1. Registrar la Solicitud de Cambio: Project Manager registra personalmente la solicitud. 2. Verificar la Solicitud de Cambio: Project Manager verifica la solicitud. 3. Evaluar Impactos: Project Manager evalúa impactos. 4. Tomar Decisión: Project Manager toma la decisión consultando telefónicamente al Sponsor, en su defecto consultando a por lo menos dos miembros del Comité de Control de Cambios.

5. Implantar el Cambio: Project Manager implanta el cambio. 6. Formalizar el Cambio: Project Manager convoca al Comité de Control de Cambios y sustenta la necesidad de haber utilizado este procedimiento de urgencia. Comité de Control de Cambios formaliza la aprobación o reconsidera la decisión del Project Manager.

7. Ejecutar Decisión del Comité: Project Manager ejecuta decisión del Comité. 8. Concluir el Cambio: Project Manager concluye el proceso de cambio.

4.2.

Ingeniería del Proyecto A. Concepción a. Modelamiento del Negocio

142

Diagrama General del Negocio

o Solicitar información de Productos Exportables

143

Solicitar Información Actores:

Inversionista, Administrador

Descripción:

El inversionista extranjero solicita información sobre algún producto exportable de la Región al trabajador, se busca el código del producto solicitado manualmente o por tablas Excel y buscan empresas asociadas con ese producto. Luego se entrega la información al inversionista extranjero.

Precondiciones:

Ninguna

Pos condiciones:

Ninguna

144

Flujo Normal:

El inversionista extranjero solicita información de algún producto exportable al Trabajador. El Trabajador busca el código de producto solicitado. El Trabajador busca empresas que producen dicho producto. El trabajador entrega información al inversionista.

Flujos Alternativos:

o Solicitar Registro de Empresa

Registro de Empresas Actores:

Empresario, Administrador, Director de Área

Descripción:

El empresario solicita registrar su empresa al administrador, se le entrega un formulario para que el empresario lo llene. El empresario regresa el formulario lleno al administrador. Luego se envía el formulario al Director

145

para que se evalué y posteriormente decida si se registra la empresa. Precondiciones:

Ninguna

Pos condiciones:

Ninguna

Flujo Normal:

El empresario solicita registrar su empresa al administrador. El Administrador le entrega un formulario para que el empresario lo llene. El empresario llena el formulario y se lo entrega al Administrador. El Administrador le entrega el formulario lleno al Director. El Director evalúa el formulario y posteriormente decide si se registra la empresa.

Flujos Alternativos:

Diagrama Casos de Uso con el Sistema

146

o Caso de Uso Solicitar Información

147

Caso de Uso Consultar Categoria de Producto Actor

Inversionista

Descripción:

Se consulta las categorías asociadas a un producto.

Precondiciones:

Ninguna

Pos condiciones:

Ninguna

Flujo Normal:

1.

El inversionista quiere consulta una categoría.

2.

El sistema muestra las categorías disponibles

3.

El inversionista selecciona la categoría deseada.

4.

El sistema muestra los productos asociados a la Categoria.

Caso de Uso Consultar Producto Exportable Actor

Inversionista

Descripción:

Se consulta el producto por el cual esta interesado el inversionista

Precondiciones:

Ninguna

Pos condiciones:

Se muestra los productos que satisfacen al inversionista

Flujo Normal:

1.

El inversionista quiere consultar un producto

2.

El sistema muestra los productos exportables-.

3.

El inversionista selecciona el producto deseado

4.

El sistema muestra una lista con los productos que satisfacen las restricciones.

Caso de Uso Consultar Empresas Exportadoras Actor

Inversionista

Descripción:

Se consulta las empresas que están asociadas al producto seleccionado anteriormente.

Precondiciones: Pos condiciones: Flujo Normal:

1.

El inversionista quiere consultar una empresa del producto seleccionado anteriormente

2.

El sistema muestra las empresas exportables de dicho producto.

3.

El inversionista selecciona la empresa exportable

4.

El sistema muestra una lista con las empresas asociadas a dicho producto.

148

Caso de Uso Buscar Producto Actor

Inversionista

Descripción:

Se buscan productos con determiandas características

Precondiciones: Pos condiciones: Flujo Normal:

Se muestra los productos que satisfacen la restricción 1.

El inversionista quiere consultar un producto.

2.

El sistema muestra el principal filtro búsqueda.

3.

El inversionista introduce el nombre del producto a ser buscado.

4.

El sistema muestra una lista con los productos que satisfacen la búsqueda.

Caso de Uso Llenar de Información

149

Caso de Uso Registrar Empresa Actor

Administrador

Descripción:

Se podrá registrar las empresas en el sistema una vez evaluada por la DirCetur

Precondiciones: Pos condiciones: Flujo Normal:

1.

El administrador quiere registrar una empresa en el sistema

2.

El sistema validad los nuevos datos.

3.

El sistema registra la empresa

Caso de Uso Registrar Productos Actor

Administrador

Descripción:

Se podrá registrar nuevos productos exportables o agregar nuevos productos a empresas existentes.

Precondiciones: Pos condiciones: Flujo Normal:

Asociarse a empresas ya registradas 1.

El administrador quiere registrar nuevos productos exportables

2.

El sistema valida los nuevos datos

3.

El sistema registra el producto

Caso de Uso Ingresar Informacion Actor

Administrador

Descripción:

Se podrá agregar información al sistema sobre capacitaciones, ferias

Precondiciones: Pos condiciones: Flujo Normal:

1.

El administrador quiere registrar nuevos productos exportables

2.

El sistema valida los nuevos datos

3.

El sistema registra el producto

150

B. Elaboración C. Construcción D. Transición 4.3.

Soporte del Proyecto

4.3.1. Gestión de la Configuración

PLAN DE GESTIÓN DE LA CONFIGURACIÓN ROLES DE LA GESTIÓN DE LA CONFIGURACIÓN: ROLES QUE SE NECESITAN PARA OPERAR LA GESTIÓN DE LA CONFIGURACIÓN.

Nombre

Persona Asignada

del Rol

Responsabilidades

Niveles de Autoridad

Project Manager

PFBM

Supervisar el funcionamiento de la gestión de configuración

Toda autoridad sobre el proyecto y sus funciones.

Miembros del Equipo de Proyecto

Varios

Al inicio del Proyecto

Depende de cada miembro, se especifica para cada Item de configuración.

En cada reunión del equipo del proyecto

PLAN DE DOCUMENTACIÓN: CÓMO SE ALMACENARÁN Y RECUPERARÁN LOS DOCUMENTOS Y OTROS ARTEFACTOS DEL PROYECTO.

Formato (e=electróni co h=hard copy)

Acceso

Project Charter

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Plan de Proyecto

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n

Durante todo el proyecto

Document os ó Artefactos

Rápido Necesario

Disponibilid ad Amplia Necesaria

Seguridad de Acceso

Recupera ción de Informaci ón

Retención de Información

151

Restringida

Informe de Performan ce del proyecto

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Solicitud de Cambio

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Informe de Cierre de Proyecto

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

ITEMS DE CONFIGURACIÓN (CI): OBJETOS DEL

PROYECTO SOBRE LOS CUALES SE ESTABLECERÁN Y

MANTENDRÁN DESCRIPCIONES LÍNEA BASE DE LOS ATRIBUTOS FUNCIONALES Y FÍSICOS, CON EL FIN DE MANTENER CONTROL DE LOS CAMBIOS QUE LOS AFECTAN.

Categoría Código del Item de Configuración

1=Físico Nombre del Item de Configuración

2=Documen to 3=Formato 4=Registro

3.1

Fuente

Formato

P=Proyecto

(Softwar e+

C=Contratista Versión +

Observacio nes

V=Proveedor E=Empresa

Platafor ma)

Informe de Sesión Curso de Gestión de Proyectos

2

P

Hard Copy

3.2.2

Materiales de Curso MS Project

3

P

PDF

3.4.3

Informes de Sesión Curso MS Project

2

P

Hard Copy

152

5.1.1

Informe Mensual

2

P

PDF

Firmado y Aprobado

5.2.1

Informe Final

2

P

PDF

Firmado y Aprobado

GESTIÓN DEL CAMBIO:

ESPECIFICAR EL PROCESO DE GESTIÓN DEL CAMBIO O ANEXAR EL PLAN DE GESTIÓN

DEL CAMBIO.

Ver Plan de Gestión del Proyecto

CONTABILIDAD DE ESTADO Y MÉTRICAS DE CONFIGURACIÓN:

ESPECIFICAR

EL

REPOSITORIO DE INFORMACIÓN, EL REPORTE DE ESTADO Y MÉTRICAS A USAR.



El Repositorio de Información de los documentos del proyecto será una carpeta con la estructura del WBS para la organización interna de sus sub-carpetas.



No se llevarán métricas del movimiento y la historia de los documentos, artefactos, y CI’s para este proyecto.

VERIFICACIÓN Y AUDITORÍAS DE CONFIGURACIÓN:

ESPECIFICAR CÓMO SE ASEGURARÁ LA

COMPOSICIÓN DE LOS ITEMS DE CONFIGURACIÓN, Y COMO SE ASEGURARÁ EL CORRECTO REGISTRO, EVALUACIÓN, APROBACIÓN, RASTREO E IMPLEMENTACIÓN EXITOSA DE LOS CAMBIOS A DICHOS ITEMS.

Las verificaciones y auditorías de la integridad de la configuración serán rutinarias y bisemanales, realizadas por el Inspector de Aseguramiento de Calidad y donde se comprobará: •

Integridad de la información de los CI’s.



Exactitud y reproducibilidad de la historia de los CI’s.

4.3.2. Aseguramiento de la Calidad

INFORME DE AUDITORÍA DE CALIDAD FASE DEL PROYECTO

CÓDIGO DE LA AUDITORÍA

CIERRE

001

FECHA DE AUDITORÍA 27/11/2013

LÍDER DE LA AUDITORÍA SPONSOR

EQUIPO DE AUDITORÍA CARLOS JESUS MURGUIA MORON (DIRECTOR COMERCIO EXTERIOR)

153

JORGE ESPINOZA MIRANDA(ADMINITRADOR) MARTHA MORAN GALINDO(DIRECTORA TURISMO)

OBJETIVOS DE LA AUDITORÍA     

Verificar el estado del proyecto Verificar que el desarrollo de Software se haya realizado según el lenguaje establecido. Verificar que la capacitación del uso del software haya sido realizada y efectiva según el cronograma. Verificar el cumplimiento de los requisitos del usuario para el producto. Verificar que el Manual de Usuario ya esté disponible según el cronograma.

RESULTADOS DE LA AUDITORÍA TEMA AUDITADO

EVALUACIÓN

COMENTARIO

Estado de avance del Proyecto

El proyecto ha iniciado según lo programado.

Estado de Manual de Usuario

El Manual de Usuario

El contenido del Manual de

Fase ya está

Usuario fue utilizado para la

concluido dentro de

capacitación del Software

la fecha establecida Estado del desarrollo del software

El Software fue

Se verificó el desarrollo del

implementado según

sistema, para verificar si se

el lenguaje

esta usando los estándares y

establecido

lenguaje establecido del proyecto

EVALUACIÓN GENERAL DE LO AUDITADO El cronograma del proyecto se está desarrollando dentro de las fechas establecidas Según lo planificado. ACCIONES RECOMENDADAS Ninguna

COMENTARIOS ADICIONALES DE LA AUDITORÍA La puesta en producción del Software en Fase 1 se ha realizado según lo planificado. Adecuada mente según indica las evaluaciones de capacitación y la aplicación de la solicitudes de cambio.

154

SE ADJUNTA MATERIAL ADICIONAL

Si

X

no

NOMBRES DE LOS ADJUNTOS

4.3.3. Medición del Valor Ganado

CHECKLIST DE PRESENTACIÓN PARA REUNIÓN DE KICK OFF REALIZADO A CONTENIDO DE LA PRESENTACIÓN

SATISF

KICK OFF

ACCIÓN

OBSERVACIONES

(SI /NO) OBJETIVO DE LA PRESENTACIÓN DEFINIDO CONTENIDO

DE

LA

PRESENTACIÓN

SI O

AGENDA

ESTABLECIDA

DEFINICIÓN DEL PROYECTO

SI

SI

(¿QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE?) DEFINICIÓN DEL PRODUCTO DEL PROYECTO (DESCRIPCIÓN

DEL

PRODUCTO

DEL

PROYECTO,

SI

SERVICIO O CAPACIDAD FINAL A GENERAR)

PRINCIPALES STAKEHOLDERS DEL PROYECTO (CLASIFICADOS

SPONSOR, COMITÉ DE CONTROL PROJECT MANAGER, EQUIPO DE GESTIÓN DE PROYECTOS, CLIENTE, OTROS STAKEHOLDERS) COMO

DE CAMBIOS,

NECESIDADES DEL NEGOCIO A SATISFACER FINALIDAD

DEL PROYECTO

(FIN

SI

SI

ÚLTIMO, PROPÓSITO

GENERAL, U OBJETIVO DE NIVEL SUPERIOR POR EL CUAL SE EJECUTA EL PROYECTO,

SI

ENLACE CON PORTAFOLIOS, PROGRAMAS O ESTRATEGIAS DE LA ORGANIZACIÓN)

EXCLUSIONES CONOCIDAS DEL PROYECTO (QUE ES LO QUE NO ABORDARÁ EL PROYECTO)

NO

PRINCIPALES SUPUESTOS DEL PROYECTO

SI

PRINCIPALES RESTRICCIONES DEL PROYECTO

SI

Se recomienda detallar cuáles son las exclusiones conocidas del proyecto

155

LÍNEA BASE DEL ALCANCE (WBS A 2DO NIVEL) LÍNEA BASE

TIEMPO (CRONOGRAMA DE HITOS, NETO ESTIMADO, RESERVA DE CONTINGENCIA, Y RESERVA DE GESTIÓN)

No es necesario detallar todo el WBS

DEL

TIEMPO

LÍNEA BASE

NO

DEL

COSTO (PRESUPUESTO

SI

TOTAL, POR

FASES, POR PERIODOS DE TIEMPO, POR TIPO DE RECURSO, RESERVA DE CONTINGENCIA, Y

SI

RESERVA DE GESTIÓN)

OBJETIVOS

DE CALIDAD POR FACTOR RELEVANTE DE

CALIDAD

SI

ORGANIGRAMA DEL PROYECTO

SI

MATRIZ RAM RESUMIDA

NO

MATRIZ DE CALIDAD DEL PROYECTO

SI

MATRIZ DE COMUNICACIONES DEL PROYECTO

SI

PRINCIPALES

RIESGOS DEL PROYECTO Y RESPUESTAS

PLANIFICADAS

SI

MATRIZ DE ADQUISICIONES DEL PROYECTO

NO

SISTEMA DE CONTROL DE CAMBIOS

SI

La empresa no adquiere productos de otras empresas.

156

4.3.4. Métricas de Evaluación de desempeño

LOG DE CONTROL DE POLÉMICAS Código de Polémica

Descripción

Involucrados

Enfoque de Solución

Acciones de Solución

Responsable

Fecha

Resultado Obtenido

PO-001

Existen desacuerdos entre el

Analista de Sistemas de El Cliente.

Solicitar la participación de un representante del cliente que permita dirimir las polémicas.

Solicitar la participación

Project MAnager

06/11/2013

Se definieron parámetros objetivos para la identificación de un requerimiento fuera del alcance, reduciendo significativamente los desacuerdos entre el Analista de Sistemas del Cliente y el Project Manager.

Project Manager y el Analista de Sistemas de El Cliente al identificar los requerimientos que están fuera del alcance del

Project Manager.

del gerente de desarrollo o un representante que permita establecer los parámetros para identificar un cambio consecuencia

proyecto.

de un requerimiento fuera del Alcance del proyecto.

PO-002

Los programadores han mostrado su malestar por las continuas tardanzas y faltas de un programador.

Project Manager. Programadres.

sistema de sanciones y bonificaciones con relación al control de asistencia

Coordinar con el sponsor

Solicitar al analista de sistemas especificaciones de diseño de fácil visualización.

Solicitar al analista de sistemas que se entreguen las fuentes de los diagramas de diseño así como la instalación de un visor en las pcs de los programadores.

Project

23/10/2013

Se redujo la inasistencia y tardanzas del programa

Manager

Sponsor. PO-003

Los programadores comentan que las especificaciones de diseño no son visibles en el documento Word.

Programadores . Analista de Sistemas de El Cliente. Project Manager.

Project Manager

08/09/2013

Se trabajó siguiendo las especificaciones de diseño de El Cliente.

157

CAPITULO V: CIERRE DEL PROYECTO

158

5.1.

Gestión de Proyecto 5.1.1. Cierre

PLAN DE GESTIÓN DE PROYECTO CICLO DE VIDA DEL PROYECTO Y ENFOQUE MULTIFASE:

DESCRIPCIÓN DETALLADA DEL CICLO

DE VIDA DEL PROYECTO Y LAS CONSIDERACIONES DE ENFOQUE MULTIFASE

(CUANDO LOS RESULTADOS DEL FIN

DE UNA FASE INFLUYEN O DECIDEN EL INICIO O CANCELACIÓN DE LA FASE SUBSECUENTE O DEL PROYECTO COMPLETO).

CICLO DE VIDA DEL PROYECTO FASE DEL PROYECTO (1º NIVEL DEL WBS)

1.0 Inicio

ENTREGABLE PRINCIPAL DE LA FASE

ENFOQUES MULTIFASE CONSIDERACIONES PARA LA INICIACIÓN DE ESTA FASE

CONSIDERACIONES PARA EL CIERRE DE ESTA FASE

Project Charter Identificar a los interesados

2.0 Planificación

Plan de Calidad Plan de Costos Plan del Alcance

3.0 Ejecución

4.0

Plan

de Comunicacione s

Plan

de Recursos Humanos

Informes

de los requerimientos del usuario

Control y Informe de Pruebas Seguimiento

5.0 Cierre

Informes Finales

El Informe Final sólo podrá ser elaborado al término del desarrollo de los cursos de: Gestión de Proyectos y G.P usando el MS Project 2007.

PROCESOS DE GESTIÓN DE PROYECTOS: DESCRIPCIÓN DETALLADA DE LOS PROCESOS DE GESTIÓN DE PROYECTOS QUE HAN SIDO SELECCIONADOS POR EL EQUIPO DE PROYECTO PARA GESTIONAR EL PROYECTO.

159

Proceso

Nivel de Implantació n

Inputs

Modo de Trabajo

Outputs

Herramientas y Técnicas

Desarrollar el acta de constitución del Proyecto

Una sola vez, al inicio del proyecto

-Enunciado del Proyecto.

Mediante Acta de reuniones entre Constitución del el sponsor y el Proyecto Project Manager

PMBOK

Desarrollar enunciado del Alcance del Proyecto

Una sola vez, al inicio del Proyecto

-Acta de Constitución del Proyecto.

Mediante Enunciado del reuniones entre Alcance del el sponsor y el Proyecto Project Manager

PMBOk

-Enunciado del Alcance del Proyecto

Reuniones del Equipo del Proyecto

Plan de Gestión del Proyecto

PMBOK

-Acta de Constitución del Proyecto.

Reuniones del Equipo del Proyecto.

Plan de Gestión del Alcance del Proyecto.

Plantillas Formularios

Reuniones del equipo del proyecto

EDT

Plantillas de EDT

-Enunciado del Trabajo del Proyecto Desarrollar el Plan de Gestión del Proyecto

Planificación del Alcance

Al inicio del proyecto, pudiéndose actualizar en su desarrollo

-Enunciado del Alcance del Proyecto Preliminar. -Plan de Gestión del Proyecto. Crear EDT

Plan de Gestión del Alcance del Proyecto.

- Diccionario EDT

Redactar el Diccionario EDT. Desarrollo del Cronograma

Enunciado del Alcance del Proyecto.

Reunión del equipo del proyecto.

- Plan de Gestión del Proyecto.

Estimación de duración de actividades.

-Cronograma del Proyecto.

Red del Cronograma.

-Plan de Gestión del Proyecto.

160

Preparación del presupuesto de Costes

-Enunciado del Alcance del Proyecto.

Línea Base de Coste. Plan de Gestión de Costes

- EDT

Suma de costes Análisis de Reserva.

- Diccionario EDT. - Plan de Gestión de Costes. Planificación de Calidad

Factores ambientales de la empresa.

Establecimient o de objetivos de calidad.

Plan de Gestión de Calidad.

Estudios Comparativos

- Métrica de Calidad.

- Enunciado del Alcance del Proyecto. - Plan de Gestión del Proyecto. Planificación de Recursos Humanos

Planificación de las Comunicaciones

Factores ambientales de la empresa.

Reuniones de coordinación con el equipo del proyecto.

Roles y Responsabilidad es.

- Plan de Gestión del Proyecto.

- Organigrama Asignación de del Proyecto. roles y responsabilidad - Plan de Gestión del Personal. es.

Factores ambientales de la empresa.

Reuniones formales e informales con el equipo.

Organigramas y descripciones de cargos.

Plan de Gestión de las comunicaciones.

Tecnología delas Comunicacione s

Acciones correctivas recomendadas

PMBOK

- Enunciado del Alcance del Distribución de Proyecto. la documentación - Plan de y acuerdos. Gestión del Proyecto. Supervisar y controlar el trabajo del Proyecto

Durante todo el desarrollo del Proyecto

Plan de Gestión del Proyecto.

Reuniones de coordinación.

Reuniones de - Información información del sobre el estado del rendimiento del proyecto. trabajo.

161

Informar el Rendimiento

A partir de la ejecución del Proyecto

Información Informe de sobre el performance rendimiento del del proyecto. trabajo. -Mediciones de Rendimiento.

-Informes de Rendimiento. -Acciones correctivas recomendadas.

Recogida de la información de rendimiento Reuniones de revisión del estado de la situación

-Plan de Gestión del Proyecto. -Solicitudes de Cambio aprobadas

ENFOQUE DE TRABAJO: DESCRIPCIÓN DETALLADA DEL MODO EN QUE SE REALIZARÁ EL TRABAJO DEL PROYECTO PARA LOGRAR LOS OBJETIVOS DEL PROYECTO.

El proyecto ha sido planificado del tal manera que el equipo de proyecto conoce claramente los objetivos del proyecto, y las responsabilidades de los entregables que tienen a su cargo. A continuación se detalla el proceso a seguir para realizar el trabajo del proyecto: 1.

Inicialmente el equipo de proyecto se reúne para definir cuál será el alcance del proyecto.

2.

Se establece los documentos de gestión del proyecto necesarios que respaldan los acuerdos tomados por el equipo de proyecto.

3.

Se establecen la responsabilidades y roles del equipo de proyecto, y las fechas en que deberán estar listos los entregables.

4.

Se realizan reuniones semanales del equipo de proyecto para informar cual es el estado del proyecto, en términos de costo, calidad, tiempo. En esta reunión se presenta el Informe de Performance del Proyecto.

5.

Al término del proyecto se verifica la entrega de todos los entregables, y se redactan los documentos de cierre del proyecto.

PLAN DE GESTIÓN DE CAMBIOS:

DESCRIPCIÓN DE LA FORMA EN QUE SE MONITOREARÁN Y CONTROLARÁN

LOS CAMBIOS, INCLUYENDO EL QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE.

Ver Formato Plan de Gestión de Cambios

PLAN DE GESTIÓN DE LA CONFIGURACIÓN:

DEFINE AQUELLOS ITEMS QUE SON CONFIGURABLES,

AQUELLOS ITEMS QUE REQUIEREN UN CONTROL FORMAL DE CAMBIOS, Y LOS PROCESOS PARA CONTROLAR LOS CAMBIOS A DICHOS ITEMS.

Ver Formato Plan de Gestión de Configuración

GESTIÓN DE LÍNEAS BASE:

DESCRIPCIÓN DE LA FORMA EN QUE SE MANTENDRÁ LA INTEGRIDAD, Y SE

USARÁN LAS LÍNEAS BASE DE MEDICIÓN DE PERFORMANCE DEL PROYECTO, INCLUYENDO EL QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE.

162

El informe de performance del proyecto es un documento que se presentará semanalmente en la reunión de coordinación del equipo de proyecto, y debe presentar la siguiente información: - Estado Actual del Proyecto: 1. Situación del Alcance: Avance Real y Avance Planificado. 2. Eficiencia del Cronograma: SV y SPI. 3. Eficiencia del Costo: CV y CPI. 4. Cumplimiento de objetivos de calidad. - Problemas y pendientes que se tengan que tratar, y problemas y pendientes programados para resolver.

COMUNICACIÓN ENTRE STAKEHOLDERS:

DESCRIPCIÓN DETALLADA DE LAS NECESIDADES Y TÉCNICAS

DE COMUNICACIÓN ENTRE LOS STAKEHOLDERS DEL PROYECTO.

NECESIDADES DE COMUNICACIÓN DE LOS STAKEHOLDERS -Documentación de la Gestión del Proyecto.

TÉCNICAS DE COMUNICACIÓN A UTILIZAR

-Reuniones del equipo del proyecto para definir el alcance del mismo.

-Reuniones de coordinación de actividades del -Reuniones del equipo del proyecto que son proyecto.

convocadas por el Project Manager según se crean pertinentes donde se definirán cuales

son

las

actividades

que

se

realizarán. -Todos los acuerdos tomados por el equipo del proyecto deberán ser registrados en el Acta de Reunión de Coordinación. -Reuniones de información del estado del -Reuniones proyecto.

semanales

del

equipo

del

proyecto donde el Project Manager deberá informar al Sponsor y demás involucrados, cual es el avance real del proyecto en el periodo respectivo.

-Informe de Performance del Proyecto.

-Documento que será distribuido al equipo de proyecto en la reunión de coordinación semanal, y enviado por correo electrónico.

REVISIONES DE GESTIÓN:

DESCRIPCIÓN DETALLADA DE LAS REVISIONES CLAVES DE GESTIÓN QUE

FACILITARÁN EL ABORDAR LOS PROBLEMAS NO RESUELTOS Y LAS DECISIONES PENDIENTES.

TIPO DE REVISIÓN DE GESTIÓN

CONTENIDO

EXTENSIÓN O ALCANCE

OPORTUNIDAD

163

Reuniones de coordinación del Equipo del Proyecto.

Revisión del Acta de Reunión Anterior.

Reunión Semanal de información del Estado del Proyecto.

Revisión del Acta de Reunión anterior.

Comunicaciones

Solicitar feedback

- Presentación de entregables (si fuera el caso).

La reunión será convocada por el Project Manager.

Reunión convocada por solicitud del Project Manager.

La reunión se realizará todos los miércoles.

Programada para todos los Miércoles.

- Informe de Performance del Proyecto.

informales.

del Conocer

desarrollo

de

las

sesiones

del

programa

detalles

del Ninguna en especial

desarrollo de las sesiones.

de capacitación.

LÍNEA BASE Y PLANES SUBSIDIARIOS: DEFINICIÓN DE LÍNEA BASE Y ADJUNTAN AL

PLANES SUBSIDIARIOS QUE SE

PLAN DE GESTIÓN DEL PROYECTO.

LÍNEA BASE

Documento LÍNEA BASE DEL ALCANCE

LÍNEA BASE DEL TIEMPO

LÍNEA BASE DEL COSTO

PLANES SUBSIDIARIOS

Adjunto (si/no) SI

SI

SI

Tipo de Plan

Adjunto (si/no)

PLAN DE GESTIÓN DE ALCANCE

SI

PLAN DE GESTIÓN DE REQUISITOS

SI

PLAN DE GESTIÓN DE SCHEDULE

SI

PLAN DE GESTIÓN DE COSTOS

SI

PLAN DE GESTIÓN DE CALIDAD

SI

PLAN DE MEJORA DE PROCESOS

NO

PLAN DE RECURSOS HUMANOS

SI

PLAN DE GESTIÓN DE COMUNICACIONES

SI

PLAN DE GESTIÓN DE RIESGOS

SI

PLAN DE GESTIÓN DE ADQUISICIONES

SI

164

5.2.

Ingeniería del Proyecto

5.3.

Soporte del Proyecto 5.3.1. Gestión de la Configuración

PLAN DE GESTIÓN DE LA CONFIGURACIÓN ROLES DE LA GESTIÓN DE LA CONFIGURACIÓN: ROLES QUE SE NECESITAN PARA OPERAR LA GESTIÓN DE LA CONFIGURACIÓN.

Nombre

Persona Asignada

del Rol

Responsabilidades

Niveles de Autoridad

Project Manager

PFBM

Supervisar el funcionamiento de la gestión de configuración

Toda autoridad sobre el proyecto y sus funciones.

Miembros del Equipo de Proyecto

Varios

Al inicio del Proyecto

Depende de cada miembro, se especifica para cada Item de configuración.

En cada reunión del equipo del proyecto

PLAN DE DOCUMENTACIÓN: CÓMO SE ALMACENARÁN Y RECUPERARÁN LOS DOCUMENTOS Y OTROS ARTEFACTOS DEL PROYECTO.

Formato (e=electróni co h=hard copy)

Acceso

Project Charter

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Plan de Proyecto

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Document os ó Artefactos

Rápido Necesario

Disponibilid ad Amplia Necesaria

Seguridad de Acceso

Recupera ción de Informaci ón

Retención de Información

165

Informe de Performan ce del proyecto

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Solicitud de Cambio

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

Informe de Cierre de Proyecto

E

Disponibl e On-line

A todos los stakeholder s

Lectura general Modificació n Restringida

Durante todo el proyecto

ITEMS DE CONFIGURACIÓN (CI): OBJETOS DEL

PROYECTO SOBRE LOS CUALES SE ESTABLECERÁN Y

MANTENDRÁN DESCRIPCIONES LÍNEA BASE DE LOS ATRIBUTOS FUNCIONALES Y FÍSICOS, CON EL FIN DE MANTENER CONTROL DE LOS CAMBIOS QUE LOS AFECTAN.

Categoría Código del Item de Configuración

1=Físico Nombre del Item de Configuración

2=Documen to 3=Formato 4=Registro

3.1

Fuente

Formato

P=Proyecto

(Softwar e+

C=Contratista Versión +

Observacio nes

V=Proveedor E=Empresa

Platafor ma)

Informe de Sesión Curso de Gestión de Proyectos

2

P

Hard Copy

3.2.2

Materiales de Curso MS Project

3

P

PDF

3.4.3

Informes de Sesión Curso MS Project

2

P

Hard Copy

5.1.1

Informe Mensual

2

P

PDF

Firmado y Aprobado

5.2.1

Informe Final

2

P

PDF

Firmado y

166

Aprobado GESTIÓN DEL CAMBIO:

ESPECIFICAR EL PROCESO DE GESTIÓN DEL CAMBIO O ANEXAR EL PLAN DE GESTIÓN

DEL CAMBIO.

Ver Plan de Gestión del Proyecto

CONTABILIDAD DE ESTADO Y MÉTRICAS DE CONFIGURACIÓN:

ESPECIFICAR

EL

REPOSITORIO DE INFORMACIÓN, EL REPORTE DE ESTADO Y MÉTRICAS A USAR.



El Repositorio de Información de los documentos del proyecto será una carpeta con la estructura del WBS para la organización interna de sus sub-carpetas.



No se llevarán métricas del movimiento y la historia de los documentos, artefactos, y CI’s para este proyecto.

VERIFICACIÓN Y AUDITORÍAS DE CONFIGURACIÓN:

ESPECIFICAR CÓMO SE ASEGURARÁ LA

COMPOSICIÓN DE LOS ITEMS DE CONFIGURACIÓN, Y COMO SE ASEGURARÁ EL CORRECTO REGISTRO, EVALUACIÓN, APROBACIÓN, RASTREO E IMPLEMENTACIÓN EXITOSA DE LOS CAMBIOS A DICHOS ITEMS.

Las verificaciones y auditorías de la integridad de la configuración serán rutinarias y bisemanales, realizadas por el Inspector de Aseguramiento de Calidad y donde se comprobará: •

Integridad de la información de los CI’s.



Exactitud y reproducibilidad de la historia de los CI’s.

5.3.2. Aseguramiento de la Calidad

INFORME DE AUDITORÍA DE CALIDAD FASE DEL PROYECTO

CÓDIGO DE LA AUDITORÍA

CIERRE

001

FECHA DE AUDITORÍA 27/11/2013

LÍDER DE LA AUDITORÍA SPONSOR

EQUIPO DE AUDITORÍA CARLOS JESUS MURGUIA MORON (DIRECTOR COMERCIO EXTERIOR) JORGE ESPINOZA MIRANDA(ADMINITRADOR) MARTHA MORAN GALINDO(DIRECTORA TURISMO)

167

OBJETIVOS DE LA AUDITORÍA     

Verificar el estado del proyecto Verificar que el desarrollo de Software se haya realizado según el lenguaje establecido. Verificar que la capacitación del uso del software haya sido realizada y efectiva según el cronograma. Verificar el cumplimiento de los requisitos del usuario para el producto. Verificar que el Manual de Usuario ya esté disponible según el cronograma.

RESULTADOS DE LA AUDITORÍA TEMA AUDITADO

EVALUACIÓN

COMENTARIO

Estado de avance del Proyecto

El proyecto ha iniciado según lo programado.

Estado de Manual de Usuario

El Manual de Usuario

El contenido del Manual de

Fase ya está

Usuario fue utilizado para la

concluido dentro de

capacitación del Software

la fecha establecida Estado del desarrollo del software

El Software fue

Se verificó el desarrollo del

implementado según

sistema, para verificar si se

el lenguaje

esta usando los estándares y

establecido

lenguaje establecido del proyecto

EVALUACIÓN GENERAL DE LO AUDITADO El cronograma del proyecto se está desarrollando dentro de las fechas establecidas Según lo planificado. ACCIONES RECOMENDADAS Ninguna

COMENTARIOS ADICIONALES DE LA AUDITORÍA La puesta en producción del Software en Fase 1 se ha realizado según lo planificado. Adecuada mente según indica las evaluaciones de capacitación y la aplicación de la solicitudes de cambio. SE ADJUNTA MATERIAL ADICIONAL

Si

X

no

NOMBRES DE LOS ADJUNTOS

168

5.3.3. Métricas y Evaluación del Desempeño

INFORME DE MÉTRICAS DEL PROYECTO NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

SISTEMA WEB DE PRODUCTOS EXPORTABLES

SWPE

CUADRO DE MÉTRICAS (RELACIONES PRODUCTO / INSUMO) TIPO DE DESCRIPCIÓN

EN TR EG

ENTREGABLE

TAMAÑO DE

DEL

TRABA

AB

JO

LOS

M

ENTR

PL

EGAB

EA

LES

LE

Informe de

RECURSOS E MÉTRICA

OBSERVACIONES

D OS

3.2.1.2 al

Elaboración

3.2.12.2

del informe de

Sesión

8 págs.

1.5 hs

0.1875 hr/pag

la sesión Informe del Estado del Proyecto

1.3

Elaborar el Informe de

4 hojas

1 hr

0.250 hr/pag

Performance del Proyecto

169

Informe Mensual

5.1.1.

Elaboración

5.1.2.

del informe

5.1.3.

Informe Final

5.2

35 hojas

4 hs

0.114 hr/pag

Diseñado de acuerdo al formato

mensual

proporcionado por la Dircetur Elabora el Informe Final del Servicio

30 hojas

4hrs

0.133 hr/pag

Diseñado de acuerdo al formato proporcionado por la DIRCETUR

170

CAPITULO VI: CONCLUSIONES Y RECOMENDACIONES

171

6.1.

Conclusiones

La elaboración del Sistema Web de Productos Exportables de la Región Ica fue una labor que enfrentó una serie de limitaciones no contempladas en la propuesta original de desarrollo del proyecto. Los principales obstáculos fueron la inexistencia de estadísticas que registren datos de producción a nivel regional, y la escasa información procesada con que cuentan las instituciones públicas y privadas a nivel local. Para subsanar tales carencias sería necesario realizar un levantamiento directo de información a través de una encuesta si no un censo a productores de toda la región. Este tipo de actividades, por su carácter de bienes públicos y su alto costo financiero y administrativo, solo suelen ser llevadas a cabo por los gobiernos central o regional. Afortunadamente, la estrategia original para el acopio de información—basada en el levantamiento de información secundaria proveniente de asociaciones de productores y entidades estatales—, y la existencia de datos confiables de Aduanas, permitieron recoger suficientes datos para desarrollar un SWPE útil, innovador y relevante, trabajándose dentro de los parámetros temporales y presupuestales estipulados por el proyecto. De hecho, considera que el producto final, el SWPE, excede los requerimientos originalmente planteados por los términos de referencia de este proyecto, en la medida que se ofrece un producto adecuadamente diseñado para un público objetivo específico.

6.2.

Recomendaciones

La metodología planteada originalmente para la elaboración del SWPE, basada en RUP, es capaz de desarrollar una base de datos consistentes, amplios y útiles para el público objetivo importante. Pero esto no significa que la sostenibilidad del MERI como herramienta útil pueda descansar en este primer esfuerzo. De hecho, se considera que el SWPE resultante de este proyecto constituye solo una matriz para organizar la presentación de la oferta exportable de la

172

región Ica. Más aun, la importancia de realizar actividades de promoción y difusión relacionadas con este proyecto no puede ser exagerada. En primer lugar, la información sobre empresas consignada en SWPE es información dinámica que se desactualiza día a día. Esto significa que, para mantener su relevancia, el SWPE debe ser constantemente actualizado. Por otro lado, como ya se explicó, la información contenida en el MERI no es exhaustiva, en la medida que la estadística existente en el país tampoco lo es. Pero el público objetivo del MERI no requiere necesariamente contar con estadísticas agregadas. En tal sentido, es importante resaltar la necesidad de expandir la información específica para cada empresa con el fin de incrementar la utilidad para el inversionista/comprador extranjero. Estos requerimientos hacen evidente la necesidad de contar con información de primera mano de todas las empresas de la región, incluidas o no en el SWPE.

GLOSARIO DE TERMINOLOGÍA DEL PROYECTO Nº

TÉRMINO

DEFINICIÓN

1

PMBOK

Fundamentos de la dirección de proyectos

2

Software

Programa o aplicación para dar instrucciones de una tarea específica.

3

DIRCETUR

Dirección Comercio Exterior y Turismo

4

Interface grafica

Aproximación amistosa de una aplicación informática dirigida a usuarios no especializados, en la cual las informaciones y las acciones aplicables a las mismas se representan mediante objetos gráficos sensibles a ser manipulados de forma visual.

5

Inversionista

El inversionista es una persona que invierte cierto capital en una empresa, formada por un grupo que conforman la misma y de acuerdo con el mayor aporte de capital, se determina la responsabilidad de cada uno y se distribuye la ganancia del capital

173

6

Demanda Externa

Es la cantidad de bienes y servicios producidos en un país, y que son demandados por residentes en el extranjero

7

WBS

Work Breakdown Structure / Estructura de Desglose del Trabajo (EDT).

8

AC

Actual Cost / Coste Real

9

Metodología RUP

Rational Unifed Process constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

10

QA

Aseguramiento de calidad

11

QC

Control de calidad

12

Prototipos

Es un ejemplar o primer molde de lo que se va a trabajar, en nuestro caso son las pantallas con las que contara nuestros sistema.

13

Base de Datos

Conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso

174

BIBLIOGRAFICA Ambler, S., Nalvone, j., & Vizdos, M. (2005). Sterling-hoffman. Recuperado el 2013 de junio de 12, de http://www.sterlinghoffman.com/cgibin/index.pl?p=newsletter/articles/article138.html Biocomercio. (2008). Programa Nacional BioComercio. Recuperado el 5 de mayo de 2013, de htto://biocomercioperu.pe/ Borrero. (2003). Tecnologias de la Informacion en Internet. España. Boyd, A. (2001). The five maxims of project satisfaction. Aslib Proceedings, . Chauman, Y. (2003). Administración Profesional de Proyectos La Guía. Mexico. Debrauwer, l., & Van der Heyde, F. (2005). UML 2. Barcelona: ENI. DeCarlo, J., & Mancin, E. (2004). IBM Rational Unified Process for System. 2004. Ibm.com/redbooks. Recuperado el 19 de junio de 2013, de http://www.redbooks.ibm.com/redbooks/SG247362/wwhelp/wwhimpl/js/html/wwhel DIRCETUR. (s.f.). Recuperado el 28 de abril de 2013, de http://www.dirceturica.gob.pe/index.php?option=com_content&view=article&id=78&Ite mid=89, Dixon, M. (2000). Project management body of knowledge. Recuperado el 29 de junio de 2013, de http://www.apm.org.uk/ Fernández Céspedes, K. V. (2010). Análisis, diseño e implementación de un sistema de registro y seguimiento de solicitudes a concesionarios de cafeterías a través de una intranet. Universidad Catolica del Peru. Garcia, G. (2009). Estudio de Factibilidad de Exportacion de Granadilla al mercado aleman. Gido, J., & Clements, J. (2003). Administración Exitosa de Proyectos. MExico: International Thompson . Jimenez Murillo, K. R. (2012). Propuesta de MEtodologia y Estandares para la Administracion de Proyectos en las pequeñas y medias Empresas de Software. San Jose . Kendall, E., & Kendall, J. (2005). Analisis y Diseño. Pearson Education. kroll, P. (2010). Tendencias del Mundo Real que Influyen en las Mejores Prácticas de Software. Recuperado el 5 de mayo de 2013, de http://www.clubdeinvestigacion.com/contenido/articles/expositor-per-kroll.html Kruchten, P. (2004). Electrical and Computer Engineering. Recuperado el 12 de mayo de 2013, de http://www.ece.ubc.ca/faculty/philippe-kruchten 175

Mapfre. (2011). Information Technology Consulting. Recuperado el 22 de mayo de 2013, de http://www.itc-software.com.ar/casoexito2.html Martinez, A., & R., M. (2012). Guia a Rational Unified Process. Per, K. (2003). The Rational Unified Process Made Easy Addison. Wesley. PMBOK. (2008). Project Management Institute. Guía de los Fundamentos de la Dirección de Proyectos. Pennsylvania: 4. Quispe Soto, E. I. (2009). Ingenieria de Software Metodologia RUP. Recuperado el 22 de junio de 2013, de http://es.scribd.com/doc/58904463/Metodologia-RUP RUP, I. R. (2002). Recuperado el 23 de mayo de 2013 Sencico. (2009). Scrib. Recuperado el 2 de mayo de 2013, de http://es.scribd.com/doc/131652708/SENCICO-SESION-01-MS-PROJECT-2010-pdf Siicex. (2010). Sistema Integrado de Informacion de Comercio Exterior. Recuperado el 6 de junio de 2013, de http://www.siicex.gob.pe/siicex/portal5ES.asp?_page_=775.77400 Thompson, M. (2009). Todo Sobre Proyectos. Recuperado el 5 de abril de 2013, de http://todosobreproyectos.blogspot.com/2009/01/el-ciclo-de-los-proyectos.html Universidad Politecnica de Valencia. (25 de Septiembre de 2012). Recuperado el 12 de junio de 2013, de http://www.upv.es/contenidos/DOCINF/info/buenaspracticas.pdf Weitzenfeld, A. (2005). Ingenieria de Software orientado a objetos UML.

176

1. ANEXOS

177

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF