Programacion Orientada A Objetos

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERA
DIVISIN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS
CARRERA DE INGENIERA DE SISTEMAS
ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN

LOS PROCESOS DE DESARROLLO DE SOFTWARE
PROYECTO PROFESIONAL PRESENTADO POR:

GABRIELA ELENA GUEVARA VALDIVIA
ANA GLORIA MORALES TORRES
PARA OPTAR POR EL TTULO DE INGENIERO DE SISTEMAS
Lima, Noviembre del 2011
ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

PROCESOS DE DESARROLLO DE SOFTWARE
RESUMEN
El presente proyecto de tesis consiste en "Establecimiento de modelos y
metodologas innovadoras en los procesos de desarrollo de software", debido a
las grandes necesidades de software y a las oportunidades de negocio que se
logran obtener. El objetivo del proyecto es comprender que las diferencias entre
software y otros productos se encuentran en el proceso de desarrollo detrs de su
elaboracin.
Para tal efecto el proyecto se ha dividido en 3 captulos, en el primer captulo se

realiza levantamiento de informacin de cmo se lleva a cabo un proceso
actualmente en el cual existen procedimientos manuales que pueden ser
automatizados; mediante el uso de herramientas tecnolgicas se elaboran los
modelos del proceso actual y el proceso nuevo propuesto; para su revisin,
aprobacin y elaboracin por parte de los interesados.
En el segundo captulo se lleva a cabo la evaluacin de los procesos de

planificacin y gestin de requerimientos utilizados en un rea de desarrollo de
software con el propsito de aplicar las prcticas generales y especficas
establecidas por el Modelo CMMI (Capability Maturity Model Integration).
Finalmente en el tercer captulo se manifiesta la aplicacin de algunas prcticas

utilizadas por las metodologas giles de desarrollo de software en nuestros
centros de trabajo, con el fin de establecer valores y principios que permitan a los
equipos desarrollar software rpido, respondiendo a cambios que puedan surgir a
lo largo del proyecto.
-2-

NDICE
LISTAS ESPECIALES ............................................................................................ 5

INTRODUCCIN ................................................................................................... 9
CAPITULO 1 ........................................................................................................ 12
GESTIN DE PROCESOS DE NEGOCIO ....................................................... 12
INTRODUCCIN .............................................................................................. 13
1.1
Presentacin de la empresa objeto de estudio ......................................... 14
1.2
Campo de accin...................................................................................... 17
1.3
Prototipo del proceso en BPM Studio ....................................................... 26
1.4
Indicadores de desempeo ...................................................................... 28
CONCLUSIONES .............................................................................................. 30
CAPITULO 2 ........................................................................................................ 31
CMMI ................................................................................................................. 31
INTRODUCCIN .............................................................................................. 32
2.1
Objeto de estudio ..................................................................................... 33
2.2
Alcance de la evaluacin .......................................................................... 36
2.3
Factibilidad del cambio ............................................................................. 36
2.4
Evaluacin de la situacin actual ............................................................. 39
2.5
Procesos propuestos. ............................................................................... 48
CONCLUSIONES .............................................................................................. 59
CAPITULO 3 ........................................................................................................ 60
MTODOS GILES PARA EL DESARROLLO DE SOFTWARE ...................... 60
INTRODUCCIN .............................................................................................. 61
3.1
Fundamentacin Terica .......................................................................... 63
3.2
Adopcin de Prcticas giles ................................................................... 71
3.2.1
Prctica gil 1: Kanban ....................................................................... 71
3.2.2
Prctica gil 2: Daily Meeting ............................................................. 79
3.2.3
Prctica gil 3: Task board ................................................................. 84
3.2.4
Prctica gil 4: Pair Programming ...................................................... 93
3.3
Evaluacin de Resultados ........................................................................ 97
CONCLUSIONES .............................................................................................. 99
-3-

CONCLUSIONES............................................................................................... 101
GLOSARIO DE TRMINOS ............................................................................... 103
SIGLARIO .......................................................................................................... 104
BIBLIOGRAFA .................................................................................................. 105
ANEXOS ............................................................................................................ 106
7.1
Plantillas para el proceso: Project Planning (PP) ................................... 106
7.2
Plantillas para el proceso: Requirements Management (REQM) ........... 133
-4-

LISTAS ESPECIALES
Figura 1 Organigrama de AMERICATEL PERU SA. ....................................................................... 15
Figura 2 Organigrama de la Gerencia Comercial y Finanzas. ......................................................... 16
Figura 3 Ciclo de facturacin para el producto de Larga Distancia ................................................. 17
Figura 4 Lnea de tiempo del producto de larga distancia ............................................................... 18
Figura 5 Etapas de la gestin de cobranzas para el producto de Larga Distancia ......................... 18
Figura 6 Lnea de tiempo configurada para el producto Larga Distancia ........................................ 20
Tabla 1 Descripcin del proceso actual de la Gestin de cobranza ................................................ 22
Figura 7 El tiempo aproximado en que demora es de 3 horas ........................................................ 23
Tabla 2 Situacin Problema del proceso actual de la Gestin de Cobranza ................................... 24
Figura 8 Proceso Gestin de Cobranza ........................................................................................... 26
Figura 9 Subproceso de la Generacin de las Etapas de Cobranza ............................................... 26
Figura 10 Evento de cancelacin de gestin de cobranza .............................................................. 26
Figura 11 Subproceso de la Gestin de Cobranza para la Etapa de Telecobranza Personalizada 27
Tabla 3 Indicador de Desempeo 1 ................................................................................................. 28
Figura 12 Organigrama SYPSA SAC ............................................................................................... 35
Tabla 6 Evaluacin de Cumplimiento para el rea de proceso PP .................................................. 42
Tabla 7 Evaluacin de Cumplimiento para el rea de proceso PMC .............................................. 44
Tabla 8 Evaluacin de Cumplimiento para el rea de proceso REQM............................................ 45
Figura 13 Prcticas cumplidas y no cumplidas para Planeamiento de Proyectos .......................... 46
Figura 14 Practicas cumplidas y no cumplidas para Monitoreo y Control de Proyectos ................. 46
Figura 15 Prcticas cumplidas y no cumplidas para Gestin de Requerimiento ............................. 47
Figura 16 Total de prcticas cumplidas y no cumplidas para las tres reas de procesos ............... 47
Figura 17 Proceso para el Planeamiento de Proyectos (PP) .......................................................... 48
Tabla 9 Descripcin del proceso propuesto para el rea de proceso PP ........................................ 49
Tabla 10 Roles y conocimientos esperados para el rea de proceso PP ....................................... 49
-5-

Tabla 11 Descripcin de las actividades propuestas para el rea de proceso PP .......................... 51

Tabla 12 Matriz de trazabilidad de las actividades vs prcticas especficas de PP ........................ 52
Figura 18 Proceso para la Gestin de requerimientos (REQM) ...................................................... 53
Tabla 13 Descripcin del proceso propuesto para el rea de proceso REQM ................................ 56
Tabla 14 Roles y conocimientos esperados para el rea de proceso REQM ................................. 56
Tabla 15 Descripcin de las actividades propuestas para el rea de proceso REQM .................... 57
Tabla 16 Matriz de trazabilidad de las actividades vs prcticas especficas de REQM .................. 58
Figura 19 Tablero Kanban [2]........................................................................................................... 63
Figura 20 Daily meeting [3] .............................................................................................................. 66
Figura 21 Un Task Board con historias de usuario, tareas y estatus de implementacin. .............. 67
Fuente: Eclipse Wikis: Scrum ........................................................................................................... 67
Figura 22 Pair programming[7] ......................................................................................................... 68
Figura 23 Sit together[8] ................................................................................................................... 70
Figura 24 Sprint 2 Tablero Kanban (1) ............................................................................................. 75
Figura 28 Sprint 2 Daily meeting (1) ................................................................................................ 81
Figura 32 Sprint 2 Task board (1) .................................................................................................... 88
Figura 34 Sprint 3 Task board(1) ..................................................................................................... 91
Figura 36 Sprint 1 Pair Programming (1) ......................................................................................... 94
-6-

Figura 40 Plantilla WBS.doc ........................................................................................................... 106

Figura 41 Estimar los elementos de funcionalidad ........................................................................ 107
Figura 42 Estimar los archivos lgicos ........................................................................................... 107
Figura 43 Estimar factores de ajuste.............................................................................................. 108
Figura 44 Ajustar los puntos de funcin ......................................................................................... 108
Figura 45 Estimar factibilidad econmica ...................................................................................... 108
Figura 46 Distribuir la factibilidad econmica ................................................................................. 109
Figura 47 Ciclo de Vida.doc ........................................................................................................... 110
Figura 48 Variables a considerar.xls .............................................................................................. 110
Figura 49 Calculo del presupuesto.xls ........................................................................................... 110
Figura 50 Plantilla de lista de verificacin para estimacin de costos.doc .................................... 111
Figura 51 Plantilla para Hitos del Proyecto.doc ............................................................................. 112
Figura 52 Plantilla del cronograma detallado.xls ........................................................................... 113
Figura 53 Plantilla de registro de los riesgos.doc .......................................................................... 114
Figura 54 Evaluacin cualitativa de los riesgos.xls ........................................................................ 114
Figura 55 Poltica Plan de Datos.doc ............................................................................................. 115
Figura 57 Plantilla del plan de capacitacin.doc ............................................................................ 119
Figura 58 Plantilla del Acta de constitucin del proyecto.doc ........................................................ 120
Figura 59 Plantilla de Acta de Reunin .......................................................................................... 123
Figura 60 Plantilla de relacin de miembros del proyecto.doc ...................................................... 124
Figura 61 Poltica para Planificacin de Proyectos.doc ................................................................. 125
Figura 62 Plantilla para el Seguimiento y control de tareas.doc .................................................... 131
Figura 64 Plantilla Solicitud de Requerimiento.doc........................................................................ 133
Figura 65 Plantilla Lista de requerimientos.xls ............................................................................... 134
Figura 66 Plantilla Acta de Reunin ............................................................................................... 135
Figura 67 Plantilla Lista de Cambios.doc ....................................................................................... 136
Figura 68 Plantilla para especificacin de Caso de Uso.doc ......................................................... 137
Figura 69 Plantilla Cronograma de Desarrollo.xls .......................................................................... 138
Figura 71 Plantilla Poltica de Gestin de Requerimientos.doc ..................................................... 139
-7-

Figura 72 Plantilla para Requerimientos de recursos.doc ............................................................. 143

Figura 73 Plantilla de roles para requerimientos.doc ..................................................................... 143
Figura 74 Plantilla para encuesta de satisfaccin.doc ................................................................... 144
Figura 75 Plantilla Lista de verificacin para evaluar la adherencia del proyecto.doc .................. 145
-8-

INTRODUCCIN
El presente trabajo se redacta con carcter de trabajo profesional para la
obtencin del ttulo de Ingeniero de Sistemas en la que se desarrolla tres casos
prcticos que tienen por objetivo plasmar los conocimientos adquiridos durante el
desarrollo del curso de actualizacin profesional.
Debido a que nos encontramos en un medio que cambia constantemente, las

organizaciones deben responder a una creciente demanda de complejidad en sus
operaciones, definida por la convergencia de requerimientos de clientes y socios
de negocios con relacin a informacin operativa, la rapidez de los cambios en el
mercado y una infraestructura de sistemas de informacin completamente
heterogneas; esta necesidad requiere mantener una continua actualizacin de
las nuevas herramientas, metodologas y estndares de desarrollo para poder
brindar soluciones ptimas a las organizaciones.
Actualmente las nuevas tendencias no siempre son aplicadas y en muchos casos

se debe a la desconfianza basada en el conocimiento necesario para aplicarlas;
es preciso resaltar que invertir en infraestructura tecnolgica y sistemas de
informacin no necesariamente significa que las cualidades positivas brotarn
complementariamente por s solas, ya que no obstante el avance tecnolgico que
pudiera haber sido implementado, an se requerir que a nivel organizacional se
concrete el cambio de sus procesos con el acogimiento de modelos,
metodologas, mtodos, y buenas prcticas que sean aplicadas como una
solucin complementaria e integral.
Los
proyectos
de
desarrollo
son
crticos
en
muchas
organizaciones,
especialmente para aquellas cuyo principal rubro de negocio es el servicio de

desarrollo de software a la medida. Este trabajo pretende ser un aporte de
investigacin a las nuevas herramientas de desarrollo del mercado, as mismo
como ejemplo de aplicacin de innovadoras prcticas, procesos y procedimientos
-9-

que darn origen a soluciones de negocio ms sofisticadas las cuales brinden la

diferenciacin y ventaja competitiva de las organizaciones que las implementan.
El presente proyecto tambin tiene como objetivo aplicar los diferentes modelos y
metodologas para mejorar e innovar, el desenvolvimiento de los procesos de
desarrollo de software en las organizaciones desde el modelado de un proceso de
negocio hasta la ejecucin de los entregables, cumpliendo con las buenas
prcticas que garantizarn la efectividad del proceso de desarrollo de software.
La compresin de la importancia y los conceptos principales de la gestin de

procesos de negocio en las organizaciones, dado que constituyen un sistema
enfocado a perseguir la mejora continua del funcionamiento de las actividades de
una organizacin. Es as que elaborar un modelo de proceso de negocio
utilizando la notacin BPMN permitir identificar y seleccionar los procesos y su
descripcin, documentacin y mejora continua de los mismos.
Disear los procesos de desarrollo de software de una organizacin a travs de

un proyecto de mejora de procesos y la aplicacin de un conjunto de prcticas
realizadas con el objetivo de alcanzar un propsito determinado. El utilizar CCMi
como modelo de referencia permitir interpretar correctamente las prcticas de un
grupo de reas de proceso de los proyectos de desarrollo de software.
Promover el desarrollo de proyectos y su gestin en procesos con ciclos de

lapsos cortos de tiempo y por organizaciones ms flexibles y adaptables que
permitan incorporar cambios con rapidez y en cualquier fase del proyecto es parte
de la filosofa de las metodologas giles, as como abogar para lograr mayor
fluidez con los clientes en cuanto a negociacin, requerimientos y entregables.
Aplicando mtodos giles se lograr implementar los procesos de negocio de una
organizacin en forma iterativa e incremental.
En tal sentido el documento consta de tres captulos cuyo desarrollo explica por s
solo cada uno de los temas de buenas prcticas que ha sido abarcado.
- 10 -

En el primer captulo, se realiza un modelado del proceso de negocio de gestin

de cobranza para una empresa de telecomunicaciones, por su facturacin vencida
y pendiente en la etapa de tele-cobranza aplicando la metodologa BPM; con lo
cual se logra obtener un mapa claro del proceso real, de las reas y agentes
externos involucrados en el proceso y el nuevo mapa propuesto para su
implementacin.
En el segundo captulo, se aplica la metodologa CMMi para la mejora de

procesos de planificacin de proyectos y gestin de requerimientos en un rea de
desarrollo de software la cual presenta carencias en la definicin de procesos; a
travs de la evaluacin de la situacin actual se tuvo conocimiento del
cumplimiento y aplicacin de las prcticas especficas y genricas establecidas
por CMMi en una organizacin real.
En el tercer captulo, se desarrollan algunas prcticas utilizadas en las

metodologas giles como: daily meeting, taskboard, kanban y pair programming;
cada una de las cuales fueron implementadas en nuestros centros de trabajo
como evidencia de la aplicacin de las prcticas, las mismas que describen la
experiencia y retrospectiva en cada entregable (sprint) luego de su ejecucin.
- 11 -

CAPITULO 1
GESTIN DE PROCESOS DE NEGOCIO
- 12 -

INTRODUCCIN
Las organizaciones deben responder a una creciente demanda de complejidad en
sus operaciones, definida por la convergencia de requerimientos de clientes y
socios de negocios con relacin a informacin operativa, la rapidez de los
cambios en el mercado y una infraestructura de sistemas de informacin
completamente heterognea.
Las organizaciones se apoyan en sus procesos de negocios para ser guiados en

este complejo escenario. No obstante, en muchas organizaciones, dada la
complejidad del mismo, existe una importante diferencia entre los procesos que
deberan estar implantados y los procesos que se encuentran operando el
negocio en realidad.
La Gestin de procesos de negocio (BPM) es una metodologa corporativa que se

enfoca en la administracin de los procesos dentro de una organizacin y cuyo
objetivo es mejorar la eficiencia a travs de la gestin de los procesos de negocio,
que se deben modelar, organizar, documentar y optimizar de forma continua.
El presente trabajo, consisten en proponer una mejora en los procesos de gestin

de cobranza propiamente dicha a la deuda vencida y pendiente en la etapa de
tele-cobranza de la Empresa Americatel Per S.A. con la ayuda del BPM se podr
obtener un mapa claro del proceso real as como las reas y proveedores
externos involucradas en el proceso y el nuevo mapa propuesto para su
implementacin.
En tal sentido, el documento est organizado como sigue: Presentacin de la

Empresa objeto de estudio; Definicin del campo de accin; Modelo prototipo del
proceso en BPMN propuesto como mejora; Y finalmente, los indicadores de
desempeo que permitirn evaluar la mejora; todo lo cual, pasaremos a explicar
a continuacin.
- 13 -

1.1 Presentacin de la empresa objeto de estudio

Americatel es una empresa de telecomunicaciones que comienza a operar en el
Per en el 2002 y da inicio a una verdadera revolucin en el mercado de Larga
Distancia con el lanzamiento del cdigo 19-77.
a. MISIN
Ser un proveedor integral de servicios de telecomunicaciones, llegando
directamente
al
usuario
final,
por
medios
almbricos
inalmbricos,
consolidndose de esta forma como un actor importante en los segmentos de

negocios donde opera.
b. VISION
La Empresa debe ofrecer soluciones de telecomunicaciones eficientes e
innovadoras tecnolgicamente, para as contribuir en el crecimiento de nuestros
clientes con el mejor servicio y a precios competitivos.
c. OBJETIVOS ESTRATGICOS
El objetivo principal de Americatel es satisfacer las necesidades de los clientes.

Por ello, ha incrementado la cartera de productos que ofrece en el mercado,
incluyendo adems de la Larga Distancia, Servicios de Internet, Telefona Fija,
Transmisin de Datos y Americatel NGN. De esta forma, ratifica su compromiso
de ser la mejor opcin en servicios integrales de telecomunicaciones tanto para
empresas, como para personas en todo el Per.
Americatel Per est focalizada en cuatro segmentos de mercado: Empresas,

Corporaciones, Masivo y Mayoristas.
En Empresas, su objetivo es crecer en el segmento PYMES ofreciendo una
solucin integral de telecomunicaciones a travs de los medios de accesos
disponibles (Wimax y planta externa), en Lima y Callao.
- 14 -

En el segmento Corporaciones, el objetivo es mantener y desarrollar la

cartera de clientes agregando servicios de Tecnologas de Informacin y
servicios satelitales a nivel nacional.
En el segmento Masivo, el objetivo es procurar estabilizar los mrgenes del
servicio de larga distancia en un entorno altamente competitivo y de tendencia
decreciente para as generar nuevas oportunidades de desarrollo. Para
lograrlo se adoptan estrategias de acuerdo al tipo de cliente:
En el segmento masivo personas, se aplicarn promociones peridicas
para generar percepcin de precios bajos y recordacin de marca y se
realizarn campaas mensuales de tele-venta.
En el segmento masivo empresas, se ofrecern planes adaptados a las
necesidades de cada cliente.
En el segmento Mayorista, el objetivo es rentabilizar la red de transporte local
y nacional, mediante la terminacin de trfico a operadores nacionales e
internacionales y el backbone a travs de la oferta de circuitos de transporte
local de altas capacidades a operadores de telecomunicaciones.
d. ORGANIGRAMA
Organigrama de Americatel Per S.A.
Gerencia General
Secretaria
Analista Direccin de Estudios
Gerencia Legal y
Relaciones Institucionales
Asistente Legal
Gerencia de Operaciones
Gerencia Comercial de
Empresas
Gerencia de Asuntos
Regulatorios
Especialista en
Asuntos Regulatorios
Gerencia Comercial
Masivos y Wholesale
Gerencia de
Administracin y Finanzas
Figura 1 Organigrama de AMERICATEL PERU SA.

Fuente: AMERICATEL PER SA
- 15 -

Organigrama de la Sub Gerencia de Control Financiero

Americatel Per S.A.
Sub Gerencia de Control Financiero
Asistente de Control y
Aseguramiento Ingresos
Jefe de Liquidaciones y
Control de Trfico
Asistente de Provisiones
y Liquidaciones
Tesorera
Jefe de Cobranzas
Asistente de Tesorera
Asistente 1 de Cobranzas
Auxiliar de Cobranzas
Figura 2 Organigrama de la Gerencia Comercial y Finanzas.

Fuente: AMERICATEL PER SA
- 16 -

1.2 Campo de accin

Americatel cuenta con un rea de cobranzas la cual tiene asignada dos
responsabilidades: La primera, informar la recaudacin de lo facturado en sus
diversas modalidades; y la segunda, realizar gestin de cobranza propiamente
dicha a la deuda vencida y pendiente, sta ltima responsabilidad ser el objeto
de estudio del presente documento.
Detalles del proceso de gestin de cobranza para el producto Larga

Distancia
El proceso de gestin de cobranza se efecta para documentos de un ciclo de
facturacin y producto determinado, para los cuales le corresponde ejecutar una
etapa de gestin. Los documentos de un ciclo de facturacin tienen la misma
fecha de facturacin y de vencimiento. Por ejemplo para el producto larga
distancia existen 2 ciclos de facturacin durante un mes.
Producto
Larga Distancia
Ciclo
Fecha
de
Fecha
de
Facturacin
Vencimiento
01092011
10/08/2011
27/08/2011
05092011
31/08/2011
15/09/2011
Figura 3 Ciclo de facturacin para el producto de Larga Distancia
La gestin de cobranza para una empresa de telecomunicaciones debe tener en

cuenta normas establecidas por las entidades reguladoras de los servicios que
prestan (OSIPTEL), adems de contar con reglas del negocio establecidas por la
empresa, se manejan etapas de cobranza las cuales deben realizarse en caso
que un documento se encuentre vencido y pendiente; la definicin y el orden de
estas etapas se encuentran configuradas en una lnea de tiempo, el cual vara por
cada producto, adems de considerar reglas de negocio que restrinjan o
suspendan alguna gestin de cobranza.
- 17 -

Lnea de tiempo de Larga Distancia
Das despus del Vcto.
Fecha de
Vencimiento
15
22
Tele-cobranza Envo de carta Suspensin del

personalizada
masiva
servicio
42
49
Corte del
servicio
64
Envo de carta Tercerizacin

pre registro
cartera
72
182
212
Anulacin del
negocio
Registro en
centrales de
riesgo
Cobranza
judicial
Figura 4 Lnea de tiempo del producto de larga distancia
Una de estas reglas establecidas por la entidad reguladora seala que no es

posible realizar gestin de cobranza sobre los clientes que han realizado reclamos
de los montos facturados a su consumo. Los reclamos son gestionados por el
rea de Servicio de Atencin al Cliente (SAC) quienes a travs de servicios WEB
publicados nos brindarn informacin de los reclamos, nuevos reclamos o
cambios en los estados de los reclamos.
Otra de las reglas menciona que no es posible realizar gestin de cobranza sobre
los clientes a los cuales se le denomina CORPORATIVOS. La segmentacin de
los clientes es proporcionada por el rea de ventas.
Las etapas de cobranza configuradas para el producto larga distancia son:
Figura 5 Etapas de la gestin de cobranzas para el producto de Larga Distancia
- 18 -

Tele-cobranza Personalizada: Etapa en la que se realiza una llamada al

