desarrollo de un nuevo software para operadores de comercio exterior - planificación

FGPR020- Versión 4.0

CONTROL DE VERSIONES

Versión Hecha por Revisada por Aprobada por Fecha Motivo

1.0 GLÑ

FJ 25/06/2011 Versión original 1.1 JP FJ 27/06/2011 Versión ajustada

SSCCOOPPEE SSTTAATTEEMMEENNTT

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

DESARROLLO DE UN NUEVO SOFTWARE PARA OPERADORES DE COMERCIO EXTERIOR

CONSOTER

DESCRIPCIÓN DEL ALCANCE DEL PRODUCTO REQUISITOS: CONDICIONES O CAPACIDADES QUE DEBE POSEER O SATISFACER EL PRODUCTO PARA CUMPLIR CON

CONTRATOS, NORMAS, ESPECIFICACIONES, U OTROS

DOCUMENTOS FORMALMENTE IMPUESTOS.

CARACTERÍSTICAS: PROPIEDADES FÍSICAS, QUÍMICAS, ENERGÉTICAS, O SICOLÓGICAS, QUE SON DISTINTIVAS DEL PRODUCTO, Y/O QUE DESCRIBEN SU SINGULARIDAD.

1. Que los usuarios del cliente cuenten con una herramienta informática que les permita ingresar, actualizar, consultar y dar de baja Operadores de Comercio, Circunscripciones, Representantes y Sanciones.

1. Módulo web que permite realizar el mantenimiento de Operadores de Comercio, Circunscripciones, Representantes y Sanciones.

2. Se debe poder exportar e imprimir las consultas.

2. Las consultas podrán ser visualizadas e impresas desde el navegador y exportadas a Excel y PDF.

3. El módulo debe ser una aplicación Web.

3. Para el uso de la aplicación basará tener un explorador Web.

4. Debe contar con esquema de seguridad integrado a la plataforma del cliente.

4. Para el ingreso, el usuario deberá autenticarse en la Intranet para que le habilite las opciones que le corresponde según su perfil.

5. El diseño de las interfaces debe ser de acuerdo al estándar del cliente.

5. La aplicación deberá diseñarse de acuerdo al estándar de páginas Web del cliente (colores, fuentes, distribución de objetos, formas de menú, entre otros)

6. La aplicación debe ser multiusuario y que permita sesiones concurrentes.

6. La aplicación deberá ser multiusuario y manejar transacciones a nivel de servidor de aplicaciones y de base de datos.

7. Debe contemplar un Manual de usuario con las instrucciones del uso del módulo en la Intranet del cliente.

7. El Manual de usuario deberá seguir el estándar de los manuales de usuario del cliente y publicarse en la Intranet.

8. Documentación de las pruebas unitarias y de integración de los módulos desarrollados.

8. La documentación de las pruebas deberán realizarse de acuerdo a los formatos pre-establecidos por el cliente.

9. Este módulo deberá estar integrado con el conjunto de aplicación de la Intranet del cliente.

9. Se definirá la ubicación de la aplicación en el mapa Web de la Intranet del cliente.

10. El usuario podrá utilizar cualquier navegador disponible en el mercado para utilizar el módulo

10. El módulo debe ser compatible con los diversos navegadores.

Contacto: [email protected], Página Web: www.dharmacon.net

Dharma Consulting ha sido revisada y aprobada como un proveedor de entrenamiento en Project Management por el Project Management Institute (PMI). Como un Registered Education Provider (R.E.P.) del PMI, Dharma Consulting ha

aceptado regirse por los criterios establecidos de aseguramiento de calidad del PMI.


2

CRITERIOS DE ACEPTACIÓN DEL PRODUCTO: ESPECIFICACIONES O REQUISITOS DE RENDIMIENTO, FUNCIONALIDAD, ETC., QUE DEBEN CUMPLIRSE ANTES QUE SE ACEPTE EL PRODUCTO DEL PROYECTO.

CONCEPTOS CRITERIOS DE ACEPTACIÓN

1. TÉCNICOS La aprobación del Analista de Sistemas del entregable. 2. DE CALIDAD La aprobación del cumplimiento de estándares de

programación, así como de los requerimientos funcionales y no funcionales.

3. ADMINISTRATIVOS Actas de conformidad del servicio por parte del cliente. 4. COMERCIALES Cumplir con los acuerdos del contrato. 5. SOCIALES Entrega de la documentación de pruebas integrales y manuales

de usuarios de acuerdo a los formatos del cliente.

ENTREGABLES DEL PROYECTO: PRODUCTOS ENTREGABLES INTERMEDIOS Y FINALES QUE SE GENERARÁN EN CADA

FASE DEL PROYECTO. FASE DEL PROYECTO PRODUCTOS ENTREGABLES

1.0 Gestión del Proyecto Proyecto gestionado 2.0 Operadores de Comercio

Módulo de operadores de comercio exterior terminado

3.0 Circunscripciones Módulo de circunscripciones terminado 4.0 Representantes Módulo de representantes terminado 5.0 Sanciones Módulo de sanciones terminado 6.0 Entregables Finales Documentación de pruebas, revisión de estándares y entrega 7.0 Levantamiento de Observaciones

Análisis de observaciones y levantamiento con el documento de entrega

EXCLUSIONES DEL PROYECTO: ENTREGABLES, PROCESOS, ÁREAS, PROCEDIMIENTOS, CARACTERÍSTICAS, REQUISITOS, FUNCIONES, ESPECIALIDADES, FASES, ETAPAS, ESPACIOS FÍSICOS, VIRTUALES, REGIONES, ETC., QUE SON

EXCLUSIONES CONOCIDAS Y NO SERÁN ABORDADAS POR EL PROYECTO, Y QUE POR LO TANTO DEBEN ESTAR CLARAMENTE ESTABLECIDAS PARA EVITAR INCORRECTAS INTERPRETACIONES ENTRE LOS STAKEHOLDERS DEL PROYECTO. 1. No se realizará ninguna actividad de análisis y/o diseño de software pues se considera que estas actividades han sido completadas al 100% por el cliente. 2. Aceptación y pruebas funcionales del componente aprobados por el cliente 3. Implantación del producto 4. Infraestructura de desarrollos 5. No se considera Cambio de idioma. 6. No se considera cambios solicitados no definidos en la matriz de requisitos aprobados.

RESTRICCIONES DEL PROYECTO: FACTORES QUE LIMITAN EL RENDIMIENTO DEL PROYECTO, EL RENDIMIENTO DE

UN PROCESO DEL PROYECTO, O LAS OPCIONES DE PLANIFICACIÓN DEL PROYECTO. PUEDEN APLICAR A LOS OBJETIVOS DEL PROYECTO O A LOS RECURSOS QUE SE EMPLEA EN EL PROYECTO.

INTERNOS A LA ORGANIZACIÓN AMBIENTALES O EXTERNOS A LA ORGANIZACIÓN

El proyecto debe terminarse dentro del presupuesto estimado y acordado con el cliente

Toda la información que se maneja en el proyecto es de carácter confidencial.

Los entregables serán aprobados por el cliente luego de las pruebas funcionales que este realice y se hayan levantados todas las observaciones que este haya reportado

Se debe cumplir con los estándares de programación del cliente

Deberá contarse con toda la infraestructura y el ambiente de desarrollo apropiado para la realización de la construcción y pruebas del software

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

Penalidad económica por cada día de incumplimiento de plazos

SUPUESTOS DEL PROYECTO: FACTORES QUE PARA PROPÓSITOS DE LA PLANIFICACIÓN DEL PROYECTO SE

CONSIDERAN VERDADEROS, REALES O CIERTOS.


3

INTERNOS A LA ORGANIZACIÓN AMBIENTALES O EXTERNOS A LA ORGANIZACIÓN

Se cuenta con el personal capacitado para el desarrollo del software que encarga el cliente El personal está capacitado en los estándares de programación y el uso del framework del cliente

El cliente se encargara de proveer el análisis y el diseño del software que requiera con el nivel de detalle suficiente. El cliente se encargara de realizar las revisiones de estándares y las pruebas del software entregado por el proveedor para lo cual contara con el personal capacitado El Cliente se encarga del hosting.




1.0 GLÑ

FJ 25/06/2011 Versión original 1.1 JP FJ 27/06/2011 Versión ajustada


DDOOCCUUMMEENNTTAACCIIÓÓNN DDEE RREEQQUUIISSIITTOOSS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

DESARROLLO DE UN NUEVO SOFTWARE PARA CONSOTER OPERADORES DE COMERCIO EXTERIOR

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 cliente, para establecer posibles vínculos para otros proyectos. El cliente requiere tercerizar la etapa de construcción de sus proyectos informáticos por capacidad operativa y reducción de costos. El cliente requiere contar con un sistema informático que le permita registrar y recuperar la información de los Operadores de Comercio Exterior. OBJETIVOS DEL NEGOCIO Y DEL PROYECTO: DEFINIR CON CLARIDAD LOS OBJETIVOS DEL NEGOCIO Y DEL PROYECTO PARA PERMITIR LAS TRAZABILIDAD DE ÉSTOS. Cumplir con los requerimientos del cliente en el plazo menor de lo presupuestado de manera eficiente. Cumplir con los requerimientos establecidos por el cliente para la construcción del módulo de Operadores de Comercio Exterior. REQUISITOS FUNCIONALES: DESCRIBIR PROCESOS DEL NEGOCIO, INFORMACIÓN, INTERACCIÓN CON EL PRODUCTO, ETC.

STAKEHOLDER PRIORIDAD OTORGADA POR EL STAKEHOLDER

REQUISITOS

CÓDIGO DESCRIPCIÓN

El Cliente ALTA REQ01 Desarrollar el módulo de mantenimiento de Operadores de Comercio, c Circunscripciones, Representantes y Sanciones.

ALTA REQ02 Implementar la trazabilidad del módulo.

ALTA REQ03 Manual de usuario disponible en la Intranet.

ALTA REQ04 Documentación de las pruebas de integración.

ALTA REQ05 Debe permitir la impresión y exportación a Excel y PDF de todas las consultas.

ALTA REQ06 El módulo debe ser una aplicación Web.

ALTA REQ07 Este módulo deberá estar integrado con el conjunto de aplicación de la Intranet del cliente.

REQUISITOS NO FUNCIONALES: DESCRIBIR REQUISITOS TALES CÓMO NIVEL DE SERVICIO, PERFOMANCE, SEGURIDAD, ADECUACIÓN, ETC.


REQUISITOS





2

El Cliente ALTA REQ08 Cumplir con los estándares de programación.

ALTA REQ09 Debe contar con esquema de seguridad integrado a la plataforma del cliente. ALTA REQ09 Entrega del código fuente de la aplicación desarrollada ALTA REQ10 Entrega de procedimientos de instalación ALTA REQ11 Mantener la confidencialidad de la información del cliente. ALTA REQ12 El sistema debe poder ejecutarse en cualquier navegador. ALTA REQ13 Soporte multiusuario y de conexiones concurrentes. ALTA REQ14 Documentación de las pruebas unitarias y de integración de los módulos desarrollados. La DC Consulting ALTA REQ15 El proyecto debe ser rentable y llevarse a cabo en el tiempo establecido. REQUISITOS DE CALIDAD: DESCRIBIR REQUISITOS RELATIVOS A NORMAS O ESTÁNDARES DE CALIDAD, O LA SATISFACCIÓN Y CUMPLIMIENTO DE FACTORES RELEVANTES DE CALIDAD.


REQUISITOS


El Cliente ALTA REQ16 Cumplir con los estándares de programación del cliente.

CRITERIOS DE ACEPTACIÓN: ESPECIFICACIONES O REQUISITOS DE RENDIMIENTO, FUNCIONALIDAD, ETC., QUE DEBEN CUMPLIRSE ANTES DE ACEPTAR EL PROYECTO.

CONCEPTOS CRITERIOS DE ACEPTACIÓN

1. TÉCNICOS La aprobación del Analista de Sistemas del entregable. 2. DE CALIDAD La aprobación del cumplimiento de estándares de

programación, así como de los requerimientos funcionales y no funcionales.

3. ADMINISTRATIVOS Actas de conformidad del servicio por parte del cliente. 4. COMERCIALES Cumplir con los acuerdos del contrato. 5. OTROS Entrega de la documentación de pruebas integrales y manuales

de usuarios de acuerdo a los formatos del cliente. REGLAS DEL NEGOCIO: REGLAS PRINCIPALES QUE FIJAN LOS PRINCIPIOS GUÍAS DE LA ORGANIZACIÓN. Se deberá realizar una reunión de carácter técnico semanalmente. Se deberá realizar una reunión de gestión quincenalmente. Presentar el informe de rendimiento quincenalmente. La gestión del proyecto se realizará de acuerdo a la Metodología de Gestión de Proyectos de La DC Consulting siguiendo el Estándar de Gestión de Proyectos del PMI. IMPACTOS EN OTRAS ÁREAS ORGANIZACIONALES El éxito del proyecto brindará nuevas oportunidades de negocio para el área comercial de LA DC CONSULTING.

IMPACTOS EN OTRAS ENTIDADES: DENTRO O FUERA DE LA ORGANIZACIÓN EJECUTANTE. Los Operadores de Comercio Exterior podrán contar con acceso a la información de estado de las sanciones a través de la web y consultar la información actualizada.


3

REQUERIMIENTOS DE SOPORTE Y ENTRENAMIENTO

Los equipos de desarrollo son de propiedad del equipo del proyecto. Se requiere un servidor de pruebas proporcionado por el cliente. Se requiere que el cliente proporcione de un ambiente de desarrollo. Se requiere que el cliente proporcione un ambiente de trabajo para los equipos del cliente. Se requiere que el cliente proporcione capacitación en los estándares del cliente.

SUPUESTOS RELATIVOS A REQUISITOS Los requerimientos no variarán una vez iniciado el proyecto. El cliente no cambiará las exigencias referidas a calidad. Se contará con la disponibilidad del ambiente de desarrollo para la ejecución del proyecto. Se contará con los recursos financieros y humanos durante todo el desarrollo del proyecto. El cambio de personal no afectará el avance del proyecto. Los cambios al alcance serán considerados como un adicional el proyecto. RESTRICCIONES RELATIVAS A REQUISITOS Toda observación deberá ser levantada en un máximo de 10 días calendarios. El pago de servicio sólo podrá ser efectuado con la firma del Acta de Conformidad del Cliente Sólo debe utilizarse las librerías del framework otorgado por el cliente. Los Ingenieros serán colegiados y estarán habilitados durante todo el tiempo de vida del proyecto. Los programadores deben tener experiencia de 03 años como mínimo en el estándar J2EE. El Project Manager debe tener experiencia de 05 años como mínimo en Gestión de Proyectos.

ESTADO ACTUAL

NIVEL DE ESTABILIDAD

GRADO DE COMPLEJIDAD

Estado

Activo Abreviatura

AC Estado

Alto Abreviatura

A Estado

Alto Abreviatura

A

Aprobado AP

Versión Hecha por

Revisada por

CONTROL DE VERSIONES Aprobada por

Fecha

Motivo

FGPR_026_04 V4

1 GL FJ JP 22/07/2011 Versión final

MATRIZ DE TRAZABILIDAD DE REQUISITOS

NOMBRE DEL PROYECTO DESARROLLO DE UN NUEVO SOFTWARE PARA OPERADORES DE COMERCIO EXTERIOR

SIGLAS DEL PROYECTO CONSOTER

Cancelado CA Mediano M Mediano M

Diferido DI Bajo B Bajo B

Adicionado AD

ATRIBUTOS DE REQUISITO TRAZABILIDAD HACIA:

CÓDIGO

DESCRIPCIÓN

SUSTENTO DE SU

INCLUSIÓN

PROPIETARIO

FUENTE

PRIORIDAD

VERSIÓN ESTADO

ACTUAL (AC,

CA, DI, AD, AP)

FECHA DE

CUMPLIMIENTO NIVEL DE

ESTABILIDAD

