Implementación de Herramientas Informáticas - Planificación

FGPR030- Versión 4.0

CONTROL DE VERSIONES
Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

27.03.2011

Motivo

CASO COMPLETO
PLANIFICACIÓN DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de
Herramientas Informáticas

HCDA

DOCUMENTOS INCLUIDOS:
- Documentación de Requisitos.
- Matriz de Trazabilidad de Requisitos.
- Scope Statement.
- WBS del Proyecto.
- Diccionario WBS (simplificado).
- Identificación y Secuenciamiento de Actividades.
- Red del Proyecto.
- Estimación de Recursos y Duraciones.
- Cronograma del Proyecto.
- Plan de Gestión de Costos.
- Costeo del Proyecto.
- Presupuesto del Proyecto – Por Fase y por Entregable.
- Presupuesto en el Tiempo (Curva S).
- Plantilla de Métrica de Calidad.
- Línea Base de Calidad.
- Matriz de Actividades de Calidad.
- Plan de Gestión de la Calidad.
- Organigrama del Proyecto.
- Matriz de Asignación de Responsabilidades.
- Descripción de Roles.
- Cuadro de Adquisiciones del Personal del Proyecto.
- Diagrama de Carga del Personal.
- Plan de Recursos Humanos.
- Plan de Gestión de las Comunicaciones.
- Matriz de Comunicaciones del Proyecto.
- Lista de Stakeholders
- Clasificación de Stakeholders – Matriz Influencia vs. Poder
- Glosario de Terminología.
- Plan de Gestión de Adquisiciones.
- Matriz de Adquisiciones del Proyecto.
- Plan de Gestión de Riesgos.
- Identificación y Evaluación Cualitativa de Riesgos
- Plan de Respuesta a Riesgos.

1


Versión

Hecha por

Revisada por

Aprobada por

1.0

SB

SC

SC

Fecha

Motivo

01.02.2011 Versión Original

DOCUMENTACIÓN DE REQUISITOS
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

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.

Incremento de la recaudación
Generar sensación de riesgo para el operador 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.

Recuperar deuda en cobranza coactiva proveniente de operaciones eras
Implementar herramientas informáticas de apoyo para los ejecutores y auxiliares coactivos
Aprovechar la disponibilidad de la información de Tributos Internos y Tributos eros (cruces
de información)
REQUISITOS FUNCIONALES: DESCRIBIR PROCESOS DEL NEGOCIO, INFORMACIÓN, INTERACCIÓN CON EL PRODUCTO, ETC.
STAKEHOLDER

PRIORIDAD OTORGADA POR
EL STAKEHOLDER

Gerencia de Gestión Muy alta
de
Recaudación
era (Cliente)

CÓDIGO

RE01

Alta

RE02

Alta

RE03

Muy alta

RE04

REQUISITOS NO FUNCIONALES: DESCRIBIR

REQUISITOS
DESCRIPCIÓN

Recibir información oportuna de
operaciones
eras
realizadas por operadores de
comercio exterior con deuda en
cobranza coactiva.
Remitir
semanalmente
a
centrales de riesgo la lista de
deudores en cobranza coactiva.
No permitir la modificación de
domicilio fiscal a operadores de
cobranza coactiva.
Evitar la devolución por pago
indebido o en exceso por tributos
internos
a
operadores
de
cobranza coactiva

REQUISITOS TALES CÓMO NIVEL DE SERVICIO, PERFORMANCE, SEGURIDAD,

ADECUACIÓN, ETC.

STAKEHOLDER

EL STAKEHOLDER

CÓDIGO

REQUISITOS
DESCRIPCIÓN

Gerencia de Gestión Alta
de
Recaudación
era (Cliente)
Sponsor
Alta

RE05

Recibir a tiempo las herramientas
eras según cronograma.

RE06

Alta

RE07

Alta

RE08

Cumplir con los estándares del
MDSI
Cumplir
con
los
tiempos
establecidos
Procurar el
envió
de
la
información dentro del esquema
de seguridad ya existentes.

REQUISITOS DE CALIDAD: DESCRIBIR REQUISITOS RELATIVOS A NORMAS O ESTÁNDARES DE CALIDAD, O LA SATISFACCIÓN Y
CUMPLIMIENTO DE FACTORES RELEVANTES DE CALIDAD.

2


STAKEHOLDER

EL STAKEHOLDER

Gerencia de Gestión
de
Recaudación
era (Cliente)

CÓDIGO

RE09

RE10

CRITERIOS DE ACEPTACIÓN: ESPECIFICACIONES

REQUISITOS
DESCRIPCIÓN

Facilidad en el uso de las
herramientas medible a través de
una encuesta. (4 de 5)
Fiabilidad de la información
mediante el número de reclamos
por operadores indebidamente
reportados (5%)

O REQUISITOS DE RENDIMIENTO, FUNCIONALIDAD, ETC., QUE DEBEN

CUMPLIRSE ANTES DE ACEPTAR EL PROYECTO.

1.
2.
3.
4.
5.
6.

CONCEPTOS
TÉCNICOS
DE CALIDAD
ADMINISTRATIVOS
COMERCIALES
SOCIALES
OTROS

CRITERIOS DE ACEPTACIÓN
Validación de las funcionalidades solicitadas
Aprobación del plan de pruebas de aceptación
Contar con el documento de aceptación del líder usuario
Memorándum con el cual emitió la RIN

REGLAS DEL NEGOCIO: REGLAS PRINCIPALES QUE FIJAN LOS PRINCIPIOS GUÍAS DE LA ORGANIZACIÓN.
Comunicación constante entre el equipo de proyecto, respecto a la ejecución del proyecto
Emitir informes periódicos del rendimiento del proyecto y tomar acciones correctivas de ser el
caso
La gestión del proyecto se realiza de acuerdo a la MGP (Metodología de Gestión de Proyectos de
SUNETA)
El desarrollo de sistemas de información se realiza de acuerdo a la MDSI
IMPACTOS EN OTRAS ÁREAS ORGANIZACIONALES
Reduce el trabajo manual de las áreas de cobranza coactiva
Optimiza el trabajo de las áreas de cobranza coactiva
Elaboración de normatividades que correspondan para conseguir el resultado esperado
IMPACTOS EN OTRAS ENTIDADES: DENTRO O FUERA DE LA ORGANIZACIÓN EJECUTANTE.
Que las centrales de riesgo publiquen la información enviada de acuerdo a lo establecido en
convenio interinstitucional
REQUERIMIENTOS DE SOPORTE Y ENTRENAMIENTO
Capacitación a los ejecutores y auxiliares coactivos en el uso de las herramientas informáticas

SUPUESTOS RELATIVOS A REQUISITOS
Los requisitos del cliente no cambiaran a lo largo del desarrollo del proyecto
Se contará con el personal necesario oportunamente
La alta dirección no cambiará la prioridad del proyecto
RESTRICCIONES RELATIVAS A REQUISITOS
Todas las actividades se realizaran en los ambientes de la SUNETA

3


Versión

Hecha por

1.0

SA

Revisada por

Aprobada por

Fecha

SC

01.02.2011

SB

Motivo

Versión Original

MATRIZ DE TRAZABILIDAD DE REQUISITOS
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de Herramientas
Informáticas

HCDA

ESTADO ACTUAL
Estado
Abreviatura
Activo
AC

NIVEL DE ESTABILIDAD
Estado
Abreviatura
Alto
A

GRADO DE COMPLEJIDAD
Estado
Abreviatura
Alto
A

Cancelado

CA

Mediano

M

Mediano

M

Diferido

DI

Bajo

B

Bajo

B

Adicionado

AD

Aprobado

AP

ATRIBUTOS DE REQUISITOS

CODI
GO

Re04

RE05

DESCRIPCION

Evitar la
devolución por
pago indebido o
en exceso por
tributos internos
a operadores de
comercio
exterior con
deuda en
cobranza
coactiva
Recibir a tiempo
las herramientas
eras según
cronograma.

SUSTE
NTO
DE SU
INCLU
SION

PROPI
ETARI
O

Solicita
do por
la
gerenci
a de
recaud
ación e
ra

Geren
cia de
Recau
dación
era

Sponso
r

Spons
or

FUENTE

PRI
ORI
DAD

V
E
R
SI
O
N

ESTADO
ACTUAL
(AC, CA,
DI, AD,
AP)

TRAZABILIDAD HACIA:

FECHA
DE
CUMPLIM
IENTO

NIVEL DE
ESTABILI
DAD (A,
M, B)

GRADO
DE
COMPLE
JIDAD (A,
M, B)

CRITERI
O DE
ACEPTA
CION

Memoram
dun de
priorizació
n de la
Acciones
Operativa
s de
mejora

Muy
Alta

1.
0

AC

13.Dic.20
10

A

M

Aceptació
n del Plan
de
proyecto

Memoram
dun de
priorizació
n de la
Acciones

Alta

1.
0

AC

Según
entregable

A

M

Aceptació
n del Plan
de
proyecto

NECESIDAD
ES,
OPORTUNI
DADES,
METAS Y
OBJETIVOS
DEL
NEGOCIO
Reducción
del stock de
deuda era
mediante la
retención de
cheques a
devolver al
contribuyent
e
Incrementar
la
recaudación
posterior a la
entrega de

ALCANCE
DEL
PROYECTO
/ENTREGABL
E DEL WBS

DISEÑO DEL
PRODUCTO

DESARROLLO
DEL
PRODUCTO

ESTRATEGIA
DE PRUEBA

Verificar y
pagar deudas
eras en el
proceso de
devolución de
Tributos
Internos.

Cruces son
solicitud de
devolución

Verificación,
antes de
atención de
solicitudes, de
deudas en
cobranza
coactiva de
en cada
servidor.

Invocación a
servicio de
deuda en el
proceso de
devoluciones
de Tributos
Internos

Pruebas en
ambiente de
pruebas

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

OBJETIVOS
DEL
PROYECTO

ESCENARIO
DE PRUEBA

Verificar que a
contribuyentes
con deuda era
no se le permita
la devolución
de tributos

No Aplica

REQUERIMIEN
TO DE ALTO
NIVEL

Cumplir con lo
requerido por el
cliente

Cumplir con lo
requerido por el
cliente

4

Operativa
s de
mejora

RE06

Cumplir con los
estándares del
MDSI

RE07

Cumplir con los
tiempos
establecidos

RE08

Procurar el envió
de la informaciòn
dentro del
esquema de
seguridad ya
existentes.

Sponso
r

Sponso
r

Sponso
r

Spons
or

Memoram
dun de
priorizació
n de la
Acciones
Operativa
s de
mejora

Alta

1.
0

AC

No Aplica

A

M

Aceptació
n del Plan
de
proyecto

Spons
or

Memoram
dun de
priorizació
n de la
Acciones
Operativa
s de
mejora

Alta

1.
0

AC

Según
entregable

A

M

Aceptació
n del Plan
de
proyecto

Spons
or

Memoram
dun de
priorizació
n de la
Acciones
Operativa
s de
mejora

M

Aceptació
n del Plan
de
proyecto

Alta

1.
0

AC

No Aplica

A

las
herramientas
, según el
compromiso
realizado en
el Plan
Estrategico
Institucional
Contar con
aplicaciones
debidamente
documentad
as para su
fácil
mantenimien
to.
Incrementar
la
recaudación
posterior a la
entrega de
las
herramientas
, según el
compromiso
realizado
con el
Ministerio de
Economía y
Finanzas
Garantizar la
seguridad de
la
información
de los
contribuyent
es.

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

Cumplir con lo
requerido por el
cliente

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

Cumplir con lo
requerido por el
cliente

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

No Aplica

Cumplir con lo
requerido por el
cliente

5


Versión

Hecha por

Revisada por

Aprobada por

1.0
2.0

SB
SB

SC
SC

SC
SC

Fecha

Motivo

27.03.2011 Versión Final

SCOPE STATEMENT
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de Herramientas Informáticas

HCDA

DESCRIPCIÓN DEL ALCANCE DEL PRODUCTO
REQUISITOS: CONDICIONES

O CAPACIDADES QUE DEBE CARACTERÍSTICAS: PROPIEDADES FÍSICAS, QUÍMICAS,
POSEER O SATISFACER EL PRODUCTO PARA CUMPLIR CON ENERGÉTICAS, O SICOLÓGICAS, QUE SON DISTINTIVAS DEL
CONTRATOS, NORMAS, ESPECIFICACIONES, U OTROS PRODUCTO, Y/O QUE DESCRIBEN SU SINGULARIDAD.
DOCUMENTOS FORMALMENTE IMPUESTOS.

1. Se debe informar oportunamente a los
ejecutores y auxiliares coactivos sobre las
operaciones eras
realizadas por
importadores con deuda coactiva.
2. Remitir a centrales de riesgo los datos de
importadores con deuda en cobranza
coactiva por operaciones eras

3. El importador debe tener el mismo
domicilio fiscal mientras duren las acciones
de cobranza coactiva.

4. Se deben integrar procesos de los
negocios de Tributos Internos y Tributos
eros.

1. La notificación electrónica debe llegar a la
casilla del ejecutor y/o auxiliar a más tardar
luego de 15 minutos de realizada la operación
era.
2. La información preliminar se debe generar en
forma automática, luego de la depuración la
consolidación también debe realizarse de
manera automática, es decir sin necesidad de
que alguna persona realice alguna acción.
3. Cuando se registre un expediente coactivo, en
forma automática se debe bloquear la
posibilidad de modificación de domicilio fiscal,
cuando se concluya el expediente se debe
levantar el bloqueo.
4. No se deben realizar devoluciones por pagos
indebidos o en exceso si el solicitante tiene
deudas en cobranza coactiva por operaciones
eras.

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
1. TÉCNICOS
2. DE CALIDAD
3. ADMINISTRATIVOS
4. COMERCIALES

CRITERIOS DE ACEPTACIÓN

Validación de las funcionalidades solicitadas
Aprobación del plan de pruebas de aceptación
Contar con el documento de aceptación del líder usuario
Memorándum con el cual emitió la RIN (Requerimiento Informático de
Negocio)

5. SOCIALES

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

6


2.0 Análisis de Requerimientos - Informe de Definición (F2) con numeral 1 completo.
del Sistemas de Información
- Documento R2A - Lista de Verificación 01 (Checklist)
- Acta de aceptación del equipo usuario
3.0 Diseño del Sistema de - Informe de Definición (F2) con numeral 2 completo
Información
- Documento R2D - Lista de Verificación 01 (Checklist)
4.0 Construcción del Software - Pase a Producción autorizado
- Informe de Pruebas de Desarrollo
- Instructivo de Instalación del Pase
- Manual de usuario
5.0 Pruebas de Sistemas y - Registro de observaciones detectadas
- Informe de pruebas del sistema
Conformidad de Usuario
- Informe de conformidad de usuario
6.0
Implantación
y - Software instalado en ambiente de producción
Estabilización del software
- Manual de usuario publicado en intranet
7.0 Capacitación

- Archivo de presentación elaborado en PowerPoint
- Lista de asistencia a capacitación realizada

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 incluye la actualización de las circulares de trabajo
2. No incluye la modificación de convenios con centrales de riesgo
3. No se considera deuda administrada por la Agrupación Nacional Adjunta
4. No se adquirirán nuevos servidores de correo
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

Los servidores de aplicativos y de base de
datos de los ambientes de pruebas no tienen
las mismas características que los servidores
de los ambientes de producción.
El proyecto debe culminar como máximo el
31.03.2011
Todas las actividades relacionadas al
desarrollo de sistemas se deben realizar en
instalaciones de la SUNETA
SUPUESTOS DEL PROYECTO: FACTORES

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

CONSIDERAN VERDADEROS, REALES O CIERTOS.

INTERNOS A LA ORGANIZACIÓN

AMBIENTALES O EXTERNOS A LA ORGANIZACIÓN

Las implementaciones realizadas al software Las entidades externas (Centrales de Riesgo) ya
son sobre la última versión implantada para tienen el software para publicar la información
evitar pérdida de funcionalidad
remitida por la SUNETA, la publicación
se realizará de acuerdo a convenio.
Se renovará los contratos de los analistas y No se publicarán normas dadas por externos que
programadores asegurando contar con ellos modifiquen las bases legales bajo las cuales se
hasta el término del proyecto.
sustenta el proyecto.
El proyecto se mantendrá como prioridad
Institucional
7


ONTROL DE VERSIONES
Versión

Hecha por

Revisa
sada por

Aprobada por

1.0
2.0

SB
EP

SC
SB

SC
SB

Fecha

Motivo

n
n

WBS
NOMBRE DEL PROYECTO

Implementación de

SIGLAS DEL PROYE
ECTO

HCDA

8


Versión

Hecha por

Revisada por

Aprobada por

1.0
2.0

SB
EP

SC
SB

SC
SB

Fecha

Motivo


DICCIONARIO WBS (simplificado)
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

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.

1.1.1 Project
Charter
1.1 Iniciación

FASE 1: Gestión del Proyecto

1.1.2 Scope
Statement

1.2 Plan del
Proyecto

1.3 Informe de
Estado del
Proyecto
1.4 Reunión de
Coordinación
Semanal

Documento que detalla: la definición del
proyecto, definicióndel producto,
requerimiento de los stakeholders,
necesidades del negocio, finalidad y
justificación del proyecto, cronograma de
hitos, organizaciones que intervienen,
supuestos, restricciones, riesgos, y
oportunidades del proyecto.
Documento que establece el trabajo que
debe realizarse, y los productos
entregables que deben producirse.