cliente deudor indicndole su pago vencido y pendiente, esperando obtener
una fecha de promesa de pago. El resultado de la gestin es tipificado para
control y evaluacin de la recuperacin.
Envo de Carta Masiva: Etapa en la que se enva al cliente deudor una
comunicacin escrita informndole sobre su pago vencido y pendiente. El
resultado de la gestin (recepcin del documento) es tipificado para control y
evaluacin de la recuperacin.
Suspensin del servicio: Como norma establecida por la entidad reguladora,
antes de realizar esta gestin se debe verificar la ejecucin de la gestin de
envo de carta masiva. Se comunica al rea de operaciones para que realice
la suspensin del servicio. El resultado debe indicar si se realiz o no, con
xito la suspensin.
Corte del servicio: Como norma establecida por la entidad reguladora, antes
de realizar esta gestin se debe verificar la ejecucin de dos gestiones
anteriores: envo de carta masiva y suspensin. Se comunica al rea de
operaciones para que realice el corte del servicio. El resultado debe indicar si
se realiz o no, con xito el corte.
Envo de Carta Pre Registro (en centrales de riesgo): Etapa en la que se
enva al cliente deudor una comunicacin escrita informndole sobre su pago
vencido y pendiente, adems que de no hacerse efectiva la cancelacin se
informar a las centrales de riesgo. El resultado de la gestin (recepcin del
documento) es tipificado para control y evaluacin de la recuperacin.
Tercerizacin de Cartera: En esta etapa se encarga la gestin de cobranza
por un lapso de tres meses a un proveedor externo. El resultado de la gestin
es tipificado para control y evaluacin de la recuperacin.
- 19 -

Anulacin de Negocio: Como norma establecida por la entidad reguladora,

antes de realizar esta gestin se debe verificar la ejecucin del corte del
servicio. Esta gestin ocasiona la anulacin del contrato establecido entre la
empresa y el cliente.
Registro en Centrales de Riesgo: En esta etapa se genera un documento con
la informacin de los clientes deudores y se enva a las centrales de riesgo
(Infocorp) para el respectivo registro. El resultado de la gestin es tipificado
para control y evaluacin de la recuperacin.
Cobranza Judicial: En esta etapa se requiere generar un expediente con toda
la informacin asociada a la gestin de cada deudor durante todo el proceso,
que permita tener el sustento para poder iniciar acciones legales.
Figura 6 Lnea de tiempo configurada para el producto Larga Distancia
La eleccin del presente proceso est relacionado con la gestin de cobranza en

la etapa de Tele-cobranza Personalizada para el producto de Larga Distancia.
A continuacin se describe el proceso actual, el cual es realizado mediante el uso

de hojas de clculo.
- 20 -

Descripcin del proceso actual

1
Obtener Documentos a Gestionar
Se extrae en una hoja de clculo la relacin de documentos vencidos y

pendientes de pago a la fecha de realizar la gestin, tomando en cuenta lo
siguiente:
a. Los documentos deben pertenecer al ciclo a gestionar, estos no deben tener
registrada ninguna gestin consumada de cobranza (sigue pendiente de
pago).
b. En caso se identifiquen documentos que no pertenezcan al ciclo a gestionar y
que an prevalecen como pendientes de pago y sin haber pasado por
ninguna gestin de cobranza, tambin deben ser considerados en esta base.
2
Filtrar Documentos a Gestionar

Se selecciona los documentos que pertenecen slo al producto de larga
distancia.
Ordenar Informacin por Documento

Se ordena la informacin por el nmero de documento.
Buscar y Excluir Documentos de Clientes Corporativos

a. Se realiza la bsqueda de los documentos cuyos clientes (funciones de
bsqueda) se encuentren en la relacin de clientes con segmentacin
corporativa.
b. Los documentos de clientes que tienen segmentacin corporativa son
excluidos.
Buscar y Excluir Documentos en Reclamo

a. Se realiza la bsqueda de los documentos a gestionar (funciones de
bsqueda) en la relacin de reclamos enviados en hoja de clculo.
b. Los documentos marcados con reclamo son excluidos.
Ordenar Informacin por Cliente

Se ordena la informacin por el cdigo de cliente.
Ordenar Informacin por Negocio

Se ordena la informacin por el nmero de negocio.
Buscar Informacin del Negocio

a. Se realiza la bsqueda de los negocios para obtener los anis activos por
negocio y los telfonos de contacto del cliente.
b. Se complementa con la informacin del negocio encontrada.
- 21 -

Generar Archivo de Gestin

a. Se guarda la hoja de clculo como Base Final a Gestionar
b. Se prepara archivo de texto (segn estructura definida) para enviar al
proveedor que realiza la gestin de tele-cobranza personaliza.
10
Enviar Archivo al Proveedor

Se realiza el envo del archivo al proveedor y se obtiene la confirmacin de
recepcin del archivo por parte del proveedor.
11
Cargar Resultado de Gestin

Se recibe el archivo por el resultado de la gestin de tele-cobranza
personalizada.
12
Actualizar Informacin de Resultado de Gestin

a. Se ordena la informacin por el nmero de documento.
b. Se realiza el cruce de informacin entre el archivo enviado al proveedor y el
archivo recibido que contiene el resultado de la gestin, con la finalidad de
actualizar el cdigo de tipificacin de la gestin de tele-cobranza hacia los
documentos de la Base Final a Gestionar.
Ejemplo de tipificaciones del resultado de la gestin de tele-cobranza
01001 Contacto con titular
01002 Contacto con familiar / otros
01003 Indica que pag
01004 Indica tener reclamo
01005 Indica haber refinanciado
01006 Promesa de pago
01007 Volver a llamar
Tabla 1 Descripcin del proceso actual de la Gestin de cobranza
- 22 -

En el siguiente cuadro se puede apreciar el tiempo total que se emplea para

generar la informacin haciendo uso de hojas de clculo.
2, 250 recibos procesados
tem
Tarea
1
2
3
4
5
6
Captura de documentos vencidos y pendientes.

Excluir los documentos de larga distancia.
Ordenar informacin por documento.
Excluir los documentos virtuales.
Cruzar informacin con reclamos para excluir documentos.
Ordenar informacin por cliente.
Cruzar informacin con la segmentacin de clientes para
excluir documentos de clientes con segmentacin
7 corporativo.
8 Ordenar informacin por negocio.
Cruzar informacin con datos de clientes para obtener anis y
9 contacto del cliente.
Tiempo
(minutos)
25
5
1
2
7
1
10 Se complementa con la informacin del negocio encontrada

11 Guardar archivo base para la gestin.
Preparar la informacin que est en el archivo base de
12 acuerdo a una estructura especfica.
13 Envo del archivo generado.
15 Recepcin del archivo de resultado de la gestin.
15 Ordenar informacin por documento.
Cruzar informacin con archivo de resultado de la gestin
16 para actualizar el cdigo de tipificacin de la gestin.
TOTAL
20
1
15
15
1
50
2
1
1
35
182
Figura 7 El tiempo aproximado en que demora es de 3 horas
a) Situacin Problemtica
Frente al proceso actual de gestin de cobranza en la etapa de tele-cobranza
personalizada se identifican las siguientes problemticas:
SITUACIN PROBLEMTICA
El
tiempo
para
obtener
PROBLEMA A RESOLVER
los La informacin est registrada en
documentos a gestionar es extenso
diferentes hojas de clculo, las cuales
y con una alta probabilidad de error,
son
que
reas de la empresa y/o proveedores.
ocupa
recursos,
tiempo
proporcionadas
por
diversas
costos.
Conocimiento tardo de la situacin Carencia
de
funcionalidades
de los documentos que podran
consoliden,
originar la suspensin de la gestin
informacin dinmica para que pueda
- 23 -
procesen
que
muestren

de cobranza, ocasionando malestar
generar las funciones de alertas,
y quejas en los clientes.
control y seguimiento de la gestin de

cobranza.
Generacin manual del archivo que El mtodo manual utilizado para

se
enva
al
proveedor
quien
generar un archivo con estructura
realizar la etapa de tele-cobranza
especfica no es apropiado para la
personalizada.
eficiencia
del
proceso,
pudiendo
ocasionar errores los cuales pueden

ser resueltos con la automatizacin.
La obtencin y actualizacin del El
resultado
de la etapa de tele-
empleo
de
herramientas
administrativas manuales durante un
cobranza personalizada se procesa
proceso
de
actualizacin
y guarda en hojas de clculo.
brindan seguridad y eficiencia.
masivo
Se desconoce oportunamente el No se dispone de informacin en

resultado de la gestin de cobranza
lnea integrada oportunamente, que
en cada etapa para la toma de
permita elaborar consultas en tiempo
decisiones.
real.
Tabla 2 Situacin Problema del proceso actual de la Gestin de Cobranza
b) Oportunidades de mejora
Para el manejo de la gestin de cobranza en sus diferentes etapas se propone la

automatizacin
de
los
procesos
que
permiten
la
carga,
generacin,
almacenamiento y consulta de la informacin con la gestin realizada en cada

documento.
1. As como para la etapa de tele-cobranza en las dems etapas se validarn

tres condiciones las cuales excluyen la gestin de los documentos:
a. Evaluacin de la deuda pendiente: Mediante un proceso que consulte el
saldo por cobrar del documento se puede conocer si an sigue pendiente.
- 24 -

b. Evaluacin de reclamos registrados: Para poder considerar los reclamos

registrados se realizar un proceso que cargue los reclamos y modifique la
situacin de gestin del documento.
c. Evaluacin de la segmentacin del cliente: Para los clientes que estn
catalogados como corporativos se realizar un proceso de consulta que
permita excluir sus documentos de la gestin de cobranza.
2. La generacin del archivo que se enva al proveedor quien realiza la gestin

de tele-cobranza ser realizada a travs de un proceso automtico el cual
utilizar las consultas propuestas anteriormente:
a. Seleccionar y filtrar la informacin de los documentos correspondientes a

un ciclo y producto indicado; excluir los documentos cancelados,
documentos con situacin de gestin en reclamo y los documentos cuyos
clientes sean corporativos.
b. Los registros obtenidos sern adaptados a la estructura especfica del
archivo.
c. Se actualizar los datos de inicio de la gestin de tele-cobranza (fecha,
hora, usuario y etapa de gestin actual) por cada documento.
3. Para recibir el archivo de resultado de la gestin se crear un proceso de

carga que permita leer la informacin que enva el proveedor:
a. Validar cada lnea del archivo (documento y cdigo de tipificacin)

b. Actualizar la informacin (cdigo de tipificacin y fecha de ejecucin) del
resultado de la gestin de tele-cobranza por cada documento.
c. Generacin de archivo de errores en caso de encontrar alguna
inconsistencia.
4.
Para conocer el estado de cada documento durante la gestin se crear una

consulta en lnea.
- 25 -

1.3 Prototipo del proceso en BPM Studio
Figura 8 Proceso Gestin de Cobranza
Figura 9 Subproceso de la Generacin de las Etapas de Cobranza
Figura 10 Evento de cancelacin de gestin de cobranza

- 26 -

Figura 11 Subproceso de la Gestin de Cobranza para la Etapa de Telecobranza Personalizada
- 27 -

1.4 Indicadores de desempeo
INDICADOR 1 Porcentaje de recuperacin de recibos

OBJETIVO
Evaluar el costo beneficio
METAS
Incrementar en 10% con respecto al ao anterior

(15%)
Expresin
matemtica:
(CRCxG / CRExG) * 100

Dnde:
CRCxG = Cantidad de Recibos Cancelados durante la
gestin
CRExG = Cantidad de Recibos Enviados en la
gestin
Tabla 3 Indicador de Desempeo 1
INDICADOR 2 Recuperacin neta en soles
META/S
Reducir el costo de la gestin en comparacin del

importe de los documentos cancelados durante la
gestin.
Costo de gestin sea <=15% del importe de los
documentos cancelados durante la gestin.
Expresin
matemtica:
TRCxG CTxG
OBJETIVO
CTxG = CF * DT * HxD * PxD

Dnde:
TRCxG = Total Recibos Cancelados x Gestin
CTxG = Costo Total x Gestin
CF = Costo Fijo
DT = Das Trabajados
HxD = Horas por Da
PxD = Posiciones por Da
- 28 -

INDICADOR 3 % Documentos no gestionados por reclamos

OBJETIVO
Conocer el porcentaje de documentos no gestionados

debido a un reclamo registrado.
< al 10% respecto al ao anterior (15%)
METAS
Expresin
matemtica:
(CRxG / CRxGR) * 100

Dnde:
CRxG = Cantidad de Recibos por Gestin
CRxGR = Cantidad de Recibos por Gestionar en
Reclamo
- 29 -

CONCLUSIONES
1. Visualizacin clara y simple de las actividades del proceso a mejorar y

automatizar, con la ayuda del BPM se podr tener un mapa claro del proceso
real de la gestin en la etapa de tele-cobranza, as como las reas y
proveedores externos involucradas en el proceso.
2. Optimizacin de tiempo en el procesamiento de informacin para el rea de

cobranza; para gestionar la etapa de tele-cobranza se requiere trabajar con
gran cantidad de informacin de diferentes fuentes la cual al ser procesada
automticamente disminuye en gran medida el tiempo de ejecucin y los
errores del proceso.
3. Al contar con un proceso automtico de seleccin que maneje exclusiones

segn las reglas del negocio definidas reduce el riesgo de contar con errores
en la obtencin de la informacin a procesar.
4. Se obtiene un valor agregado de manera notable en los procesos de

evaluacin de la gestin de cobranza. Actualmente la empresa distribuye la
informacin de la gestin con quince das de desfase, razn por la cual los
resultados de la evaluacin no son obtenidos de manera oportuna.
- 30 -

CAPITULO 2
CMMI
- 31 -

INTRODUCCIN
El vertiginoso cambio tecnolgico en que vivimos, tiene un trascendente impacto

en la industria y la comunidad en general a causa de la incesante produccin de
innovadoras herramientas que dan origen a nuevas y ms sofisticadas soluciones
de negocio que brindan la diferenciacin y ventaja competitiva de los negocios
que las implementan; ello produce un efecto domin para innovarse manteniendo
lneas de negocio atractivas que fomenten la retencin o incremento de su cartera
de clientes, evitando reducirse hasta desaparecer.
Al comps de dicha innovacin tecnolgica, la sociedad en general se ha

percatado que es necesario contar con profesionales mejor preparados, y
premunidos de metodologas y buenas prcticas que les permitan la integracin
de los procesos y actividades de los negocios, mitigando errores, mejorando la
atencin del core del negocio, produciendo informacin de valor orientada al
cliente, y estratgica para la toma de decisiones oportunas por los puestos de
gestin.
En tales escenarios de competitividad, el modelo CMMI (Capability Maturity Model

Integrated) compendia una serie de disciplinas y mtodos que conllevan a
transformar el funcionamiento de las organizaciones y sus recursos para asegurar
una transformacin gradual por niveles para producir productos de servicios de
calidad, que se logran aplicando una vasta gama de buenas prcticas generales y
especficas.
En tal sentido, el presente trabajo aplica el modelo de CMMI para la mejora de

procesos del Grupo SYPSA SAC, la cual presenta carencias en la definicin de
procesos para gestin de proyectos, desarrollo de software, y otras reas de
proceso. Por ello, el presente trabajo est organizado como sigue: Descripcin de
la Organizacin objeto de estudio; Definicin del alcance de la evaluacin;
Factibilidad del cambio; Evaluacin de la situacin actual; Y finalmente, se
describen los procesos propuestos para la mejora en las reas seleccionadas.
- 32 -

2.1 Objeto de estudio

a. Descripcin de la empresa objeto de estudio
GRUPO SYPSA SAC es una organizacin de profesionales, dedicada a proveer

soluciones y servicios de alta tecnologa a la pequea, mediana y gran empresa.
Con ms de 30 aos de experiencia, ofrecen una amplia gama de productos tanto
de hardware como de software de las marcas ms prestigiadas del mercado
informtico y diversos servicios de Tecnologa de la Informacin e Integracin de
Sistemas.
La compaa ha ido adquiriendo un completo conocimiento de los diversos

mercados e industrias a travs de los aos, con el fin de ofrecer soluciones y
servicios que agreguen valor a los clientes. El personal de sistemas cuenta en su
mayora con certificaciones de los principales fabricantes de tecnologa,
adquiridas a lo largo de su desarrollo profesional en las distintas empresas donde
laboraron.
Actualmente la empresa est integrada por profesionales de las diferentes reas

de la Tecnologa de la Informacin, habiendo expandido sus actividades a otros
pases tales como Mxico, Ecuador, Guatemala, Panam y Venezuela.
Grupo SYPSA SAC ha sido reconocido por la Corporacin de VMware como la

empresa de "Mayor crecimiento en ventas durante el ao 2009", mrito que fue
otorgado en el evento Kick off del 2010 por el Gerente de Preventas VMware. En
dicho nombramiento se destac el resultado obtenido por la empresa al haber
implementado en forma exitosa el primer proyecto del Per de una solucin de
virtualizacin de estaciones de trabajo (VDI) en una de las principales empresas
pesqueras del medio. En la actualidad contamos con el mayor nmero de
profesionales certificados del Per en VMware Versin 4.
Grupo SYPSA SAC, ha mantenido durante muchos aos una larga y exitosa
relacin de negocios con IBM del Per S.A., siendo certificada por ellos a nivel
- 33 -

internacional en la comercializacin de los Sistemas IBM iSeries, pSeries y

xSeries, logrando actualmente ser los Asociados de Negocios de IBM ms
antiguo del pas. (Primer Socio de Negocios de IBM del Per, desde 1984. Socio
categora PREMIER, la ms alta otorgada por IBM).
Empresa con amplia experiencia en proyectos de implementacin de ERP en el
Per, socio GOLDEN de SAP Andina y del Caribe; lder consecutivo durante los
ltimos 3 aos de SAP Business One.
Por tanto presentamos las alianzas estratgicas:
En soluciones de Infraestructura
Infraestructura de IBM del Per (Storage, Blades servidores Power).
Principales canales de ventas de Lenovo y DELL del Per.
Distribuidores de soluciones de Impresin de Lexmark.
En Soluciones de Software
Canal con mayor crecimiento de SAP
Distribuidor de licencias de Oracle, Tivoli.
Soluciones de Valor Agregado
Implementacin de soluciones de Alta Disponibilidad de VisionSolutions

Inc. y de DoubleTake.
Implementaciones de soluciones de virtualizacin de VMWare.
b. Misin
Brindar el mximo nivel de excelencia y satisfaccin en el valor agregado de las
soluciones,
productos
servicios
que
otorgamos
nuestros
clientes,
estableciendo como base una relacin de confianza y transparencia que nos

permita compartir su visin estratgica de negocios a mediano y largo plazo.
- 34 -

c. Visin
Ser la empresa lder en brindar y gestionar Servicios de Tecnologa de la
informacin de primer nivel en nuestro pas, contribuyendo con el desarrollo
nacional y la calidad profesional y tica de sus colaboradores.
d. Organigrama
Figura 12 Organigrama SYPSA SAC

Fuente SYPSA SAC
e. Objetivos del Negocio
Desarrollar programas con la finalidad y capacidad de resolver situaciones

reales a las empresas para su desarrollo, y evolucin tecnolgica para
atender sus necesidades y hacerlas mejores empresas en su campo laboral,
financiero, administrativo y econmico, adems de actualizarlos en el campo
computacional.
Consolidarse como el mejor servicio de Desarrollo de Software propietario.

Actualizacin
tecnolgica
de
los
productos
que
se
encuentran
ya
implementados en varios clientes, as como el incorporar una serie de nuevos

productos que permitan ampliar el portafolio del rea.
- 35 -

2.2 Alcance de la evaluacin

Grupo SYPSA SAC cuenta con un Departamento de Desarrollo Propietario, rea
que ser estudiada por el presente proyecto.
El Alcance se enfoca en el anlisis y propuesta de mejora para los procesos de
planeamiento (PP) y de la Gestin de Requerimientos (REQM) para nuevos
desarrollos en la empresa.
2.3 Factibilidad del cambio

a. Resea sobre antecedentes de cambios de procesos
En el ao 2009, la empresa tom la decisin de contratar los servicios de un

tercero para realizar una nueva versin del ERP, la misma que se basaba en un
cambio del look and feel de las pantallas.
Como parte de las tareas de este proyecto, el rea de desarrollo deba ser
instruida en el manejo de los nuevos controles utilizados con el objetivo de brindar
apoyo en la culminacin del proyecto y estar aptos para tomar el control del
mismo.
La empresa proporcion el cdigo fuente del ERP, este proyecto estuvo

planificado, organizado y controlado por el tercero, no se involucr al personal del
rea de desarrollo.
En el ao 2010, la empresa realiz el lanzamiento de la nueva versin invitando a

la base de clientes instalada, con lo cual se comprometieron a iniciar las
instalaciones en el primer trimestre del ao 2011.
Debido a que el proyecto no tuvo control ni se realiz seguimiento por parte del
personal de la empresa, al momento de involucrar a las personas del rea de
implementacin para un control de calidad, se encontraron una infinidad de
errores: proceso incompletos, procesos cambiados, desorganizacin, validaciones
faltantes y descontrol de las opciones con las que contaba el ERP; fue en ese
- 36 -

momento que se pudo conocer que el nivel de cambio de la nueva versin no

estaba slo en la forma (look and feel) sino tambin en la codificacin de los
procesos.
La nueva versin no pudo ser instalada en el tiempo ofrecido, teniendo que

reenviar cartas a los clientes para una prxima fecha. Enseguida se asegur la
capacitacin integral al personal de desarrollo de la empresa, luego se retir del
proyecto al tercero y la empresa tom el control del proyecto.
b. Probables focos de resistencia
No existe una definicin de funciones de cada puesto, lo cual ocasiona que

una responsabilidad es de todos y de nadie a la vez.
No se ha implementado una poltica para el rea de desarrollo concerniente a

creacin de nuevos productos; razn por la cual no se sabe de qu manera
coordinar las actividades en caso que algn proyecto haya sido desarrollado
por un tercero.
La organizacin exige que el costo de un proyecto sea ms importante que el

tiempo necesario para generar un producto organizado, controlado y
documentado.
Los programadores no tienen documentan sus labores o tareas que

desarrollan diariamente.
Dentro de la organizacin no existe un grupo de personas dedicadas a

realizar las pruebas (testing), el nivel del control de calidad est basado en
dos momentos: las pruebas del programador y las pruebas que pueda realizar
el cliente o el consultor de la empresa asignado al cliente.
Los clientes estn acostumbrados a enviar sus requerimientos de diversas

formas, no se le ha solicitado manejar formatos ni asignar a una persona para
comunicar los requerimientos.
La empresa no ha definido las herramientas, mecanismos o formatos

especficos para utilizarlos en la diagramacin de procesos.
- 37 -

Un programador o el rea de programacin no cuenta con informacin de los

procesos a nivel funcional, que permitan realizar modificaciones al sistema
logrando un entendimiento previo del proceso.
c. Procesos, mecanismos, mtodos, prcticas actuales.
Registro de modificaciones de los programas; actualmente se maneja un

procedimiento definido para realizar y registrar modificaciones en los
programas que sufren cambios.
Distribucin de cambios; se ha definido un procedimiento para controlar e

instalar los cambios realizados en el ERP hacia los clientes.
Registro de incidencias; se cuenta con una herramienta para ingresar las

incidencias del ERP reportadas por los consultores o clientes.
d. Problemas u oportunidades de mejora conocidos.
Proceso para planificar proyectos de desarrollo.
Proceso para gestionar los requerimientos.
Proceso para realizar las pruebas de control de calidad.
No se cuenta con una metodologa formalizada para el desarrollo de los

sistemas.
No se ha definido un procedimiento formal para la gestin de cambio en los

sistemas.
No se cuenta con un esquema definido para realizar las pruebas funcionales e