(A, M, B) GRADO DE

COMPLEJIDAD

(A, M, B)

CRITERIO DE

ACEPTACION

NECESIDADES,

OPORTUNIDADES,

METAS Y

OBJETIVOS DEL

OBJETIVOS DEL

PROYECTO ALCANCE DEL

PROYECTO

/ENTREGABLE DEL

WBS

DISEÑO DEL

PRODUCTO

DESARROLLO DEL

PRODUCTO

ESTRATEGIA DE

PRUEBA

ESCENARIO DE

PRUEBA

REQUERIMIENTO DE

ALTO NIVEL

REQ01

Desarrollar el módulo de mantenimiento de Operadores de

Comercio, circunscripciones, representantes y sanciones.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

M

A

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones

Desarrollo del módulo

OCE en Java según el

estándar y el

framework del cliente.

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas

proporcionado por el

cliente

Cumplimiento del

requerimiento del

cliente.

REQ02

Implementar la trazabilidad del módulo.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

M

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones

Desarrollo del módulo

OCE en Java según el

estándar y el

framework del cliente.

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ03 Entrega de manual de usuario.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

formato del cliente.

Desarrollado en

formato HTML No aplica

No aplica

Cumplimiento del

requerimiento del

cliente.

REQ04 Documentación de las pruebas de integración.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Formato de

pruebas de

integración

Documento Word

según formato. No aplica

No aplica

Cumplimiento del

requerimiento del

cliente.

REQ05

Debe permitir la impresión y exportación a Excel de todas las

consultas. EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones

Librerías

proporcionadas del

cliente.

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ06 Cumplir con los estándares de programación.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.

Desarrollo del código

de acuedo a los

estándares.

Revisión por parte

del Arquitecto de La

DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ06 El módulo debe ser una aplicación Web.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.


de acuedo a los

estándares.

Revisión por parte


DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ07

Este módulo deberá estar integrado con el conjunto de aplicación de

la Intranet del cliente. EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.


de acuedo a los

estándares.

Revisión por parte


DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ08 Cumplir con los estándares de programación.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.


de acuedo a los

estándares.

Revisión por parte


DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ09

Debe contar con esquema de seguridad integrado a la plataforma del

cliente. EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.


de acuedo a los

estándares.

Revisión por parte


DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ09 Entrega del código fuente de la aplicación desarrollada

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.


de acuedo a los

estándares.

Revisión por parte


DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ10 Entrega de procedimientos de instalación

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B

Acta de

verificación de

estándares

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

De acuerdo al

manual de

estándares del

cliente.


de acuedo a los

estándares.

Revisión por parte


DC Consulting

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ11 Mantener la confidencialidad de la información del cliente.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

B No aplica

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos Según contrato.

No aplica

No aplica

No aplica

Cumplimiento del

requerimiento del

cliente.

REQ12 El sistema debe poder ejecutarse en cualquier navegador.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

M

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones

Realizar las pruebas de

concurrencia

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ13 Soporte multiusuario y de conexiones concurrentes.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

M

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones


concurrencia

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ14

Documentación de las pruebas unitarias y de integración de los

módulos desarrollados. EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

M

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones


concurrencia

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.

REQ15

El proyecto debe ser rentable y llevarse a cabo en el tiempo

establecido. LA DC CONSULTING

LA DC CONSULTING

CONTRATO

ALTA

1.0

AC

15/12/2009

A

A

Informe de cierre

del proyecto

Obtener ingresos

y/o

posicionamiento

en el mercado

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Informe de

rentabilidad de la

DC Consulting.

Monitoreo del

rendimiento del

proyecto. No aplica

No aplica

Cumplimiento del

requerimiento del

cliente.

REQ16 Cumplir con los estándares de programación del cliente.

EL CLIENTE

EL CLIENTE

CONTRATO

ALTA

1.0

AC

15/12/2009

A

M

Acta de

conformidad

Satisfacción del

cliente

Cumplir con el

alcance del

proyecto

Plan de Gestión

de Proyectos

Documento de

especificaciones


concurrencia

Elaborar pruebas

unitarias y de

integración.

Ambiente de pruebas


cliente

Cumplimiento del

requerimiento del

cliente.




1.0 JP FJ JP 27/06/2011 Versión Inicial

2.0 JP FJ JP 20/07/2011 Versión final

WWBBSS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

DESARROLLO DE UN NUEVO SOFTWARE PARA CONSOTER

OPERADORES DE COMERCIO EXTERIOR










1.0 GL FJ JP 27/06/2011 Versión Inicial

2.0 GL FJ JP 27/06/2011 Versión final

DDIICCCCIIOONNAARRIIOO WWBBSS ((ssiimmpplliiffiiccaaddoo))

SIGLAS DEL PROYECTO NOMBRE DEL PROYECTO



CONSOTER

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.

Entregable 1:

Gestión del Proyecto

1.1 Iniciación

1.1.1 Project Charter

Documento que detalla la definición del proyecto y producto, finalidad y justificación del proyecto, principales hitos, supuestos, restricciones y oportunidades del proyecto.

1.1.2 Registro y Estrategia de StakeHolders

Documento que detalla los stakeholders y la estrategia a utilizar con cada uno.

1.2 Planificación

1.2.1 Sentencia de

Alcance

Documento que establece el trabajo que debe realizarse y los productos entregables que deben producirse.

1.2.2 EDT Estructura de Desglose del trabajo, con los principales entregables del proyecto organizados de manera jerárquica.

1.2.3 Plan de


Documento formalmente aprobado que define como se ejecuta, supervisa y controla el proyecto. Contiene el cronograma, el presupuesto, línea base de calidad, organización del proyecto, RAM, Plan de gestión de RRHH, Plan de gestión de Comunicaciones, Plan de gestión de riesgos.

1.3 Informes de Estado del Proyecto

Documento que informará el estado del avance de cada entregable del proyecto, en cuanto a tiempo, costo, alcance y calidad. El informe se emitirá semanalmente.

1.4 Reuniones de Coordinación

1.4.1 Reunión Técnica Semanal con el Cliente

Reunión con el analista de sistemas de El Cliente, para solucionar inconvenientes de carácter técnico.

1.4.2 Reunión de Gestión Semanal con el Cliente

Reunión con el analista de sistemas de El Cliente, el Supervisor del El Cliente, el Project manager de La DC Consulting y opcionalmente el gerente de proyectos de TI de la DC Consulting, para informar el avance del proyecto y solucionar inconvenientes de tipo administrativo, logístico, cumplimientos de objetivos.





1.4.3 Reunión quincenal con el equipo de gestión del Proyecto.

Reunión del Project Manager con el Gerente de TI y Gerente General de la DC Consulting, para coordinar e informar el cumplimiento de objetivos, desempeño del personal, requerimientos para mejorar el desempeño

1.5 Cierre del Proyecto

Reunión con el equipo del proyecto donde el Project Manager deberá presentar: - Informe de Performance del proyecto. - Lecciones aprendidas del proyecto. - Métricas del proyecto. - Acta de Aceptación del proyecto. - Archivo final del proyecto.

Entregable 2:

Operadores de Comercio

2.1 Registro y Modificación de

Operador

Opción del software que permite el registro y modificación de los datos de los operadores de comercio exterior, tales como clase de operador, código aduanero, RUC, nombre comercial, razón social, actividad principal, actividades secundarias, contactos administrativos, vigencia, circunscripción principal.

2.2 Consulta de Operador

2.2.1 Consulta de Operador

Consulta de operadores de comercio exterior por diferentes criterios, tales como clase de operador, código aduanero, RUC, nombre comercial, razón social, actividad principal.

2.2.2 Exportación a PDF y Excel

Documento en formato PDF o EXCEL conteniendo los criterios utilizados y el resultado de la consulta.

2.3 Cambio de Estado de Operador

Opción del software que permite cambiar el estado del Operador de Comercio Exterior.

2.4 Documentación

2.4.1 Pruebas Unitarias

Documento con las pruebas realizadas acerca del registro, modificación, consulta y cambio de estado de operadores de comercio. Debe documentarse la prueba funcional así como las sentencias SQL utilizadas.

2.4.2 Manual de Usuario

Manual de Usuario en formato HTML del registro, modificación, consulta y cambio de estado de operadores de comercio exterior.

Entregable 3:

Circunscripciones

3.1 Asignación de Operador a

Circunscripciones

Opción del software que permite el registro y modificación de las circunscripciones en las que un operador de comercio está permitido de realizar sus actividades.


Local por Circunscripción

Opción del software que permite registrar y modificar los locales del operador de comercio en cada una de las circunscripciones en las que tiene permitido operar.

3.3 Consulta de Locales

3.3.1 Consulta de

Locales

Consulta de locales por diferentes criterios como operador de comercio, circunscripción y ubicación geográfica.



3.4 Cambio de Estado de Local

Opción del software que permite cambiar el estado del local del Operador de Comercio Exterior.





3.5 Documentación


Documento con las pruebas realizadas acerca del registro, modificación, consulta y cambio de estado de los locales de los operadores de comercio. Debe documentarse la prueba funcional así como las sentencias SQL utilizadas.


Manual de Usuario en formato HTML del registro, modificación, consulta y cambio de estado de los locales de los operadores de comercio exterior.

Entregable 4:

Representantes

4.1 Registro de y Modificación de Representante

Opción del software que permite registrar y modificar los datos de los representantes de los operadores de comercio exterior, entre los cuales están sus nombres, apellidos, firma y foto.

4.2 Consulta de Representante

4.2.1 Consulta de

Representante

Consulta de representantes por diferentes criterios como operador de comercio, nombres y apellidos.



4.3 Cambio de Estado

Representante

Opción del software que permite cambiar el estado del representante del Operador de Comercio Exterior.

4.4 Documentación


Documento con las pruebas realizadas acerca del registro, modificación, consulta y cambio de estado de los representantes de los operadores de comercio. Debe documentarse la prueba funcional así como las sentencias SQL utilizadas.


Manual de Usuario en formato HTML del registro, modificación, consulta y cambio de estado de los representantes de los operadores de comercio exterior.

Entregable 5:

Sanciones

5.1 Registro de Sanciones y

Seguimientos

Opción del software que permite registrar las sanciones y su seguimiento (cambios de estado, apelaciones, motivo) de los operadores de comercio exterior, pudiendo aplicar total o parcialmente a sus circunscripciones.

5.2 Consulta Sanciones por

Operador

5.2.1 Consulta de Sanciones.

Consulta de sanciones y sus seguimientos por diferentes criterios tales como acción realizada, fecha de sanción y motivo de la sanción o el seguimiento.

5.2.2 Exportación a PDF y Excel.


5.3 Documentación


Documento con las pruebas realizadas acerca de las sanciones y seguimientos de los operadores de comercio. Debe documentarse la prueba funcional así como las sentencias SQL utilizadas.


Manual de Usuario en formato HTML del registro, seguimiento y consulta de las sanciones de los operadores de comercio exterior.





Levantamiento de

Entregable 6:

Entregables Finales

6.1 Pruebas de Integración

Documento con las pruebas realizadas con la todas las funcionalidades integradas (operadores de comercio, circunscripciones, representantes y sanciones). Debe documentarse la prueba funcional así como las sentencias SQL utilizadas. Debe contemplar toda la casuística.

6.2 Revisión de Estándares

Documento con la validación de los estándares utilizados en la construcción del software.

6.3 Documentación

Entrega

Carta de entrega al cliente, cd conteniendo las pruebas de integración, manuales, código fuente, respuesta a observaciones.

Entregable 7:

Observaciones

7.1 Actualización de las pruebas de

Integración

Actualización de las pruebas de integración luego de haberse subsanado las observaciones.

7.2 Documentación

Entrega

Carta de entrega al cliente, cd conteniendo las pruebas de integración, manuales, código fuente, respuesta a observaciones.

CONTROL DE VERSIONES Versión Hecha por Revisada por Aprobada por Fecha Motivo

1.0 GL

FJ 29/06/2011 Versión Original 2.0 GL

FJ 19/07/2011 Versión Actualizada

Identificación y Secuenciamiento de Actividades

Proyecto de Desarrollo de un Nuevo Software Para

Operadores De Comercio Exterior

Paquete de Trabajo Actividad de Trabajo Actividad Restricciones o Fecha Persona Zona Tipo de

Código WBS Nombre Código Nombre Alcance de Trabajo de la Actividad Predecesora Supuestos Impuesta Responsable Geográfica Actividad 1.1.1.2 Project Charter 1.1.1.2.1

1.1.1.2.2

1.1.1.2.3

1.1.1.2.4

Reunión con el sponsor

Elaborar Project Charter

Revisar Project Charter

Aprobar Project Charter


Elaborar Project Charter

Revisar Project Charter

Aprobar Project Charter

1.1.1.2.1

1.1.1.2.2

1.1.1.2.3

GL

GL

GL

GL

1.1.2.1 Scope Statement 1.1.2.1.1

1.1.2.1.2

1.1.2.1.3

1.1.2.1.4


Elaborar el Scope Statement

Revisar el Scope Statement

Aprobar el Scope Statement


Elaborar el Scope Statement

Revisar el Scope Statement

Aprobar el Scope Statement

1.1.2.1.1

1.1.2.1.2

1.1.2.1.3

GL

GL

GL

GL

1.1.2.2 Plan de Gestión del Proyecto 1.1.2.2.1

1.1.2.2.2

1.1.2.2.3

1.1.2.2.4

Reunión con el equipo del proyecto

Elaborar el Plan de Gestión del Proyecto

Revisión del Plan de Gestión del Proyecto

Aprobar el Plan de Gestión del Proyecto

Reunión con el equipo del proyecto

Elaborar el Plan de Gestión del Proyecto

Revisión del Plan de Gestión del Proyecto

Aprobar el Plan de Gestión del Proyecto

1.1.2.2.1

1.1.2.2.2

1.1.2.2.3

AT,DZ,GL,JV,PP,P

GL

GL

GL

V,WG

1.1.3.1 Contratación de Personal 1.1.3.1.1

1.1.3.1.2

1.1.3.1.3

Realizar la convocatoria

Realizar proceso de selección

Negociar contratación

Realizar la convocatoria

Realizar proceso de selección

Negociar contratación

GL

GL

GL 1.1.3.1.1[FC+5 días]

1.1.3.1.2 1.1.3.2 Capacitación del equipo en los estándares del cliente 1.1.3.2.1 Asistir a la capacitación en los estándares del cliente Asistir a la capacitación en los estándars del cliente

AT,DZ,GL,JV,PP,PV,WG

1.1.3.3 Informes de Desempeño Semanal 1.1.3.3 Informes de Desempeño Semanal Informes de Desempeño Semanal

GL 1.1.3.4 Monitoreo y Control de Cambios 1.1.3.4 Monitoreo y Control de Cambios Monitoreo y Control de Cambios

GL

1.1.3.5 Reuniones de Coordinación 1.1.3.5.1

1.1.3.5.2

1.1.3.5.3

Reunión Técnica Semanal con el Cliente

Reunión De Gestión Semanal con el cliente

Reunión Semanal con el equipo de Gestión del Proyecto

Reunión Técnica Semanal con el Cliente

Reunión De Gestión Semanal con el cliente

Reunión Semanal con el equipo de Gestión del Proyecto

GL

GL

GL

1.1.4 Cierre del Proyecto 1.1.4.1

1.1.4.2

1.1.4.3

Desarrollar taller de lecciones aprendidas

Elaborar informe final del proyecto

Cierre del Proyecto

Desarrollar taller de lecciones aprendidas

Elaborar informe final del proyecto

Cierre del Proyecto

1.1.4.1

1.1.4.2

GL,AT,DZ,JV,PP,P

GL

GL

V,WG

1.2.1 Registro y Modificación de Operador 1.2.1.1

1.2.1.2

1.2.1.3

1.2.1.4

1.2.1.5

1.2.1.6

1.2.1.7

Revisar la especificación

Preparar casos de pruebas

Construir el software

Ejecutar casos de prueba unitaria

