Introduccin

El desarrollo del software hoy en da no es una actividad meramente

artesanal y que se basa nicamente en el grado de experiencia del equipo de
desarrollo. El software que se crea actualmente es cada vez ms complejo y
exige tener mtodos y procesos cada vez ms rigurosos que permitan tener un
seguimiento ms cercano, pero que al mismo tiempo permitan tener un control
estricto sobre cada etapa que constituye el proceso de desarrollo de software.
Las empresas orientadas al desarrollo persiguen posicionarse en el mercado
mediante la creacin de productos de calidad as como tambin un servicio al
cliente que las diferencien de sus posibles competidores; para esto es
necesario el uso de un modelo de mejora que permita gestionar las actividades
y procesos desde la etapa inicial de desarrollo hasta la entrega del producto al
cliente. Por tal motivo se presenta el siguiente proyecto de investigacin que
cosiste en una propuesta de implementacin del modelo de mejora CMMI de
Servicios en el Nivel 2, en el cual se abordaron los captulos que se mencionan
a continuacin:
En el Captulo I se presenta informacin general de la empresa, como lo son:
antecedentes, descripcin del departamento de donde se realizaron las
residencias, localizacin misin y visin, la ubicacin geogrfica, as como
tambin el marco terico referente al presente proyecto.
En el Captulo II se refiere a la metodologa, es decir al conjunto de
procedimientos y actividades que se siguieron para alcanzar el objetivo general
anteriormente planteado.
En el Captulo III se enfoca al diseo de la propuesta de implementacin
para alcanzar el Nivel 2 de CMMI de servicios, que incluyen una serie de
formatos que servirn como estndares para medir y controlar cada etapa del
proceso de desarrollo.

Justificacin
La empresa Intekel Automatizacin se dedica a la automatizacin mediante
el desarrollo de software y la utilizacin de diversas tecnologas.
El origen del proyecto surge por la necesidad de proporcionar una posible
solucin a los problemas que presenta la empresa al llevar el control de cada
proyecto por separado; dicha solucin est constituida por un modelo de
mejora continua que se capaz de medir y controlar todos los proyectos en sus
diferentes etapas de desarrollo.
La propuesta que se pretende realizar mediante este proyecto es que la
empresa Intekel Automatizacin adopte el modelo CMMI de servicios en el
Nivel 2, con el fin de obtener procesos definidos, pero principalmente
gestionados y estandarizados, lo que garantizar tener un mejor control de los
proyectos a lo largo de su ciclo de desarrollo.
Al realizar la adopcin de un Modelo de Capacidad y Madurez Integrado
(CMMI) no solo se solucionaran los problemas que afectan el correcto
funcionamiento de la empresa sino que tambin se obtendran beneficios tales
como la fcil comunicacin y entendimiento entre los miembros del equipo que
estn involucrados en el desarrollo del proyecto, as como tambin la reduccin
de tiempo de desarrollo y sobretodo crear un software que se apague a las
necesidades y caractersticas del cliente.

Objetivo General
Hacer una propuesta de implementacin del modelo CMMI de Servicios
Nivel 2 en la empresa Intekel Automatizacin, con el fin de proponer una
solucin a los problemas que existen en la empresa al controlar y planear los
proyectos.
Disear estndares, documentacin y planeacin de los diferentes
procesos y proyectos de Intekel Automatizacin implementando el
modelo CMMI de Servicios Nivel 2, con el fin de priorizar acciones en la
mejora de procesos de la empresa y enfatizar la alineacin de los
procesos de acuerdo a los objetivos que se tienen planeados dentro del
plan de negocio de la empresa

Objetivos Especficos
1.-Conocer las etapas que conforman el proceso de desarrollo de software,
as como tambin las actividades correspondientes a cada etapa.
2.- Utilizar la metodologa CMMI para lograr una mejora continua de los
procesos

al

realizar

su

respectiva

documentacin,

organizacin,

divulgacin y capacitacin de los mismos que servirn como estndares

para medir y controlar cada actividad perteneciente al proceso de
desarrollo de proyecto, mismos formatos que facilitarn el cumplimiento
de las practicas especficas que indica el Nivel 2 del Modelo CMMI de
Servicios.

CAPTLO I. MARCO
REFERECIAL
TERIC

En este primer captulo se presenta toda la informacin relacionada con la

empresa Intekel Automatizacin, esto con el fin de conocer cules son sus
objetivos y delimitar con exactitud la problemtica que se pretende resolver, As
como tambin se presenta el marco terico referente a este proyecto.
1.1 Antecedentes
La empresa comienza en 2007 con registro como persona fsica, y a partir
de noviembre del 2013 se est iniciando una nueva etapa como una empresa
S.A. de C.V., bajo el nombre de Intekel Tecnologa de Automatizacin
Industrial, con el propsito de ampliar expectativas y la oferta de servicios a
nuestros

clientes

Ilustracin 1 Historia de Intekel Automatizacin

La filosofa de atencin a los clientes de Intekel y crecimiento se basa en

adoptar modelos de calidad.
Intekel Automatizacin es socio fundador del Clster IT Veracruz en Energa
ENTIC.
Pgina Web: www.intekel.com

1.1.1

rea de Trabajo

Departamento de Calidad

DIRECCIN GENERAL

Direccin Administrativa

Departamento de Calidad

Ilustracin 2 rea de trabajo

El rea de trabajo est directamente relacionada con el aseguramiento de la

calidad de los productos, y tiene como principal objetivo la satisfaccin del
cliente.
Una de las funciones que van aunadas a este departamento de calidad es
asegurar el establecimiento, implementacin y la preservacin de los procesos
necesarios

para

elaborar

necesidades de los clientes.

productos

que

satisfagan

plenamente

las

1.1.2 Descripcin del rea de Residencia

Actualmente se encuentra laborando en el departamento de Calidad que es
un departamento subordinado de la Direccin Administrativa, algunas de las
actividades principales de este departamento son; realizar encuestas de
satisfaccin del cliente y el anlisis posterior a estas encuestas realizadas,
asegurarse de que se cumpla con los objetivos pactados, as como tambin
garantizar la calidad de los productos de acuerdo con la usabilidad y
funcionabilidad de stos.

1.2 Localizacin de la Empresa (Croquis y Direccin)

Empresa Intekel Tecnologa de Automatizacin Industrial, S.A. de C.V.
Domicilio: Francisco Gonzales Bocanegra 508, Puerto Mxico, 96510 Coatzacoalcos.
Telfonos: +52 (921) 171 4626 / +52 (921) 163 249

Ilustracin 3 Ubicacin de la Empresa

1.3 Organigrama
EMPRESA INTEKEL TECNOLOGA DE AUTOMATIZACIN INDUSTRIAL
DE S.A. DE C.V.

Ilustracin 4 Organigrama de la empresa

1.4 Misin y Visin

1.4.1 Misin
Somos una compaa especializada en el desarrollo de software y
automatizacin de procesos industriales que trabaja en disear e implementar
soluciones tecnolgicas que brinden ventajas competitivas a nuestros clientes.
1.4.2 Visin
Ser una compaa competitiva en Mxico y en el extranjero, sostenible, con
capacidad de innovacin y espritu de emprendimiento; y motivo de orgullo de
las personas que forman parte.

1.5 Giro de la Empresa

Intekel Tecnologa de Automatizacin Industrial, S.A de C.V es una empresa
especializada en el rea de Software y Automatizacin para el sector industrial,
logstica, petrleo y energa.

1.6 Delimitacin del Problema

Intekel Automatizacin es una empresa que se dedica al desarrollo de
Software, as como tambin a la automatizacin para diversos sectores como lo
son; el sector industrial, logstico, petrolero y energtico.
Durante los ltimos meses el nmero de proyectos que desarrolla la
empresa Intekel Automatizacin ha incrementado, pero al suceder esto,
tambin han incrementado los inconvenientes para controlar cada proyecto por
separado. Los inconvenientes que se tiene principalmente se han encontrado
en el rea de 1.planeacin, ejecucin y cierre de dichos proyectos, lo que tiene
como consecuencia que el cierre de estos presente demoras y traiga consigo
perdidas en tiempo y dinero.
Estos problemas se han dado generalmente por que no se cuenta con un
2.modelo de gestin que permita hacer ms eficientes las actividades
relacionadas con cada etapa del desarrollo de los proyectos, as tambin se
entiende que la 3.falta de planeacin, organizacin y control tiene mucho que
ver con la causa de estos problemas
NOTA DE RESALTADO DE TEXTO:
1. Son las diferentes reas que manejamos en el departamento de
Operaciones, en el depto., tiene inconvenientes porque no se cuenta
con los documentos que ayuden en el proceso de levantamiento de
requerimiento, de planeacin (Project Plan, Costos, Recursos
Humano, Tiempo), control de cambio (se refiere cuando el cliente
desea un nuevo cambio y el cliente tiene la mentalidad que se
contempl en la cotizacin o contrato, tal cambio tiene costo), cierre
de proyecto (Entrega del proyecto y aceptacin por parte del

cliente),.ANEXARE EL CICLO DE VIDA DE INTEKEL, TODO VA

CONFORME A LA METODOLOGIA DE CMMI
2. Actualmente Intekel no cuenta con un modelo de gestin de
proyectos por eso se va implementar el modelo de CMMI
3. El no tener una gestin de proyectos o control a la empresa le
genera conflicto internamente y externamente. La gestin de los
proyectos es para que sepamos cmo van los diferentes proyectos
que tiene la empresa

1.7 Fundamento Terico

Los conceptos generales asociados con los temas de la investigacin para el
desarrollo del presente proyecto son los siguientes:
1.7.1 Que es el CMM?
El Modelo de Madurez de Capacidades es un modelo de referencia para la
aplicacin de conceptos de gestin de procesos y de mejora de calidad en el
desarrollo y mantenimiento de software, que deben ser implementadas por toda
organizacin interesada en desarrollar y mejorar la calidad de sus productos y
su productividad.

Este modelo est basado en conceptos de calidad total y de mejoramiento