integrales necesarias para poner en produccin un desarrollo.
Existen algunos requisitos implcitos o expectativas que a menudo no se

mencionan, o se mencionan de forma incompleta.
No se cuenta con un ambiente dedicado para la realizacin de las pruebas

funcionales e integrales.
No se cuenta con procedimientos para proteger y controlar los datos de

pruebas.
Las mtricas del proceso de desarrollo son determinados mediante

estadsticas basadas en la experiencia.
- 38 -

e. Factores clave de xito actuales.
Obtener el apoyo de la Gerencia General para lograr inicialmente algn nivel

de certificacin.
Lograr institucionalizar en la empresa que el tiempo para cubrir fases de un

proyecto es necesario e importante, ya que de no ser as podra convertirse
en serios problemas de expansin del proyecto.
Entrenamiento apropiado del conocimiento y actualizaciones regulares de

polticas y procedimientos organizacionales a todos los empleados de la
organizacin, contratistas y usuarios de terceros como sea relevante para la
funcin de su trabajo.
Formalizar un Manual de Organizacin y Funciones (MOF) para la empresa.
Asignacin especfica y firme de los recursos incluidos en el plan (humanos,

econmicos, etc.)
Implementar una estrategia que homologue los niveles de informacin en toda

la organizacin, involucrando a los todos stakeholders y tomando activamente
la retroalimentacin de las personas que han interactuado en el desarrollo de
los sistemas a fin de explicar la visin futura y eliminar temores.
2.4 Evaluacin de la situacin actual

a. Descripcin de las fuentes de informacin utilizadas:
Se realizaron diversas entrevistas y encuestas con el objetivo de conocer ms
a fondo la forma de trabajo del rea de desarrollo del Grupo Sypsa S.A. y la
documentacin actual con las que cuentan para iniciar sus proyectos de
implementacin.
Los roles de las personas entrevistadas fueron:
Gerente de Desarrollo y Proyectos
Jefes de Desarrollo.
Analistas programadores.
Algunos usuarios de la empresa.
A las personas entrevistadas se les solicitaron contestar con respuestas

afirmativas o negativas sustentadas en algunos casos de atencin en la
- 39 -

empresa. Estas respuestas nos permitirn evaluar el cumplimiento y

aplicacin de las prcticas especficas y genricas establecidas por CMMi en
las reas de planificacin de proyectos y gestin de requerimientos.
b. Evaluacin de cumplimiento de las prcticas especficas y genricas de

las siguientes reas de proceso:
i.
Project Planning (PP)
PP
SG 1
Preguntas
Establecer estimaciones
SP 1.1
Est descrito en algn lugar cul es el

alcance del proyecto en alto nivel,
considerando que cubra todo lo que se
tiene que hacer?
Se calcula el tamao de los productos?
No
Se puede conocer cul fue el tamao de

los proyectos anteriores?
Si
Existe alguna definicin que seale cules

son los ciclos de vida posibles?
Si
Esta definicin es conocida, y se utiliza

para planificar el proyecto?
Se calcula el estimado utilizando algn
procedimiento adems del juicio de
experto?
Se toma en cuenta la informacin
histrica?
No
Se conoce bajo qu supuestos se estim?
No
SP 1.2
SP 1.3
SP 1.4
SG 2
SP 2.1
SP 2.2
Si/No
Desarrollar un plan de proyecto

Se tiene el presupuesto del proyecto?
Se prepar en base al estimado,
incluyendo otros costos no asociados al
esfuerzo (alquiler de equipos, licencias,
etc.)?
Si
Se calcula el tamao al culminar la

evaluacin del producto que se requiere.
La
informacin
se
puede
obtener
consultando con las personas encargadas
del requerimiento.
Dentro del cronograma utilizado se
establece etapas como: levantamiento de
informacin, aprobacin de requerimientos,
diseo de programas, aprobacin de
diseo, programacin, pruebas con usuario,
depuracin, entrega.
No siempre se utiliza.
No
No
Se considera la experiencia de proyectos

anteriores, pero no existe informacin
escrita.
No
Se tiene un cronograma elaborado en

base al esfuerzo?
No
Contiene todas las actividades del

proyecto?
Se conocen los hitos, dependencias, y los
recursos asignados?
No
Se identifican y analizan los riesgos?
No
- 40 -
Comentario
Si
El cronograma se construye considerando

las horas de cada una de las tareas a
realizar.
Hay algunas actividades que a ese nivel no
son incluidas.
Se establecen hitos; las actividades se
ordenan considerando que algunas son pre
requisito de otras; los recursos son
asignados en el cronograma.
Hay algunos riesgos que estn relacionados
a los recursos asignados al proyecto los
cuales se cubren incrementando el tiempo
de las actividades relacionadas, y otros

riesgos que estn en el lado del cliente los

cuales no son contemplados.
Se encuentran documentados en algn
lugar?
Existe un plan de datos del proyecto?
No
Se sabe qu informacin
recolectar y cul generar?
debe
Si
Se establecen los niveles de acceso?

Se tienen niveles de control de cambio (ej.
Versiones) para los entregables que lo
requieran?
Si
Si
Se determinan los recursos humanos,

equipamiento,
etc.,
necesarios
del
proyecto?
Si
Dnde se documenta?
No
SP 2.5
Se identifican las necesidades de

capacitacin de los recursos humanos del
proyecto? Cmo?
En dnde se
planifican las acciones de capacitacin
necesarias?
No
SP 2.6
Se identifican los stakeholders relevantes

de todas las fases del proyecto? Cmo se
sabe cules son? Dnde se registra el
resultado de la planificacin?
Se tiene un plan documentado?
Si
SP 2.3
SP 2.4
SP 2.7
SG 3
SP 3.1
SP 3.2
se
Obtener el compromiso con el Plan

Se identifican otros planes de los que
depende el proyecto? Dnde se
documentan para su posterior seguimiento?
Se reconcilia el plan de proyecto con los
recursos realmente asignados? Qu
sucede si no se cuenta con los recursos
estimados? El plan se modifica para
acomodarse a la disponibilidad de los
recursos?
SP 3.3
Se obtiene el compromiso de los

miembros del proyecto, con el plan?
Cmo?
GG 1
GP 1.1
Lograr metas especificas

Realizar las prcticas especficas
GG 2
GP 2.1
Institucionalizar un proceso gestionado

Existe una poltica que indique cmo se
debe realizar la planificacin del proyecto?
Las personas que realizan la planificacin
- 41 -
Si
Cada lder del proyecto establece como

administrar la informacin que se genera del
proyecto.
Se construye un file con los documentos
que se reciben durante el levantamiento de
informacin; de igual forma coordina con
cada programador el resguardo de los
programas que se estn generando, a
travs de backup semanales.
Slo hay una directiva que para elaborar
cambios en los programas o interfaces se
debe guardar antes un backup de lo
anterior.
Los recursos necesarios para el proyecto
son considerados antes de iniciar el
proyecto inclusive el equipamiento en la
locacin del cliente.
El recurso slo est incluido en el
cronograma.
El equipamiento se solicita a travs de
correo.
Como parte de la propuesta se incluye un

organigrama del proyecto donde se indican
los cargos y lderes de cada rea que
estarn involucrados con el proyecto.
No
No
Se identificar actividades preliminares pero

no son documentadas.
No
El plan de proyecto no se modifica a menos

que el cliente decida suspender por algn
motivo el proyecto.
Si
Si no hay disponibilidad de recursos se

maneja haciendo uso del tiempo adicional
incluido en el cronograma, pero si este
excediera se cubre el retraso con horas de
trabajo adicionales.
Antes de iniciar el proyecto se lleva a cabo
una reunin (kick off) con los integrantes del
proyecto, en el que se presenta las metas y
objetivos
del
proyecto,
lineamientos
generales, roles, etc.
No
No se cumplen en su totalidad.
No
No se realiza actividades para hacer la

planificacin.

GP 2.2
GP 2.3
GP 2.4
GP 2.5
GP 2.6
GP 2.7
GP 2.8
GP 2.9
GP
2.10
conocen esta poltica? La utilizan?

Las actividades que se realizan durante el
plan, se encuentran planificadas?
Se asignan recursos para la planificacin?
(plantillas, software, etc.)
Est establecido qu roles estn
involucrados en el planeamiento del
proyecto, y est documentado quines
desempean estos roles?
Los roles involucrados en el proceso de
planeamiento, han recibido entrenamiento
en el proceso establecido?
Se utilizan mecanismos de control
(versionado, control de cambios, etc.), a los
entregables
producidos
durante
el
planeamiento?
Se conoce a quienes se debe involucrar
en el planeamiento del proyecto?
Se utilizan indicadores para controlar el
proceso de planeamiento?
Se revisa la adherencia de las actividades
de planificacin ejecutadas versus el
proceso establecido en la poltica?
Se entera la Gerencia del progreso y
resultados de la planificacin de los
proyectos?
No
No
No
El planeamiento es realizado por una sola

persona.
No
La persona encargada del planeamiento

utiliza juicio de experto.
No
No
No
No
Si
El medio de comunicacin es a travs de

las reuniones en las que asiste el jefe del
rea e informa sobre el desarrollo de las
actividades y los proyectos nuevos que van
a iniciar.
Tabla 6 Evaluacin de Cumplimiento para el rea de proceso PP
ii.
Project Monitoring and Control (PMC)
PCM
Preguntas
Si/No Comentario
SG 1
Monitorizar el proyecto frente al plan
SP 1.1 Se hace seguimiento al avance del
Si
Se lleva el control del cronograma
cronograma, considerando avance esperado
considerando el tiempo ofrecido.
vs real?
Se hace seguimiento al costo y esfuerzo del No
proyecto, considerando los valores esperados
vs reales?
Cundo existen desviaciones se toman
Si
En caso de haber una desviacin se
decisiones?
adiciona horas de trabajo para cubrir en lo
posible lo ofrecido.
Se documenta el resultado del seguimiento?
No
SP 1.2 Se hace seguimiento a los compromisos del
Si
A travs de definiciones de hitos se
proyecto? (considerar aquellos internos y
involucra a los lderes de cada rea
externos)
correspondiente para la revisin del
desarrollo concerniente en el hito.
SP 1.3 Se realiza seguimiento a los riesgos No
identificados? Se deja evidencia del
seguimiento, acciones realizadas y estado de
los riesgos en el tiempo?
SP 1.4 Se verifica que se estn produciendo los
Si
Como parte de la documentacin del hito se
entregables acordados?
adjunta una hoja de evaluacin para que el
cliente indique sus observaciones y/o
conformidad de la entrega.
- 42 -

Se verifica que los entregables de entrada

estn siendo recibidos?
Si
Se verifica el cumplimiento de las reglas de

resguardo (niveles de acceso, backup)?
No
Se toma accin cuando no se cumple lo

establecido?
No
SP 1.5 Se hace seguimiento a la participacin de los

stakeholders identificados?
Si
SP 1.6 Se realizan revisiones de progreso del

proyecto peridicamente?
Si
El equipo de proyecto conoce el estado del

proyecto?
No
SP 1.7 Se tienen reuniones formales con el cliente y

otros stakeholders relevantes para revisar el
estado del proyecto en hitos predeterminados?
Se documenta el resultado?
Si
SG 2
Gestionar las acciones correctivas hasta su cierre
SP 2.1 Se registran los problemas del proyecto?
Si
Se registran las acciones correctivas,
Si
indicando responsables, fechas, etc.?
SP 2.2 Se hace seguimiento a las acciones
correctivas establecidas? Se conoce cules
son?
SP 2.3 El jefe de proyecto se asegura que las
acciones correctivas se lleven a cabo? Se
actualiza el estado de las acciones correctivas
y
problemas?
Se puede conocer cul es la lista de
problemas pendientes de solucionar del
proyecto?
GG 1 Lograr metas especificas
GP
1.1
GP
Existe una poltica que indique cmo se debe
2.1
realizar el control del proyecto?
Si
No
Se reitera la directiva verbalmente o a

travs de correo, indicando la importancia
que tiene.
Algunas tareas como pruebas, carga de
informacin, etc. que figuran en el
cronograma tienen una responsabilidad
definida a nivel de rea o empresa.
Hay reuniones que se desarrollan en el
rea de desarrollo donde se exponen los
proyectos en curso, posibles problemas o
inconvenientes.
A las reuniones de control de avance de
proyecto asisten los lderes del proyecto
mas no todo el equipo.
Las revisiones son a travs de los hitos,
que en caso resulte disconforme se
convoca a reuniones con las partes
involucradas de las cuales se generan
actas de reunin cuyo detalle indica los
puntos en disconformidad, fechas de
resolucin, responsables y nueva revisin.
A travs de las actas de reunin.

Dentro del esquema del acta de reunin
existe un acpite que indica acciones
correctivas.
Se establece reuniones para revisar los
puntos pendientes y/o acciones correctivas
comprometidas.
El lder o jefe del proyecto es el encargado
de hacer seguimiento a lo que est
pendiente, pero no existe un documento
tabulado donde se registre los problemas y
el estado de cada uno.
No
No se cumplen todas las prcticas.
No
Las formas de controlar un proyecto son

diferentes an siendo del mismo tipo
(nuevo desarrollo)
En casi un 70% se utiliza una misma forma
de realizar algn control, pero depende
mucho de la negociacin del tiempo del
proyecto en que esta vare.
Dentro del cronograma se definen hitos,
alguno de ellos estn relacionados al
control del desarrollo.
En algunas ocasiones no se asigna el
recurso idneo lo cual es trascendente por
el conocimiento y experiencia que se
requiere.
Las personas que realizan el control conocen

esta poltica y la utilizan?
No
GP
2.2
Las actividades que forman parte del control,

se encuentran planificadas?
Si
GP
2.3
Se asignan recursos adecuados para realizar

las actividades de control del proyecto?
(plantillas, software, etc.)
No
- 43 -
Despus que el cliente revisa la

documentacin del hito, alimenta la hoja de
evaluacin y luego la enva; esta hoja es
recibida como muestra de conformidad o
disconformidad y se utiliza para llevar a
cabo una revisin si fuera el caso.
La mayora de veces si, pero ha ocurrido en
ocasiones que las directivas dadas para el
resguardo de la informacin no se ha dado.

GP
2.4
Est establecido qu roles estn involucrados

en el control del proyecto? Est documentado
quines desempean estos roles?
No
GP
2.5

control de proyecto han recibido entrenamiento
en el proceso establecido?
No
GP
2.6
Si
GP
2.7
Se
utilizan
mecanismos
de
control
(versionado, control de cambios, etc.), en los
entregables producidos o utilizados durante el
control del proyecto?
Se conoce a quienes se debe involucrar en el
control del proyecto?
GP
2.8
Se utilizan indicadores para

progreso del proyecto?
el control del
No
GP
2.9
Se revisa la adherencia de las actividades de

control de proyecto ejecutadas versus el
No
GP
2.10

resultados del proyecto?
Si
Si
No est especificado. Las personas

involucradas en el mantenimiento y control
de los proyectos estn definidas pero
dependiendo de la carga laboral el rol
puede ser llevado por diferentes personas.
En algunas ocasiones hay capacitacin al
personal que se encargar de brindar el
soporte pero no es siempre.
Existe un procedimiento establecido para el
control de los cambios realizados en los
proyectos, el cual involucra el registro de
las modificaciones y versiones.
Si las actividades de control estn incluidas
en el cronograma cada una de ellas tiene
asignado un responsable.
Cada
actividad
establecida
en
el
cronograma detallado maneja diferentes
situaciones que permiten identificar en que
proceso se encuentra (por definir, iniciada,
en proceso, etc.) pero no hay vinculacin
con lo establecido.
Se realizan reuniones peridicas en las que
se informa el estado de los proyectos.
Tabla 7 Evaluacin de Cumplimiento para el rea de proceso PMC
iii.
Requirements Management (REQM)
REQM
SG 1
SP 1.1
Preguntas
Si/No Comentario
Obtener una comprensin de los requerimientos
Existen
criterios
para
aceptar No
requerimientos? (ejemplo de criterios: plantilla
para recibirlos, fuentes autorizadas de
requerimientos, trminos a evitar, etc.)
Se revisan y aprueban los requerimientos?
Si
Los requerimientos se revisan y son
plasmados en un modelo conceptual para su
aprobacin.
Se mantiene una lista con los requerimientos
Si
Se manejan los requerimientos dentro del
autorizados?
cronograma detallado.
SP 1.2
Existe algn mecanismo que permita obtener

el compromiso de los desarrolladores y testers
con los requerimientos?
Si
Este mecanismo se ejecuta en la prctica?
No
Se registran los cambios a la lista acordada

de requerimientos?
Si
Se evala el impacto? Por todos los