Documentar prueba unitaria

Revisión de estándares

Aprobación del Project Manager








1.2.1.1

1.2.1.2

1.2.1.3

1.2.1.4

1.2.1.5

1.2.1.6

DZ

DZ

DZ

DZ

DZ

WG

GL

1.2.2 Consulta de Operador 1.2.2.1

1.2.2.2

1.2.2.3

1.2.2.4

1.2.2.5

1.2.2.6

1.2.2.7

1.2.2.8



Construir la consulta

Construir exportación de consulta a PDF y Excel













1.2.2.1

1.2.2.2

1.2.2.3

1.2.2.4

1.2.2.5

1.2.2.6

1.2.2.7

DZ

DZ

DZ

DZ

DZ

DZ

WG

GL

1.2.3 Cambio de Estado de Operador 1.2.3.1

1.2.3.2

1.2.3.3

1.2.3.4

1.2.3.5

1.2.3.6

1.2.3.7















1.2.3.1

1.2.3.2

1.2.3.3

1.2.3.4

1.2.3.5

1.2.3.6

DZ

DZ

DZ

DZ

DZ

WG

GL

1.2.4 Documentación 1.2.4.1

1.2.4.2

1.2.4.3

Elaborar Manual de Usuario






1.2.4.1

1.2.4.2

JV

WG

GL

1.3.1 Asignación de Operador a Circunscripciones 1.3.1.1

1.3.1.2

1.3.1.3

1.3.1.4

1.3.1.5

1.3.1.6

1.3.1.7















1.3.1.1

1.3.1.2

1.3.1.3

1.3.1.4

1.3.1.5

1.3.1.6

AT

AT

AT

AT

AT

WG

GL

1.3.2 Registro y Modificación de Local por Circunscripción 1.3.2.1

1.3.2.2

1.3.2.3







1.3.2.1

1.3.2.2

AT

AT

AT

1.3.2.4

1.3.2.5

1.3.2.6

1.3.2.7









1.3.2.3

1.3.2.4

1.3.2.5

1.3.2.6

AT

AT

WG

GL

1.3.3 Consulta de Locales 1.3.3.1

1.3.3.2

1.3.3.3

1.3.3.4

1.3.3.5

1.3.3.6

1.3.3.7

1.3.3.8

















1.3.3.1

1.3.3.2

1.3.3.3

1.3.3.4

1.3.3.5

1.3.3.6

1.3.3.7

AT

AT

AT

AT

AT

AT

WG

GL

1.3.4 Cambio de Estado de Local 1.3.4.1

1.3.4.2

1.3.4.3

1.3.4.4

1.3.4.5

1.3.4.6

1.3.4.7















1.3.4.1

1.3.4.2

1.3.4.3

1.3.4.4

1.3.4.5

1.3.4.6

AT

AT

AT

AT

AT

WG

GL


1.3.5.2

1.3.5.3







1.3.5.1

1.3.5.2

JV

WG

GL

1.4.1 Registro de y Modificación de Representante 1.4.1.1

1.4.1.2

1.4.1.3

1.4.1.4

1.4.1.5

1.4.1.6

1.4.1.7

1.4.1.8

1.4.1.9



















1.4.1.1

1.4.1.2

1.4.1.3

1.4.1.4

1.4.1.5

1.4.1.6

1.4.1.7

1.4.1.8

PP

PP

PP

PP

PP

WG

GL

WG

GL

1.4.2 Consulta de Representante 1.4.2.1

1.4.2.2

1.4.2.3

1.4.2.4

1.4.2.5

1.4.2.6

1.4.2.7

1.4.2.8

















1.4.2.1

1.4.2.2

1.4.2.3

1.4.2.4

1.4.2.5

1.4.2.6

1.4.2.7

PP

PP

PP

PP

PP

PP

WG

GL

1.4.3 Cambio de Estado Representante 1.4.3.1

1.4.3.2

1.4.3.3

1.4.3.4

1.4.3.5

1.4.3.6

1.4.3.7















1.4.3.1

1.4.3.2

1.4.3.3

1.4.3.4

1.4.3.5

1.4.3.6

PP

PP

PP

PP

PP

WG

GL


1.4.4.2

1.4.4.3

Manual de Usuario Revisión de

estándares Aprobación del

Project Manager



Project Manager

1.4.4.1

1.4.4.2

JV

WG

GL

1.5.1 Registro de Sanciones y Seguimientos 1.5.1.1

1.5.1.2

1.5.1.3

1.5.1.4

1.5.1.5

1.5.1.6

1.5.1.7















1.5.1.1

1.5.1.2

1.5.1.3

1.5.1.4

1.5.1.5

1.5.1.6

PV

PV

PV

PV

PV

WG

GL

1.5.2 Consulta Sanciones por Operador 1.5.2.1

1.5.2.2

1.5.2.3

1.5.2.4

1.5.2.5

1.5.2.6

1.5.2.7

1.5.2.8

















1.5.2.1

1.5.2.2

1.5.2.3

1.5.2.4

1.5.2.5

1.5.2.6

1.5.2.7

PV

PV

PV

PV

PV

PV

WG

GL


1.5.3.2

1.5.3.3



Project Manager



Project Manager

1.5.3.1

1.5.3.2

JV

WG

GL

1.6.1 Pruebas de Integración 1.6.1.1

1.6.1.2

1.6.1.3

1.6.1.4

Diseñar la prueba

Ejecutar la prueba

Elaborar informe de prueba de integración


Diseñar la prueba

Ejecutar la prueba

Elaborar informe de prueba de integración


1.6.1.1

1.6.1.2

1.6.1.3

JV

JV

JV

GL

1.6.2 Revisión de Estándares 1.6.2.1

1.6.2.2

1.6.2.3

Verificar código de programación

Ajustar código

Verificar código de programación conjuntamente con el Analista d

Verificar código de programación

Ajustar código

Verificar código de programación conjuntamente con el Analista d

1.6.2.1

1.6.2.2

WG

PV,PP,DZ,AT

PV

1.6.3 Documentación Entrega 1.6.3.1

1.6.3.2

1.6.3.3

1.6.3.4

Preparar el CD con código fuente, pruebas unitarias y manual de u

Elaborar documento de pase a producción

Elaborar Carta de Entrega e Informe


Preparar el CD con código fuente, pruebas unitarias y manual de us

Elaborar documento de pase a producción

Elaborar Carta de Entrega e Informe


uario

1.6.3.1

1.6.3.2

1.6.3.3

JV

JV

JV

GL

1.7 Levantamiento de Observaciones 1.7.1

1.7.2

1.7.3

1.7.4

Revisar Informe de observaciones

Ajustar el código

Actualizar documentación de entrega

Presentación de entregables finales

Revisar Informe de observaciones

Ajustar el código

Actualizar documentación de entrega

Presentación de entregables finales

1.7.1

1.7.2

1.7.3

GL

PP

GL

1.6.2.4 Ajustar código Ajustar código 1.6.2.3 PV,PP,DZ,AT




1.0 GL FJ 29/06/2011 Versión Original

2.0 GL FJ 19/07/2011 Versión Actualizada

RREEDD DDEELL PPRROOYYEECCTTOO




2.0

1.0

3.0

6.0 7.0

4.0

5.0


Dharma Consulting ha sido revisada y aprobada como un proveedor de entrenamiento en Project Management por el Project Management Institute (PMI). Como un Registered Education Provider (R.E.P.) del PMI, Dharma Consulting ha aceptado regirse por los criterios establecidos de aseguramiento de calidad del PMI.







2.0 GL FJ 19/07/2011 Versión actualizada

CCRROONNOOGGRRAAMMAA DDEELL PPRROOYYEECCTTOO


DESARROLLO DE UN NUEVO SOFTWARE PARA OPERADORES DE COMERCIO EXTERIOR CONSOTER

1.0 GL

FJ 29/06/2011 Vers i ón Ori gi na l

Nombre del

Nombre del

Nombre del

Nombre del

1.1.1.2.2

1.1.1.2.3 Elaborar Project Charter

Revisar Project Charter GL

GL HH

HH 8 horas

2 horas S/. 227.27

S/. 56.82

1.1.2.1.2

1.1.2.1.3 Elaborar el Scope Statement

Revisar el Scope Statement GL

GL HH

HH 8 horas

2 horas S/. 227.27

S/. 56.82

1.1.2.2.2

1.1.2.2.3 Elaborar el Plan de Gestión del Proyecto

Revisión del Plan de Gestión del Proyecto GL

GL HH

HH 16 horas

2 horas S/. 454.55

S/. 56.82

1.1.3.1.2

1.1.3.1.3 Realizar proceso de selección

Negociar contratación GL

GL HH

HH 24 horas

8 horas S/. 681.82

S/. 227.27 Informes de Desempeño Se 1.1.3.3 Informes de Desempeño Semanal GL HH 360 horas ############

Reunión Técnica Semanal c 1.1.3.5.1 Reunión Técnica Semanal con el Cliente GL HH 1 hora S/. 28.41

1.1.4.2 Elaborar informe final del proyecto GL HH 16 horas S/. 454.55

1.2.1.2

1.2.1.3

1.2.1.4

1.2.1.5

1.2.1.6






DZ

DZ

DZ

DZ

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82

1.2.2.2

1.2.2.3

1.2.2.4

1.2.2.5

1.2.2.6

1.2.2.7







DZ

DZ

DZ

DZ

DZ

WG

HH

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 681.82

S/. 545.45

S/. 181.82

1.2.3.2

1.2.3.3

1.2.3.4

1.2.3.5

1.2.3.6






DZ

DZ

DZ

DZ

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82

1.2.4.2 Revisión de estándares WG HH 8 horas S/. 181.82

1.3.1.2

1.3.1.3

1.3.1.4

1.3.1.5

1.3.1.6






AT

AT

AT

AT

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82

1.3.2.2

1.3.2.3

1.3.2.4

1.3.2.5

1.3.2.6






AT

AT

AT

AT

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82

1.3.3.2

1.3.3.3

1.3.3.4

1.3.3.5

1.3.3.6

1.3.3.7







AT

AT

AT

AT

AT

WG

HH

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 681.82

S/. 545.45

S/. 181.82

1.3.4.2

1.3.4.3

1.3.4.4

1.3.4.5

1.3.4.6






AT

AT

AT

AT

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82


1.4.1.2

1.4.1.3

1.4.1.4

1.4.1.5

1.4.1.6

1.4.1.7

1.4.1.8








PP

PP

PP

PP

WG

GL

WG

HH

HH

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

0 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82

S/. 0.00

S/. 181.82

1.4.2.2

1.4.2.3

1.4.2.4

1.4.2.5

1.4.2.6

1.4.2.7







PP

PP

PP

PP

PP

WG

HH

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 681.82

S/. 545.45

S/. 181.82

1.4.3.2

1.4.3.3

1.4.3.4

1.4.3.5

1.4.3.6






PP

PP

PP

PP

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82


1.5.1.2

1.5.1.3

1.5.1.4

1.5.1.5

1.5.1.6






PV

PV

PV

PV

WG

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 545.45

S/. 181.82

1.5.2.2

1.5.2.3

1.5.2.4

1.5.2.5

1.5.2.6

1.5.2.7







PV

PV

PV

PV

PV

WG

HH

HH

HH

HH

HH

HH

16 horas

160 horas

40 horas

40 horas

32 horas

8 horas

S/. 272.73

S/. 2,727.27

S/. 681.82

S/. 681.82

S/. 545.45

S/. 181.82

1.5.3.2

1.5.3.3 Revisión de estándares

Aprobación del Project Manager WG

GL HH

HH 8 horas

0 horas S/. 181.82

S/. 0.00

1.6.1.2

1.6.1.3 Ejecutar la prueba

Elaborar informe de prueba de integración JV

JV HH

HH 96 horas

24 horas S/. 818.18

S/. 204.55

1.6.2.2

1.6.2.3 Ajustar código

Verificar código de programación conjuntamente con el Analist PV,PP,DZ,AT

PV HH

HH 32 horas

0.8 horas S/. 545.45

S/. 13.64

1.6.3.2

1.6.3.3 Elaborar documento de pase a producción

Elaborar Carta de Entrega e Informe JV

JV HH

HH 16 horas

4 horas S/. 136.36

S/. 34.09

1.7.2

1.7.3 Ajustar el código

Actualizar documentación de entrega PP

GL HH

HH 136 horas

24 horas S/. 2,318.18

S/. 681.82


2.0 GL FJ 19/07/2011 V ers ión Actua l i za da

Costeo del Proyecto

Proyecto de Desarrollo de un Nuevo Software para Operadores De Comercio Exterior

Entrregable Id Tarea Recurso Unidad Cantidad Costo Total Recurso Unidad Cantidad Costo Total Recurso Unidad Cantidad Costo Total Recurso Unidad Cantidad Costo Total

Project Charter 1.1.1.2.1 Reunión con el sponsor HH 2 horas S/. 56.82

1.1.1.2.4 Aprobar Project Charter GL HH 0 horas S/. 0.00

1.1.2.1.4 Aprobar el Scope Statement GL HH 0 horas S/. 0.00

Plan de Gestión del Proyect 1.1.2.2.1 Reunión con el equipo del proyecto AT,DZ,GL,JV, HH 14 horas S/. 255.68

1.1.2.2.4 Aprobar el Plan de Gestión del Proyecto GL HH 0 horas S/. 0.00

Contratación de Personal 1.1.3.1.1 Realizar la convocatoria GL HH 8 horas S/. 227.27

Capacitación del equipo en 1.1.3.2.1 Asistir a la capacitación en los estándars del cliente AT,DZ,GL,JV, HH 112 horas S/. 2,045.45

Monitoreo y Control de Ca 1.1.3.4 Monitoreo y Control de Cambios GL HH 360 horas ############

Reunión De Gestión Seman 1.1.3.5.2 Reunión De Gestión Semanal con el cliente GL HH 45 horas S/. 1,278.41

Reunión Semanal con el eq 1.1.3.5.3 Reunión Semanal con el equipo de Gestión del Proyecto GL HH 45 horas S/. 1,278.41

Cierre del Proyecto 1.1.4.1 Desarrollar taller de lecciones aprendidas GL,AT,DZ,JV, HH 8 horas S/. 146.10

1.1.4.3 Cierre del Proyecto GL HH 0 horas S/. 0.00

Registro y Modificación de 1.2.1.1 Revisar la especificación DZ HH 24 horas S/. 409.09

1.2.1.7 Aprobación del Project Manager GL HH 0 horas S/. 0.00

Consulta de Operador 1.2.2.1 Revisar la especificación DZ HH 24 horas S/. 409.09


Cambio de Estado de Oper 1.2.3.1 Revisar la especificación DZ HH 24 horas S/. 409.09


Documentación 1.2.4.1 Elaborar Manual de Usuario JV HH 40 horas S/. 340.91


Asignación de Operador a C 1.3.1.1 Revisar la especificación AT HH 24 horas S/. 409.09


Registro y Modificación de 1.3.2.1 Revisar la especificación AT HH 24 horas S/. 409.09


Consulta de Locales 1.3.3.1 Revisar la especificación AT HH 24 horas S/. 409.09


Cambio de Estado de Local 1.3.4.1 Revisar la especificación AT HH 24 horas S/. 409.09


Documentación 1.3.5.1 Elaborar Manual de Usuario JV HH 40 horas S/. 340.91


Registro de y Modificación 1.4.1.1 Revisar la especificación PP HH 24 horas S/. 409.09


Consulta de Representante 1.4.2.1 Revisar la especificación PP HH 24 horas S/. 409.09


Cambio de Estado Represen 1.4.3.1 Revisar la especificación PP HH 24 horas S/. 409.09


Documentación 1.4.4.1 Manual de Usuario JV HH 40 horas S/. 340.91


Registro de Sanciones y Se 1.5.1.1 Revisar la especificación PV HH 24 horas S/. 409.09


Consulta Sanciones por Op 1.5.2.1 Revisar la especificación PV HH 24 horas S/. 409.09