Documento formalmente aprobado que define cómo se ejecuta,
supervisa y controla un proyecto. Puede ser resumido o
detallado y estar compuesto por uno o más planes de gestión
subsidiarios y otros documentos de planificación.
Contiene lo siguiente:
- WBS
- DWBS.
- Cronograma
- Presupuesto
- Línea Base de Calidad
- Plan de Gestión de Calidad
- Organización del Proyecto
- RAM
- Plan de Gestión de Recursos Humanos
- Plan de Gestión de Comunicaciones
- Plan de Respuesta a Riesgos
- Plan de Gestión de Adquisiciones
Documento que informará el estado de avance de cada
entregable del proyecto (en cuanto a costos, tiempos, alcance y
calidad), semanalmente se entregará un informe.
Reunión de Coordinación Semanal, del equipo de proyecto, en
las oficinas de SUNETA, para informar el avance del proyecto, y
presentar los informes de la semana.

9

FASE 3: Diseño del Sistema de
Información

FASE 2: Análisis de Requerimientos del Sistemas de Información


Para el cierre del proyecto se realizará una reunión con el equipo
del proyecto, donde el PM deberá presentar los siguientes
documentos:
- Informe de Performance del Proyecto.
1.5 Cierre del
- Lecciones Aprendidas del Proyecto.
proyecto
- Métricas del Proyecto.
- Acta de Aceptación del Proyecto.
- Archivo Final del Proyecto
Parte del documento denominado informe de definición en el que
se especifican las siguientes características del sistema de
2.1 Modelamiento información a implementar:
de Requerimientos
- Alcance del sistema de información
del Sistema de
- Diagrama de contexto del sistema de información
Información
- Catálogo de requerimientos funcionales
- Catálogo de requerimientos no funcionales
Complementa el Informe de Definición para la fase de análisis,
incluyendo la siguiente información:
- Diagrama de casos de uso
- Especificación de los casos de uso del sistema
2.2 Análisis de los
casos de uso
- Especificación de interfaces de usuario
- Especificación del comportamiento dinámico de
interfaces
- Especificación de formatos de impresión
2.3 Interfaces con incluyendo información correspondiente a interfaces con otros
otros sistemas
sistemas (Nombres de los sistemas relacionados, responsables
de los sistemas, formatos de datos de intercambio, entre otros)
2.4 Migración de
datos y carga
incluyendo información correspondiente a la migración de datos
inicial
y carga inicial
2.5 Análisis de
consistencia y
verificación de
requerimientos

Corresponde a la lista de verificación de la calidad técnica y
consistencia de los modelos, en la que se evidencias las
conformidades y no conformidades respecto al modelo revisado.
Documento en el que se evidencia en forma literal que el equipo

2.6 Aprobación del
usuario y coordinador del proyecto, dan conformidad a la
Análisis

presentación realizada respecto al análisis del sistema.
Actividad mediante la cual se define y documenta el
3.1 Definición de la
particionamiento físico del sistema de información. Se
arquitectura del
representa los componentes del sistema a través del Diagrama
sistema
de Despliegue.
Actividad mediante la cual se define y documenta el diseño de la
3.2 Diseño de la
arquitectura de
arquitectura de soporte, a través del diagrama de clases y de
soporte
interacción de objetos.
Se realiza el diseño de la Realización de los Casos de Uso
(Grafico); por cada caso de uso relevante se realiza el diagrama
3.3 Diseño
orientado a objetos de Interacción de Objetos (Diagrama de Secuencia o Diagrama
de Colaboración), tomando como base las clases de diseño.
3.4 Diseño físico de Actividad mediante la cual se genera y documenta el diseño
datos
físico de datos, usando como software el Power Designer.
Actividad mediante la cual se define y documenta lo siguiente:
3.5 Generación de
- Especificaciones del entorno de construcción
especificaciones de
- Gráfico de diagrama de componentes y/o despliegue
construcción
- Especificaciones de construcción

10


FASE 5: Pruebas de Sistemas y

FASE 4: Construcción del Software

Actividad mediante la cual se define y documenta lo siguiente:
- Especificación del Entorno de Migración y Carga Inicial
de Datos.
- Definición de Procedimientos de Migración y Carga
3.6 Migración y
Inicial.
carga inicial de
datos
- Diseño detallado de Módulos de Migración y Carga
Inicial.
- Especificación Técnica de las Pruebas de Migración y
Carga Inicial
Se especifican los
requerimientos relacionados a la
documentación de usuarios:
3.7 Detalle de
- Manuales de usuario
documentación de
usuario
- Ayudas en línea
- Tutoriales
4.1 Presentación
del Informe de
Definición

Actividad que consiste en exponer el Informe de Definición, al
equipo que construirá y probará el sistema informático.

Actividad que consiste en escribir las líneas de programa del
sistema informático, en base a lo detallado en el Informe de
Definición;
Actividad que consiste en integrar el trabajo de los diferentes
4.3 Integración de
programadores en un solo computador y generar el archivo
código fuente y
ejecutable mediante el cual los usuarios podrán acceder al
pruebas de
sistema informático implementado; además de ello realizar se
desarrollo
diferentes opciones del sistema informático.
Actividad que consiste en elaborar los siguientes documentos:
- Informe de Pruebas de Desarrollo
4.4 Elaboración de
- Documentación del usuario (según actividad 3.7)
documentación
- Instructivo de Instalación del Pase a Producción
- Pase a Producción
Convocar al equipo usuario y analistas de calidad para
presentarles el software y recoger las observaciones que
4.5 Presentación
pudieran tener y se evalúa las que corresponderían atender
del software
dentro del proyecto.
5.1 Elaborar el Plan Actividad mediante la cual se definen y especifican los casos de
de Pruebas de
prueba que se ejecutarán y documentarán durante la etapa de
Sistemas
Pruebas del sistema (Actividad 5.3).
Actividad que consiste en realizar el checklist de todos los
5.2 Verificación de
documentos necesarios para iniciar las pruebas del sistema,
entregables
incluidas las pruebas de aceptación.
Actividad que consiste en ejecutar y documentar el plan de
pruebas elaborado en la actividad 5.1; registrando y
5.3 Pruebas de
comunicando al analista de sistemas responsables las
Sistemas
observaciones detectadas para su corrección.
Actividad que consiste en convocar al coordinador del proyecto y
el equipo usuario a fin de realizar las pruebas del sistema y
5.4 Pruebas
verifiquen que sus requerimientos se encuentran cubiertos por el
Aceptación
sistema; el documento resultante es el acta de aceptación del
sistema.
Actividad que consiste en derivar mediante el sistema SIGESA el
Pase a Producción a la División de Operaciones de
5.5 Enviar Pase a
Infraestructura Tecnológica; para su instalación en los servidores
Producción
correspondientes.
4.2 Programación
del Código Fuente

11

FASE 7:
Capacitación

FASE 6: Implantación y
estabilización del software


Documento que evidencia la instalación del pase a producción,
de manera que las herramientas de cobranza implementadas, se
encuentre disponible para los ejecutores, auxiliares coactivos y
6.1 Instalación de otros usuarios según el alcance determinado. Incluye además la
Pases a Producción siguiente documentación:
- Log de instalación del pase a producción
- Log de ejecución de base de datos
Actividad que consiste en monitorear el adecuado
funcionamiento de las herramientas informáticas implementadas,
6.2 Estabilización
registrando y dando solución oportuna a los incidentes
del Software
reportados por los usuarios del sistema.

Convocar a los usuarios potenciales de la herramienta y
exponerles la forma de uso; indicarles el lugar virtual donde
7.1 Capacitación a
pueden encontrar el manual del sistema.
usuarios del
sistema

12


Versión

Hecha por

Rev
Revisada por

Aprobada por

1.0
2.0

EP
EP

SA
SB

SB
SB

Fecha

Motivo


IDENTIFICACIÓN Y SECUENCIAMIENTO DE ACTIVIDADES
NOMBRE DEL PROYECTO
O

Implementación de
PAQUETE DE TRABAJO
CÓDIGO
WBS
1.1.1

NOMBRE
Project
Charter

CÓDIG
O

1.1.1.A01
1.1.1.A02
1.1.1.A03

1.1.2

Scope
Statement

1.1.2.A01

1.1.2.A02
1.1.2.A03
1.2
1.3

1.4

1.5

Plan del
proyecto

1.2.A01

Informe de
Estado del
Proyecto
Reunión de
Coordinación

1.3.A01

Cierre
del
Proyecto

1.5.A01

1.4.A01

SIGLAS DEL PROYECTO

HCDA

ACTIVIDAD DEL PAQUETE DE TRABAJO
ALCANCE DEL
NOMBRE
TRABAJO DE LA
A
ACTIVIDAD
Reunión con el
Reunión inicial de
sponsor
trabajo
Elaborar Project
Redactar el
Charter
documento de inicio
o
Revisar y aprobar e
el
Revisar Project
Project Charter
Charter
Reunión de
Reunión con el
información con el
Sponsor
cto
sponsor del proyec
Elaborar el Scope
Elaborar el docume
ento
Statement
del Scope Stateme
ent
Revisar y aprobar e
el
Revisar el Scope
Statement
Scope Statement
Redactar el plan de
el
Elaborar el plan del
proyecto
proyecto

ACT. PREDECESORA
TIPO DE RELACIÓN
ADELANTO/ATRASO

RESTRICCIONES
O SUPUESTOS

FECHA
IMPUES
TA

PERSONA

ZONA

RESPONSABLE

GEOGRÁFICA

EP/CP
1.1.1.A01

EP/CP

1.1.1.A02

EP/CP
EP/CP/LU

1.1.2.A01

LU/DP/LT/CP

1.1.2.A02

DP/CP
DP/CP/LU/LT

Elaborar informe del
Estado del Proyecto

Redactar el informe de
e
estado del proyecto
cto

SP

Realizar reunión de
Coordinación semanal

Reunión de
nal
coordinación seman
del equipo del
proyecto
Redactar
documentos de
cierre del proyecto

EP/LT/LU

Elaborar
documentos de
cierre del proyecto

CP/LT/LU

TIPO DE
ACTIVIDAD
(TIME DRIVEN,
RESOURCE
DRIVEN)

SECUENCIAMIENTO DE ACTIVIDADES
DENTRO DEL PAQUETE DE TRABAJO

Oficinas de
SUNETA
Oficinas de
SUNETA
Oficinas de
SUNETA
Oficinas de
SUNETA

Time driven

Oficinas de
SUNETA
Oficinas de
SUNETA
Oficinas de
SUNETA

Resource
driven
Resource
driven
Resource
driven

Oficinas de
SUNETA

Resource
driven

1.3.A01

Oficinas de
SUNETA

Resource
driven

1.4.A01

Oficinas de
SUNETA

Resource
driven

1.5.A01

1.1.1.A01

Resource
driven
Resource
driven
Time driven

1.1.1.A02
1.1.1.A03

1.1.2.A01
1.1.2.A02
1.1.2.A03

1.2.A01

13


2.1

Modelamien
to de
Requerimie
ntos del
Sistema de
Información

2.1.A01

2.1.A02

2.1.A03

2.1.A04

2.1.A05

2.2

Análisis de
los casos
de uso

Revisión de la RIN con
el coordinador y equipo
usuario
Elaborar diagrama de
contexto del sistema de
información
Elaborar catálogos de
requerimientos
funcionales y no
funcionales
Elaborar los diagramas
y especificaciones de
caso de uso
Especificaciones de
interfaces, perfiles y
formatos de impresión

2.4

2.5

2.6

Análisis de Paquetes

2.2.A02

2.3

2.2.A01

Análisis de Clases

Interfaces
con otros
sistemas

2.3.A01

Especificaciones de
interfaces con sistemas
relacionados

Migración
de datos y
carga inicial

2.4.A01

Análisis de
consistencia
y
verificación
de
requerimien
tos
Aprobación
del Análisis

2.5.A01

2.5.A02

2.6.A01

Especificaciones de
migración de datos y
carga inicial

Verificación de la
calidad técnica de los
modelos
Análisis de consistencia
técnica entre modelos

Revisión del análisis y
elaboración del acta

Reunión de trabajo
jo
para revisar y
completar la RIN
Graficar el de
contexto del sistem
ma
de información
Identificar y listar lo
os
requerimientos
funcionales y no
funcionales
Graficar y detallar
los casos de uso
Elaborar prototipos
s
de interfaces, definir
ir
perfiles de acceso y
so
definir formatos de
e
impresión
Identificar y graficar
r
los paquetes de
sistemas
Identificar y graficar
r
las clases del
sistema
Identificar y
documentar las
interfaces con
sistemas
relacionados
Identificar y
documentar las
especificaciones de
e
migración de datos y
carga inicial
Ejecutar el checklist
list
de validación técnic
ca
de los modelos
Documentar la
consistencia técnica
ica
entre modelos
Presentar el
resultado del análisis
lisis
al equipo usuario y
coordinador del
proyecto

1.2 A01

CP/LU/AS1/A
S2

Oficinas de
SUNETA

Resource
driven

2.1.A01

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.1.A01

2.1.A02

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.1.A02

2.1.A03

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.1.A04

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.1.A03

2.1..A04

2.1.A05

2.1.A05

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.2.A01

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.2.A02

AS1/AS2

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA

Resource
driven

2.3.A01

AS1/AS2

2.2.A01
.2.2A02

2.3.A01

2.4.A01

2.4.A01

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.5.A01

AS1/AS2

Oficinas de
SUNETA

Resource
driven

2.5.A02

CP/LT/LU

Oficinas de
SUNETA

Resource
driven

2.5.A01
.2.5A02

2.6.A01

14


3.1

Definición
de la
arquitectura
del sistema

3.1.A01
3.1.A02
3.1.A03

3.1.A04

3.2

3.3

3.4

Diseño de
la
arquitectura
de soporte
Elaboración
de
diagramas
Diseño
físico de
datos

3.2.A01

3.3.A01

3.4.A01
3.4.A02

3.4.A03

3.5

Generación
de
especificaci
ones de
construcció
n

3.5.A01

3.5.A02

3.5.A03

3.6

Migración y
carga inicial
de datos

3.6.A01

3.6.A02

3.7

Detalle de
documentac
ión de
usuario

3.7.A01

Definición de niveles de
arquitectura
Identificación de
subsistemas de diseño
Elaboración de
catálogos de
excepciones
Especificación del
entorno tecnológico del
sistema
Elaboración de
diagramas de clases y
de interacción de
objetos
Elaboración de
diagramas de secuencia
Diseño del modelo físico
de datos
Especificaciones de los
caminos de acceso a
datos
Estimación de
volúmenes de tablas
Especificación del
entorno de construcción

Elaboración de los
diagramas de
componentes y
despliegue
Elaboración de las
especificaciones de
construcción
Definición de
procedimiento de carga
inicial
Especificación técnica
de las pruebas de carga
inicial
Especificaciones de los
documentos de usuarios
a elaborar

Graficar los niveles
s
de arquitectura
Identificar los
subsistemas
documentar el
catálogo de
excepciones
Documentar el
entorno tecnológico
ico
del sistema
Elaborar los
diagramas de clase
es
y de interacción

2.6.A01

AS1/AS2

3.1.A01

AS1/AS2

3.1.A02

AS1/AS2

3.1.A03

AS1/AS2

Elaborar los
diagramas de
secuencia
Elaborar el modelo
o
físico de datos
Definir y documenta
ar
los privilegios a las
s
tablas
Estimar la cantidad
d
de registros anual
para cada tabla
Documentar la
a
configuración para
las PCs de los
programadores
Elaborar los
diagramas de
componentes y
despliegue
Documentar las
e
especificaciones de
construcción
Documentar el
procedimiento de
carga inicial
Documentar como
o
se probará la carga
a
inicial
Detallar que
documentos de
usuario se deben
elaborar

3.2.A01

Oficinas de
SUNETA
Oficinas de
SUNETA
Oficinas de
SUNETA

Resource
driven
Resource
driven
Resource
driven

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA
Oficinas de
SUNETA

Resource
driven
Resource
driven

3.1.A01

3.1A02

3.1.A03

3.1.A04

AS1/AS2

AS1/AS2

3.3.A01

AS1/AS2

3.4.A01

AS1/AS2

3.4.A02

AS1/AS2

Oficinas de
SUNETA

AS1/AS2

Oficinas de
SUNETA

3.2.A01

3.3.A01

3.4.A01
3.4.A02

Resource
driven

3.4.A03

3.1.A04

Resource
driven

3.4.A03

3.5.A01

3.5.A01

AS1/AS2

Oficinas de
SUNETA

Resource
driven

3.5.A02
3.5.A03

3.5.A02

AS1/AS2

Oficinas de
SUNETA

Resource
driven

3.5.A03

AS1/AS2

Oficinas de
SUNETA

Resource
driven

3.6.A01

AS1/AS2

Oficinas de
SUNETA

Resource
driven

3.6.A02

AS1/AS2

Oficinas de
SUNET
A

Resource
driven

15

3.6.A01
3.6A02

3.7.A01


4.1

Presentació
n del
Informe de
Definición
Programaci
ón del
código
fuente

4.3

4.4

Integración
de código
fuente y
pruebas de
desarrollo
Elaboración
de
documentac
ión

Reunión explicativa de
presentación de análisis
y diseño

Presentar los
prototipos y reglas
s
identificadas

3.7.A01

4.2.A01

Programación J2EE

Programación
cliente/servidor