posibles
afectados?
(desarrolladores,
analistas, testers)
Se registra el impacto?
Se hace seguimiento a la aplicacin del
cambio? (Se conoce la lista de cambios
pendientes de implementar?
No
SP 1.3
- 44 -
No
No
Se lleva a cabo una reunin para comunicar

las especificaciones del proyecto (objetivo,
requerimientos,
fases,
responsabilidades,
tiempo)
Se ejecuta cuando los proyectos son medianos
o grandes.
Las modificaciones se detallan la lista inicial de
requerimientos, la cual se nombra como una
versin 2.
La evaluacin del impacto utiliza juicio de
experto, que en ocasiones no satisface lo
necesario.

SP 1.4
Se puede relacionar los requerimientos como

los planes, especificaciones funcionales, casos
de prueba y cambios al cdigo fuente?
No
SP 1.5
Se tienen actividades que permitan asegurar

que los cambios aceptados estn siendo
considerados en el plan?
Si
GG 1
GP 1.1
GP 2.1
Lograr metas especificas

Existe una poltica que indique cmo se debe
realizar la gestin de los requerimientos?
No
No
Actualmente estas relaciones no estn

documentadas.
Se trabajan plantillas similares a las Caso de
uso de sistema pero plantearemos una
optimizacin de la plantilla.
Los cambios aceptados dentro del proyecto
son certificados por el cliente, a travs de los
hitos de entrega, Cronograma de Proyecto
visualiza hitos de atencin de requerimientos
programados.
Se consideran en el Acta de Constitucin del
Proyecto
No se cumplen todas las prcticas.

No hay una poltica establecida, pero existen
algunos lineamientos que son de conocimiento
de las personas que tienen la responsabilidad
del desarrollo.
Como directiva se cumple con las actividades
que se desarrollan en el levantamiento de
informacin. Se publican en el Boletn
Institucional.
Dentro del cronograma hay una actividad que
se denomina levantamiento de informacin y
aprobacin de requerimientos. Priorizamos
requerimientos en el Cronograma del Proyecto,
siendo supervisado por el Gerente del
Proyecto.
Las personas que realizan la gestin de

requerimientos conocen esta poltica y la
cumplen?
Si
GP 2.2
Las actividades de gestin de requerimientos,

se encuentran planificadas?
Si
GP 2.3
Cules son los recursos que se utilizan para

la gestin de requerimientos? Son adecuados
y suficientes? Los utilizan?
No
GP 2.4
Est establecido qu roles estn involucrados

en la gestin de requerimientos? Est
documentado quines desempean estos
roles?
gestin de requerimientos, han recibido
entrenamiento en el proceso establecido?
Si
Se definen las personas que cumplirn el rol

de analista los cuales sern responsables de
esta actividad dentro del cronograma.
No
Vamos a considerar el registro tanto en el Acta

de Proyecto como en la Poltica de Gestin de
Requerimientos. Se va a crear una Plantilla de
Roles.
Solo a travs de los nombres de los archivos
que contienen los requerimientos.
GP 2.5
GP 2.6
Se
utilizan
mecanismos
de
control
(versionado, control de cambios, etc.), a los
entregables producidos durante la gestin de
requerimientos?
Si
GP 2.7
Se conoce a quienes se debe involucrar en

las actividades de gestin de requerimientos?
No
GP 2.8
Se utilizan indicadores para controlar la

gestin de los requerimientos?
Si
GP 2.9
Se revisa la adherencia de las actividades de

gestin de requerimientos ejecutadas versus el
No
GP
2.10

resultados de las actividades de la gestin de
requerimientos?
Si
Se realiza por manejo de Versiones, pero por

cada
cierto
nmero
o
conjunto
de
requerimientos solicitados y entregados.
Las personas encargadas de gestionar los
requerimientos conocen su responsabilidad,
pero esta informacin no est distribuida en la
organizacin.
Se realizan encuestas de satisfaccin sobre
avance del diseo entregado al cliente.
Reuniones de Comit con Jefe de Proyecto y

revisin del Cronograma de Proyecto
Tabla 8 Evaluacin de Cumplimiento para el rea de proceso REQM

- 45 -

c. Presentacin de resultados
Por cada rea de proceso, porcentaje de prcticas cumplidas y no
cumplidas
Cumplidas y No cumplidas
rea de proceso: PP
100%
80%
60%
40%
20%
0%
No
Total
80%
Si
20%
Figura 13 Prcticas cumplidas y no cumplidas para Planeamiento de Proyectos
rea de proceso: PCM
i.
100%
80%
60%
40%
20%
0%
No
Total
57%
Si
43%
Figura 14 Practicas cumplidas y no cumplidas para Monitoreo y Control de Proyectos
- 46 -

rea de proceso: REQM
100%
80%
60%
40%
20%
0%
No
Total
48%
Si
52%
Figura 15 Prcticas cumplidas y no cumplidas para Gestin de Requerimiento
ii. Porcentaje total de prcticas cumplidas y no cumplidas
Total de Practicas cumplidas y no cumplidas en las

tres reas de proceso (PP, PMP y REQM)
100%
80%
60%
40%
20%
0%
No
Total
57%
Si
43%
Figura 16 Total de prcticas cumplidas y no cumplidas para las tres reas de procesos
- 47 -

2.5 Procesos propuestos.

a. Proceso de Project Planning (PP)
a.1. Definicin del Proceso
Figura 17 Proceso para el Planeamiento de Proyectos (PP)
- 48 -

a.2. Descripcin del Proceso

Proceso
Planeamiento de Proyectos
Propsito
Establecer y mantener los planes que definan las actividades de un proyecto.
Objetivos
Desarrollar el plan del proyecto

Interactuar con las partes involucradas
Mantener el plan del proyecto
Inicio
El proceso inciia con la recepcin del proyecto que enva el rea de ventas
Fin
Como resultado del proceso se obtiene el plan del proyecto
Responsable Gerente de Consultara

Tabla 9 Descripcin del proceso propuesto para el rea de proceso PP
Roles y conocimientos esperados

Rol y Abreviacin
rea de
Ventas
Conocimientos
Habilidad para establecer relaciones interpersonales, proactividad,

capacidad de negociacin y liderazgo.
Encargado de coordinar con el cliente la mejor solucin para
implementar nuevos desarrollos.
GC Muchas veces es un representante del cliente y debe determinar e
implementar la satisfaccin y atencin de las necesidades e
inquietudes exactas del cliente, basndose en su conocimiento de
la firma que representa en el grado de calidad esperado.
AV
Gerencia
de
Consultora
Tabla 10 Roles y conocimientos esperados para el rea de proceso PP
Actividades
Planeamiento de Proyectos
Cod.
AP 1.1
AP1. Entregar proyecto

Prctica Rol
Tarea
AV El AV entrega el proyecto a la GC.
AP2. Recibir proyecto
AP 2.1
GC El GC recibe el proyecto del AV.

AP3. Evaluar y definir el alcance
AP 3.1
GC El GC realiza un anlisis del proyecto para definir su alcance.

AP4. Definir secuencia de actividades
AP 4.1
GC El GC define toda la secuencia de actividades a realizarse en el

planeamiento.
AP5. Preparar el WBS
- 49 -

AP 5.1
SP 1.1
GC El GC divide el proyecto en paquetes manejables que permitan

identificar el esfuerzo, las responsabilidades y el calendario del
proyecto.
AP6. Estimar el tamao del proyecto
AP 6.1
AP 6.2
SP 1.2
SP 1.4
GC El GC estima los puntos de funcin para calcular el tamao del
SP 1.3
GC El GC definir el ciclo de vida del proyecto.
proyecto.
AP7. Estimar el presupuesto del proyecto

AP 7.1
SP 2.1
GC El GC identifica los hitos principales, define un cronograma

calendarizado,
riesgos,
dependencia
de
tareas
el
presupuesto.
AP8. Identificar recursos, roles y responsabilidades del
proyecto
AP 8.1
GC El GC identifica a las personas involucradas y le asigna un

responsabilidad y rol dentro del proyecto.
AP9. Elaborar acta de constitucin del proyecto
AP 9.1
SP 2.6
GC El GC consolida la informacin del proyecto: objetivos, alcance,

fases, organigrama, y costos estimados; con la finalidad de crear
el acta de constitucin.
AP10. Identificar y evaluar riesgos del proyecto
AP 10.1
SP 2.2
GC El GC identifica y analiza los riesgos para determinar el impacto y

la probabilidad que ocurra, de esa manera brindar soporte a la
planificacin del proyecto.
AP11. Conciliar otros planes relacionados
AP 11.1
SP 3.1
SP 3.2
GC El GC verifica los planes de otras reas relacionadas al rea de

desarrollo, con las cuales el proyecto va intercambiar informacin
y compartir actividades, con el objetivo de integrar los planes de
trabajo.
AP12. Elaborar el plan de proyecto
AP 12.1
GC El GC se encarga de organizar y documentar la definicin de los

roles, responsabilidades, riesgos y planes relacionados al
proyecto.
AP13. Solicitar ambientes y equipo
AP 13.1
SP 2.4
GC El GC se encarga de solicitar los equipos, servidores, ambientes

de trabajo, accesos, etc. necesarios para el desarrollo del
proyecto.
AP14. Solicitar recursos humanos
- 50 -

AP 14.1
SP 2.4
GC El GC en funcin a la necesidad de recursos identificados para el

proyecto solicita al rea de recursos humanos los recursos en
caso de no contar con los requeridos.
AP15. Seleccionar y contratar
AP 15.1
GC RRHH se encargar de realizar los procedimientos para contratar

al personal solicitado para los proyectos en caso sea necesario.
AP16. Planificar capacitacin
AP 16.1
SP 2.5
GC Si el conocimiento del personal es insuficiente para efectos de

involucrarlos en el proyecto El GC organiza un plan de
capacitacin que abarque desde la bsqueda del instructor hasta
la construccin del syllabus de la capacitacin.
AP17. Actualizar plan de proyecto
AP 17.1
SP 3.2
GC El GC actualiza la informacin de los recursos, equipos y

ambientes asignados al proyecto y las actividades del plan de
capacitacin en caso de haberse realizado.
AP18. Informar estado del plan de proyecto
AP 18.1
GP 2.10
GC El GC comunica el plan del proyecto a la gerencia general a

travs de un correo.
AP19. Definir comit de proyectos
AP 19.1
GC El GC define los stakeholders internos y externos que estarn

involucrados en el proyecto y las responsabilidades de cada uno.
AP20. Preparar reunin kick off
AP 20.1
GC El GC prepara la presentacin que deber contener un resumen

del alcance del proyecto.
Tabla 11 Descripcin de las actividades propuestas para el rea de proceso PP
- 51 -

AP 1.1
AP 2.1
AP 3.1
AP 4.1
AP 5.1
AP 6.1
AP 6.2
AP 7.1
AP 8.1
AP 9.1
AP 10.1
AP 11.1
AP 12.1
AP 13.1
AP 14.1
AP 15.1
AP 16.1
AP 17.1
AP 18.1
AP 19.1
AP 20.1
SP 3.3
SP 3.2
SP 3.1
SP 2.7
SP 2.6
SP 2.5
SP 2.4
SP 2.3
SP 2.2
SP 2.1
SP 1.4
SP 1.3
Actividades
SP 1.2
Practicas
Especficas
SP 1.1
a.3. Matriz de Trazabilidad de las actividades vs. Practicas especficas de PP
X
X
X
X
X
X
X
X
X
Tabla 12 Matriz de trazabilidad de las actividades vs prcticas especficas de PP
- 52 -

b. Proceso de Requirements Management (REQM)
b.1. Definicin del Proceso
Figura 18 Proceso para la Gestin de requerimientos (REQM)
- 53 -

b.2. Descripcin del Proceso

Proceso
Gestin de Requerimientos
Propsito
Efectuar el anlisis de los requerimientos del Cliente.

Determinar el alcance de los requerimientos del Cliente.
Definir los requerimientos funcionales y los no funcionales.
Identificar los casos de uso, los actores y las relaciones entre estos.
Priorizar los casos de uso para un mejor avance en el proyecto.
Comprometer al equipo del proyecto con los requerimientos del sistema.
Preparar el documento de las Especificaciones Funcionales.
Descripcin
Este proceso es descrito por las siguientes actividades:

1. Se establece una reunin en la cual el cliente especifica sus requerimientos. En
caso no se realice, el cliente puede proporcionar un documento fsico o un
correo electrnico especificando los detalles pero ajustado al formato de
Solicitud de Requerimiento.
2. Este requerimiento es recibido por el equipo de gestin de requerimientos (Jefe
de Proyecto) quien revisa que la solicitud cuente con el detalle y las
especificaciones completas, segn formato, para realizar una adecuada revisin
con el objetivo de generar la propuesta adecuada.
Si el requerimiento no cumple con el formato establecido (Solicitud de
Requerimiento) se enva un mensaje al cliente solicitndole enviar la
informacin en el formato establecido.
3. En caso el requerimiento cuente con todo lo necesario se procede a enviar la
informacin al analista de sistema para que proceda con el anlisis
correspondiente.
4. Si la solicitud es: un nuevo requerimiento, entonces se procede a elaborar el
modelo conceptual que ser enviado al Jefe de Proyecto para su evaluacin. En
caso se encuentren algunas observaciones o documentos insuficientes para
poder realizar una propuesta se le informa al cliente la necesidad de mayor
detalle o ms informacin que d una mayor precisin del tema.
5. Si la solicitud es: una modificacin sobre un requerimiento, el analista procede
a evaluar los cambios, si se acepta la evaluacin se procede a verificar los
requisitos directamente afectados, luego se procede a generar la propuesta del
cambio y elaborar un informe de impacto el cual ser enviado al cliente, este
documento es registrado en una lista de cambios.
6. Si la propuesta de cambio no es aceptada se genera un informe de evaluacin y
se remite al Jefe de Proyecto para su envo al cliente.
7. El Jefe de Proyecto revisa la propuesta con los requerimientos y observa en
caso alguno de ellos sea ambiguo o no se entienda, en caso que las
- 54 -

observaciones no puedan ser resueltas por el equipo se convoca a reunin con

el cliente para poder cerrar las dudas que se tengan.
8. Una vez que el documento est sin observaciones y cumpla con todas las
requisitos del requerimiento, el Jefe de Proyecto enva el documento de
Atencin de Requerimiento al cliente para su validacin correspondiente y as
obtener la aprobacin del requerimiento para su pase al rea correspondiente.
9. Si el documento es observado por el cliente, este es enviado al equipo de
requerimiento para su evaluacin y correccin correspondiente. Una vez que se
han levantado todas las observaciones reportadas por el cliente se hacen los
ajustes necesarios para que el documento sea enviado nuevamente al Jefe de
Proyecto. Finalmente se entrega el documento de especificaciones funcionales
al cliente a fin de validar su entendimiento y lograr la aprobacin de este
documento el cual ser la base para el diseo de sistemas.
10. Una vez obtenida la aprobacin del cliente se procede a registrar el
requerimiento aprobado, luego se procede a elaborar el cronograma de
desarrollo del requerimiento (se elabora un cronograma detallado con todas la
actividades que se van a implementar y el cual ser utilizada por el Jefe de
Proyecto, el analista y los desarrolladores, adems de un cronograma resumido
para poder llevar un control por parte de la gerencia.).
Tambin se procede a generar un organigrama con informacin de los
integrantes que estarn a cargo de la implementacin del requerimiento, esta
informacin estar registrada en un acta de compromiso.
Objetivos
Optimizar la gestin de requerimientos en la empresa.
Lograr que los requerimientos de cliente sean claramente comprendidos para

tener en claro el alcance del mismo y general una propuesta ptima.
Desarrollar los requerimientos hasta un nivel de detalle que permita identificar

con facilidad los componentes del producto que permitir satisfacer las
necesidades del cliente.
Inicio
Fin
Inicio de un nuevo proyecto.
Contrastar los requerimientos del cliente con el detalle obtenido de los mismos.
Cuando el requerimiento es atendido. Esta gestin se da en cualquier parte del

proyecto general si el requerimiento forma parte de un proyecto.
Responsable
Jefe de Proyecto: Responsable de la gestin de los requerimientos. Evaluar el

documento de anlisis del equipo de desarrollo que resumen la comprensin de
la solicitud y que ser enviada al Cliente para su revisin y autorizacin.
Analista Funcional: Responsable de realizar el anlisis de los requerimientos

del Cliente y plasmarlos en los Casos de Uso.
Cliente: Quien solicita un requerimiento nuevo o la modificacin a un
- 55 -

requerimiento anterior.
Tabla 13 Descripcin del proceso propuesto para el rea de proceso REQM
Roles y conocimientos esperados

Rol y Abreviacin
Conocimientos
Cliente
Analista
Funcional
AF
Jefe de
proyecto
JP
Aplicaciones de la empresa.
Preparacin de Solicitud de Requerimiento.
Conocimiento RUP, UML, herramientas Case, Mtodos Agiles.
Preparacin de documentos funcionales.
Nivel alto de capacidad de anlisis.
Poder de negociacin y paciencia.
Liderazgo, seguridad.
Poder de negociacin, conocimientos de RUP, UML.
Manejo de equipos de trabajo.
Tabla 14 Roles y conocimientos esperados para el rea de proceso REQM
Actividades
Requerimientos de Desarrollo: Nuevos Proyectos
AR1. Solicitar Requerimiento
Cod.
AR 1.1
Prctica Rol
SP 1.1
Tarea
El cliente enva requerimiento para ser atendido.

AR2.Levantar informacin sobre Requerimiento
AR 2.1
GP 1.1
JP El Jefe de Proyecto recibe la solicitud de requerimiento y revisa la validez

del formato.
AR 2.2
JP Si el formato no es correcto, Solicita el envi del Formato valido de la

Solicitud de Requerimiento.
AR3. Registrar Requerimiento
AR 3.1
SP 1.1
AF Si el requerimiento ha sido solicitado en el Formato Valido registrado en

la Poltica de Gestin de Requerimientos, entonces se procede a
Registrar la Solicitud del Requerimiento para su posterior anlisis de
atencin.
AR4. Analizar Requerimiento
AR 4.1
SP 1.1
AF El Requerimiento se analiza para conocer si es un nuevo requerimiento o

es un cambio a un requerimiento solicitado previamente o cambio de
algn grado de impacto en el sistema.
AR5. Elaborar Modelo Conceptual
AR 5.1
SP 1.4
AF Si es un nuevo requerimiento, se elabora un modelo conceptual para

asegurar la comprensin de la solicitud.
AR6. Anlisis y Validacin de cambio
AR 6.1
SP 1.3
AF Los Requisitos sern verificados ante alguna afectacin frente a un

cambio solicitado por algn requerimiento.
- 56 -

AR 6.2
SP 1.3
AF El Analista Funcional trabajara una propuesta de cambio, sealando lo

analizado del requerimiento solicitado
AR 6.3
SP 1.3
AF Se elabora un informe del impacto que el cambio puede generar en el

desarrollo.
AR 6.4
SP 1.3
AF Se registra el cambio y el impacto en la Lista de cambios, tanto para

conocer lo que se trabaja y los cambios pendientes de implementacin
AR 6.5
AF Si el cambio es rechazado termina la actividad. Si es aprobado se le

enva al Jefe de Proyecto para que Evalu la propuesta y continua el
flujo.
AR7. Evaluar propuesta
AR 7.1
JP Evala la propuesta de atencin de requerimiento o el anlisis del

impacto de un cambio solicitado, arma una Atencin de Requerimiento y
se lo enva al cliente para su aprobacin.
AR8. Recibir propuesta de atencin de Requerimiento
AR 8.1
El cliente analiza la comprensin de la solicitud por ser atendida y

procede con la aprobacin de la propuesta para que siga su curso.
AR9. Registrar Requerimiento Aprobado
AR 9.1
SP 1.1
JP Se registra el requerimiento con la aceptacin del cliente y se actualiza la

lista de requerimientos.
SP 1.2
JP Se actualiza la Lista de Requerimientos para mantener actualizada la
AR 10.1
informacin.
AR10. Elaborar Cronograma de Desarrollo
AR 10.1
SP 2.2
JP Se elabora el cronograma de desarrollo para tener actualizada la

informacin y que ninguna actividad se desfase de la planificacin del
proyecto.
AR 11.1
SP 1.5
JP Se actualiza el cronograma tanto resumido como detallado. Se considera

la inclusin de los cambios aceptados por atender.
AR 12.1
GP 2.4 JP
Se detallan los involucrados en la atencin del requerimiento
GP 2.2
Se verifica la inclusin de todas las actividades de la gestin de
AR 13.1
JP
requerimientos
AR11. Desarrollar Organigrama del Proyecto
AR 11.1
SP 1.2
JP Se verifica la inclusin de los recursos del proyecto. Se asegura los

integrantes para la atencin de la gestin de requerimientos.
AR 12.1
SP 1.2
JP Se elabora el Acta de Reunin

AR12 Informar a Gerencia del proyecto
AR 12.1
GP
2.10
JP Se enva toda la informacin de las actividades de gestin de los

requerimientos.
Tabla 15 Descripcin de las actividades propuestas para el rea de proceso REQM
- 57 -

b.3. Matriz de Trazabilidad de las actividades vs. Practicas especficas de
GP 2.10
GP 2.9
GP 2.8
GP 2.7
GP 2.6
GP 2.5
GP 2.4
GP 2.3
GP 2.2
GP 2.1
GP 1.1
SP 1.5
SP 1.4
SP 1.3
Actividades
AR 1.1
AR 2.1
AR 2.2
AR 3.1
AR 4.1
AR 5.1
AR 6.1
AR 6.2
AR 6.3
AR 6.4
AR 6.5
AR 6.6
AR 7.1
AR 8.1
AR 8.2
AR 9.1
AR 9.2
AR 10.1
AR 10.2
AR 10.3
AR 10.4
AR 10.5
AR 11.1
AR 11.2
AR 11.3
AR 12.1
SP 1.2
Practicas
Especficas
SP 1.1
REQM
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabla 16 Matriz de trazabilidad de las actividades vs prcticas especficas de REQM
- 58 -

CONCLUSIONES
1.
De acuerdo al resultado de anlisis realizado para determinar en grado de

cumplimiento y no cumplimiento de las prcticas en las tres reas de
proceso (PP, PCM y REQM), se determina que se requiere el 57% de
esfuerzo de la Organizacin para obtener procesos eficaces.
2.
La evaluacin de las tres reas del proceso (PP, PCM y REQM) permitir
tener una oportunidad para corregir o modificar los procesos de desarrollo
de software que han perdido su desempeo en el tiempo.
3.
Se debe implementar una poltica o normativa que permita cambiar la

actitud del personal frente a los nuevos procesos que se estn
implementando en la Organizacin.
4.
Fomentar la integracin entre todos los integrantes de la compaa,

mediante reuniones de coordinacin donde cada uno podr aportar ideas
en beneficio de todos.
5.
Incentivar la formacin de una cultura organizacional, orientada a cumplir

con las expectativas de satisfaccin al cliente.
6.
Implementar nuevas tcnicas o metodologas que ayuden a las personas

a aumentar la productividad, efectividad y utilidad de la Organizacin, as
mismo continuar con la poltica de mejora continua en los procesos de
desarrollo de software y servicios.
7.
La definicin del proceso de planificacin es de vital importancia en el

ciclo de vida del proyecto, ya que al culminar el proyecto permitir evaluar
lo real con lo estimado.
- 59 -

CAPITULO 3
MTODOS GILES PARA EL DESARROLLO DE
SOFTWARE
- 60 -

INTRODUCCIN
Los sistemas de informacin pueden constituirse en una gran variedad de
soluciones que podran
funcionar desde escenarios muy simples, con
cualidades de ser prcticos, de bajo costo, con pocas restricciones, limitados

controles y consumo de recursos; e ir variando hasta convertirse en soluciones
complejas, de considerable costo, muy robustas, con muchas restricciones, uso
de sofisticadas herramientas, cuantiosas reglas de negocio automticas, que
generan mltiples artefactos para variados usos y toda una gama de controles
y validaciones que demandan la necesaria interaccin de
las personas en
mltiples instancias de la organizacin.
Sin embargo, la experiencia mundial ha demostrado que las soluciones en TI,

segn sea la problemtica por atender podran resultar sobredimensionadas, o
complicar las actividades cotidianas de la organizacin. Por ello es muy
importante concebir el criterio de que la sofisticacin y gran costo de las
soluciones en sistemas de informacin, no necesariamente se convierte en el
apropiado remedio a los problemas que se pretenden resolver, y en otras
muchas oportunidades las integraciones de sistemas desatienden la solucin
de situaciones problemticas cambiantes de gran volatilidad, que encarecen la
oferta de servicios de las casas de software basadas meramente en soluciones
de TI.
Por ello, es preciso resaltar que en la actualidad Mtodos giles, juega un rol
trascendental de aplicacin universal, que viene acompaado de mucha
bibliografa, casos de xito e impulso a nivel mundial, lo que est motivando el
inters de muchas casas consultoras que las est incorporando como una
solucin ms plena que complementa sus soluciones de TI, y que aplica a
resolver
situaciones
problemticas
postergadas.
Tambin
es
preciso
mencionar, que los fundamentos de los Mtodos giles se basan en la

simplicidad, y su aplicacin siguiendo la metodologa que est al alcance de
personas emprendedoras que desean solucionar problemas cotidianos, y que
- 61 -

ya han sido aplicadas y maduradas progresivamente en la realidad de nuestros

centros de trabajo, proporcionando cambios muy favorables en la organizacin.
En tal sentido, el documento est organizado como sigue: Fundamentacin

terica sobre las practicas seleccionadas; Adopcin de prcticas agiles
implementadas en nuestro centro de trabajo; y finalmente la Evaluacin de los
Resultados, todo lo cual, pasaremos a explicar a continuacin.
- 62 -

3.1 Fundamentacin Terica

TABLERO KANBAN
La palabra Kanban, de origen japons, se compone de dos trminos: Kan-ban
que puede traducirse como "tarjetas visuales o Tablero visual, y se considera
una filosofa derivada del mtodo Just In Time (JIT) [1].
Figura 19 Tablero Kanban [2]
Es un mecanismo basado en el sistema de produccin Toyota, que se inspira

en los principios de otras metodologas giles y en adicin del enfoque Kaizen
(mejora continua), que dispara trabajo slo cuando existe capacidad para
procesarlo.
El disparador de trabajo es representado por tarjetas kanban, que implementa
un mtodo eficaz y gil mediante anotaciones que precisan de las gestiones
realizadas inscritas en tarjetas visuales que acompaan al flujo del proceso [1].
Esta forma de accionar permite conocer el estado situacional de los problemas

para la toma oportuna de accin para su solucin, sin necesidad de disponer
de una sofisticada y/o costosa tecnologa, y jugando con las capacidades
permisibles, de acuerdo con la disponibilidad limitada de los recursos con que
se cuenta.
En tal sentido, evaluados los recursos y en base a ello definido el nmero de

tarjetas Kanban disponibles, stas se van utilizando asociadas a cada caso y
acompaan a un item de trabajo durante todo el proceso de produccin, hasta
que ste, es empujado fuera del sistema, liberando una tarjeta. Un nuevo tem
- 63 -

de trabajo, solo podr ser ingresado/aceptado si se dispone de una tarjeta

kanban libre.
Este proceso de produccin, donde un trabajo se introduce al sistema slo

cuando existe disponibilidad para procesarlo, se denomina pull (tirar) en
contrapartida al mecanismo push (empujar), donde el trabajo se introduce en
funcin de la demanda.
En otras palabras, Kanban es un sistema de Pull y no de Push (tirar y no

empujar) porque puede ser accionado y efectuado por la disponibilidad de los
recursos, es decir, cuando es posible de ser atendido, cuando es necesario y
cuando se necesita.
En el desarrollo de Software, Kanban fue introducido por David Anderson, de la

Unidad de Negocios XIT de Microsoft, en 2004, reemplazando el sistema de
tarjetas, por un tablero visual similar al de Scrum, que se basa principalmente
en [2]:
Visualizacin del flujo de trabajo: Consiste en la visualizacin de todo el
proceso de desarrollo, mediante un tablero fsico que se divide en columnas,
las cuales representan un proceso de trabajo (insumos, atencin del proceso
(actividades que lo ejecutan), y resultados o producto).
El objetivo de mostrar el proceso, consiste en: Entender mejor el proceso de
trabajo actual; conocer los problemas que puedan surgir, tomar decisiones
en la oportuna solucin de los problemas para stos no se repitan en el
prximo ciclo de proceso; y, mejorar la comunicacin entre todos los
interesados/participantes del proceso para asegurar su fluidez y expedites.
Limitacin del trabajo en curso: Los lmites del WIP (work in progress
trabajo en curso) consiste en conocer la capacidad lmite para asegurar un
proceso continuo, lo cual se debe acordar previamente, para concertar en la
cantidad de tems que se pueden atender por cada proceso (es decir, por
- 64 -

columnas del tablero). El principal objetivo de establecer estos lmites, es el

de anticiparse en la deteccin de cuellos de botella, descubrir ms
tempranamente los errores, defectos y consideraciones que fueron omitidas.
Medicin y gestin del flujo: Al terminar ms rpidamente cada etapa del
proceso (mediciones comparativas), y pasar el trabajo al siguiente proceso
identificando las anomalas que se presenten, ello nos permite tener una
retroalimentacin ms rpida para asegurar la fluidez del proceso e
identificar con claridad los problemas que se descubren para participar en
subsanarlos con mucha mayor rapidez, y evitando los cuellos de botella,
traducindose en menor costo, tiempo, uso de recursos y menor dao. El
objetivo es lograr mantener una produccin estable, continua y previsible,
midiendo con precisin el tiempo que emplean las actividades que
conforman el ciclo completo que demanda la ejecucin del proceso.
Kanban ofrece el
marco necesario para crear su propio proceso, hasta
encontrar el flujo ptimo de trabajo y la preparacin del equipo de trabajo

implicado en cada etapa del proceso, y slo con indicaciones sencillas:
visualiza el flujo, el estado de las tareas y minimiza el trabajo en curso,
establece mediciones, y con el equipo adecuado de personal motivado y
debidamente acondicionado en sus roles y actividades, se irn alcanzando la
participacin ideal en el proceso [1].
DAILY MEETING
Breve reunin diaria para realizar el repaso al avance de cada tarea, con
revisin de las mediciones, identificacin de los problemas, as como la
adopcin de acciones de solucin y ajustes previstos para evitar los cuellos de
botella, y asegurar el trabajo planificado para la jornada, adems de permitir
que el equipo se sincronice para trabajar de forma coordinada [3].
- 65 -

Figura 20 Daily meeting [3]
Daily Meeting tiene unas guas especficas:

La reunin comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo- para quien llegue tarde.
Todos son bienvenidos, pero solo el equipo comprometido con el proyecto
puede hablar.
La reunin tiene una duracin fija de 15 minutos, de forma independiente
con el tamao del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a asegurar una
reunin corta y mantener la atencin de los participantes).
La reunin debe ocurrir en la misma ubicacin y a la misma hora, todos los
das.
Durante la reunin, cada miembro del equipo contesta a tres preguntas:
Qu has hecho ayer?, Qu es lo que ests planeando hacer hoy?, Has
tenido algn problema que te haya impedido alcanzar tu objetivo? Ello
atendiendo a aspectos que salgan de la rutina normal del proceso, y en el
caso de los problemas, para asegurar su oportuna revisin y solucin a fin
de que no se repitan.
TASK BOARD
Una representacin del estado del proyecto, que muestre a simple vista la
situacin actual. Debera ser una referencia para saber en qu va el proyecto
con slo mirarlo. Por lo tanto, se tienen que tratar de mantener el nivel de
complejidad al mnimo posible. De todas formas, como todo en Scrum, su
implementacin debera irse adaptando a las necesidades del equipo de
trabajo [4].
- 66 -