Documentación 1.5.3.1 Manual de Usuario JV HH 40 horas S/. 340.91

1.5.4 Entrega de módulo de Sanciones HH 0 horas S/. 0.00

Entregables Finales 1.6.1.1 Diseñar la prueba JV HH 40 horas S/. 340.91


Revisión de Estándares 1.6.2.1 Verificar código de programación WG HH 24 horas S/. 545.45

1.6.2.4 Ajustar código PV,PP,DZ,AT HH 16 horas S/. 272.73

Documentación Entrega 1.6.3.1 Preparar el CD con código fuente, pruebas unitarias y manual d JV HH 4 horas S/. 34.09


Levantamiento de Observa 1.7.1 Revisar Informe de observaciones GL HH 16 horas S/. 454.55

1.7.4 Presentación de entregables finales GL HH 0 horas S/. 0.00



1.0 GL

FJ 19/07/2011 Versión Original

Proyecto de Desarrollo de un Nuevo Software para


Presupuesto del Proyecto (Por Fase y Entregables)

Proyecto Fase Entregable Monto (S/.)

Proyecto de Desarrollo

de un Nuevo Software

para Operadores de

Comercio Exterior


Inicio S/. 340.91

S/. 29,492.69

S/. 15,659.09

S/. 20,477.27

S/. 15,840.91

S/. 10,840.91

S/. 2,945.45

S/. 3,454.55

Planificación S/. 1,107.95

Ejecución S/. 27,443.18

Cierre S/. 600.65

Total Fase

Operadores de

Comercio

Registro y modificación del Operador S/. 4,818.18

Consulta de Operador S/. 5,500.00 Cambio de Estado de Operador S/. 4,818.18

Documentación S/. 522.73

Total Fase

Circunscripciones

Asignación de Operador a Circunscripciones S/. 4,818.18

Registro y Modificación de Local por Circunscripción S/. 4,818.18

Consulta de Locales S/. 5,500.00

Cambio de Estado de Local S/. 4,818.18


Total Fase

Representantes

Registro de y Modificación de Representante S/. 5,000.00

Consulta de Representante S/. 5,500.00

Cambio de Estado Representante S/. 4,818.18


Total Fase

Sanciones Registro de Sanciones y Seguimientos S/. 4,818.18

Consulta Sanciones por Operador S/. 5,500.00


Total Fase

Entregables Finales Pruebas de Integración S/. 1,363.64

Revisión de Estándares S/. 1,377.27

Documentación Entrega S/. 204.55

Total Fase

Levantamiento de

Observaciones

S/. 3,454.55

Total Fase

Total Fases S/. 98,710.88 Reserva de Contingencia S/. 9,871.09

Reserva de Gestión S/. 9,871.09

Presupuesto del Proyecto S/. 118,453.05




Proyecto de Desarrollo de un Nuevo Software para


Presupuesto del Proyecto (Por Semana)

Proyecto Semana Costo (S/.)

Costo Acumulado por

Semana nº por Semana

DESARROLLO DE UN

NUEVO SOFTWARE

PARA OPERADORES

DE COMERCIO

EXTERIOR

Semana 01 1221.59 S/. 1,221.59

Semana 02 4642.05 S/. 5,863.64

Semana 03 3948.86 S/. 9,812.50

Semana 04 3494.32 S/. 13,306.82

Semana 05 2176.14 S/. 15,482.95

Semana 06 3267.05 S/. 18,750.00

Semana 07 3267.05 S/. 22,017.05

Semana 08 3267.05 S/. 25,284.09

Semana 09 3448.86 S/. 28,732.95

Semana 10 3312.5 S/. 32,045.45

Semana 11 3267.05 S/. 35,312.50

Semana 12 3267.05 S/. 38,579.55

Semana 13 3267.05 S/. 41,113.64

Semana 14 3267.05 S/. 47,835.23

Semana 15 2721.59 S/. 51,102.27

Semana 16 3267.05 S/. 54,369.32

Semana 17 3312.5 S/. 57,545.45

Semana 18 3130.68 S/. 60,380.68

Semana 19 2585.23 S/. 62,965.91

Semana 20 2585.23 S/. 65,551.14

Semana 21 2585.23 S/. 68,136.36

Semana 22 2585.23 S/. 70,721.59

Semana 23 2585.23 S/. 72,897.73

Semana 24 2176.14 S/. 75,278.41

Semana 25 2380.68 S/. 76,295.45

Semana 26 1017.05 S/. 77,426.14

Semana 27 1130.68 S/. 79,102.27

Semana 28 1676.14 S/. 80,323.86

Semana 29 1221.59 S/. 81,545.45

Semana 30 1221.59 S/. 82,767.05

Semana 31 1221.59 S/. 83,988.64

Semana 32 1221.59 S/. 84,982.95

Semana 33 994.32 S/. 85,977.27

Semana 34 994.32 S/. 86,857.95

Semana 35 880.68 S/. 87,738.64

Semana 36 880.68 S/. 88,619.32

Semana 37 1221.59 S/. 89,840.91

Semana 38 1085.23 S/. 90,926.14

Semana 39 371.59 S/. 91,297.73

Semana 40 1653.41 S/. 92,951.14

Semana 41 1221.59 S/. 94,172.73

Semana 42 1221.59 S/. 95,394.32

Semana 43 1221.59 S/. 96,615.91

Semana 44 1494.32 S/. 98,110.23

Semana 45 600.65 S/. 98,710.88

Total Semanas S/. 98,710.88

Reserva de Contingencia Reserva de Gestión

PRESUPUESTO TOTAL DEL PROYECTO




1.0 FJ JP 21/07/2011 Versión original

PPRREESSUUPPUUEESSTTOO EENN EELL TTIIEEMMPPOO ((CCuurrvvaa SS)) NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO









1.0 JP,LC FJ JP 30/06/2011 Versión inicial

2.0 JP,LC FJ JP 20/07/2011 Versión final

PPLLAANNTTIILLLLAA DDEE MMÉÉTTRRIICCAA DDEE CCAALLIIDDAADD




MÉTRICA DE:

PRODUCTO PROYECTO X

FACTOR DE CALIDAD RELEVANTE: ESPECIFICAR CUÁL ES EL FACTOR DE CALIDAD RELEVANTE QUE DA ORIGEN A LA MÉTRICA.

Cantidad de requisitos con observaciones que originen solicitudes de cambio

DEFINICIÓN DEL FACTOR DE CALIDAD: DEFINIR EL FACTOR DE CALIDAD INVOLUCRADO EN LA MÉTRICA Y ESPECIFICAR PORQUÉ ES RELEVANTE.

Es relevante porque una cantidad muy grande de solicitudes de cambio podría afectar la disponibilidad de recursos comprometidos para otros proyectos, originando retrasos e incumplimiento de plazos a nivel contractual.

Las observaciones que originen cambios podrían alterar la línea base que el proyecto podría requerir replanificaciòn lo que podría afectar seriamente la rentabilidad de todo el contrato.

El cambio de alcance podría retrasar la entrega del producto y por ende afectara seriamente el flujo de caja

PROPÓSITO DE LA MÉTRICA: ESPECIFICAR PARA QUÉ SE DESARROLLA LA MÉTRICA?

La métrica se desarrolla para monitorear la calidad en la definición del alcance del proyecto, de manera que se pueda tomar las acciones correctivas de manera oportuna

DEFINICIÓN OPERACIONAL: DEFINIR COMO OPERARÁ LA MÉTRICA, ESPECIFICANDO EL QUIÉN, QUÉ, CUÁNDO, DÓNDE, CÓMO?

El Project manager actualizará la métrica de cantidad de observaciones a la funcionalidad que originen solicitud de cambios, después de haber recibido las observaciones del cliente. Esta métrica estará disponible para el proyecto y para otros proyectos.

MÉTODO DE MEDICIÓN: DEFINIR LOS PASOS Y CONSIDERACIONES PARA EFECTUAR LA MEDICIÓN.

Se recabara la información de cantidad de requisitos con observaciones que originen solicitudes de cambio al final de la fase de pruebas funcionales. Es un conteo de observaciones.

La métrica será presentada en el informe de control de ejecución y se actualizaran en cada iteración observaciones-cambios.

ICRF= RF con cambios/Total RF

RESULTADO DESEADO: ESPECIFICAR CUÁL ES EL OBJETIVO DE CALIDAD O RESULTADO DESEADO PARA LA MÉTRICA.

La cantidad de requisitos con observaciones que originen solicitudes de cambio debe ser menor al 10% del total de requerimientos funcionales y no funcionales.

ICRF menor al 10%

ENLACE CON OBJETIVOS ORGANIZACIONALES: ESPECIFICAR CÓMO SE ENLAZA LA MÉTRICA Y EL FACTOR DE CALIDAD RELEVANTE CON LOS OBJETIVOS DE LA ORGANIZACIÓN.

El cumplimiento de esta métrica es indispensable para poder cumplir con los objetivos del contrato y lograr productos de alta calidad.

RESPONSABLE DEL FACTOR DE CALIDAD: DEFINIR QUIÉN ES LA PERSONA RESPONSABLE DE VIGILAR EL FACTOR DE CALIDAD, LOS RESULTADOS DE LA MÉTRICA, Y DE PROMOVER LAS MEJORAS DE PROCESOS QUE SEAN





2

NECESARIAS. En primera instancia el encargado de vigilar el factor de calidad es el Project manager, quien deberá tomar las medidas que sean necesarias para lograr el objetivo de calidad planteado.

La responsabilidad última de lograr el buen manejo del alcance del proyecto es del Sponsor

MÉTRICA DE:

PRODUCTO X PROYECTO


Cantidad de horas-hombre consumidas en re-trabajos

DEFINICIÓN DEL FACTOR DE CALIDAD: DEFINIR EL FACTOR DE CALIDAD INVOLUCRADO EN LA MÉTRICA Y ESPECIFICAR PORQUÉ ES RELEVANTE. Es relevante porque una cantidad muy grande de horas-hombre gastadas en re-trabajos afectara negativamente la rentabilidad del proyecto.

PROPÓSITO DE LA MÉTRICA: ESPECIFICAR PARA QUÉ SE DESARROLLA LA MÉTRICA? La métrica se desarrolla para monitorear la calidad del producto, de manera que se pueda tomar las acciones correctivas de manera oportuna

DEFINICIÓN OPERACIONAL: DEFINIR COMO OPERARÁ LA MÉTRICA, ESPECIFICANDO EL QUIÉN, QUÉ, CUÁNDO, DÓNDE, CÓMO? El Project manager actualizará la métrica de cantidad de horas-hombre en re-trabajos, después de haber recibido las observaciones del cliente.

MÉTODO DE MEDICIÓN: DEFINIR LOS PASOS Y CONSIDERACIONES PARA EFECTUAR LA MEDICIÓN. Se recabara la información de cantidad de horas-hombre destinadas a re-trabajo al final de la fase de pruebas funcionales, e inmediatamente después de presupuestar los re- trabajos por observaciones al software. Se medirá en cantidad de horas hombre. La métrica será presentada en el informe de control de ejecución y se actualizaran en cada iteración observaciones-cambios.

HHRT=Nro de h-h presupuestadas para retrabajos

RESULTADO DESEADO: ESPECIFICAR CUÁL ES EL OBJETIVO DE CALIDAD O RESULTADO DESEADO PARA LA MÉTRICA. La cantidad de horas hombre para re-trabajos no deberá exceder las 160h-h para todo el proyecto HHRT < 160 HH

Por cada entregable, la cantidad de horas hombre para re-trabajos no deberá exceder las 40h-h.

ENLACE CON OBJETIVOS ORGANIZACIONALES: ESPECIFICAR CÓMO SE ENLAZA LA MÉTRICA Y EL FACTOR DE CALIDAD RELEVANTE CON LOS OBJETIVOS DE LA ORGANIZACIÓN. El cumplimiento de esta métrica es indispensable para poder cumplir con los objetivos del contrato y lograr productos de alta calidad.

RESPONSABLE DEL FACTOR DE CALIDAD: DEFINIR QUIÉN ES LA PERSONA RESPONSABLE DE VIGILAR EL FACTOR DE CALIDAD, LOS RESULTADOS DE LA MÉTRICA, Y DE PROMOVER LAS MEJORAS DE PROCESOS QUE SEAN NECESARIAS. En primera instancia el encargado de vigilar el factor de calidad es e l Project manager, quien deberá tomar las medidas que sean necesarias para lograr el objetivo de calidad planteado. La responsabilidad última de lograr el buen manejo del alcance del proyectos es del Sponsor del proyecto


3

MÉTRICA DE:

PRODUCTO X PROYECTO


Eficiencia en el código del proyecto(ECP)

DEFINICIÓN DEL FACTOR DE CALIDAD: DEFINIR EL FACTOR DE CALIDAD INVOLUCRADO EN LA MÉTRICA Y ESPECIFICAR PORQUÉ ES RELEVANTE. La eficiencia en el código del proyecto se define como, la mejor forma para desarrollar

los requerimientos solicitador por el cliente.

PROPÓSITO DE LA MÉTRICA: ESPECIFICAR PARA QUÉ SE DESARROLLA LA MÉTRICA? Esta métrica es muy importante pues permitirá mantener el margen de utilidad del proyecto, puesto que reducirá las observaciones al código por parte del área de calidad del cliente. Nos va a permitir conocer la productividad del desarrollador con respecto a otros proyectos similares dentro de la DC Consulting.

DEFINICIÓN OPERACIONAL: DEFINIR COMO OPERARÁ LA MÉTRICA, ESPECIFICANDO EL QUIÉN, QUÉ, CUÁNDO, DÓNDE, CÓMO? El analista responsable, revisara el código de los desarrolladores una vez a la semana durante una hora entre las 9:00 y 11:00 de la mañana y registrara las incidencias para después obtener los ratios de eficiencia del código.

MÉTODO DE MEDICIÓN: DEFINIR LOS PASOS Y CONSIDERACIONES PARA EFECTUAR LA MEDICIÓN. LCF. = Líneas de código fuente total a evaluar. Contar las líneas de código total.

LCFI. = Líneas de código fuente ineficiente.

LCFT. = Total de líneas de código de los desarrolladores.

%OBT. = porcentaje obtenido de LCFI / LCFT

ECP=1 – LCFI/LCFT %

RESULTADO DESEADO: ESPECIFICAR CUÁL ES EL OBJETIVO DE CALIDAD O RESULTADO DESEADO PARA LA MÉTRICA. BUENA. 95 – 100 % (Objetivo)

REGULAR. 90 –95 %

DEFICIENTE. Menos de 90 %

ENLACE CON OBJETIVOS ORGANIZACIONALES: ESPECIFICAR CÓMO SE ENLAZA LA MÉTRICA Y EL FACTOR DE CALIDAD RELEVANTE CON LOS OBJETIVOS DE LA ORGANIZACIÓN. Esta métrica es importante ya que nos va a permitir medir y controlar el nivel de experiencia de los desarrolladores, evitando perder tiempo en la etapa del control de calidad del código; lo cual se va a ver reflejado en un mejor uso del tiempo lo que a su vez se refleja en un mejor ingreso para la DC Consulting.

RESPONSABLE DEL FACTOR DE CALIDAD: DEFINIR QUIÉN ES LA PERSONA RESPONSABLE DE VIGILAR EL FACTOR DE CALIDAD, LOS RESULTADOS DE LA MÉTRICA, Y DE PROMOVER LAS MEJORAS DE PROCESOS QUE SEAN NECESARIAS. En este caso el responsable de la métrica seria el jefe de desarrollo, el cual tiene que analizar los resultados de la métrica y llevar un cuadro con los % obtenidos todas las semanas.




1.0 JP,LC FJ JP 30/06/2011 Versión inicial

LLÍÍNNEEAA BBAASSEE DDEE CCAALLIIDDAADD


DESARROLLO DE UN NUEVO SOFTWARE PARA

OPERADORES DE COMERCIO EXTERIOR CONSOTER