Generar las líneas
de código en
lenguaje de
programación Java
va
Generar las líneas
de código en
lenguaje de
programación Visua
al
Fox Pro
Integrar las líneas d
de
código trabajadas
por los
programadores java
a

4.1.A01

4.2.A02

4.2

4.1.A01

4.1.A01

Documentar los
casos de prueba
verificados en
ambiente de
desarrollo
l
Elaborar el manual
de usuario en
formato usado por la
institución
Elaborar el tutorial
para el usuario
Elaborar el
instructivo de
se
instalación del pase
a producción
Generar el Pase a
Producción y
remitirlo para
autorización del líde
er
usuario
Mostrar las opcione
nes
del software a los
analistas que
realizan las pruebas
s
del sistema

4.3.A01

4.3.A01

4.4.A01

4.4.A02

4.4.A03
4.4.A04

Integración de código
fuente y pruebas
unitarias

Elaboración de informe
de pruebas de
desarrollo

Elaboración de manual
de usuario

Elaboración del tutorial
para el usuario
Elaboración del
instructivo de instalación

4.4.A05

4.5

Presentació
n del
software

Generación y envío de
pases a producción

4.5.A01

Presentación del
software a analistas de
calidad

AS1/AS2/PJ1
/PJ2/PVF

Oficinas de
SUNETA

Resource
driven

PJ1/PJ2

Oficinas de
SUNETA

Resource
driven

PVF

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA

Resource
driven

4.1.A01

4.2.A01

4.2.A01

PJ1/PJ2/PVF

PJ1/PVF

.4.2.A02

4.3.A01

4.4.A01

4.3.A01

PJ2

4.4.A02

PJ2

4.4.A01

PJ1/PVF

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNAT
Oficinas de
SUNETA

Resource
driven
Resource
driven

4.4.A04

PJ1/PVF

Oficinas de
SUNETA

Resource
driven

4.3.A01

AS1/AS2

Oficinas de
SUNETA

4.4.A02

4.4.A03

4.4..A04

Resource
driven

4.4.A05

4.5.A01

16

5.1

5.2

5.3

Elaborar el
Plan de
Pruebas de
Sistemas
Verificación
de
entregables
Prueba del
Sistema

5.1.A01

5.2.A01

Elaborar el Plan de
Pruebas de Sistemas

Checklist de entregables

Pruebas funcionales y
no funcionales

5.4.A01

Elaborar plan de
pruebas de aceptación

5.4.A02

Pruebas de
aceptación

Pruebas de instalación
del software

5.3.A02

5.4

5.3.A01

Convocar a usuario a
pruebas de aceptación

5.4.A03

5.5

Enviar pase
para
instalación

Realizar pruebas de
aceptación

5.5.A01

Derivar Pases a
Producción Mod. W eb a
DOIT

5.5.A02

Derivar Pases a
Producción Mod. VFP a
DOIT

os
Especificar los caso
de prueba que se
verificarán en las
a
pruebas del sistema
list
Realizar el checklist
de entregables

3.7.A01

Oficinas de
SUNETA

Resource
driven

Oficinas de
SUNETA

Resource
driven

as
Realizar las prueba
de instalación del
software
Realizar las prueba
as
funcionales y no
funcionales
Especificar los caso
os
de pruebas que se
verificarán en las
pruebas de
aceptación
Coordinar con el
equipo y usuario y
generar la
convocatoria para
las pruebas de
aceptación
Ejecutar las prueba
as
de aceptación y
elaborar el acta
correspondiente
Derivar a DOIT los
s
pases a producción
n
correspondientes a
aplicativos Java
Derivar a DOIT los
s
pases a producción
n
correspondientes a
aplicativos Visual
Fox Pro

5.2.A01

AC

Oficinas de
SUNETA

Resource
driven

5.3.A01

AC

Oficinas de
SUNETA

Resource
driven

5.3.A02

AC

Oficinas de
SUNETA

Resource
driven

5.4.A01

AC

Oficinas de
SUNETA

Resource
driven

4.4 A05

AC

AC

5.1.A01

5.2.A01

5.3.A01
5.3.A02

5.4.A01
5.4.A02
5.4.A03

5.4.A02

AC/LU

Oficinas de
SUNETA

Resource
driven

5.4.A03

AC

Oficinas de
SUNETA

Resource
driven

5.5.A01

AC

Oficinas de
SUNETA

Resource
driven

5.5.A01

17

5.5.A02

6.1

Instalación
de Pases a
Producción

6.1.A01

Instalación de pases
web

6.1.A02

6.2

7.1

Instalación de pases
FoxPro

Estabilizaci
ón del
software

6.2.A01

Monitoreo post
instalación y atención de
incidencias

Capacitació
n a usuarios
del sistema

7.1.A01

Elaboración de la
presentación (Archivo
ppt)

7.1.A02

Enviar o publicar
convocatoria

7.1.A03

Ejecución de la
capacitación

Instalación de los
componentes
informáticos en los
s
servidores de
aplicativos java de
producción
Instalación del
ejecutable en los
servidores de las
operativas
Monitorear el uso y
comportamiento de
del
sistema; registro y
atención de
incidencias
detectadas.
Elaborar la
presentación de las
s
herramientas
informáticas usando
o
PowerPoint
Enviar o Publicar la
a
convocatoria a la
capacitación y
registrar la lista de
e
asistentes
Exponer el uso de l
la
herramienta
informática,
resaltando los
beneficios para la
institución

5.5.A01

OP

Oficinas de
SUNETA

Resource
driven
6.1.A01
6.1.A02

5.5.A02

OP

Oficinas de
SUNETA

Resource
driven

5.5.A01

LT/LU

Oficinas de
SUNETA

Resource
driven
6.2.A01

4.4 A03

PJ2

Oficinas de
SUNETA

Resource
driven

PJ2

Oficinas de
SUNETA

Resource
driven

7.1.A01

7.1.A01

7.1.A02
7.1.A03

7.1.A02

AS1

18

Oficinas de
SUNETA

Resource
driven


Versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

1.0
2.0

EP
EP

SB
SB

SB
SB

05.03.2011
27.03.2011

Versión Original
Versión Final

RED DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

1.3

1.4

1.1

1.5

1.2
2.0

3.0

4.0

7.0
5.0

6.0

19


1.1
1.1.1

1.1.2

2.0
2.1

2.3

2.2

2.5

2.4

2.6

3.0

4.0

3.3

3.2

3.1

4.1
1

4.2

3.5

3.4

4.3

4.4

3.6

3.7

4.5

5.2

5.0
5.1

5.3

5.4

5.5

20


Versión Hecha por Revisada por Aprobada por
Fecha
Motivo
2.0
SA
SB
SC

ESTIMACIÓN DE RECURSOS Y DURACIONES
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

Tipo de Recurso: Personal
Entregable - Actividad
Nombre del Recurso

1.1.1 Project Charter

Trabajo
(HRSHOM)

Tipo de Recurso: Materiales o Consumibles
Duración
(HRS)

32 horas
EP,CP

8 horas

EP,CP

16 horas

EP,CP

8 horas

Nombre
de
Recurso

Cantidad

Supuestos y
Base de
Estimación

Forma de
Cálculo

8

118 horas

Forma
de
Cálculo

16

1.1.1 A03 Revisar project charter

Supuestos y
Base de
Estimación

8

1.1.1 A02 Elaboración del project charter

Cantidad

32

1.1.1 A01 Reunión con el sponsor

Nombre
de
Recurso

Tipo de Recurso: Materiales o No Consumibles

88

1.1.2 Scope Statement

LU,EP,CP

6 horas

8

1.1.2 A02 Elaboración del scope statement

EP,CP,LU

96 horas

64

1.1.2 A03 Revisar scope statement

EP,CP

16 horas

16

224 horas

56

224 horas

56

1.3 Informes de Estado del proyecto

96 horas

1928

1.3 A01 Elaborar y distribuir informes de estado
del proyecto

96 horas

1928

1.2 Plan del Proyecto
1.2 A01 Elaborar Plan del Proyecto

LU,EP,LT,CP

del proyecto 1

SI

8 horas

8

del proyecto 2

SI

8 horas

8

22

del proyecto 3

SI

8 horas

8

del proyecto 4

SI

8 horas

8

del proyecto 5

SI

8 horas

8

del proyecto 6

SI

8 horas

8

del proyecto 7

SI

8 horas

8

del proyecto 8

SI

8 horas

8

del proyecto 9

SI

8 horas

8

del proyecto 10

SI

8 horas

8

del proyecto 11

SI

8 horas

8

del proyecto 12

SI

8 horas

8

282 horas

1.4 Reunión de coordinación semanal

1848

1.4 A01 Realizar reunión de avance 1

LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8

23


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8


LT,EP,LU

6 horas

8

24


6 horas

8

16 horas

16

16 horas

16

296 horas

136

AS1,AS2,CP,EP,LU

40 horas

8

2.1.A02 Elaborar diagrama de contexto del
sistema de información

AS1,AS2

32 horas

16

2.1.A03 Elaborar catálogos de requerimientos
funcionales y no funcionales

AS1,AS2

80 horas

40

AS1,AS2

96 horas

48

1.5 Cierre del proyecto
1.5 A01 Elaborar documentos de Cierre del
proyecto

LT,EP,LU

LU,EP,LT,CP

2.1 Modelamiento de Requerimientos del
Sistema de Información
2.1.A01 Revisión de la RIN con el coordinador y
equipo usuario

2.1.A04 Elaborar los diagramas y
especificaciones de caso de uso
2.1.A05 Especificaciones de interfaces, perfiles y
formatos de impresión

AS1,AS2

2.2.A01 Análisis de clases

AS1,AS2

2.2.A02 Análisis de Paquetes

AS1,AS2

2.3 Interfaces con otros sistemas
2.3.A01 Especificaciones de interfaces con
sistemas relacionados
2.4 Migración de datos y carga inicial
2.4.A01 Especificaciones de migración de datos y
carga inicial
2.5 Análisis de consistencia y verificación de
requerimientos
2.5.A01 Verificación de la calidad técnica de los
modelos
2.5.A02 Análisis de consistencia técnica entre
modelos
2.6 Aprobación del Análisis
2.6.A01 Revisión del análisis y elaboración del
acta

48 horas

24

64 horas

2.2 Análisis de los casos de uso

32

32 horas

16

AS1,AS2

LT,CP,LU

32 horas

16
16

32 horas

16
16

16 horas

8

16 horas

8

12 horas

AS1,AS2

16

32 horas

AS1,AS2

16

32 horas

AS1,AS2

32 horas
32 horas

8

12 horas

8

144 horas

3.1 Definición de la arquitectura del sistema

72

3.1.A01 Definición de niveles de arquitectura

AS1,AS2

32 horas

16

3.1.A02 Identificación de subsistemas de diseño

AS1,AS2

48 horas

24

25

3.1.A03 Elaboración del catálogo de excepciones
3.1.A04 Especificación del entorno tecnológico
del sistema

AS1,AS2
AS1,AS2

AS1,AS2

32 horas

16
40

AS1,AS2

80 horas

40

112 horas

3.3 Diseño orientado a objetos
3.3.A01 Elaboración del diagramas (de
secuencia, colaboración y de clases)

16

80 horas

3.2 Diseño de la arquitectura de soporte
3.2.A01 Elaboración de diagrama de clases y de
interacción de objetos

32 horas

40

112 horas

40

160 horas

3.4 Diseño físico de datos

80

3.4.A01 Diseño del modelo físico de datos
3.4.A02 Especificación de los caminos de acceso
a los datos

AS1,AS2

80 horas

40

AS1,AS2

32 horas

16

3.4. A03 Estimación de volúmenes de tablas
3.5 Generación de especificaciones de
construcción
3.5.A01 Especificación del entorno de
construcción
3.5.A02 Elaboración de los diagramas de
componentes y despliegue
3.5.A03 Elaboración de especificaciones de
construcción

AS1,AS2

48 horas

24

224 horas

120

AS1,AS2

16 horas

8

AS1,AS2

64 horas

32

AS1,AS2

144 horas

80

32 horas

16

16 horas

8

3.6 Migración y carga inicial de datos
3.6.A01 Definición de procedimiento de carga
inicial
3.6.A02 Especificación técnica de las pruebas de
carga inicial
3.7 Detalle de documentación de usuario
3.7.A01 Especificaciones de los documentos de
usuarios a elaborar
4.1 Presentación del Informe de Definición
4.1 A01 Reunión explicativa de presentación de
análisis y diseño

AS1,AS2
AS1,AS2

AS1,AS2

4.2.A02 Programación cliente/servidor
4.3 Integración de código fuente y pruebas de
Desarrollo

8
8

AS1,AS2,PJ1,PJ2,PVF

PJ1,PJ2
PVF

16 horas

8

40 horas

4.2 Programación del código fuente
4.2.A01 Programación J2EE

16 horas
16 horas

8

40 horas
1,496
horas
1,264
horas

8
640

232 horas

240

216 horas

80

640

26

4.3 A01 Integración de código fuente y pruebas
Unitarias

216 horas

80

120 horas

72

PJ1,PVF

32 horas

24

4.4 A02 Elaboración del manual de usuario

PJ2

32 horas

40

4.4 A03 Elaboración del tutorial para el usuario

PJ2

24 horas

32

PJ1,PVF

16 horas

16

16 horas

8

16 horas

8

4.4 Elaboración de documentación
4.4 A01 Elaboración de informe de pruebas de
desarrollo

4.4 A04 Elaboración del instructivo de instalación
4.4 A05 Generación y envío de pases a
producción
4.5 Presentación del software
4.5 A01 Presentación del software a analistas de
calidad

PJ1,PJ2,PVF

PJ1,PVF

AS1,AS2

16 horas

8

120 horas

120

120 horas

120

8 horas

8

AC

8 horas
254.4
horas

8

5.3.A01 Pruebas de instalación del software

AC

5.3.A02 Pruebas funcionales y no funcionales

AC

8 horas
246.4
horas

320

5.1 Elaborar el Plan de Pruebas de Sistemas
5.1.A01 Plan de Pruebas de Sistemas

AC

5.2 Verificación de entregables
5.3.A01 Checklist de entregables
5.3 Pruebas de Sistemas

5.4 Pruebas de Aceptación
5.4.A01 Elaborar plan de pruebas de aceptación
5.4.A02 Convocar a usuario a pruebas de
aceptación
5.4.A03 Realizar pruebas de aceptación
5.5 Enviar pase para instalación
5.5.A01 Derivar Pases a Producción Mod. Web a
DOIT
5.5.A02 Derivar Pases a Producción Mod. VFP a
DOIT

8

48 horas

56

AC

24 horas

24

AC

8 horas

8

AC,LU

AC
AC

16 horas

24

16 horas

16

8 horas

8

6.1.A01 Instalación de pase web

OP

6.1.A02 Instalación de pase FoxPro

OP

8 horas

8

16 horas

6.1 Instalación de Pases a Producción

6.2 Estabilización del software
6.2.A01 Monitoreo post instalación y atención de
incidencias

328

16

8 horas

8

LT,LU

8 horas

8

120 horas

240

120 horas

240

27

7.1 Capacitación a usuarios del sistema
7.1.A01 Elaboración de la presentación (Archivo
ppt)
7.1.A02 Enviar o publicar convocatoria
7.1.A03 Ejecución de la capacitación

24 horas

24

PJ2

8 horas

8

PJ2

8 horas

8

AS1

8 horas

8

28


Versión Hecha por Rev
Revisada por Aprobada por
Fecha
1.0
SA
SB
SC
01.02.2010
2.0
SA
SB
SC
27.03.2011

Motivo
Versión Original
Versión Final

CRONOGRAMA DEL PROYECTO
NOMBRE DEL PROYECTO

Implementación de

SIGLAS DEL PROYECTO

HCDA

30


Fecha
Motivo
1.0
SA
SB
SC
2.0
SA
SB
SC

COSTEO DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

Tipo de Recurso: Personal
Entregable - Actividad

Nombre del
Recurso


Unidades

EP,CP

8 horas

EP,CP

16 horas

1.1.1 A03 Revisar project charter

EP,CP

8 horas
118
horas

LU,EP,CP

6 horas


1.1.2 A02 Elaboración del scope
statement
1.1.2 A03 Revisar scope statement

EP,CP,LU

96 horas

EP,CP

16 horas
224
horas


1.2 A01 Elaborar Plan del Proyecto

Costo
Total

Tipo de Recurso: Máquinas o no Consumibles
Nombre del
Recurso

Unidad
es

Cantidad

Costo
Unitario

Costo
Total

32 horas

1.1.1 A02 Elaboración del project
charter


Cantida Costo
d
Unitario

Tipo de recurso: Materiales o
Consumibles
Nombre del Unida Canti Costo Costo
Recurso
des
dad Unitar Total
io

LU,EP,LT,
CP

224
horas

280,16
2 0
280,16
2 0
280,16
2 0

440

70,140,
3 80
2240,1
280,11
3 20
280,16
2 0

290

1960,3
920,16
4 80,224

4640

880
440

4640

880

35

0
1.3 Informes de Estado del proyecto

96 horas

1.3 A01 Elaborar y distribuir informes
de estado del proyecto

96 horas

de estado del proyecto 1

280
280

280

280

280

280

280

280

280

280

280

280

8 horas

280

280

SI

8 horas

280

280

SI

8 horas

280

280

SI

8 horas

280

280

SI

8 horas

280

280

SI

280

280

60,140,
3 70
60,140,
3 70
60,140,
3 70

270

1
1
1
1
1


SI

8 horas

1


SI

8 horas

1


SI