continuo y ha sido desarrollado en el SEI (Software Engineering Institute)
relacionado con Carnegie Mellon University, en Pittsburgh.
El CMM se desarroll como reaccin a la crisis del software a principios de
los ochenta y financiado por el Departamento de Defensa de los Estados
Unidos.
1.7.2 Definicin de CMMs
El CMM consiste en una serie de procedimientos destinados a evaluar y
mejorar los procesos de desarrollo, implementacin y mantenimiento del
software. (Aqu los procedimientos es conforme a la empresa, varia en dos
proceso desarrollo de software y desarrollo de mquinas industriales,
pero en este caso CMMI se adapta solo a desarrollo de software) Aunque
an est en vas de desarrollo, es un estndar que la industria acepta para
evaluar y garantizar la calidad y madurez de sus aplicaciones. Por otro lado,
hay CMMs para procesos que no son estrictamente en el sector del software,
como por ejemplo el BMP (Business Process Management).
1.7.3 A cerca de CMMs
Los CMMs se centran en mejorar los procesos en una organizacin.
Contienen elementos esenciales para la eficacia de los procesos en una o ms
disciplinas, y describen un camino evolutivo de mejora desde procesos ad hoc
e inmaduros a procesos disciplinados y maduros con calidad y eficacia
mejoradas.
1.7.4 Enfoque CMMI
CMMI (Capability Maturity Model Integration) es un modelo que pueden
utilizar las organizaciones que lo deseen para mejorar todos sus procesos. Este
modelo ha sido creado dentro de Software Engineering Institute que pertenece
a la Carnegie Mellon University.
El CMMI es un enfoque de mejora de procesos que provee a las
organizaciones de los elementos esenciales para un proceso efectivo,
proporcionan una gua de uso para desarrollar procesos.

Este modelo lo que nos propone es una serie de prcticas que se tienen que
seguir para mejorar los procesos y ser ms productivos. Estas prcticas estn
asignadas a determinadas reas de proceso los cuales estn dentro de ciertos
niveles de madurez. Para conseguir cada uno de los niveles de CMMI antes
hay que haber cumplido las prcticas de los niveles anteriores.

1.7.5 Evolucin de CMMI

CMMI es la evolucin de CMM. El objetivo del proyecto CMMI es mejorar la
usabilidad de modelos de madurez integrando varios modelos diferentes en un
solo marco de trabajo.
Se desarrolla sobe el principio de calidad de Jurn de solvencia contrastada
en la produccin industrial: "la calidad del resultado depende principalmente de
la calidad de los procesos empleados en su desarrollo".
A continuacin se presentan las fechas clave en el desarrollo del Modelo
CMMI.
1984 El Congreso del Gobierno Americano aprob la creacin de un
organismo de investigacin para el desarrollo de modelos de mejora para los
problemas en el desarrollo de los sistemas de software, y evaluar la capacidad
de respuesta y fiabilidad de las compaas que suministran software al
Departamento de Defensa.
Creacin del SEI (Instituto de Ingeniera del Software), fundado por el
Departamento de Defensa Americano y la Universidad Carnegie Mellon.
1985 SEI empieza a trabajar en un marco de madurez de procesos que
permita evaluar a las empresas productoras de software. La investigacin
evoluciona hacia el Modelo de Madurez de las Capacidades (CMM).
1991 En agosto SEI publica la versin 1.0 del Modelo de Madurez de las
Capacidades para el Software (SW-CMM, Capability Maturity Model for
Software).
1993 SEI publica la versin 1.1 de SW-CMM
1997 Publicacin de la versin 1.2
2000 SW-CMM fue integrado y relevado por el nuevo modelo CMMI.
CMMI se desarroll para facilitar y simplificar la adopcin de varios modelos
de forma simultnea, y su contenido integra y da relevo a la evolucin de sus
predecesores:
CMM-SW (CMM for Software).
SE-CMM (Systems Engineering Capability Maturity Model).
IPD-CMM (Integrated Product Development).
2002 Se lanz CMMI Versin 1.1,
2006 Luego en agosto de sigui la versin 1.2.

1.7.6 Objetivos
El objetivo del modelo CMMI es alentar a las compaas para que
monitoreen y mejoren continuamente sus procesos, y evalen el nivel de
madurez de los mismos.
De los principales objetivos de CMMI son

Producir servicios y Productos de alta calidad.

Reduccin de ciclos
Mejorar la satisfaccin del cliente.
Mejorar la gestin de requisitos
Ganar reconocimiento en la industria.

1.7.7 Qu es el CMMI de Servicios?

CMMI SVC es un modelo que ayuda a las organizaciones proveedoras de
servicio al establecimiento, administracin y ofrecimiento de servicios exitosos.
Las prcticas contenidas en el modelo pueden ser tiles para:

Decidir servicios que pueden ofrecer y los estndares que los regulan
Asegurar que tiene todo lo necesario para ofrecer el servicio y que los

servicios estn disponibles en caso de requerirse

Establecer un nuevo sistema, cambiar o retirar uno existente, sin afectar

el servicio que tiene

Establecer acuerdos, cuidar las solicitudes de servicio y operar los

sistemas
Identificar las fallas y prevenirlas siempre que sea posible
Estar preparado para recuperarse de un desastre potencial y restablecer
el servicio si ocurre

El modelo CMMI-SVC cubre las actividades requeridas para establecer,

prestar y gestionar servicios. Segn se define en el contexto de CMMI, un
servicio es un producto intangible no almacenable.
El modelo CMMI-SVC contiene prcticas que cubren la gestin de trabajos,
la gestin de procesos, el establecimiento de servicios, la prestacin y soporte
a los servicios, y los procesos de soporte.

1.7.7 Beneficios de CMMI de Servicios

Algunos de los beneficios que tiene el uso del CMMI de Servicios cuando es
implementado y seguido por la organizacin, ms all de contar con una
evaluacin sobre el modelo.
Mejora la visibilidad sobre los Proyectos: En el sentido de que el equipo y
cada integrante sabe en qu trabaja, as como la Gerencia y la Direccin. Cada
uno sabe el estado de cada uno de los proyectos.
Mejora la comunicacin: Cada participante, en su rol, sabe cules son sus
responsabilidades y compromisos en los proyectos en los que participa, y tiene
la informacin para hacer sus tareas.
Mejora la planificacin: Permite que se establezcan planes ms realistas y
de acuerdo a lo que la empresa es capaz de hacer. Toma tiempo aceptar la
realidad (sobre todo al jefe), pero beneficia mucho a los proyectos y a la
organizacin para, a partir de esa base, mejorar la productividad, eficiencia y
calidad.
Reduce el Re-trabajo: Reduce el re-trabajo al mejorar la planificacin y
seguimiento, la comunicacin, las responsabilidades, y la deteccin temprana
de errores.
Mejora la calidad del producto: Con una apropiada obtencin de
requerimientos, la deteccin temprana de errores, uso de inspecciones y
pruebas, la rastreabilidad de los requerimientos, la implementacin de prcticas
de ingeniera de software, la planificacin y seguimiento, y la capacitacin
adecuada de los participantes.
Conocimiento de la organizacin: Al contar con ms informacin (mtricas) la
organizacin es ms predecible y sabe de lo que es capaz de hacer
(retroalimenta al proceso y a la planificacin). Esto beneficia tambin al rea de
ventas ya que conoce los mrgenes de maniobra a la hora de vender un
proyecto.

Mejora el ambiente de trabajo: Si bien al principio hay tensin por la

implementacin de las nuevas prcticas, cuando todos trabajan con el proceso
se genera una poltica de puertas abiertas, cada uno sabe qu hacer, se
aceptan ideas, se generan discusiones con sentido, se participa en mejorar el
proceso, el producto y la relacin con el cliente. Mejor comunicacin.
Se genera una Base de Conocimiento : Con la ejecucin de los procesos y
los proyectos se genera una base de conocimiento muy rico e importante para
la organizacin. Procesos, planes, ejemplos, mtricas, estimaciones, lecciones
aprendidas, capacitaciones, historia; accesible y que puede ser utilizada. El
tiempo de incorporacin de una persona es ms rpido al tener acceso a esta
base.
Se tiene una visin compartida: Se genera un ambiente de equipo al contar
con una visin compartida de lo que quiere la organizacin, de sus objetivos y
de cmo cada uno participa y aporta al logro de estos objetivos.
Un cliente ms informado: El cliente participa ms en el proyecto, conoce el
estado de su proyecto y sabe cules son sus responsabilidades.
Estos beneficios no se dan de la noche a la maana, existen algunos que se
manifestarn en forma ms temprana que otros. Tambin depende de la forma
de la implementacin y cual sea el foco, lo que siempre es cierto es que cuesta
trabajo dar los primeros pasos y tener la disciplina de mantenerse en el camino.

1.7.9 A cerca de los niveles

Los niveles se utilizan en CMMI-SVC para describir el camino evolutivo
recomendado para una organizacin que quiera mejorar los procesos que se
utilizan para proporcionar servicios. Los niveles tambin pueden ser el
resultado de la actividad de calificacin en las evaluaciones.
Los dos caminos de mejora se asocian con los dos tipos de niveles: niveles
de capacidad y niveles de madurez. Estos niveles se corresponden con dos
enfoques para la mejora de procesos denominados representaciones. Las
dos representaciones se denominan continua y por etapas. Si se utiliza la
representacin continua se logran niveles de capacidad. Si se utiliza la
representacin por etapas se logran niveles de madurez. Para alcanzar un
nivel concreto, la organizacin debe satisfacer todas las metas del rea de
proceso o del conjunto de reas de proceso que son el objeto de la mejora,
independientemente de si se trata de niveles de capacidad o de madurez.
Ambas representaciones proporcionan caminos para mejorar sus procesos con
el fin de lograr objetivos de negocio, y ambas proveen los mismos contenidos
esenciales y utilizan los mismos componentes de modelo.
La Tabla 1 compara los cuatro niveles de capacidad con los cinco niveles de
madurez. Se observa que los nombres de dos de los niveles son los mismos en
ambas representaciones (esto es, Gestionado y Definido). Las diferencias son
que no existe nivel de madurez 0; que no hay niveles de capacidad 4 y 5; y que
en el nivel 1, los nombres utilizados en el nivel de capacidad 1 y el nivel de
madurez 1 son distintos.

Nivel

Representacin Continua
Niveles de Capacidad

Representacin

por

Etapas
Niveles de Madurez

Nivel 0
Nivel 1
Nivel 2
Nivel 3
Nivel 4

Incompleto
Realizado
Gestionado
Definido

Inicial
Gestionado/administrado
Definido
Gestionado

Nivel 5