LÍNEA BASE DE CALIDAD FACTOR DE CALIDAD RELEVANTE

OBJETIVO DE CALIDAD

MÉTRICA A

USAR

FRECUENCIA Y MOMENTO DE MEDICIÓN

FRECUENCIA Y MOMENTO DE REPORTE

Performance del proyecto

Número de Requisitos

con solicitudes de cambio <

10%

ICRF < 10%

Número de Requisitos con solicitudes de cambio

Cada vez que el cliente entregue observaciones, la primera vez es después de la primera prueba funcional

Cada vez que el cliente entregue observaciones, la primera vez es después e la primera prueba funcional Informe de gestión del proyecto

Calidad del producto

Cantidad de horas-

hombre en re-trabajos < 160HH

HH RT< 160 HH

Cantidad de horas-hombre en re-trabajos

Cada vez que se haga el costeo del re- trabajo cuando se reciban observaciones. La primera vez es después de la primera prueba funcional

Cada vez que se haga el costeo del re- trabajo cuando se reciban observaciones. La primera vez es después de la primera prueba Informe de gestión del proyecto funcional


ECP > 95% ECP Eficiencia de código del proyecto.

Una vez a la semana

Una vez a la semana










1.0 JP FJ JP 02/07/2011 Versión inicial

MMAATTRRIIZZ DDEE AACCTTIIVVIIDDAADDEESS DDEE CCAALLIIDDAADD




ENTREGABLE ESTÁNDAR DE CALIDAD APLICABLE

ACTIVIDADE S DE

PREVENCIÓN

ACTIVIDADES DE CONTROL

1.1.1 Project Charter

Metodología de GP de la DC Consulting

Aprobación por Sponsor




1.2.1 Sentencia de Alcance



1.2.2 EDT Metodología de GP de la DC Consulting


1.2.3 Plan de Gestión del Proyecto


















2.1 Registro y Modificación de Operador

Documento con RF, RNF, análisis y diseño

Revisión de RF, RNF, análisis y diseño

Pruebas(analista de pruebas)/Revisión de estándares(Arquitecto)/Aprobación por el Project manager





detallado Estándares de programación del cliente

detallado


Documento con RF, RNF, análisis y diseño detallado Estándares de programación del cliente

Revisión de RF, RNF, análisis y diseño detallado







Documento con RF, RNF, análisis y diseño detallado

Aprobación por el Project manager


Formato estándar de manual de usuario


3.1 Asignación de Operador a Circunscripciones




3.2 Registro y Modificación de Local por Circunscripción






























4.3 Cambio de Estado Representante










5.1 Registro de Sanciones y Seguimientos

Documento con RF, RNF, análisis y

Revisión de RF, RNF, análisis y

Pruebas(analista de pruebas)/Revisión de estándares(Arquitecto)/Aprobación





diseño detallado Estándares de programación del cliente

diseño detallado

por el Project manager

5.2 Consulta Sanciones por Operador














Estándares de programación del cliente


6.3 Documentación Entrega

Formato estándar de documentación de entrega


7.1 Actualización de las pruebas de Integración




Contrato marco






PPLLAANN DDEE GGEESSTTIIOONN DDEE LLAA CCAALLIIDDAADD


DESARROLLO DE UN NUEVO SOFTWARE PARA CONSOTER OPERADORES DE COMERCIO EXTERIOR 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. Este proyecto debe cumplir con los requisitos de calidad de la DC Consulting terminando dentro del presupuesto y tiempo estimados manteniendo una buena definición del alcance. También debe cumplir con los requisitos de calidad del Cliente en cuanto de producto, como estándares de programación, buenas prácticas y otros que se definan como requisitos.

LÍNEA BASE DE CALIDAD DEL PROYECTO: ESPECIFICAR LOS FACTORES DE CALIDAD RELEVANTES PARA EL

PRODUCTO DEL PROYECTO Y PARA LA GESTIÓN DEL PROYECTO. PARA CADA FACTOR DE CALIDAD RELEVANTE DEFINIR LOS OBJETIVOS DE CALIDAD, LAS MÉTRICAS A UTILIZAR, Y LAS FRECUENCIAS DE MEDICIÓN Y DE REPORTE.

FACTOR DE CALIDAD

RELEVANTE

OBJETIVO DE CALIDAD

MÉTRICA A UTILIZAR

FRECUENCIA Y MOMENTO DE MEDICIÓN

FRECUENCIA Y MOMENTO DE REPORTE

Rendimiento del proyecto

Número de Requisitos

con solicitudes de cambio < 10% ICRF <

10%

Número de Requisitos con solicitudes de cambio

Cada vez que el cliente entregue observaciones, la primera vez es después de la primera prueba funcional

Cada vez que el cliente entregue observaciones, la primera vez es después de la primera prueba funcional Informe de gestión del proyecto


Cantidad de horas-

hombre en re-trabajos <

160HH

HH RT< 160 HH

Cantidad de horas-hombre en re- trabajos

Cada vez que se haga el costeo del re-trabajo cuando se reciban observaciones. La primera vez es después de la primera prueba funcional

Cada vez que se haga el costeo del re-trabajo cuando se reciban observaciones. La primera vez es después de la primera prueba Informe de gestión del proyecto funcional


ECP > 95% ECP Eficiencia de código del proyecto.

Una vez a la semana

Una vez a la semana

Rendimiento del Proyecto

SPI >= 0.9 +-0.05

Índice de rendimiento

de cronograma

Una vez a la semana.


Rendimiento del Proyecto

CPI>= 0.9+- 0.05

Índice de rendimiento de costos



PLAN DE MEJORA DE PROCESOS: ESPECIFICAR LOS PASOS PARA ANALIZAR PROCESOS, LOS CUALES FACILITARÁN

LA IDENTIFICACIÓN DE ACTIVIDADES QUE GENERAN DESPERDICIO O QUE NO AGREGAN VALOR.





2

Para mejorar un proceso se seguirán los siguientes pasos: 1. Diagramar el proceso. 2. Identificar principales indicadores (de costo, de tiempo, de calidad) y medirlos. 3. Hacer una lluvia de ideas para determinar las partes del proceso que podrían mejorarse 4. Hacer diagramas de Ichikawa para determinar la causa raíz por cada proceso mejorable 5. Definir acciones correctivas sobre las causas raíces identificadas. 6. Diagramar el proceso mejorado. 7. Aplicar las acciones correctivas 8. Medir los indicadores del proceso mejorado y verificar si las acciones correctivas han sido efectivas. 9. Estandarizar las mejoras logradas para hacerlas parte del proceso

MATRIZ DE ACTIVIDADES DE CALIDAD: ESPECIFICAR PARA CADA PAQUETE DE TRABAJO SI EXISTE UN

ESTÁNDAR O NORMA DE CALIDAD APLICABLE A SU ELABORACIÓN. ANALIZAR LA CAPACIDAD DEL PROCESO QUE GENERARÁ CADA ENTREGABLE Y DISEÑAR ACTIVIDADES DE PREVENCIÓN Y DE CONTROL QUE ASEGURARÁN LA OBTENCIÓN DE ENTREGABLES CON EL NIVEL DE CALIDAD REQUERIDO (VER MATRIZ ADJUNTA).

PAQUETE DE TRABAJO ESTÁNDAR O NORMA DE

CALIDAD APLICABLE ACTIVIDADES DE

PREVENCIÓN ACTIVIDADES DE CONTROL

1.1.1 Project Charter Metodología de GP de la DC Consulting





1.2.1 Sentencia de Alcance



1.2.2 EDT Metodología de GP de la DC Consulting


1.2.3 Plan de Gestión del Proyecto


















2.1 Registro y Modificación de Operador



Pruebas/Revisión de estándares/Aprobación por el Project manager






3




Pruebas/Revisión de estándares/Aprobació n por el Project manager







3.1 Asignación de Operador a Circunscripciones




3.2 Registro y Modificación de Local por Circunscripción



























4

4.3 Cambio de Estado Representante














5.2 Consulta Sanciones por Operador














Estándares de programación del cliente



Formato estándar de documentación de entrega


7.1 Actualización de las pruebas de Integración




Contrato marco Aprobación por el Project manager

ROLES PARA LA GESTIÓN DE LA CALIDAD: ESPECIFICAR LOS ROLES QUE SERÁN NECESARIOS EN EL EQUIPO

DE PROYECTO PARA DESARROLLAR LOS ENTREGABLES Y ACTIVIDADES DE GESTIÓN DE LA CALIDAD. PARA CADA ROL ESPECIFICAR: OBJETIVOS, FUNCIONES, NIVELES DE AUTORIDAD, A QUIEN REPORTA, A QUIEN SUPERVISA, REQUISITOS DE

CONOCIMIENTOS, HABILIDADES, Y EXPERIENCIA PARA DESEMPEÑAR EL ROL.

ROL NO 1 : SPONSOR

Objetivos del rol: Responsable ejecutivo y final por la calidad del proyecto Funciones del rol: Revisar, aprobar y tomar acciones correctivas para la mejora de la calidad Niveles de autoridad: Poder de decisión sobre los recursos de la DC Consulting. Reporta a: Directorio de la DC Consulting.


5

ROL NO 2: PROJECT

MANAGER

ROL NO 3 : ANALISTAS DE

PRUEBAS/DOCUMENTA

DOR

Supervisa a: Project manager Requisitos de conocimientos: Gestión en general y gestión de proyectos Requisitos de habilidades Liderazgo, comunicación, negociación, motivación, solución de conflictos Requisitos de experiencia: 10 años de experiencia en el ramo

Objetivos del rol: Gestionar la calidad en el proyecto Funciones del rol: Revisar, aceptar u ordenar el re-trabajo en los entregables. Generar, ejecutar y evaluar las acciones correctivas. Realizar el aseguramiento de la calidad. Niveles de autoridad: Exigir el cumplimiento de los entregables del proyecto. Reporta a: Sponsor Supervisa a: Analista de pruebas/documentador, Programadores y Arquitecto. Requisitos de conocimientos: Gestión de proyectos Requisitos de habilidades: Liderazgo, comunicación, negociación, motivación, solución de conflictos Requisitos de experiencia: 3 años de experiencia en gestión de proyectos de TI Objetivos del rol: Cumplir con los objetivos de calidad del proyecto Funciones del rol : Realizar las pruebas funcionales de los componentes desarrollados, recopilar los datos y generar las métricas de calidad definidas Niveles de autoridad: Aplicar los recursos que se asignan

Reporta a: Project manager

Supervisa a: Requisitos de conocimientos: Técnicas de pruebas de software, lenguaje de programación Java. Requisitos de habilidades: Comunicación, capacidad analítica, orden

Requisitos de experiencia: 3 años en pruebas de sistemas

ORGANIZACIÓN PARA LA CALIDAD DEL PROYECTO: ESPECIFICAR EL ORGANIGRAMA DEL PROYECTO

INDICANDO CLARAMENTE DONDE ESTARÁN SITUADOS LOS ROLES PARA LA GESTIÓN DE LA CALIDAD.

Sponsor

Comité de gestión de cambios

Project manager

Equipo de Proyecto

DOCUMENTOS NORMATIVOS PARA LA CALIDAD: ESPECIFICAR QUE DOCUMENTOS NORMATIVOS REGIRÁN

LOS PROCESOS Y ACTIVIDADES DE GESTIÓN DE LA CALIDAD. 1. Procedimiento para la mejora de procesos 2.Procedimiento para reuniones de aseguramiento de la calidad

PROCEDIMIENTOS

PLANTILLAS

3.Procedimiento de revisión de estándares 4.Procedimiento para la evaluación y levantamiento de observaciones 1.Métricas 2.Diagrama de procesos


6

FORMATOS

CHECKLISTS

OTROS DOCUMENTOS

3. Ishikawa 4 Pareto 1.Documentación de métricas 2.Documentación de procesos 3. 4 1.De verificación de procedimientos 2.De verificación de producto 3. 4 1. 2. 3 4

PROCESOS DE GESTIÓN DE LA CALIDAD: ESPECIFICAR EL ENFOQUE PARA REALIZAR LOS PROCESOS DE

GESTIÓN DE LA CALIDAD INDICANDO EL QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, CON QUÉ, Y PORQUÉ. El aseguramiento de calidad se hará monitoreando continuamente la performance del trabajo mediante listas de verificación, los resultados del control de calidad, y sobre todo las métricas

ENFOQUE DE

ASEGURAMIENTO DE

LA CALIDAD

ENFOQUE DE

CONTROL DE LA

CALIDAD

ENFOQUE DE

MEJORA DE

PROCESOS

De esta manera se descubrirá tempranamente cualquier necesidad de auditoria de procesos, o de mejora de procesos

Los resultados se formalizarán como solicitudes de cambio y/o acciones correctivas/preventivas

Asimismo se verificará que dichas solicitudes de cambio, y/o acciones correctivas/preventivas se hayan ejecutado y hayan sido efectivas

El control de calidad se ejecutara revisando los entregables para ver si están conformes o no

Los resultados de estas mediciones se consolidarán y se enviarán al proceso de aseguramiento de calidad

Asimismo en este proceso se hará la medición de las métricas y se informarán al proceso de aseguramiento de calidad

Para los defectos detectados se tratará de detectar las causas raíces de los defectos para eliminar las fuentes del error, los resultados y conclusiones se formalizarán como solicitudes de cambio y/o acciones correctivas/preventivas Para mejorar el proceso: 1. Diagramar el proceso. 2. Identificar principales indicadores (de costo, de tiempo, de calidad) y medirlos. 3. Hacer una lluvia de ideas para determinar las partes del proceso que podrían mejorarse 4. Hacer diagramas de Ishikawa para determinar la causa raíz por cada proceso mejorable 5. Hacer un diagrama de Pareto y definir acciones correctivas sobre las causas identificadas como las responsables del 80% de los problemas. 6. Diagramar el proceso mejorado. 7. Aplicar las acciones correctivas 8. Medir los indicadores del proceso mejorado y verificar si las acciones correctivas han sido efectivas. 9. Estandarizar las mejoras logradas para hacerlas parte del proceso





OORRGGAANNIIGGRRAAMMAA DDEELL PPRROOYYEECCTTOO


DESARROLLO DE UN NUEVO SOFTWARE PARA


Sponsor Gerente de

Desarrollo

Gerente de

Proyectos de TI

Comité Control

de Cambios

Supervisor

Equipo de

Gestión

Project Manager Analista de

Sistemas

Equipo de

Ejecución Programadores Arquitecto /

Programador

Analista de

Pruebas

Leyenda

Azul: Unidades funcionales de La DC

Consulting Amarillo: Unidades funcionales de

El Cliente

Naranja: Comité formado por personal de El Cliente y La DC Consulting






Dharma Consulting ha sido revisada y aprobada como un proveedor de entrenamiento en Project Management por el Project Management Institute (PMI). Como un Registered Education Provider (R.E.P.) del PMI, Dharma Consulting ha aceptado regirse

por los criterios establecidos de aseguramiento de calidad del PMI.



1.0 GL FJ JP Versión inicial

MMAATTRRIIZZ DDEE AASSIIGGNNAACCIIÓÓNN DDEE RREESSPPOONNSSAABBIILLIIDDAADDEESS ((RRAAMM))



OPERADORES DE COMERCIO EXTERIOR ENTREGABLES

SPONSO R

GERENTE DE TI

PROJECT

MANAGE R

ARQUITECTO

/PROGRAMADOR

PROGRAMADOR

ANALISTA DE

PRUEBAS

GERENTE

DESARROLL O

SUPERVISO R

ANALISTA

SISTEMA S

1.1 Project Charter

A V R

1.2 Registro Stakeholders

A V R

1.2.1 Sentencia de

Alcance

A V R

1.2.2 EDT A V R 1.2.3 Plan de

gestión A V R

1.3 Informe de Estado

V A R

1.4.1 Reunión Técnica con

Cliente

A R P

1.4.2 Reunión A R P P P





Gestión con Cliente

1.4.3 Reunión quincenal gestión