8 horas

1


SI

8 horas

1

1.4 Reunión de coordinación
semanal

SI
SI

8 horas
8 horas

SI

8 horas
282
horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas

1
1
1

270
270

36



LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas

60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70

270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270

37



LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas


LT,EP,LU

6 horas

60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70
60,140,
3 70

270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270
270

38

1.5 A01 Elaborar documentos de Cierre
del proyecto

16 horas
LU,EP,LT,
CP

2.1 Modelamiento de Requerimientos
del Sistema de Información
2.1.A01 Revisión de la RIN con el
coordinador y equipo usuario
2.1.A02 Elaborar diagrama de contexto
del sistema de información
2.1.A03 Elaborar catálogos de
requerimientos funcionales y no
funcionales
2.1.A04 Elaborar los diagramas y
especificaciones de caso de uso
2.1.A05 Especificaciones de interfaces,
perfiles y formatos de impresión

16 horas

AS1,AS2,C
P,EP,LU
AS1,AS2

AS1,AS2

40 horas
32 horas

80 horas

AS1,AS2

96 horas

AS1,AS2

48 horas

AS1,AS2

32 horas

2.2.A02 Análisis de Paquetes

AS1,AS2

32 horas

2.5 Análisis de consistencia y
verificación de requerimientos
2.5.A01 Verificación de la calidad
técnica de los modelos
2.5.A02 Análisis de consistencia técnica
entre modelos
2.6.A01 Revisión del análisis y
elaboración del acta
3.1 Definición de la arquitectura del
sistema

240,24
0,320,5
5 60,280
480,48
0
2
1200,1
200
2
1440,1
440
2
720,72
2 0

1640

480.48
2 0
480.48
2 0

960

480.48
2 0

960

480.48
2 0

960

240,24
2 0
240,24
2 0

480

120,16
3 0,140

420

960
2400

2880
1440

64 horas

2.2.A01 Análisis de clases

2.4 Migración de datos y carga inicial
2.4.A01 Especificaciones de migración
de datos y carga inicial

700

296
horas


2.3.A01 Especificaciones de interfaces
con sistemas relacionados

140,28
0,120,1
4 60

960

32 horas
AS1,AS2

32 horas
32 horas

AS1,AS2

32 horas
32 horas

AS1,AS2

16 horas

AS1,AS2

16 horas

480

12 horas
LT,CP,LU

12 horas
144
horas

39

3.1.A01 Definición de niveles de
arquitectura
3.1.A02 Identificación de subsistemas
de diseño
3.1.A03 Elaboración del catálogo de
excepciones
3.1.A04 Especificación del entorno
tecnológico del sistema
3.2 Diseño de la arquitectura de
soporte
3.2.A01 Elaboración de diagrama de
clases y de interacción de objetos

AS1,AS2

32 horas

AS1,AS2

48 horas

AS1,AS2

32 horas

AS1,AS2

32 horas

3.4.A01 Diseño del modelo físico de
datos
3.4.A02 Especificación de los caminos
de acceso a los datos
3.4. A03 Estimación de volúmenes de
tablas
3.5 Generación de especificaciones
de construcción
3.5.A01 Especificación del entorno de
construcción
3.5.A02 Elaboración de los diagramas
de componentes y despliegue
3.5.A03 Elaboración de
especificaciones de construcción
3.6 Migración y carga inicial de datos
3.6.A01 Definición de procedimiento de
carga inicial
3.6.A02 Especificación técnica de las
pruebas de carga inicial
3.7 Detalle de documentación de
usuario
3.7.A01 Especificaciones de los
documentos de usuarios a elaborar
4.1 Presentación del Informe de
Definición

960
1440
960
960

80 horas
AS1,AS2

3.3.A01 Elaboración del diagramas (de
secuencia, colaboración y de clases)

480,48
2 0
720,72
2 0
480,48
2 0
480,48
2 0

AS1,AS2

80 horas
112
horas
112
horas
160
horas

AS1,AS2

80 horas

AS1,AS2

32 horas

AS1,AS2

48 horas
224
horas

AS1,AS2

16 horas

AS1,AS2
AS1,AS2

64 horas
144
horas
32 horas

AS1,AS2

16 horas

AS1,AS2

16 horas

1200,1
200

2400

1680,1
680

3360

1200,1
2 200
480,48
2 0
720,72
2 0

2400

240,24
2 0
960,96
2 0
2160,2
2 160

480

240,24
2 0
240,24
2 0

480

240,24
2 0

480

2

2

960
1440

1920
4320

480

16 horas
AS1,AS2

16 horas
40 horas

40


4.1 A01 Reunión explicativa de
presentación de análisis y diseño

AS1,AS2,P
J1,PJ2,PVF

4.2 Programación del código fuente
4.2.A01 Programación J2EE

PJ1,PJ2

4.2.A02 Programación cliente/servidor
4.3 Integración de código fuente y
pruebas de desarrollo

PVF

4.3 A01 Integración de código fuente y
pruebas unitarias

PJ1,PJ2,P
VF

4.4 A01 Elaboración de informe de
4.4 A02 Elaboración del manual de
usuario
4.4 A03 Elaboración del tutorial para el
usuario
4.4 A04 Elaboración del instructivo de
instalación
4.4 A05 Generación y envío de pases a
producción
4.5 A01 Presentación del software a
analistas de calidad
5.1 Elaborar el Plan de Pruebas de
Sistemas

40 horas
1,496
horas
1,264
horas
232
horas
216
horas
216
horas
120
horas

PJ1,PVF

32 horas

PJ2

32 horas

PJ2

24 horas

PJ1,PVF

16 horas

PJ1,PVF

16 horas

240,24
0,200,2
5 00,160

1040

15800,
2 15800
4640
1

31600
4640

1800,1
800,14
3 40

5040

400,32
2 0
800
1
600
1
200,16
2 0
200,16
2 0

720
800
600
360
360

16 horas
AS1,AS2

16 horas
120
horas
120
horas
8 horas

240,24
2 0

2400

480

2400

1

5.1.A01 Plan de Pruebas de Sistemas

AC

5.3.A01 Checklist de entregables

AC

8 horas
254.4
horas

AC

1

AC

8 horas
246.4
horas
48 horas

5201.7
1 8

5201.7
8

AC

24 horas

1 480

480

5.3.A01 Pruebas de instalación del
software
5.3.A02 Pruebas funcionales y no
funcionales
5.4.A01 Elaborar plan de pruebas de

1 160

160

160

160

41

aceptación
5.4.A02 Convocar a usuario a pruebas
de aceptación
5.4.A03 Realizar pruebas de aceptación
5.5.A01 Derivar Pases a Producción
Mod. Web a DOIT
5.5.A02 Derivar Pases a Producción
Mod. VFP a DOIT
6.1 Instalación de Pases a
Producción

160

16 horas

440

160
160

1 160
1 160

160

1800,2
2 100

3900

1

16 horas
AC

8 horas

1

AC

8 horas

1

16 horas

6.1.A01 Instalación de pase web

OP

8 horas

6.1.A02 Instalación de pase FoxPro

OP

8 horas
120
horas
120
horas

6.2.A01 Monitoreo post instalación y
atención de incidencias
7.1 Capacitación a usuarios del
sistema
7.1.A01 Elaboración de la presentación
(Archivo ppt)

160,28
2 0

160

AC,LU

8 horas

160

160

AC

LT,LU

160

24 horas
200

200

PJ2

8 horas

1

7.1.A02 Enviar o publicar convocatoria

PJ2

8 horas

200

7.1.A03 Ejecución de la capacitación

AS1

8 horas

1 200
1 240

240

42


Versión

Hecha por

Revisa
sada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versió Original
ón

PRESUPUESTO DEL PROYECTO
- POR FASE Y POR ENTREGABLE –
OR
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de
PROYECTO

HCDA

FASE

ENTREGABLE

1.0 Gestión del
l
Proyecto

1.1 Iniciación
1.3 Informes de Estado del
Proyecto
1.4 Reunión de Coordinación
Semanal
1.5 Cierre del Proyecto

2.0 Análisis de
e
Requerimientos d
del
Sistema de
Información

Implementa
ción de
Herramient
as
Informática
s

3.0 Diseño del
l
Sistema de
Información

4.0 Construcción
n
del Software

2.1 Modelamiento de
Requerimientos del Sistema
de Información
2.2 Análisis de los casos de
uso
2.3 Interfaces con otros
sistemas
2.4 Migración de datos y
carga inicial
arquitectura del sistema
3.2 Diseño de la arquitectura
de soporte
3.3 Diseño orientado a
objetos
3.5 Generación de
especificaciones de
construcción
3.6 Migración y carga inicial
de datos
3.7 Detalle de documentación
de usuario
4.1 Presentación del Informe
de Definición
4.2 Programación del código
fuente
4.3 Integración de código
fuente y pruebas de
desarrollo
4.4 Elaboración de
documentación

MONTO S/.
7,570.00
9,800.00
3,360.00
12,960.00
700.00
Total Fase
9,320.00

34,120.00
34

1,920.00
960.00
960.00
960.00
420.00
Total Fase
4,320.00

14,540.00
14

2,400.00
2,400.00
4,800.00
7,200.00

960.00
480.00
Total Fase
1,040.00

22,560.00
22

36,800.00
5,600.00

3,960.00
480.00

43

5.0 Pruebas de
e
Sistemas y
Conformidad de
e
Usuario

6.0 Implantación y
n
Estabilización de
del
Software

7.0 Capacitac
ción

Total Fase
2,400.00
5.1 Elaborar Plan de Pruebas
de Sistemas
160.00
Entregables
6,560.00
1,960.00
5.5 Enviar pase para
320.00
instalación
Total Fase
320.00
3,900.00
Producción
6.2 Estabilización del
software
Total Fase
7.1 Capacitación a usuarios
del sistema

47,880.00
47

11,400.00
11

4,220.00

640.00
Total Fase

640.00

TOTAL FA
ASES

135,360.00

Reserva de Contingen
encia

13,536.00

Reserva de Ges
stión

13,536.00

PRESUPUESTO TOTAL DEL PROYEC
YECTO

162,432.00

44

Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0
2.0

SA
SA

SC
SC

SB
SB

01.08.2010
27.03.2011

Motivo

Versión Original
Versión Final

PRESUPUESTO EN EL TIEMPO (Curva S)
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

Informe de horas extra del valor acumulado
Total
1800000

1600000

1400000

1200000

Costo

1000000

800000

600000

400000

200000

0
T1

T2

T3
2010

T4

T1
2011

45

Versión

Hecha por

Revisada por

Aprobada por

1.0
2.0

SA
SA

SB
SB

SC
SC

Fecha

Motivo


PLANTILLA DE MÉTRICA DE CALIDAD
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO


HCDA

MÉTRICA DE:
PRODUCTO

X

PROYECTO

F ACTOR DE CALIDAD RELEVANTE: ESPECIFICAR CUÁL ES EL FACTOR DE CALIDAD RELEVANTE QUE DA
ORIGEN A LA MÉTRICA.
Cobertura de las Funcionalidades Requeridas por el Usuario según Requerimiento
Informático
DEFINICIÓN DEL FACTOR DE C ALIDAD: DEFINIR EL FACTOR DE CALIDAD INVOLUCRADO EN LA MÉTRICA
Y ESPECIFICAR PORQUÉ ES RELEVANTE.
Esta métrica es relevante porque permitirá lograr el cumplimiento de los objetivos del
proyecto.
PROPÓSITO DE LA M ÉTRICA: ESPECIFICAR PARA QUÉ SE DESARROLLA LA MÉTRICA?
La métrica se desarrolla para monitorear la trazabilidad del producto final vs. el
requerimiento informático.
DEFINICIÓN OPERACIONAL: DEFINIR COMO OPERARÁ LA MÉTRICA, ESPECIFICANDO EL QUIÉN, QUÉ,
CUÁNDO, DÓNDE, CÓMO?
Durante las pruebas de aceptación, el líder Usuario validará que el sistema contiene todas
las funcionalidades requeridas mediante la ejecución de los casos de pruebas previstos
para tal fin.
MÉTODO DE MEDICIÓN: DEFINIR LOS PASOS Y CONSIDERACIONES PARA EFECTUAR LA MEDICIÓN.
1. Convocar al líder usuario para las pruebas de conformidad
2. Ejecutar el plan de pruebas de aceptación que se precisa en el documento PPU01
3. Totalizar las no conformidades detectadas por el líder usuario
RESULTADO DESEADO: ESPECIFICAR CUÁL ES EL OBJETIVO DE CALIDAD O RESULTADO DESEADO PARA
LA MÉTRICA.
El valor esperado es igual al 100% de conformidad.
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 ésta métrica es indispensable para poder recuperar deuda en cobranza
coactiva proveniente de operaciones mediante el uso del software que permitirá reportar a
centrales de riesgo los deudores.
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.
La persona operativamente responsable de vigilar el factor de calidad, los resultados de la
métrica, y de promover las mejoras de procesos que sean necesarias para lograr los objetivos
de calidad planteados, es el líder usuario en primera instancia, pero la responsabilidad última
de lograr que el software cumpla las funcionalidades y levantar las no conformidades es el
líder técnico.

46

MÉTRICA DE:
PRODUCTO

PROYECTO

X

F ACTOR DE CALIDAD RELEVANTE: ESPECIFICAR CUÁL ES EL FACTOR DE CALIDAD RELEVANTE QUE DA
ORIGEN A LA MÉTRICA.
Performance del Proyecto
DEFINICIÓN DEL FACTOR DE C ALIDAD: DEFINIR EL FACTOR DE CALIDAD INVOLUCRADO EN LA MÉTRICA
Y ESPECIFICAR PORQUÉ ES RELEVANTE.
La Performance del Proyecto se define como el cumplimiento del cronograma y del
presupuesto del proyecto.
Este factor de calidad es relevante pues permitirá al equipo de proyecto poner
oportunamente a disposición de los ejecutores y auxiliares coactivos herramientas
informáticas que permitirán recuperar deuda en cobranza coactiva.
PROPÓSITO DE LA M ÉTRICA: ESPECIFICAR PARA QUÉ SE DESARROLLA LA MÉTRICA?
La métrica se desarrolla para monitorear la performance del proyecto en cuanto a
cumplimiento de cronograma y presupuesto, y poder tomar las acciones correctas en forma
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á el sistema EVM en el MS Project, en la mañana de los lunes
de cada semana, y calculara el CPI (Cost Perfomance Index) y el SPI (Schedule Perfomanec
Index), en las oficinas de SUNETA, obteniendo de esta forma los ratios de performance
del proyecto, los cuales se tendrán disponibles los lunes en la tarde.
MÉTODO DE MEDICIÓN: DEFINIR LOS PASOS Y CONSIDERACIONES PARA EFECTUAR LA MEDICIÓN.
1. Se recabará información de avances reales, valor ganado, fechas de inicio y fin real,
trabajo real, y costo real, los cuales se ingresarán en el MS Project.
2. El MS Project calculará los índices de CPI y SPI.
3. Estos índices se trasladarán al Informe Semanal de Proyecto.
4. Se revisará el informe con el Sponsor y se tomarán las acciones correctivas y/o
preventivas pertinentes.
5. Se informará al sponsor de dichas acciones de ser el caso.
Resultado Deseado: especificar cuál es el objetivo de calidad o resultado deseado para la
métrica.
1. Para el CPI se desea un valor acumulado no menor de 0.95
2. Para el SPI se desea una valor acumulado no menor de 0.95
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 ésta métrica es indispensable para poder recuperar deuda en cobranza
coactiva proveniente de operaciones eras mediante el uso del software que permitirá
reportar a centrales de riesgo los deudores.
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.
La persona operativamente responsable de vigilar el factor de calidad, los resultados de la
métrica, y de promover las mejoras de procesos que sean necesarias para lograr los objetivos
de calidad planteados, es el Project Manager en primera instancia, pero la responsabilidad
última de lograr la rentabilidad del proyecto y el cumplimiento de los plazos recae en forma
ejecutiva en el Sponsor del Proyecto.

47

Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión original

L Í NE A B A S E DE CA L I DA D
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

F ACTOR DE
C ALIDAD
RELEVANTE
Performance
del Proyecto

Performance
del Proyecto

Cumplimiento
de
funcionalidades
requeridas por
el usuario

OBJETIVO DE
C ALIDAD

CPI>= 0.95

SPI >= 0.95

100%

HCDA

LÍNEA BASE DE CALIDAD
FRECUENCIA Y
MÉTRICA A
USAR

MOMENTO DE
MEDICIÓN

FRECUENCIA Y
MOMENTO DE
REPORTE

CPI= Cost
Performance
Index
Acumulado

Frecuencia:
Semanal
Medición: Lunes
en la mañana

Frecuencia:
Semanal
Reporte: Lunes
en la tarde

SPI=
Schedule
Performance
Index
Acumulado
Totalizar
no
conformidades
detectadas por
el usuario

Frecuencia:
Semanal
Medición: Lunes
en la mañana

Frecuencia:
Semanal
Reporte: Lunes
en la tarde

Frecuencia:
Pruebas de
aceptación de
cada pase a
producción
Medición:
Culminadas las
pruebas de
aceptación

Frecuencia:
Mensual
Reporte: Primer
Lunes de cada
mes

48

Versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

1.0
2.0

SA
SA

SB
SB

SC
SC

01.02.2010
27.03.2011

Versión Original
Versión Final

MATRIZ DE ACTIVIDADES DE CALIDAD
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de
ENTREGABLE