Herramienta utilizada para mostrar el cmo se implementarn las historias de

usuario que forman parte de un sprint dentro de la metodologa gil de
desarrollo de software scrum.
Este panel de control deber contener los productos a desarrollar (historias de

usuario) y las actividades que los componen, incluyendo los estados en el que
se encuentran: "Por hacer", "Trabajndolo", "En pruebas" y "Terminado"; es
muy comn implementarlo con notitas Post-it agrupadas de manera matricial,
de acuerdo al siguiente esquema [5]:
Figura 21 Un Task Board con historias de usuario, tareas y estatus de implementacin.

Fuente: Eclipse Wikis: Scrum
Se puede usar post-its de distintos colores para diferenciar tipos de tareas.

Referencia de colores:
Los post-it amarillos para mostrar las historias de usuario asignadas durante
el planning sprint.
Los post-it verdes para mostrar las tareas estimadas.
Los post-it rojos, para errores. o que son tareas opcionales, para tiempo que
sobre.
Todos los movimientos en el Task Board se deben realizar nicamente en el
Daily Meeting
- 67 -

PAIR PROGRAMMING
Es una de las tcnicas que componen la metodologa de programacin extrema
(XP). Se puede considerar la programacin extrema como la adopcin de las
mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a
cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida
del software [7].
Figura 22 Pair programming[7]
Se requiere que dos Ingenieros en Software participen en un esfuerzo

combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una
accin que el otro no est haciendo actualmente: Mientras que uno codifica las
pruebas de unidades el otro piensa en la clase que satisfar la prueba, por
ejemplo.
La persona que est haciendo la codificacin se le da el nombre de

controlador mientras que a la persona que est dirigiendo se le llama el
navegador. Se sugiere a menudo para que a los dos socios cambien de
papeles por lo menos cada media hora o despus de que se haga una prueba
de unidad.
La programacin en pareja se enfoca en las siguientes ventajas, ordenadas de

mayor a menor.
Ms Disciplina. Emparejando correctamente es ms probable que hagan "lo
que se debe hacer" en lugar de tomar largos descansos.
- 68 -

Mejor cdigo. Emparejando similares es menos probable producir malos

diseos ya que su inmersin tiende a disear con mayor calidad.
Flujo de trabajo constante. El emparejamiento produce un flujo de trabajo
distinto al trabajar solo. En pareja el flujo de trabajo se recupera ms
rpidamente: un programador pregunta al otro "por dnde quedamos?".
Las parejas son ms resistentes a las interrupciones ya que un desarrollador
se ocupa de la interrupcin mientras el otro contina trabajando.
Mltiples desarrolladores contribuyen al diseo. Si las parejas rotan con
frecuencia en el proyecto significa que ms personas estn involucradas con
una caracterstica en particular. Esto ayuda a crear mejores soluciones,
especialmente cuando una pareja no puede resolver un problema difcil.
Moral mejorada. La programacin en parejas es ms agradable para algunos
programadores, que programar solos.
Propiedad colectiva del cdigo. Cuando el proyecto se hace en parejas, y las
parejas se rotan con frecuencia, todos tienen un conocimiento del cdigo
base.
Enseanza. Todos, hasta los novatos, poseen conocimientos que los otros
no. La programacin en pareja es una forma amena de compartir
conocimientos.
Cohesin de equipo. La gente se familiariza ms rpidamente cuando
programa en pareja. La programacin en pareja puede animar el sentimiento
de equipo.
Pocas interrupciones. La gente es ms renuente a interrumpir a una pareja
que a una persona que trabaja sola.
- 69 -

Menos estaciones de trabajo. Ya que dos personas van a trabajar en una

estacin de trabajo, se requieren menos estaciones de trabajo, y las
estaciones extras pueden ser ocupadas para otros propsitos.
Los estudios han demostrado que despus de entrenar para las habilidades
sociales implicadas, parejas de programadores son ms de dos veces ms
productivos que uno para una tarea dada. Segn The Economist [6]:
"Laurie Williams de la universidad de Utah en Salt Lake City ha demostrado

que los programadores emparejados son solamente 15% ms lentos de dos
programadores trabajando independientemente, pero producen 15% menos
errores. Y ya que la prueba y depuracin son a menudo muchas veces ms
costosa que la programacin inicial, esto es da un resultado impresionante"
Es un dilogo entre dos personas simultneamente programando, analizando,

diseando y probando; y tratando de programar mejor. Hacer pareja no
significa que no se puede pensar slo. Ambas personas necesitan
compaerismo y privacidad, si alguno de los miembros necesita trabajar en una
idea debe hacerlo, pero cuando regrese debe revisarlo con su equipo [6].
Sit Together
Desarrollar en un espacio abierto lo suficientemente grande como para

contener al equipo completo, donde cada integrante posea su espacio de
privacidad.
Figura 23 Sit together[8]

- 70 -

Es importante que quienes conformen el equipo se sienten juntos y puedan

establecer contacto visual con facilidad. Esto no siempre es posible, entonces
se debe recurrir a otros espacios que puedan frecuentarse regularmente. Hay
que tener en cuenta que si el equipo est disperso y se presentan problemas
es importante reunirse ms a menudo, en la forma en que se pueda [8].
3.2 Adopcin de Prcticas giles
3.2.1 Prctica gil 1: Kanban

I. Sprint 1
Anlisis de la situacin actual

La empresa ha sido recientemente concesionada en todo el core de
negocio, quedando solamente en funcionamiento las reas Administrativas
que cuentan con el aporte tecnolgico de un Sistema Integral Administrativo
que comprende 11 mdulos, referidos a: Recursos Humanos, Planillas,
Seguro Mdico, Control de Asistencia, Pensionistas, Contabilidad, Cuentas
por Pagar, Cuentas por Cobrar, Activo Fijo, Presupuesto y Logstica.
Como resultado de la concesin, gran cantidad de trabajadores se
acogieron al programa de renuncia voluntaria quedando en las oficinas
personas que conocen poco o nada del proceso y operacin de dicho
sistema administrativo, que tiene que seguir operando para producir los
resultados, retro insumos y reportes que requiere la organizacin para
engranar y controlar sus actividades, cumplir con sus obligaciones y
reportar a los organismos externos.
En tal escenario de carencias y necesidad de apoyo, la Gerencia de

Tecnologa de Informacin tambin se vio afectada con el trmino de
contrato que sostena en la modalidad de outsourcing con la participacin
de un equipo de colaboradores, de los cuales un grupo de ellos formaban
parte del rea de Desarrollo de Sistemas, quedando en la actualidad slo
con dos personas para atender los pedidos de asistencia tcnica en las
- 71 -

diversas reas; por tales circunstancias, actualmente no se estn

desarrollando nuevos requerimientos, solo se atienden mantenimientos,
extraccin de informacin, capacitaciones y asistencia tcnica a usuarios.
Actualmente, existen muchos requerimientos de informacin para satisfacer

pedidos
internos,
externos
de
auditoria,
adems
se
solicitan
capacitaciones para el manejo del sistema, ya que existen muchos usuarios

nuevos. Ante tal demanda de trabajo, al reducido nmero de personas del
rea de sistemas no le es posible concretar una atencin en el tiempo y
oportunidad que surge la necesidad ya que la congestin, jerarqua del rea
que requiere las soluciones y la importancia de los problemas ocasiona que
permanentemente se cambien las prioridades y finalmente se sumen las
quejas y reclamos injustificados que ocasionan que se pierda de vista la
Orden de Trabajo que requiere atencin, ya que los plazos se tornan
imposibles de cumplir o simplemente ya se vencieron quedando
insatisfechos.
Seleccin de la prctica gil a implementar

En tal contexto, siendo de alta rotacin los requerimientos de las diversas
reas y de perfecta aplicacin al caso de estudio de mtodos giles, se
seleccion la prctica de:
Tablero Kanban
Resultado esperado
Con sta prctica, sin acudir a recursos humanos que no se disponen para
el desarrollo de una solucin, se aplica el mtodo Kanban para inicialmente
conocer la disponibilidad de recursos y su capacidad de atencin, adems
de conocer de forma visual el flujo de trabajo posible de atender, descubrir
los problemas tempranamente, reducir los flujos y acciones que no
representen valor, establecer mediciones y controlar el trabajo al ejecutarlo
- 72 -

para descubrir los cuellos de botella y tomar decisiones que aporten

soluciones definitivas (no se repitan los problemas) y se genere valor.
II. Sprint 2
Planificacin
Se identificaron las actividades pendientes, en curso y las recientemente

terminadas
Se realiz la clasificacin de las actividades pendientes segn la prioridad de
su atencin.
Se define que inicialmente las columnas que controlen el flujo de trabajo a
considerar en el tablero sern:
Por hacer: rdenes de Trabajo que ya cuenta con la coordinacin del
usuario sobre lo que espera recibir.
Requerimiento: En esta parte del tablero se colocaran las solicitudes de
trabajo que han sido requeridas y que llegaron a travs de memorndums,
oficios (si se trata de entidades externas) o por correo electrnico, y que an
no cuentan con la especificacin o detalle de lo esperado con el rea
usuaria.
En atencin: Desarrollo: en esta columna se ha definido que el lmite de las
rdenes de Trabajo en curso son de tres. Asimismo se ha subdivido esta
columna en dos, referidas a: haciendo (actividades en atencin) y listo:
cuando fueron concluidas pero requiere del control de calidad previo para su
paso al siguiente nivel.
Revisin: En esta columna se colocan las rdenes de Trabajo que estn
siendo revisadas y que han sido derivadas a las reas que lo solicitaron su
atencin. Cabe mencionar, que siendo una limitante del proceso la cantidad
de recursos del rea de desarrollo, entonces se estableci y coordin
- 73 -

previamente, que esta actividad sera atendida con los recursos de la propia
rea usuaria.
Terminado: Una vez concluida la etapa de revisin por los responsables de
las reas usuarias, se la conformidad de la atencin, con lo cual la Orden de
Trabajo se da por concluida.
Se definen los contenidos de cada tarjeta, quedando en que se colocarn las
fechas en las que llega el requerimiento, en que se identifica lo que hay que
hacer, aquella en que pasa al estado haciendo y la fecha en la que se
encuentra en estado terminado. Asimismo, se identifica la prioridad o
preferencia de las acciones segn el color de la tarjeta utilizada; en tal
sentido, cuando una Orden de Trabajo requiere ser atendida con urgencia,
se utilizar post-it verde; mientras que se utilizar post-it rojo para cuando
el lmite de la capacidad de trabajo ya est consumido, y que se manifiesta
cuando la Orden que le toca ser atendida, en ese momento queda en estado
de espera.
Se define que en el tablero irn todas las rdenes de Trabajo que demoren
ms de una hora para su atencin.
Convencimiento a la Gerencia de la Oficina de Tecnologas de Informacin
(OTI), sobre la implementacin de ste piloto en las labores de Desarrollo.
- 74 -

Ejecucin
Figura 24 Sprint 2 Tablero Kanban (1)

Inicialmente las tareas eran agregadas tmidamente, el WIP se estableci en tres, y en la
atencin de incidencias o tareas que no figuran en el tablero, se formaba cuello de botellas en
haciendo

Muchas tareas en estado haciendo pasaban al estado de espera porque se solicitaban otras
tareas que eran requeridas con prioridad
Evidencias en video: http://www.youtube.com/watch?v=7pGfs5NZvg4
- 75 -

Retrospectiva
Al inicio de la prctica fue necesario establecer el flujo del proceso que
abarca las acciones para canalizar la atencin de todos los requerimientos,
con lo cual se fueron conociendo los problemas, encontrando su solucin y
estableciendo el protocolo del proceso entre las reas usuarias que
requieren solucin a sus problemas y los recursos humanos del rea de
Desarrollo, encargados de solucionarlas en la medida de su capacidad de
atencin, fue algo trabajoso nuestra capacidad de atencin, as como definir
las columnas que debieran formar parte del tablero, adems de identificar
los estados de las tareas para colocarlas en su respectivo lugar.
Como era de esperar, a causa de la gran demanda de soluciones y el

limitado nmero de personas para atenderlas, el tablero lleg a tener mucho
movimiento, causando preocupacin el hecho de que las tareas que se
encontraban en la etapa haciendo, tenan que ser postergadas para dar
atencin a temas urgentes, a pesar de que se tendran que distraer los
mismos recursos ya ocupados para atender esas tareas prioritarias.
Asimismo, atendiendo a la planificacin se estableci que en el tablero

serian colocadas las tareas cuya duracin en su atencin fuera mayor a una
hora, sin embargo, existan muchas tareas que eran atendidas en rango
menor pero que por su constancia repetitiva, prcticamente ocupaban todo
el da de trabajo, adems de que la presin de las reas usuarias en
obtener solucin a sus requerimientos, capacitaciones o
respuestas a
documentos escaparon al patrn formal del requerimiento al ser solicitados

por va telfonos, o verbal en las visitas de usuarios, o presin por la
jerarqua de gerentes de rea, que pedan prioridad en los sus temas de su
inters, ocasionando que se ocupen los recursos en sas atenciones.
En la revisin de los resultados se propone para el siguiente sprint el

reordenamiento del horario de oficina para la atencin de incidencias o
- 76 -

tareas no planificadas, solicitando autorizacin a la gerencia de la OTI que

estas se atenderan a puertas abiertas solo hasta el medioda, y posterior a
ello la puerta permanecera cerrada, adems que solo se contestaran
llamadas estrictamente urgentes para continuar con las tareas programadas
en el tablero.
III. Sprint 3
Planificacin
Se mantiene el esquema planteado en la explicacin del sprint 2, a fin de
permitir familiarizarse con la ejecucin de esta prctica.
Asimismo, se establece que la atencin de las tareas y/o incidencias se

realizarn en dos grupos, el primero, desarrollado en el horario de 8 a 12
am, dedicado a las resolver las incidencias o capacitaciones que los
usuarios pudieran demandar a dedicacin exclusiva, y cuya atencin no
abarque ms de una hora, tal como fue establecido; y para el resto del da,
hasta el horario de las 6.00 pm con atencin por turnos a puerta cerrada,
para ser dedicadas a las tareas consignadas en el tablero.
Ejecucin
- 77 -


Ahora ms tareas son terminadas dentro del plazo previsto, sin embargo, de existir algn cuello
de botella, la tarea es puesta en espera y coordinaba su solucin con el lder usuario

Este nuevo esquema empezar a ser utilizado, y permitir a los lderes usuarios tener una visin
completa del estado de sus rdenes de trabajo, y en caso quisieran agregar tareas tenan, la
alternativa sera mover la prioridad con alguna de las ya establecidas
Evidencias en video: http://www.youtube.com/watch?v=71lYQooZSFY
- 78 -

Retrospectiva
La implementacin de esta mejora permiti tener un trabajo ms fluido,
aunque no todo pudo ser perfecto, ya que a pesar de estar a puerta cerrada
siempre se produjeron excepciones, pero con mayor control.
Hubo mayor apoyo desde la Gerencia de la que dependo, sobre todo
despus de comprender el uso del tablero y conocer los resultados
favorables; asimismo, recomend que sta prctica se extendiera para
organizar la atencin de los requerimientos de responsabilidad de los
dems equipos de la Oficina.
Se propone como mejora que en el tablero se consignen las tareas
organizadas por las cuatro grandes reas implicadas en el aporte del
Sistema Integral Administrativo, para que as los lderes usuarios tuvieran
una visualizacin ms clara de las rdenes de trabajo que estaran en
perspectiva de ser atendidas y que ellos mismos deban priorizar el trueque
apropiado de requerirse alguna necesidad de cambio.
Se retir del tablero el campo de requerimientos, donde se colocaban las
ordenes de trabajo generadas por las reas, pero de las que no se contaba
con la claridad suficiente para propiciar su atencin, debido a que
transcurra mucho tiempo sin ser especificadas las acciones por atender,
aducindose
falta de tiempo para ello, lo que ocasionaba que
permanecieran pendientes todo el tiempo en el tablero, en cambio ahora

son devueltas solicitando previamente la aclaracin o propuesta de reunin
para culminar la especificacin necesaria.
Dichas reuniones tambin tendrn la misma modalidad de atencin gil y
directa, ya que nos centramos rpidamente en lo que se requiere, con lo
cual concluyen rpido y se puede avanzar mejor.
3.2.2 Prctica gil 2: Daily Meeting

I. Sprint 1
- 79 -


La cantidad de rdenes de Trabajo que se generan y que llegan por
memorndums, correos electrnicos, llamadas telefnicas, o directamente
de la Jefatura, no permite llevar el control adecuado para que todas puedan
ser atendidas en el tiempo oportuno.
Durante su ejecucin cualquier
problema que se presentaba no era comunicado oportunamente porque se

prefera pasar la atencin a la siguiente orden de trabajo, dejando aquella
orden de trabajo en espera.
La poca comunicacin que exista por estar inmersos en el da a da,

tratando de atender el mayor nmero de requerimientos no permita conocer
los inconvenientes a tiempo para que pueda ser escalado y solucionado por
los interesados, sin embargo, a pesar de ello se lograba reducir la brecha
de rdenes de trabajo (aquellos que conseguan fluir hasta la fase de
Terminados sin presentar problemas).

Se selecciona la prctica:
Daily meeting
Resultado esperado
Que se cumplan con la programacin de dos 2 reuniones por semana, lunes
y jueves a las 8.30, con una duracin mnima de 5 minutos.
Se espera mejorar la comunicacin, conocer los problemas (sobre todo los
recurrentes) que pueden detener el flujo de atencin y que ponen en peligro
las fechas de entrega.
II. Sprint 2
Planificacin
En la presentacin del tablero kanban y los beneficios que se esperan

recibir, se establece que el seguimiento de este tablero se complementar
- 80 -

con reuniones cortas; inicialmente dos reuniones por semana: lunes y jueves
a las 8.30 de la maana.
Se establecen las reglas de cada sesin: reuniones alrededor del tablero y
de pie, con tiempo mnimo 5 minutos y mximo 15 en caso que se requiera
de ms tiempo; para esto slo se tocarn temas relacionados al estado de
los trabajos y los problemas o cuellos de botella que se encontraron durante
el flujo de su desarrollo, y las acciones a realizar para que se siga moviendo.
El feedback que se obtiene de las reuniones de trabajo permitir conocer el
problema, planificar acciones de solucin que sern actualizados en el
tablero.
Ejecucin
Figura 28 Sprint 2 Daily meeting (1)

Inicialmente una reunin bastante tmida por parte de mi colaborador, y solo fueron reclamos
sobre las atenciones adicionales que se brindan y que no forman parte de este tablero
- 81 -


Al final del sprint haba mucha mayor comunicacin y anima al equipo a encontrar sus propias
soluciones
Evidencias en video: http://www.youtube.com/watch?v=TwmogHsHn4E
Retrospectiva
La prctica se realiz con una variacin pequea en los horarios de inicio,
alcanzo el nivel esperado, ya que antes de su ejecucin contaba con un
colaborador un poco tmido para la comunicacin, siempre sumido en los
reclamos por soluciones prontas y mortificado pensando que las reuniones
eran improductivas, adems de que ocupaban mucho tiempo y resolvan
poco o nada la problemtica que atravesaba el rea de Desarrollo. Al inicio
cost trabajo y frustraciones poder retroalimentarse de las experiencias de
captaba desde el trabajo que realizaba, adems de hacer desconfiar en que
este mtodo pudiera resultar exitoso y realmente convertirse en un
valorable aporte para aliviarnos en los problemtica del da a da.
Como resultado, al trmino de este Sprint se obtuvo a un colaborador ms

abierto a escuchar, adems de aprender a expresar con claridad y
- 82 -

concretamente los problemas hallados para plantear el desarrollo correcto

del trabajo a realizar.
III. Sprint 3
Planificacin
Se agrega una sesin adicional a las 2 reuniones programadas para el
transcurso de la semana, quedando establecidas para los lunes mircoles y
viernes, en el mismo horario y manteniendo las mismas caractersticas del
sprint 2.
Ejecucin

Se mejor la comunicacin, los reclamos por el desorden en la atencin cedieron, hubo mayor
dedicacin, y el agregar una sesin ms en las reuniones semanales ahora permite identificar
ms rpidamente cualquier impedimento que pudiera surgir
- 83 -


La mejora para la nueva distribucin de las tareas en el tablero fue aceptada
Evidencias en video: http://www.youtube.com/watch?v=LIPgnJ9usoM
Retrospectiva
Ya casi siempre se respetaba el tiempo y se consegua comentar lo
importante, en lo cual no se exceda de 5 minutos. Creo que ello era
bueno, ya que permita centrarse solo en que quede la evidencia de los
impedimentos que pudieran surgir en el avance.
Inmediatamente terminada la reunin se proceda a documentar los

impedimentos que no estaban al alcance de ser solucionados para
conocimiento de la Gerencia y que posteriormente se pudiera realizar su
trmite.
3.2.3 Prctica gil 3: Task board

I. Sprint 1

El rea de desarrollo tena un equipo de desarrollo los cuales se
encontraban ubicados en diferentes ambientes, de tal forma que no se tena
- 84 -

conocimiento certero de lo que cada miembro del equipo estaba

desarrollando.
Esta rea de desarrollo se encarga de realizar todos los proyectos de
desarrollo que el rea de ventas capta en su cartera de clientes diversos,
sin embargo no existe un procedimiento definido para planificar, ejecutar y
controlar los diversos proyectos de desarrollo. El da a da de la carga
laboral no permita organizar de manera efectiva el rea, se conducan los
proyectos como pequeas islas. Se realizaban reuniones espordicas de 15
das
ms,
durante
ese
tiempo
los
proyectos
se
gestionaba
individualmente.
Uno de los proyectos que se llev a cabo utilizando outsourcing para el

desarrollo se convirti en un caos, ya que los miembros del equipo se
encontraban aislados, este proyecto dur en total 2 aos (1 ao y medio
controlado por el tercero, ms 1 ao controlado por el rea)
En muchos de los proyectos de desarrollo se haca necesaria una induccin

o entrenamiento en el negocio para el cual se iba a realizar el desarrollo,
estas actividades se asuman como parte de la etapa de programacin, lo
que comprometa un tiempo adicional no contemplado en los entregables.
Los desarrollos consistan en realizar el levantamiento de informacin de

todo lo que se solicitaba, para que luego el equipo de desarrollo se dedicara
a programar hasta culminar; esta forma de conducir los proyectos
ocasionaba que el producto final no cumpla con las expectativas o
especificaciones del cliente, ya que en muchos casos se asuman y
concluan dudas presentadas durante el desarrollo; esta situacin generaba
mayor costo ya que en algunos casos se requera un re-diseo del sistema
o aplicativo desarrollado.
- 85 -

Por tales razones, se justifica la necesidad de implementar alguna prctica

