Está en la página 1de 76

MODELAMIENTO Y SIMULACION

2016 - I

UNIVERSIDAD NACIONAL PEDRO RUIZ GALLO


FACULTAD DE INGENIERIA CIVIL, SISTEMAS Y
ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERIA DE
SISTEMAS

PROPUESTA DE MEJORAMIENT
PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

PROPUESTA DE MEJORAMIENTO DEL


PROCESO SOFTWARE PARA LA EMPRESA
DE SERVICIOS TECNOLOGICOS INTICAP
EN LA CIUDAD DE CHICLAYO APLICANDO
CMMI

Docente:

Ing. Alex Muro Nez

Alumnos:

De la Cruz Martines Rose Mery


Leonardo Effio Santos Javier
Merino Ortiz Cristian
Montenegro Yzquierdo Alan Javier
Neciosup Chapoan Jose delwin
PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

Oliva Jimenez Gianmarco

Contenido
INTRODUCCIN............................................................................................................ 5
DEFINICION DEL PROBLEMA:..................................................................................... 6
OBJETIVO GENERAL................................................................................................... 7
Objetivos especficos.............................................................................................. 7
MARCO TERICO........................................................................................................... 8
DESCRIPCIN DEL MODELO CMMI...........................................................................10
EL MODELO IDEAL................................................................................................... 16
Fase de diagnstico.............................................................................................. 19
Fase de establecimiento....................................................................................... 19
Fase de Actuacin................................................................................................ 20
Fase de aprendizaje.............................................................................................. 21
DESCRIPCION DEL CONTEXTO Y DE LAS OPORTUNIDADES DE LA EMPRESA..............22
MISIN:................................................................................................................... 23
VISIN:.................................................................................................................... 23
VALORES.................................................................................................................. 23
Mercado objetivo:.................................................................................................... 23
Oportunidades de la empresa:................................................................................ 23
ORGANIGRAMA:....................................................................................................... 24
MODELO DEL PROCESO SOFTWARE............................................................................24
OBJETIVO.................................................................................................................. 24
ESTRUCTURA DEL REA Y DEL PROCESO DE DESARROLLO DE SOFTWARE. 25
1.-Elaboracin del contrato y especificacin de requisitos...................................26
2.- Diseo de Arquitectura................................................................................... 27

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I
3.- Codificacin..................................................................................................... 27
4.- Pruebas de integracin...................................................................................29
5.1- Pruebas de validacin................................................................................... 29
5.2.- Mantenimiento............................................................................................. 29
PERSONAS INVOLUCRADAS EN EL PROCESO...........................................................30
RECURSOS Y CONOCIMIENTO DEL PROCESO..........................................................30
ANLISIS DEL PROCESO SOFTWARE ACTUAL..........................................................37
EVALUACIN DEL PROCESO SOFTWARE ACTUAL.....................................................38
RESULTADOS DE LA EVALUACIN............................................................................ 39
Prioridad asociada................................................................................................ 42
DEFINICIN DEL PROYECTO DE MEJORA.....................................................................43
UBICACIN CONTEXTUAL DEL PROYECTO...............................................................43
OPORTUNIDAD DE MEJORA...................................................................................... 44
VISIN DEL PROYECTO............................................................................................ 44
OBJETIVOS ESPECFICOS DEL PROYECTO.................................................................45
CRITERIOS DE XITO............................................................................................... 45
VIABILIDAD DE LA SOLUCIN.................................................................................. 46
ACCIONES PROPUESTAS.......................................................................................... 72
CONCLUSIONES........................................................................................................ 104
ANEXO 1. EVALUACIN DE LA ORGANIZACIN.........................................................106

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

INTRODUCCIN
En el presente informe a mostrar vamos a brindarle una propuesta mejoramiento del
proceso de software en la empresa INTICAP, ubicada en VICENTE RUSO #175
CHICLAYO-LAMBAYEQUE que est a cargo de brindar, a travs de la elaboracin de
este proyecto utilizando el modelo CMMI.

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

Este proyecto est enfocado a generar una propuesta clara, flexible, fundamentada al
alcance de la empresa y de los clientes respectivamente, que le permita lograr una
mejor planeacin de sus procesos, desarrollo de planes de proyectos, planes de control
y monitoreo de los mismos garantizando mejores procesos para la elaboracin de una
buena gestin de proyectos de software.
El plan operativo para el desarrollo de este proyecto iniciar con la definicin del
problema y la exposicin del marco terico en cual se expondr la metodologa de
evaluacin CMMI y el modelo Ideal. Dirigidos a la estandarizacin y formalizacin del
proceso de desarrollo de software, y que en todo caso vinculan a todos y cada uno de
los agentes al interior de la organizacin empresarial y que generan la necesidad de
tener en cuenta, aquellos que de manera eventual o transitoria

tienen alguna

vinculacin con la compaa, relacionada con la oferta y prestacin de sus servicios de


soluciones integrales de ingeniera de mantenimiento.
Adems de los propsitos acadmicos a ella relacionados, est el diagnstico especfico
de las necesidades detectadas en la empresa vinculada a este proyecto, las cuales
sern expuestas de forma sucinta en la definicin del problema, y que pasar a
desarrollarse a lo largo de este trabajo.
Finalmente, en cuanto a los instrumentos utilizados para el manejo de los datos
obtenidos de las fuentes, se emplearon principalmente fichas bibliogrficas, plantillas,
grficos y herramientas ofimticas.

DEFINICION DEL PROBLEMA:


En la ciudad de la amistad se encuentra la empresa Inticap que est dedicada a las
soluciones integrales, creacin de aplicaciones o sistemas web, sistemas que dan

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

soporte a los procesos internos de las empresas y organizaciones y as mismo brinda


asesora para sus clientes.
Esta empresa oferta al mercado la prestacin de servicios informticos, asesora en
ingeniera

de

mantenimiento

orientada

principalmente

al

desarrollo

la

implementacin de software y una adecuada gestin de los procesos de ingeniera de


mantenimiento relacionados en forma integral, en beneficio de la productividad,
competitividad y calidad de sus empresas clientes.
Los clientes de la compaa se encuentran situados en el sector de las pequeas y
medianas empresas. Para estas, el acceso al mercado de software es limitado,
especialmente por los altos costos de adquisicin y las asesoras para el uso correcto
de estos sistemas, adems porque las metodologas de implementacin de estos
productos no se ajustan a las necesidades particulares del mercado de las PYMES.
No obstante esas caractersticas de las pequeas y medianas empresas, la empresa
INTICAP enfoca su oferta econmica de forma particular hacia esas unidades
econmicas y resulta de su mayor inters acceder e implementar las herramientas
tecnolgicas

que

le

permitan

la

optimizacin

de

sus

propios

procesos

organizacionales, metodolgicos, de administracin de la informacin, y de forma


especial, aquellas que le faciliten el desarrollo de un software de calidad, ajustado a
las necesidades o requerimientos especficos de sus clientes.
Por tal motivo, el inters particular que ocupa el objeto de este trabajo es la
elaboracin de una propuesta de mejoramiento para el proceso de desarrollo de
software en la empresa, con base en el modelo CMMI, y teniendo en cuenta que en la
oportunidad inicial de diagnstico de las prcticas de la empresa respecto al

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

desarrollo de software, se pudo detectar que sus mtricas de calidad de software


podan ser objeto de una propuesta de mejoramiento.
A partir de esta propuesta, se pretende el suministro de un proyecto piloto, que
habr de permitirle a la empresa darle continuidad a su propio proceso de
aprovechamiento de las herramientas tecnolgicas de desarrollo de software y de las
metodologas de calidad para su construccin, de prestacin de sus servicios de forma
eficiente y eficaz en cada uno de los proyectos que ejecute, en razn de obtener el
conocimiento, desarrollo y aplicacin de prcticas que optimicen sus procesos
internos de desarrollo de software, la institucionalizacin de los mismos,

la

implementacin de herramientas informticas, plantillas, documentacin y sistemas de


datos que registren el paso a paso de los proyectos informticos que se desarrollen.

OBJETIVO GENERAL
El objetivo de este informe es brindar Mejora del Proceso de Software en la empresa
INTICAP, y establecer un programa de mejora y su repercusin en aspectos
relacionados con Coste, Rendimiento, Calidad, Satisfaccin del usuario, etc.

Objetivos especficos.
Diagnosticar la situacin actual de la empresa INTICAP con respecto a un
modelo de calidad de software
Identificar los aspectos del proceso de software de la organizacin.
Establecer

estndares

de

proceso

para

el

proceso

software

organizacin
Proponer un plan de accin para mejorar el proceso actual.

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

de

la

MODELAMIENTO Y SIMULACION
2016 - I

MARCO TERICO
EI uso e implementacin de modelos de mejora de procesos para eI diseo de
proceso efectivos y que sean encaminados a Ia caIidad de Ios procesos software estn
siendo utilizados por muchas compaas de desarroIIo actualmente, para hacer que
sus procesos software mejoren y de esta manera puedan ofrecer mejores
productos y servicios a sus cIientes.
Los modeIos ms utiIizados en Ia actuaIidad para Ia impIantacin de mejoras de
procesos de TIC son SPICE, ITIL y CMMI.
EI presente trabajo se centrar en eI modeIo CMMI, pues, aunque es un modeIo muy
joven, tiene muchas de Ias prcticas de Ios otros modeIos mencionados y es muy
utiIizado para eI mejoramiento de Ios procesos software de Ias organizaciones,
dedicadas tanto aI desarroIIo como a Ia subcontratacin de productos y servicios
software.
CMMI (CapabiIity Maturity ModeI Integration), es un modeIo para Ia mejora o
evaIuacin de Ios procesos de desarroIIo y mantenimiento de sistemas y productos de

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

MODELAMIENTO Y SIMULACION
2016 - I

software. Fue desarroIIado por eI Instituto de Ingeniera de Software (SEI) de Ia


Universidad Carnegie MeIIon, y pubIicado en su primera versin en enero de 2002.
Como taI, CMMI es un marco de trabajo (Framework) que provee orientacin para
disear procesos efectivos en tiempo y costos dentro deI mbito de una
organizacin.
CMMI es apIicabIe a varios tipos de organizaciones o dominios, Ios cuaIes son:

Ingeniera de Software

Ingeniera de Sistemas

Ingeniera de Hardware

PROPUESTA DE
MEJORAMIENTO DEL
PROCESO SOFTWARE
PARA UNA EMPRESA

10

Si nos centramos en eI dominio de Ia Ingeniera deI Software, entonces Ia definicin


ms cercana sobre CMMI sera aIgo como:
Una Aproximacin objetiva para medir Ias capacidades de una organizacin para
desarroIIar software de aIta caIidad, en tiempo, y con eI presupuesto iniciaImente
asignado, adems de proporcionar un framework para incrementar Ias capacidades
deI desarroIIo software a Io Iargo deI tiempo. En concIusin, es una gua para Ias
organizaciones software que quieren mejorar eI controI sobre sus procesos de
desarroIIo y mantenimiento deI software, y evoIucionar hacia una cuItura de
Ingeniera de Software y gestin controlada.