ESTÁNDAR DE
C ALIDAD APLICABLE


MGP-SUNETA


ACTIVIDADES DE
PREVENCIÓN

MGP-SUNETA


HCDA

MGP-SUNETA

1.3 Informes de Estado
del proyecto
1.4 Reunión de
coordinación semanal
2.1 Modelamiento de
Requerimientos del
Sistema de Información
2.2 Análisis de los casos
de uso
2.3 Interfaces con otros
sistemas
2.4 Migración de datos y
carga inicial
2.5 Análisis de
consistencia y
verificación de
requerimientos
2.6 Aprobación del
Análisis

arquitectura del sistema

MGP-SUNETA
MGP-SUNETA
MGP-SUNETA

ACTIVIDADES DE
CONTROL
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor

Revisión de Estándar

Aprobado por
usuario Normativo

Revisión de Pares de
documentación
documentación
documentación

Aprobado por
usuario Normativo
Aprobado por
usuario Normativo
Aprobado por
usuario Normativo

MDSI

documentación

Aprobado por
usuario Normativo

MDSI

documentación

Aprobado por
usuario Normativo
Aprobado por
profesional
asignado del Área
de Administración
de la
Infraestructura
Tecnología

MDSI
MDSI
MDSI
MDSI

MDSI

49

3.2 Diseño de la
arquitectura de soporte

3.3 Diseño orientado a
objetos
3.4 Diseño físico de
datos
3.5 Generación de
especificaciones de
construcción
3.6 Migración y carga
inicial de datos
3.7 Detalle de
documentación de
usuario

Aprobado por
profesional
asignado del Área
de Administración
de la
Infraestructura
Tecnología
Aprobado por
Líder Técnico
Aprobado por
Líder Técnico

MDSI

MDI
MDSI
MDSI

Aprobado por
Líder Técnico

MDSI

Aprobado por
Líder Técnico

MDSI

Aprobado por
Líder Técnico

4.1 Presentación del
Informe de Definición

Conforme acuerdo
de Gerencia de
Desarrollo

4.2 Programación del
código fuente

Estándares de
Programación.

4.3 Pruebas Unitarias y
de Integración de código
fuente
4.4 Elaboración de
documentación de
Usuario
software

Aprobado por
Líder del Equipo
de Desarrollo
Aprobado por
Arquitecto de
Estándares de
Software
Aprobado por
Líder de Equipo
Desarrollo

MDSI
Conforme a
Estándares de
Documentación
Conforme acuerdo
de Gerencia de
Desarrollo

Revisado por Analista
de Calidad.

Aprobado por
Líder Usuario
Aprobado por
Líder de Equipo
Calidad

5.1 Plan de Pruebas de
Sistemas

MDSI

Revisión de inclusión de
al menos 1 caso de
prueba por cada
Requisito del SW

entregables

Conforme a Lista de
Verificación de
Entregables Nº1 del
Procedimiento de
V&V

de Calidad

5.3 Pruebas de
Sistemas

MDSI

Informe de Pruebas de
Sistemas Revisado por
Analista de Calidad (par)

5.4 Pruebas de
Aceptación

MDSI

6.1 Instalación de
Pases a Producción

MDSI

Logs revisados por
Operador

MDSI

Seguimiento post
instalación,

Software
7.1 Capacitación a
usuarios del sistema

MDSI

Aprobado por
Líder de Equipo
de Calidad

Aprobado por
Líder de Equipo
de Calidad
Aprobación del
Usuario
Aprobado por
Administrador de
Pases a
Producción
Aprobado por Jefe
de Proyecto
Aprobado por Jefe
de DGI
50

Fecha

Motivo

1.0

SA

SB

SC

01.02.2010

Versión Original

2.0

SA

SB

SC

27.03.2011

Versión Final

PLAN DE GESTION DE LA CALIDAD
NOMBRE DEL PROYECTO

Implementación de

SIGLAS DEL PROYECTO

HCDA

POLÍTICA DE C ALIDAD DEL PROYECTO: ESPECIFICAR LA INTENCIÓN DE DIRECCIÓN QUE FORMALMENTE
TIENE EL EQUIPO DE PROYECTO CON RELACIÓN A LA CALIDAD DEL PROYECTO.
1) Cumplimiento de los plazos asignados al proyecto
2) Cobertura al 100% de las funcionalidades del software comprometidas con el área
normativa
3) Satisfacción del usuario operativo respecto del uso del software y de los resultados
que éste entrega.
4) El trabajo debe cumplir con la Metodología de Desarrollo de Sistemas vigente en la
organización

LÍNEA B ASE DE C ALIDAD 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.
F ACTOR DE
FRECUENCIA Y
FRECUENCIA Y
OBJETIVO DE
C ALIDAD
MÉTRICA A UTILIZAR
MOMENTO DE
MOMENTO DE
C ALIDAD
MEDICIÓN
REPORTE
RELEVANTE
Entrega de
Fecha de entrega Medición al día
Informe
la
Mensual.
de novedades = siguiente de la
acordado fecha acordada
información fecha
Dos
días
según
convenio para el envío de
después de la
a los
con Centrales de la novedad
fecha
de
usuarios
riesgo
mensual
medición.
internos y
Performance
externos
del Proyecto
conforme a
lo
estipulado
en
convenio
acordado.
Datos
Cantidad
de Mensualmente
Informe
Confiabilidad
reportados Observaciones por después de cada
Mensual
de la
a Centrales inconsistencia de envío
Información
de Riesgo
data = 0
procesada
100%
confiables
Nivel de
Nivel
de Al
final
del
Informe
satisfacción Satisfacción
= proceso
de
Mensual
Satisfacción
por parte
Resultados
estabilización del
del Usuario
del usuario obtenidos a través software, esto 30
días después de
operativo
de encuesta.
>=70%
su implantación
51

PLAN DE M EJORA 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.

Cada vez que se deba mejorar un proceso se seguirán los siguientes pasos:
1.- Verificar que efectivamente se trata de una mejora y no de un error de software de ser el
caso debe ser reportado al área de incidentes para su atención inmediata.
2.- De tratarse de una mejora se debe delimitar conjuntamente con el usuario el ámbito de la
mejora (proceso a mejorar)
3.- El detalle de la oportunidad de mejora debe ser escalado por el usuario operativo al
usuario normativo
4.- El área normativa revisa el detalle de la oportunidad de mejora en base a lo cual define el
requerimiento informático estandarizado para solicitar el costeo respectivo al área de
sistemas.
5.- El área de sistemas realiza el costeo de la implementación de la oportunidad de mejora
6.- La alta dirección conjuntamente con el área normativa determinan la prioridad de las
oportunidades de mejora y según ello se va cargando al cronograma institucional para su
posterior atención.
M ATRIZ DE ACTIVIDADES DE C ALIDAD: 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).
P AQUETE DE TRABAJO

ESTÁNDAR O NORMA
DE C ALIDAD
APLICABLE


MGP-SUNETA

1.3 Informes de
Estado del proyecto
1.4 Reunión de
coordinación semanal
1.5 Cierre del
proyecto
2.1 Modelamiento de
Requerimientos del
Sistema de
Información
2.2 Análisis de los
casos de uso
2.3 Interfaces con
otros sistemas
2.4 Migración de
datos y carga inicial
2.5 Análisis de
consistencia y
verificación de
requerimientos
2.6 Aprobación del
Análisis

ACTIVIDADES DE
CONTROL
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor
Aprobación
sponsor

MGP-SUNETA

1.1.2 Scope
Statement

ACTIVIDADES DE
PREVENCIÓN

MGP-SUNETA
MGP-SUNETA
MGP-SUNETA
MGP-SUNETA

Revisión de Estándar

Aprobado por
usuario Normativo

documentación
documentación
documentación

Aprobado por
usuario Normativo
Aprobado por
usuario Normativo
Aprobado por
usuario Normativo

MDSI

documentación

Aprobado por
usuario Normativo

MDSI

documentación

Aprobado por
usuario Normativo

MDSI

MDSI
MDSI
MDSI

52

arquitectura del
sistema

MDSI

3.2 Diseño de la
arquitectura de
soporte

Aprobado por
profesional
asignado del Área
de Administración
de la
Infraestructura
Tecnología
Aprobado por
profesional
asignado del Área
de Administración
de la
Infraestructura
Tecnología
Aprobado por
Líder Técnico
Aprobado por
Líder Técnico

MDSI

3.3 Diseño orientado
a objetos
3.4 Diseño físico de
datos
3.5 Generación de
especificaciones de
construcción
3.6 Migración y carga
inicial de datos
3.7 Detalle de
documentación de
usuario

MDI
MDSI
MDSI

Aprobado por
Líder Técnico

MDSI

Aprobado por
Líder Técnico

MDSI

Aprobado por
Líder Técnico


Conforme acuerdo
de Gerencia de
Desarrollo

4.2 Programación del
código fuente

Estándares de
Programación.

4.3 Pruebas Unitarias
y de Integración de
código fuente
4.4 Elaboración de
documentación de
Usuario
software

Aprobado por
Líder del Equipo
de Desarrollo
Aprobado por
Arquitecto de
Estándares de
Software
Aprobado por
Líder de Equipo
Desarrollo

MDSI
Conforme a
Estándares de
Documentación
Conforme acuerdo
de Gerencia de
Desarrollo

de Calidad.

Aprobado por
Líder Usuario
Aprobado por
Líder de Equipo
Calidad

5.1 Plan de Pruebas
de Sistemas

MDSI

Revisión de inclusión de
al menos 1 caso de
prueba por cada
Requisito del SW

entregables

Conforme a Lista de
Verificación de
Entregables Nº1 del
Procedimiento de
V&V

de Calidad

5.3 Pruebas de
Sistemas

MDSI

Informe de Pruebas de
Sistemas Revisado por
Analista de Calidad (par)

5.4 Pruebas de
Aceptación
6.1 Instalación de
Pases a Producción

MDSI
MDSI

Logs revisados por
Operador

Aprobado por
Líder de Equipo
de Calidad

Aprobado por
Líder de Equipo
de Calidad
Aprobación del
Usuario
Aprobado por
Administrador de
53

Pases a
Producción
Aprobado por
Jefe de Proyecto
Aprobado por
Jefe de DGI

Seguimiento post
MDSI
Software
instalación,
7.1 Capacitación a
MDSI
usuarios del sistema
ROLES PARA LA GESTIÓN DE LA C ALIDAD: 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.
Objetivos del rol: Es la persona que realiza las pruebas del sistema a fin
de verificar el funcionamiento del software conforme a lo especificado en
ROL NO 1 :
Analista
de el Informe de Definición
Control de Calidad Funciones del rol:
Elaborar el plan de pruebas de sistemas
Ejecutar los casos de pruebas
Reportar los defectos detectados
Elaborar el informe final de pruebas del sistema
Convocar al usuario para las pruebas de conformidad
Ejecutar el plan de pruebas de aceptación de usuario
Niveles de autoridad: Decide sobre la técnica de prueba a utilizar
Reporta a: Al líder técnico
Supervisa a: Requisitos de conocimientos:
- Estándares de Calidad del Software, ISO 9126 , NTP 12207
- Técnicas de Pruebas
- Experiencia y conocimiento en el aseguramiento de la calidad
del software y control de calidad del software
- Herramienta de Modelamiento Power Designer Metodología
RUP y de lenguaje UML para Análisis y Diseño.
- Inglés básico (lectura de manuales, ayudas de herramientas
informáticas e internet).
Requisitos de habilidades:
- Trabajo en equipo
- Comportamiento ético
- Proactividad
- Comunicación
Requisitos de experiencia:
Experiencia general de dos (2) años en desarrollo (pruebas y/o
construcción) de sistemas de información, acreditado mediante
declaración jurada.
Experiencia de trabajo mínima de dos (2) años en pruebas de
aplicaciones informáticas basadas en el estándar J2EE; y /o mínima
de dos (2) años en pruebas de aplicaciones informáticas basadas en
Visual Fox/Visual Basic, acreditado mediante declaración jurada.
Experiencia de trabajo mínima de dos (2) años en base de datos
Oracle o bases de datos relacionales, acreditado mediante
declaración jurada.
ORGANIZACIÓN PARA LA C ALIDAD DEL PROYECTO: ESPECIFICAR EL ORGANIGRAMA DEL PROYECTO
INDICANDO CLARAMENTE DONDE ESTARÁN SITUADOS LOS ROLES PARA LA GESTIÓN DE LA CALIDAD.

54

DOCUMENTOS NORMATIVOS PARA LA C ALIDAD: ESPECIFICAR QUE DOCUMENTOS NORMATIVOS
REGIRÁN LOS PROCESOS Y ACTIVIDADES DE GESTIÓN DE LA CALIDAD.
1.Metodología de De Desarrollo de Sistemas de Información
2. Memorándum de Gerencia De Desarrollo que norma la presentación de
los entregables antes de pasar al siguiente proceso de desarrollo del
PROCEDIMIENTOS
software.
.

PLANTILLAS

FORMATOS

CHECKLISTS

OTROS
DOCUMENTOS

1.Conformidad de Usuario
2 Informe de Pruebas de Sistemas
3.- Plan de Pruebas de Sistemas
4.- Plan de Pruebas de Conformidad de Usuario
1.Conformidad de Usuario
2 Informe de Pruebas de Sistemas
3.- Plan de Pruebas de Sistemas
4.- Plan de Pruebas de Conformidad de Usuario
1. De V&V
2. De SQA
3.
4
1.
2.
3
4

55

PROCESOS DE GESTIÓN DE LA C ALIDAD: 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É.

ENFOQUE DE
ASEGURAMIENTO DE
LA C ALIDAD

ENFOQUE DE
CONTROL DE LA
CALIDAD

ENFOQUE DE
MEJORA DE
PROCESOS

El Aseguramiento de la Calidad se hará cumpliendo el Procedimiento de SQA de
acuerdo a los roles estipulados y se informará de los resultados a la Oficina de
Ingeniería de Procesos y Software.
El Comité de Calidad tomará acción sobre los indicadores obtenidos en el proceso
de SQA.
El seguimiento post instalación de los productos lo realizará el equipo de Atención
a Usuarios bajo un plan de implementación que informe oportunamente las
oportunidades al área normativa de las oportunidades de mejora detectados.
Se ejecutarán los checklist definidos para cada entregable en el procedimiento
V&V
Se llevará un registro de todos los defectos reportados y se les hará seguimiento
hasta la subsanación de todos.

Cada vez que se deba mejorar un proceso se seguirán los siguientes pasos:
1.- Verificar que efectivamente se trata de una mejora y no de un error de software
de ser el caso debe ser reportado al área de incidentes para su atención inmediata.
2.- De tratarse de una mejora se debe delimitar conjuntamente con el usuario el
ámbito de la mejora (proceso a mejorar)
3.- El detalle de la oportunidad de mejora debe ser escalado por el usuario
operativo al usuario normativo
4.- El área normativa revisa el detalle de la oportunidad de mejora en base a lo cual
define el requerimiento informático estandarizado para solicitar el costeo respectivo
al área de sistemas.
5.- El área de sistemas realiza el costeo de la implementación de la oportunidad de
mejora
6.- La alta dirección conjuntamente con el área normativa determinan la prioridad
de las oportunidades de mejora y según ello se va cargando al cronograma
institucional para su posterior atención.

56

Versión

Hecha por

Revisa
sada por

Aprobada por

Fecha

1.0
2.0

SA
SA

SB
SB

SC
SC

01.02.2010
27.03.2011

Motivo

Versió Original
ón
Versió Final
ón

ORGANIGRAMA DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

Organigra
ama del Proyecto: PROYECTO HCDA
SPONSOR
ONSOR
Sandra Casas

COMITE DE
CAMBIOS

COORDINADOR D
DEL
PROYECTO

PROJECT MA
ANAGER
Samuel Benites
CONTROL DE
PROYECTO
Yulia Palacios
EQUIPO DE GESTION DE PROYECTO

EQUIPO
CONSULTIVO

LIDER TEC
CNICO

Equipo de
Analistas de
Sistemas

Equipo de
e
Programador
dores

LIDER USUA
ARIO

Equipo de
pruebas de
calidad

EQUIPO USUA
USUARIO
ejecutores y au
uxiliares
coactivos
s

EQUIPO DE EJECUCION DEL PROYECTO
Leyenda:
Verde: Personal del proyecto
Amarillo : usuarios
EQUIPO INTEGRADO DE PROYECTO

57


Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión Original

MATRIZ DE ASIGNACIÓN DE RESPONSABILIDADES (RAM)
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA
Roles / Personas
Equipo del Proyecto

entregables

CP

LT

Equipo Usuario

SP

PM

AP

AC

EU


A

R

P
P

HCDA
1.0 Gestion del Proyecto
1.1 Iniciacion

A

R

1.3 Informes de Estado del
proyecto
1.4 Reunión de coordinación
semanal

A

R

V

R

2.0 Análisis de Requerimientos del
Sistemas de Información
2.1 Modelamiento de
Requerimientos del Sistema de
Información

A


R

P
P

P

P

P

P

A

V

R

P

P

V

R

P

P

V

R

R

P
58


2.4 Migración de datos y carga
inicial
3.0 Diseño del Sistema de
Información
3.1 Definición de la arquitectura
del sistema
3.2 Diseño de la arquitectura de
soporte

V

R

V

R

V

R

A
A
A

R
R


R

3.5 Generación de
especificaciones de construcción
3.6 Migración y carga inicial de
datos
3.7 Detalle de documentación de
usuario
4.0 Construcción del Software
4.1 Presentación del Informe de
Definición
4.2 Programación del código
fuente
4.3 Integración de código fuente y