Cuantitativamente
En optimizacin

Tabla 1 Nivel de Capacidad vs Nivel de Madurez

1.7.9.1 Niveles de Capacidad

Los niveles de capacidad se aplican a los logros de mejora de procesos de
la organizacin en reas de proceso concretas. Estos niveles son un medio
para mejorar incrementalmente los procesos asociados a un rea de proceso
determinada. Los cuatro niveles de capacidad se numeran de 0 a 3.
Para dar soporte a quienes utilicen la representacin continua, todos los
modelos CMMI reflejan niveles de capacidad en su diseo y contenido. Los
cuatro niveles de capacidad, siendo cada uno de los cuales una capa de la
base para la continua mejora de procesos, se designan utilizando nmeros de
0 al 3:

0. Incompleto
1. Realizado
2. Gestionado
3. Definido
Se logra un nivel de capacidad de un rea de proceso cuando se satisfacen
todas sus metas genricas hasta ese nivel. El hecho de que los niveles de
capacidad 2 y 3 utilicen los mismos trminos que las metas genricas 2 y 3 es
intencionado porque cada una de estas metas y prcticas genricas refleja el
significado de los niveles de capacidad de las metas y prcticas. A continuacin
se describe brevemente cada uno de los niveles de capacidad.

Nivel de capacidad 0: Incompleto

Un proceso incompleto es un proceso que no se realiza o se realiza
parcialmente. Al menos una de las metas especficas del rea de proceso no se
satisface, y no existen metas genricas para este nivel, ya que no hay ninguna
razn para institucionalizar un proceso realizado parcialmente.
Nivel de capacidad 1: Realizado
Un proceso de nivel de capacidad 1 se caracteriza como un proceso
realizado. Un proceso realizado es un proceso que logra que se lleve a cabo el
trabajo que se necesita para producir productos de trabajo; las metas
especficas del rea de proceso se satisfacen. Aunque el nivel de capacidad 1
da como resultado mejoras importantes, esas mejoras pueden perderse con el
tiempo si no se institucionalizan. La aplicacin de la institucionalizacin (las
prcticas genricas de CMMI en los niveles de capacidad 2 y 3) ayuda a
asegurar que las mejoras se conserven.
Nivel de capacidad 2: Gestionado
Un proceso de nivel de capacidad 2 se caracteriza como un proceso
gestionado. Un proceso gestionado es un proceso realizado que se planifica y
ejecuta acorde a polticas; que emplea personas cualificadas que disponen de
recursos adecuados para producir resultados controlados; que involucra a las
partes interesadas relevantes; que se monitoriza, controla y revisa; y para el
que se evala el cumplimiento de su descripcin de proceso. La disciplina de
procesos reflejada en el nivel de capacidad 2 ayuda a asegurar que las
prcticas existentes se mantienen en periodos de mayor presin.
Nivel de capacidad 3: Definido
Un proceso de nivel de capacidad 3 se caracteriza como un proceso
definido. Un proceso definido es un proceso gestionado que se adapta a partir
del conjunto de procesos estndar de la organizacin de acuerdo a las guas
de adaptacin de la organizacin; tiene una descripcin de proceso que se
mantiene; y contribuye con activos relacionados con procesos a los activos de
proceso organizativos. Un proceso definido establece claramente el propsito,

las entradas, los criterios de entrada, las actividades, los roles, las medidas, los
pasos de verificacin, las salidas, y los criterios de salida. En el nivel de
capacidad 3, los procesos se gestionan de forma ms proactiva utilizando y
entendiendo las interrelaciones entre las actividades del proceso y las medidas
detalladas del proceso y sus productos de trabajo.
1.7.9.2 Niveles de Madurez
Los niveles de madurez se aplican a logros de mejora de procesos de una
organizacin comprendidas en varias reas de proceso. Estos niveles son un
medio para mejorar los procesos asociados a un conjunto de reas de proceso
determinado (esto es, un nivel de madurez). Los cinco niveles de madurez se
numeran de 1 a 5.
Un nivel de madurez es una plataforma evolutiva definida para la mejora de
procesos organizativa. Cada nivel de madurez madura un subconjunto
importante de los procesos de la organizacin, preparndola para pasar al
siguiente nivel de madurez. Los niveles de madurez se miden por el logro de
las metas genricas y especficas asociadas a cada uno de los conjuntos
predefinidos de reas de proceso. Los cinco niveles de madurez, siendo cada
uno de los cuales una capa de la base para la continua mejora de procesos, se
designan utilizando nmeros de 1 al 5:
Nivel 1: Inicial Procesos impredecibles, pobremente controlados y reactivos.
El proceso de software se caracteriza como ad hoc y ocasionalmente catico.
Pocas actividades estn definidas y el xito de los proyectos depende del
esfuerzo individual. Hay carencia de procedimientos formales, estimaciones de
costos, planes del proyecto, mecanismos de administracin para asegurar que
los procedimientos se siguen.
Nivel 2: Administrado. Procesos caracterizados en proyectos y acciones
reactivas con frecuencia. Son establecidas las actividades bsicas para la
administracin de proyectos de software para el seguimiento de costos,
programacin y funcionalidad. El xito est en repetir prcticas que hicieron
posible el xito de proyectos anteriores, por lo tanto hay fortalezas cuando se
desarrollan procesos similares, y gran riesgo cuando se enfrentan nuevos
desafos.

Nivel 3: Definido. Procesos caracterizados en la organizacin, y con

acciones proactivas. Las actividades del proceso de desarrollo de software
para la administracin e ingeniera estn documentadas, estandarizadas e
integradas en un proceso de software estndar para la organizacin.
Nivel 4: Administrado cuantitativamente. Los procesos son medidos y
controlados.
Se registran medidas detalladas de las actividades del Proceso y calidad del
Producto. El proceso de desarrollo de software y el producto son entendidos
cuantitativamente y controlados.
Nivel 5: Optimizado. Enfoque continuo en la mejora de procesos.
Existe una mejora continua de las actividades, las que se logran a travs de
una retroalimentacin con las reas de procesos establecidas para este nivel y
tambin a partir de ideas innovadoras y tecnologa. La recoleccin de datos es
automatizada y usada para identificar elementos ms dbiles del proceso. Se
hace un anlisis riguroso de causas y prevencin de defectos.
1.7.9.2 reas de proceso del Nivel 2 de CMMI de Servicios
En el modelo CMMI el rea de proceso es el conjunto de prcticas
relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto
de objetivos:
Objetivos genricos: Son aquellos que estn asociados a un nivel de
capacidad, establecen lo que una organizacin debe alcanzar en ese nivel de
capacidad.
Practicas especficas: Se aplican a una nica rea de proceso y localizan
las particularidades que describen que se debe implementar para satisfacer el
propsito del rea de proceso.
El logro de cada uno de esos objetivos en un rea de proceso significa
mejorar el control en la ejecucin del rea de proceso.
A continuacin se presentan las 7 reas de proceso correspondientes a los
cinco niveles correspondientes al modelo CMMI:

Gestin de Requisitos (REQM)

Planificacin de proyectos (PP)
Seguimiento y Control de proyectos (PMC)

Medicin y Anlisis (MA)

Gestin de acuerdos con proveedores (PPQA)
Gestin de la configuracin (CM)
Aseguramiento de la Calidad de Productos y Procesos

1.7.10 Ventajas de CMMI de Servicios

La gran ventaja de CMMI de Servicios es que ha demostrado ser una
metodologa de gran eficacia, que ha permitido mejoras de gran impacto en
procesos de desarrollo de productos software, Servicios TI.

Las reas de proceso seleccionadas pueden cumplir con los

objetivos de negocio directamente.

Se requiere de una inversin menor.
Reduccin del coste de desarrollo.
Localizacin y resolucin de defectos.
Mejora en la fiabilidad de la planificacin,

en

trminos

de dedicacin y de calendario.
Aumento de la efectividad sobre la planificacin realizada.
Mejora en la calidad de producto.
Reduccin del nmero de defectos y deteccin en

las

fases tempranas de su ciclo de vida.

Mejora de la Imagen de Marca.
1.7.11 Desventajas de CMMI de Servicios
Algunos de los inconvenientes que el modelo CMMI de Servicios podra
tener

seria

la falta

de

adecuacin

al

enfoque

a servicio

que

est

experimentando el sector de las TI (procesos de desarrollo de productos de

software) en todas sus lneas de actividad, as como el alto esfuerzo
de implantacin que exige.

Los problemas de calidad pueden no ser tomados en cuenta.

Puede que no se tengan beneficios a largo plazo.
Falta de estrategia incorporada.
Se puede implementar los procesos en el orden equivocado.

CAPTULO

II.

METODOLOGA DE
LA INVESTIGACIN
APLICADA

2.1 Descripcin de la metodologa

Para la Propuesta de Implementacin del Modelo CMMI de Servicios Nivel 2
para la Empresa Intekel Automatizacin, se estableci la aplicacin del enfoque
exploratorio-cualitativo en la investigacin. Lo que permite hacer una
investigacin sobre un tema muy novedoso y poco conocido, y el cual servir
para preparar el terreno para futuras investigaciones. Este enfoque
Exploratorio-cualitativo busca utilizar una lgica inductiva, en la cual se explora
y describe la informacin de los fenmenos sociales en estudio. Para luego,
analizarla y generar ideas que se plantean en el objetivo general.
El objetivo general al realizar este proyecto es desarrollar una Propuesta
para Implementar el Modelo CMMI de servicios Nivel 2 con el fin de proponer
una solucin a los problemas que tiene la empresa al controlar y planear los
proyectos, y mediante esto alcanzar un crecimiento empresarial. (Cambiar por
el que redacte en la parte de arriba)
Se utiliza el diseo de investigacin no experimental. Al ser una investigacin
sistemtica

emprica,

no

requiere

la

manipulacin

de

variables

independientes, y acciones de observacin y comprensin de los fenmenos

de investigacin se realizan en un contexto real.
El tipo de diseo no experimental propuesto en el presente proyecto sugiere
aplicar la forma transeccional o transversal, esto debido a que la recoleccin de
datos se realiz en un periodo especfico.
La metodologa de investigacin aplicada en el presente proyecto se
determin desarrollarla por medio de un enfoque cualitativo, el cual se adapta
favorablemente a las caractersticas del presente proyecto.
El proceso que se realiz para llevar a cabo la investigacin del proyecto
esta descrito mediante una serie de actividades, expuesta a continuacin:
La primera actividad que se llev a cabo fue la definicin del problema para
dar una solucin concreta, donde se reuni a todo el personal para compartir
sus opiniones respecto a las actividades de las que son parte en los proyectos
para conocer y entender la problemtica a resolver. Al tener esta reunin los