DC Consulting

P A R

1.5 Cierre P A R 2.1 Registro y Modificación de

Operador

A V R


A V R

2.3 Cambio de Estado

A V R

2.4 Documentación

A R

3.1 Asignación de Operador a

Circunsc.

A V R


Local por Circunscripción

A V R


A V R

3.4 Cambio de Estado Local

A V R

3.5 Documentación

A R

4.1 Registro y Modificación

Representante

A V R

4.2 Consulta A V R





Representante 4.3 Cambio

Estado Representante

A V R

4.4 Documentación

A R


A V R

5.2 Consulta Sanciones

A V R

5.3 Documentación

A R

6.1 Pruebas Integración

A R


A R

6.3 Documentación

Entrega

A R

7.1 Actualización

Pruebas

A V R

7.2 Documentación

Entrega

A R

LEYENDA





R = RESPONSABLE

P = PARTICIPA V = REVISA

A = APRUEBA

INCLUIR ESTOS DATOS EN LA TABLA SUPERIOR

Roles en Celeste La DC Consulting Roles en Amarillo El Cliente




1.0 GL FJ JP Versión Inicial

DDEESSCCRRIIPPCCIIÓÓNN DDEE RROOLLEESS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO



NOMBRE DEL ROL

Arquitecto / Programador

OBJETIVOS DEL ROL: OBJETIVOS QUE DEBE LOGRAR EL ROL DENTRO DEL PROYECTO (PARA QUÉ SE HA CREADO EL ROL).

El rol del Arquitecto / Programador tiene como objetivo que la construcción del software se realice según los estándares de programación del El Cliente, así como evitar redundancias y obtener un código fuente eficiente y de calidad.

RESPONSABILIDADES: TEMAS PUNTUALES POR LOS CUALES ES RESPONSABLE (¿DE QUÉ ES RESPONSABLE?).

Es responsable de que el código fuente cumpla los estándares de programación solicitados por el cliente, en los módulos de Operadores de Comercio, Circunscripciones, Representantes y Sanciones.

FUNCIONES: FUNCIONES ESPECÍFICAS QUE DEBE CUMPLIR (¿QUÉ DEBE REALIZAR PARA LOGRAR SUS OBJETIVOS Y CUBRIR SUS RESPONSABILIDADES?).

Coordinación con el equipo de trabajo las buenas prácticas de programación y uso de librerías compartidas. Revisión del código fuente para inspeccionar la calidad del código y el estricto cumplimiento de los estándares proporcionados por el cliente. Coordinación con el jefe de proyecto para informar las dificultades y/o requerimientos presentados en la construcción del código fuente. Realizar la revisión conjunto con el Analista de Sistemas de El Cliente.

NIVELES DE AUTORIDAD: QUÉ DECISIONES PUEDE TOMAR CON RELACIÓN AL ALCANCE, TIEMPO, COSTO, CALIDAD, RECURSOS HUMANOS Y MATERIALES, PLANES Y PROGRAMAS, INFORMES Y ENTREGABLES, ADQUISICIONES, CONTRATOS, PROVEEDORES, ETC.

El arquitecto depende funcionalmente del Gerente de Proyectos de TI. Tiene la capacidad de aceptar u observar el código fuente construido por los programadores del equipo. La relación con los programadores es horizontal.

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

Reporta al Project Manager.

SUPERVISA A: A QUIÉNES SUPERVISA DENTRO DEL PROYECTO.

Supervisa la calidad del software construido por los programadores.

REQUISITOS DEL ROL: QUÉ REQUISITOS DEBEN CUMPLIR LAS PERSONAS QUE ASUMAN EL ROL.

Estudios de java bajo el estándar J2EE con una duración mínima de 48 horas. Certificación Java deseable.

CONOCIMIENTOS: QUÉ TEMAS, MATERIAS, O ESPECIALIDADES DEBE CONOCER, MANEJAR O DOMINAR.

Proactivo en grado alto. Facilidad de comunicación en grado medio. Facilidad para trabajar en equipo en grado medio.

HABILIDADES: QUÉ HABILIDADES ESPECÍFICAS DEBE POSEER Y EN QUÉ GRADO.





EXPERIENCIA: QUÉ EXPERIENCIA DEBE TENER, SOBRE QUÉ TEMAS O SITUACIONES, Y DE QUÉ NIVEL.

OTROS: OTROS REQUISITOS ESPECIALES TALES COMO GÉNERO, EDAD, NACIONALIDAD, ESTADO DE SALUD, CONDICIONES FÍSICAS, ETC.

Experiencia mínima de 3 años en construcción de aplicaciones usando el estándar J2EE. Deseable haber asumido el rol de arquitecto en algún proyecto.

NOMBRE DEL ROL

Gerente de Proyecto de TI

OBJETIVOS DEL ROL: OBJETIVOS QUE DEBE LOGRAR EL ROL DENTRO DEL PROYECTO (PARA QUÉ SE HA CREADO EL ROL). Apoyar al Project Manager en aspectos técnicos y de gestión del proyecto.

RESPONSABILIDADES: TEMAS PUNTUALES POR LOS CUALES ES RESPONSABLE (¿DE QUÉ ES RESPONSABLE?).

Tener participación activa en el proyecto en la implementación de los cuatro módulos: Operadores de Comercio, Circunscripciones, Representantes y Sanciones; dando soporte y apoyo al project manager. FUNCIONES: FUNCIONES ESPECÍFICAS QUE DEBE CUMPLIR (¿QUÉ DEBE REALIZAR PARA LOGRAR SUS OBJETIVOS Y CUBRIR SUS RESPONSABILIDADES?). Formar parte del comité de control de cambios. Obtener información de los principales indicadores del proyecto. Reunirse con el comité de gestión del proyecto a fin de solucionar los problemas que se presenten y dar propuestas de mejora. NIVELES DE AUTORIDAD: QUÉ DECISIONES PUEDE TOMAR CON RELACIÓN AL ALCANCE, TIEMPO, COSTO, CALIDAD, RECURSOS HUMANOS Y MATERIALES, PLANES Y PROGRAMAS, INFORMES Y ENTREGABLES, ADQUISICIONES, CONTRATOS, PROVEEDORES, ETC.

Coordinación con las áreas funcionales de la empresa.

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

Sponsor.

SUPERVISA A: A QUIÉNES SUPERVISA DENTRO DEL PROYECTO.

Project Manager. REQUISITOS DEL ROL: QUÉ REQUISITOS DEBEN CUMPLIR LAS PERSONAS QUE ASUMAN EL ROL.

CONOCIMIENTOS: QUÉ TEMAS, MATERIAS, O ESPECIALIDADES DEBE CONOCER, MANEJAR O DOMINAR. HABILIDADES: QUÉ HABILIDADES ESPECÍFICAS DEBE POSEER Y EN QUÉ GRADO. EXPERIENCIA: QUÉ EXPERIENCIA DEBE TENER, SOBRE QUÉ TEMAS O SITUACIONES, Y DE QUÉ NIVEL.

Estudios de java bajo el estándar J2EE con una duración mínima de 48 horas. Facilidad de comunicación y empatía. Creatividad. Facilitador.

Experiencia mínima de 5 años en la gestión de proyectos de TI.

OTROS: OTROS REQUISITOS ESPECIALES TALES COMO GÉNERO, EDAD, NACIONALIDAD, ESTADO DE SALUD, CONDICIONES FÍSICAS, ETC.

2






CCUUAADDRROO DDEE AADDQQUUIISSIICCIIOONNEESS DDEELL PPEERRSSOONNAALL DDEELL PPRROOYYEECCTTOO

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO DESARROLLO DE UN NUEVO SOFTWARE PARA


ROL

TIPO DE ADQUISICIÓN

FUENTE DE

ADQUISIC

IÓN

MODALIDAD DE ADQUISICIÓN

LOCAL DE TRABAJO ASIGNADO

FECHA DE INICIO DE

RECLUTAMIENTO

FECHA REQUERIDA DE

DISPONIBILIDA

D DE PERSONAL

COSTO DE RECLUTAMIENTO

APOYO DE AREA DE RRHH

SPONSOR Pre asignación

Consult ora

DC Consulting

01/07/2009 Ninguno Ninguno

PROJECT MANAGER Pre Asignación

Consult ora

Decisión del Sponsor

DC Consulting


ARQUITECTO PROGRAMADOR

Pre Asignación

Consult ora

Decisión del PM

DC Consulting

15/03/2010( observación)

Ninguno Ninguno

PROGRAMADOR Negociación Consult ora

Decisión Del PM

DC Consulting

10/07/2009 10/07/2009 Ninguno Ninguno

ANALISTA DE PRUEBAS DOCUMENTADOR

Por Adquisición

Consult ora

Decisión deL PM

DC Consulting

01/12/2009 18/12/2009 Ninguno Ninguno

COORDINADOR CONTRATISTA DE LA DC CONSULTING

Pre Asignación

Consult ora

Decisión del Sponsor

DC Consulting





ANALISTA DE SISTEMA DEL CLIENTE

Pre Asignación

Cliente Decisión del Cliente

Cliente 01/07/2009 Ninguno Ninguno




SUPERVISOR DE DESARROLLO DEL CLIENTE

Pre Asignación



CORDINADOR CONTRATISTA DEL CLIENTE

Pre Asignación



GERENTE DE DESARROLLO DEL CLIENTE

Pre Asignación



LIDER DE USUARIO DE CLIENTE

Asignación Cliente Decisión del Cliente r


REVISOR DE STANDARES DEL CLIENTE

Asignación Cliente Decisión del Cliente


ANALISTA DE PRUEBAS DEL CLIENTE

Asignación Cliente Decisión del Cliente





1.0 GL FJ GL 20/07/2011 Versión Inicial

PPLLAANN DDEE RREECCUURRSSOOSS HHUUMMAANNOOSS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO DESARROLLO DE UN NUEVO SOFTWARE PARA CONSOTER OPERADORES DE COMERCIO EXTERIOR

ORGANIGRAMA DEL PROYECTO: ESPECIFICAR EL ORGANIGRAMA DEL PROYECTO.

Ver Organigrama del proyecto v1.0

NOTA: ADJUNTAR ORGANIGRAMA DEL PROYECTO.

ROLES Y RESPONSABILIDADES: ESPECIFICAR LA MATRIZ DE ASIGNACIONES DE RESPONSABILIDADES (RAM).

Ver Matriz de Asignación y Responsabilidades versión 1.0

NOTA: ADJUNTAR MATRIZ RAM.

DESCRIPCIÓN DE ROLES: NOMBRE DEL ROL, OBJETIVOS, FUNCIONES, NIVELES DE AUTORIDAD, A QUIÉN REPORTA, A QUIÉN SUPERVISA, REQUISITOS DE CONOCIMIENTOS, HABILIDADES, Y EXPERIENCIA PARA DESEMPEÑAR ROL.

Ver Descripción de Roles

NOTA: ADJUNTAR FORMATOS DE DESCRIPCIÓN DE ROLES.

ADQUISICIÓN DEL PERSONAL DEL PROYECTO: CÓMO, DE DÓNDE, CUÁNDO, CUÁNTO, ETC.?

Ver Cuadro de Adquisición de Personal.

NOTA: ADJUNTAR CUADRO DE ADQUISICIÓN DE PERSONAL.

CRONOGRAMAS E HISTOGRAMAS DE TRABAJO DEL PERSONAL DEL PROYECTO: CRONOGRAMAS DE ASIGNACIÓN DE PERSONAS Y ROLES, HISTOGRAMAS DE TRABAJO TOTALES Y POR ESPECIALIDADES.

NOTA: ADJUNTAR DIAGRAMA DE CARGA DE PERSONAL.

CRITERIOS DE LIBERACIÓN DEL PERSONAL DEL PROYECTO: CUÁNTO, CÓMO, HACIA DÓNDE?

ROL CRITERIO DE LIBERACIÓN

¿CÓMO? DESTINO DE ASIGNACIÓN

Sponsor Al término del proyecto.

Otros proyectos de la DC Consulting.

Gerente de Proyectos de TI

Al término del proyecto.

Comunicación del Sponsor.


Project Manager Al término del proyecto.

Comunicación del Sponsor.






Programador (1) Al término del proyecto.

Programador (4) Al término de la fase de entregables finales.

Comunicación del Project Manager Comunicación del Project Manager.

Otros proyectos de La DC Consulting. Otros proyectos de La DC Consulting.

Arquitecto / Programador

Al término de la fase de Entregables Finales.

Comunicación del Project Manager.


Analista de Pruebas Al término del contrato.

Comunicación del Project Manager.

CAPACITACIÓN, ENTRENAMIENTO, MENTORING REQUERIDO: QUÉ, PORQUÉ, CUÁNDO, CÓMO, DÓNDE, POR QUIÉN, CUÁNTO?

Se debe incentivar la participación del arquitecto/programador a las charlas de calidad de software y arquitectura J2EE que brinde La DC Consulting o El Cliente. Se capacitará al Project Manager, Arquitecto/Programador y Programadores acerca de los estándares utilizados por parte de El Cliente. El Project Manager se encargará de capacitar al analista de pruebas en la funcionalidad de los módulos desarrollados. SISTEMA DE RECONOCIMIENTO Y RECOMPENSAS: QUÉ, PORQUÉ, CUÁNTO, CÓMO, DÓNDE, POR QUIÉN, CUÁNTO?

El sistema de reconocimiento y recompensas estará dado por: - Carta de felicitación en caso haber logrado las metas personales y del

proyecto. - Asignación de hasta dos medios días libres en caso de cumplimiento de las

metas personales y del proyecto (CPI y SPI no menores de 1.0). CUMPLIMIENTO DE REGULACIONES, PACTOS, Y POLÍTICAS: QUÉ, PORQUÉ, CUÁNDO, CÓMO, DÓNDE, POR QUIÉN, CUÁNTO?

Las tolerancia de ingreso a las instalaciones de El Cliente no deberá exceder los 20 minutos diarios o 120 minutos acumulados en mes calendario. La vestimenta deberá ser formal, con excepción de los viernes en que la vestimenta será casual (no zapatillas ni ropa deportiva). Las solicitudes de permisos particulares por horas o días serán presentadas y evaluadas por el Project Manager.

REQUERIMIENTOS DE SEGURIDAD: QUÉ, PORQUÉ, CUÁNDO, CÓMO, DÓNDE, POR QUIÉN, CUÁNTO? La información proporcionada por el cliente acerca de las especificaciones de construcción debe ser de carácter reservado. El código fuente no puede ser sacado fuera de las instalaciones de El Cliente.

2




1.0 GL FJ JP 01/07/2009 Versión Inicial

PPLLAANN DDEE GGEESSTTIIÓÓNN DDEE CCOOMMUUNNIICCAACCIIOONNEESS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO


CONSOTER

COMUNICACIONES DEL PROYECTO: ESPECIFICAR LA MATRIZ DE COMUNICACIONES DEL PROYECTO. Se adjunta matriz de comunicaciones del proyecto.

NOTA: ADJUNTAR MATRIZ DE COMUNICACIONES DEL PROYECTO 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. Captar las polémicas a través de conversación y observación. Llevar un registro de polémicas. Asignar un responsable. Seguimiento por parte del responsable. Elaborar alternativas para evitar que la polémica se convierta en conflicto. Revisión semanal del estado de las polémicas y revisar si las soluciones propuestas se están aplicando. En caso una polémica se convierta en un conflicto, escalar al Gerente de Proyectos de TI y de no solucionarse, al Sponsor. PROCEDIMIENTO PARA ACTUALIZAR EL PLAN DE GESTIÓN DE COMUNICACIONES: DEFINA EL PROCEDIMIENTO PARA REVISAR Y ACTUALIZAR EL PLAN DE GESTIÓN DE COMUNICACIONES. Revisión del plan de gestión de comunicaciones cuando:

- Se detecte que hay deficiencia en la comunicación. - Alguna solicitud de cambio afecte el Plan de gestión del proyecto. - Cuando se detecte un nuevo stakeholder.