R
R
R
R
A

5.1 Plan de Pruebas de Sistemas

R

V

R
R
R

5.0 Pruebas de Sistemas y

V

V

R

V

R

A

V

R

A

V

P

R
R
59



R


V

6.0 Implantación y estabilización del
software
Producción

P

A

R

A

P

A

P


P

7.0 Capacitación
7.1 Capacitación a usuarios del
sistema

P

R = RESPONSABLE
P = PARTICIPA
V = REVISA
A = APRUEBA

R

P

V

LEYENDA

V

R

P

CODIGOS DE ROLES
SP: SPONSOR
PM: PROJECT MANAGER
CP: COORDINADOR DEL PROYECTO
LT: LÍDER TÉCNICO
AP: ANALISTA PROGRAMADOR
AC: ANALISTA DE CALIDAD
EU: EQUIPO USUARIO

INCLUIR ESTOS DATOS EN LA
TABLA SUPERIOR

60


Versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

1.0

SA

SB

SC

01.02.2011

Versión Original

DESCRIPCIÓN DE ROLES
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

NOMBRE DEL ROL
Analista de Control de Calidad
OBJETIVOS DEL ROL: OBJETIVOS

QUE DEBE LOGRAR EL ROL DENTRO DEL PROYECTO

(PARA QUÉ SE HA CREADO EL

ROL).

Es la persona que realiza las pruebas del sistema a fin de verificar el funcionamiento del software
conforme a lo especificado en el Informe de Definición
RESPONSABILIDADES: TEMAS PUNTUALES POR LOS CUALES ES RESPONSABLE (¿DE QUÉ ES RESPONSABLE?).
Realizar las pruebas de sistemas
Apoyar al usuario en las pruebas de aceptación
Enviar el pase a producción para su instalación
FUNCIONES: FUNCIONES ESPECÍFICAS QUE DEBE CUMPLIR (¿QUÉ DEBE REALIZAR PARA LOGRAR SUS OBJETIVOS Y CUBRIR
SUS RESPONSABILIDADES?).

Elaborar el plan de pruebas de sistemas
Ejecutar los casos de pruebas
Reportar los defectos detectados
Elaborar el informe final de pruebas del sistema
Convocar al usuario para las pruebas de conformidad
Ejecutar el plan de pruebas de aceptación de usuario
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.

Decide sobre la técnica de prueba a utilizar
REPORTA A: A QUIÉN REPORTA DENTRO DEL PROYECTO.
Al líder técnico
SUPERVISA A: A QUIÉNES SUPERVISA DENTRO DEL PROYECTO.
REQUISITOS DEL ROL: QUÉ REQUISITOS DEBEN CUMPLIR LAS PERSONAS QUE ASUMAN EL ROL.
- Estándares de Calidad del Software, ISO 9126 , NTP 12207
- Técnicas de Pruebas
Experiencia y conocimiento en el aseguramiento de la
CONOCIMIENTOS:
calidad del software y control de calidad del software
QUÉ TEMAS, MATERIAS, O
ESPECIALIDADES DEBE CONOCER,
- Herramienta de Modelamiento Power Designer Metodología
MANEJAR O DOMINAR.
RUP y de lenguaje UML para Análisis y Diseño.
- Inglés básico (lectura de manuales, ayudas de herramientas
informáticas e internet).
Trabajo en equipo
Comportamiento ético
HABILIDADES:
Proactividad
QUÉ HABILIDADES ESPECÍFICAS DEBE
POSEER Y EN QUÉ GRADO.
Comunicación

61

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

Experiencia general de dos (2) años en desarrollo (pruebas
y/o construcción) de sistemas de información, acreditado
mediante declaración jurada.
Experiencia de trabajo mínima de dos (2) años en pruebas
de aplicaciones informáticas basadas en el estándar J2EE;
y /o mínima de dos (2) años en pruebas de aplicaciones
informáticas basadas en Visual Fox/Visual Basic, acreditado
Experiencia de trabajo mínima de dos (2) años en base de
datos Oracle o bases de datos relacionales, acreditado

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

62

Versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

1.0

SA

SB

SC

01.02.2011

Versión Original

CUADRO DE ADQUISICIONES DEL PERSONAL DEL
PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

LOCAL
ROL

TIPO DE
ADQUISICI
ÓN

Sponsor
Project
Manager

Preasigna
ción
Preasigna
ción

FUENTE

MODALID

DE
ADQUISIC
IÓN

AD DE

ADQUISIC
IÓN

SUNETA
SUNETA

Comité
de
Control
de
Cambios
Coordina
dor
General

Asignado

SUNETA

Preasigna
ción

SUNETA

Líder
Técnico

Asignado

SUNETA

Líder
Usuario

Asignado

SUNETA

Analista
de
Sistemas
Program
ador
Java
Program
ador VFP

Asignado

SUNETA

Asignado

SUNETA

Asignado

SUNETA

Analista
de
Calidad

Asignado

SUNETA

DE
TRABA
JO
ASIGNA
DO

FECHA DE
INICIO DE

RECLUTAMI
ENTO

FECHA
REQUERIDA
DE
DISPONIBILI
DAD DE
PERSONAL

APOY
COSTO DE
RECLUTAMI
ENTO

O DE

AREA
DE

RRH
H

SUNETA
Decisión
del
Sponsor
Decisión
del
Sponsor

Ninguno

SUNETA

Ninguno

SUNETA

Ninguno

Ningu
no

Ninguno

Ningu
no

25.Mar.201
0

Ninguno

Ningu
no

25.Mar.201
0

Ninguno

Ningu
no

25.Mar.201
0

Ninguno

Ningu
no

08.Jul.2010

Ninguno

Ningu
no

08.Jul.2010

Ninguno

Ningu
no

08.Jul.2010

Ninguno

Ningu
no

Decisión
SUNETA
del
Project
Manager
Decisión
SUNETA 01.Mar.2010
del
Gerente
de
Desarrollo
SUNETA 01.Mar.2010
Decisión
del
coordinad
or de
proyecto
SUNETA 15.Mar.2010
Decisión
del Líder
Técnico
SUNETA 15.Jun.2010
Decisión
del Líder
Técnico
SUNETA 15.Jun.2010
Decisión
del Líder
Técnico
SUNETA 15.Jun.2010
Decisión
del Jefe
de
División

Ningu
no
Ningu
no

63

Versión
1.0

Hecha por Revisada por Aprobada por
Fecha
Motivo
SA
SB
SC
01.02.2011 Versión Inicial

DIAGRAMA DE CARGA DE PERSONAL
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

RECURSO: SPONSOR

RECURSO: EJECUTIVO DEL PROYECTO

64

RECURSO: ANALISTA DE SISTEMAS 1

RECURSO: PROGRAMADOR JAVA 1

66

RECURSO: ANALISTA DE CALIDAD

67

Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión original

PLAN DE RECURSOS HUMANOS
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

ORGANIGRAMA DEL PROYECTO: ESPECIFICAR EL ORGANIGRAMA DEL PROYECTO.
Ver organigrama del proyecto – versión 1.0
NOTA: ADJUNTAR ORGANIGRAMA DEL PROYECTO.
ROLES Y RESPONSABILIDADES: ESPECIFICAR LA MATRIZ DE ASIGNACIONES DE RESPONSABILIDADES
(RAM).
Ver Matriz de Asignación de Responsabilidades (RAM) – 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 – versión 1.0
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 – versión 1.0
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.
Ver Diagramas de Carga del Personal – versión 1.0

NOTA: ADJUNTAR DIAGRAMA DE CARGA DE PERSONAL.
CRITERIOS DE LIBERACIÓN DEL PERSONAL DEL PROYECTO: CUÁNTO, CÓMO, HACIA DÓNDE?
CRITERIO DE
DESTINO DE
ROL
¿CÓMO?
LIBERACIÓN
ASIGNACIÓN
Sponsor
Al término del proyecto Comunicación de la Otros
proyectos
Agrupacion Nacional
SUNETA
Project Manager
Al término del proyecto Comunicación
del Otros
proyectos
sponsor
SUNETA
Comité de control de Al término del proyecto Comunicación
del Otros
proyectos
cambios
sponsor
SUNETA
Coordinador
del Al término del proyecto Comunicación
del Otros
proyectos
proyecto
Project Manager
SUNETA
Líder Usuario
del Otros
proyectos
Coordinador
del SUNETA
proyecto

68

del Otros
proyectos
Coordinador
del SUNETA
proyecto
Analista de Sistemas
Finalizado el periodo Comunicación
del Otros
proyectos
de estabilización de las Líder Técnico
SUNETA
herramientas
implementadas
Programador
Finalizado el periodo Comunicación
del Otros
proyectos
de estabilización de las Líder Técnico
SUNETA
herramientas
implementadas
Analista de Control de Al término del proyecto Comunicación
del Otros
proyectos
Calidad
Coordinador
del SUNETA
proyecto
C APACITACIÓN, ENTRENAMIENTO, M ENTORING REQUERIDO: QUÉ, PORQUÉ, CUÁNDO, CÓMO, DÓNDE, POR
QUIÉN, CUÁNTO?
Al término de la construcción de cada herramienta era (software) se programa la
Capacitación a los usuarios en el manejo de las funcionalidades y bondades del nuevo sistema.
La capacitación incluye también la explicación de los nuevos procedimientos aprobados y
participan también los miembros del equipo de trabajo para que conozcan la parte funcional del
negocio.
SISTEMA DE RECONOCIMIENTO Y RECOMPENSAS: QUÉ, PORQUÉ, CUÁNTO, CÓMO, DÓNDE, POR QUIÉN,
CUÁNTO?
La Agrupación Nacional Adjunta – SUNETA tiene un sistema por incentivos donde se evalúan
la participación de los colaboradores en los proyectos realizados en
el año.
La variable analizada es el tiempo.
Para un CPI promedio no menor de 1.0, 30% de bonificación sobre la remuneración mensual.
Para un CPI entre 0.9 y 1.0, 15% de bonificación sobre la remuneración mensual.
Para un CPI menor a 0.9 no se accede a la bonificación
CUMPLIMIENTO DE REGULACIONES, P ACTOS, Y POLÍTICAS: QUÉ, PORQUÉ, CUÁNDO, CÓMO, DÓNDE, POR
QUIÉN, CUÁNTO?
En el caso del personal contratado que forma parte del proyecto solo deberán realizar tareas que
correspondan a sus contratos respectivos.
REQUERIMIENTOS DE SEGURIDAD: QUÉ, PORQUÉ, CUÁNDO, CÓMO, DÓNDE, POR QUIÉN, CUÁNTO?
Parte del equipo de trabajo dispone de Laptops para las tareas asignadas que se realizan
durante la jornada de trabajo. Al momento de retirase deben asegurar el equipo al escritorio con
una cadena proporcionado por la administración.
El desarrollo de las herramientas debe seguir la metodología de desarrollo de sistemas – MDSI
que considera los mecanismos de seguridad a tomar en cuenta en la etapa de obtención y
análisis de requerimientos.
Líder Técnico

69

Versión

Hecha por

Revisada por

Aprobada por

1.0

SA

SB

SC

Fecha

Motivo

01.02.2011 Versión original

PLAN DE GESTIÓN DE COMUNICACIONES
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

COMUNICACIONES DEL PROYECTO: ESPECIFICAR LA MATRIZ DE COMUNICACIONES DEL PROYECTO.
Ver Matriz de comunicación del proyecto – versión 1.0
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.
XCVXCV

1. Se captan las polémicas a través de la observación y conversación, o de alguna persona
o grupo que los exprese formalmente.
2. Se codifican y registras las polémicas en el Log de Control de Polémicas
Código de
Polémica

Descripción

Involucrados

Enfoque de
solución

Acciones de
solución

Responsable

Fecha

Resultado
Obtenido

3. Se revisa el Log de Control de Polémicas en la reunión semanal de coordinación con el
fin de:
a. Determinar las soluciones a aplicar a las polémicas pendientes por analizar, designar
un responsable por su solución, un plazo de solución, y registrar la programación de
estas soluciones en el Log de Control.
b. Revisar si las soluciones programadas se están aplicando, de no ser así se tomarán
acciones correctivas al respecto.
c. Revisar si las soluciones aplicadas han sido efectivas y si la polémica ha sido
resuelta, de no ser así se diseñarán nuevas soluciones (continuar en el paso ‘a’).
4. En caso que una polémica no pueda ser resuelta o en caso que haya evolucionado hasta
convertirse en un problema, deberá ser abordada con el siguiente método de
escalamiento:
a. En primera instancia será tratada de resolver por el Project Manager y el Equipo de
Gestión de Proyecto, utilizando el método estándar de resolución de problemas.
b. En segunda instancia será tratada de resolver por el Project Manager, el Equipo de
Gestión de Proyecto, y los miembros pertinentes del Equipo de Proyecto, utilizando el
método estándar de resolución de problemas.
c. En tercera instancia será tratada de resolver por el Sponsor, el Project Manager, y los
miembros pertinentes del proyecto, utilizando la negociación y/o la solución de
conflictos.
En última instancia será resuelta por el Sponsor o por el Sponsor y el Comité de Control de
Cambios si el primero lo cree conveniente y necesario.

70

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

EL

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

El Plan de Gestión de las Comunicaciones deberá ser revisado y/o actualizado cada vez que:
1. Hay una solicitud de cambio aprobada que impacte el Plan de Proyecto.
2. Hay una acción correctiva que impacte los requerimientos o necesidades de información
de los stakeholders.
3. Hay personas que ingresan o salen del proyecto.
4. Hay cambios en las asignaciones de personas a roles del proyecto.
5. Hay cambios en la matriz autoridad versus influencia de los stakeholders.
6. Hay solicitudes inusuales de informes o reportes adicionales.
7. Hay quejas, sugerencias, comentarios o evidencias de requerimientos de información no
satisfechos.
8. Hay evidencias de resistencia al cambio.
9. Hay evidencias de deficiencias de comunicación intraproyecto y extraproyecto.
La actualización del Plan de Gestión de las Comunicaciones deberá seguir los siguientes pasos:
1. Identificación y clasificación de stakeholders.
2. Determinación de requerimientos de información.
3. Elaboración de la Matriz de Comunicaciones del Proyecto.
4. Actualización del Plan de Gestión de las Comunicaciones.
5. Aprobación del Plan de Gestión de las Comunicaciones.
6. Difusión del nuevo Plan de Gestión de las Comunicaciones.
GUÍAS PARA EVENTOS DE COMUNICACIÓN: DEFINA GUÍA PARA REUNIONES, CONFERENCIAS, CORREO
ELECTRÓNICO, ETC.

Guías para Reuniones .- Todas las reuniones deberán seguir las siguientes pautas:
1. Debe fijarse la agenda con anterioridad.
2. Debe coordinarse e informarse fecha, hora, y lugar con los participantes.
3. Cuando la reunión requiera la evaluación de documentos estos deberán ser referenciados
en la convocatoria (como links al repositorio de documentos; no como archivos adjuntos)
4. Se debe empezar puntual.
5. Se deben fijar los objetivos de la reunión, los roles (por lo menos el facilitador y el
anotador), los procesos grupales de trabajo, y los métodos de solución de controversias.
6. Se debe cumplir a cabalidad los roles de facilitador (dirige el proceso grupal de trabajo) y
de anotador (toma nota de los resultados formales de la reunión).
7. Se debe terminar puntual.
8. Se debe emitir un Acta de Reunión (ver formato adjunto), la cual se debe repartir a los
participantes (previa revisión por parte de ellos).
Guías para Correo Electrónico.- Todos los correos electrónicos deberán seguir las siguientes
pautas:
1. Deben ser enviados desde el dominio de la empresa (suneta.gob.pe)
2. Deben enviarse solo a los involucrados en el tema comunicado
3. El “Asunto” siempre debe empezar con el texto [HCDA]
GUÍAS PARA DOCUMENTACIÓN DEL PROYECTO: DEFINA LAS GUÍAS PARA CODIFICACIÓN, ALMACENAMIENTO,
RECUPERACIÓN, Y REPARTO DE LOS DOCUMENTOS DEL PROYECTO.

Guías para Codificación de Documentos.- La codificación de los documentos del proyecto será la
siguiente:
[TI|TA]_AAAA_BBB_CCCC.DDD
Donde:
TI: Si proviene de Tributos Internos |TA: Si proviene de Tributos eros
AAAA = Código del Proyecto= ‘HCDA’
BBB = Abreviatura del Tipo de Documento= pch, sst, wbs, dwbs, org, ram, etc.
CCC = Versión del Documento=’v1_0’, ‘v2_0’, etc.
DDD = Formato del Archivo=doc, exe, pdf, mpp, etc.

70