temas que destacaron fueron que se ha tenido la dificultad de llevar el control y

planeacin de cada proyecto, debido a que no hay una correcta administracin
de los proyectos. Por ello es que se decidi hacer la propuesta de Implementar
el modelo CMMI nivel 2 de servicios, debido a que este modelo representara
una solucin concreta a los problemas de administracin de proyectos, adems
que debido a las caractersticas de este modelo se incrementara de manera
considerable la eficiencia en cada etapa del proceso de desarrollo de cada
proyecto.
La segunda actividad fue la bsqueda de informacin sobre el modelo CMMI
de Servicios (en internet como libros virtuales, talleres impartidos por empresas
y la aplicacin del modelo CMMI de servicios en Empresas de Software) para
poder analizar y comprender dicho modelo y as proponer la solucin al
problema que presenta Intekel Automatizacin, al igual acudiendo a un breve
taller que se imparti del modelo SCRUM en la empresa, dado a que es una
metodologa de desarrollo muy simple, que requiere trabajo duro porque no se
basa en el seguimiento de un plan, sino en la adaptacin continua a las
circunstancias de la evolucin del proyecto, lo que servira como un
complemento si se aceptara la propuesta de la implementacin del modelo
CMMI Nivel 2 de Servicios.
La tercera actividad fue la realizacin de plantillas para cada etapa del
modelo CMMI de Servicios nivel 2, las cuales se elaboraron en base a las
necesidades que presenta la empresa.
La cuarta tarea consisti en realizar un anexo el cual contiene una serie de
preguntas que proporcionaran conocer el estado inicial de la empresa respecto
a las normas relacionadas con CMMI para posteriormente en base a los
resultados obtenidos se definan las mejoras necesarias que hay que tomar en
cuenta, estas preguntas sern relacionadas con cada una de las reas de
proceso de CMMI Nivel 2 de Servicios.

CAPTULO

III.

PROPUESTA

DE

IMPLEMENTACIN
DE

CMMI

SEVICIOS

DE
DEL

NIVEL 2 PARA LA
EMPRESA INTEKEL
ATOMATIZACIN

3.1 Objetivo Genrico del nivel 2

El objetivo primordial del nivel 2 de CMMI de Servicios es conseguir que en
los proyectos de la organizacin haya una gestin de los requisitos y que los
procesos (formas de hacer las cosas) estn planeados, ejecutados, medidos y
controlados.

3.2 Proceso de desarrollo de proyectos

3.2.1 Contacto
Esta es la primera etapa del ciclo de vida de proceso de CMMI en la
empresa Intekel Automatizacin, esta etapa tiene por objetivo establecer el
contacto inicial con el cliente de ah es de donde proviene su nombre-. En
esta etapa es donde el rea de anlisis y ventas hacen su intervencin, segn
sea el caso; la primer rea se refiere a desarrollar un nuevo software; por el
contrario el segundo se refiere a cuando solo se realiza la venta de un producto
ya existente entra el rea de ventas.
Las actividades correspondientes a la etapa de contacto se enumeran de la
siguiente manera, as tambin se presentan las plantillas pertenecientes a cada
actividad.
1.-Prospeccin: Esta es la actividad inicial de la etapa de contacto y cosiste
en realizar una bsqueda de los posibles clientes, el documento perteneciente
a esta actividad deber contener la informacin general de estos clientes
potenciales.
2.-Primer Visita Empresarial: Hace referencia al conocimiento de las
necesidades del cliente, para poder presentar una posible solucin.
3.-Elaboracin de Propuesta Tcnica: En esta actividad se elaboran las
posibles soluciones a la problemtica definida en la Primer Visita Empresarial.
4.-Segunda Visita Empresarial: En esta actividad se presentan la propuesta
tcnica ante el cliente, para tener as una aclaracin de las dudas existentes o
si se requieren de algunos cambios en la propuesta, as tambin se deber
realizar una lista de las funciones, mdulos y tareas que realizara la solucin.
Si existen cambios se deber regresar a la actividad 3, sino aqu termina la
etapa de contacto.

Plantillas de la etapa de contacto

Ilustracin 5 Plantilla de la etapa de Contacto (Agenda de

Prospeccin)

Esta plantilla enfocada al Sector de Construccin y no de Desarrollo de Software

Ilustracin 6 Plantilla de la etapa de Contacto (Bitcora de

Requerimientos)

Ilustracin 7 Plantilla de la etapa de Contacto (Control de

Cambios)

Ilustracin 8 Plantilla de la etapa de Contacto (Checklist)

3.2.2 Planeacin
Esta etapa del proceso se refiere a realizar una programacin de actividades
que correspondern a desarrollo del proyecto, as tambin se deben asignar los
recursos materiales y el capital humano correspondiente a cada proyecto que
se pretende desarrollar, este ltimo debe tener las aptitudes y conocimientos
tcnicos necesarios para cada proyecto. Las actividades pertenecientes a la
etapa de planeacin son las siguientes:
1.-Definir Actividades del Proyecto: En esta actividad debe realizarse un
pronstico de las tareas correspondientes para el desarrollo del proyecto.
2.-Realizar Diagrama de Gantt: En la realizacin de este diagrama se
establecen los tiempos de cada tarea, mencionadas en la actividad 1.
3.-Cotizar: Se elabora una lista con los materiales necesarios para el
desarrollo del proyecto as como tambin sus precios.
4.- Proyeccin: Esta actividad hace referencia al personal que laborar en el
proyecto, en esta parte deben definirse sus aptitudes y capacidades que posea
dicho personal.
5.- Propuesta Econmica: Se genera un documento, el cual contendr el
costo total de la solucin propuesta.
6.- Tercera Visita Empresarial: En esta actividad se presenta ante el cliente
la propuesta econmica antes elaborada. Si la propuesta es aceptada se
procede a firmarla como un acuerdo antes de la elaboracin del contrato, por lo
contario si no es aceptada aqu termina la etapa de planeacin y se anula el
proyecto.
7.-Generacin del Contrato: Se elabora un contrato, el cual deber contener
un conjunto de clusulas en donde se especificar las funciones del proyecto,
en las que ambas partes debern estar de acuerdo.
8.-Cierre de Contrato: Esta tarea se refiere a la firma del contrato
previamente mencionado.

Plantillas de la etapa de Planeacin

Ilustracin 9 Plantilla de la etapa de Planeacin (Lista de

Actividades)

Ilustracin 10 Plantilla de la etapa de Planeacin (Diagrama

de actividades)

Ilustracin 11 Plantilla de la etapa de Planeacin (Lista de

Precios de Materiales)

Ilustracin 12 Plantilla de la etapa de Planeacin (Matriz de

Capacitacin)

Ilustracin 13 Plantilla de la etapa de Planeacin (Propuesta

Econmica)

3.2.3 Ejecucin
Esta es la etapa de desarrollo del trabajo en s. En sta se desarrolla el
proyecto y se realizan iteraciones con las cuales se debe cumplir en un cierto
periodo de tiempo, estos tiempos son los que se especifican en el diagrama de
Gantt, al finalizar cada iteracin es necesario realizar una serie de pruebas
para verificar la funcionalidad de la solucin, adems se hace un conjunto de
pruebas contra el checklist elaborado en la fase de contacto, con el fin de
verificar que se cumpla con todos los requisitos
1.-Peticin de materiales: Esta primera actividad se refiere a la solicitud de
los materiales que se han de utilizar para el desarrollo del proyecto, estos
pueden ser documentos, formatos, etctera, necesarios para iniciar con el
desarrollo en s. Esta actividad es opcional, puesto que depende de la
naturaleza del proyecto.
2.-Realizacin de iteraciones: En esta parte se determina el grado de avance
que debe de tenerse en un periodo de tiempo definido en la etapa de
planeacin mediante la utilizacin del Diagrama de Gantt, al final del periodo
definido deben realizarse revisiones por parte del encargado del proyecto.
3.-Realizacin de pruebas: Aqu se llevan a cabo las diferentes pruebas de la
solucin, se inicia con una prueba de funcionalidad, la cual se refiere a verificar
que la solucin cumpla con las funciones que debe desempear, esta prueba
se realiza para verificar que se cumpla lo establecido en el checklist realizado
en la etapa de contacto; posteriormente se procede a realizar una prueba
general, esta se enfoca a verificar el diseo de la interfaz (color, ortografa,
tamaos, etc.). Otra de las pruebas que se realizan tambin en esta etapa es la
verificacin de los cambios que se realizan durante el desarrollo del proyecto.

Plantillas de la etapa de Ejecucin

Ilustracin 14 Plantilla de la etapa de Ejecucin (Lista de

Equipo y Materiales)

Ilustracin 15 Plantilla de la etapa de Ejecucin (Evidencia

Descriptiva)

Ilustracin 16 Plantilla de la etapa de Ejecucin (Solicitud de

Material)

Ilustracin 17 Plantilla de la etapa de Ejecucin (Lista de

Equipo y Herramienta)

Ilustracin 18 Plantilla de la etapa de Ejecucin (Evidencia

Descriptiva)

Ilustracin 19 Plantilla de la etapa de Ejecucin

[Verificacin de Checklist)

Ilustracin 20.a Plantilla de la etapa de Ejecucin

[Verificacin de Funcionalidad)

Ilustracin 20.b Plantilla de la etapa de Ejecucin [Verificacin de

Funcionalidad)

3.2.4 Cierre
Es la etapa final del proyecto cuando este se entrega y se verifica que se
cumple con lo establecido, llevando a cabo las valoraciones pertinentes sobre
lo planeado y lo ejecutado, as como sus resultados, en consideracin al
objetivo del software pactado en el rea de anlisis de la etapa de contacto,
llegando a la culminacin del proyecto. Tambin deber presentarse una
encuesta referente a la calidad del servicio, para poder evaluar el servicio
prestado durante el desarrollo de la intervencin, para as identificar los errores
en la gestin. Esta etapa est compuesta por 2 actividades, las cuales se
muestran a continuacin:
1.-Finalizacin del proyecto: En esta actividad el cliente firma la aceptacin
el proyecto, este debe cumplir con lo antes pactado.
2.-Encuesta de satisfaccin del cliente: Realizar la encuesta para conocer el
grado de satisfaccin del producto y del servicio brindado.