que aporte en la organizacin de los proyectos de desarrollo y sobre todo
que no requiere aprobacin de alguna gerencia, motivo por el cual se eligi
la prctica:
Task board
Resultado esperado
Con la aplicacin de esta prctica lograremos visualizar en un slo panel los
requerimientos de los proyectos de desarrollo en los que estn involucrados
los miembros del equipo; cambiar la forma de pensar donde el trabajo de
cada uno sea responsabilidad del equipo hace a un cambio general en el
ambiente.
II. Sprint 2
Planificacin
Se realiz una induccin en el tema de metodologas giles, para ello se
utiliz pginas web didcticas que permitieron explicar a manera de
resumen dicha metodologa.
Para poder construir el task board se realizaron prcticas de daily
meeting donde cada miembro del equipo responda a las tres preguntas:
Qu hiciste ayer? Qu vas hacer hoy? y Si tienes alguna duda?
Se consolidaron los requerimientos de los proyectos que haban iniciado
su fase de desarrollo, los cuales se consiguieron llevando a cabo la
prctica de daily meeting.
Se encontraron requerimientos que tomaran ms de 1 semana, los
cuales fueron divididos.
Se ordenaron los requerimientos por proyecto y prioridad indicada por el
solicitante.
- 86 -

Se definieron las columnas del panel por las que cada requerimiento
pasara cumpliendo con el ciclo de vida de desarrollo:
-
Story (Historia): Se colocaron los diversos requerimientos llamados

tambin historias de usuario.
To Do (Hacer): Contena las tareas que estaban pendientes de iniciar.
In process (En proceso): Contena las tareas que estaban siendo

realizadas.
To verify (Para verificar): Contena las tareas que estaban siendo

probadas.
Done (Hechi): Contena las tareas que haban sido culminadas.
Se definieron los colores de los post-it:

Amarillo: requerimientos
Verde: tarea asignada
Se escribieron las tareas que se tenan que realizar por cada
requerimiento.
Se procedi a colocar cada tarea en la columna correspondiente segn la
fase en la que se encontraba.
Ejecucin
- 87 -

Figura 32 Sprint 2 Task board (1)

Al momento de hacer el panel se dio la necesidad de agregar en una columna el cliente ya que
se manejan varios proyectos.
- 88 -

Las tareas se haban movido de columna, puesto que ya haban cubierto dicha fase del ciclo de
vida del proyecto.
Retrospectiva
Al empezar la construccin del panel hubieron preguntas, como por
ejemplo: cul era la diferencia entre la columna story y la columna to do
ya que se pensaba que el requerimiento era el que pasaba de una columna
a otra; se explic el mecanismo de funcionamiento del panel, indicando que
los post-it de los requerimientos (story) son estticos hasta que se cumple
con el requerimiento y que los post-it pequeos son los que pasan de una
columna a otra segn el progreso del mismo.
No encontramos un espacio donde colocar el nombre del miembro del

equipo asignado a cada tarea, muchas de las cuales son realizadas por
- 89 -

varias personas. Se propuso colocar las iniciales del nombre de la persona

asignada en una esquina inferior de cada post-it.
El tiempo de duracin de los proyectos de desarrollo pueden estar entre 1 a

6 meses, por lo que en el panel tuvimos dudas de cmo implementar esta
realidad; si llegbamos a colocar un proyecto de 4 meses, este cubra ms
de un panel y los dems proyectos no se visualizaran. Se sugiri
contemplar dos paneles para manejar:
-
Requerimientos a corto plazo (entre 2 a 6 semanas)
Requerimientos a mediano plazo (2 a 6 meses)
Relacionar un requerimiento del panel a mediano plazo con un

requerimiento del panel a corto plazo.
Hay actividades soporte que realiza el rea de desarrollo por el reporte de

incidencias en los clientes, esta actividad tienen prioridad con respecto a las
dems, razn por la que surgi la duda de cmo implementarla en el panel
para que sea visible. Surgi la mejora de contemplar una primera lnea
superior dentro del panel, la cual representara una zona en la que las
tareas no son planificadas pero son urgentes de atender.
Finalmente las personas de las dems reas opinaban del panel que estaba
en el rea de desarrollo, preguntaban qu significaba o se acercaban a leer.
I.
Sprint 3
Planificacin
Se estructur un nuevo panel adicionando en la parte superior una lnea
llamada swimlanes, la cual permitira colocar en dicha zona dividida, las
tareas solicitadas por temas de soporte.
Se construy un solo panel, en el que se detall los requerimientos de un
slo cliente por un desarrollo de 1 mes.
- 90 -

Se proporcion y esclareci los colores de los post-it para identificar de

manera visual las tareas en cada columna.
Se coloc en cada tarea las iniciales del nombre de la persona para
verificar la disponibilidad de cada miembro del equipo.
Ejecucin
Figura 34 Sprint 3 Task board(1)
En este nuevo diagrama se visualiza el swimlane adicionado para manejar las tareas
no planificadas de soporte.
- 91 -


En el segundo da ingreso al panel una tarea no planificada de soporte, que provoc que una
tarea en proceso qued suspendida por dos das, por lo que se pint dos puntos rojos (uno por
cada da)
Evidencias de video: http://www.youtube.com/watch?v=ubICgsca_V0
Retrospectiva
Los
miembros
del
equipo
se
encontraban
ms
colaborativos
en
comparacin a la primera vez.
Se tena una mejor visin de las tareas debido a los cambios realizados al
panel: se agreg el swimlane (se puede visualizar las tareas de soporte en
caso hubiesen), se estandariz los colores de los post-it, se coloc la
iniciales de la persona asignada a la tarea.
- 92 -

Cuando hay una tarea que es comn en varios requerimientos, tenamos

duda de cmo implementarlo, una propuesta podra ser colocar una tarea
por cada requerimiento.
3.2.4 Prctica gil 4: Pair Programming

I. Sprint 1

Durante las pruebas realizadas en un proyecto, para el cual la empresa
terceriz el desarrollo, el tiempo estimado se duplic hasta en un 150%,
esto debido a que el equipo de desarrollo que se encarg de la
programacin estuvo aislado y trabaj de forma independiente.
Muchos de los errores o incidencias reportadas en este desarrollo

tercerizado fue por qu no se involucr a un equipo de desarrollo mixto (de
la empresa y del tercero), por el contrario se asumieron funcionalidades
incorrectas.

Como aporte en la resolucin de este tipo de problemas en el rea de
desarrollo se elige como prctica:
Pair Programming
Resultado esperado
Al aplicar esta prctica se espera contar con el ambiente nico para todos
los miembros del equipo, lo cual permitir compartir conocimientos y
habilidades.
Aprovechando la fase de pruebas de un proyecto de desarrollo se propuso

trabajar con dos personas sentadas frente a una misma computadora, cada
una de las cuales deber aportar, tanto el programador y el analista. El
- 93 -

tiempo de pruebas deber disminuir en comparacin al tiempo de pruebas

que tom en la versin anterior.
II. Sprint 2
Planificacin
Se
seleccion
las
dos
personas
que
conformarn
el
par
de
programadores.
Se eligi una tarea de anlisis cuyo planteamiento tendra varias
alternativas.
Se establecieron los das de trabajo para realizar la prctica.
Ejecucin
Figura 36 Sprint 1 Pair Programming (1)

En la primera reunin participaba ms una de las dos personas, durante ese tiempo se explicaba e
indicaba la opcin de anlisis propuesta.
Evidencias en
video:http://www.youtube.com/watch?v=RTbkqlvqDLk&feature=related
Retrospectiva
El trabajo se realiz frente a la computadora.
- 94 -

Durante el tiempo de trabajo en pareja una de las dos personas no se sinti

libre de participar. Se plante volver hacer esta prctica obteniendo mayor
participacin de ambos miembros.
Se tuvo algunos inconvenientes por que la persona no tena suficiente

conocimiento para utilizar ciertas herramientas de diseo de software.
Se sugiere considerar el nivel de conocimiento de los miembros que
conformaran las parejas de programacin, de lo contrario realizar
capacitacin o induccin previa en el tema.
III. Sprint 3
Planificacin
Seleccionar las dos personas con un nivel de conocimiento adecuado
para conformar una pareja de programacin.
Establecer el orden de participacin de cada miembro.
Elegir un requerimiento que se encuentre en fase de prueba.
Ejecucin

La primera persona revisa el cdigo de la opcin elegida demostrando que funciona de acuerdo
al anlisis entregado.
- 95 -


La segunda persona revisa la opcin elegido para comprobar el funcionamiento, en este
momento se intercambian los roles.

Se logr tener un mismo ambiente para el equipo de desarrollo, de esta forma se podr compartir
los conocimientos y habilidades de cada uno.
Retrospectiva
Esta segunda vez result mejor la prctica de pair programmig, hubo una
participacin ms equitativa entre ambas personas.
- 96 -

Se pudo intercambiar los roles sin perder el enfoque, ya que la dos

personas contaban con el mismo conocimiento necesario. Existieron dudas
durante
la
sesin,
las
cuales
fueron
absueltas
por
los
mismos
programadores.
Se realiz la prctica en la computadora, donde se pudo navegar y mostrar

lo necesario.
Hubo necesidad de hacer correcciones, las cuales fueron realizadas y

probadas en el mismo momento, esto fue un buen indicio ya que de
realizarse el testing de esta forma, la fase de pruebas sera ms rpida.
Durante este sprint se habilit el ambiente para los miembros del rea de
desarrollo, lo cual aport en la realizacin de esta prctica que al parecer
indica un inicio de una nueva etapa en el rea.
3.3 Evaluacin de Resultados

Anlisis de las retrospectivas del sprint 2 y 3
Cada retrospectiva permiti conocer los resultados de la prctica anteriormente
ejecutada, la conformidad o no conformidad del equipo, y las evidencias que
eran mostradas por el exceso de tiempo establecido para la atencin de las
tareas, lo cual permita estar organizado para buscar constantemente
soluciones orientadas a satisfacer a los usuarios, entregar trabajo culminado
con calidad, hacer notar los problemas, proponer enmiendas, y animarlos a
encontrar sus propias soluciones, ayudando y fomentando a mantener el
entusiasmo del equipo a causa de los resultados favorables.
Retrospectiva del trabajo
El desarrollo de este trabajo ha permitido conocer cmo implementar las
prcticas de las metodologas giles de desarrollo de software, desde el marco
terico, seleccin, planificacin y ejecucin de las practicas aplicadas a la
realidad de nuestro mbito laboral, rescatando y apuntalando lo que considera
- 97 -

como positivo y desechando lo que no es aplicable, replanteando nuevas

metas y alternativas de solucin que se continan retroalimentando hasta llegar
al ideal de la implementacin.
- 98 -

CONCLUSIONES
1. La implementacin del tablero visual y/o por tarjetas result muy apropiada
para ordenar de forma visual y clara el proceso de atencin de las tareas
segn
nuestra
disponibilidad
de
recursos,
permitiendo
detectar
oportunamente y con evidencias los cuellos de botella que antes no eran

posibles de identificar desde su origen, lo que permite
resolver los
problemas con efectividad, y a fin de que posteriormente no se repitan.
2. Esta buena prctica, acompaada de la creatividad y motivacin de los

colaboradores permiti conocer y participar en la continua mejora del flujo
del proceso, encontrando soluciones prcticas, de corto plazo y con mnima
inversin, permitiendo atender con calidad, eficiencia y xito, a usuarios
frustrados y desesperados por ser atendidos, que en la actualidad, gracias
a ste mtodo, se muestran conformes con la eficacia de la solucin.
3. Basado en reuniones cortas, efectivas y precisas que permiten conocer la

evidencia de las trabas que impedan culminar con xito las tareas en el
tiempo establecido, y con ello disponer de la informacin oportuna y
necesaria para planear y proceder a tomar acciones que resuelvan los
problemas y hagan que en un futuro prximo esas mismas situaciones
puedan ser manejables.
4. Asimismo, todas estas acciones orientadas a encontrar soluciones

efectivas ha permitido conocer el flujo del proceso, e incorporar un espritu
y motivacin de trabajo en equipo, logrando una mayor comunicacin,
colaboracin y comprensin entre el equipo de desarrollo, y los usuarios
interesados en ser atendidos, haciendo ms agradable la atencin de las
tareas.
- 99 -

5. El uso del task board permiti que pudiramos consolidar todos los
proyectos que tiene a cargo el rea de desarrollo, inclusive las tareas no
planificadas que solicitan a travs del rea de soporte; se puede ver cul es
el objetivo que se quiere alcanzar a diario sin desviarse de lo ofrecido en
cada Sprint.
6. As mismo funciona como un radiador de informacin, lo cual mejora la

comunicacin del equipo, amplificando el feedback entre los miembros,
adicionalmente ayuda a que el equipo se mantenga enfocado en la
consecucin de resultados. Al ser la primera rea que practica esta nueva
metodologa nos convertimos en agentes de cambio.
7. La programacin en parejas nos dio buenos resultados ya que se demostr

que aplicando esta prctica los tiempos de entrega mejoran notablemente.
Las pruebas realizadas son de mayor calidad y confianza, ya que son
revisadas por dos personas, llevndose a cabo las pruebas unitarias y las
pruebas funcionales.
8. El intercambio de conocimiento y las alternativas de solucin a

inconvenientes presentados son resueltos por los miembros del equipo.
9. En General, la experiencia de haber implementado las prcticas giles en

nuestros centros laborales ha sido un primer comienzo para cambiar la
forma de conducir los proyectos, desechando formas o mtodos que no
generan valor ni retorno de inversin y ms bien adoptando estas nuevas
metodologas para desarrollo de software.
10. Para obtener un software de calidad aplicando las teoras giles de

desarrollo es importante seguir muy ceidamente los valores y principios
giles para llegar al objetivo deseado. Las metodologas giles reducen el
coste de desarrollo y mantenimiento del software.
- 100 -

CONCLUSIONES
1. Con la ayuda del BPM se puede obtener un mapa claro del proceso real de
la gestin de cobranza en la etapa de tele-cobranza, as como de las reas
y los proveedores externos involucrados en el proceso.
2. Visualizacin clara y simple de las actividades del proceso a mejorar y

automatizar.
3. Actualmente los procesos, personas y tecnologa son los principales

determinantes del costo, cronograma y calidad de un producto.
4. La evaluacin de las tres reas del proceso (PP, PCM y REQM)

permitieron obtener una oportunidad para corregir o modificar los procesos
de un rea de desarrollo de software que han perdido su desempeo en el
tiempo.
5. Implementar nuevas tcnicas o metodologas que ayuden a los
colaboradores a aumentar la productividad, efectividad y utilidad de la
empresa.
6. Continuar con la poltica de mejora continua en los procesos de desarrollo

de software y servicios.
7. Incorporar cambios con rapidez y en cualquier fase de un proyecto de

desarrollo.
8. Ser capaces de gestionar los proyectos de una forma ms gil.
9. Los equipos pequeos y formados por miembros de diferentes disciplinas

consiguen mejores resultados implementando las metodologas giles.
- 101 -

10. El desarrollo de este trabajo ha permitido conocer cmo implementar las

prcticas de las metodologas giles de desarrollo de software, desde el
marco terico, seleccin, planificacin y ejecucin de las prcticas
aplicadas a la realidad de nuestro mbito laboral.
- 102 -

GLOSARIO DE TRMINOS
Backbone: Se refiere a las principales conexiones troncales de Internet que

est compuesta de un gran nmero de routers comerciales, gubernamentales,
universitarios y otros de gran capacidad interconectados que llevan los datos a
travs de pases, continentes y ocanos del mundo mediante cables de fibra
ptica.
Ciclo: Es el periodo de tiempo en el que se gestionan las cobranzas dentro de
un mes.
Cliente corporativo: Es una segmentacin que tiene un cliente.
Etapa de cobranza: Se llama as a los procesos por los cuales pasa un recibo
una vez iniciada a gestin de cobranza.
Just in time: mtodo justo a tiempo.
Stateholders: Personas quienes pueden afectar o son afectados por las
actividades de una empresa.
Lneas de tiempo: Son los periodos de tiempo que tiene cada etapa de
cobranza.
Negocio: Es un nmero de contrato asignado al cliente que se origina por una
venta de un producto.
Reclamo: Es el hecho por el cual un cliente puede suspender la gestin de
cobranza de un recibo para solicitar la revisin de la informacin
correspondiente a la deuda.
Recaudacin: Es el proceso a travs del cual se importa las cobranzas
realizadas en los bancos, OL y Americatel.
Segmentacin: Es el proceso a travs del cual se clasifica al cliente por
tamao.
Tele-cobranza: Proceso a travs del cual se realiza las llamadas a los clientes
con recibos pendientes.
Feedback: Reatroalimentacin: Conjunto de reacciones o respuestas que
manifiesta un receptor respecto a la actuacin del emisor, lo que es tenido en
cuenta por este para cambiar o modificar su mensaje.
- 103 -

SIGLARIO
AMP: Americatel
ANI: Es un nmero de telfono.
ANI de facturacin: Es el nmero de telfono con el cual se realiza la
facturacin.
ANI de asociado: Es el nmero de telfono con el cual se realiz la
inscripcin.
ERP: Entreprise resource planning
LD: Servicio de larga distancia.
NGN: Servicio de nueva generacin de negocios.
NOC: Centro de operaciones de Americatel.
PYMES: Pequea y mediana empresa
SAC: rea de servicio de atencin al cliente en Americatel.
TI: Tecnologa de Informacin
WiMAX: Worldwide Interoperability for Microwave Access - Interoperabilidad
mundial para acceso por microondas): Es una norma de transmisin de datos
que utiliza las ondas de radio en las frecuencias de 2,3 a 3,5 Ghz. que permite
la recepcin de datos por microondas y retransmisin por ondas de radio.
- 104 -

BIBLIOGRAFA
1.
KANBAN: Successful Evolutionary Change for Your Technology Business

/ David J. Anderson.
2.
Kanban y Scrum, Obteniendo lo mejor de ambos" de Henrik Kniberg y

Mattias
Skarin.
http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINA
L-printed.pdf.
3.
Flexibilidad con SCRUM.

http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf.
4.
Aplicando SCRUM.
http://everac99.wordpress.com/2010/06/18/%C2%BFque-es-scrum/
5.
Que es SCRUM.
http://www.aplicandoscrum.com/category/gestion-visual/
6.
Extreme programming explained: embrace change / Kent Beck with

Cynthia Andres.
7.
Programacin en Pareja.
http://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja
8.
Arquitectura, Ingeniera y Desarrollo de Software.

http://carlossantos.wordpress.com/category/programacion-extrema/
- 105 -

ANEXOS
7.1 Plantillas para el proceso: Project Planning (PP)
SP 1.1: Plantilla de WBS
Figura 40 Plantilla WBS.doc
- 106 -

SP 1.2 SP 1.4: Plantilla COCOMO: estima el tamao del producto:
Paso 1 - Estimar Puntos de Funcin (PF)

Estimar los Elementos de Funcionalidad (EF)
No modificar las 7 primeras filas de esta pgna
No Elemento de Funcionalidad (EF)
1 Actualizar Clientes (agregar)
2 Actualizar Clientes (modificar)
3 Actualizar Clientes (eliminar)
4 Actualizar Clientes (imprimir)
5 Mostrar movimiento en KARDEX
6 Consultar estado de cuenta
7 Actualizar Vendedor (agregar)
8 Actualizar Vendedor (modificar)
9 Actualizar Vendedor (eliminar)
10 Actualizar Vendedor (imprimir)
TEF
EE
EE
EE
SE
SE
CE
EE
EE
EE
SE
ED
18
18
1
18
6
1
7
7
1
7
AR Nivel
6
A
6
A
9
P
6
A
2
P
1
B
3
P
3
P
2
B
3
P
Nivel para las EE - Entradas Externas

Archivos
Elementos de Datos (ED)
Referenciados (AR) 1-4
5-15
0-1
Bajo
Bajo
2-3
Bajo
Promedio
4+
Promedio
Alto
16+
Promedio
Alto
Alto
Nivel para las SE - Salidas Externas y CE - Consultas Externas

Archivos
6-19
20+
0-1
Bajo
Bajo
Promedio
2-3
Bajo
Promedio
Alto
4+
Promedio
Alto
Alto
Figura 41 Estimar los elementos de funcionalidad

Paso 2 - Estimar Puntos de Funcin (PF)
Estimar los Archivos Lgicos (AL)
No modificar las 7 primeras filas de esta pgna
No Nombre del Archivo Lgico (AL)
1 Factura
2 DetalleFactura
3 Producto
4 Cheque
5 Boucher
6 Cuenta
7 Funcin
8 Peso
9 Categoria
10 Familia
TAL
ALI
ALI
ALI
ALI
ALI
ALI
ALI
ALI
ALI
ALI
ED
10
12
56
6
9
20
3
4
15
14
AR Nivel
1
B
1
B
1
P
1
B
1
B
1
B
1
B
1
B
1
B
1
B
Figura 42 Estimar los archivos lgicos
- 107 -
Nivel para Archivos Lgicos Internos (ALI) y Externos (ALE)

Archivos
20-50
51+
0-1
Bajo
Bajo
Promedio
2-5
Bajo
Promedio
Alto
6+
Promedio Alto
Alto

Paso 3 - Estimar los Factores de Ajuste (FA)
No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Sigla
DCM
DDP
PER
HUC
TRT
ODE
EUE
OUP
CPR
REU
IEA
OFE
MSI
FCH
Factores de Ajustes
Nivel
Comunicacin de Datos
2
Procesamiento de Datos Distribuidos
3
Rendimiento
1
Restricciones sobre la Configuracin
4
Ratio de Transacciones
0
Entrada de Datos en Lnea
3
Eficiencia del Usuario Final
2
Actualizacin en Lnea
3
Procesamiento Complejo
3
Reusabilidad
3
Facilidad de Instalacin
3
Facilidad Operacional
5
Mltiples Sitios
2
Facilidad de Cambio
2
Total Factores de Ajuste (TFA)
36
Valor del Factor de Ajuste (VFA) = 0.65 + 0.01 * TFA 1.01
Figura 43 Estimar factores de ajuste
Paso 4 - Ajustar los Puntos de Funcin (PFA)

No modificar ninguna fila, columna o elemento de esta pgina. Se calculan automticos
Tipo de Punto de Funcin
BAJO
PROMEDIO
ALTO
(TEF/TAL)
Conteo Peso Conteo Peso Conteo Peso
Subtotal
EE - Entradas Externas
1
3
3
4
2
6
27
SE - Salidas Externas
0
4
2
6
1
7
19
CE - Consultas Externas
1
3
0
4
0
6
3
ALI - Archivos Lgicos Internos
9
7
1
10
0
15
73
ALE - Archivos Lgicos Externos
0
5
0
7
0
10
0
Puntos de Funcin Desajustados (PFD)
122
Puntos de Funcin Ajustados (PFA)
123.22
Calcular Puntos De Funcin
Figura 44 Ajustar los puntos de funcin
Paso 6 - Estimar factibilidad econmica para el proyecto
Variable
MD - Modo de Desarrollo
ESF - Esfuerzo
TDES - Tiempo de Desarrollo
CH - Cantidad de Hombres (promedio)
CHM - Costo por Hombre al Mes (promedio)
C - Costo del Proyecto
Valor
1
9.47
5.87
2
1100
10 418.29
Figura 45 Estimar factibilidad econmica
- 108 -
hombres-mes
meses
hombres
dlares
dlares

Paso 7 - Distribuir la Factbilidad Econmca para el proyecto
Distribucin para las fases del proyecto

ESF
Fase
Valor (%)
Concepcin
0.47
5
Elaboracin
1.89 20
Construccin
6.16 65
Transicin
0.95 10
Total
9.47 100
TDES
Valor (%)
0.59 10
1.76 30
2.94 50
0.59 10
5.87 100
(Fuente: Philippe Kruchten A Rational Development Process )
Distribucin para las etapas del proyecto