La actualización del Plan de Gestión de las Comunicaciones deberá seguir los siguientes pasos:

- Identificación y clasificación de los stakeholders - Determinación de requerimientos de información. - Elaboración de la matriz de comunicaciones del proyecto. - Actualización del plan de gestión de comunicaciones. - Aprobación del plan de gestión de comunicaciones. - Difusión del nuevo plan gestión de comunicaciones.

GUÍAS PARA EVENTOS DE COMUNICACIÓN: DEFINA GUÍA PARA REUNIONES, CONFERENCIAS, CORREO ELECTRÓNICO, ETC.





2

Guía para reuniones:

1. Debe fijarse la agenda con anterioridad. 2. Debe coordinarse e informar fecha y hora con los participantes con una anticipación

mínima de 2 días. 3. Se debe empezar puntual. 4. Se deben fijar los objetivos de la reunión. 5. Se debe asignar a una persona para que redacte el acta de reunión indicando los

acuerdos tomados, responsables y fechas comprometidas. 6. Debe distribuirse el acta de reunión a todos los participantes vía correo electrónico.

Guía para el correo electrónico:

1. Comunicaciones de carácter técnico entre Analista y Project Manager, deben ir con copia al Supervisor del Cliente.

2. Comunicaciones de gestión, entre Supervisor y Project Manager, deben ir con copia al Analista, Gerente de Proyectos de TI de La DC Consulting.

3. Las comunicaciones del Project Manager y los programadores deben ir con copia a todo el equipo del proyecto. Igualmente las comunicaciones en sentido inverso.

4. Los programadores no tienen salida a correos externos. Políticas de Respaldo: Cada programador es responsable de obtener una copia de seguridad diaria de la información que no haya subido al repositorio. El Project Manager es responsable de obtener un backup externo del respositorio.

GUÍAS PARA DOCUMENTACIÓN DEL PROYECTO: DEFINA LAS GUÍAS PARA CODIFICACIÓN, ALMACENAMIENTO, RECUPERACIÓN, Y REPARTO DE LOS DOCUMENTOS DEL PROYECTO. La codificación de los documentos del proyecto será el siguiente:

PPPP – EE – TTTT – V.VV - YYYYMMDD

PPPP: Nombre del proyecto (abreviación o alias) EE: Fase pudiendo ser Iniciación, Planeación, Ejecución, Monitoreo y Control, Cierre. TTTT: Tipo de documento, ejemplo: PRCH-Project Charter V.VV: Versión del proyecto YYYYMMDD: Fecha del documento

Guía para almacenamiento y gestión de documentos:

1. En el servidor de archivos se tendrá una estructura similar al EDT del proyecto donde se

tendrán las últimas versiones de los documentos. 2. Cuando algún miembro del equipo desee actualizar un archivo, deberá sacar una copia en

su pc. 3. Una vez que se quiera actualizar la versión en el servidor de archivos se coordinará con el

Project manager quien consolidará los cambios para quedarse con la versión final controlada del documento.

4. Los miembros del equipo borrarán las versiones que copiaron en sus pc’s. 5. Su publicará una relación de documentos del proyecto y la ruta para accesarlos.

GUÍAS PARA EL CONTROL DE VERSIONES: DEFINA GUÍAS PARA REGISTRO Y CONTROL ORDENADO DE LAS VERSIONES DE LOS DOCUMENTOS DEL PROYECTO.


3

Todos los documentos del proyecto están sujetos al control de versiones. Cada documento tendrá un cuadro en la primera página con la siguiente información:

- Código de Versión - Hecha por - Revisada por - Aprobada por - Fecha - Motivo

GLOSARIO DE TERMINOLOGÍA DEL PROYECTO: GLOSARIO DE TÉRMINOS, NOMBRES, CONCEPTOS, FÓRMULAS, ETC. OCE: Agrupacion de personas de Comercio Exterior.

G2: Documento de Especificaciones de El Cliente que servirá de guía para la construcción por parte de La DC Consulting. AOX: Acta de observaciones de El Cliente. X es el correlativo del acta.

RAOX: Respuesta a acta de observaciones de La DC Consulting. X Es el correlativo del acta

EDT: Estructura de desglose de trabajo.

EV: Valor Ganado

PV: Valor Planeado

AC: Costo Real

PU: Prueba unitaria

MU: Manual de usuario

IPP: Instructivo de pase a producción.

Circunscripción: Área geográfica en la que tiene cobertura una aduana.

MDS: Metodología de Desarrollo de Sistemas






1.0 GL FJ JP 20/07/2011 Versión inicial

MMAATTRRIIZZ DDEE CCOOMMUUNNIICCAACCIIOONNEESS DDEELL PPRROOYYEECCTTOO



CONSOTER

INFORMACIÓN

CONTENIDO

FORMATO NIVEL DE DETALLE

RESPONSABLE DE COMUNICAR

GRUPO RECEPTOR

MEDIO DE INFORMACION

FRECUENCIA DE COMUNICACIÓN

CÓDIGO DE ELEMENTO WBS

Iniciación del Proyecto

Datos y comunicación sobre la iniciación del proyecto.

Project Charter

Medio Project Manager

Sponsor, Gerente de proyecto de TI y equipo de proyecto.

Documento digital PDF vía correo electrónico.

Una sola vez 1.1.1 Project Charter

Planificación del proyecto.

Datos preliminares sobre el alcance del proyecto.

Scope Statement

Alto Project Manager

Sponsor, Gerente de proyecto de TI y equipo de proyecto.


Una sola vez 1.1.2 Scope Statement

Planificación del Proyecto.

Planificación detallada del proyecto: Alcance, tiempo, Costo, Calidad, Comunicaciones, Riesgos y adquisiciones.

Plan del proyecto


Equipo de proyecto.


Una sola vez. 1.2 Plan del proyecto




Ejecución del proyecto

Estado entregables, costos

Informe de desempeño


Sponsor, Gerente de Proyectos de TI

Documento digital vía correo electrónico.

Semanal 1.3.1

Incurridos, avance cronograma.

y equipo de proyecto.

Ejecución del Proyecto

Horas Laboradas.

Formato de Horas laboradas.


Sponsor, Gerente de Proyectos de TI

Documento digital vía correo electrónico.

Semanal 1.3.2

Control de Cambios

Consultas de especificaciones.

Formato de Consultas de Especificación

Alto Programador Project Manager Correo electrónico Diario 1.4.1

Control de Cambios

Control de Cambios

Formato de Control de Cambios.


Analista de Sistemas de El Cliente.

Documento Word vía correo electrónico.

Semanal 1.4.2

Control de Cambios

Solicitud de Cambio

Formato de Solicitud de Cambio.

Alto Analista de Sistemas de El Cliente.

Comité de gestión del proyecto.

Documento impreso.

Semanal. 1.4.3

Levantamiento de Observaciones

Observaciones de El Cliente

Acta de Observaciones

Alto Analista de Sistemas de El Cliente

Project Manager Documento impreso.

Semanal 6.1

Levantamiento de Observaciones

Respuestas y comentarios de las observaciones

Formato de respuesta a observaciones .


Analista de Sistemas de El Cliente.

Documento impreso.

Por cada acta de observaciones.

6.2

Cierre del Proyecto

Acta de Aceptación.

Acta con la aceptación del producto.

Medio Analista de Sistemas de El Cliente.

Project Manager. Documento impreso.

Una sola vez. 7.2

Cierre del Proyecto

Informe de cierre y Lecciones aprendidas.

Formato de Cierre del Proyecto.


Sponsor, Gerente de Proyectos de TI.

Presentación PPT vía correo electrónico.

Una sola vez 7.1




1.0 JP FJ 07/07/2011 Versión original

PPLLAANN DDEE GGEESSTTIIÓÓNN DDEE RRIIEESSGGOOSS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO


CONSOTER

METODOLOGÍA DE GESTIÓN DE RIESGOS

PROCESO DESCRIPCIÓN HERRAMIENTAS FUENTES DE INFORMACIÓN

Planificación de Gestión de los Riesgos

Elaborar el plan de gestión de riesgos

PMBOK Sponsor

PM Equipo de proyecto

Identificación de Riesgos

Identificar que riesgos pueden afectar el proyecto y documentar sus características

Lluvia de ideas Revisión de documentación.

Sponsor

Lista de riesgos PM Equipo de proyecto

Revisión de documentación.

Documentación de módulos construidos anteriormente.

Entrevistas Gerente de Desarrollo de El Cliente. Supervisor de El Cliente.

Análisis Cualitativo de Riesgos

Evaluar la probabilidad y el impacto de cada riesgo

Definición de PM probabilidad e impacto

Establecer un ranking de riesgos Elaborar matriz de probabilidad e impacto

Equipo de proyecto

Análisis Cuantitativo de Riesgos

No se realizará No aplica No aplica

Planificación de Respuesta a los Riesgos

Definir la respuesta a los riesgos Juicio experto PM Planificar la respuesta a los riesgos Equipo de

proyecto

Seguimiento y Control del Riesgos

Verificar la ocurrencia de riesgos PMBOK PM Supervisar la ejecución de la PM respuesta a riesgos





2

ROLES Y RESPONSABILIDADES DE GESTIÓN DE RIESGOS

PROCESO ROLES PERSONAS RESPONSABILIDADES




Líder JP Proveer definiciones

Gestor de riesgos GL Responsable del proceso

Equipo riesgos WG,PP,DZ,AT,PV Ejecutar proceso Líder JP Proveer definiciones Gestor de riesgos GL Responsable del proceso Equipo riesgos WG,PP,DZ,AT,PV Ejecutar proceso

Gestor de riesgos GL Responsable del proceso

Equipo riesgos WG, PP, DZ, AT, PV Ejecutar proceso


No aplica No aplica No aplica



Gestor de riesgos GL Responsable del proceso Equipo riesgos WG, PP, DZ, AT,PV Ejecutar proceso Gestor de riesgos GL Responsable del proceso Ejecutar proceso

PRESUPUESTO DE GESTIÓN DE RIESGOS

PROCESO PERSONAS MATERIALES EQUIPOS TOTAL Planificación de Gestión de los Riesgos

Project Manager Gerente de TI Sponsor

$250 $300 $500


Project Manager Equipo ejecución

$1050 $1050 $250 $300


$ 550 $ 550 Project Manager $100


$ 100 $ 100


Project Manager Gerente de TI Sponsor

$125 $150 $250


$525 $525

Project Manager $1500

$1500

$3725 PERIODICIDAD DE LA GESTIÓN DE RIESGOS


3

PROCESO

MOMENTO DE EJECUCIÓN ENTREGABLE DEL

WBS PERIODICIDAD DE

EJECUCIÓN


Inicio del proyecto Cada vez que se identifiquen riesgos nuevos o se re-evalúen riesgos pre-existentes

1.2.2 Plan de gestión del proyecto

Una vez Cada vez que se identifiquen riesgos nuevos o se re-evalúen riesgos pre-existentes


Inicio del proyecto En cada reunión del equipo de proyecto

1.2.2 Plan de gestión del proyecto 1.3.5.3 Reunión semanal con el equipo







No se realizará No aplica No aplica






Cada semana 1.3.5.3 Reunión semanal con el equipo

Cada semana

FORMATOS DE LA GESTIÓN DE RIESGOS

FORMATO

CONTENIDO PROCESO EN QUE

SE GENERA

RESPONSABLE DE GENERARLO

FRECUENCIA O PERIODICIDAD

Plan de Gestión de Riesgos

Metodología de gestión Roles y responsabilidades Periodicidad Formatos


GL Una vez Cada vez que se identifiquen riesgos nuevos o se re-evalúen riesgos pre- existentes

Identificación y Evaluación Cualitativa de Riesgos

Riesgos Causa raíz Tipo de riesgo



Identificación y Evaluación Cualitativa de Riesgos

Probabilidad Impacto



Plan de Respuesta a Riesgos

Respuesta Tipo de respuesta Responsable de la respuesta Plan de contingencia




4

Informe de Monitoreo de Riesgos Solicitud de Cambio Acción Correctiva

Estado de los riesgos


GL Cada semana




1.0 GL FJ 07/07/2011 Versión original

IIDDEENNTTIIFFIICCAACCIIOONN YY EEVVAALLUUAACCIIÓÓNN CCUUAALLIITTAATTIIVVAA DDEE RRIIEESSGGOOSS




PROBABILIDAD VALOR NUMÉRICO IMPACTO VALOR NUMÉRICO TIPO DE RIESGO PROBABILIDAD X IMPACTO

Muy Improbable 0.1 Muy Bajo 0.05 Muy Alto mayor a 0.50

Relativamente Probable 0.3 Bajo 0.10 Alto menor a 0.50

Probable 0.5 Moderado 0.20 Moderado menor a 0.30

Muy Probable 0.7 Alto 0.40 Bajo menor a 0.10

Casi Certeza 0.9 Muy Alto 0.80 Muy Bajo menor a 0.05

CÓDIGO DEL

RIESGO

DESCRIPCIÓN DEL RIESGO

CAUSA RAÍZ TRIGGER

ENTREGABLES AFECTADOS

ESTIMACIÓN DE

PROBABILIDAD

OBJETIVO

AFECTADO

ESTIMACIÓN DE IMPACTO

PROB X

IMPACTO

TIPO DE RIESGO

R01

Especificaciones ambiguas o incompletas

Que el Analista de Sistema no haya sabido recopilar los requerimientos del cliente para realizar el diseño

Que los programadores reporten al menos tres interrogantes o inconsistencia cuya respuesta

1.4.5 Operadores de Comercio 1.4.6 Circunscripciones 1.4.7 Representantes 1.4.8 Sanciones

0.7 Alcance 0.40 0.28

Tiempo 0.40 0.28

Costo 0.40 0.28

Calidad

y el análisis de sus especificaciones.

no se encuentre en el documento de especificaciones

TOTAL PROBABILIDAD X IMPACTO

0.84 Muy Alto

R02 Que la implementación de las solicitudes de

Que el Analista de Sistema no

Que el tiempo de implementación

1.4.5 Operadores de Comercio

0.5 Alcance 0.40 0.20

Tiempo 0.80 0.40 Muy Alto




2

R03

R04

R05

cambio aprobadas excedan al 10% del tiempo estimado para la construcción de los requerimientos iniciales.

Renuncia de alguno de los miembros del equipo de proyecto Tiempo de implementación de re- trabajos exceda el límite permitido de 30 días.

Los programadores terminen antes de la fecha pactada

haya sabido recopilar los requerimientos del cliente para realizar el diseño y el análisis de sus especificaciones. Perspectivas profesionales y salariales Que la experiencia y/o conocimiento del programador no sea la requerida. Falta de control sobre su trabajo.

Que la experiencia, compromiso y/o conocimiento del programador

de las solicitudes de cambio aprobadas corresponda al 7% del tiempo estimado para la Construcción de los requerimientos iniciales.

Tardanzas que excedan los 30 minutos diarios o 150 minutos mensuales; Inasistencias mayores a 2 en cada bimestre; Incumplimiento de actividades en tiempo y calidad 2 veces al mes.

Tiempo de implementación de re-trabajos sea de 20 días.

SPI > 1 Módulos de operadores, circunscripciones, representantes o

1.4.6 Circunscripciones 1.4.7 Representantes 1.4.8 Sanciones



1.4.5 Operadores de Comercio 1.4.6 Circunscripciones 1.4.7

Costo 0.80 0.40

Calidad

TOTAL PROBABILIDAD X 1

IMPACTO

0.3 Alcance

Tiempo 0.80 0.24

Costo 0.05 0.15

Calidad 0.20 0.06

TOTAL PROBABILIDAD X 0.45

IMPACTO

0.3 Alcance

Tiempo 0.80 0.24

Costo 0.80 0.24

Calidad 0.40 0.12


IMPACTO 0.3 Alcance

Tiempo 0.40 0.12

Costo 0.40 0.12

Calidad

Alto

Muy Alto

sea superior a la requerida.

sanciones terminados