Plantillas de la etapa de Cierre

Ilustracin 21 Plantilla de la etapa de Cierre (Carta de

Cierre)

Ilustracin 22 Plantilla de la etapa de Cierre

(Encuesta del Proyecto)

3.2.4.1 Cambios
Esta sub etapa entra en accin solo si el cliente no est de acuerdo con el
software entregado y requiere de algunas correcciones o si desea agregar
algunos modificaciones, todo esto se llevara a cabo con una solicitud de
cambios y llevando un control de estos, aqu tambin se realizan las
verificaciones para llevar el proyecto a la etapa de cierre.
1.-Solicitud de Cambios: En esta actividad se plantean los cambios a
realizar, para cubrir las necesidades surgidas durante el desarrollo del proyecto
(estos cambios que se presentan se refieren a funciones, actividades o
mdulos que no fueron pactados durante la etapa de planeacin).
2.- Control de Cambios: Aqu se hace una descripcin detallada de los
cambios presentados con anterioridad, as tambin se especifica el grado de
impacto que el cambio tendr en el proyecto.

Plantillas de la etapa de Cambios

Ilustracin 23 Plantilla de la etapa de Cambio

(Solicitud de Cambio)

Ilustracin 24 Plantilla de la etapa de Cambio (Control

de Cambios)

3.2reas de Proceso
Siete son las reas de proceso correspondientes al nivel 2 se enumeran a
continuacin:

Gestin de Requisitos (REQM)

Planificacin de proyectos (PP)
Seguimiento y Control de proyectos (PMC)
Medicin y Anlisis (MA)
Gestin de acuerdos con proveedores (PPQA)
Gestin de la configuracin (CM)
Aseguramiento de la Calidad de Productos y Procesos

3.2.1 (REQM) Gestin de Requisitos

En REQM lo que se pretende es tener un control sobre los requisitos. Estos
requisitos deben estar a parte de bien identificados, comprensibles para todas
las partes interesadas que tengan relacin con los requisitos. Tambin estos
requisitos sern entrada de otras reas de proceso. Otra de las cosas que las
prcticas de esta rea de proceso pretenden mejorar es el hecho de que los
cambios efectuados sobre los requisitos sean controlados y que no afecten a la
integridad de lo ya definido.
Objetivo de (REQM): Los requisitos son administrados, y se identifican las
inconsistencias entre los requisitos y los planes y otros artefactos del proyecto.
Prcticas Especficas:

SP 1.1 Comprender el significado de los requisitos

SP 1.2 Obtener compromiso de los participantes / interesados

acerca de los requisitos

SP 1.3 Administrar cambios a los requisitos
SP 1.4 Mantener la trazabilidad bidireccional de los requisitos
SP 1.5 Identificar inconsistencias entre los requisitos y otros
productos del proyecto

3.2.2 (PP) Planificacin de proyectos

Esta rea de proceso lo que hace es establecer un orden dentro de los
proyectos. Para establecer este orden lo que se tiene es un plan desarrollado
con base a los requisitos de REQM. Dentro de este plan habr estimaciones
del proyecto para saber cunto va a costar, que va a necesitar y cundo se
aleja de lo fijado, se definir el ciclo de vida para establecer en cada etapa lo
que hay que hacer, se identificarn riesgos que puedan provocar retrasos en el
proyecto y obtener el compromiso de todos los participantes entre otras cosas.
Este plan de proyecto debe ser algo que vaya evolucionando con el paso del
tiempo

adaptndose

al

contexto

de

cada

momento

realizando

las

modificaciones que sean oportunas.

El propsito de Planificacin de Proyectos (PP) es establecer y mantener los
planes que definan los trabajos.
Objetivos de (PP): Se realizan y mantienen estimaciones de las
magnitudes del proyecto, Se establece y mantiene un plan de proyecto que es
empleado para administrar el proyecto, y Los compromisos con el plan estn
formalmente establecidos y son mantenidos a lo largo del proyecto.
Prcticas Especficas:

SP 1.1 Estimar el alcance del proyecto

SP 1.2 Estimar atributos de las tareas y de los productos del

proyecto
SP 1.3 Definir el ciclo de vida del proyecto
SP 1.4 Estimar esfuerzo y costo del proyecto
SP 2.1 Establecer el cronograma y el presupuesto del proyecto
SP 2.2 Identificar los riesgos del proyecto
SP 2.3 Planificar la administracin de datos del proyecto
SP 2.4 Planificar recursos necesarios para el proyecto
SP 2.5 Planificar la adquisicin de conocimiento y habilidades
SP 2.6 Planificar la participacin de los interesados en el proyecto
SP 2.7 Establecer el plan del proyecto
SP 3.1 Revisar todos los planes que puedan afectar al proyecto
SP 3.2 Ajustar el plan de proyecto para reflejar recursos
estimados vs. disponibles
SP 3.3 Obtener compromisos respecto al plan
3.2.3 (PMC) Seguimiento y Control de proyectos

La idea de esta rea de proceso ser la de controlar el plan de proyecto

mediante el seguimiento. Para ello se deber controlar las horas de trabajo,
tener informes de avance, revisiones en algunos puntos, etc. Con este
seguimiento luego se podr tomar acciones correctivas si se ve que el trabajo
se desva demasiado del plan a seguir. El beneficio que nos proporciona esta
rea de proceso es la de anticiparnos a los problemas. No es lo mismo darse
cuenta que el proyecto se ha desviado del plan a seguir al final donde cuesta
siempre ms cualquier cambio que conforme se est realizando el trabajo
detectarlo y ajustar lo necesario para que vuelva al plan.
El propsito de Seguimiento y Control de Proyectos (PMC) es proporcionar
informacin sobre el trabajo en curso de forma que se puedan realizar las
acciones

correctivas

apropiadas

cuando

el

rendimiento

se

desve

significativamente del plan.

Objetivos de (PMC): El avance y la performance del proyecto se
monitorean respecto a lo establecido en el plan de proyecto y Cuando los
resultados o la performance del proyecto se desvan significativamente del plan
se gestionan acciones correctivas.
Prcticas Especficas:

SP 1.1 Monitorear los parmetros de planificacin del proyecto

SP 1.2 Monitorear los compromisos
SP 1.3 Monitorear los riesgos del proyecto
SP 1.4 Monitorear la administracin de datos del proyecto
SP 1.5 Monitorear la participacin de los interesados
SP 1.6 Conducir revisiones de avance
SP 1.7 Conducir revisiones de cumplimientos de hitos
SP 2.1 Analizar temas pendientes
SP 2.2 Ejecutar acciones correctivas
SP 2.3 Administrar acciones correctivas

3.2.4 (MA) Medicin y Anlisis

El propsito de esta rea de proceso es desarrollar y mantener la capacidad de
tomar mediciones para responder a las necesidades de informacin requeridas
para el gerenciamiento del proceso de software, tanto a nivel de proyecto como
a nivel de organizacin.
Estas mediciones pueden agruparse en dos grupos diferentes: por un lado los
empleados para monitorear los proyectos (lneas de cdigo, horas invertidas,
etc.) y otros ms generales (proyectos finalizados a tiempo, promedio de
retraso, etc.).
Objetivos de (MA): Las actividades de medicin y anlisis estn alineadas
con los objetivos y necesidades de informacin.
Prcticas Especficas:

SP 1.1 Establecer objetivos de las mediciones.

SP 1.2 Especificar mtricas
SP1.3
Especificar
procedimientos
de

almacenamiento de datos
SP 1.4 Especificar procedimientos de anlisis
SP 2.1 Recolectar datos
SP 2.2 Analizar datos
SP 2.3 Almacenar datos y resultados
SP 2.4 Comunicar resultados a los involucrados.

recoleccin

3.2.5 (SAM) Gestin de Acuerdos con Proveedores

SAM lo que pretende es controlar todo lo relacionado con los proveedores. Se
tendr un control de cules son los proveedores que se tiene a la disposicin,
teniendo tambin constancia de sus caractersticas para una posterior decisin
de cul elegir. Tambin segn el producto de los proveedores se suelen
controlar sus procesos para asegurar los plazos de entrega y las caractersticas
del producto adquirido.
El propsito de Gestin de Acuerdos de Proveedores (SAM) es gestionar la
adquisicin de productos y servicios a suministradores.
Objetivos

de

(SAM):

Se

establecen

y mantienen

acuerdos con

proveedores y Los acuerdos con los proveedores son satisfechos por el

proyecto y por los proveedores.

Prcticas Especficas:

SP 1.1 Determinar tipo de adquisicin

SP 1.2 Seleccionar proveedores
SP 1.3 Establecer acuerdos con proveedores
SP 2.1 Ejecutar acuerdos con proveedores
SP 2.2 Monitor de procesos de Seleccin de Proveedores
SP 2.3 Evaluar los Work Produts del proveedor seleccionados
SP2.4 Aceptar el producto adquirido
SP 2.5 Transicin de productos

3.2.6 (CM) Gestin de la Configuracin

Esta rea de proceso lo que pretende es mantener un control sobre todos los
elementos que componen el proyecto, sean entregables o no. Para ello
mantendr la integridad de todos los elementos del proyecto. El propsito de
Gestin de Configuracin (CM) es establecer y mantener la integridad de los
productos de trabajo mediante la identificacin de configuracin, el control de
configuracin, el registro del estado de la configuracin, y las auditoras de
configuracin.
Objetivos de CM: Se establecen lneas base de los artefactos puestos bajo
administracin de la configuracin. y Los cambios a los artefactos son
monitoreados y controlados.
Prcticas Especficas:

SP 1.1 Identificar tems de configuracin

SP 1.2 Establecer un sistema de

administracin

de

la

configuracin
SP 1.3 Crear o liberar lneas base
SP 2.1 Monitorear pedidos de cambio
SP 2.2 Controlar tems de configuracin
SP 3.1 Establecer la configuracin de gestin de registros
SP 3.2 Realizar auditoras de revisin
3.2.7 (PPQA) Aseguramiento de la Calidad de Productos y Procesos
Lo que esta rea de proceso pretende es asegurarse que se cumplen los
estndares y los procesos que se han establecido. Para ello debern ser
evaluados de una forma objetiva, preferiblemente por personas ajenas a los
productores y que determinarn si se estn cumpliendo los estndares y los
procedimientos. El propsito de Aseguramiento de Calidad Procesos y