Guías para Almacenamiento de Documentos.- El almacenamiento de los documentos del
proyecto
deberá seguir las siguientes pautas:
1. Durante la ejecución del proyecto cada miembro del equipo mantendrá en su máquina
una carpeta con la misma estructura que el WBS del proyecto, donde guardará en las
sub-carpetas correspondientes las versiones de los documentos que vaya generando.
2. Al cierre de una fase o al cierre del proyecto cada miembro del equipo deberá eliminar los
archivos temporales de trabajo de los documentos y se quedará con las versiones
controladas y numeradas (ver guías para el control de versiones), las cuales se enviarán
al Project Manager.
3. El Project Manager consolidará todas las versiones controladas y numeradas de los
documentos, en un archivo final del proyecto, el cual será una carpeta con la misma
estructura del W BS, donde se almacenarán en el repositorio sharepoint los documentos
finales del proyecto; una vez almacenadas las versiones finales nadie debe tener
privilegios de escritura.
4. Se publicarán una Relación de Documentos del Proyecto y la ruta de acceso para
consulta.
5. Los miembros del equipo borrarán sus carpetas de trabajo para eliminar redundancias de
información y multiplicidad de versiones.
Guías para Recuperación y Reparto de Documentos.1. La recuperación de documentos a partir de la Biblioteca de Proyectos de SUNETA es
libre para todos los trabajadores de SUNETA.
2. El reparto de documentos digitales e impresos es responsabilidad del Coordinador de
Proyecto.
3. El reparto de documentos impresos no contempla el control de copias numeradas.
GUÍAS PARA EL CONTROL DE VERSIONES: DEFINA GUÍAS PARA REGISTRO Y CONTROL ORDENADO DE LAS
VERSIONES DE LOS DOCUMENTOS DEL PROYECTO.

1. Todos los documentos de Gestión de Proyectos están sujetos al control de versiones, el
cual se hace insertando una cabecera estándar con el siguiente diseño:
Código de
Versión

Hecha por

Revisada por

Aprobada
por

Fecha

Motivo

2. Cada vez que se emite una versión del documento se llena una fila en la cabecera,
anotando la versión, quién emitió el documento, quién lo revisó, quien lo aprobó, a que
fecha corresponde la versión y por qué motivo se emitió dicha versión.
3. Debe haber correspondencia entre el código de versión del documento que figura en la
cabecera del Control de Versiones y el código de versión del documento que figura en el
nombre del archivo (Ver Guía para Codificación de Documentos), según:
[TI|TA]_AAAA_BBB_CCCC.DDD
Donde:
TI: Si proviene de Tributos Internos |TA: Si proviene de Tributos eros
AAAA = Código del Proyecto= ‘HCDA’
BBB = Abreviatura del Tipo de Documento= pch, sst, wbs, dwbs, org, ram, etc.
CCC = Versión del Documento=’v1_0’, ‘v2_0’, etc.
DDD = Formato del Archivo=doc, exe, pdf, mpp, etc.
GLOSARIO DE TERMINOLOGÍA DEL PROYECTO: GLOSARIO

DE TÉRMINOS, NOMBRES, CONCEPTOS,

FÓRMULAS, ETC.

Ver Glosario de Terminología del Proyecto – versión 1.0.
71


Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión original

MATRIZ DE COMUNICACIONES DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO


HCDA

72


INFORMACION

Planificación
del Proyecto

Estado
Proyecto

del

Coordinación
del Proyecto

Cierre
Proyecto

del

CONTENIDO

FORMATO

Planificación
detallada
del
proyecto;
alcance
,tempo,
costo,
calidad,
rrhh,
comunicaciones,
riesgos
y
adquisiciones
Estado
Actual,
Avance, Pronóstico
del tiempo y costo,
problema pendientes
Información
detallada de las
Reuniones
de
Coordinación
Semanal
Datos
y
comunicación sobre
el cierre del proyecto

Plan
del
Proyecto

Muy alto

Project Manager

Sponsor, Coordinador
general de Usuarios, ,
Agrupaciones
Adjuntos, Gerente de
Desarrollo de sistemas
eros

Una sola vez

1.2. Plan del
Proyecto

Informe
de
Performance

Alto

Coordinador del
Proyecto

Project Manager

Mensual

1.3
Informe
de Estado del
Proyecto

Acta
Reunión

Alto

Coordinador del
Proyecto

Project Manager, Líder
Técnico

Semanal

1.4 Reunión
de
Coordinación
Semanal

Medio

Project Manager

Sponsor, Coordinador
general de Usuarios,
Agrupaciones
Adjuntos, Gerente de
Desarrollo de sistemas
eros

Una sola vez

1.5 Cierre del
Proyecto

de

Cierre
del
proyecto

NIVEL DE
DETALLE

RESPONSABLE
DE COMUNICAR

GRUPO RECEPTOR

FRECUENCIA
DE
COMUNICACIÓN

CODIGO DE
ELEMENTO
WBS

73


Iniciación
del
modelamiento
del sistema

Especificaciones del
modelo de negocio

Informe
definición
modelo
negocio

de
del
del

Medio

Iniciación
diseño
sistema

del
del

modelamiento
del
sistema

Iniciación de la
construcción

diseño del sistema

Iniciación de la
capacitación
para el uso del
software

Convocatoria de la
capacitación

Informe
de Medio
definición con
el
modelamiento
del sistemas
Informe
de Medio
definición con
el diseño del
sistemas
convocatoria
Alto

Coordinador
Proyecto

del

Analista
modelamiento
sistema

del
del

Líder
Técnico, Una sola vez
ejecutores coactivo s
de
la
a
Maritima y Aérea,
equipo de sistemas
Lider
Técnico
y Una sola vez
equipo de sistemas

Analista de diseño
del sistema

Líder
Técnico
y
equipo de sistemas

Una sola vez

Coordinador
Proyecto

Ejecutores coactivos,
centrales de riesgo

Una sola vez

del

74


Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión original

LISTA DE STAKEHOLDERS
- POR ROL GENERAL EN EL PROYECTO NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

ROL GENERAL
SPONSOR

STAKEHOLDERS
Sandra Casas
PROJECT MANAGER
SAMUEL ALONSO BENITES SAENZ
Samuel
EQUIPO DE GESTIÓN DE PROYECTO

EQUIPO DE PROYECTO

COMITÉ DE CAMBIOS

OTROS MIEMBROS DEL EQUIPO DE PROYECTO
- Alberto Moreno
- Elita Pinasco
- Esther Melgarejo
- Efrain Nuñez
- Ernesto Panda
- Jacsa Ranses
- José Nandez
- María Savaleta
- Walter Olace
-

Ricardo Toma
Micky Sholos
Luz Osti

PORTAFOLIO MANAGER
PROGRAM MANAGER
PERSONAL DE LA OFICINA DE
PROYECTOS

YULIA PALACIOS
(Personal de la Intendencia Nacional de Estudios
Tributarios y Planeamiento)

GERENTES DE OPERACIONES

GERENTES FUNCIONALES

USUARIOS / CLIENTES

Gerente de Desarrollo de Sistemas eros:
Marcela Pro
Gerente de Desarrollo de Sistemas Tributarios:
junior choque
Coordinador General: SANDY ANTUNEZ
Ejecutores coactivos
Auxiliares coactivos

75

PROVEEDORES / SOCIOS DE
NEGOCIOS

OTROS STAKEHOLDERS

Centrales de Riesgo:
certimas
Focorp mchanges
Participantes:
- Operadores de Comercio Exterior
- iris la rosa

76

1.0
2.0

SR
SR

JH
JH

GL
GL

Fecha
01.02.2010
27.03.2011

Motivo
Versión Original
Versión Final

CLASIFICACION DE STAKEHOLDERS
- MATRIZ INFLUENCIA VS PODER NOMBRE DEL PROYECTO


SIGLAS DEL PROYECTO
HCDA

77

PODER SOBRE EL PROYECTO
BAJO

ALTA

Project Manager:
Samuel Benites
Estrategia: Remitir con
anticipación el Informe de
Definición de lo que
realmente se va a construir y
obtener su conformidad a
priori.

ALTO
Sponsor:
sandra casas
Comité de Cambios:
RICHARD TOMAS
Miguel Shulca
Lourdes Ojeda
Estrategia: Una explicación
de los alcances de la
herramienta y su impacto
esperado en la recaudación.

Estrategia: Remitir con
anticipación el Informe de
Definición de lo que
realmente se va a construir y
obtener su conformidad a
priori.

BAJA

INFLUENCIA SOBRE EL PROYECTO

Usuarios:
Ejecutores Coactivos
Auxiliares Coactivos

Equipo de Trabajo:
Alberto Moreno
Elita Pinasco
Esther Melgarejo
Efrain Nuñez
Ernesto Panda
Jacse Ranses
José Nandez
Marina Suelem
Walter Olace
Estrategia: Reuniones
periódicas del avance en el
desarrollo de las herramientas.
Proporcionarles el feedback
detallado e inmediato de
cualquier cambio
Centrales de Riesgo:
certimas
Focorp
mchanges
Operadores de Comercio
Exterior

PODER
INFLUENCIA

Gerente de Desarrollo de
Sistemas eros: Marcela
Pro
Estrategia: Informar
permanentemente del
avance del proyecto y las
amenazas que se presenten
para el cumplimiento del
mismo.
Gerente de Desarrollo de
Sistemas Tributarios:
Michael Ruiz
Estrategia: Reunión para
explicar la herramienta que
se va a construir y el nivel
esperado de integración con
el esquema de tributos
internos.
Personal de la Intendencia
Nacional de Estudios
Tributarios y Planeamiento:
Yulia Palacios
Estrategia Informarle
permanentemente el avance
del proyecto y sustentar
cualquier retraso existente o
posible riesgo.

Estrategia: Reunión para
explicarle las características
de los entregables y lograr
: Nivel de Autoridad
: Involucramiento Activo

78

Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión Original

GLOSARIO DE TERMINOLOGÍA DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas
Nº
1

AGNA

TÉRMINO

2
3
4

TI
TA
IFGRA

5

MDSI

6
7
8
9
10

MGP
GDSA
F2
RIN
INETP

11

PMBOK

12

WBS

HCDA

DEFINICIÓN
Agrupacion Nacional Adjunta
Tributos Internos
Tributos eros
Fiscalización y Gestión de
Recaudación
Metodología de Desarrollo de Sistemas de Información
de SUNETA
Metodología de Gestión de Proyectos de SUNETA
Gerencia de Desarrollo de Sistemas eros
Requerimiento Informático de Negocio
Intendencia Nacional de Estudios
Project Management Body of Knowledge / Fundamentos
de la Dirección de Proyectos
Work Breakdown Structure / Estructura de Desglose del
Trabajo (EDT)

79

DEFINICIONES
Tributos eros: Tributos Administrados pos SUNETA provenientes de Operaciones de Comercio
Exterior.
Cobranza Coactiva: Se inicia cuando la obligación queda en mora y el deudor no paga lo adeudado
pese a haberse realizado la inducción al pago mediante llamadas y/o notificaciones escritas, ni se
evidencia la voluntad de pago mediante una solicitud de fraccionamiento; así la entidad toma la
decisión de iniciar el proceso buscando recuperar los valores adeudados, a través de embargos
Acción Correctiva / Corrective Action: Directiva documentada para ejecutar el trabajo del proyecto
y poder, de ese modo, alinear el rendimiento futuro previsto del trabajo del proyecto con el plan de
gestión del proyecto.
Acción Preventiva / Preventive Action: Directiva documentada para realizar una actividad que
puede reducir la probabilidad de sufrir consecuencias negativas asociadas con los riesgos del
proyecto.
Requerimiento Funcional: define el comportamiento interno del software: cálculos, detalles técnicos,
manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de
uso serán llevados a la práctica.
Requerimiento No Funcional: Específica criterios que pueden usarse para juzgar la operación de un
sistema en lugar de sus comportamientos específicos, por tanto, se refieren a todos los requisitos que
ni describen información a guardar, ni funciones a realizar.

80

Versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

1.0

SA

SB

SC

01.02.2011

Versión Original

PLAN DE GESTIÓN DE ADQUISICIONES
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

ADQUISICIONES DEL PROYECTO: ESPECIFICAR LA MATRIZ DE ADQUISICIONES DEL PROYECTO.
Ver Matriz Adquisiciones del Proyecto

PROCEDIMIENTOS ESTÁNDAR A SEGUIR: PROCEDIMIENTOS DE ADQUISICIÓN QUE SE DEBEN SEGUIR.
Para los contratos de capacitación por adjudicación directa por ser de menor cuantía se
realiza el siguiente proceso:
- Se solicita una cotización al representante autorizado en la capacitación de la
herramienta IBATIS y DOJO
- Se revisa la cotización y se calcula cuántos asistentes podrían participar para cumplir
con los requisitos para ser considerada de menor cuantía.
- Se negocia con el proveedor para fijar ajustes al contenido, horario y cantidad de
personas que podrían asistir al curso.
Se redacta el contrato final y lo firma ambas partes
Para contratos de equipamiento informático vía licitación pública se debe seguir lo estipulado
por la Ley de Adquisiciones del Estado
- Se solicita a la Oficina de Investigación Tecnológica un estudio de mercado en base al
Requerimiento Técnico remitido por el Líder Técnico del Poyecto HCDA
- Se remite el Requerimiento Técnico Final al Área de Compras
- Se construyen los términos de referencia en base al requerimiento técnico final
- Se pone en venta las bases de la licitación pública.
- Se reciben las solicitudes de postulación
- Se evalúa a los postulantes
- Se comunica el resultado del concurso en el que se otorga la buena pro
- Se firma el contrato previa conformidad del equipamiento
Para contratos de compra por menor cuantía de materiales de oficina nos basamos en la
lista de proveedores seleccionados:
- Se solicita las cotizaciones a los proveedores
- Se compara las cotizaciones
- Se compra el que otorgue mayor costo – beneficio
Se recibe los materiales en almacén y se cancela mediante cheque al proveedor.
Para contratos administrativo de servicios (CAS) se sigue lo que indica la norma:
- Se publica la convocatoria con las competencias requeridas
- Se reciben las hojas de vida
- Se realiza evaluación curricular
- Se publica la lista de aptos para entrevistas
- Se entrevista
- Los seleccionados de la entrevista firman el contrato
El inicio de labores es inmediato
FORMATOS ESTÁNDAR A UTILIZAR: FORMATOS DE ADQUISICIÓN QUE SE DEBEN SEGUIR.

81

La empresa TANUS tiene modelos predefinidos de contratación tipo CAS el cual estipula el
tipo de servicio, el periodo , la remuneración y periodicidad.

Para los contratos de capacitación externa, la empresa TAMA no tiene un formato
establecido, es el proveedor quien facilitará el contrato.

Para los contratos por adquisición de software es el proveedor quien entregará el contrato a
la empresa TAMA

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 establecieron las siguientes fechas para la realización de
los
contratos:
- Contratos de capacitación: Marzo del 2010
- Contratos de equipamiento informático: Marzo del 2010
- Contratos administrativo de servicios (CAS): Abril 2010
- Contratos de adquisición de SW : Abril 2010
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.

Contratos de capacitación: se deberá coordinar con los proveedores por lo menos un mes
antes a fin de asegurar que se pueda concretar durante el mes de marzo, las coordinaciones
se realizan por correo electrónico y con el pago del 50% antes de iniciar el servicio y
concluido éste el resto.
Contratos de equipamiento informático: el concurso se organiza 3 meses antes, el pago del
servicio es 100% una vez otorgado la conformidad.
Contratos administrativo de servicios (CAS): Se debe coordinar pata que el proceso inicie 2
meses antes. Este tipo de contratos son bastante rápidos pero se debe asegurar que
efectivamente el personal reúne las competencias requeridas.
Contratos de adquisición de SW: Abril 2011: se debe comprar con 1 mes de anticipación
para asegurar que el personal contratado podrá contar con las herramientas requeridas.
RESTRICCIONES Y SUPUESTOS: QUE

PUEDAN AFECTAR LAS ADQUISICIONES PLANIFICADAS Y POR LO TANTO EL

LOGRO DE LOS OBJETIVOS DEL PROYECTO.

Las restricciones y/o supuestos que han sido identificados y que pueden afectar las
adquisiciones del
proyecto son las siguientes:
- Se asume que de haber cambios de gobierno o cambios presupuestarios no habrán
cambios en el presupuesto ya otorgado para las adquisiciones
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 el Plan de Respuesta a Riesgos se tiene los siguientes:
R001 – Incumplimiento de Contratos de Capacitación
Las respuestas planificadas son:
- Solicitar a los participantes una evaluación del curso recibido por cada sesión.
- Solicitar ajustes al curso según resultado de encuestas
- Pagar el 50% si el servicio fue conforme
- Actualizar lista de proveedores

82

R002 – Incumplimiento del Contratos CAS
- Evaluación del desempeño laboral cada trimestre
- Renovación de contratos según resultado de evaluación
R002 – No Conformidad al Proveedor que obtuvo la Buena Pro
- Ejecutar la carta de garantía prevista en las bases
- Suspenderlo como proveedor del Estado por 2 años
MÉTRICAS: MÉTRICAS DE ADQUISICIÓN A SER USADAS PARA GESTIONAR Y EVALUAR PROVEEDORES.
Se tomarán como referencia el cumplimiento de plazos para la entrega de los productos y
servicios

83


Versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

1.0

SA

SB

SC

01.02.2011

Versión Original

MATRIZ DE ADQUISICIONES DEL PROYECTO
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA
CRONOGRAMA DE ADQUISICIONES REQUERIDAS

REQUERIMIEN
PRODUCTO O
SERVICIO A
ADQUIRIR

Capacitaci
ón
en
Herramient
a
de
Desarrollo
con DOJO

CÓDIGO
DE
ELEMENT
O WBS

TIPO DE
CONTRAT
O

Contrat
o
de
Precio
Fijo

PROCEDIMIEN
TO DE
CONTRATACIÓ
N

Adjudicaci
ón
por
menor
cuantía

FORMA DE
CONTACTAR
PROVEEDORES

TO DE
ESTIMACIONE
S
INDEPENDIENT
ES