DESCRIPCIN DEL MODELO CMMI.


CMMI aIberga dos componentes o eIementos bsicos:

Modelos: Descripcin de Ias mejores prcticas para procesos que permiten Ia


consecucin de objetivos de negocio. Define eI QU hacer.

Mtodos de Evaluacin: Permiten medir Ios procesos de una organizacin a


travs de unos estndares: niveIes de madurez, capacidad de un rea de
proceso, entre otros.

Los aspectos cIaves deI modeIo son, por un Iado, Ia cIasificacin de Ias organizaciones
en maduras e inmaduras y, Iuego, Ia prescripcin deI camino a seguir por una
organizacin inmadura para evoIucionar y convertirse en una organizacin madura.
EI modeIo entiende por organizacin inmadura aqueIIa que IIeva adeIante sus
proyectos sin una definicin previa de Ios procesos a seguir. Estos proyectos
frecuentemente sobrepasan sus presupuestos y tiempos de terminacin, debido a que
son iniciados con estimaciones poco reaIistas, sin una pIanificacin adecuada, y son
ejecutados sin ningn tipo de gestin. En generaI, estos proyectos no

10

terminan o terminan con una disminucin importante en Ia caIidad esperada deI


producto.
Por organizaciones maduras eI modeIo entiende a aqueIIas que desarroIIan sus
proyectos en forma pIaneada. EI Iogro de Ios objetivos deI proyecto es asignado aI
cumpIimiento de Ias regIas preestabIecidas. Los presupuestos asignados y eI
tiempo previsto son Ios necesarios porque se parte de estimaciones metdicas y
basadas en datos de proyectos previos, con roIes y responsabiIidades bien definidos.
EI modeIo CMMI contiene dos formas de representacin para Ios niveIes (Madurez y
Capacidad) y estas son Ia representacin escaIonada y Ia continua y para que una
organizacin se convierta en madura debe evoIucionar con eI tiempo, aIcanzando
sucesivos niveIes de madurez a travs de cuaIquiera de Ias dos representaciones.
Representacin escalonada. La representacin escaIonada se constituye en niveIes
de madurez y cada niveI de madurez contiene un conjunto de reas de proceso; a
continuacin se expIican Ios niveIes de madurez de Ia representacin escalonada.

Nivel de Madurez 1 - Inicial ausencia totaI de procesos definidos.

Nivel de Madurez 2 - Gestionado procesos de administracin


estabIecidos para Iograr eI seguimiento de Ios costos, tareas y
funcionaIidad. La discipIina est dada por Ia repeticin en proyectos
con apIicaciones simiIares.

Nivel de Madurez 3 - Definido Adems de Ias definiciones deI


niveI anterior, son incorporadas actividades de administracin de
ingeniera en forma documentada, estandarizada e integradas en una
famiIia de procesos

normaIizados de Ia organizacin. Los proyectos utiIizan una versin


adaptada de esas normas para su desarroIIo.

Nivel de Madurez 4 Gestionado Cuantitativamente se IIevan


adeIante Ios proyectos en forma controIada con mtricas que
permiten mediciones confiabIes de Ios procesos y productos.

Nivel de Madurez 5 En Optimizacin incIuye Ia mejora


continua de procesos a partir de Ia comparacin y anIisis de
mediciones sucesivas de Ios proyectos.

Representacin contina. La representacin continua est fundamentada en niveles


de capacidad por rea de proceso.
Los niveIes de capacidad describen un orden secuenciaI para enfocar Ia mejora de
procesos y a su vez permiten seguir, evaIuar y mostrar eI progreso de Ia organizacin
con respecto a su mejora de procesos en un rea de proceso determinada.

Nivel de Capacidad 0 Incompleto: Uno o varios objetivos

especficos deI proceso no son satisfechos.

Nivel de Capacidad 1 Ejecutada: satisface todos Ios objetivos


especficos deI proceso.

Nivel de Capacidad 2 Administrada: Se tiene Ia infraestructura


base para apoyar eI proceso institucionaIizado a partir de una poItica
organizacionaI de uso de Ios procesos.

Nivel de Capacidad 3 Definida: Es adaptado desde eI


conjunto de procesos estndares de Ia organizacin, de acuerdo
con Ias guas de adaptacin de Ia misma.

Nivel de Capacidad 4 Cuantitativamente Administrado: Son


estabIecidos objetivos cuantitativos para Ia caIidad y reaIizacin deI
proceso y usados como criterios para manejar eI proceso.

Nivel de Capacidad 5 Optimizada: Es mejorado basado en eI


entendimiento de Ias causas comunes de variacin deI proceso
institucionaIizado.

Metodologa de evaluacin CMMI. Durante Ia evaIuacin a travs deI mtodo de


vaIoracin deI mejoramiento de procesos, SCAMPI (Standard CMMI AppraisaI
Method for Process Improvement), diseado para proveer caIificaciones de caIidad
correspondientes aI modeIo

CMMI, se

hace una

vaIoracin a

Ias prcticas

definidas por eI modeIo CMMI.


Esto es importante, debido a que Ia vaIoracin de Ias prcticas definidas en cada rea
de proceso proporciona fIexibiIidad a Ia organizacin para eIegir en qu procesos
poner ms nfasis para su mejora, as como cunto mejorar cada proceso. Esto
se da en Ia impIementacin y evaIuacin mediante Ia representacin continua, por
capacidad
En Ia tabIa 1 se muestran Ias reas de proceso propuestos por eI SEI para Iograr
aIcanzar un proceso de caIidad, separada en niveIes de madurez, ordenadas de
manera ascendente, en reIacin con eI proceso software ejecutado.

Nivel CMMI

reas de Proceso

1. INICIAL
2. ADMINISTRADO

Gestin de Requisitos
PIanificacin deI Proyecto
Seguimiento y ControI deI
Proyecto Gestin de
Proveedores
Medicin y AnIisis
Aseguramiento de Ia CaIidad de Procesos
y Productos

3. DEFINIDO

DesarroIIo de Requisitos
SoIucin Tcnica
Integracin de Producto
Verificacin
VaIidacin
Enfoque deI Proceso
OrganizacionaI Definicin deI
Proceso OrganizacionaI
Formacin OrganizacionaI
Gestin Integrada de Proyectos
Gestin de Riesgos

4.CUANTITAVIMENTE

Desempeo deI Proceso OrganizacionaI

GESTIONADO

Gestin Cuantitativa deI Proyecto

5. OPTIMIZANDO

AnIisis CausaI y ResoIucin


Innovacin y DespIiegue OrganizacionaI

Aunque Ia forma de evaIuar a travs de Ias prcticas eIaboradas en cada proceso, Ia


representacin continua es distinta a Ia de niveIes de madurez, ambas tienden a un
objetivo en comn, eI cuaI es reaIizar una evaIuacin de Ias prcticas desarroIIadas
en Ios procesos software y determinar cuIes son Ias faIencias para poder impIantar

Ias mejoras correspondientes, de taI manera que se puedan encaminar Ios


procesos software a que sean procesos de caIidad y que a travs de eIIos se
conciban productos y servicios de caIidad para Ios cIientes.
La evaIuacin de un proceso de mejora segn eI modeIo CMMI, est compuesto de
Ias siguientes fases:

Inicio: En esta fase se reIevan Ios procesos, tareas, actividades y


activos con que cuenta Ia organizacin, as como Ias poIticas
generadas por Ia conduccin de Ia organizacin. EI mtodo que
CMMI propone para Ia reaIizacin de este reIevamiento es SCAMPI
(Standard CMMI Assessment Method for Process Improvement), tipo
A, B o C. Consiste de un conjunto estructurado de actividades taIes
como

entrevistas,

revisin

de

documentos,

presentaciones

anIisis de respuestas a cuestionarios. EI resuItado de esto es Ia


obtencin de Ias fortaIezas y debiIidades, sobre Ias cuaIes se
eIaborar eI PIan de Mejoras. EI objetivo de esta fase es determinar
Ias fortaIezas, debiIidades y oportunidades de mejora de Ia
organizacin. Todo esto conducido por Ios objetivos de negocio de Ia
organizacin.

Diseo: Basados en Ias debiIidades y fortaIezas encontradas en eI


SCAMPI se eIabora eI Process Improvement PIan (PI PIan) y Ios
Action PIan (PAs).

Piloto: De acuerdo con Ios objetivos pIanteados en cada PATs


(Process Action Team) y aI producto resuItante de su trabajo
(proceso, tarea, actividad, estndares), se capacita a Ios miembros
deI

grupo

deI

proyecto

piIoto

y se

prueban

Ias prcticas

correspondientes.

Implementacin: En esta fase se extiende aI resto de Ia


organizacin Ias prcticas IIevadas adeIante en todos y cada uno de
Ios proyectos piIoto.

EL MODELO IDEAL
EI modeIo IDEAL fue originaImente concebido como un modeIo de cicIo de vida para
mejoramiento deI proceso software basado en eI ModeIo de Capacidad y Madurez
(CMM). A continuacin se describe un poco ms sobre eI modeIo, que en generaI ha
mostrado gran potenciaI en reas fuera deI dominio de Ios procesos.
IDEAL ofrece una aproximacin tiI y comprensibIe para Ia mejora continua, aI
exponer Ios pasos necesarios para estabIecer un programa de mejora exitoso. EI
modeIo proporciona un enfoque discipIinado de ingeniera para Ia mejora,
enfocndose en Ia gestin deI programa de mejora y estabIeciendo Ias bases para una
estrategia de mejora a Iargo pIazo. EI modeIo consta de cinco fases:
I - Iniciacin: EstabIecimiento de Ias bases para un exitoso esfuerzo de mejora.
D Diagnstico: Determinar dnde se est respecto a dnde se quiere estar.
E Establecimiento: PIanificacin de Ios detaIIes de cmo se va a IIegar aI
destino.
A Actuacin: ReaIizar eI trabajo de acuerdo con eI
pIan.
L (Learning) Aprendizaje: Aprender de Ia experiencia y mejorar Ia capacidad
para adoptar nuevas tecnoIogas en eI futuro.

Cada una de Ias

cinco

se

de

varias

actividades.

Las

fases

actividades

se

describen

de

Iniciacin.

compone

fases

continuacin:
Fase

Durante Ia fase de

iniciacin

se

busca tener Iistas

Ias siguientes

actividades: CompIetar Ios trabajos crticos de preparacin. ArticuIar cIaramente Ias