Productos (PPQA) es proporcionar al personal y a la gerencia un conocimiento

objetivo de los procesos y de sus productos de trabajo asociados.
Objetivos de (PPQA): Se evala objetivamente la adhesin de los
procesos y artefactos a los estndares y descripciones de proceso vigentes y
El no cumplimiento de los estndares y descripciones de proceso es
objetivamente comunicado y su resolucin asegurada.
Prcticas Especficas:

SP 1.1 Evaluar procesos objetivamente

SP 1.2 Evaluar productos y servicios objetivamente
SP 2.1 Comunicar y asegurar la resolucin de cuestiones de

calidad.
SP 2.2 Establecer y mantener registros de las actividades de
aseguramiento de la calidad.

Conclusiones
Lo que nos permite CMMI es que de una forma progresiva se puede
desarrollar la madurez de la organizacin nivel a nivel. El llegar a un
nivel superior indica que hay una serie de prcticas importantes que
aumentan la madurez de la organizacin a la hora de enfrentarse a
problemas ms exigentes. Esto nos obliga a aceptar que la forma para
sobrevivir en el mercado actual a largo plazo es realizar mejores
productos, con un coste temporal ms corto y que sea ms barato. Para
esto es necesario un modelo de mejora que ayude a mejorar ciertos
aspectos de la organizacin.
En base a la investigacin sobre el modelo CMMI de Servicios al
elaborar este proyecto se puede concluir que la propuesta de
implementar el modelo Cmmi nivel 2 de servicios en la empresa Intekel
automatizacin es recomendable dado a que con este modelo la
empresa solucionara aquellos problemas generados por no llevar un
control adecuado de los proyectos realizados, obteniendo Madurez en
sus Procesos, y esto sera un indicador del crecimiento en la capacidad
de los procesos que se efecten en la empresa, as tambin el
rendimiento al obtener el resultado alcanzado y la capacidad que se
genere en los procesos efectuados.
Para que Intekel Automatizacin tenga una fcil adopcin del nivel 2
de dicho modelo se es necesario cubrir todas las metas del rea de
proceso o del conjunto de reas de proceso que son el objeto de la
mejora, y as satisfacer las descripciones especficas de los procesos,
estndares y procedimientos requeridos por el cliente y ser una empresa
altamente competitiva.

Recomendaciones
Al realizar la implementacin del modelo CMMI de servicios es necesario
hacer las siguientes recomendaciones que facilitaran la adopcin de CMMI:
1. Al momento de realizar la implementacin se considera pertinente definir una
metodologa ITI (Identificacin-Transformacin-Implantacin), la cual facilitar
la adopcin de CMMI. Esta metodologa permitir a la empresa obtener una
transformacin rpida y progresiva con resultados y objetivos de calidad.
2. Capacitar a todo el personal, pero principalmente a los desarrolladores en los
nuevos procesos, procedimientos y el uso de los formatos.
3. Es conveniente que la empresa mantenga un rea que monitoree
permanentemente los procesos CMMI y que vigile su cumplimiento.
4. Es recomendable que el personal de toda rea este informado del avance de
cada proyecto.
5. Se anexan un conjunto de preguntas que servirn para conocer el estado inicial
de la empresa, respecto a los procesos y actividades pertenecientes a CMMI.

Competencias Desarrolladas y Aplicadas

Durante la elaboracin del proyecto las competencias especficas que se han
desarrollado en el rea de trabajo (departamento de Calidad) apegadas al perfil
profesional de un ingeniero en gestin empresarial son las que a continuacin
se mencionan:
1. Aplicar mtodos de investigacin para desarrollar e innovar sistemas,
procesos y productos en las diferentes dimensiones de la organizacin.
2. Disear e innovar estructuras administrativas y procesos, con base en
las necesidades de las organizaciones para competir eficientemente en
mercados globales.
3. Utilizar las nuevas tecnologas de informacin en la organizacin, para
optimizar los procesos de comunicacin y eficientar la toma de
decisiones
4. Gestionar sistemas integrales de calidad, ejerciendo un liderazgo
efectivo y un compromiso tico, aplicando las herramientas bsicas de la
ingeniera.

As como tambin de una caracterstica ms universal se desarrollaron

competencias generales, un poco ms comunes en las conductas de la
empresa como lo son:
1.
2.
3.
4.
5.
6.

Analizar y sintetizar informacin requerida por la empresa.

Mostrar alto compromiso tico.
Trabajando en equipo con armona y compromiso.
Aportacin de ideas creativas para la solucin de algunos proyectos.
Relacionarnos con nuestros compaeros de trabajo.
Empleamos las tecnologas de la informacin y comunicacin.

Anexos
Para poder realizar una implementacin exitosa de CMMI de Servicios
en nivel que se ajuste a la necesidades de Intekel Automatizacin, es
necesario conocer el estado inicial de la empresa respecto a las normas
relacionadas con CMMI para posteriormente en base a los resultados
obtenidos definir las mejoras necesarias que hay que tomar en cuenta.
Para obtener dicho estado inicial se realiza un cuestionario para cada
una de las reas de proceso de CMMI, en estos cuestionario se
formulan preguntas que hay que contestar si se realiza lo que especifica
la pregunta o no. En caso de necesitar alguna aclaracin habr un
apartado de comentarios para tener en cuenta algo respecto a la
respuesta de la pregunta. En general las preguntas que tengan como
respuesta NO, sern las que tendrn que tener una propuesta para
convertirla en un SI y as cumplir la norma. Tambin puede ocurrir que
algunas contestaciones SI, tengan como comentarios algo que aunque
en general la respuesta es afirmativa hay cosas que podran mejorar

Estado Inicial Prcticas Especficas REQM

Si
No

(1)SP1.1: Se han identificado quines son los proveedores de requisitos

autorizados (canales apropiados o fuentes oficiales de quien poder recibir
requisitos, por ejemplo, cliente externo, interno, usuarios finales, etc.)?
(2)SP1.1: Se han establecido criterios objetivos para la evaluacin y
aceptacin de los requisitos (ej.: clara y adecuadamente definido, completo,
consistente con otros requisitos, identificado unvocamente, implementable
adecuadamente, testeable, trazable)?
(3)SP1.1: Se analizan los requisitos para garantizar que se cumplen los
criterios de aceptacin establecidos?
(4)SP1.1: Se llega a un conjunto de requisitos acordados por ambas
partes de forma que los participantes del proyecto puedan comprometerse

con dichos requisitos?

(5)SP1.1: Existe un registro donde se recojan los requisitos del cliente
(documento, BD o herramienta especfica de gestin de requisitos)?
(6)SP1.2: Se evala el impacto de los requisitos (y de los cambios a
requisitos) sobre los compromisos ya existentes?
(7)SP1.2: Queda documentado el compromiso del personal encargado de
implementar los requisitos para con los mismos (ej.: firma del plan de
proyecto, actas de la reunin de lanzamiento o de las reuniones internas de
requisitos, atributo en la BD de requisitos para reflejar el estado de
revisin/compromiso)?
(8)SP1.3: Se registran las peticiones de cambio a los requisitos (fuente,
razn, versin a la que afecta,...)?
(9)SP1.3: Se ha establecido claramente quin es el responsable de
aprobar/rechazar una peticin de cambio a un requisito?; se han definido
criterios de escalado para tomar esta decisin?
(10)SP1.3: Se controla el estado de los requisitos?; existen atributos
que indiquen el estado actual de cada requisito?
(11)SP1.3: Se revisan el plan de proyecto y los Work Products
relacionados con los requisitos para asegurar que existe consistencia con
los requisitos y los cambios realizados en ellos?
(12)SP1.3: Existen Procesos, Procedimientos, Plantillas, Herramientas
para Gestin de Requisitos? La utilizan los proyectos?
(13)SP1.4: Se tiene una trazabilidad (ej.: matriz de trazabilidad) desde los
requisitos fuente hacia sus derivadas y a la inversa?
(14)SP1.4: Se tiene una trazabilidad (ej.: matriz de trazabilidad) entre los
requisitos y su relacin con objetos, personas, interfaces, procesos, Work
Products y funciones?
(15)SP1.5: Se identifican incoherencias entre los requisitos, los planes de
proyecto y los Work Products, se documentan y se toman medidas

correctivas?

Estado Inicial Prcticas Especficas PMC

Si
No

(1)SP1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados respecto al calendario?
(2)SP1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados respecto a los costes y el esfuerzo?
(3)SP1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados de los atributos de los Work Products y las
tareas?
(3)SP1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados de los atributos de los Work Products y las
tareas?
(4)SP1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados respecto a los recursos utilizados?
(5)SP1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados respecto a los conocimientos del personal?
(6)SP1.1: Se documentan las desviaciones significativas de parmetros
analizados?
(7)SP1.2: Se identifican y documentan los compromisos no satisfechos
(o que corren riesgo de no ser satisfechos)?
(8)SP1.2: Se documenta los resultados de las revisiones realizadas?
(9)SP1.3: Se revisan regularmente (segn lo definido en el plan de
proyecto) los riesgos teniendo en cuenta el contexto y las circunstancias
actuales del proyecto (ej.: pueden surgir nuevos riesgos, desaparecer otros,
cambiar la probabilidad o impacto de un riesgo segn cambian las
circunstancias del proyecto)?

(10)SP1.3: De existir riesgos se comunican a las partes interesadas?