Representantes 1.4.8 Sanciones


0.24 Moderado


3

R06

Que se presente un desastre natural: Terremoto o Tsunami

Control sobre su trabajo.

La ubicación geográfica del centro de desarrollo de trabajo es en Pacasmayo - Callao

anticipadamente.

Que se de el movimiento telúrico. Que se de la alerta al Tsunami

Todo el proyecto 0.10 Alcance

Tiempo 0.80 0.08

Costo 0.80 0.08

Calidad TOTAL PROBABILIDAD X

0.16 IMPACTO

Tiempo Costo Calidad

R07

R08

R09

Que el usuario final observe o rechace el entregable

Problema con la infraestructura y comunicaciones del cliente

Que uno de los programadores rinda más de lo esperado.

Que el Analista de Sistema no haya sabido recopilar los requerimientos del cliente para realizar el diseño y el análisis de sus especificaciones Que ocurra un problema en la red debido a que el local se conectaba remotamente a la sede central.

Que el programador cuente con mayor

Observaciones al entregable final que impliquen un tiempo de implementación mayor a 4 horas hombre, es decir observaciones de fondo. Falta de conectividad continuada por mas de 15 minutos o falta de conectividad en un mes por mas de 2 horas. Porcentaje de avance SPI > 1 controlado por

1.4.9 Entregables Finales 1.4.5 Operadores de Comercio 1.4.6 Circunscripciones 1.4.7 Representantes 1.4.8 Sanciones

1.4.5 Operadores de Comercio 1.4.6 Circunscripciones


0.3 Alcance 0.80 0.24

Tiempo 0.80 0.24

Costo 0.80 0.24

Calidad


IMPACTO

0.5 Alcance

Tiempo 0.20 0.10

Costo 0.10 0.05

Calidad 0.10 0.05


IMPACTO 0.3 Alcance

Tiempo 0.20 0.06

Costo 0.20 0.06

Calidad 0.20 0.06

Moderado Muy Alto

Moderado Moderado

4

experiencia programador. 1.4.7

TOTAL PROBABILIDAD X


Que se identifique

Que exista

Se identifica

Representantes 1.4.8 Sanciones

1.4.5 Operadores

0.7 Alcance

IMPACTO 0.18

R10

componentes comunes en los módulos

funcionalidades que se puedan generalizar

funciones similares ya desarrollada e incluirlas en librerías de uso compartido.

de Comercio 1.4.6 Circunscripciones 1.4.7 Representantes 1.4.8 Sanciones

Tiempo 0.2 0.14

Costo 0.2 0.14

TOTAL PROBABILIDAD X IMPACTO 0.28

Moderado





1.0 GL FJ 09/07/2011 Versión original

PPLLAANN DDEE RREESSPPUUEESSTTAA AA RRIIEESSGGOOSS


DESARROLLO DE UN NUEVO SOFTWARE PARA OPERADORES DE COMERCIO EXTERIOR CONSOTER

CÓDIGO DEL

RIESGO

AMENAZA / OPORTUNID

AD

DESCRIPCIÓ

N DEL

RIESGO

CAUSA RAÍZ TRIGGER

ENTREGABLE

S

AFECTADOS

Ordenados

en forma

Decreciente

PROBABILID

AD POR

IMPACTO TOTAL

Muy Alto

Alto

Moderado

Bajo Muy Bajo

TIPO DE RIESGO

RESPONSABL

E DEL

RIESGO

RESPUESTAS PLANIFICAD

AS

Evitar

Mitigar

Transferir

Explotar

Compartir

Mejorar

Aceptar

TIPO DE

RESPUESTA

RESPONSABL

E

DE LA

RESPUESTA

FECHA

PLANIFICAD A

PLAN DE

CONTINGEN CIA

R02 AMENAZA

Que la implementa ción de las solicitudes de cambio aprobadas excedan al 10% del tiempo estimado para la construcció n de los requerimien tos iniciales

Que el Analista de Sistema no haya sabido recopilar los requerimien tos del cliente para realizar el diseño y el análisis de sus especificaci ones

Que el tiempo de implementa ción de las solicitudes de cambio aprobadas correspond a al 7% del tiempo estimado para la construcció n de los requerimien tos iniciales.

1.4.5 Operadores de Comercio 1.4.6 Circunscripc iones 1.4.7 Representa ntes 1.4.8

Sa nciones

1 Muy Alto JP

Verificación y Validación de Requisitos. Juicio de expertos. Informar sobre la cantidad de solicitudes de cambio a la fecha.

Mitigar GL

Mitigar GL

Antes de iniciar la etapa de Ejecución En las reuniones técnicas semanales con el cliente.

Evaluar los cambios, informar al cliente y tomar acciones correctivas.

AMANEZA Especificaci ones

Que el Analista de

Que los programado

1.4.5

Operadores 0.84 Muy Alto WG Mitigar GL

Antes de iniciar la

Evaluar la cantidad de




R01

R07 AMENAZA

ambiguas o incompletas Que el usuario final observe o rechace el entregable Tiempo de implementa

Sistema no haya sabido recopilar los requerimien tos del cliente para realizar el diseño y el análisis de sus especificaci ones. Que el Analista de Sistema no haya sabido recopilar los requerimien tos del cliente para realizar el diseño y el análisis de sus especificaci ones

Que la experiencia y/o

res reporten al menos tres interrogant es o inconsistenc ia cuya respuesta no se encuentre en el documento de especificaci ones

Observacio nes al entregable final que impliquen un tiempo de implementa ción mayor a 4 horas hombre, es decir observacion es de fondo.

Tiempo de implementa

de Comercio 1.4.6 Circunscripc iones 1.4.7 Representa ntes 1.4.8

Sa nciones 1.4.9

Ent regables Finales 1.4.5 Operadores de

0.72 Muy Alto GL

Verificación y Validación de Requisitos. Informar sobre el tiempo que está tomando en aclarar las especificaci ones Programar reuniones periódicas con el usuario final para la revisión de los avances Comunicaci ón y coordinació n informal con representan tes del usuario final

Comunicaci ón y coordinació

Mitigar GL

Mitigar GL Mitigar GL

etapa de Ejecución En las reuniones técnicas semanales con el cliente. En las reuniones de gestión semanal con el cliente Acción continua

especificaci ones ambiguas e incompletas e informar al cliente.

Analizar causas, tomar acciones correctivas y monitorear resultados

Analizar

R04 AMENAZA

ción de re- trabajos exceda el límite permitido

de 30

conocimient o del programado r no sea la requerida. Falta de

ción de re- trabajos sea de 20 días.

Comercio 1.4.6 Circunscripc iones 1.4.7 Representa

0.60 Muy Alto GL

n informal con el equipo del proyecto Establecer puntos de

Mitigar GL Acción continua

En las reuniones

causas, tomar acciones correctivas y monitorear

días. control sobre su

ntes 1.4.8

control en la ejecución

Mitigar GL semanales con el

resultados




trabajo Sa

nciones de los

trabajos equipo del

proyecto

R03

AMENAZA

Renuncia de alguno de los miembros del equipo de proyecto

Perspectiva s profesionale s y salariales

Tardanzas que excedan los 30 minutos diarios o 150 minutos mensuales; Inasistencia s mayores a 2 en cada bimestre; Incumplimie nto de actividades en tiempo y calidad 2 veces al mes.


Sa nciones

0.45

Alto

GL

Realizar actividades de construcció n de equipo e Identificar interés en el proyecto.

Mitigar

GL

Acción continua

Analizar causas, tomar acciones correctivas y monitorear resultados

Comunicaci ón y coordinació n informal con los miembros del equipo

Mitigar

GL

Acción continua

R10

OPORTUNID AD

Que se identifique componente s comunes en los módulos

Que exista funcionalida des que se puedan generalizar

Se identifica funciones similares ya desarrollada e incluirlas en librerías de uso compartido.


Sa nciones

0.28

Moderado

WG

Revisión detalla para identificar re-uso de componente s

Explotar

GL

Acción continua

Informar al Project Manager y tomar medidas del caso

R05

OPORTUNID AD

Los programado res terminen antes de la

Que la experiencia, compromiso y/o conocimient

SPI > 1 Módulos de operadores, circunscripci ones,

1.4.5 Operadores de Comercio 1.4.6

0.24

Moderado

GL

Incentivar la eficiencia de los programado res

Mejorar

GL

Acción continua

Reconocimi ento a los programado res e informar al




fecha pactada

o del programado r sea superior a la requerida. Control sobre su trabajo.

representan tes o sanciones terminados anticipadam ente

Circunscripc iones 1.4.7 Representa ntes 1.4.8

Sa nciones

Adecuada gestión del conocimient o

Explotar

GL

Acción continua

Sponsor.

R08

AMENAZA

Problema con la infraestruct ura y comunicacio nes del cliente

Que ocurra un problema en la red debido a que el local se conectaba remotament e a la sede central.

Falta de conectivida d continuada por mas de 15 minutos o falta de conectivida d en un mes por más de 2 horas.


Sa nciones

0.20

Moderado

GL

Lograr un acuerdo con el cliente para mantener un servicio continuo e incluir penalizacion es por fallas en las comunicacio nes o infraestruct ura.

Transferir

GL

Antes de iniciar la etapa de ejecución

Activar el sistema de comunicació n alterna

Contar con un sistema de comunicació n alternativo

Transferir

GL

Antes de iniciar la etapa de ejecución

R09

OPORTUND AD

Que uno de los programado res rinda

Que el programado r cuente con mayor

Porcentaje de avance SPI > 1

1.4.5 Operadores de Comercio

0.18

Moderado

GL

Realizar un proceso de selección riguroso

Mejorar

GL

Acción continua

Reconocimi ento de logros del programado




más de lo esperado.

experiencia controlado por programad or.

1.4.6 Circunscripc iones 1.4.7 Representa ntes 1.4.8

Sa nciones

Realizar actividades de construcció n de equipo e incluir bonos o recompensa s.

Mejorar

GL

Acción continua

r y realizar un plan de entrenamie nto al resto del equipo.

R06

AMENAZA

Que se presente un desastre natural: Terremoto o Tsunami

La ubicación geográfica del centro de desarrollo de trabajo es en Pacasmayo - Callao

Que se de el movimiento telúrico. Que se de la alerta al Tsunami

Todo proyecto

0.16

Moderado

GL

Llegar a un acuerdo con el cliente para poder utilizar otro local en caso de ocurrir un desastre natural

Transferir

GL

Antes de la ejecución de los trabajos

Evaluar la situación y dependiend o de eso tomar las acciones del caso

Realizar simulacros con el personal

Mitigar

GL

Acción continua

Contar con un backup de los códigos fuentes en otro local

Mitigar

GL

Semanalme nte





PPLLAANN DDEE GGEESSTTIIÓÓNN DDEE AADDQQUUIISSIICCIIOONNEESS NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO



ADQUISICIONES DEL PROYECTO: ESPECIFICAR LA MATRIZ DE ADQUISICIONES DEL PROYECTO. Ver matriz de adquisición del proyecto

PROCEDIMIENTOS ESTÁNDAR A SEGUIR: PROCEDIMIENTOS DE ADQUISICIÓN QUE SE DEBEN SEGUIR. Para los contratos de personal se realizará el siguiente proceso: -Realizar convocatoria -Realizar proceso de selección -Negociar remuneración -Contratar -Realizar el pago

FORMATOS ESTÁNDAR A UTILIZAR: FORMATOS DE ADQUISICIÓN QUE SE DEBEN SEGUIR. -La DC Consulting tiene un formato estándar de contrato de personal, el cual se personaliza de acuerdo el requerimiento del servicio, el periodo en el que se realizará y el monto a pagar. -El contrato se emitirá en dos copias, será revisado y si hay observaciones se modificará, luego se firmara y se imprimirán dos copias una para cada interesado

COORDINACIÓN CON OTROS ASPECTOS DE LA GESTIÓN DEL PROYECTO: COORDINACIÓN CON EL SCHEDULING DEL PROYECTO, REPORTE DE PERFORMANCE, CAMBIOS EN LAS DECISIONES DE HACER O COMPRAR, COORDINACIÓN DE FECHAS CONTRACTUALES CON LA PROGRAMACIÓN DEL PROYECTO, ETC. En la planificación del proyecto se considero las siguientes fechas para la realización de los contratos: Contrato de personal para la realización de las pruebas de integración

La persona encargada de hacer las pruebas de integración estará disponible 2 semanas antes del inicio de la tarea y tendrá un proceso de inducción en el que se pondrá al tanto de la estructura del sistema.

COORDINACIÓN CON LA GESTIÓN DE PROYECTOS DE LOS PROVEEDORES: COORDINACIÓN CON LA GESTIÓN DE PROYECTOS DE PROVEEDORES, ENLACES DE PROCESOS, PROCEDIMIENTOS, FORMATOS Y/O METODOLOGÍAS. El contrato con la persona que realizara la prueba de integración del sistema se realizar por lo menos 30 días antes de requerirse su disponibilidad, puesto que según el plazo de ley, si estuviera trabajando en otro lugar requerirá por lo menos 30 días antes de resolver su contrato y estar disponible

RESTRICCIONES Y SUPUESTOS: QUE PUEDAN AFECTAR LAS ADQUISICIONES PLANIFICADAS Y POR LO TANTO EL LOGRO DE LOS OBJETIVOS DEL PROYECTO.





Las restricciones y/o supuesto que se han identificado y que podrían afectar la contratación de personal para las pruebas son las siguientes: -La persona contratada podría estar disponible recién después de los 30 dias debido a que legalmente su actual empleador podría requerir que se completen los 30 dias de acuerdo a ley -Podrían presentarse solicitudes de cambio que amplíen el plazo de contratación y por tanto que requieran renegociar los contratos

RIESGOS Y RESPUESTAS: PRINCIPALES RIESGOS RELACIONADOS A LAS ADQUISICIONES, Y RESPUESTAS QUE HAN SIDO CONSIDERADAS EN LA GESTIÓN DE RIESGOS DEL PROYECTO. Según al plan de respuesta a riesgos se tiene lo siguientes:

R001 – No encontrar el perfil requerido

-Realizar una convocatoria más amplia

MÉTRICAS: MÉTRICAS DE ADQUISICIÓN A SER USADAS PARA GESTIONAR Y EVALUAR PROVEEDORES. Se tomara en cuenta la evaluación que haga el Project manager sobre el desempeño del arquitecto.

2




1.0 GL FJ JP 20/07/2011 Versión inicial

MMAATTRRIIZZ DDEE AADDQQUUIISSIICCIIOONNEESS DDEELL PPRROOYYEECCTTOO




PRODUCTO O SERVICIO A ADQUIRIR

CÓDIGO DE

ELEMENTO WBS

TIPO DE CONTRATO

PROCEDIMIENTO DE

CONTRATACIÓN

FORMA DE CONTACTAR

PROVEEDORES

REQUERIMIENTO DE ESTIMACIONES INDEPENDIENTES

ÁREA/ROL/PERSONA RESPONSABLE DE LA

COMPRA

MANEJO DE MÚLTIPLES

PROVEEDORES

PROVEEDORES PRE-

CALIFICADOS

CRONOGRAMA DE ADQUISICIONES REQUERIDAS

Planif. Contrat

Solic. Resp.

Selecc. Proveed.

Admin. Contrato

Cerrar Contrato

Del al Del al Del al Del al Del al Realización de pruebas de integración

6.1

Prueba s

Integra

ción

Contrato de precio fijo – Tasa horaria

-Realizar convocatoria -Realizar proceso de selección -Negociar remuneración -Contratar -Realizar pago

- Convocatoria en web especializada s

No GL (Project manager) Departamento de RRHH de la DC Consulting

Proveedor único

No 08/06/ 2009 al 14/06/ 2009

20/10/2 009 al 30/10/2 0009

20/11/20 09 al 30/11/20 09

17/02/20 10 al 16/03/20 10

17/03/20 10



desarrollo de un nuevo software para operadores de comercio exterior - planificación

Documents