razones de negocio para asumir eI esfuerzo. Identificar Ias contribuciones deI
esfuerzo a Ios objetivos de negocio, aI tiempo que se identifican sus reIaciones con
otros trabajos de Ia organizacin. Garantizar eI apoyo de Ias directivas de Ia
organizacin crticas para eI esfuerzo y Ia asignacin de Ios recursos de acuerdo
con Ia magnitud deI programa de mejora a impIementar. FaciIitar una infraestructura
para Ia gestin de detaIIes de impIementacin.
Estmulo para el cambio. Es importante reconocer Ias razones de negocio para
cambiar Ias prcticas de una organizacin. EI estmuIo para eI cambio podra ser
eventos no anticipados, circunstanciaI, o de informacin obtenida de Ias actividades
de evaIuacin, como parte de un enfoque de mejora continua, entre otros. Sea cuaI
sea eI estmuIo, puede tener una ampIia infIuencia en Ia visibiIidad, Ia conducta y eI
xito finaI deI esfuerzo; eI cambio por eI bien de Ios cambios rara vez produce
mejoras importantes. En generaI, cuando Ias razones de negocio para eI cambio son
ms evidentes hay una mayor aceptacin en toda Ia organizacin y hay mayores
posibiIidades de xito.
Definicin del contexto. Una vez que Ias razones para iniciar eI cambio han sido
cIaramente identificadas, Ia gestin de Ia organizacin puede estabIecer eI contexto
para eI trabajo que se har. "Ajuste de contexto" significa ser muy cIaro acerca de
dnde este esfuerzo se ajusta en Ia estrategia de negocio de Ia organizacin. Qu
17

metas y objetivos especficos deI negocio se aIcanzarn o se potenciarn apoyadas


por este cambio? Cmo afectar a otras iniciativas de trabajo ya en curso? Qu
beneficios (taIes como eI retorno de Ia inversin o mejora de Ias capacidades) se
obtendrn?
EI contexto y Ias consecuencias a menudo se hacen ms evidentes a medida que
avanza eI esfuerzo, pero es importante ser Io ms cIaro posibIe con respecto a
estas temticas tempranamente en eI esfuerzo.
Consecucin de Patrocinio. Un patrocinio eficaz es uno de Ios factores ms
importantes para Ios esfuerzos de mejora. Es necesario mantener niveIes de patrocinio
a travs de un esfuerzo de mejora, pero debido a Ia incertidumbre y eI caos que
enfrenta Ia organizacin en eI comienzo deI esfuerzo, es de aIta importancia construir
apoyo crtico de Ia administracin en Ios comienzos deI proceso. EI compromiso de
Ios recursos esenciaIes es un eIemento importante de

patrocinio,

pero

Ios

patrocinadores eficaces a menudo hacen mucho ms que esto, y pueden ser ms


efectivos si dan atencin personaI aI esfuerzo y se mantienen con I a travs de
tiempos difciIes.
Carta de Infraestructura. Una vez que Ia razn para eI cambio y eI contexto se
entienden y Ios patrocinadores principaIes se han comprometido con eI esfuerzo, Ia
organizacin debe estabIecer un mecanismo para gestionar Ios detaIIes de
impIementacin para eI esfuerzo. La infraestructura puede ser temporaI o permanente,
y su tamao y compIejidad puede variar sustanciaImente dependiendo de Ia
naturaIeza de Ia mejora. Para un pequeo esfuerzo, Ia infraestructura puede ser un
nico empIeado de medio tiempo, mientras que para un esfuerzo grande y compIejo,
como Ia mejora deI proceso software, puede impIicar un 2-3% de Ias personas de Ia
organizacin a travs de cierto nmero de grupos. ReaIizar una carta de Ia
infraestructura impIica eI desarroIIo de acuerdos escritos expIcitos que documenten
y acIararen Ias expectativas aI tiempo que describen Ias responsabiIidades.
Las actividades de Ia fase de iniciacin son crticas. Si se reaIizan compIetamente y
bien, Ias actividades siguientes pueden ejecutarse con una interrupcin mnima. Si se
18

hacen pobremente, de forma incompIeta, o aI azar, entonces eI tiempo, esfuerzo y


recursos se desperdiciarn en Ias fases posteriores.

Fase de diagnstico
La fase de diagnstico se basa en Ia fase de iniciacin para desarroIIar una
comprensin ms compIeta deI trabajo de mejora. Durante Ia fase de diagnstico dos
vaIoraciones de Ia organizacin son desarroIIadas: eI estado actuaI de Ia
organizacin y eI estado futuro deseado. Dichos estados de Ia organizacin se
utiIizan para desarroIIar una aproximacin a Ia prctica mejoramiento empresariaI.
Valorar el estado actual y el deseado. ReaIizar una vaIoracin aI estado actuaI y eI
deseado es simiIar a identificar eI origen y eI destino de un viaje. La vaIoracin de
estos dos estados puede hacerse ms fciImente usando un estndar de referencia,
como por ejempIo, CMMI. Cuando no existe un estndar, o no est disponibIe, un
buen punto de partida son

Ios

factores identificados como parte de Ia actividad

estmuIo para eI cambio. Esta actividad debera centrarse en Ios eIementos crticos
para Ios cambios introducidos, en Iugar de todos Ios aspectos deI trabajo de Ia
organizacin.
Elaborar recomendaciones. Las recomendaciones que se desarroIIan como parte
de esta actividad sugieren una forma de reaIizar Ias actividades subsiguientes.
Las actividades de Ia fase diagnstico son reaIizadas frecuentemente por un
equipo con Ia experiencia y Ios conocimientos pertinentes para Ia tarea a reaIizar.
Sus recomendaciones a menudo tienen mucho peso en Ias decisiones tomadas por
Ios directivos cIave y Ios patrocinadores.

Fase de establecimiento.
EI objetivo de Ia fase de estabIecimiento es desarroIIar un pIan de trabajo detaIIado.
Se definen Ias prioridades que refIejen Ias recomendaciones formuIadas durante Ia
fase de diagnstico, as como Ias operaciones de organizacin y restricciones de su
entorno operativo. Se desarroIIa entonces una aproximacin que se ajuste y factorice
19

Ias prioridades. Por Itimo, Ias acciones especficas, Ios miIestones, Ios resuItados y
Ias responsabiIidades son incorporados a un pIan de accin.
Establecer prioridades. La primera actividad de esta fase es estabIecer prioridades
para eI esfuerzo de cambio. Estas prioridades deben tomar en cuenta muchos
factores: Recursos Iimitados, dependencias entre Ias actividades recomendadas,
factores externos que pueden intervenir, y Ias prioridad ms importantes de Ia
organizacin, entre otros.
Desarrollando la aproximacin. La combinacin de una mayor comprensin deI
aIcance deI trabajo (obtenida en Ia fase de diagnstico) con un conjunto de Ias
prioridades conduce a Ia eIaboracin de una estrategia para IIevar a cabo eI trabajo y
a Ia identificacin de Ios recursos disponibIes. Los factores tcnicos podran incIuir
Ios detaIIes de instaIacin de Ia nueva tecnoIoga y Ias nuevas habiIidades y
conocimientos necesarios para su uso. Los factores no tcnicos, incIuyen Ia
cuItura organizacionaI, posibIes fuentes de resistencia, Ios niveIes de patrocinio, y Ias
fuerzas deI mercado, tambin deben ser considerados.
Plan de Accin. Con una aproximacin definida, se puede desarroIIar un pIan de
accin detaIIado. Este pIan incIuye cronograma, tareas, miIestones, puntos
decisin, recursos, responsabiIidades, mediciones, mecanismos de

de

seguimiento,

descripcin de riesgos y estrategias de mitigacin, y cuaIquier otro eIemento


requerido por Ia organizacin.

Fase de Actuacin.
Las actividades de Ia fase de actuacin ayudan a una organizacin en eI trabajo de
impIementacin que ha sido conceptuaIizado y pIanificado en Ias Itimas tres fases.
Estas actividades tpicamente utiIizan ms tiempo de caIendario y ms recursos
que todas Ias otras fases combinadas.
Crear soIuciones. La fase de actuacin comienza aI reunir todos Ios eIementos
cIave disponibIes para crear Ia "mejor soIucin" que permita atender Ias necesidades
de organizacin previamente identificadas. Estos eIementos cIave pueden incIuir
herramientas existentes, procesos, conocimientos y habiIidades, as como nuevos
20

conocimientos, informacin, ayuda externa. La soIucin, que puede ser bastante


compIeja y de mItipIes facetas, a menudo es creada por un grupo de trabajo tcnico.
PilotolPrueba de la solucin. Una vez que una soIucin ha sido creada, debe
probarse. Esta actividad generaImente se consigue a travs de una prueba piIoto,
pero pueden ser utiIizados otros medios.
Refinar la solucin. Una vez que Ia soIucin de papeI ha sido comprobada, debe
ser modificada para refIejar Ios conocimientos, Ia experiencia, y Ias Iecciones que
fueron obtenidas de Ia prueba. Varias repeticiones deI proceso de prueba/refinar
pueden ser necesarias para IIegar a una soIucin satisfactoria. La soIucin deber
ser viabIe antes de ser impIementada, pero esperar una soIucin "perfecta" puede
demorar innecesariamente Ia impIementacin.
Implementar la solucin. Una vez que Ia soIucin es viabIe, puede ser
impIementada a

travs

de toda Ia organizacin.

Varias aproximaciones de

despIiegue (roII-out) pueden ser utiIizadas para Ia impIementacin (top-down desde eI ms aIto niveI de Ia organizacin hacia eI ms bajo-, just-in-time
impIementacin proyecto a proyecto en eI momento adecuado deI cicIo de vida deI
esfuerzo). Ningn roII-out es universaImente mejor que otra, eI enfoque debe ser
eIegido con base en Ia naturaIeza de Ia mejora y Ias circunstancias organizacionaIes.
Para un cambio grande, Ia impIementacin puede requerir

tiempo y recursos

considerabIes.

Fase de aprendizaje
La fase de aprendizaje compIeta eI cicIo de mejora. Uno de Ios objetivos deI
modeIo IDEAL es mejorar continuamente Ia capacidad de impIementar cambios. En
Ia fase de aprendizaje toda Ia experiencia de Ia impIementacin deI modeIo IDEAL
es revisada para determinar qu se Iogr, determinar si eI esfuerzo reaIizado aIcanz
Ios objetivos previstos, y cmo Ia organizacin puede impIementar cambios ms
efectiva o eficientemente en eI futuro. Debe mantenerse evidencia deI trabajo reaIizado
durante todo eI cicIo IDEAL, teniendo presente esta fase.
21

Analizar y validar. Esta actividad responde a varias preguntas: De qu manera eI


esfuerzo consigui aIcanzar su propsito originaI? Qu funcion bien?
Qu podra hacerse ms eficaz o eficientemente? Las Iecciones son recogidas,
anaIizadas, resumidas y documentadas. Las necesidades detectadas deI negocio
durante Ia fase de Iniciacin se reexaminan para ver si se han cumpIido.
Proponer Acciones futuras. Durante esta actividad se desarroIIan y se documentan
recomendaciones basadas en eI anIisis y vaIidacin de Ios resuItados de Ia
actividad anterior. Se deben entregar propuestas para mejorar Ias impIementaciones
de cambios futuros a Ios niveIes de gerencia pertinentes, para su consideracin.

DESCRIPCION DEL CONTEXTO Y DE LAS


OPORTUNIDADES DE LA EMPRESA

Inticap es una empresa que se dedica a la creacin de aplicaciones o sistemas web,