(11)SP1.4: En caso de datos sensibles (ej.: datos sujetos a LOPD), se
comprueba peridicamente que se estn siguiendo los requisitos y
procedimientos establecidos para asegurar la privacidad y seguridad de los
datos
(12)SP1.5: En el plan de proyecto se han definido la involucracin y las
responsabilidades de las personas interesadas para las distintas actividades
se revisa que todo esto se est cumpliendo?
(13)SP1.6: Se realizan reuniones de seguimiento peridicas del equipo de
proyecto para tratar el progreso tcnico, planes y posibles problemas contra
lo definido en el plan? Se documenta el resultado de las mismas?
(14)SP1.7: Se revisan peridicamente los logros y resultados de ciertos
hitos seleccionados, identificando posibles problemas contra el plan
definido? Se documenta el resultado?
(15)SP2.1: Se lleva un registro de los problemas ms significativos que
surgen en el proyecto (posibles fuentes de problemas: durante las
actividades de verificacin y validacin, desviaciones significativas respecto
del plan, riesgos, problemas con las partes interesadas, baja de un miembro
del equipo de proyecto, etc.)?
(16)SP2.1: Se documentan el anlisis y las razones por las que el
problema requiere o no accin correctiva?
(17)SP2.2: Se determinan y registran las acciones correctivas (ej.:
renegociar calendarios, aadir recursos) destinadas a resolver el problema?
18)SP2.3: Se dispone de un registro en el que poder consultar el estado
actual de las acciones correctivas (p.ej.: cantidad de abiertas/cerradas,
pendientes, en proceso, etc.)?
(19) SP2.3 Existen Procesos, Procedimientos, Plantillas, Herramientas
para el Seguimiento y Control de Proyecto? La utilizan los proyectos?

Estado Inicial Prcticas Especficas MA

Si
No

(1)SP1.1: La direccin establece peridicamente cules son los objetivos

estratgicos de la organizacin? (por ejemplo: aumentar rentabilidad,
aumentar satisfaccin del cliente, aumentar calidad del producto, etc.)
(2)SP1.1: Se priorizan las necesidades de informacin u objetivos segn
su importancia y siempre ajustndolo a los limites posibles?
(3)SP1.1: Se definen y documentan objetivos operativos de medicin para la
unidad de desarrollo alineados a los objetivos estratgicos de la organizacin?
(por ejemplo: objetivo estratgico-aumentar satisfaccin del cliente, objetivo
operativo para la unidad de desarrollo-reducir errores en produccin)
(4)SP1.1: Se dispone una trazabilidad entre las necesidades de
informacin ylos objetivos?
(5)SP1.1: Se revisan peridicamente los indicadores y se actualizan en
caso necesario?
(6)SP1.2: Existe una definicin operativa clara y sin ambigedades para
cada indicador (ej.: descripcin del indicador, frmula, unidades de
medicin, etc.)?
(7)SP1.2: Se identifican medidas candidatas basadas en los objetivos y
se clasifican?
(8)SP1.2: Se identifican medidas ya existentes que se ocupen ya de los
objetivos en el proyecto o en otros de la organizacin?
(9)SP1.3: Se identifican las fuentes existentes de datos que se generan
en la labor actual?
(10)SP1.3: Se identifican las medidas que son necesarias pero que no
estn disponibles an?
(11)SP1.3: Los procedimientos de recogida y almacenamiento de los
indicadores son estndar para todos los proyectos?

(12)SP1.3: Para cada indicador, se ha especificado cmo calcular la

medida, la frecuencia de clculo,

quin es el responsable de tomar la

medida y dnde se ha de guardar su resultado? (Por ejemplo: de dnde

obtener los datos de entrada al indicador, forma de clculo, posibles
procedimientos y herramientas para su obtencin).
(13)SP1.3: Existen herramientas que ayuden a la recogida y clculo
automtico de los indicadores?
(14)SP1.3: Existen Procesos, Procedimientos, Plantillas, Herramientas
para Medicin y Anlisis? La utilizan los proyectos?
(15)SP1.3: Se revisan y actualizan los procesos de recogida de datos
para una posible mejora?
(16)SP1.3: Se valora las medidas segn su esfuerzo en obtenerlas o su
importancia y se actualizan?
(17)SP1.4: Se especifica el procedimiento de anlisis y los informes que
se prepararn?
(18)SP1.4: Se analizan los datos de acuerdo al procedimiento de anlisis
definido (responsable de anlisis, forma de anlisis, frecuencia)?
(19)SP1.4: Para cada indicador, se ha especificado quin y a quines se
han de comunicar los resultados de la medida?
(20)SP1.4: Se revisan los contenidos y formatos de los anlisis e
informes para una posible actualizacin?
(21)SP1.4: Se especifican los criterios para evaluar la utilidad de los
anlisis?
(22)SP2.1: Se realizan controles de integridad de los datos lo ms
cercano posible a la fuente?
(23)SP2.2: Se interpretan los resultados de los datos y se sacan
conclusiones?
(24)SP2.2: Se realizan mediciones adicionales si son necesarias para la
presentacin de los resultados?

(25)SP2.2: Antes de una presentacin ms amplia, Se examinan los datos

junto con las personas interesadas de las mediciones?
(26)SP2.2: Se perfeccionan los criterios para la validez de las
necesidades de informacin y de los objetivos?
(27)SP2.2: En caso de identificar desviaciones significativas durante la
medicin y anlisis se emprenden acciones para solucionar la causa de la
desviacin?
(28)SP2.3: Se examinan los datos histricos para asegurar su integridad,
exactitud y extensin?
(29)SP2.3: Se asegura la seguridad sobre el acceso a los datos (uso
exclusivo del algn grupo o personal, uso indebido)?
(30)SP2.4: Los resultados de la medicin y del anlisis se comunican a
las partes interesadas en el momento oportuno para que lleven a cabo las
acciones que vean necesarias?
(31)SP2.5: Se ayuda a las partes interesadas de las mediciones y anlisis,
a su comprensin?
Estado Inicial Prcticas Especficas SAM

Si
No

(1)SP1.1: Para determinar el tipo de adquisicin para cada producto o

componente de producto a ser adquirido. Existe en la organizacin, o en el
mbito de los proyectos un listado con los tipos de adquisiciones posibles
para los proyectos? Por ejemplo: HW, SW: COTS, diseos grficos, mdulos,
entre otros.
(2)SP1.2: Existe una lista de proveedores homologados de los que
realizar adquisiciones?
(3)SP1.2: Existen criterios que determinen qu proveedores seleccionar?
(4)SP1.2: Se evala el riesgo de seleccionar uno u otro proveedor?; se
incluye ese riesgo en la seccin de riesgos del plan de proyecto?
(5)SP1.3: Se especifica claramente en el contrato los requisitos que el/los

Work Products deben contener?

(6)SP1.3: Se especifica en el contrato un plan de seguimiento sobre el
proveedor? Por ejemplo informes de progreso, reuniones de seguimiento,
etc
(7)SP1.3: Se identifica quienes sern los responsables de posibles
cambios en el contrato y como sern comunicados?
(8)SP1.3: Se identifican las responsabilidades del proveedor con
respecto a sus productos y su mantenimiento?
(9)SP1.3: Se revisa nuestro plan de proyecto para alinearlo con el del
proveedor?
(10)SP1.3: Se da seguimiento formal al progreso del proveedor para ver
si se ajusta a lo planificado?
(11)SP1.3: Se reflejan los posibles cambios en el proceso o en los
productos del proveedor?
(12)SP2.1: Se realizan revisiones tcnicas de seguimiento?
(13)SP2.1: Se da seguimiento y analizan los procesos del proveedor para
ver si se ajustan a los requisitos del acuerdo establecido?
(14)SP2.2: Se monitoriza algunos procesos claves del proveedor para ver
su rendimiento a fin de detectar posibles problemas que puedan afectar a
cumplir los requisitos del acuerdo?
(15)SP2.2: Se toman acciones correctivas ante los desvos en los
procesos?
(16)SP2.3: Existen criterios para seleccionar los productos a evaluar?
(17)SP2.3: Se evalan formalmente los productos seleccionados? Se ve
si su arquitectura es factible y va a satisfacer cambios futuros, se mira si
son compatibles con el resto de productos?
(18)SP2.3:
deficiencias?

Se

toman

acciones

correctivas

para

solucionar

las

(19)SP2.4: Se han establecido criterios, tests y procedimientos para la

aceptacin del producto?
(20)SP2.4: Se verifica que el producto cumple los requisitos para la
aceptacin?
(21)SP2.4: Se documentan los resultados de los test de aceptacin?
(22)SP2.4: Se ha establecido un plan de accin con el proveedor para
cualquier Work Product que no pasa las pruebas de aceptacin?
(23)SP2.4: Se asegura que se reciben todos los productos de trabajo
especificados en el acuerdo de servicio?
(24)SP2.5: Se ha planificado la transicin/integracin del producto del
proveedor en nuestro desarrollo?
(25)SP2.5: Se asegura el almacenamiento, uso de los productos
adquiridos as como se tiene una buena formacin de los empleados sobre
estos?
(26) Existen Procesos, Procedimientos, Plantillas, Herramientas para la
Gestin de Acuerdos con Proveedores? La utilizan los proyectos?
Estado Inicial Prcticas Especficas CM

Si
No

(1)SP1.1: Se han identificado los Work Products o elementos de

configuracin que van a ser designados como una entidad para la gestin de
configuracin? Como posibles Work Products estn descripciones de
proceso, requisitos, manuales, interfaces, cdigo fuente, etc.
(2)SP1.1: Para la identificacin de las entidades para la gestin de
configuracin se han tenido en cuenta una serie de criterios bien
documentados?
(3)SP1.1: Se le asignan identificadores nicos a las entidades para la
gestin de configuracin?
(4)SP1.1: Se especifican caractersticas importantes de las entidades
para la gestin de configuracin, como por ejemplo el autor, lenguaje de
programacin, nombre archivo, etc.?

(5)SP1.1:

Se

identifica

documenta

cuando

cada

entidad

de

configuracin estar bajo la gestin de configuracin?

(6)SP1.1: Se identifica el responsable de la configuracin de cada
entidad?
(7)SP1.2: Se tiene un mecanismo para la gestin de diferentes niveles de
control? Los niveles pueden ir desde una simple revisin informal por parte
del autor hasta niveles de control ms complejos con la participacin del
cliente.
(8)SP1.2: Existe un sistema de control de versiones para controlar los
Work Products bajo la gestin de configuracin?
(9)SP1.2: Todos los miembros del equipo de proyecto hacen uso del
sistema de control de versiones para archivar, actualizar y recuperar los
Work Products bajo la gestin de configuracin?
(10)SP1.2: Cuando se guarda una versin es posible etiquetarla
describiendo exactamente qu contiene?, es decir es posible saber qu
cambios, qu funciones concretas incluye una versin de una fecha
concreta?
(11)SP1.2: Se dispone de un sistema para registrar las peticiones de
cambio a los Work Products bajo la gestin de configuracin?
(12)SP1.2: Se ha establecido un sistema de copias de seguridad y
recuperacin para preservar el contenido del sistema de gestin de
configuracin?
(13)SP1.3: Se han identificado y documentado los productos de trabajo
que conformarn cada lnea base? aclaracin: en Ingeniera de Software una
lnea base es una agrupacin de requisitos, diseo, cdigo fuente,
ejecutables, documentacin de usuario, etc. a la cual se le ha asignado un
identificador nico. Cuando se genera una lnea base, los elementos que la
componen se consideran estables. Cualquier cambio a estos elementos una
vez que son lnea base, se deberan gestionar a travs de un proceso formal
de cambio