Correo
No
electrónico
a
los
representan
te
autorizado
de
la
herramienta
en nuestro
país

ÁREA/ROL/PERSO
NA RESPONSABLE
DE LA COMPRA

MP

M ANEJO DE
MÚLTIPLES
PROVEEDOR
ES

Proveedo
r Único

PROVEEDOR
ES PRECALIFICADOS

Ninguno

Planif.
Contr
at
Del
al

Solic.
Resp
.
Del
al

Ener
o
2010

Ener
o
2010

Selecc.
Provee
d.

Admin.
Contrat
o

Cerrar
Contrat
o

Del al

Del al

Del al

Enero
2010

Febrer
o 2010

Febrer
o 2010

84


Capacitación
Herramienta
Desarrollo
IBATIS

en
de
con

Contrato
o
de
Precio
Fijo

Adjudicación
n por menor
cuantía

Correo
electrónico a
los
representante
e autorizado
de
la
herramienta
en
nuestro
país
Publicación
de Bases de
la Licitación.

No

M
P

Proveedor
Único

Ninguno

Ene
ro
201
0

Ener
o
2010

Ener
o
2010

Febrer
o 2010

Febrer
o 2010

Equipamiento
Informático
(10
PC’s, 1 impresora,
6 servidores, redes
para
telecomunicaciones
)
Materiales
de
Oficina
(papel,
cuadernos,
lapiceros)

Compra

Adjudicación
n
por
Licitación
Pública

SI
Cotizacione
s anteriores

M
P

Si

ninguno

Ene
ro
201
0

Ener
o
2010

Ener
o
2010

Febrer
o 2010

Marzo
2010

Compra

Adjudicació
n por menor
cuantía

Solicitud de
Cotización

SI
Cotizacione
s anteriores

M
P

Lista
de
Proveedore
s

Librerías
Li,
Tay
Loi, Lápiz
López

Ene
ro
201
0

Ener
o
2010

Ener
o
2010

Febrer
o 2010

Marzo
2010

Licencias de SW
IBATIS
para
desarrollo

Contrat
o
de
Precio
Fijo

Adjudicació
n por menor
cuantía

Correo
electrónico a
los
representant
e autorizado
de
la
herramienta
en
nuestro
país

No

M
P

Proveedor
Único

Ninguno

Ene
ro
201
0

Ener
o
2010

Ener
o
2010

Febrer
o 2010

Febrer
o 2010

85


Servicio
de
desarrollo,
y
diseño
construcción de
sistemas
de
información

CAS – Contrato
Administrativo
Servicios (Decreto
Legislativo
Nº
1057)

Concurso
abierto

Publicación de No
la convocatoria
en el portal de
la empresa

MP

Lista
de
Proveedores

Ninguno

Enero
2010

Enero
2010

Enero
2010

Febrero
2010

Febrero
2010

86


Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión Original

PLAN DE GESTIÓN DE RIESGOS
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de

HCDA

METODOLOGÍA DE GESTIÓN DE RIESGOS
PROCESO
DESCRIPCIÓN

HERRAMIENTAS

FUENTES DE INFORMACIÓN

Planificación de
Gestión de los
Riesgos

Elaborar Plan de Gestión
de los Riesgos

PMBOK
PMI Compendium

Sponsor y usuarios.
PM y equipo de proyecto

Identificación de
Riesgos

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

Checklist
riesgos

Sponsor y usuarios
Archivos históricos de
proyectos

Análisis Cualitativo
de Riesgos

Evaluar probabilidad e
impacto
Establecer ranking de
importancia

Definición de
probabilidad e
impacto
Matriz de
Probabilidad e
Impacto

Sponsor y usuarios.

Análisis Cuantitativo
de Riesgos

No se realizará

No aplica

No aplica

Planificación de
Respuesta a los
Riesgos

Definir respuesta a
riesgos
Planificar ejecución de
respuestas

Sponsor y usuarios.
Archivos históricos de
proyectos

Seguimiento y
Control del Riesgos

Verificar la ocurrencia de
riesgos. Supervisar y
verificar la ejecución de
respuestas. Verificar
aparición de nuevos
riesgos

Sponsor y usuarios.

.

ROLES Y RESPONSABILIDADES DE GESTIÓN DE RIESGOS
PROCESO
ROLES
PERSONAS

de

RESPONSABILIDADES

Planificación de
Gestión de los
Riesgos

Equipo de G. Riesgos
Líder
Apoyo
Miembros

JH
RS, EH
EM, AU, W A

Dirigir actividad, responsable
directo
Proveer definiciones
Ejecutar Actividad

Identificación de
Riesgos

Líder
Apoyo
Miembros

JH
RS, EH
EM, AU, W A

Dirigir actividad, responsable
directo
Proveer definiciones
Ejecutar Actividad
87

Análisis
Cualitativo
de Riesgos

Planificación de
Respuesta a los
Riesgos
Seguimiento
y
Control del Riesgos

Líder
Apoyo
Miembr
ros
Líder
Apoyo
Miembr
ros
Líder
Apoyo
Miembr
ros

JH
RS, EH
EM, AU, W A
JH
RS, EH
EM, AU, W A
JH
RS, EH
EM, AU, W A

PRESUPUESTO DE GESTIÓN DE RIESGOS
PROCESO
PERSONAS

Líder
Apoyo
Miembr
ros

Planificación de
Gestión de los
Riesgos

Dirigir activ
ividad, responsable
directo
Proveer de
efiniciones
Ejecutar A
Actividad
Dirigir activ
ividad, responsable
directo
Proveer de
efiniciones
Ejecutar A
Actividad
Dirigir activ
ividad, responsable
directo
Proveer de
efiniciones
Ejecutar A
Actividad

MATERIALES

EQU
UIPOS

$
70
$
180
$
50
$
300

TOTAL

$ 300

Identificación de
Riesgos
Análisis
Cualitativo
de Riesgos

Planificación
Respuesta
a
Riesgos

de
los

Seguimiento
y
Control del Riesgos
$ 300
PERIODICIDAD DE LA GESTI
TIÓN DE RIESGOS
PROCESO

Planificación de
Gestión de los
Riesgos
Identificación
Riesgos

MOMENT DE EJECUCIÓN
TO

de

Análisis Cualitativo
de Riesgos
Planificación
de
Respuesta a los
Riesgos
Seguimiento
y
Control del Riesgos

Al inicio del proyecto
En cada reunión del
a
equipo d proyecto
del
a
equipo d proyecto
del
a
equipo d proyecto
del
a
equipo d proyecto
del
En cada fase del
a
proyecto
o

ENTREGABLE DEL WBS

PERIODICIDAD DE
EJECUCIÓN


Una vez

Semanal
Semanal
Semanal
Semanal

Una vez
Semanal
Una vez
Semanal
Una vez
Semanal
Semanal

88

FORMATOS DE LA GESTIÓN DE RIESGOS
PROCESO EN
QUE SE
FORMATO
CONTENIDO

RESPONSABLE DE

FRECUENCIA O

GENERARLO

PERIODICIDAD

GENERA

Plan de Gestión
de Riesgos

Detalle del Plan de
Gestión de Riesgos

Identificación
y
Evaluación
Cualitativa
de
Riesgos

Lista de Riesgos con
el detalle del impacto
sobre el proyecto

Plan
Respuesta
Riesgos

de
a

Detalla las acciones a
ejecutar cuando el
riesgo se materializa

Informe
Monitoreo
Riesgos
Solicitud
Cambio

de
de

Detalla el estado de la
evaluación de los
riesgos identificados.
Detalla el cambio
solicitado que tendrá
efecto
positivo
o
negativo directo en el
plan del proyecto.
Detalla las acciones a Seguimiento
ejecutar a fin de y Control del
alinear el rendimiento Riesgos
previsto del trabajo
del proyecto con el
plan del proyecto.

de

Acción Correctiva

Planificación
de Gestión
de
los
Riesgos
Análisis
Cualitativo de
Riesgos
Identificación
de Riesgos
Análisis
Cualitativo de
Riesgos
Planificación
de
Respuesta a
los Riesgos
Seguimiento
y Control del
Riesgos
Seguimiento
y Control del
Riesgos

JH

Una vez (al inicio)

RS

Una vez (al inicio)

EH

Una vez (al inicio)

JH

Semanal

RS

Semanal

RS

Semanal

89


Versión

Hecha por

Revisada por

Aprobada por

Fecha

1.0

SA

SB

SC

01.02.2011

Motivo

Versión original

IDENTIFICACION Y EVALUACIÓN CUALITATIVA DE RIESGOS
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Implementación de
PROBABILIDAD
Muy Improbable
Relativamente Probable
Probable
Muy Probable
Casi Certeza
CÓDIGO
DEL RIESGO
R001

R002

R003

DESCRIPCIÓN DEL
RIESGO
Solicitud de
requerimientos
adicionales no
contemplados en el
alcance.
Solicitud de reemplazo
del personal contratado
que no cuenta con las
competencias requeridas
para el puesto

VALOR NUMÉRICO
0.1
0.3
0.5
0.7
0.9

CAUSA RAÍZ
Identificación de
nuevos entregables
por falla en la
elaboración del
Modelo del Negocio.

Selección de
personal no
corresponde a las
necesidades
requeridas para el
puesto
Suspensión del proyecto Cambios en

IMPACTO
Muy Bajo
Bajo
Moderado
Alto
Muy Alto

TRIGGER
Solicitud de
reunión para
incorporar
ajustes al
modelo de
negocio

HCDA
VALOR NUMÉRICO
0.05
0.10
0.20
0.40
0.80
ENTREGABLES
AFECTADOS
Todo el
proyecto

El software
Detección de
retrasos en la
entrega de los
programas o
rutinas
asignadas
Comunicaciones Todo el

TIPO DE RIESGO
Muy Alto
Alto
Moderado
Bajo
Muy Bajo

ESTIMACIÓN
DE

OBJETIVO
AFECTADO

PROBABILIDAD X IMPACTO
mayor a 0.50
menor a 0.50
menor a 0.30
menor a 0.10
menor a 0.05

ESTIMACIÓN
DE IMPACTO

PROBABILIDAD
Alcance
0.5
0.20
0.40
Tiempo
0.40
Costo
Calidad
TOTAL PROBABILIDAD X
IMPACTO
0.3
Alcance
Tiempo
0.40
Costo
Calidad
0.10
IMPACTO

0.5

Alcance

0.10

PROB X
IMPACTO

TIPO DE
RIESGO

0.10
0.20
0.20
0.50

Alto

0.12
0.03
0.15
0.05

Moderado
Muy Bajo

90


normatividades
Oficiales
externas que afectan recibidas por la
el sustento legal del alta dirección
proyecto.
R004

R005

R006

R007

Baje la prioridad del
proyecto

Ejecución de garantías
por incumplimiento
contractual en entrega
de equipos de cómputo.

Solicitud de reemplazo
del Personal contratado
CAS por incumplimiento
de contrato.

Desaprobación del
usuario del software
terminado

Cambios de
directivos claves
para el proyecto

-Falta de stock por
parte del proveedor.
-Configuración no
corresponde a la
solicitada.
-Selección
inapropiada de
proveedor
Remuneración no
competitiva con el
mercado laboral

El software no
contempla todos los
requerimientos
establecidos en el
alcance

proyecto

Comunicaciones Todo el
Oficiales
proyecto
emitidas por la
alta dirección

Detección
de Todo el
incumplimientos Proyecto
y signos de falta
de calidad en el
servicio

0.5

0.1

Tiempo
Costo
Calidad
IMPACTO
Alcance
0.40
Tiempo
Costo
Calidad
IMPACTO
Alcance
Tiempo
0.4
Costo
0.2
Calidad
IMPACTO

0.05
0.20

0.20

Moderado

0.04
0.02

0.06
Bajo

Conversaciones Todo el
Proyecto
o consultas
informales

Detección de no El software
conformidad
durante la
prueba de
aceptación del
usuario.

0.3

0.3

0.4
Alcance
0.2
Tiempo
0.4
Costo
Calidad
0.2
IMPACTO
Alcance
0.4
Tiempo
Costo
0.2
Calidad
IMPACTO

0.12
0.06
0.12
0.06
0.36

Moderado

0.12
0.06
0.18

Moderado

91


Versión

Hecha por

1.0

SA

Revisada por

Aprobada por

Fecha

SC

01.02.2011

SB

Motivo

Versión original

PLAN DE RESPUESTA A RIESGOS
NOMBRE DEL PROYECTO

SIGLAS DEL PROYECTO

Informáticas

HCDA

Ordenados
en forma
Decreciente

Evitar
Mitigar
Transferir
Explotar
Compartir
Mejorar

Muy Alto
Alto
Moderado
Bajo
Muy Bajo

Aceptar
CÓDIGO
DEL
RIESGO

R001

R002

PROBABILIDAD
AMENAZA /
OPORTUNIDAD

Amenaza

Amenaza

DESCRIPCIÓN DEL
RIESGO

Solicitud de
requerimientos
adicionales no
contemplados en el
alcance.

Solicitud de
reemplazo del
Personal
contratado CAS
por incumplimiento
de contrato.

CAUSA RAÍZ

Identificación
de nuevos
entregables
por falla en la
elaboración
del Modelo del
Negocio.

T RIGGER

ENTREGABLES
AFECTADOS

POR

IMPACTO
TOTAL

TIPO DE
RIESGO

RESPONSABLE DEL
RIESGO

RESPUESTAS
PLANIFICADAS

TIPO DE
RESPUESTA

RESPONSABLE
DE LA

RESPUESTA

Coordinación
permanente con el
líder usuario.
Solicitud de
reunión para
incorporar
ajustes al
modelo de
negocio

Remuneración
no competitiva Conversaciones
con el
o consultas
informales
mercado
laboral

Todo el proyecto

Todo el proyecto

0.50

Alto

SB

0.36
Moderado

EP/SB

Reuniones de
retroalimentación
con personas del
área usuaria

Reuniones de
retroalimentación
sobre grado de
satisfacción

FECHA
PLANIFICADA

Acción continúa

Mitigar

SB
Durante la etapa
de análisis de
requerimientos

Mitigar

SB

Reuniones
mensuales

PLAN DE
CONTINGENCIA

Evaluación del
impacto sobre la
incorporación de
nuevos
requerimientos.
Decisión de
inclusión en el
actual proyecto en
uno posterior

Evaluación del
impacto en el
alcance, costo y
tiempo.
Considerar la
incorporación
temporal al proyecto
de otro recurso.
(priorización de
proyectos)

92


SB
Baje la prioridad
del proyecto
R003

Amenaza

Desaprobación del
usuario del
software terminado
R004

Amenaza

Cambios de
directivos
claves para el
proyecto

El software no
contempla
todos los
requerimientos
establecidos
en el alcance

Comunicaciones
Oficiales
emitidas por la
alta dirección

Todo el proyecto

0.20

Participación en
determinación y
priorización de
cartera de proyectos

Moderado

SB
Conversaciones
o consultas
informales

El software

0.18

Moderado

Evaluación de
selección de
personal no
corresponde a
las
necesidades
requeridas
para el puesto

Ejecución de
garantías por
incumplimiento
contractual en
entrega de equipos
de cómputo.

-Falta de stock
por parte del
proveedor.
-Configuración
no
corresponde a
la solicitada.
-Selección
inapropiada de
proveedor

Detección de
retrasos en la
entrega de los
programas o
rutinas
asignadas

R006

Amenaza

Amenaza

Detección de
incumplimientos
y signos de falta
de calidad en el
servicio

El software

Todo el Proyecto

0.15

0.06

Moderado

EP/SB

Reuniones de
retroalimentación
sobre grado de
satisfacción

Bajo

SB
Suspensión del
proyecto
R007

Amenaza

Cambios en
normatividades
externas que
afectan el
sustento legal
del proyecto.

Comunicaciones
Oficiales
recibidas por la
alta dirección

Todo el proyecto

0.05

Muy Bajo

Seguimiento
semanal de las
tareas asignadas.

Evaluación del
impacto para
determinar el
tiempo y costo
que
representaría
levantar las
observaciones

Acción continúa

Durante la etapa
de análisis de
requerimientos

Reuniones
semanales

Evaluación del
impacto en el
alcance, costo y
tiempo.
Considerar la
incorporación
temporal al
proyecto de otro
recurso.
(priorización de
proyectos)

Acción continua
Durante las etapas
de desarrollo y
pruebas

Evaluación del
impacto.
Tomar medidas
correctivas

SB

Monitoreo de los
equipos de
cómputo.
Encuestas de
satisfacción al
equipo de proyecto
sobre el grado de
respuesta de los
equipos.
Actualizar lista de
proveedores
alternativos
Participación en
determinación y
priorización de
cartera de
proyectos.

Evaluación del
impacto.
Informar al área
usuaria.

Reuniones
formales de
priorización de
proyectos

Mitigar

Seguimiento
semanal de las
tareas asignadas.

SB

R005

SB

SB

Coordinación
permanente con el
líder usuario.

Reuniones de
retroalimentación
con personas del
área usuaria

Solicitud de
reemplazo del
personal
contratado
que no cuenta con
las competencias
requeridas para el
puesto

Mitigar

Mitigar

SB

Mitigar

SB
Mitigar

Evaluación del
impacto.
Informar al área
usuaria.

Reuniones
formales de
priorización de
proyectos

93

Implementación de Herramientas Informáticas - Planificación

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Implementación de Herramientas Informáticas - Planificación (20)

Más de Dharma Consulting (20)

Implementación de Herramientas Informáticas - Planificación