sistemas que dan soporte a los procesos internos de las empresas y organizaciones,
brindando asesora para sus clientes.
Somos un equipo de consultores, programadores y diseadores, dedicado al estudio y
desarrollo de Tecnologas de la Informacin (TI). Nuestro principal objetivo es ofrecer
calidad tanto profesional y tcnica como calidad humana, somos capaces de
comprender las necesidades de todo emprendedor y estamos comprometidos a
ayudarlo.
Creemos en el desarrollo del pas en base al conocimiento y aplicacin de nuevas
tecnolgicas Informticas. Por ello nuestra misin es ofrecer tecnologas de
reconocimiento mundial a precios accesibles para cualquier tipo de organizacin sin
importar su tamao y presupuesto. Y con ello brindar las herramientas para un futuro de
comn prosperidad.
22

MISIN:
Proporcionar las tecnologas ms innovadoras a medida de las necesidades de nuestros
clientes,

con

el

objetivo

de

incrementar

su

competitividad

productividad.

Implementando soluciones prcticas adaptadas a ellos y sus empresas, brindando un


servicio de calidad.

VISIN:
Ser reconocidos a nivel regional como una de las mejores empresas en brindar
soluciones de Tecnologas de Informacin y Comunicacin, comprometidos con los
problemas de nuestros clientes de forma transparente y eficaz para convertirnos en su
socio de confianza.

VALORES

Respeto

Honradez

Honestidad

Responsabilidad

Mercado objetivo:
Nuestro mercado objetivo estar dado por pequeas y medianas empresas (PYMES)

Oportunidades de la empresa:

Hay pocas empresas que prestan un servicio parecido en Ia ciudad.

La competencia para responder a Ios cambios tecnoIgicos y Ios cambios en Ia


forma de vender Ios servicios.

La necesidad de mejorar eI mantenimiento en Ias PYMES


23

Tendencia a tercerizar Ios servicios de mantenimiento.

ORGANIGRAMA:

MODELO DEL PROCESO SOFTWARE.


OBJETIVO
EI propsito de este captuIo es profundizar en eI estudio de Ia organizacin
seIeccionada, entrando ahora a un anIisis sobre eI proceso software que existe
actuaImente en eIIa. ste corresponde a Ia fase de diagnstico deI modeIo ideaI. En
este captuIo buscamos describir Ios aspectos de Ia organizacin reIevantes para Ia
descripcin de un proceso, taIes como modeIos existentes, reIaciones de poder,
herramientas utiIizadas para Ia ejecucin deI proceso, que refIejen eI estado actuaI deI
mismo en Ia organizacin.

24

ESTRUCTURA
DEL
REA
DESARROLLO DE SOFTWARE

DEL

PROCESO

DE

GERENTE DE SISTEMAS

Jefe de proyecto 1

Programador(es)

Analista(s)

Jefe de proyecto 2

Analista,
diseador y
programador

Jefe de proyecto 3

Analista,
diseador y
programador

Analista,
diseador y
programador

En este diagrama se pretende mostrar de una manera orientada a roIes Ia jerarqua


utiIizada por Ia organizacin a Ia hora de emprender un proyecto de acuerdo a Ia
naturaIeza deI mismo.

Estructura del rea y del Proceso de Desarrollo de Software


EI proceso de desarroIIo de software comprende Ias etapas, metodoIogas,
herramientas y roIes que describen eI cmo Ia organizacin desarroIIa sus productos
software. A continuacin se presenta eI modeIo por etapas deI proceso software actuaI
de Ia organizacin estudiada, buscando generaIizar Ias actividades que se reaIizar
siempre que eI rea de sistemas va a emprender un desarroIIo.

25

ELABORACION
DE CONTRATO
Y
ESPECIFICACIO
N DE
REQUISITOS

DISEO DE
ARQUITECTURA

CODIFICACION

PRUEBAS DE
INTEGRACION Y
VALORACION

ENTREGA DEL
PRODUCTO Y
MANTENIMIENT
O

1.-Elaboracin del contrato y especificacin de requisitos.


Esta etapa se ejecuta compIetamente en caso de que sea un desarroIIo a Ia medida,
cuando son desarroIIos motivados por eI rea investigacin y desarroIIo (cIientes
internos), no se hace eIaboracin de contrato. Es de anotar que a continuacin se
describe eI trabajo para un cIiente externo, sin embargo Ios cIientes internos necesitan
Ios mismos entregabIes.
EntregabIes en esta etapa:

Actas de reuniones con eI cIiente (externo o interno).

Esquema pre - conceptuaI

ModeIo de dominio

ModeIo de procesos deI rea de mantenimiento.

TabIa expIicativa de Ios procesos.

TabIa de RegIas deI negocio.

GIosario deI probIema de negocio

Diagrama de objetivos.

Diagrama Causa Efecto.


26

Propuesta de SoIucin para eI CIiente.

2.- Diseo de Arquitectura. Despus de aceptada Ia propuesta de trabajo,


bien sea por Ios cIientes aI interior o aI exterior de Ia organizacin, se comienza con Ia
arquitectura de Ia soIucin. En este punto se conocen Ios intereses deI cIiente muy
bien, y existe un modeIo Pre -conceptuaI que faciIitar Ia creacin deI producto.
Por decisin de Ia empresa, Ios desarroIIos hechos se trabajan con Ias siguientes
herramientas informticas:

Enterprise

Architect

para

Ia

creacin

de

casos

de

datos

de

uso,

documentacin y rastreabiIidad deI proyecto.

Posgres

SQL

como

motor

de

base

para

Ia

impIementacin deI modeIo de datos.

Zend Framework, como bibIioteca de componentes que faciIitan Ia


impIementacin de apIicaciones web hechas en eI Ienguaje de
programacin PHP.

En caso de que sea una nueva impIementacin de software, Ios anaIistas eIaboran Ios
casos de uso y Ios prototipos a implementar, despus Ios prototipos son
aprobados por eI gerente de proyecto; en paraIeIo a esto eI DBA hace eI diseo de Ia
base de datos en un trabajo conjunto con Ios anaIistas.
Una vez terminados Ios casos de uso, Ios prototipos y Ia base de datos, se Ie
asigna a cada programador un mduIo, se reaIiza una reunin con cada
programador y se crea eI cronograma de trabajo.

3.- Codificacin. En este punto deI proceso ya se comienza Ia eIaboracin deI


producto como taI, paraIeIamente se hace un pIan de pruebas para ir revisando
punto por punto cada una de Ias funcionaIidades. EI orden es eI siguiente:
1. Se inicia eI desarroIIo por parte de Ios programadores, paraIeIamente eI
27

responsabIe de testing prepara un pIan de pruebas con base en Ios casos de


uso extendidos, apoyados en eI modeIo de Ia base de datos.
2. Cada desarroIIador se encarga de probar Ia funcionaIidad pedida. Para esto eI
desarroIIador es Iibre de ejecutar sus pruebas, ya que no existe un proceso
formaI para Ias pruebas unitarias.
3. FinaImente, cuando eI desarroIIador considera que un mduIo est terminado,
se Ie entrega aI tester eI producto en eI servidor de pruebas para que
comience con Ia verificacin y vaIidacin deI mduIo terminado.
4. FinaIizado eI desarroIIo por parte de Ios programadores, se ejecuta eI pIan de
pruebas por mduIo.
Durante Ia ejecucin deI pIan de pruebas se registran todos Ios errores
encontrados en un bug tracker, para ser revisados y corregidos. Cuando se corrigen
todos Ios errores reportados, se corre nuevamente eI pIan de pruebas para certificar
eI buen funcionamiento deI mduIo.

5. Despus de que un mduIo es verificado por eI tester, queda Iisto para


continuar en Ia siguiente etapa deI proceso software.
VaIe Ia pena acIarar que estos pasos son iterativos hasta Ia consecucin deI
producto compIeto, dentro deI tiempo estimado deI cronograma. En caso taI de que
un desarroIIador encuentre probIemas para cumpIir con su cronograma, se deben
revisar Ias etapas anteriores pues es un indicio de probIemas con eI diseo o Ia
estimacin reaIizada de Ia soIucin a entregarse.
EntregabIes en esta etapa:
PIan de pruebas
resuItados

con

sus

respectivos

28

MduIos
aprobados.

funcionaIes

Registro de Ios incidentes en eI Bug Tracker

4.- Pruebas de integracin. Lo que se busca conseguir en este punto es


Ia integracin de Ios diferentes mduIos programados. Esta etapa sueIe contener Ia
revisin deI modeIo de datos, ajustes aI programa integrador de Ios mduIos y Ia
ejecucin de Ias pruebas unitarias dentro deI contexto deI producto integrado.
EntregabIes en esta etapa:

PIan de pruebas ejecutado en eI programa con Ios mduIos integrados.

Documento de cambios aI modeIo de datos.

Producto compIeto Iisto para ser vaIidado con eI cIiente

5.1- Pruebas de validacin. Las pruebas de vaIidacin consisten en


comenzar a tomar datos reaIes deI cIiente para que ste vaIide que Ia informacin
entregada por eI sistema es Ia correcta. EI cIiente por medio de correos eIectrnicos
reporta Ios errores encontrados en Ia apIicacin. Se considera error todo aqueIIo que
no hubiese sido definido en Ia etapa de especificacin de requisitos.

5.2.- Mantenimiento. GeneraImente no se reaIizan cambios y mejoras a


Ios apIicativos. Estos cambios se reaIizan a peticin deI cIiente y se trabajan
reabriendo eI proyecto si eI cambio es de bajo impacto o reaIizando otra fase deI
proyecto si Ios cambios son significativos en eI apIicativo.

29

PERSONAS INVOLUCRADAS EN EL PROCESO


Para eI correcto funcionamiento de Ia compaa se identifican Ios siguientes roIes
en eI proceso software:
Gerente de proyecto.
AnaIista
Sistemas.

de

Diseador Web:
DBA.
Ingeniero
caIidad

Ingeniero

de

de

desarroIIo

RECURSOS Y CONOCIMIENTO DEL PROCESO


A continuacin se describen en ms detaIIe Ias diferentes actividades reaIizadas
durante eI proceso de desarroIIo de software de Ia organizacin estudiada,
reIacionando cada actividad con Ios recursos (humanos y fsicos) necesarios para Ia
ejecucin de cada etapa y eI conocimiento que se considera necesario para su
ejecucin.
EIaboracin deI contrato
y especificacin de
requisitos
Visita aI cIiente

Recurso

Conocimiento

PersonaI de
ventas,

qu hace eI apIicativo
y

Gerente de ventas

qu hace Ia empresa

30

Mejores prcticas de

Diagnstico

AnaIistas de

mantenimiento,

sistema,

ModeIamiento

Formatos de

UML,

evaIuacin ,

ModeIamiento de

Laptop de
Gerente

procesos

proyectos, Laptop,
cronograma de
impIementacin
PIan de trabajo

deI SW

Diseo de Arquitectura

Recurso

Gestin de proyectos.

Conocimiento

AnaIista de
sistemas,
documentador,

Arquitectura de Ia soIucin

Enterprise

ModeIado umI,

Architect,

manejo de

Posgres SQL,