(14)SP1.3:

Est

definido

claramente

quin

est

autorizado

para

crear/liberar una lnea base?

(15)SP1.3: El conjunto de las lneas base son de fcil acceso?
(16)SP2.1: Existe algn procedimiento escrito que establezca cmo se
gestionan las peticiones de cambio?
(17)SP2.1: El registro de las peticiones de cambio incluye campos que
permiten la adecuada gestin de las mismas (ej.: estado de la peticin,
productos afectados, esfuerzo estimado, responsable asignado, etc.)?
(18)SP2.1: Se realiza un adecuado seguimiento del estado de las
peticiones de cambio hasta su cierre?
(19)SP2.1: Se analiza el impacto de los cambios y las correcciones al
proyecto?
(20)SP2.1: Se examinan las solicitudes de cambio que se abordarn en la
siguiente lnea base, obteniendo un acuerdo entre las partes implicadas y
justificando toda decisin?
(21)SP2.2: Se tiene un control de los elementos de configuracin durante
toda la vida til del producto?
(22)SP2.2: Antes de cambiar una configuracin se obtiene la autorizacin
de la persona apropiada?
(23)SP2.2:

Se

utilizan

mecanismos

de

check-in,

check-out

para

incorporar los cambios de manera que se garantice la integridad de los

elementos de configuracin?
(24)SP2.2: Se hace una evaluacin de los cambios para comprobar que
no se han causado efectos no deseados sobre la lnea de base, como por
ejemplo comprometer la seguridad del sistema?
(25)SP3.1: Se detallan las versiones especficas de los elementos de
configuracin que conforman una lnea base particular?
(26)SP3.1: Es posible recuperar una versin antigua?

(27)SP3.1: Se especifica la versin ms actual

del elemento de

configuracin?
(28)SP3.1: Se especifican las diferencias entre sucesivas lneas base?
(29)SP3.2: Se evala la integridad de las lneas base y se confirma el
correcto seguimiento de los procedimientos y cumplimiento de los
requisitos?
(30)SP: Existen Procesos, Procedimientos, Plantillas, Herramientas para
la Gestin de la Configuracin? La utilizan los proyectos?

Estado Inicial Prcticas Especficas CM

Si
No

(1)SP1.1: Se dispone de plantillas de Estructura de Desglose de Trabajo

(WBS) estndar (por tipologa de proyectos) en la unidad organizativa?
(2)SP1.1: Se desarrolla un WBS de la arquitectura del producto teniendo
en cuenta que se puedan identificar los riegos y sus tareas de mitigacin,
tareas de prestaciones de apoyo, tareas de adquisicin de nuevos
conocimientos, tareas para la integracin, tareas para control de calidad o
verificacin de planes
(3)SP1.1: Se identifican los paquetes de trabajo con suficiente detalle
como para precisar estimaciones de tareas de proyecto, responsabilidades y
calendario?
(4)SP1.1: Se identifican los productos que se adquirirn externamente?
(5)SP1.1: Se identifican los Work Products que sern reutilizados?
(6)SP1.2: Se establecen estimaciones de los Work Products?, se pueden
realizar estimaciones posteriormente de coste teniendo en cuenta el tamao
de los Work Products (lneas de cdigo, nmero de funciones, nmero de
clases, etc.). Los mtodos para determinar el tamao y la complejidad de los
mismos deben basarse en modelos validados o datos histricos
(7)SP1.3: Se establece el ciclo de vida del proyecto?

(8)SP1.4: Se estima las horas de trabajo y el coste del proyecto (teniendo

en

cuenta

los

atributos

de

los

Work

Products,

necesidades

de

infraestructura, etc.?
(9)SP1.4:

Quedan

documentadas

las

estimaciones

junto

los

criterios/razones para establecerlas?

(10)SP2.1: Se identifican los principales hitos del proyecto?
(11)SP2.1: Se identifican las limitaciones de tiempo, recursos que se
tienen para la hora de crear el calendario?
(12)SP2.1: Se identifican las dependencias de las tareas (predecesorsucesor) y se intentan reducir al mnimo el tiempo global de la tarea con
mtodos como el camino critico CPM?
(13)SP2.1: Se establece y mantiene el presupuesto y calendario general
del proyecto?
(14)SP2.1: Se ha establecido un criterio de lo que constituye una
desviacin significativa respecto del plan de proyecto (y que por tanto nos
defina cundo deberamos replanificar el proyecto)?
(15)SP2.2: Se identifica y documenta una lista de riesgos para el proyecto
(ej.: falta de recursos, falta de conocimiento, etc.)? Se determinan la
probabilidad de ocurrencia, impacto y gravedad de cada riesgo?
(16)SP2.2: Se revisa y mantiene actualizada la lista de riesgos del
proyecto (ej.: pueden surgir nuevos riesgos, desaparecer otros, cambiar la
probabilidad o impacto de un riesgo segn cambian las circunstancias del
proyecto)?
(17)SP2.2: Se obtiene un acuerdo en forma de documento con las partes
interesadas sobre la correccin de los riegos documentados?
(18)SP2.3: Se establecen procedimientos para garantizar la privacidad y
seguridad de documentos del proyecto?
(19)SP2.3: Se determinan los datos del proyecto a recopilar, identificar y
distribuir?

(20)SP2.4: Se definen las necesidades de personal del proyecto (ej.:

necesito 2 analistas y 4 programadores)?
(21)SP2.4: Se definen las necesidades de infraestructura del proyecto
(ej.: equipamiento, HW, SW, instalaciones...)?
(22)SP2.5: En caso de no disponerse de los conocimientos requeridos por
el proyecto se seleccionan mecanismos para conseguirlos (ej.: asistir a un
curso, auto-formacin, contratacin de un externo)?
(23)SP2.6: Estn definidos los roles y responsabilidades de las partes
interesadas para cada actividad del ciclo de vida?; se definen las
interacciones entre las partes interesadas? Una buena forma de tener esto
es una matriz bidimensional con las partes interesadas en un eje y las
actividades del proyecto en otro eje.
(24)SP2.7: Se ha documentado un plan general de proyecto que incluya
todos los aspectos de la gestin de proyectos? Existen plantillas que
ayuden a desarrollar dicho plan de proyecto
(25)SP3.1: Se revisan los planes del proyecto para un total entendimiento
entre todas las partes involucradas?
(26)SP3.1: Existen evidencias de la coordinacin entre los involucrados
en el plan de proyecto a travs de reuniones y acuerdos?
(27)SP3.2: En caso necesario, se modifica/ajusta el plan de proyecto para
adaptarlo a los recursos disponibles (ej.: se renegocian presupuestos, se
revisan

calendarios,

se

renegocian

los

acuerdos

con

las

partes

interesadas)?; quedan evidencias de las acciones anteriores?

(28)SP3.3: Se presenta el plan de proyecto a todas las personas
involucradas en el proyecto, buscando as su conformidad? Queda
evidencia de la ejecucin de estas presentaciones/reuniones, bien a travs
de actas de reunin, emails, etc.?

Estado Inicial Prcticas Especficas PPQA

Si
No

(1)SP1.1: Se realizan auditoras peridicas de aseguramiento de la

calidad para evaluar si los procesos seguidos en el proyecto cumplen con
los procesos, estndares y procedimientos establecidos en la organizacin?
(2)SP1.1: Se han establecido criterios claros (responde a Qu, Cundo,
Cmo, Quin) para que las auditoras de los procesos se lleven a cabo de
forma objetiva? (nota: los resultados de la auditora deberan ser los mismos
independientemente del auditor que la realice)
(3)SP1.2: Se registran las no conformidades de las auditorias a procesos
de forma que puedan ser gestionadas y se les pueda dar seguimiento?
(4)SP1.2: Se realizan auditoras peridicas de aseguramiento de la
calidad para verificar si los Work Products generados en el proyecto
cumplen con los criterios de calidad, estndares y procedimientos
establecidos en la organizacin?
(5)SP1.2: Se han establecido criterios claros (responde a Qu, Cundo,
Cmo, Quin) para que las auditoras de los Work Products se lleven a cabo
de forma objetiva? (nota: los resultados de la auditora deberan ser los
mismos independientemente del auditor que la realice)
(6)SP1.2: Se registran las no conformidades de las auditorias a Work
Products de forma que puedan ser gestionadas y se les pueda dar
seguimiento?
(7)SP1.2: Se han prefijado unos puntos (calendario) a lo largo de la vida
(fases ms crticas, antes de la entrega al cliente, etc.) del proyecto en los
que auditar los productos de trabajo?
(8)SP2.1: Se determinan y registran acciones correctivas destinadas a
resolver las no conformidades?
(9)SP2.1: Se da un seguimiento apropiado (ej.: revisiones peridicas,
fechas concretas de revisin para las cuales la no conformidad debera estar
resuelta, revisin del estado en la prxima auditora) a las no conformidades
hasta su cierre?

(10)SP2.1: En caso de que la no conformidad no pueda ser cerrada por el

propio equipo del proyecto, se ha definido un mecanismo de escalado para
asegurar su resolucin
(11)SP2.1: Se asegura de que las partes interesadas son conscientes de
los resultados de las evaluaciones y las tendencias de la calidad de forma
oportuna?
(12)SP2.2: Se desarrollan informes de auditora que reflejen el resultado
de las revisiones de aseguramiento de la calidad en los proyectos: n de
noconformidades detectadas por proceso, n no-conformidades abiertas,
cerradas, etc.?
(13)SP2.2: Existen Procesos, Procedimientos, Plantillas, Herramientas
para el Aseguramiento de la Calidad de los Procesos y Productos? La
utilizan los proyectos?