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