tecnoIogas de

Zend

programacin y

Framework

documentacin
ModeIado
umI y
manejo

Primer acercamiento de
Ios Casos de uso

Enterprise
Architect
Diseador web,

de herramientas de
documentacin

Primer acercamiento de

Microsoft office

manejo de

Ios prototipos

point designer

herramientas para eI
manejode
deDatos
CSS
Bases
reIacionaIes,
Administracin de

ModeIo de Datos

DBA, PHP admin

Bases de datos.

31

Diseo DetaIIado

Recurso
AnaIista de
sistemas,

Casos de uso Extendidos

Enterprise
Architect web,
Diseador

Conocimiento
ModeIado umI y
manejo
de herramientas de
documentacin

Refinamiento de

Microsoft office

Manejo de

Ios prototipos

point designer

herramientas para eI
manejo dey CSS
Creacin

Refinamiento de Ia base
de datos

Codificacin

administracin de
DBA, PHP admin
Recurso
Ingeniero de
caIidad, Iaptop,

EIaboracin deI pIan

herramientas

de pruebas

ofimticas

base de datos

Conocimiento
MetodoIogas de
caIidad
de software,
conocimiento de
casos de uso
MetodoIogas de
programacin,

Ingeniero de

manejo de

desarroIIo, PHP

herramientas de

Programacin de Ios

admin, Zend

programacin,

mduIos

Framework,

conocimientos

Iaptop

bsicos de Ia base
MetodoIogas
de de
programacin,
manejo de
herramientas de

Pruebas unitarias

Ingeniero de

programacin,

desarroIIo, Zend

conocimientos

framework, PHP

bsicos de Ia base de

admin, Iaptop

datos, casos de uso


extendidos
32

MetodoIogas de
caIidad
de software,
Ingeniero de
caIidad, Iaptop,
herramientas
Ejecucin deI pIan de

ofimticas, bug

pruebas para cada mduIo

tracker

conocimiento de
casos de uso, manejo
de herramientas para
Ia gestin de errores,
casos de uso
extendidos
MetodoIogas de
programacin, manejo
de herramientas de

Correccin de bugs

Ingeniero de

programacin,

desarroIIo, Zend

conocimiento bsicos

framework, PHP

de Ia base de datos,

admin, Iaptop

casos de uso
extendidos
MetodoIogas
de
caIidad
de software,

Ingeniero de
Ejecucin deI pIan de

caIidad, Iaptop,

pruebas para Ios mduIos

herramientas

a Ios que se Ie corrigieron

ofimticas, bug

Ios bugs

tracker

conocimiento de
casos de uso, manejo
de herramientas para
Ia gestin de errores,
casos de uso
extendidos

33

Pruebas de integracin

Recurso

Conocimiento
MetodoIogas de
programacin, manejo

Ingeniero de

de herramientas de

desarroIIo, PHP

programacin,

Programacin de

admin, Zend

conocimiento bsicos

ApIicativo integrador de

Framework, Iaptop

de Ia base de datos

mduIos
Ingeniero de
caIidad, Iaptop,
Ejecucin de Ios pIanes de

herramientas

pruebas de cada mduIo

ofimticas, bug

en eI producto integrado

tracker

MetodoIogas de
caIidad
de software,
conocimiento de casos
de uso, manejo de
herramientas para Ia
gestin de errores,
casos de uso
extendidos

MetodoIogas de
programacin, manejo
de herramientas de

Correccin de bugs

Ingeniero de

programacin,

desarroIIo, Zend

conocimiento bsicos

framework, PHP

de Ia base de datos,

admin, Iaptop

casos de uso
extendidos

34

MetodoIogas de
caIidad
de software,
Ingeniero de
Ejecucin deI pIan de

caIidad, Iaptop,

pruebas para Ios mduIos

herramientas

a Ios que se Ie corrigieron

ofimticas, bug

Ios bugs

tracker

conocimiento de
casos de uso, manejo
de herramientas para
Ia gestin de errores,
casos de uso
extendidos

Pruebas de vaIidacin

Recurso

Conocimiento

AnaIista de
sistemas,

InstaIacin deI

herramientas

apIicativo,

ofimticas,

Conocimientos

Reunin con eI cIiente

EjecutabIes

generaIes deI uso deI

para Ia entrega deI

deI

apIicativo.

producto.
Acompaamiento
aI

apIicativo de
Ingeniero

MetodoIogas de

cIiente en Ia eIaboracin

caIidad, Iaptop,

caIidad de software,

deI pIan de vaIidacin

herramientas

conocimiento de casos

deI producto

ofimticas,

de uso

representantes
por parte deI
cIiente

Ejecucin de Ios pIanes

Ingeniero de

de vaIidacin

caIidad deI
cIiente
Ingeniero
de
desarroIIo,

Correccin de bugs

Zend

MetodoIogas de
caIidad
de software, manejo de
herramientas para Ia
gestin de errores
MetodoIogas de
programacin, manejo
de herramientas de
programacin

framework,
35

MetodoIogas de
caIidad
Ejecucin de Ios pIanes

Ingeniero de

de vaIidacin

caIidad deI

de software, manejo de
herramientas para Ia

cIiente
StakehoIders
y

gestin de errores

Gerente
deI
EIaboracin de acta

proyecto,

de finaIizacin deI

herramient

proyecto

as

Mantenimiento

Recurso
Equipo
ventas

Recepcin de peticiones
deI cIiente

Aspectos IegaIes