ESF
Etapa
Valor (%)
Modelado del Negocio
0.47
5
Requerimientos
1.42 15
Anlisis y Diseo
2.37 25
Implementacin
3.31 35
Prueba
0.47
5
Implantacin
1.42 15
Total
9.47 100
TDES
Valor (%)
0.88 15
0.88 15
1.47 25
1.76 30
0.29
5
0.59 10
5.87 100
(Fuente: Philippe Kruchten A Rational Development Process )
Distribucin para los cursos de la carrera

ESF
Curso
Valor (%)
Proyecto Informtico 1
4.74 50
Proyecto Informtico 2
3.79 40
Tesis
0.95 10
Total
9.47 100
TDES
Valor (%)
2.35 40
2.35 40
1.17 20
5.87 100
Figura 46 Distribuir la factibilidad econmica
- 109 -

SP 1.3: Plantilla de Ciclo de vida

Cronogram a de Desarrollo - Resum en
Etapa
Responsable
SYPSA
Semanas
CLIENTE 1 2
Levantamiento de Informacin
GP, JI, JD
GS, US
Aprobacin de Requerimientos
GP, JI, JD
GS, US
Diseo de Programas
JD, P1, P2
Aprobacin de Diseo
GP, JD
Programacion
JD, P1, P2
Pruebas con Usuario
JD, P1, P2 US
Depuracion
JD, P1, P2 US
Entrega
GP, JD
3 4 5 6
7 8 9 10 11 12 13 14 15 16 17
D1
GS, US
D2
GS, US
D3
D4
Figura 47 Ciclo de Vida.doc
SP 2.1: Plantilla para Estimar el presupuesto

a. Calculo del presupuesto
Variables en costos (Und)
Viaticos
200.00
Viajes
1228.00
Maquinas
310.00
PMO
5000.00
Porcentajes
Porcentaje Contingencia
Porcentaje Gestion
Porcentaje utilidad
Gastos Generales
20.00%
25.00%
8.00%
1.682
Variables por dia

Capacitacion
Cantidad Viajes
Cantidad de maquinas
Tipo de cambio
Figura 48 Variables a considerar.xls

Presupuesto Del Proyecto
Detalles
Costos (S/.)
Montos Variables
Inicializacion
2,856
Analisis y diseo
7,574
Ambiente y Desarrollo
1,919
Desarrollo
17,636
Pruebas y Planeamiento
15,746
Deployment
3,698
Costos total Variables
49,428
Montos fijos
Viticos
4,000
Viajes
1,228
PMO (Pago Personal y servicio)
50,000
Maquinas
27,900
Costo Total Fijos
83,128
Costos Totales
132,556
Reserva de Contingencia (20%)
26,511
Linea Base
159,067
Riesgo de Gestion (25%)
39,767
Presupuesto
198,834
Utilidad (8%)
15,907
Monto total
214,741
Costo Proyecto
214,741
Figura 49 Calculo del presupuesto.xls
- 110 -
20
1
9
3.1
18

b. Planilla Lista de verificacin
LISTA DE VERIFICACIN DE ESTIMACIN DE COSTOS

Nombre del Proyecto:
Preparado por:
Fecha:
Asegurarse que todos los recursos necesarios sean tomados en consideracin:
Administracin del Proyecto
Personal
Materiales
Proveedores
Viajes
Pagos a consultores y otros servicios profesionales
Diversos (traslados, copias, mensajeras, etc.)
Plan de contingencia
Inflacin
Recomendaciones
Sea lo ms especfico posible, usar estimaciones, mtricas para cuantificar los recursos que el
proyecto requerir.
Expresar los costos estimados en unidades monetarias
Asegrese que las actividades consideradas en el proyecto, tienen costos potenciales

involucrada en el proyecto, cuando considere un potencial costo
Asegurarse que las estimaciones o mtricas muestren cantidades realistas para cada item de
costo, tales como nmero de horas/das por alquiler de equipo, nmero de trabajadores
requeridos para realizar la construccin en horas/das y as por el estilo.
Figura 50 Plantilla de lista de verificacin para estimacin de costos.doc
- 111 -

c. Plantilla para especificacin de hitos del proyecto

HITOS DEL PROYECTO

Preparado por:
Fecha:
Hitos
WBS
Fecha
Comentarios:
Revisado por:
Fecha:
Autorizado por:
Fecha:
Figura 51 Plantilla para Hitos del Proyecto.doc
- 112 -
Descripcin

d. Plantilla Cronograma detallado

CRONOGRAMA DETALLADO
Inicio
Tarea
SEMANA
Responsab H i
Lanzam iento
FASE 1 - LEVANTAMIENTO DE INFORMACIN
FASE 2 - ANALISIS Y DISEO
FASE 3 - APROBACIN DE DISEO
FASE 4 - DESARROLLO Y PROGRAMACION
FASE 4 - PRUEBAS Y CONTROL DE CALIDAD
FASE 5 - PUESTA EN MARCHA Y SOPORTE
Figura 52 Plantilla del cronograma detallado.xls
- 113 -

SP 2.2: Plantilla de Registro de Riesgos
REGISTRO DE LOS RIESGOS DEL PROYECTO

Preparado por:
Fecha:
NOTA: Enumere todos los riesgos identificados del proyecto dentro de cada categora. Conserve esta informacin
para su referencia a travs del proceso de la gerencia de riesgo:
Riesgos tcnicos
1.
2.
3.
4.
5.
Riesgos de gestin
1.
2.
3.
4.
5.
Riesgos organizacionales
1.
2.
3.
4.
5.
Riesgos externos
1.
2.
3.
4.
5.
Figura 53 Plantilla de registro de los riesgos.doc
EVALUACIN CUALITATIVA DE LOS RIESGOS DEL PROYECTO

Preparado por:
Fecha:
Riesgo
Actual
Respuesta
Probabilidad Impacto Prioridad al riesgo
Accin a tomar
0
0
0
0
0
0
0
0
0
Figura 54 Evaluacin cualitativa de los riesgos.xls
- 114 -
Nuevo
Probabilidad Impacto Prioridad
0
0
0
0
0
0
0
0
0

SP 2.3: Plan de datos
Procedimiento para la Seguridad Lgica, accesos y confidencial de la informacin

producida
Todos los involucrados en el proyecto debern sujetarse a las polticas de seguridad establecidas.
Se asignar por usuario un espacio limitado para el almacenamiento de la informacin vincula con
la actividad laboral en los servidores de archivos autorizados por la Jefatura de Desarrollo.
Est restringido el almacenamiento de informacin que no guarde ninguna relacin o vnculo con
el proyecto asignado.
Se debern establecer los niveles de acceso para los miembros del proyectos.
a. De Aplicacin por parte del Encargado del rea de Soporte
Establecer las medidas de seguridad y confidencialidad que se aplicar en la produccin,

generacin, emisin, publicacin, intercambio, distribucin y transmisin de datos e informacin
automatizada relacionada con el proyecto
Mantendr el derecho de los usuarios a la confidencialidad del correo electrnico.
b. De Aplicacin por parte del Usuario
Deber mantener el respaldo de la informacin requerida para su trabajo, incluyendo en ello, el

respaldo de los mensajes de correo electrnico que requiere conservar, para lo cual deber
archivar dicha informacin en el directorio asignado por el Encargado de Soporte ubicado en el
servidor principal de Empresa.
Los usuarios tendrn derecho a la confidencialidad de su informacin, con la salvedad de

aquellos casos en que se detecten acciones que se pongan en riesgo la seguridad de la red de
datos y/o fuga de informacin.
Deber utilizar la cuenta asignada, para el acceso a los servicios a los que tenga autorizacin.
Figura 55 Poltica Plan de Datos.doc
- 115 -

Procedimiento para Gestin de Cambios

Es la evaluacin y planificacin del proceso de cambio para asegurar que, si ste se lleva a
cabo, se haga de la forma ms eficiente, siguiendo los procedimientos establecidos y
asegurando en todo momento la calidad y continuidad del servicio TI.
CONTROL DE VERSIONES
Versin Hecha por
Revisada por
Aprobada por
Fecha
Motivo
PLAN DE GESTIN DE CAMBIOS

Nombre del proyecto
NOMBRE DEL ROL
PERSONA ASIGNADA
RESPONSABILIDADES
NIVELES DE AUTORIDAD
TIPOS DE CAMBIOS: DESCRIBIR LOS TIPOS DE CAMBIOS Y LAS DIFERENCIAS PARA TRATAR CADA UNO DE ELLOS.
PROCESO GENERAL DE GESTIN DE CAMBIOS: DESCRIBIR EN DETALLE LOS PROCESOS DE LA GESTIN DE CAMBIOS,
ESPECIFICANDO QU, QUIN, CMO, CUNDO Y DNDE
SOLICITUD DE CAMBIOS:
Captar las solicitudes y preparar el
documento en forma adecuada y
precisa.
Poltica Plan de Datos 2/3.doc
- 116 -

VERIFICAR SOLICITUD DE
CAMBIO: Asegurar que se ha
provisto toda la informacin
necesarioa para hacer la evaluacin
EVALUAR IMPACTOS:
Evala los impactos integrales de
los cambios
TOMAR DECISIN Y
REPLANIFICAR: Se toma la
decisin a la luz de los impactos,
(dependiendo de los niveles de
autoridad), se replanifica segn sea
necesario
IMPLANTAR EL CAMBIO:
Se realiza el cambio, se monitorea
el progreso, y se reporta el estado
del cambio
CONCLUIR EL PROCESO
DE CAMBIO: Asegura que todo
el proceso haya sido seguido
correctamente, se actualizan los
registros
PLAN DE CONTINGENCIA ANTE SOLICITUDES DE CAMBIO URGENTES: DESCRIBIR EL PLAN DE CONTINGENCIA PARA
ATENDER SOLICITUDES DE CAMBIO SUMAMENTE URGENTES QUE NO PUEDEN ESPERAR A QUE SE RENA EL COMIT DE CONTROL DE
CAMBIOS.
HERRAMIENTAS DE GESTIN DE CAMBIOS: DESCRIBIR CON QUE HERRAMIENTAS SE CUENTA PARA OPERAR LA GESTIN DE
CAMBIOS.
SOFTWARE
PROCEDIMIENTOS
FORMATOS
OTROS
Poltica Plan de Datos 3/3.doc
- 117 -

SP 2.4: Plantilla de Requerimiento de Recursos

Plantilla de Requerimiento de Recursos
Preparado por:
Fecha
Entregable
Actividad
Recurso
Cantidad
%
Desde
asignacin
Figura 56 Plantilla de Requerimientos de Recursos.doc
- 118 -
Hasta
Observaciones

SP 2.5: Plantilla de plan de capacitacin

Plan de Capacitacin
Preparado por:
Fecha:
Justificacin del Proyecto:
La necesidad del negocio que dio origen o necesidad del proyecto.
Descripcin del producto:
Un breve resumen de la descripcin del producto
Seleccionar las necesidades

especficas de capacitacin:
Determinar los recursos
de capacitacin 1.
de capacitacin 2....
de capacitacin n
Desarrollar material de
formacin:
Indicar material que se requiere para la capacitacin
Obtener instructores
calificados:
Realizar capacitacin:
Periodo inicio fin
Evaluar la efectividad del

entrenamiento:
Actualizar la formacin
recibida a cada recurso de
la organizacin:
Figura 57 Plantilla del plan de capacitacin.doc
- 119 -

SP 2.6: Plantilla de Acta de Constitucin del Proyecto
Acta de Constitucin del Proyecto

(Project Charter)
A. Informacin General
Nombre del Proyecto
Fecha de Preparacin
Patrocinador:
Fecha de
Modificacin:
Autorizado por:
Preparado por:
B.
Descripcin del producto o servicio del Proyecto
Descripcin narrativa de los productos y servicios que deben ser suministrados por el proyecto.
C.
Alineamiento del Proyecto

Consideraciones de la Organizacin
D.
Propsitos del Proyecto
Objetivos del Proyecto

Objetivos del Proyecto
Costo
Plazo
Calidad
Alcance
E.
Alcance y Extensin del Proyecto
Principales Entregables del Proyecto.
Figura 58 Plantilla del Acta de constitucin del proyecto.doc
- 120 -

Principales Fases del Proyecto.
Stakeholders claves.
Restricciones.
Asunciones
Lmites del proyecto
F.
Factores Crticos de xito del Proyecto
G.
Planeamiento Inicial del Proyecto al alto nivel
Estimacin de recursos requeridos:
Costo Estimado del Proyecto:
Beneficios Estimados:
Estimacin de Fechas a Programar:
Plantilla del Acta de constitucin del proyecto 2/3.doc
- 121 -

Fecha de inicio:
Fecha de trmino:
H.
Autoridad del Proyecto
Autorizacin
Gerente del proyecto
Nombre:
Comit de Seguimiento (Direccin)
I.
Integrantes del equipo del proyecto, Roles y
Responsabilidades
1.
2.
3.
4.
5.
J.
Firmas
Nombre/Funcin
Firma
Plantilla del Acta de constitucin del proyecto 3/3.doc
- 122 -
Fecha

SP 3.1; GP 2.10: Plantilla acta de reunin donde se documentan la

dependencia con otros planes y otros acuerdos
CT030: Acta de Reunin

Nmero:
Proyecto / asunto:
Fecha de reunin:
Asistentes:
Agenda
Puntos tratados:
En agenda
Fuera de agenda
Puntos pendientes:
Figura 59 Plantilla de Acta de Reunin
- 123 -
24/10/a
Pg. 1

SP 3.3: Plantilla relacin de los miembros del proyecto
Re la ci n de mi em br os del pr o ye c t o
Reunin de Trabajo
Fecha: DD/MM/YYYY
Proyecto:
Asistentes:
Cargo
Abrev.
Funciones
Usuario lder principal
ULP
Usuario administrador
AD
Usuario lder mdulo 1
ULM2
Usuario lder mdulo 2
ULM1
Usuario
US
Coordinador de sistemas
CS
Jefe de Desarrollo
JD
Analista
ANA
Programador
PGM
Tester
QA
Figura 60 Plantilla de relacin de miembros del proyecto.doc
- 124 -
Firma

GP 2.1; GP 2.2; GP 2.3; GP 2.4; GP 2.5; GP 2.7, G 2.9: Poltica para

Planificacin de Proyectos
POLTICA PARA PLANIFICACIN DE PROYECTOS
Seccin 1 - Resumen Ejecutivo (Qu como mnimo incluya):
El nombre del proyecto

Nombre del cliente
Todas las instalaciones involucradas
Una historia breve del proyecto
Una descripcin del proyecto
Una descripcin de la solucin que ser entregada
Cualquier otra informacin relevante al programa
Seccin 2 - Introduccin
Seccin 2.1 - Propsito y objetivos
Brevemente describa las necesidades del negocio del cliente y sus problemas y cmo sern resueltos
por el proveedor de la solucin.
Seccin 2.2 - Estrategia del proyecto
Describa cmo se alcanzarn los objetivos del proyecto.

Documente las fases del ciclo de vida posibles. Los proyectos se pueden estructurar por fases, como
Iniciacin, Planificacin, Ejecucin y Cierre.
Identifique los hitos principales.
Seccin 2.3 - Alcance
Describa los lmites del proyecto. El alcance circunscribe las actividades o funciones a realizar.
Brevemente describa qu procesos del cliente, instalaciones y locaciones se emplearn. Documento
aquello que el proyecto no tendr en cuenta.
Seccin 2.4 - Entregables o productos
Describa la lista de los principales productos del proyecto, como los componentes del servicio,
documentos, etc. Cubra componentes como hardware, software, entrenamiento y consultora.
Seccin 2.5 - Interfaces organizacionales
Describa todas las interfaces organizacionales que intervienen en el proyecto como clientes, terceras
partes, de clientes de la organizacin del cliente, etc. Adicionalmente, identifique las interfaces
internas del cliente y su organizacin que sean relevantes.
Figura 61 Poltica para Planificacin de Proyectos.doc
- 125 -

Seccin 2.6 - Documentos de referencia
Incluya ttulos, fechas y revisiones de los documentos que pertenezcan al proyecto.

Seccin 3 - Estructura del proyecto
La identificacin clara de la estructura del proyecto facilitar la planificacin y las comunicaciones.

Tome en cuenta la organizacin y estructura del proyecto, roles y responsabilidades. Use una o ms
grficas para bosquejar la organizacin del proyecto. Incluya al cliente, proveedores de la solucin
y terceras partes.
Seccin 3.1 - Roles y responsabilidades
Identifique todos los miembros del proyecto y equipos de proyectos relacionados, al igual que otras
personas claves. Describa roles y responsabilidades especficos. Aclare los roles gerenciales versus
los roles de personal tcnico. Incluya los nmeros telefnicos y direccin de correo electrnico.
Tambin incluya los roles del usuario final en cualquier actividad que represente una dependencia
para el proyecto e indique sus responsabilidades.
Seccin 3.2 - Proyectos integrantes del proyecto, relaciones y dependencias
Identifique todos los gerentes / lderes de proyectos participantes tanto del cliente como del
contratista. Incluya los proyectos gerenciados por el cliente cuando sea apropiado, por ejemplo, si
se comparten coberturas diferentes de alcance de un proyecto general ms amplio. Revise todos los
proyectos integrantes para identificar interdependencias y asunto interdisciplinarios.
Seccin 3.3 - Cmo trabajar el equipo del proyecto
Muestre las relaciones de informes entre los miembros del proyecto, tanto para el cliente como para
el contratista. Defina los roles de supervisin. Describa las reuniones proyectadas regularmente,
procedimiento de comunicaciones, reportes y otros procedimientos. Determine quines sern las
personas a contactar en las instalaciones del cliente.
Seccin 3.4 - Roles del cliente
Identifique el personal del cliente que se comunicar con el personal del contratista e indique los
medios de comunicacin (verbal, escrita) que se emplearn. Si el cliente exige reportes o reuniones
formales, descrbalos.
Seccin 3.5- Rol de terceras partes
Describa cmo participarn las terceras partes dentro del marco del proyecto.
Seccin 3.6 - Intervencin de ejecutivos y aprobaciones, relaciones ejecutivas
Poltica para Planificacin de Proyectos 2/6.doc
- 126 -

Defina cmo intervienen los ejecutivos o gerentes funcionales de las partes participantes. Defina las
aprobaciones necesarias para los productos principales del proyecto. Enumere, desde la perspectiva
del usuario, los nombres de los ejecutivos de las partes y describa cmo se espera que apoyen el
proyecto.
Seccin 3.7 - Proceso de control de cambios
Defina el proceso de control de cambios que se usar para controlar los entregables del proyecto.
Defina los niveles de responsabilidad para la aprobacin de cambios.
Seccin 3.8 - Tcnicas y herramientas de gestin de proyectos
Describa las tcnicas que se emplearn para administrar el proyecto.

Seccin 3.9 - Proceso de comunicacin
Asegure comunicaciones frecuentes entre las partes asociadas con el proyecto para evitar el fracaso
del proyecto. Planee los enlaces de flujos de informacin internas y externas al proyecto y
determine qu tan frecuentemente se requiere la comunicacin.
Seccin 4 - Actividades y Estimados
Aqu se deben definir las actividades y estimados principales del proyecto.

Seccin 4.1 - Tareas, subtareas, actividades y esfuerzos respectivos y habilidades para el proyecto e
integrantes
Para cada fase del proyecto, defina la estrategia, prerrequisitos, tareas, actividades externas y
criterios de xito.
Para cada tarea, proporcione una descripcin, el recurso y la habilidad o conocimiento requeridos,
estime el esfuerzo y el nombre de la persona responsable.
De modo similar, designa las subtareas para cualquier tarea que se ejecutan enteramente a nivel del
proyecto. Las subtareas de las tareas ejecutadas por proyectos integrantes sern definidas en los
proyectos respectivos.
Seccin 5 - Recursos
Proporcione los recursos necesarios y disponibles para el proyecto.

Seccin 5.1 -Personal
- 127 -

Presente una tabla que muestre los recursos humanos asignados, sus roles, organizaciones y tiempo
asignado. Resuma la cantidad total de das-hombre y otros gastos por fases, haga una referenciacin
cruzada entre proyectos e identifique las fuentes de los estimados.
Seccin 5.2 - Equipos
Describa los requerimientos logsticos para acceso telefnico, fotocopiadoras, equipos especiales y
equipos de cmputo requeridos.
Seccin 5.3 - Instalaciones
Describa las necesidades para espacio en el sitio de trabajo, espacio de oficina u otra necesidad.
Seccin 5.4 - Otros
Proporcione una lista de requerimientos especiales como accesos a pisos, cuentas de correo
electrnico, etc.
Seccin 6 - Cronograma
Desarrolle el cronograma del proyecto sobre la base de los estimados de tiempo y la secuencia
requerida y duracin de las tareas, subtareas y actividades.
Seccin 6.1 - Cronograma por fase y tareas principales del proyecto y proyectos relacionados
Detalle el cronograma del proyecto, fase por fase, incluyendo las tareas principales del proyecto y
proyectos relacionados.
Seccin 6.2 - Lista de Hitos
Detalle los hitos principales del proyecto e indique el estado de estos en cualquier momento dado
durante el proyecto.
Seccin 7 - Revisiones y aprobaciones
Esta seccin puede ser la ms crtica del Plan del proyecto. Todo el personal que interviene debe
entender el propsito y cronograma del proyecto como tambin los procedimientos que se usarn y
la reparticin de responsabilidades.
Seccin 7.1 - Revisiones del proyecto
Establezca un calendario de revisiones para el proyecto que satisfaga las necesidades de todas
partes. Provea detalles suficientes para anunciar y preparar las revisiones y agendas, como
objetivos, participantes, directores, asuntos a tratar, distribucin de los informes de revisin y
disposicin de los materiales de revisin.
- 128 -

Seccin 7.2 - Aprobaciones de documentos del proyecto
Describa el proceso de aprobaciones (incluyendo nivel de aprobacin, organizacin y

procedimientos) dentro de la firma contratista, la empresa cliente y terceras partes.
Seccin 7.3 - Transiciones entre fases
Defina los criterios y procesos para realizar las transiciones entre las fases.
Seccin 8 - Dependencias del proyecto, riesgos y contingencias
Revise y valore los riesgos y dependencias de los proyectos integrantes y del proyecto total. Resalte
los riesgos que queden fuera del control de los miembros del equipo del proyecto. Discuta los
planes de contingencia para mitigar la ocurrencia de los riesgos.
Seccin 8.1 - Dependencias hacia proyectos y eventos
Discuta las actividades sobre las cuales el equipo del proyecto tiene poco control. Describa y
discuta el impacto de las actividades que se retrasen o fallen. Discuta la sensibilidad que presenta el
proyecto general hacia esos eventos. Explique las medidas de mitigacin de riesgo que se tomarn.
Seccin 8.2 - Riesgos y contingencias
Cules son los riesgos tcnicos y administrativos? Cul es la probabilidad de ocurrencia de los
eventos de riesgo? Cmo se puede mitigar la posibilidad de falla por esos riesgos? Se han
desarrollado los planes de reduccin de riesgos? Qu planes de contingencias se tienen? Se cuenta
con fondos de contingencia?
Seccin 8.3 - Proceso de solucin de problemas
Describa cmo se identificarn, clasificarn, priorizarn, escalarn y resolvern los problemas.

Tambin identifique los mecanismos de comunicacin y rutas y responsabilidad de resolver
problemas para el proyecto y cada proyecto integrante.
Seccin 8.4 Seguimiento y Control
Realizar un seguimiento de tareas y esfuerzos en la consecucin de proyectos. El proceso de captura

de datos para el Seguimiento y Control debe hacerse de forma peridica y en periodos de tiempo
pequeos para obtener mayor detalle en los resultados y tomar las acciones pertinentes de forma
rpida y eficaz.
Seccin 8.4 Aseguramiento de la Calidad
Realizar la revisin de las actividades y documentacin producida durante la etapa de planificacin,