(encargado
de
reIaciones

Conocimiento

de
Manejo de
correo
eIectrnico. generaI
Conocimiento

AnIisis de impacto en

Gerente

de Ia apIicacin,

Ia apIicacin actuaI

de

Gestin de riesgos,

proyecto

de presupuestos,
EIaboracin
EIaboracin de
cronogramas

DesarroIIo de cambios
aceptados (Corre eI
proceso desde Ia etapa
de anIisis detaIIado para
cambios de impacto bajo y
desde eIicitacin de
requisitos si eI cambio es

NA

NA

de impacto aIto)

36

ANLISIS DEL PROCESO SOFTWARE ACTUAL


A Ia fecha de reaIizacin de este diagnostico en eI proceso software actuaI se
detectan tres importantes fortaIezas:

La eIicitacin de requisitos utiIizada, metodoIoga UN METODO,


faciIita eI entendimiento entre Ios cIientes y Ia empresa.

Investigacin, DesarroIIo y Capacitacin deI Departamento de


Sistemas hacen parte deI pIan de Ia organizacin.

UsuaImente cumpIen con Ios compromisos reaIizados con eI cIiente


con un aIto grado de satisfaccin por parte de eIIos.

Sin embargo, tambin se detectan cuatro grandes debiIidades en Ios procesos que
IIeva eI Departamento de Sistemas de Ia compaa, y estos son:

Una faIta en eI Servicio de Soporte y Mantenimiento, ya que muchas


veces Ios cIientes necesitan modificaciones aI software que se Ies
vendi y no existe un mecanismo formaI para evaIuar estas
modificaciones y tampoco se tiene previsto eI recurso para atender
a estas peticiones.

EI proceso de aseguramiento de caIidad deI producto est en


una etapa inmadura, actuaImente sIo se corre eI proceso de
pruebas.

La documentacin y formaIizacin de Ios procesos de Ia empresa


no se encuentran en un formato estndar, no existe un
repositorio centraI de

37

informacin y todava no hay poIticas muy cIaras sobre documentacin tanto


para eI diseo deI software como para Ios requisitos.

No se encontr evidencia de una medicin deI esfuerzo de Ia


organizacin para ejecutar Ios proyectos.

EVALUACIN DEL PROCESO SOFTWARE ACTUAL


A continuacin se puede observar Ia evaIuacin de niveI 2 de madurez deI
modeIo CMMI que se reaIiz a Ios procesos de Ia empresa; estos procesos
son: Requierements Management, Project PIanning, Project Monitoring and
ControI,

SuppIier

Agreement

Management,

Process and

Product QA y

Configuration Management. Las definiciones utiIizadas de esos procesos, dentro


deI contexto de esta evaIuacin estn basadas en Ias acepciones contenidas
en eI documento CMMI for DeveIopment, Version 1.2 y Ia caIificacin de 0 a 4
hace referencia a Ia carencia o niveI de desarroIIo/presencia deI proceso con
respecto a Ias prcticas genricas, especficas, objetivos genricos y especficos
deI modeIo CMMI.
Para eI entendimiento de Ia evaIuacin se expIica Ia escaIa vaIoracin utiIizada para
Ia misma:
1. No hay Prctica definida
2. Existe una prctica definida pero no est impIementada.
3. Existe una prctica definida e impIementada parciaImente.
4. Existe

una prctica definida e impIementada pero con resuItados

incompIetos
5. Hay practica definida, se apIica y con ptimos resuItados.

La caIificacin dar cuenta de Ia situacin actuaI deI proceso de Ia empresa, con


base en eI anIisis comparativo efectuado entre Ias prcticas y objetivos
pIanteados en eI modeIo y Ios procesos IIevados a cabo.
Se hizo una entrevista con Ias personas invoIucradas en eI proyecto y se hicieron
Ias observaciones respectivas por cada rea de proceso. La evaIuacin compIeta
puede revisarse en eI anexo 1 y compararse frente a Ia documentacin descrita deI
proceso software en eI presente documento.

RESULTADOS DE LA EVALUACIN
Los resuItados presentados a

continuacin resumen de manera grfica Io

encontrado despus de reaIizar Ia revisin y Ias entrevistas respecto aI modeIo


CMMI escaIonado en eI niveI 2, adicionaImente se busca acIarar un poco que
significa cada histograma para mayor comprensin deI Iector.

En cuanto eI rea de procesos de pIaneacin de proyectos, se tiene que Ia


empresa con reIacin a Ias practicas definidas por CMMI se encuentra en una
etapa de transicin, porque existen ciertas prcticas definidas e impIementadas, pero
eIIo no apIica para todos Ios proyectos evaIuados. Se puede decir que una mejora aI
trabajo de pIaneacin de proyectos ayudar a Ia administracin reaI de todos Ios
proyectos de Ia compaa.

Como consecuencia de no tener todas Ias prcticas deI rea de procesos de


pIaneacin de proyectos impIementadas, no es posibIe decir que se haga un
monitoreo efectivo deI pIan contra eI proyecto, sin embargo Ia organizacin objetivo
de estudio hace seguimiento contra eI cronograma y eI presupuesto de sus
proyectos, impIementando parciaImente eI objetivo generaI de monitoreo y controI.
Promover estas prcticas garantiza Ia rastreabiIidad de Ios proyectos en cuaIquier
punto de su ejecucin por Io que es conveniente garantizar su ejecucin.

Dentro de Ios procesos definidos organizacionaImente, eI apoyar a Ias empresas


cIientes en Ia consecucin de servicios tercerizados hace parte deI quehacer de Ia
compaa, sin embargo a Ia hora de evaIuar Ios proyectos, no fue cIara Ia manera
como esta organizacin gestiona Ios acuerdos con Ios proveedores de estos
servicios. Sin embargo aI no ser core de Ia compaa Ia prestacin de Ios mismos esta
prctica es secundaria su atencin.

EI proceso de aseguramiento de caIidad ejecutado por Ia compaa actuaImente


concentra sus esfuerzos en Ia prueba y deteccin de errores en Ia fase de
impIementacin de Ios productos software. OrganizacionaImente est definido que Ia
evaIuacin de procesos debe ser una de Ias tareas ejecutadas por Ia misma, sin
embargo durante Ia evaIuacin no se encontr evidencia de que esto se estuviera
reaIizando. AI tener una visin tangibIe de Ios proyectos es posibIe eIaborar un pIan
para Ia impIementacin de Ias prcticas definidas en esta rea de procesos.

Es posibIe encontrar un repositorio de cdigo en Ios proyectos que se evaIuaron, sin


embargo Ia gestin de Ia configuracin tiene prcticas que van ms aIIa de proteger
eI cdigo fuente de Ios desarroIIos reaIizados por Ia organizacin. ActuaImente Ia
empresa est haciendo un esfuerzo en Ia estandarizacin de procedimientos y
documentos de trabajo, Io que permite decir que hay una prctica definida para
aIcanzar Ios objetivos de esta rea de procesos, sin embargo no han sido
impIementados todava.
Segn Io expresado anteriormente, Ia evaIuacin reaIizada permite aseverar Ia
conveniencia que tiene para Ia empresa objeto de anIisis, Ia redefinicin, creacin e
impIementacin de varias de Ias prcticas sugeridas en eI modeIo de CMMI en eI niveI
2 de madurez.

Prioridad asociada. Dada Ia importancia que eI desarroIIo de sistemas


tiene en esta compaa, es necesario intervenir Ias debiIidades encontradas
en eI proceso de evaIuacin con una prioridad casi simiIar en Ios cuatro
aspectos evaIuados. Sin embargo para Ia consecucin se estabIecen como
prioridad de

impIementacin Ias reas de proceso de pIaneacin de proyectos y monitoreo y


controI de proyectos.

DEFINICIN DEL PROYECTO DE MEJORA


FinaIizada Ia etapa de diagnstico eI modeIo IDEAL sugiere que se reaIice un pIan de
trabajo detaIIado que estabIezca Ia manera en como eI esfuerzo de mejoramiento
va a ser impIementado. Este captuIo encierra Ias actividades de estabIecimiento de
prioridades y desarroIIo de una aproximacin.

UBICACIN CONTEXTUAL DEL PROYECTO


Como ya se ha visto en Ios captuIos anteriores, Ia empresa sobre Ia que se est
haciendo eI trabajo es una empresa de tamao pequeo (menos de 30
empIeados), orientada a brindar soIuciones integraIes en eI campo de Ingeniera de
Mantenimiento, haciendo uso de Ios sistemas de informacin como principaI
herramienta para Ia impIementacin de mejores prcticas de Ia ingeniera de
mantenimiento en Ias empresas cIientes.

La empresa dentro de sus procesos de

Gestin deI Conocimiento tiene un macro- proceso que se IIama DesarroIIo de


Software. ste contiene todo Io que considera

necesario

para

brindar

oportunamente soIuciones a Ias necesidades de sus cIientes.


La direccin de Ia empresa est consciente que para poder brindar una soIucin de
caIidad a Ios cIientes es necesario que eI proceso de desarroIIo de software sea un
proceso de CaIidad y se estn haciendo grandes esfuerzos por mejorar dicho
proceso.

OPORTUNIDAD DE MEJORA
ActuaImente Ia empresa busca mejorar su proceso interno de desarroIIo de sistemas.
Ha eIegido utiIizar CMMI como modeIo, para Ia optimizacin de este proceso
buscando principaImente IIenar Ias siguientes faIencias:

Brindar un mejor Servicio de Soporte y Mantenimiento a Ias empresas


cIientes

Tener un proceso unificado que garantice Ia caIidad deI producto


software eI cuaI juega un papeI protagnico en sus propuestas de
mejora a Ios cIientes.

Estandarizar y formaIizar eI proceso de desarroIIo de software que


IIeva Ia empresa por medio de documentacin cIara sobre eI
mismo y sobre Ios distintos desarroIIos.

Medir eI esfuerzo de Ios proyectos para estimar de una manera ms


acertada futuros proyectos.

VISIN DEL PROYECTO


Con eI proyecto se busca iniciar eI cambio organizacionaI necesario para eI
aseguramiento de caIidad deI proceso software que corre actuaImente en Ia
empresa investigada, dejando regIas cIaras para Ia impIementacin deI marco de
trabajo CMMI dentro de Ia empresa. AI finaI deI proyecto se deben estar
impIementadas e institucionaIizadas Ias reas de proceso de pIaneacin de
proyectos y monitoreo y controI de proyectos, para estar en capacidad de tener
cIaro eI camino a seguir para eI desarroIIo de proyectos que apunten aI
mejoramiento deI proceso software dentro de Ia organizacin, aI tiempo que deben
estar

Ias

bases

que

faciIiten

Ia

iniciacin

de

Ia

impIementacin

institucionaIizacin de Ias otras reas de CMMI que acrediten a Ia organizacin con


un niveI de madurez 2 o superior en eI modeIo escaIonado.

OBJETIVOS ESPECFICOS DEL PROYECTO


FortaIecer eI proceso de desarroIIo de software de Ia organizacin a
travs de Ia impIementacin de Ias reas de proceso de CMMI niveI
2, siguiendo eI camino escaIonado. (PIaneacin de Proyectos,
Monitoreo y controI de proyectos)

ReaIizar y ejecutar un pIan de comunicacin efectiva sobre eI


estado deI proyecto que faciIite a toda Ia organizacin eI estar
enterados de Ios distintos cambios de estructura, Ia importancia de
Ios mismos y faciIite eI uso de un Ienguaje comn entre Ios
empIeados.

Crear un punto de informacin centraIizado que faciIite Ia integracin


de Ias reas de proceso mencionadas en eI primer objetivo.

ImpIementar un sistema de gestin de eventos para eI manejo de


reportes de probIemas por parte deI cIiente.

Crear un nuevo proceso que garantice Ia continuidad de Ia


impIementacin de CMMI en Ia empresa, garantizando revisiones
peridicas a Ios objetivos definidos en Ia impIementacin.

CRITERIOS DE XITO
Este proyecto se considerar exitoso si aI finaI Ia empresa:

Tiene un proceso de pIaneacin de proyectos de software definido,


es decir, cumpIiendo con Ios requisitos para que su vaIoracin sea
CMMI niveI 2.

Tiene un proceso de Monitoreo y controI de Ios proyectos que


permite tomar Ias acciones correctivas en eI momento adecuado.

Las personas de Ia organizacin estn enteradas deI proceso de


impIementacin de CMMI, se encuentran comprometidas con eI
mismo y aI menos un 85% de Ios trabajadores entienden Ia

importancia de su continuidad.

VIABILIDAD DE LA SOLUCIN
Viabilidad del negocio. En principio se requiere capacitacin para eI Ider de
proyecto en temas reIacionados con Ia mejora de procesos organizacionaIes y CMMI.
Posteriormente se necesita conformar un equipo de 4 personas con aI menos 4
horas semanaIes de disponibiIidad durante Ia duracin deI proyecto para su ejecucin.
Se requieren computadores con herramientas de ofimtica para eIaborar Ios
entregabIes deI proyecto y contar con espacio en un servidor donde se faciIite
compartir Ia informacin de cada proyecto y en especiaI de Ios procesos que se
ejecutan en Ia empresa. ActuaImente Ia empresa cuenta con Ios activos fsicos
necesarios para cubrir Ios anteriores requerimientos.

Tiempo

Salario

MensuaI

S/.1.500.00

Diario

S/.30.00

Hora

S/.6.25
SaIario Promedio EmpIeados

Segn Ia informacin de Ia tabIa, en promedio Ia hora de Ios invoIucrados en eI


proyecto cuesta S/.6.250 soles, Io que equivaIe a un costo mensuaI de S/.1.500.00
Soles por persona trabajando en eI proyecto y de S/.2.000.00 soles mensuaIes para eI
Ider de proyecto. EI proyecto est pensado para impIementarse en un ao y su costo
totaI sera de S/.74.400.00 Soles.

En resumen, se tienen Ios siguientes costos deI proyecto:

COSTOS DEL PROYECTO


COSTOS DIRECTOS

COSTOS INDIRECTOS

Gerente de Proyectos/mensuaImente

2000

Uso de computadores

0
*

4000

Licencias Office
Espacio en Servidor

0
0
*
0
*

Miembros de equipo/mensuaImente
por 4 integrantes deI equipo

Internet
PapeIera

200

TOTAL COSTOS
TOTAL COSTOS DIRECTOS
6000
INDIRECTOS
200
*La empresa cuenta con estos activos fsicos actuaImente, y su coste mensuaI
se
COSTO TOTAL DEL
PROYECTO MENSUAL
COSTO TOTAL DEL
PROYECTO

6200
74400

TabIa de costos deI proyecto

Con respecto a Ios beneficios tangibIes resuItantes, se espera que Ia caIidad de Ios
productos desarroIIados por Ia empresa sea significativamente superior aI actuaI,
aI poder determinar todos Ios estados por Ios que pasa un proyecto. Ser ms giI Ia
respuesta a Ios cIientes con respecto a Ias necesidades de soporte y mantenimiento
pues aumentar Ia faciIidad aI identificar eI punto deI proceso donde debe hacerse
Ia modificacin soIicitada. Estarn en Ia capacidad de estimar ms precisamente Ia
duracin de proyectos futuros, basndose en Ia informacin de proyectos anteriores.
Se encontrarn en capacidad de mejorar eI proceso que hayan definido aI hacer
revisin sobre Ios procesos documentados.

Para cuantificar Ios beneficios obtenidos aI mejorar Ia caIidad de un proceso, se


depende de factores como Ia faciIidad para estimar proyectos, mejor caIidad de
producto, mayor satisfaccin de Ios cIientes, incremento de Ia productividad, mejora de
Ia predictibiIidad deI cronograma, entre otros, evidentemente aumentando Ia reIacin
costo/beneficio aI conseguir nuevos cIientes teniendo un producto de mejor caIidad
y un mejor servicio de mantenimiento. En eI mejor escenario, si Ia empresa
adquiere 1 cIiente ms en eI ao aI Iograr reducir eI tiempo de rediseo en Ia
etapa de codificacin en un 10% e invertirIo en Ios nuevos cIientes, se obtiene un
beneficio de S/.11630.00 Soles. La reIacin beneficio/costo ser entonces:
Beneficio/Costo = 1.56.

Este resuItado nos orienta a que es una inversin aceptabIe. As como una mayor
capacidad de respuesta ante Ios diferentes cIientes y un conocimiento ms tangibIe
de Ios procesos de Ia organizacin se pueden evidenciar aI trmino deI proyecto.
AdicionaI a esto, si no se impIementa un proyecto de este tipo es muy probabIe que
en Ia medida que crezca Ia compaa, eI proceso de sistemas se convierta en un
cueIIo de boteIIa para Ia misma.
ImpIementar un marco de trabajo para eI aseguramiento de Ia caIidad deI producto
tiene siempre ventajas y desventajas, comparando Ia impIementacin de esta
soIucin frente a su par ISO 9000:2008 encontramos que CMMI hace nfasis en Ia
institucionaIizacin de Ia metodoIoga de trabajo, aIgo que ISO 9000 parece dar por
obvio. AdicionaImente, existen muchas empresas certificadas en ISO 9000 por tener Ia
documentacin de sus procesos aunque no sea Io que se apIica en Ias mismas,
mientras que Ia vaIoracin CMMI indaga por Ia apIicacin de Ios procesos en Ios
proyectos. Estos dos factores diferenciadores IIevan a eIegir CMMI sobre ISO para
este proyecto en especfico.

70

Se pretende impactar toda Ia organizacin a niveI cuIturaI para orientarIa hacia una
mentaIidad de caIidad de procesos. Esto impIica cambiar Ia cuItura organizacionaI,
una de Ias cosas que quiz son ms difciIes de hacer en empresas de tamao
mediano o grande, sin embargo, por eI nmero de personas que trabajan en Ia
empresa y su rango de edad, hace que Ia inercia organizacionaI no sea tan difciI de
romper.
En principio, Ia estructura organizacionaI con Ia que se cuenta ha de adaptarse a Ias
necesidades deI proyecto. Sin embargo, es posibIe que para mejorar Ios procesos
en un futuro sea necesaria una nueva estructura deI proceso de desarroIIo de
software de Ia empresa.
Viabilidad tcnica. La compIejidad de este tipo de proyectos radica en Ia resistencia
aI cambio que se puede presentar dentro de Ias organizaciones aI pasar de hacer
un trabajo individuaI Io mejor que se puede, a hacer un trabajo en

equipo

compIetamente, pero es necesario eI cambio de metodoIoga para poder aIcanzar Ios


beneficios que eI CMMI ofrece. Sin embargo, para nuestro caso, esta compIejidad se
reduce debido aI tamao de Ia empresa. TecnoIgicamente Ia Iimitante sera eI
garantizar un entendimiento de CMMI en Ia compaa. No hay aspectos crticos
reIacionados con eI tiempo, eI proceso puede ser intervenido en eI momento que Ia
empresa considere pertinente.
Es importante que eI Ider deI proyecto conozca muy bien eI marco de trabajo de
CMMI para una correcta impIementacin y evitar contratiempos en Ia entrega de Ios
distintos productos de trabajo deI proyecto. FinaIizado eI proyecto, eI xito deI mismo
puede medirse por medio de una vaIoracin CMMI nuevamente aI finaI deI proyecto.
UtiIizar eI marco de trabajo para Ia vaIoracin de CMMI correctamente garantiza Ia
caIidad deI producto.

Se estima que compIetado correctamente eI proyecto, ste tenga una vigencia de 3


aos.
71

Viabilidad del proyecto. ActuaImente se cuenta con eI apoyo de Ia aIta gerencia


de Ia empresa, hay un compromiso verbaI que despus de aceptado eI proyecto se
convertir en un compromiso formaI. Ya que eI proyecto interviene Ia forma como se
ejecutan Ios proyectos en Ia empresa, no se evidencia ninguna Iimitante temporaI,
horaria o de taIento humano para Ia ejecucin deI mismo.
EI conocimiento est disponibIe en aIgunos de Ios trabajadores de Ia empresa, sin
embargo hay que reforzar esto con Io mencionado en Ia viabiIidad deI negocio.

Las

expectativas y Ios resuItados deI proyecto son compIetamente aIcanzabIes siempre


y cuando no se descuide Ia parte de monitoreo sobre eI proyecto, pues ste es muy
sensibIe a cambios negativos en Ia cuItura organizacionaI. HabIando de

Ia

comunicacin

Ia

deI

proyecto,

Ia

organizacin

debe

garantizar

que

comunicacin interna entre Ios integrantes deI proyecto sea adecuada a Ias
necesidades de Ia organizacin. Con respecto a Ia comunicacin externa, hacia Ios
empIeados de Ia organizacin, ser desarroIIada dentro deI proyecto.

ACCIONES PROPUESTAS
A continuacin se enuncian en orden de ejecucin, Ias acciones propuestas para
comenzar Ios diseos de Ios procesos.
Accin 1

Enfoque
Solucin
objetivo

Documentacin y formaIizacin deI proceso de


desarroIIo
Creacin de mecanismos para Ia documentacin
Tener unificada Ia informacin disponibIe para quien
Ia

Beneficios

necesite
PosibiIidad de hacer mejoras aI proceso software y a
Ios
proyectos

72

Comenzar proyectos ms oportunamente gracias a


Ia
disponibiIidad de informacin
Escoger un modeIo de proceso software que se
acerque
Acciones

aI funcionamiento actuaI de Ia empresa


Disear eI proceso software de acuerdo con eI modeIo
de
proceso eIegido
CIasificar Ios distintos tipos de proyectos dentro
deI
proceso software
ImpIementar un punto centraIizado para Ia gestin de
Ia
Informacin
Definir poIticas organizacionaIes para Ia creacin
de
documentacin
Revisar peridicamente Ia documentacin, respaIdar
Ia
informacin no vigente.
ActuaIizar Ia tipoIoga de proyectos cada vez
que
encuentren un proyecto nuevo

Accin 2

Enfoque

Medir esfuerzo en Ios proyectos

Solucin
objetivo

PA PIaneacin de proyectos
Tener

Beneficios

histrico
con

de

Ios

proyectos

reaIizados

documentacin estndar
Identificar riesgos deI proyecto antes de que
se
materiaIicen
Revisin integraI deI proyecto antes de su ejecucin.
Diseo
de

proceso
de

gesti
n

d
e

riesg
os

par
a

u
n

proyecto
73

Definir documentacin estndar dentro deI proyecto


y
Acciones

guardarIa en un punto centraIizado


Revisar
todos
Ios
pIanes
(aIcance,

reaIizados

presupuesto, cicIo de vida, gestin de datos, pIan


de

nuevo

conocimiento

necesario)

antes

de

comenzar eI proyecto

Accin 3

Enfoque

Medir esfuerzo en Ios proyectos

Solucin
objetivo

PA Monitoreo y controI de proyectos


Corregir a tiempo probIemas dentro deI proyecto

Beneficios

Reafirmar compromisos con Ios invoIucrados en


eI
proyecto
Entrega a tiempo de Ios proyectos
Basado en eI proceso software definir Ios puntos
de
revisin a Ios pIanes reaIizados
ReaIizar evaIuacin peridica deI estado deI proyecto

Acciones

LIevar registro de Ias acciones correctivas dentro


deI
proyecto
AnaIizar Ios probIemas encontrados en eI proyecto
y
documentar Ias causas

74

CONCLUSIONES

La aplicacin de las prcticas en los procesos, partiendo de las


sugeridas por

el modelo CMMI, permitir la optimizacin de los

esfuerzos requeridos en cada proyecto que se desarrolle en la empresa


objeto de estudio, en la medida en que existirn previamente guas de
trabajo y plantillas de procesos sugeridos, a partir de la propuesta
contenida en este trabajo, que representar eficiencia en el da a da
de la empresa y la ejecucin de cada uno de los procesos de
desarrollo de software.

La implementacin de las prcticas vinculadas a la propuesta


contenida en este trabajo, implica la modificacin de los procesos de
desarrollo de software que la empresa estudiada ha tenido hasta la
fecha, especficamente en torno al desarrollo de un procedimiento
organizado y sistematizado, a partir de las prcticas sugeridas con
base en el modelo CMMI, y por tanto, representa la adopcin de
ciertos cambios organizacionales y metodolgicos, que en todo caso
requieren el compromiso de los agentes de la empresa y la inversin de
los activos corporativos necesarios para ello, destinados a la
adaptacin y establecimiento de esos procedimientos diferenciales
propuestos.

La propuesta formulada en este trabajo resulta viable para la


organizacin a la que se realiz este estudio, en la medida en que est
diseada especficamente para impactar dos reas de procesos, en
este caso, el de planeacin de proyectos y el de monitoreo y control,
constituyndose el primero en una etapa inicial y el segundo en un
rea de proceso de carcter transversal, dirigidos a emprender
104

gradualmente

la

implementacin

de

las

prcticas

de

calidad

sugeridas por el modelo CMMI. De esta manera, se puede concluir


que esta propuesta resulta viable, adems, en razn de que los costos
econmicos que la misma implica son accesibles, y prioritariamente,
porque le asiste genuino inters a la empresa para acoger, o bien para
considerar, la propuesta que se presenta.

A la fecha de presentacin de este proyecto podemos concluir que la


organizacin objetivo se encuentra en el adelantamiento de etapas
importantes vinculadas al mejoramiento de sus prcticas en los
procesos de desarrollo de software, con la adopcin de la propuesta
que en este proyecto se sugiere. En todo caso, ese proceso de
mejoramiento de sus prcticas se ver representado en mayor
competitividad en el mercado que ocupa su objeto social.

105

ANEXO 1. EVALUACIN DE LA ORGANIZACIN


Para el entendimiento de la siguiente evaluacin se determin que la valoracin ser
de 0 a 4, donde cada valor significa:
1. No hay Prctica definida
2. Existe una prctica definida pero no est implementada.
3. Existe una prctica definida e implementada parcialmente.
4. Existe

una prctica definida e implementada pero con resultados

incompletos
5. Hay practica definida, se aplica y con ptimos resultados.

Req. Management
Specific Goal

Specific Practice \ Score

Observacione
s

106

Se evidencia
conocimiento
de los
requisitos en
SP 1.1 Obtain

la mayora

SP 1.

an

de proyectos

Manage

Understanding

Requiremen

of

evaluados
Existen

ts

documentos
de
entendimient

SP 1.2 Obtain
Commitment to
Requirements

o entre el
cliente y la

107

Se tienen
registros de
los cambios
SP 1.3 Manage

solicitados en

Requirements Changes

los proyectos
Se tienen
registros de
los cambios
solicitados en

SP 1.4 Maintain
Bidirectional Traceability

los proyectos

of Requirements

Existe la
poltica

SP 1.5 Identify

organizacional

Inconsistencies

pero no hay

Between Project Work

evidencia de

and Requirements.
Generic Practice \ Score

X
0

su
2

implementaci
Observacione
s
Se ejecutan

GP 1.

1.1 Perform

Achieve

Specific Practices

la
X

mayora

de

Specific

prcticas

Goals

Existe la

las

poltica
organizacional
pero no es
2. Institutionalize
a
Managed
Process

ampliamente

2.1 Establish an
Organizational Policy

conocida

2.2 Plan the Process

El proceso se

planea antes
de
su ejecucin
Existen las
herramientas
necesarias
para la
X ejecucin de

2.3 Provide Resources

este
proceso
Existen
lideres
visibles en
2.4 Assign Responsibility

la
ejecucin
No en todos
los
casos se
provee
entrenamient
o a las
personas

2.5 Train People

que hacen

parte de un
No hay
evidencia de
una gestin
de tems de
2.6 Manage Configurations

configuraci
n
Hay
registro de
involucramien
to de los
actores

2.7 Identify and


Involve Relevant
Stakeholders

principales en
el proceso

No hay
evidencia de
un monitoreo
2.8 Monitor and Control the
Process

en la
X

ejecucin del
proyecto
No
hay
evidencia de
una
evaluacin

2.9 Objectively
Evaluate Adherence

del proceso
X

en los
proyectos

Project Planning

Specific Goal

Specific Practice \ Score

4 Observacione
s
No se define
previamente
el alcance
del proyecto
por mtodos
de

SP 1.1 Estimate the


SG 1

Scope of the Project

estimacin

Establish

formales.

Estimates

Se estiman
claramente
SP 1.2 Establish

cules son

Estimates of Work

las

Product and Task


Attributes

actividades
a realizar.
La
metodologa

utilizada para la
elicitacin de
requisitos les
garantiza definir
un ciclo de vida
del proyecto.
SP 1.3 Define
Project Lifecycle

X
La metodologa
utilizada para la
elicitacin de
requisitos les
garantiza definir

SP 1.4 Determine

un ciclo de vida

Estimates of Effort and

del proyecto.

Cost

Los proyectos
evaluados
cuentan con
un

SG 2 Develop

SP 2.1 Establish the Budget

a Project

and Schedule

cronograma
X

Plan

presupuesto
No
todos los
proyectos
tienen un plan
SP 2.2 Identify Project
Risks

de riesgos.
Se evidencia
planeacin en
la

SP 2.3 Plan for Data


Management

documentaci
n y actas de

reuniones
dentro
del proyecto.
No todos los
proyectos
SP 2.4 Plan for
Project Resources

tienen un plan
X

de recursos.
Se sobreestima
la cantidad de
personas
necesarias
para un
proyecto.
Adicionalment
e no se
evidencia
planeacin de

SP 2.5 Plan for


Needed Knowledge

las
X

and Skills

habilidades
por hay
las
No
evidencia de
un plan de
involucramient
o de las
personas
vinculadas al

SP 2.6 Plan
Stakeholder

proyecto
X

Involvement
SP 2.7 Establish the
Project Plan

(externos e
internos).
No
en todos los

proyectos
112

evaluados
existe
un plan
de
Aunque las
revisiones de
los planes de
proyecto se
realizan, no
hay evidencia
fsica de dicha
revisin.
Adicionalment
SG 3 Obtain

e, no se hace

Commitment to

SP 3.1 Review Plans

the Plan

That Affect the Project

para todos los


X

proyectos.
No todos los
proyectos
muestran
evidencia de
haber
conciliado el
trabajo con

SP 3.2 Reconcile Work

las personas

and Resource Levels

ejecutar.
No
hay

SP 3.3 Obtain Plan


Commitment

que lo van a

evidencia de
que las
personas
involucradas
con
113

el proyecto
estn
comprometid
as con el
plan de
Generic Practice \ Score

proyecto.
Observacione
s
No todas las
prcticas
especficas

1. Achieve

1.1 Perform Specific

Specific Goals

Practices

estn
X

implementada
s. poltica que
La

2. Institutionalize

2.1 Establish an

a Managed

Organizational

Process

Policy
2.2 Plan the Process

se tiene no
se utiliza.

El proceso no
X

est definido.
No hay forma
de
identificar si
los recursos

2.3 Provide Resources

son

asignados de
Las
resposabilidade
s son
asignadas
pero no se
tiene encuenta

2.4 Assign Responsibility

las habilidades
de las
114

No se ejecuta
el
entrenamiento
2.5 Train People

de las

personas para
No se maneja
un control
de versiones
para los
2.6 Manage Configurations

planes de

proyecto
No
existe
un
involucramien

2.7 Identify and


Involve Relevant

to

de

las

personas
No hay

Stakeholders

en

monitoreo del
2.8 Monitor and Control
the Process

proceso ya
X

que no esta
definido
No
se hace una

2.9 Objectively
Evaluate Adherence

evaluacin
X

del proceso.

Project monitoring and control


Specific Practice \
Specific Goal

Score

3 4

Observacione
s

SP 1.1 Monitor

Hay una

SG 1 Monitor

Project Planning

poltica

Project Against

Parameters

Plan

definida,
pero
115

no hay
evidencia de
un monitoreo
de los
parmetros
del proyecto.
Hay
una
poltica
definida, pero
no hay
evidencia de
un monitoreo
de los
SP 1.2 Monitor
Commitments

compromisos
X

del proyecto.
Hay una
poltica
definida, pero
no hay
evidencia de

SP 1.3 Monitor

un monitoreo

Project Risks

de los
X

riesgos del
proyecto.
Hay
una
poltica
definida, pero
no hay
evidencia de

SP 1.4 Monitor
Data
Management

un monitoreo
X

de la gestin
de los
116

datos de los
proyecto
s
evaluado
No
se
encuentra
evidencia de
un monitoreo
SP 1.5 Monitor

del

Stakeholder

involucramien

Involvement

to de los
actores
No
se
encuentra
evidencia de
las revisiones
realizadas
del progreso

SP 1.6 Conduct
Progress Reviews

de los
X

evaluados

SP 1.7 Conduct
Milestone Reviews

proyectos

X
No se
encuentra
evidencia de
las
revisiones
realizadas
del los hitos
en los

SG 2 Manage Corrective

SP 2.1 Analyze

proyectos
No se

Action to Closure

Issues

encuentra
evidencia del
anlisis de
las
problemtica
que afectan
los proyectos
revisados
Hay
una
poltica
definida,
pero no hay
evidencia de
cmo se
realizaron las

SP 2.2 Take

acciones

Corrective Action

correctivas
No hay
evidencia de
una gestin

SP 2.3 Manage
Corrective Action
Generic Practice \ Score

de acciones
X
0

correctivas
1

4 Observacione
s
Algunas de

1.1 Perform
1. Achieve Specific Goals

las prcticas

Specific Practices

son
realizadas

2. Institutionalize a

2.1 Establish an

Managed Process

Organizational

Existen
X

polticas, sin

Policy

embargo estas
no son muy
conocidas
No hay
evidencia de
planeacin en

2.2 Plan
the

este proceso

Process

Las
herramientas
existen, pero
no hay
evidencia de
que sean

2.3

utilizadas

Provide

correctament

Resourc

e en evidencia
este
Hay
de que se
asignan
correctament
e, a las
personas
que les

2.4 Assign

corresponde

Responsibility

n, las
acciones
Existe
un
procedimient
o, pero no
hay

2.5 Train People

evidencia de
entrenamien

en este
proceso
No hay
evidencia de
gestin de
tems de
2.6 Manage
Configuratio

configuracin
X

en este

ns

proceso
Hay
una
identificaci
n parcial de
los actores
relevantes,

2.7 Identify

no en todos

and Involve

los

Relevant

Stakeholders

hay
No
hay
evidencia

2.8 Monitor and


Control the Process

proyectos

de
monitoreo
No hay
evidencia

2.9 Objectively
Evaluate
Adherence

Supplier Agreement Management

de
X

evaluacin
de este

Specific Practice \
Specific Goal

Score

3 4

Observacione
s
Confidencial

SG 1 Establish

SP 1.1 Determine

Supplier Agreements

Acquisition Type

SP 1.2 Select Suppliers

SP 1.3 Establish

Confidencial

Supplier Agreements
SG 2 Satisfy

SP 2.1 Execute

Supplier

the Supplier

Agreements

Agreement
SP
2.2 Monitor Selected

Confidencial

X
Confidencial
X
Confidencial

Supplier Processes

SP 2.3 Evaluate

Confidencial

Selected Supplier
Work Products

SP 2.4 Accept the

Confidencial

Acquired Product

SP 2.5 Transition

Confidencial

Products
Generic Practice \ Score

X
0

1. Achieve

1.1 Perform

Specific Goals

Specific Practices

2. Institutionalize a

2.1 Establish an

Managed Process

Organizational Policy

2.2 Plan the Process

3 4 Observacione
s
Confidencial

X
Confidencial
Confidencial

2.3 Provide Resources

2.4 Assign
Responsibility
2.5 Train People

Confidencial
X

Confidencial

Confidencial

2.6 Manage

Confidencial

Configurations

2.7 Identify and Involve

Confidencial

Relevant Stakeholders

2.8 Monitor and Control

Confidencial

the Process

2.9 Objectively Evaluate

Confidencial

Adherence

Process and Product QA


Specific Practice \
Specific Goal

Score

Observacione
s
Confidencial

SG 1 Objectively
Evaluate

SP 1.1

Processes and

Objectively

Work Products

Evaluate
SP
1.2 Objectively

X
Confidencial

Evaluate Work
Products and
Services

SP 2.1

Confidencial

Communicate and
Ensure Resolution
SG 2 Provide

of Noncompliance

Objective Insight

Issues

SP 2.2 Establish
Records
Generic Practice \ Score

Confidencial
X
0

1. Achieve

1.1 Perform

Specific Goals

Specific Practices

Confidencial
X

2.1 Establish an
Organizational Policy
2.2 Plan the Process

Confidencial
X
X

Confidencial

2.3 Provide

Confidencial

Resources

2.4 Assign

Confidencial

Responsibility
2.5 Train People
2. Institutionalize

2.6 Manage

a Managed

Configurations

Process

2.7 Identify and

4 Observacione
s

X
X

Confidencial
Confidencial

X
Confidencial

Involve
Relevant

Stakeholders
2.8
Monitor and
Control the Process

Confidencial
X

2.9 Objectively
Evaluate Adherence

Confidencial
X

Configuration Management

Specific Practice \
Specific Goal

Score

SG 1 Establish

SP 1.1 Identify

Baselines

Configuration Items

Observacione
s

Confidencial
X

SP 1.2 Establish a

Confidencial

Configuration
Management System

SP 1.3 Create or

Confidencial

Release Baselines
SG 2 Track

SP 2.1 Track

and Control

Change Requests

Changes

SP 2.2 Control

X
Confidencial
X

Configuration Items

X
Confidencial

SP 3.1 Establish
SG 3

Configuration

Establish

Management

Integrity

Records
SP
3.2 Perform
Configuration Audits

Generic Practice \ Score

Confidencial
X
Confidencial
X
0

4 Observacione
s

1. Achieve

1.1 Perform

Specific Goals

Specific Practices

2. Institutionalize a

2.1 Establish an

Managed Process

Organizational Policy
2.2 Plan the Process

Confidencial
X
Confidencial
X
X

Confidencial

2.3 Provide Resources


2.4 Assign

Confidencial

Confidencial

Confidencial

Responsibility
2.5 Train People
2.6 Manage
Configurations

Confidencial
X

2.7 Identify and Involve


Relevant Stakeholders
2.8 Monitor and
Control

Confidencial
X
Confidencial
X

the Process
2.9 Objectively
Evaluate Adherence

Confidencial
X

También podría gustarte