as como el cumplimiento de las polticas establecidas para tal fin; se recomienda que el grupo o
- 129 -

persona asignada para estas auditoras no formen parte del proyecto a revisar y posteriormente
realice las observaciones y recomendaciones que deban ser mejoradas.
Procedimiento de revisin y listas de verificacin
Procedimiento de revisin
La informacin contenida en el Plan del proyecto debe presentarse de un modo conveniente para
revisin de la Direccin del Proyecto. Cualquier interrogante detallado que requiera mayor
investigacin se debe resolver antes de la revisin, de ser posible. Cualesquier cambios convenidos
sern registrados.
La Direccin por parte del contratista acordar y aprobar los requerimientos de recursos, hitos
crticos y riesgos del proyecto y la administracin de estos.
Lista de verificacin
La siguiente lista de verificacin se puede usar para revisar si el Plan del Proyecto est completo:
Las afirmaciones en la Introduccin, Seccin 2, estn alineadas con los objetivos subyacentes
del proyecto.
Las actividades de la seccin 4, Actividades y Estimados, cubren completamente los objetivos
fijados en la seccin 2 y cumplen con los entregables requeridos.
El tipo y cantidad de entregables se ha definido.
Todos los recursos mencionados en la seccin 6, Recursos, estn en concordancia con los
ltimos compromisos.
Cada miembro del equipo ha ledo y aprobado el Plan del Proyecto.
El cronograma ha sido convenido y est en concordancia con los compromisos de recursos.
Los hitos han sido convenidos por el cliente y el contratista.
Se incluyen todos los planes apropiados.
Las dependencias del proyecto estn alineadas con el plan de recursos.
Se han identificado las dependencias del proyecto hacia los usuarios finales y se cuenta con
planes de contingencia y eventos activadores.
Los riesgos adicionales se han comunicado a las personas que intervienen. Por ejemplo, los
riesgos con recursos se han comunicado a los gerentes de los recursos.
Cualquier asunto pendiente ha sido resuelto, se ha identificado el riesgo o se cuenta con un
procedimiento para resolverlo.
El plan se puede poner en operacin tan pronto sea aprobado.
Todas las participaciones del cliente se han comunicado al cliente y han sido entendidas
- 130 -

GP 2.8: Plantillas para el seguimiento y control de tareas

SEGUIMIENTO Y CONTROL DE TAREAS
Nombre del proyecto:
Estado actual del proyecto:
Estado esperado del proyecto

Tareas sin finalizar
Ciclo de vida del Nombre de tareas

proyecto
Grado de avance % Horas gastadas
Horas
planificadas
Desviacin
Horas
planificadas
Desviacin
Horas totales:
Tareas finalizadas
Ciclo de vida
Nombre de tareas
Fecha fin
Horas gastadas
Horas totales:
Otros temas:
Hitos (Entregables) finalizados
Nombre
Fecha entrega
Fecha planificada
Figura 62 Plantilla para el Seguimiento y control de tareas.doc
- 131 -
Desviacin
(das)

GP 2.9: Lista de verificacin para evaluar la Adherencia del Proyecto

Listas de Verificacin para el Control de Calidad
Preparado por:
Fecha:
Auditor:
Lista de Verificacin de las actividades realizadas durante la Planificacin
Puntos de control
Conforme
Observado
Comentarios
Realizado por:
Fecha:
Figura 63 Plantilla Lista de verificacin para evaluar la Adherencia del Proyecto.doc
- 132 -

7.2 Plantillas para el proceso: Requirements Management (REQM)

SP 1.1: Solicitud de Requerimiento
Nro.
<Correlativo asignado por Sistemas>
SOLICITUD DE REQUERIMIENTO
Recibido por:<Nombre>
Fecha: 16.08.11
Persona que recibe el requerimiento de servicio,
I. SOLICITANTE:
Lder Usuario
Presentado por:
rea:
Fecha requerida para:
II. OBJETIVOS Y FUNCIONALIDAD:

Titulo:
2. Funcin-objetivo principal:
3. Definiciones funcionales: Describe qu debe cumplirse en cada nivel (operativo, gestin, control)
3.1- Funcionalidad Operativa:
Describir las funciones que se requieren al nivel operativo. Precisar los entregables, criterios, frmulas u otros que se requieren para definir
completamente la funcin descrita. Precisar si se adjunta algn anexo.
3.2- Funcionalidad de Gestin:

<a. Descripcin 1>
Describir las funciones que se requieren en los diferentes niveles de gestin asociados con el requerimiento; por ejemplo, reportes sumarios de
gestin, acumulaciones, ratios, estadsticas. Precisar los entregables, criterios, frmulas u otros que se requieren para definir completamente la
funcin descrita. Precisar si se adjunta algn anexo.
3.3- Funcionalidad de Control:

<a. Descripcin 1>
<b. Descripcin 2>
4. Referencia legal:
<a. Descripcin 1>
Si fuese necesario, describir los requerimientos legales que deben cumplirse, o en los cuales se basa; incluir la referencia a los dispositivos legales o
normas internas. Precisar si se adjunta algn anexo.
Figura 64 Plantilla Solicitud de Requerimiento.doc
- 133 -

5. Otras reas relacionadas y sus coordinadores:

<a. Descripcin 1>
<b. Descripcin 2>
En caso de relacionarse con otras reas o empresas, detllelas, indicando el coordinador o contacto correspondiente. Igualmente si tuviese alguna
relacin con otro proceso o sistema informtico.
III. BENEFICIOS:
.
IV. OTRAS OBSERVACIONES:

<a. Descripcin 1>
Incluir cualquier otra informacin que pueda ser til para la evaluacin, o dimensionamiento del proyecto, as como para un mejor entendimiento
del mismo.
Firmas
Gerente rea Solicitante
Lder Usuario
Plantilla Solicitud de Requerimiento 2/2.doc
SP1.1, SP 1.3: Lista de requerimientos (hoja de clculo)
Cate
ActiPriorida
vida
gori
d
-des
a
Total
Comentario
s
Documento.
Respo
nsable
Prueba/
Soporte
IT
Tip
re
Requerimiento
Mdulo
Req.
o
a
Anlisis/
Diseo
RELACIN DE REQUERIMIENTOS PROYECTO X
Programa.
Fecha DD/MM/YYYY
0.00
0.00
0.00 0.00
Figura 65 Plantilla Lista de requerimientos.xls
- 134 -
0.00 0.00 0.00

SP 1.2: Acta de Reunin
Figura 66 Plantilla Acta de Reunin
- 135 -

SP 1.3: Lista de Cambios
CT410: Lista de Cambios

Relacin de Requerimientos adicionales pendientes (con severidad necesaria)
Modulo de Contabilidad General
Requerimiento de Cambio
Anlisis de Impacto
Solucin
Fec.req Fec.ent
Sever
Estado
Sever
Estado
Sever
Estado
(*) La severidad del requerimiento se est clasificando en Necesario, Conveniente y Deseable.
Mdulos de cuentas por pagar y tesorera

Anlisis de Impacto
Solucin
Fec.req Fec.ent
Mdulos de Inventario
Anlisis de Impacto
Solucin
Fec.req Fec.ent

Figura 67 Plantilla Lista de Cambios.doc
- 136 -

SP 1.4: Documento Funcional

Casos de Uso: Referencia a Requerimientos Funcionales
Figura 68 Plantilla para especificacin de Caso de Uso.doc
- 137 -

SP 1.5; GP 2.7; GP 2.10: Cronograma de Desarrollo Resumen de Cronograma

Cronograma de Desarrollo Resumen
Responsable
Semanas
Etapa
SYPSA
CLIENTE
Levantamiento de Informacin
GP, JI, JD
GS, US
Aprobacin de Requerimientos
GP, JI, JD
GS, US
Diseo de Programas
JD, P1, P2
Aprobacin de Diseo
GP, JD
Programacin
JD, P1, P2
Pruebas con Usuario
JD, P1, P2
US
Depuracin
JD, P1, P2
US
Entrega
GP, JD
GS, US
1 2
3 4 5 6
7 8 9 10 11 12
13 14 15
16 17 18
D3
D4
D1
GS, US
D2
Figura 69 Plantilla Cronograma de Desarrollo.xls
SP 2.2: Plantilla Cronograma de Desarrollo Detalle de Cronograma

Cronograma de Desarrollo Detallado
tem
Proyecto
Requerimiento
Indicaciones
Comentarios
Situacin
Responsable
Fecha
Programada
Figura 70 Plantilla Cronograma de Desarrollo Detalle de Cronograma.xls
- 138 -
Fecha
Real
Prioridad

GP 1.1; GP 2.1: Poltica de Gestin de Requerimientos

Seccin 1 Resumen Ejecutivo
El nombre del requerimiento
Nombre del cliente
Todas las instalaciones involucradas
Una descripcin del requerimiento
Una descripcin de la solucin que ser entregada
Seccin 2 - Introduccin
Seccin 2.1 - Propsito y objetivos
Describir brevemente las necesidades del negocio del cliente y sus problemas y cmo
sern resueltos con la solucin del requerimiento.
Seccin 2.2 - Estrategia del requerimiento
Describa cmo se alcanzarn los objetivos del requerimiento.
Documente las fases del ciclo de vida posibles.
Iniciacin
Planificacin
Ejecucin
Cierre.
Seccin 2.3 - Alcance
Describa los lmites del requerimiento. El alcance circunscribe las actividades o funciones a
realizar. Brevemente describa qu procesos del cliente, instalaciones y locaciones se
emplearn. Documento aquello que el proyecto no tendr en cuenta.
Seccin 2.4 - Entregables o productos
Describa la lista de los principales productos del requerimiento, como los componentes del
servicio, documentos, etc.
Seccin 2.5 - Interfaces organizacionales
Describa todas las instancias que intervienen en el en la solucin del requerimiento como
usuario lder, encargo del requerimiento por parte del cliente y otras personas que sean
relevantes en el proceso.
Seccin 2.6 - Documentos de referencia
Incluya documentacin referencial que est relacionada con el requerimiento solicitado.
Seccin 3 - Estructura del requerimiento

La identificacin clara de la estructura del requerimiento facilitar la planificacin y las
comunicaciones. Tome en cuenta la organizacin y estructura del requerimiento, roles y
responsabilidades. Use una o ms grficas para bosquejar la organizacin del requerimiento.
Incluya al cliente, proveedores de la solucin y terceras partes.
Seccin 3.1 - Roles y responsabilidades
Identifique a todos los miembros del proyecto y equipos de proyectos relacionados, al igual
que otras personas claves. Describa roles y responsabilidades especficos. Aclare los roles
gerenciales versus los roles de personal tcnico. Incluya los nmeros telefnicos y direccin de
correo electrnico. Tambin incluya los roles del usuario final en cualquier actividad que
represente una dependencia para el proyecto e indique sus responsabilidades.
Figura 71 Plantilla Poltica de Gestin de Requerimientos.doc
- 139 -

Seccin 3.2 - Proyectos integrantes del proyecto, relaciones y dependencias

Identifique todos los gerentes / lderes de proyectos participantes tanto del cliente como del
proveedor.
Seccin 3.3 - Cmo trabajar el equipo del proyecto
Muestre los informes entre los miembros del proyecto. Defina los roles de supervisin.
Proporcione la relacin de reuniones proyectadas regularmente, reportes y otros
procedimientos.
Seccin 3.4 - Roles del cliente
Identifique al personal del cliente que ser en nexo entre el cliente y el proveedor e indique los
medios de comunicacin que se emplearn.
Seccin 3.5- Rol de terceras partes
Describa cmo participarn las terceras partes dentro del marco del proyecto.
Seccin 3.6 - Intervencin de ejecutivos y aprobaciones, relaciones ejecutivas
Defina cmo intervienen los ejecutivos o gerentes funcionales de las partes participantes.
Defina las aprobaciones necesarias para los productos principales del proyecto. Enumere,
desde la perspectiva del usuario, los nombres de los ejecutivos de las partes y describa cmo
se espera que apoyen el proyecto.
Seccin 3.7 - Proceso de control de cambios
Defina el proceso de control de cambios que se usar para controlar los entregables del
requerimiento. Defina los niveles de responsabilidad para la aprobacin de cambios.
Seccin 3.8 - Tcnicas y herramientas de gestin de proyectos
Seccin 4 - Actividades y Estimados

Aqu se deben definir las actividades y estimados principales del proyecto.
Seccin 4.1 - Tareas, subtareas, actividades y esfuerzos respectivos y habilidades para
el proyecto e integrantes
Para cada fase del proyecto, defina la estrategia, prerrequisitos, tareas, actividades externas y
criterios de xito. Adems por cada tarea o sub tarea, proporcione una descripcin, el recurso
y la habilidad o conocimiento requeridos, estime el esfuerzo y el nombre de la persona
responsable.
Seccin 5 - Recursos
Proporcione los recursos necesarios y disponibles para el proyecto.
Seccin 5.1 -Personal
Presente un listado donde se muestre los recursos humanos asignados, sus roles,
organizaciones y tiempo asignado. Resuma la cantidad total de das-hombre y otros gastos por
fases, haga una referencia cruzada entre proyectos e identifique las fuentes de los estimados.
Seccin 5.2 - Equipos
Describa los requerimientos logsticos necesarios para el desarrollo del requerimiento
(telfono, equipos de cmputo requeridos y otros recursos requeridos.)
Seccin 5.3 - Instalaciones
Describa las necesidades de instalacin requeridos por el grupo del proyecto.
Seccin 6 - Cronograma
Desarrolle el cronograma del proyecto sobre la base de los estimados de tiempo y la
secuencia requerida y duracin de las tareas, subtareas y actividades.
- 140 -

Seccin 6.1 - Cronograma por fase y tareas principales del proyecto

Detalle el cronograma del proyecto, fase por fase, incluyendo las tareas principales del
proyecto.
Seccin 6.2 - Lista de Hitos
Detalle los hitos principales del proyecto e indique el estado de estos en cualquier momento
dado durante el proyecto.
Seccin 7 - Revisiones y aprobaciones

Todo el personal debe de estar informado del cronograma del proyecto as como de las
funciones o responsabilidades que tendr cada uno de ellos.
Seccin 7.1 - Revisiones del proyecto
Establezca un calendario de revisiones para el proyecto que satisfaga las necesidades de
todas las partes. Proporcione informacin sobre los procedimientos o mtodos que se van a
utilizar en los casos de pruebas.
Seccin 7.2 - Aprobaciones de documentos del proyecto
Describa el proceso de aprobaciones (incluyendo nivel de aprobacin, organizacin y
procedimientos) dentro de la firma contratista, la empresa cliente y terceras partes.
Seccin 7.3 - Transiciones entre fases
Defina los criterios y procesos para realizar las transiciones entre las fases.
Seccin 8 - Dependencias del proyecto, riesgos y contingencias

Revise y valore los riesgos y dependencias del proyecto. Resalte los riesgos que queden fuera
del control de los miembros del equipo del proyecto. Discuta los planes de contingencia para
mitigar la ocurrencia de los riesgos.
Seccin 8.1 - Dependencias hacia proyectos y eventos
Discuta las actividades sobre las cuales el equipo del proyecto tiene poco control. Describa y
discuta el impacto de las actividades que se retrasen o fallen. Discuta la sensibilidad que
presenta el proyecto general hacia esos eventos. Explique las medidas de mitigacin de riesgo
que se tomarn.
Seccin 8.2 - Riesgos y contingencias
Cules son los riesgos tcnicos y administrativos? Cul es la probabilidad de ocurrencia de
los eventos de riesgo? Cmo se puede mitigar la posibilidad de falla por esos riesgos? Se
han desarrollado los planes de reduccin de riesgos? Qu planes de contingencias se
tienen? Se cuenta con fondos de contingencia?
Seccin 8.3 - Proceso de solucin de problemas
Describa cmo se identificarn, clasificarn, priorizarn, escalarn y resolvern los problemas.
Tambin identifique los mecanismos de comunicacin y rutas y responsabilidad de resolver
problemas para el proyecto y cada proyecto integrante.
Seccin 8.4 Seguimiento y Control
Realizar un seguimiento de tareas y esfuerzos en la consecucin de proyectos. El proceso de
captura de datos para el Seguimiento y Control debe hacerse de forma peridica y en periodos
de tiempo pequeos para obtener mayor detalle en los resultados y tomar las acciones
pertinentes de forma rpida y eficaz.
Seccin 8.4 Aseguramiento de la Calidad
Realizar la revisin de las actividades y documentacin producida durante la etapa de
planificacin, se recomienda que el grupo o persona asignada para estas auditoras no formen
- 141 -

parte del proyecto a revisar y posteriormente realice las observaciones y recomendaciones

que deban ser mejoradas.
Procedimiento de revisin y listas de verificacin
Procedimiento de revisin
La informacin contenida en el Plan del Requerimiento se debe presentar de forma detallado,
que permita realizar una revisin de forma rpida y precisa. Cualquier interrogante que
requiera mayor investigacin se debe resolver antes de la revisin, de ser posible.
Lista de verificacin
La siguiente lista de verificacin se puede usar para revisar si el Plan del Requerimiento
est completo:
Las afirmaciones en la Introduccin, Seccin 2, estn alineadas con los objetivos
subyacentes del proyecto.
Las actividades de la seccin 4, Actividades y Estimados, cubren completamente los
objetivos fijados en la seccin 2 y cumplen con los entregables requeridos.
El tipo y cantidad de entregables se ha definido.
Todos los recursos mencionados en la seccin 6, Recursos, estn en concordancia con los
ltimos compromisos.
Cada miembro del equipo ha ledo y aprobado el Plan del Proyecto.
El cronograma ha sido convenido y est en concordancia con los compromisos de recursos.
Los hitos han sido convenidos por el cliente y el contratista.
Se incluyen todos los planes apropiados.
Las dependencias del proyecto estn alineadas con el plan de recursos.
Se han identificado las dependencias del proyecto hacia los usuarios finales y se cuenta
con planes de contingencia y eventos activadores.
Los riesgos adicionales se han comunicado a las personas que intervienen. Por ejemplo,
los riesgos con recursos se han comunicado a los gerentes de los recursos.
Cualquier asunto pendiente ha sido resuelto, se ha identificado el riesgo o se cuenta con un
procedimiento para resolverlo.
El plan se puede poner en operacin tan pronto sea aprobado.
Todas las participaciones del cliente se han comunicado al cliente y han sido entendidas.
- 142 -

GP 2.3: Plantilla de Control de Recursos de Requerimientos
Figura 72 Plantilla para Requerimientos de recursos.doc
GP 2.4: Plantilla de Roles para Requerimientos
Figura 73 Plantilla de roles para requerimientos.doc
- 143 -

GP 2.8: Plantilla de Encuesta de Satisfaccin

El objetivo de esta encuesta es medir la actitud mostrada por los consultores de la EMPRESA durante el
desarrollo de las tareas como Consultor Asignado a su Empresa. Esta informacin nos ayudar a mejorar el
servicio brindado a nuestros clientes.
CLIENTE
PROYECTO
CONSULTOR
EVALUADOR
CARGO
FECHA
Marcar con una X lo que corresponda.

1.Los consultores fueron puntuales al asistir a las reuniones o actividades programadas para el proyecto?
SI
NO
2.Los consultores fueron lo suficientemente claros y amables al responder a las interrogantes formuladas por los
usuarios?
MUY BUENO
BUENO
REGULAR
MALO
3.El consultor cumplieron con los tiempos acordados en la presentacin de las tareas que le correspondieron?
MUY BUENO
BUENO
REGULAR
MALO
4.En que grado not usted que el consultor estuvo involucrado en el proyecto?
MUY BUENO
BUENO
REGULAR
MALO
5.Cul es su nivel general de satisfaccin con el avance o resultado del proyecto?
MUY BUENO
BUENO
REGULAR
MALO
6.Agradeceremos cualquier comentario que usted considere conveniente para ayudarnos a mejorar nuestro nivel de
servicio:
Figura 74 Plantilla para encuesta de satisfaccin.doc
- 144 -

GP 2.9: Lista de verificacin para evaluar la Adherencia del Proyecto
Lista de Verificacin para evaluar la adherencia del proyecto

Preparado por:
Fecha:
Auditor:
Lista de Verificacin de las actividades realizadas durante la Gestin de Requerimientos
Puntos de control
Conforme
Observado
Comentarios
Realizado por:
Fecha:
Figura 75 Plantilla Lista de verificacin para evaluar la adherencia del proyecto.doc
- 145 -

Programacion Orientada A Objetos

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Programacion Orientada A Objetos

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN

PROYECTO PROFESIONAL PRESENTADO POR:

PARA OPTAR POR EL TTULO DE INGENIERO DE SISTEMAS

Lima, Noviembre del 2011

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Para tal efecto el proyecto se ha dividido en 3 captulos, en el primer captulo se

En el segundo captulo se lleva a cabo la evaluacin de los procesos de

Finalmente en el tercer captulo se manifiesta la aplicacin de algunas prcticas

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

LISTAS ESPECIALES ............................................................................................ 5

Presentacin de la empresa objeto de estudio ......................................... 14

Prototipo del proceso en BPM Studio ....................................................... 26

Indicadores de desempeo ...................................................................... 28

Objeto de estudio ..................................................................................... 33

Alcance de la evaluacin .......................................................................... 36

Factibilidad del cambio ............................................................................. 36

Evaluacin de la situacin actual ............................................................. 39

Procesos propuestos. ............................................................................... 48

Fundamentacin Terica .......................................................................... 63

Adopcin de Prcticas giles ................................................................... 71

Prctica gil 1: Kanban ....................................................................... 71

Prctica gil 2: Daily Meeting ............................................................. 79

Prctica gil 3: Task board ................................................................. 84

Prctica gil 4: Pair Programming ...................................................... 93

Evaluacin de Resultados ........................................................................ 97

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Plantillas para el proceso: Project Planning (PP) ................................... 106

Plantillas para el proceso: Requirements Management (REQM) ........... 133

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Tabla 11 Descripcin de las actividades propuestas para el rea de proceso PP .......................... 51

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Figura 40 Plantilla WBS.doc ........................................................................................................... 106

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Figura 72 Plantilla para Requerimientos de recursos.doc ............................................................. 143

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Debido a que nos encontramos en un medio que cambia constantemente, las

Actualmente las nuevas tendencias no siempre son aplicadas y en muchos casos

especialmente para aquellas cuyo principal rubro de negocio es el servicio de

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

que darn origen a soluciones de negocio ms sofisticadas las cuales brinden la

La compresin de la importancia y los conceptos principales de la gestin de

Disear los procesos de desarrollo de software de una organizacin a travs de

Promover el desarrollo de proyectos y su gestin en procesos con ciclos de

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

En el primer captulo, se realiza un modelado del proceso de negocio de gestin

En el segundo captulo, se aplica la metodologa CMMi para la mejora de

En el tercer captulo, se desarrollan algunas prcticas utilizadas en las

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

Las organizaciones se apoyan en sus procesos de negocios para ser guiados en

La Gestin de procesos de negocio (BPM) es una metodologa corporativa que se

El presente trabajo, consisten en proponer una mejora en los procesos de gestin

En tal sentido, el documento est organizado como sigue: Presentacin de la

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

1.1 Presentacin de la empresa objeto de estudio

consolidndose de esta forma como un actor importante en los segmentos de

El objetivo principal de Americatel es satisfacer las necesidades de los clientes.

Americatel Per est focalizada en cuatro segmentos de mercado: Empresas,

ESTABLECIMIENTO DE MODELOS Y METODOLOGAS INNOVADORAS EN LOS

En el segmento Corporaciones, el objetivo es mantener y desarrollar la

Figura 1 Organigrama de AMERICATEL PERU SA.