Tesis Eliana (1.5) Con Formato PDF

UNIVERSIDAD DE ORIENTE
NCLEO DE SUCRE
ESCUELA DE CIENCIAS
DEPARTAMENTO DE MATEMTICAS
PROGRAMA DE LA LICENCIATURA EN INFORMTICA

MEJORA DE PROCESOS DE DESARROLLO DE SOFTWARE EN INCUBADOS
TIC DE LA CORPORACIN PARQUE TECNOLGICO DE ORIENTE TOMANDO
COMO REFERENCIA AL MODELO CMMI
(Modalidad: Pasanta de Grado)

ELIANA DEL CARMEN DAZ HERRERA

TRABAJO DE GRADO PRESENTADO COMO REQUISITO PARCIAL PARA
OBTAR EL TTULO DE LICENCIADA EN INFORMTICA

CUMAN, 2014
II

MEJORA DE PROCESOS DE DESARROLLO DE SOFTWARE EN INCUBADOS
TIC DE LA CORPORACIN PARQUE TECNOLGICO DE ORIENTE TOMANDO
COMO REFERENCIA AL MODELO CMMI

APROBADO POR:

_____________________________
Prof. Joyce Urbina
Asesora Acadmica

_____________________________
Ing. Ramn Gorrn
Asesor Institucional

_______________________________
Jurado

__________________________________
Jurado

III

NDICE

Pg.
DEDICATORIA ............................................................................................................... V
AGRADECIMIENTOS ................................................................................................... VI
LISTA DE TABLAS ..................................................................................................... VII
LISTA DE FIGURAS ................................................................................................... VIII
LISTA DE ABREVIATURAS ........................................................................................ IX
RESUMEN .................................................................................................................... XII
INTRODUCCIN ............................................................................................................. 1
CAPTULO I. PRESENTACIN ..................................................................................... 6
1.1 PLANTEAMIENTO DEL PROBLEMA ........................................................... 6
1.2 ALCANCE Y LIMITACIONES ......................................................................... 8
1.2.1 Alcance ........................................................................................................ 8
1.2.2 Limitaciones ................................................................................................. 8
CAPTULO II. MARCO DE REFERENCIA ................................................................... 9
2.1 MARCO TERICO ............................................................................................ 9
2.1.1 Antecedentes de la investigacin ................................................................. 9
2.1.2 Antecedentes de la organizacin ................................................................ 10
2.1.3 Bases tericas ............................................................................................. 12
2.2 Marco metodolgico ......................................................................................... 20
2.2.1 Metodologa de la investigacin ................................................................ 20
2.2.2 Metodologa del rea aplicada ................................................................... 21
CAPITULO III. DESARROLLO .................................................................................... 36
3.1 Fase de inicio ..................................................................................................... 36
3.1.1 Primeros pasos ........................................................................................... 36
3.1.2 Identificar las necesidades comerciales y las guas para la mejora ........... 38
3.1.3 Construir una propuesta inicial SPI ........................................................... 40
3.1.4 Obtener la aprobacin del SPI ................................................................... 41
3.1.5 Definicin de los objetivos generales de la SPI ......................................... 42
3.2 Fase de diagnstico ........................................................................................... 44
3.2.1 Determinar las lneas bases que son necesarias para realizar la
propuesta de SPI ........................................................................................ 44
3.2.2 Determinar la conducta de las lneas bases ................................................ 53
3.2.3 Presentar los resultados .............................................................................. 55
3.2.4 Anlisis de los resultados ........................................................................... 60
3.3 Fase de establecimiento ..................................................................................... 63
3.3.1 Establecer prioridades ................................................................................ 63
3.3.2 Desarrollar la propuesta SPI ...................................................................... 64
3.3.2.1 Gestin de requisitos .......................................................................... 64
3.3.2.2 Planificacin de proyectos .................................................................. 72
3.3.2.3 Monitorizacin y control de proyectos ............................................... 87
3.3.2.4 Medicin y anlisis ............................................................................. 93
3.3.2.5 Gestin de acuerdos con proveedores .............................................. 108
IV

3.3.2.6 Gestin de configuracin .................................................................. 115
3.3.2.7 Aseguramiento de la calidad de productos y procesos ..................... 129
3.3.2.8 Prcticas genricas ............................................................................ 136
CONCLUSIONES ......................................................................................................... 140
RECOMENDACIONES ................................................................................................ 142
BIBLIOGRAFA ........................................................................................................... 144
APNDICES ................................................................................................................. 148
ANEXOS ....................................................................................................................... 166

V

DEDICATORIA

Este trabajo est dedicado a:

Dios, por haberme permitido alcanzar la meta propuesta, dndome fuerzas en el camino
sin perder la fe y la esperanza en lo que se espera.

Mis padres, Yracema Herrera y Arnoldo Daz por haberme dado la vida e impulsado a
alcanzar mis sueos, a mis hermanos Elianka Daz y Anthony Daz por su apoyo
incondicional.

Mi novio, Francisco Gerardino que estuvo a mi lado durante todo el camino dndome
fuerzas y su apoyo incondicional.

VI

AGRADECIMIENTOS

A:

Mi madre por brindarme el apoyo necesario.

Todos los profesores y educadores que a lo largo de mi vida me han suministrado las
herramientas necesarias para desarrollarme como persona y profesional.

Mis asesores, Joyce Urbina y Ramn Gorrn quienes me brindaron su ayuda y
conocimientos durante todo este proceso. Gracias.

A mi novio Francisco Gerardino y mis amigos Jos Luis Arredondo, Lezaida, Jos
Torrens, Daniel Villalba quienes siempre me acompaaron y me brindaron sus consejos.

Todos los profesores de la Licenciatura en Informtica quienes me han inculcado todos
sus conocimientos los cuales me han ayudado a desarrollarme como persona y
profesional.
VII

LISTA DE TABLAS

Pg.
Tabla 1. Definicin de calidad segn la poca. ............................................................... 16
Tabla 2. Tareas de la fase de inicio. ................................................................................. 23
Tabla 3. Tareas de la fase de diagnstico. ....................................................................... 30
Tabla 4. Tareas de la fase de establecimiento. ................................................................. 31
Tabla 5. Tareas de la fase de actuacin. .......................................................................... 33
Tabla 6. Tareas de la fase de aprovechamiento. .............................................................. 34
Tabla 7. Actividades realizadas en la fase de inicio. ....................................................... 36
Tabla 8. Actividades realizadas en la fase de diagnstico. .............................................. 44
Tabla 9. Objetivos y prcticas especficas de REQM. ..................................................... 46
Tabla 10. Objetivos y prcticas especficas de PP. .......................................................... 47
Tabla 11. Objetivos y prcticas especficas del PMC. ..................................................... 49
Tabla 12. Objetivos y prcticas especficas de MA. ........................................................ 50
Tabla 13. Objetivos y prcticas especficas de SAM. ...................................................... 50
Tabla 14. Objetivos y prcticas especficas de CM. ........................................................ 51
Tabla 15. Objetivos y prcticas especficas del PPQA. ................................................... 52
Tabla 16. Objetivos y prcticas genricas del nivel de madurez 2 de CMMI. ................ 53
Tabla 17. SP correspondientes al rea de REQM. ........................................................... 55
Tabla 18. SP correspondientes al rea de PP. .................................................................. 56
Tabla 19. SP correspondientes al rea de PMC. .............................................................. 57
Tabla 20. SP correspondientes al rea de MA. ................................................................ 57
Tabla 21. SP correspondientes al rea de SAM. .............................................................. 58
Tabla 22. SP correspondientes al rea de CM. ................................................................ 59
Tabla 23. SP correspondientes al rea de PPQA. ............................................................ 59
Tabla 24. Prcticas genricas. .......................................................................................... 60
Tabla 25. Matriz FODA de los incubados SIM C.A. de la CPTO. .................................. 61
Tabla 26. Actividades realizadas en la fase de establecimiento. ..................................... 63
Tabla 27. Roles que interactan en un proceso de control de cambio. ............................ 68
Tabla 28. Roles relevante para la gestin de riesgos. ...................................................... 83

VIII

LISTA DE FIGURAS

Pg.
Figura 1. Estructura del modelo en cascada. ................................................................... 13
Figura 2. Estructura del modelo en V. ............................................................................. 14
Figura 3. Estructura del modelo en espiral. ..................................................................... 15
Figura 4. Estructura del modelo IDEAL. ......................................................................... 22
Figura 5. Niveles de madurez de CMMI. ........................................................................ 26
Figura 6. reas de procesos por cada nivel de madurez de CMMI. ................................ 27
Figura 7. reas de procesos grupadas por categora de CMMI. ...................................... 28
Figura 8. Visin CMMI en niveles de madurez. .............................................................. 28
Figura 9. Estructura de la lista de verificacin. ............................................................... 54
Figura 10. Grfica de porcentajes de respuestas del rea de REQM. .............................. 56
Figura 11. Grfica de porcentajes de respuestas del rea de PP. ..................................... 56
Figura 12. Grfica de porcentajes de respuestas del rea de PCM. ................................. 57
Figura 13. Grfica de porcentajes de respuestas del rea de MA. ................................... 58
Figura 14. Grfica de porcentajes de respuestas del rea de SAM. ................................. 58
Figura 15. Grfica de porcentajes de respuestas del rea de CM. ................................... 59
Figura 16. Grfica de porcentajes de respuestas del rea de PPQA. ............................... 60
Figura 17. Grfica de porcentajes de respuestas de las prcticas genricas. ................... 60
Figura 18. Incorporacin de los elementos a una lnea base en un ciclo de vida en
cascada. ......................................................................................................... 122
Figura 19. Estado de solicitudes de cambio. .................................................................. 124
Figura 20. Modelo bloquear, modificar, desbloquear. ................................................... 126
Figura 21. Las tres dimensiones crticas. ....................................................................... 130

IX

LISTA DE ABREVIATURAS

SPI (Software, Processes, Improved): Proceso de Mejora de Software.

CMMI (Capability Maturity Model Integration): Modelo Integrado de Madurez y
Capacidad.

CPTO: Corporacin Parque Tecnolgico de Oriente.

SIM: Soluciones Informtica Manzanares.

IDEAL (Initiating, Diagnosing, Establishing, Acting, Leveraging): Inicio, Diagnostico,
Establecimiento, Actuacin y Aprovechamiento.

ISO (International Organization for Standardization): Organizacin Internacional de
Normalizacin.

IPPD (Integrated Product and Process Development): Integracin de Productos y
Desarrollo de Procesos.

CAR (Causal Analysis and Resolution): Anlisis de Causas y Resolucin.

CM (Configuration Management): Gestin de Configuracin.

DAR (Desicion Analysis and Resolution): Anlisis de Decisiones y Resolucin.

IPM (Integrated Project Management): Gestin Integrada de Proyectos.

MA (Measurement and Analysis): Medicin y Anlisis.

OID (Organizational Innovation and Deployment): Innovacin y Despliegue
Organizacionales.

OPD (Organizational Process Definition): Definicin de Procesos Organizacionales.

OPF (Organizational Process Focus): Enfoque Organizacional de Procesos.

OPP (Organizational Process Performance): Rendimiento de Procesos
Organizacionales.

OT (Organizational Training): Formacin Organizacional.

PI (Product Integration): Integracin de Productos.
X

PMC (Project Monitoring and Control): Control y Monitorizacin de Proyectos.

QPM (Quantitative Project Management): Gestin Cuantitativa de Proyectos.

RD (Requirements Development): Desarrollo de Requerimientos.

REQM (Requirements Management): Gestin de Requerimientos.

RSKM (Risk Management): Gestin de Riesgos.

SAM (Supplier Agreement Management): Gestin de Acuerdos con Proveedores.

TS (Technical Solution): Solucin Tcnica.

PP (Project Planning): Planificacin de Proyectos.

PPQA (Process and Product Quality Assurance): Aseguramiento de Calidad de
Procesos y Productos.

VAL (Validation): Validacin.

VER (Verification): Verificacin.

MSG (Management Steering Group): Grupo Directivo de Gestin.

SEPG (Software Engineering Process Group): Grupo de Procesos de Ingeniera de
Software.

TWG (Technical Working Group): Grupo de Trabajo Tcnico.

PYME: Pequea y Mediana Empresa.

ERS : Especificacin de Requerimientos.

GCC: Grupo de Control de Cambio.

EDT: Estructura de Desglose de Trabajo.

PMI (Project Management Institute): Instituto de Gestin de Proyectos.

CPM (Critical Path Method): Mtodo del Camino Critico.

EVM (Earned Value Management): Gestin del Valor Ganado.

XI

VP: Valor Planeado.

VG: Valor Ganado.

VR: Valor Real.

SV (Variation Schedule): Variacin del Cronograma.

CV (Change in Cost): Variacin del Costo.

EDR: Estructura de Desglose de Riesgos.

PMB (Project Management Body of Knowledge): Fundamentos de la Direccin de
Proyectos.

VS: Versus.

LOPD: Ley Orgnica de Proteccin de Datos.

TIC: Tecnologas de la Informacin y la Comunicacin.
IACCM (International Association for Contract and Commercial Management):
Asociacin Internacional para la Gestin de Contratos y Comercio.

SEI (Software Engineering Institute): Instituto de Ingeniera de Software.
XII

RESUMEN

Se desarroll una propuesta de Procesos de Mejora de Software (SPI) para elevar los
procesos de desarrollo que realizan las empresas de Tecnologas de la Informacin y la
Comunicacin (TIC) incubadas en la Corporacin Parque Tecnolgico de Oriente. El
diseo de esta propuesta permitir en este caso a los incubados TIC de Soluciones
Informticas Manzanares C.A. determinar cules son los procesos en el desarrollo de
software en los que se encuentran deficientes segn el Modelo Integrado de Madurez y
Capacidad (CMMI), posteriormente fueron planteadas mejoras que les permitirn
alcanzar en un futuro un nivel de madurez dos (2) que garantice la planificacin y el
cumplimiento de los procesos que establezca la organizacin. Se tom el modelo IDEAL
como gua proponer los cambios en la empresa, por otra parte se plante como modelo
de referencia para evaluar y determinar las mejoras a realizar el modelo CMMI para el
desarrollo versin 1.2 (Chrisis y cols., 2009). Durante el desarrollo de la propuesta
fueron evaluadas las siete (7) reas de proceso establecidas en CMMI para alcanzar un
nivel de madurez dos (2), mediante la aplicacin de las listas de verificacin tomadas de
(Sanz, 2009) titulado Implantacin de CMMI en Pequeas Empresas de Desarrollo de
Software, luego se determinaron qu prcticas se encuentran deficientes en la
organizacin y en base a esto se propusieron las mejoras a implementar para alcanzar el
nivel propuesto. Las evaluaciones y las mejoras propuestas en este trabajo pueden ser
ejecutadas en cualquier empresa pequea de desarrollo de software que desee alcanzar
un nivel de madurez dos (2) segn el modelo CMMI.

1

INTRODUCCIN

La alta competencia entre las empresas ocasiona que muchas de ellas se esfuercen por
entregar mejores productos y servicios en menor tiempo y menor costo, logrando as
satisfacer las necesidades de sus clientes. A nivel mundial, todos los procesos o
actividades que se ejecutan para obtener resultados satisfactorios dentro de una
organizacin dependen, en la mayora de los casos, de un sistema de informacin, el cual
es determinante para el funcionamiento, crecimiento y xito de la misma (Chrisis y cols.,
2009).

Para que una organizacin tenga un nivel competitivo adecuado, debe tener muy en
cuenta los factores relacionados con la tecnologa, los recursos, tanto humanos como
materiales disponibles, y establecer de forma clara y precisa la misin, visin y objetivos
de dicha entidad (Chrisis y cols., 2009). Las organizaciones se definen como una
asociacin de personas reguladas por un conjunto de normas en funcin de
determinados fines (RAE, 2006).

Durante la dcada de los aos 60 (en el siglo XX) se desarrollaban en las organizaciones
(universidades y empresas) sistemas en lenguajes de programacin de carcter general y
especficos, dado las distintas reas de conocimiento en las cuales se trabajaba, no
existan mtricas para medir cules eran los lenguajes que beneficiaban a ciertos
desarrollos. A mediados de esta dcada surgi lo que se denomin multiprogramacin,
sta consiste en que el sistema operativo aprovecha tiempos muertos para ejecutar un
programa, el sistema operativo OS/360, desarrollado por la IBM entre 1965 y 1972, fue
el primero en implementarlo; pero trajo consigo grandes problemas como: errores
deterministas, corrupcin de datos compartidos e interbloqueos. La versin de este
sistema operativo se consider como uno de los peores del mundo (Pea, 2010).

Por tal razn surge la idea de la creacin de un lenguaje de programacin que sirviera
para todo, que dispusiera de una buena notacin matemtica y una entrada/salida de

2
datos verstil y eficiente, sin embargo los esfuerzos fueron en vano y se reconoce lo que
se denomin la crisis del software (Pea, 2010).

En una conferencia internacional realizada en Alemania por la Organizacin del Tratado
del Atlntico Norte (OTAN) en 1968, cuyo nombre fue Ingeniera de Software, se
discuti todo lo referente a tan importante crisis, con el fin de evidenciar la ausencia de
una disciplina sobre el desarrollo de software. Esta disciplina lleva el mismo nombre de
la conferencia, ingeniera de software, la cual se define como la rama de la ingeniera
que crea y mantiene las aplicaciones de software usando tecnologas y prcticas de las
ciencias de la computacin, manejo de proyectos, ingeniera, el mbito de la aplicacin y
otros campos (Menndez, 2004).

As, como la ingeniera de software propone un conjunto de metodologas, tales como: el
Proceso Unificado (UP), Programacin Extrema (XP), Scrum, Watch, entre otras,
tambin propone un conjunto de estndares y modelos para determinar la calidad de un
producto de software, uno de ellos es el Modelo Integrado de Madurez y Capacidad
(CMMI), el cual surge debido al problema de integrar la ingeniera de sistemas, la
ingeniera de software y la ingeniera de productos; ya que cada una de estas disciplinas
atacaba un rea especfica, por lo cual resultaba muy costoso y hasta complicado
capacitar a un personal para cada una de estas reas. CMMI permite la integracin de
estas disciplinas, ya que contiene un conjunto de modelos para ser aplicados a las
diferentes reas (INTECO, 2009).

CMMI para el desarrollo contempla las buenas prcticas relativas a las actividades
de desarrollo y mantenimiento aplicadas a los productos y servicios. Tratan las
prcticas que cubren el ciclo de vida del producto desde la concepcin hasta la
entrega y el mantenimiento (Chrisis y cols., 2009).

A travs de la adopcin de CMMI para el desarrollo versin 1.2, las organizaciones
observan una reduccin en sus costos de produccin, mayor calidad en cuanto a sus
productos, debido a que cuentan con modelo de calidad que define sus procesos y se

3
obtiene un cliente satisfecho, informado e involucrado en el desarrollo (De Luna, 2009).
Es por ello que CMMI permite a las empresas desarrolladoras de software obtener una
mejora continua en sus procesos de desarrollo, ayudando a cumplir con las metas y
objetivos creados por la misma. La Corporacin Parque Tecnolgico de Oriente (CPTO)
es una organizacin de la Universidad de Oriente que posee una incubadora la cual
alberga iniciativas empresariales, especialmente del rea de las Tecnologas de la
Informacin y la Comunicacin (TIC), cuyos productos son esencialmente software de
diferentes tipos. La CPTO est organizada por una junta directiva que tiene como
propsito

Atender y satisfacer las demandas del entorno regional, nacional e internacional
en el rea de innovacin de servicios y tecnologas productivas, formando y
capacitando recurso humano emprendedor e investigador, ofreciendo servicios de
apoyo y espacios de calidad para la instalacin e incubacin de empresas y la
elaboracin de proyectos en funcin del desarrollo social y econmico de nuestras
poblaciones (Corporacin Parque Tecnolgico de Oriente, 2011).

La CPTO se encuentra entre las empresas que prestan servicios, uno de estos es el de
incubacin de empresas tecnolgicas que a su vez pueden producir software para un
mercado determinado (Corporacin Parque Tecnolgico de Oriente, 2011).

Las organizaciones TIC que se encuentran incubadas en la CPTO desarrollan sistemas
de informacin de diversas ndoles, sin embargo estos grupos que hacen vida en la
CPTO no cuentan con antecedentes de calidad ni con modelos que guen sus procesos de
desarrollo, lo que les dificulta alcanzar sus objetivos a la hora de realizar sus proyectos.
Tal es el caso de Soluciones Informticas Manzanares (SIM C.A.), la cual cuenta con
cinco (5) aos de experiencia en el desarrollo de software y tiene como visin ser una
empresa reconocida nacional e internacionalmente en el rea de prestacin de servicios
orientados al desarrollo de software (Corporacin Parque Tecnolgico de Oriente,
2011).

Una incubadora de empresas se puede definir como:

4
Una organizacin que tiene como propsito generar ambientes y escenarios que
promuevan y faciliten la formacin de empresas exitosas, inteligentes, sostenibles
y con altos niveles de cooperacin y trabajo en red, capaces de generar empleo y
desarrollo en su entorno. La incubadora consume, genera y desarrolla conceptos,
mecanismos y estrategias de vanguardia pensando en las necesidades de los
clientes para convertir a los emprendedores en gerentes y a las ideas en empresas.
La combinacin de estos elementos genera un efecto sinrgico que desencadena
en resultados favorables para la vida de la nueva empresa (Corporacin Parque
Tecnolgico de Mrida, 2011).

Una incubacin se puede definir como:

Un proceso organizado en condiciones controladas para minimizar riesgos,
dirigido a prestar soporte a nuevos emprendedores, que procura acelerar el
desarrollo exitoso de sus nacientes empresas, creando la oportunidad de
desarrollar sus propias ideas innovadoras, o dar inicio a nuevos productos en
empresas ya establecidas (Corporacin Parque Tecnolgico de Oriente, 2011).

Muchas empresas jvenes que no cuentan con la infraestructura necesaria y recursos
para equipos, encuentran en la incubacin la solucin para comenzar su negocio, sin
embargo no basta con esto, debido a su corta experiencia, les resulta difcil entrar al
mercado competitivo y hacerse de un nombre que les permita equipararse para ser
comparadas con empresas de larga trayectoria.

En virtud de esta situacin se propone: mejora de procesos de desarrollo de software en
incubados TIC de la Corporacin Parque Tecnolgico de Oriente tomando como
referencia el modelo CMMI, y en el que se plantearon los siguientes objetivos:
determinar la disposicin y estimular el patrocinio para la implementacin de un plan de
mejora en los incubados TIC de la CPTO, diagnosticar el estado actual en los procesos
realizados por los incubados TIC de la CPTO, determinando sus debilidades y fortalezas
con respecto a CMMI, para la realizacin de las mejoras, Disear un plan de accin
estratgico de mejora de los procesos de software integrado con el plan de negocio, la
visin y misin de los incubados TIC de la CPTO.

El trabajo se encuentra estructurado en tres (3) captulos, en el captulo I se describe la

5
problemtica que ha llevado a la organizacin a buscar una propuesta de mejora que
eleve sus procesos de desarrollo, as como el alcance y las limitaciones del trabajo de
investigacin realizado; en el captulo II se detalla el marco de referencia, los
antecedentes tanto de la investigacin como de la organizacin, se exponen los
fundamentos tericos necesarios para el desarrollo del modelo planeado, adems se
especifica la metodologa utilizada y el modelo en que se bas la propuesta; por ltimo
el captulo III muestra cada uno de los resultados obtenidos en las actividades de la
metodologa y detalla la propuesta planteada a los incubados de SIM C.A. de la CPTO
para la elevacin de sus procesos a un nivel dos (2) segn CMMI, finalmente, se
presentan las conclusiones y recomendaciones as como la descripcin de la bibliografa
consultada para la elaboracin del trabajo de investigacin.

6
CAPTULO I. PRESENTACIN

1.1 PLANTEAMIENTO DEL PROBLEMA

La CPTO es una empresa que garantiza tanto los recursos humanos como la
infraestructura necesaria para la transformacin del conocimiento en un producto
comercial (Corporacin Parque Tecnolgico de Oriente, 2011). Entre los servicios que
ofrece este ente, se encuentra la incubacin de empresas que estn iniciando sus
funciones en el mercado laboral.

La CPTO presta sus servicios a diferentes tipos de incubados, entre los que se hallan los
incubados TIC, estas son empresas encargadas de desarrollar sistemas de diversas
ndoles. Durante la incubacin las empresas pasan por tres (3) etapas importantes, de
acuerdo a su nivel de madurez y crecimiento; Pre-incubacin, Incubacin, Post-
incubacin. Las empresas que se encuentran incubadas en las instalaciones de la CPTO,
hacen uso de los servicios de infraestructura, capacitacin, asesora, acompaamiento y
red de proveedores, de esta forma estas organizaciones tienen ambientes propicios y
recursos a la hora de desarrollar sus productos (software).

En la actualidad el desarrollo de software es un mercado sumamente competitivo, las
organizaciones realizan grandes esfuerzos para entrar a este, y aquellas que se
encuentran en l luchan por mantenerse; y es que para cumplir con los requerimientos de
sus clientes, en ocasiones es necesario de un equipo grande y especializado en diferentes
reas del ciclo de vida del desarrollo de software; por lo que las organizaciones deben
ser capaces de administrar sus equipos de manera eficiente para la generacin de un
producto de calidad.

Por lo general las empresas no tienden a utilizar o aplicar procesos de desarrollo tanto
como deberan, ya sea por falta de conocimiento o por poca experiencia. Este es uno de
los factores que influye en los problemas que ocurren con el desarrollo de software,

7
muchos de los cuales o nunca salen o salen con claras deficiencias, lo que para una
empresa que se encuentra iniciando sus actividades suele ser fatal (Chrisis y cols., 2009).
Tal es el caso de SIM C.A., a quienes les fue aplicado un conjunto de entrevistas
preliminares (apndice A) y se logr evidenciar los siguientes problemas: no cuentan
con una estructura de procesos clara que les permita asignar las actividades a su
personal, lo cual genera fallas en la entrega de sus productos, incumpliendo con las
fechas pautadas con sus clientes, lo que ocasiona que la organizacin no cumpla con los
objetivos trazados al principio de la planificacin.

Es necesario acotar que para una empresa desarrolladora de software el incumplimiento
de las fechas pautadas sobre la entrega de sus productos, no slo le genera una imagen
negativa ante sus clientes, esto tambin genera prdidas de dinero, debido a que las
horas establecidas para el desarrollo se duplican y en algunos casos pueden triplicarse, la
organizacin estar obligada a pagarle horas extra a su personal, el presupuesto
calculado inicialmente se puede elevar considerablemente lo que ocasiona prdidas en
lugar de ganancias para la organizacin.

Las organizaciones deben tener claro en qu parte de su proceso de desarrollo se
encuentran y cunto falta para ser culminados sus productos. As lograrn cumplir con
las fechas de entrega y con los requisitos establecidos por sus clientes. Adems, deben
contar con un modelo de calidad de procesos que permita desarrollar el potencial del
personal que en ellas labora, dando como resultado la generacin de productos de
excelencia (Chrisis y cols., 2009).

Por tal razn se realiz una propuesta basada en el modelo CMMI que permita a los
incubados de SIM C.A. de la CPTO elevar sus procesos de desarrollo a un nivel de
madurez dos (2).

8
1.2 ALCANCE Y LIMITACIONES

1.2.1 Alcance

La propuesta de SPI, se elabora para todas aquellas empresas pequeas desarrolladoras
de software que se encuentran incubadas en la CPTO o que estn iniciando sus
funciones en los procesos de desarrollo y tienen caractersticas similares a los incubados
TIC, sta permite realizar un diagnstico a cada una de las siete (7) reas funcionales
que establece el CMMI, determinando cules son las debilidades y en cual o cuales reas
del proceso de desarrollo de software las organizaciones deben enfocar sus esfuerzos en
pro de mejorar su desarrollo y alcanzar un nivel de madurez dos (2), con respecto a las
debilidades encontradas mediante el diagnstico la propuesta provee un conjunto de
recomendaciones enfocadas en las mejores prcticas para el desarrollo de software.

Para el desarrollo de la propuesta de SPI, se utiliza el modelo de mejora denominado
Inicio, Diagnstico, Establecimiento, Actuacin y Aprovechamiento (IDEAL) que
proporcion una gua para realizar los cambios de forma correcta (McFeeley, 2009).
Este modelo proporciona una serie de pasos para que los cambios realizados sean
ejecutados con el menor impacto posible y con la mayor suma de beneficios. Por otra
parte se utiliza como referencia de calidad el CMMI el cual suministra los procesos que
una organizacin debe realizar para ser calificada en un nivel dos (2) de madurez
(Chrisis y cols., 2009).

1.2.2 Limitaciones

Elevar los procesos de desarrollo de software de una organizacin de un nivel uno (1) a
un nivel dos (2) segn CMMI, tarda aproximadamente de uno (1) a dos (2) aos por lo
que el desarrollo de este trabajo se limit al anlisis y diseo de una propuesta para la
elevacin de sus procesos segn el modelo planteado. Los modelos de calidad en
Venezuela son un tema relativamente nuevo, por lo que no se encontr numerosa
cantidad de antecedentes que pudieran guiar la investigacin.

9
CAPTULO II. MARCO DE REFERENCIA

2.1 MARCO TERICO

2.1.1 Antecedentes de la investigacin

Se puede considerar que un software se desarrolla con xito cuando: satisface las
necesidades de las personas que lo utilizan, funciona de forma impecable durante mucho
tiempo, es fcil de utilizar y modificar, de lo contrario, cuando es difcil de utilizar y
tiene demasiados errores se considera que se ha fallado en el desarrollo de software
(INTECO, 2009).

Existen diferentes metodologas para el desarrollo de software pero todas tienen como
fin desarrollar software de calidad, sin embargo usar una metodologa no asegura un
desarrollo de calidad, hace falta un modelo que gue el desarrollo y asegure el
cumplimiento de los estndares de calidad (Universidad Nacional de Pampa, 1999).
Dentro de los modelos de calidad para el desarrollo de software se encuentra CMMI el
cual fue desarrollado por Software Engineering Institute (SEI) perteneciente a la
Carnegie Mellon University. Estos modelos pueden ser adaptados segn las
caractersticas de la organizacin, mejorando los resultados obtenidos por estas mediante
el desarrollo de software (Carnegie Mellon, 2002).

Durante las investigaciones realizadas se encuentra el trabajo desarrollado en el 2008
por Rodrguez titulada Factibilidad de Implementacin del nivel 2 de CMMI en una
Organizacin de Software Pequea: Caso Divisin de Sistemas de la Universidad
Francisco de Paula Santander ubicada en Colombia. Este trabajo plante un modelo que
toma como base el diagnstico realizado a la organizacin, se evaluaron los procesos de
desarrollo de dicha organizacin con respecto al modelo CMMI y se dise un nuevo
modelo definiendo los aspectos metodolgicos y gerenciales para que la organizacin
pudiera escalar a un nivel 2 de CMMI. Tras la implementacin de CMMI, la

10
organizacin cont con una metodologa que le permiti institucionalizar y mejorar sus
procesos, los resultados de CMMI no son visibles de manera inmediata lleva tiempo que
las organizaciones puedan afrontar dichos cambios y obtener resultados.

Este proyecto fue tomado como referencia puesto que proporcion la tcnica de la
matriz de fortalezas, oportunidades, debilidades y amenazas (FODA) para la recoleccin
de datos lo que permiti analizar la situacin actual de los incubados SIM C.A. de la
CPTO para tomar acciones correctivas en un futuro.

Por otra parte, en el 2009 Sanz realiz una investigacin de maestra titulada
Implantacin de CMMI en Pequeas Empresas de Desarrollo de Software, este trabajo
estuvo dedicado a estudiar la implantacin del nivel 2 de CMMI en una pequea
empresa de desarrollo de software de la comunidad Valenciana, ubicada en Espaa, la
cual se bas en el estudio de CMMI para posteriormente realizar un diagnstico de la
situacin actual de los procesos de desarrollo que implementaba la organizacin y
proponer una solucin que le permita a sta elevar sus procesos a un nivel 2 segn el
modelo planteado. Una de las conclusiones desprendidas de este trabajo es que existen
modelos que se adaptan mejor a empresas pequeas como son los orientados a la mejora
del producto TPI/TMAP, mientras que en empresas medianas o grandes modelos como
CMMI o ISO/IEC 15504 se adaptan mejor.

Esta investigacin sirvi como base para realizar las evaluaciones que plantea el modelo
CMMI en cada una de las reas de procesos a travs de una lista de verificacin que
evidenci la ausencia o presencia de las practicas necesarias que una organizacin debe
realizar para alcanzar el nivel de madurez 2.

2.1.2 Antecedentes de la organizacin

El 26 de julio de 2006, se crea la CPTO como una Corporacin Civil, por parte de la
Universidad de Oriente, con la participacin de FUNDACITE - Sucre y PDVSA, en el

11
entendido de dar un gran paso para hacer trascender la universidad a los pueblos que la
circundan.

La CPTO, es una entidad sin fines de lucro, cuya misin fundamental es integrar a las
instituciones cientficas y tecnolgicas del oriente del pas; as como establecer una
relacin entre estas instituciones y el sector productivo regional, nacional e
internacional.

El directorio de la CPTO est conformado por la Universidad de Oriente, vanguardia de
su creacin, FUNDACITE - Sucre, PDVSA y FUNDAUDO y tiene como principal
asociado al sector productivo de la regin. La CPTO brinda accesibilidad al desarrollo
de nuevos negocios y consolidacin de aquellos que estando establecidos, requieran de
asesoramiento, proveyendo ambiente y servicio ptimo para la innovacin e incubacin
de empresas que requieran de base tecnolgica.

La CPTO, tiene su asentamiento en el antiguo edificio de CORPORIENTE,
actualmente LUIS MANUEL PEALVER, el cual se adecua para brindar todos los
servicios, con los adelantos tecnolgicos requeridos, para atender con prontitud y
eficiencia las necesidades de aquellas empresas que deseen incubarse (Corporacin
Parque Tecnolgico Oriente, 2008).

En cuanto a los primeros incubados en el rea de las TIC, la CPTO albergo a SIM C.A.,
una empresa creada en el 2008 que fue contratada por la principal empresa del pas:
Petrleos de Venezuela para el desarrollo de un proyecto de gran envergadura y de
mbito nacional, sin embargo este proyecto fue cancelado por la recesin econmica que
afrontaba el pas.

No obstante, SIM C.A., intentaron abrirse camino en el estado pero chocaron con la
cruda realidad de ser una empresa joven sin trayectoria, sin embargo vieron en la
incubacin la oportunidad y el respaldo que necesitaban para desarrollarse como una

12
empresa slida. No es sino a partir del 19 de mayo del 2009 cuando comenzaron a fungir
como empresa incubada de la CPTO e iniciaron actividades de promocin y mercadeo
de los servicios que ofrecen.

Actualmente son un equipo de doce (12) personas y las tareas van desde produccin,
actividades de marketing y gerenciales, por otro lado, se han especializado en tres (3)
aspectos principales: desarrollo de soluciones y sitios Web a la medida, desarrollo para
dispositivos mviles y estrategias de posicionamiento buscadores u Optimizacin de
motores de bsqueda o Search Engine Optimization (SEO).

2.1.3 Bases tericas

La ingeniera de software constituyeron el rea de estudio que fundamenta este trabajo
de grado ya que sta comprende todos los aspectos de la produccin del software desde
las etapas inciales de la especificacin del sistema, hasta el mantenimiento de ste
despus que se utiliza (Sommerville, 2005).

Muchas personas tienden a confundir la ingeniera de software con otras ingenieras
(ingeniera en computacin, ingeniera de sistemas) sin embargo existen diferencias
notables entre estas, por ejemplo, la ingeniera en computacin le conciernen las teoras
y fundamentos de cualquier sistema de computo (hardware y software), por su parte la
ingeniera de software slo le competen los aspectos prcticos del desarrollo y puesta en
marcha de productos tiles de software, as mismo la ingeniera de sistemas es la
encarga de todos los aspectos del desarrollo de sistemas basados en cmputo incluyendo
hardware, software e ingeniera de procesos, la ingeniera de software es una parte de
este proceso que comprende el desarrollo, control, aplicaciones y bases de datos del
sistema (Rodrguez, 2010).

En resumen se puede determinar que la ingeniera de software proporciona un proceso
sistematizado en cuanto a las actividades concernientes al desarrollo. Se puede definir al

13
proceso de desarrollo de software como un conjunto estructurado de actividades cuya
meta es el desarrollo o evolucin del software (Rodrguez, 2010). Pero
independientemente del proceso de desarrollo de software que se utilice, siempre se debe
aplicar un modelo de ciclo de vida; este se define como un marco de referencia que
contiene los procesos, actividades y tareas involucradas en el desarrollo, la explotacin y
el mantenimiento de un producto de software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su uso (INTECO, 2009).

La ingeniera de software propone diferentes tipos de ciclos de vida, el primer modelo
fue el modelo en cascada o lineal desarrollado por Royce y fue publicado en un artculo
en 1970. Este modelo establece que las diversas actividades que se van realizando al
desarrollar un producto software, se suceden de forma lineal, es decir se avanza de una
fase a la siguiente en una forma puramente secuencial (INTECO, 2009). La Figura 1
muestra el ciclo mencionado.

Figura 1. Estructura del modelo en cascada.

Sin embargo en la ejecucin de este modelo los errores eran encontrados muy tarde en el
ciclo de vida y esto se debe a que las pruebas al software eran realizadas al final del
proyecto. Entonces surge lo que se denomin el modelo en V, que ilustra cmo las
actividades de prueba (verificacin y validacin) se pueden integrar en cada fase del
ciclo de vida. Dentro del modelo en V, como se aprecia en la Figura 2, las pruebas de

14
validacin tienen lugar especialmente durante las etapas tempranas, por ejemplo, en la
revisin de los requisitos de usuario y despus durante las pruebas de aceptacin de
usuario (INTECO, 2009).

Figura 2. Estructura del modelo en V.

No obstante este modelo es bastante criticado por lo rgido y la poca flexibilidad que
ofrece a la hora de desarrollar software, durante mucho tiempo siguen surgiendo
diferentes modelos, uno de los ms aceptados fue el modelo en espiral propuesto por
Boehm en 1988 en su artculo A Spiral Model of Software Development and
Enhancement que consiste en una serie de ciclos que se repiten en forma de espiral,
comenzando desde el centro, se suele interpretar como que dentro de cada ciclo de la
espiral se sigue un modelo en cascada, sin embargo no necesariamente es as (INTECO,
2009). El modelo en espiral no fue el primero en tratar el modelo iterativo pero si el
primero en explicar en qu consistan esas iteraciones. Ver Figura 3.

Para lograr el xito en la implementacin de un ciclo de vida existen diferentes
metodologas que suelen definir una estrategia global para enfrentarse al desarrollo de
un proyecto. Una metodologa es un conjunto integrado de tcnicas y mtodos que
permite abordar de forma homognea y abierta cada una de las actividades del ciclo de

15
vida de un proyecto de desarrollo. Una definicin estndar de metodologa puede ser el
conjunto de mtodos que se utilizan en una determinada actividad con el fin de
formalizarla y optimizarla. Determina los pasos a seguir y cmo realizarlos para finalizar
una tarea (INTECO, 2009).

Figura 3. Estructura del modelo en espiral.

Existen diferentes enfoques para las metodologas de desarrollo, las cuales estn
orientadas al control de los procesos, estableciendo un proceso riguroso de las
actividades a desarrollar, herramientas a utilizar y notaciones que se usarn. Estas
metodologas son llamadas metodologas pesadas entre las cuales se encuentran el
Proceso Unificado (UP), Gray Watch y MSF (Microsoft Solution Framework). Por otra
parte se encuentran las metodologas orientadas a la interaccin con el cliente y el
desarrollo incremental del software, mostrando versiones parcialmente funcionales del
software al cliente en intervalos cortos de tiempo, para que pueda evaluar y sugerir
cambios en el producto segn se va desarrollando las cuales son llamadas metodologas
ligeras/giles entre las que se hallan Programacin Extrema (XP), DSDM (Dynamic
Systems Developmemt Method) y FDD (Feature Driven Development) por mencionar
slo algunas (Quispe, 2007).

DETERMINAR
OBJETIVOS
EVALUAR
RIESGOS
PLANIFICAR DESARROLLAR
Y PROBAR

16
Sin embargo la utilizacin de una metodologa de desarrollo no garantiza que los
procesos que ejecuta una organizacin produzcan productos de calidad, manteniendo un
control sobre los avances y su obtencin en el tiempo establecido. Por lo que las
organizaciones han optado por institucionalizar sus procesos de desarrollo mediante la
utilizacin de modelos de calidad de desarrollo de software. Un modelo de calidad es un
conjunto de buenas prcticas para el ciclo de vida del software, enfocado en los procesos
de gestin y desarrollo de proyectos. Estos guan a las organizaciones durante su proceso
de desarrollo, logrando que produzcan sus productos (software) en menor tiempo, con
un presupuesto estable y con mayor calidad (Quispe, 2007).

La calidad de forma general puede tener muchos significados, su definicin ha ido
evolucionando segn el paso del tiempo, durante diferentes pocas ha existido la calidad
sin embargo su significado y finalidad ha variado segn esta. En la Tabla 1 se describen
los diferentes conceptos de calidad.

Sin embargo la calidad de software puede definirse segn la norma ISO en 2009 como
el conjunto de caractersticas de una entidad que le confieren su actitud para satisfacer
las necesidades expresadas y las implcitas (Cueva, 1999).

Tabla 1. Definicin de calidad segn la poca.
Etapa Concepto Finalidad
Artesanal
Hacer las cosas bien sin
mirar costo o esfuerzo
necesario para ello.
Satisfacer al cliente.
Autosatisfaccin del
Artesano.
Crear un producto nico.

Revolucin industrial
Hacer muchas cosas sin
importar que sean de
calidad.
Satisfacer una gran
demanda de bienes.
Obtener beneficios.

Segunda guerra mundial
Asegurar la eficacia del
armamento con mayor y
ms rpida produccin.
Garantizar la
disponibilidad del
armamento, eficaz en
cantidad y plazo.

17
Tabla 1. Continuacin.
Etapa Concepto Finalidad
Postguerra
Japn: Hacer las cosas bien
a la primera.
Minimizar costos
mediante la calidad.
Ser competitivo.

Resto: Producir cuanto ms
mejor.
Satisfacer gran demanda
de bienes causadas por la
guerra.

Control de calidad
Inspeccin en produccin
para evitar vienes
defectuosos.

Satisfacer las demandas
tcnicas del producto.
Aseguramiento de calidad
Sistemas y procedimientos
de la organizacin para
evitar que se produzcan
vienes defectuosos.
Prevenir errores.
Reducir costos y ser
competitivo.

Calidad total
Administracin empresarial
permanente centrada en la
satisfaccin de las
expectativas del cliente.
Satisfacer al cliente
interno y externo.
Ser altamente
competitivo.
Mejora continua.

Aquellas organizaciones que deseen asegurar el desarrollo de software de calidad deben
conocer los diferentes principios asociados a la calidad como por ejemplo el
aseguramiento de calidad del software (Software Quality Assurance) el cual se basa en
un conjunto de actividades planificadas y sistemticas necesarias para aportar la
confianza en que el producto (software) cumplir con todos los procedimientos y
tcnicas necesarias para desarrollar software de calidad (Quispe, 2007).

El aseguramiento de calidad est presente en mtodos, herramientas de anlisis, diseo,
programacin, prueba, en inspecciones tcnicas formales realizadas en todos los pasos
del proceso de desarrollo, en estrategias de prueba multiescala, control de la
documentacin del software, cambios realizados y en mecanismos de medida (mtricas)
entre otros.

18
Por otra parte, la gestin de la calidad del software (Software Quality Management) es la
encarga del conjunto de actividades por parte de la direccin de una empresa para
determinar la calidad, los objetivos y las responsabilidades en el desarrollo de software
(Quispe, 2007). La gestin o administracin de la calidad suele aplicarse a nivel
empresarial o dentro de la gestin de cada proyecto, esta tiene como propsito entender
las expectativas del cliente en trminos de calidad, para desarrollar un plan proactivo
que permita satisfacer esas expectativas de sus clientes.

Por ltimo pero no menos importante, control de calidad de software (Software Quality
Control). Este se basa en tcnicas y actividades de carcter operativo que son utilizadas
para satisfacer los requisitos asociados a la calidad. Tiene dos objetivos fundamentales
los cuales son: mantener bajo control un proceso de desarrollo y eliminar las causas que
generan problemas en las actividades del proceso (Quispe, 2007).

Cada uno de los principios antes mencionados deben estar presentes si las
organizaciones desean algn tipo de garanta en cuanto a la generacin de productos de
calidad. Para esto se han desarrollado diferentes modelos de calidad que han puesto en
prctica cada uno de estos principios, entre los modelos de calidad de desarrollo de
software se encuentra la norma ISO 9000 conformada por 5 estndares internacionales
(ISO 9000, 9001, 9002, 9003, 9004) de administracin y aseguramiento de calidad
genricos. ISO 9000 garantiza la calidad del producto o servicio, evitando costos de
inspecciones. Esto da como resultado un cliente con mayor confianza en la organizacin
(Quispe, 2007).

Dentro de este orden de ideas se encuentra la norma ISO 15504 SPICE, es una norma
abierta e internacional que permite evaluar, mejorar la capacidad y madurez de los
procesos, la cual aplicada conjuntamente con la norma ISO 12207 permite realizar una
evaluacin, mejorar la calidad del proceso de desarrollo y ayudar al mantenimiento de
software (Portal en espaol de la ISO, 2011).

19
Adicional a esto, uno de los modelos que ha ido tomando un gran auge con el pasar del
tiempo es el CMMI, este se centra en el dominio de la Ingeniera de Software, lo cual da
una aproximacin objetiva para medir la madurez de una organizacin para desarrollar
software de alta calidad, en tiempo y con el presupuesto inicialmente asignado.
Proporciona un framework para incrementar las capacidades del desarrollo de software a
lo largo del tiempo; todo esto con la finalidad de establecer una gua para las
organizaciones de software que quieren mejorar el control sobre sus procesos de
desarrollo y mantenimiento y evolucionar hacia una cultura de ingeniera del software y
gestin controlada (Chrisis y cols., 2009).

Por consiguiente, si una empresa desea incrementar la calidad de su proceso de
desarrollo, debe elegir el modelo de calidad que mejor se adapte a la organizacin y en
base a esto realizar cambios pertinentes en su desarrollo e institucionalizar esos cambios
para lograr la mejora deseada.

En muchas ocasiones, la mejor forma de realizar cambios en una empresa es de manera
progresiva, con el objetivo de que la empresa no sufra ninguna prdida durante el tiempo
de cambio que les pueda llevar a desaparecer, para esto se han creado modelos que guan
los cambios progresivamente en una organizacin con el menor impacto posible, tal es el
caso del modelo IDEAL 1.0, su nombre est formado por las cinco (5) fases que lo
componen, Inicio, Diagnostico, Establecimiento, Actuacin y Aprovechamiento, el cual
proporcion un marco que permite que los cambios se propongan de manera eficaz
(McFeeley, 2009).

El modelo IDEAL asegura que los cambios se realicen correctamente y en mutuo
acuerdo con la organizacin, el modelo gua a las organizaciones durante todo el proceso
de cambio, manteniendo la comunicacin entre todos sus miembros y permitiendo que
estos elijan el modelo de calidad que mejor se adapte a sus necesidades, este permite al
equipo de cambio crear una propuesta de mejora, que le ser presentada a la
organizacin para iniciar los cambios. Una propuesta de SPI es un conjunto integrado de

20
iniciativas cuyo objetivo es el mejoramiento de las actividades de desarrollo y/o
mantenimiento de productos basados en software (Scanziani, 2008).

2.2 Marco metodolgico

2.2.1 Metodologa de la investigacin

Propsito de la investigacin

El trabajo de grado que se realiz se consider de tipo aplicado, porque el conocimiento
que de l se obtuvo, est disponible para ser utilizado en forma directa e inmediata
(Sabino, 2000). Con la elaboracin de la propuesta de SPI, SIM C.A. conocieron cuales
eran las reas de procesos que deban ser mejoradas para elevar el nivel de calidad de
sus productos.

Nivel de investigacin

Para la realizacin de este trabajo, el nivel de la investigacin se consider de tipo
descriptiva, ya que se puntualiz un problema especfico y se hall una solucin, a partir
de un criterio o modelo terico definido con anterioridad, sin llegar a considerar la
verificacin de la hiptesis planteada (Sabino, 2000). En el desarrollo de esta
investigacin se hizo uso de conceptos y estndares de desarrollo de software de calidad,
que permiti llegar a la construccin de una propuesta de SPI adaptada a las necesidades
de los incubados TIC de CPTO.

Diseo de investigacin

El diseo de la investigacin es de campo, dado que los datos necesarios para la
investigacin se obtuvieron en forma directa de la realidad. Adicionalmente, se utiliz la
investigacin documental para llevar a cabo la obtencin y anlisis de datos

21
provenientes de materiales impresos u otro tipo de documentos (Sabino, 2000). Los
incubados TIC de la CPTO, especficamente SIM C.A., proporcionaron la informacin
necesaria para el desarrollo de la propuesta, a travs de tcnicas de recoleccin como
listas de verificacin que evidenciaron el estado real de los procesos que realizan.

Tcnicas de recoleccin de datos

Se realizaron entrevistas estructuradas y no estructuradas a SIM C.A. de la CPTO, as
como el llenado de una lista de verificacin y una matriz FODA para determinar que
procesos llevan a cabo y el nivel de madurez de stos, lo que permiti la recopilacin de
informacin referente a las diversas problemticas que presentan en el manejo de los
procesos de desarrollo. Las revisiones documentales se efectuaron con el fin de obtener
informacin adicional necesaria para el desarrollo de la propuesta de SPI.

2.2.2 Metodologa del rea aplicada

Para la realizacin de la propuesta planteada se utiliz el modelo IDEAL 1.0, el cual est
diseado originalmente para guiar procesos de mejora de desarrollo de software
(McFeeley, 2009). Dicho modelo proporcion un marco que permiti identificar el nivel
de madurez de la organizacin objeto de estudio y disear los cambios que se deben
realizar para alcanzar los objetivos planteados y mejorar las reas de procesos que no
cumplan con los criterios establecidos por el CMMI para alcanzar el nivel 2 de madurez.

El modelo IDEAL est compuesto por cinco (5) fases las cuales se presentan en la
Figura 4.

Fase de inicio (Initiating)

La fase de inicio del modelo IDEAL es el punto de partida. Aqu es donde la
infraestructura de la mejora inicial se ha establecido, las funciones y responsabilidades

22
para la infraestructura se definen inicialmente, los recursos son asignados y es creada
una propuesta de SPI para guiar a la organizacin a travs de la fase de diagnstico y
establecimiento. La aprobacin inicial de la propuesta de SPI se obtiene junto con el
compromiso de recursos para el trabajo por delante (McFeeley, 2009).

Figura 4. Estructura del modelo IDEAL.

En esta fase se plantean como objetivos: obtener conocimientos y habilidades para
realizar la propuesta de SPI alineada con las necesidades de la organizacin, establecer
el compromiso para que la propuesta SPI sea exitosa, determinar si la organizacin est
dispuesta a aceptar la propuesta de SPI y de ser afirmativa la respuesta, se debe crear un
horario y una infraestructura para que ser administrada.

As mismo el modelo IDEAL plantea un conjunto de criterios para cumplir
satisfactoriamente con cada uno de los objetivos mencionados anteriormente. Estos
criterios son clasificados en dos, el criterio de entrada, que busca identificar los puntos
crticos del negocio que impulsan a la organizacin a mejorar los procesos de desarrollo
el software; como criterios de salida se tiene como resultado, el establecimiento de la

23
una infraestructura inicial y la formacin de conceptos y actividades de la propuesta de
SPI, que la organizacin ha relacionado con la estrategia empresarial de la organizacin.

De igual forma esta fase est constituida por un conjunto de tareas que guiaran los
esfuerzos de mejora, mediante la realizacin de stas se obtendrn como resultados los
productos mencionados anteriormente en los criterios de salida. A continuacin se
presentan las tareas de la fase de inicio. En la Tabla 2 se observan las actividades de la
fase de inicio.

Tabla 2. Tareas de la fase de inicio.
Fase Tareas
Inicio
1.1 Primeros pasos.
1.2 Identificar las necesidades comerciales y las guas para la
mejora.

1.3 Construir una propuesta de SPI.
1.4 Educar y fomentar el apoyo.
1.5 Obtener la aprobacin para la creacin de la propuesta de SPI.
1.6 Establecer la infraestructura.
1.7 Evaluar el clima para la creacin de la propuesta de SPI.
1.8 Definir los objetivos generales de la propuesta de SPI.
1.9 Definir los principios rectores de la propuesta de SPI.
1.10 Lanzamiento de la propuesta.

Fase de diagnstico (Diagnosing)

La fase de diagnstico del modelo IDEAL inicia a la organizacin en un camino de
mejora continuo en procesos de software, es en esta fase es donde se establecen las bases
para las fases posteriores. El plan de accin para la realizacin de la propuesta SPI se
inicia de acuerdo con la visin de la organizacin, el plan estratgico de negocio, las
lecciones aprendidas de los esfuerzos por mejorar en el pasado, problemas de negocio

24
que enfrenta la organizacin y las metas de largo alcance. Las actividades de evaluacin
se realizan para establecer las lneas base del estado actual de la organizacin. Los
resultados y recomendaciones de las evaluaciones debern ser alineados con los
esfuerzos de mejoras establecidos (McFeeley, 2009).

Al igual que en la fase anterior, la fase de diagnstico contempla un conjunto de
objetivos que se basan en comprender el funcionamiento de los procesos actuales de la
organizacin para as recopilar la informacin sobre las fortalezas, debilidades y
oportunidades de mejora lo que dar como resultado la creacin de la propuesta final de
SPI que permitir la elevacin de sus procesos a un nivel 2 de madurez segn CMMI.

Para lograr comprender el funcionamiento de cada una de las reas funcionales de la
organizacin objeto de estudio y posteriormente conocer sus debilidades, se utiliz
CMMI para el desarrollo (CMMI-DEV) 1.2, el cual es un modelo utilizado por las
organizaciones que desean mejorar sus procesos de desarrollo de software (Sanz, 2009).

La versin 1.2 de CMMI, presenta tres tipos de modelos diferentes que se encuentran
enfocados a diferentes contextos.

CMMI para el desarrollo (CMMI for Development). Este es un modelo enfocado hacia
el desarrollo de software y consiste en dos modelos: CMMI para desarrollo y CMMI +
IPPD para desarrollo. Ambos modelos comparten mucho de sus materiales y son
idnticos en las reas compartidas. Sin embargo, CMMI para desarrollo + IPPD contiene
objetivos y prcticas adicionales que cubren IPPD. CMMI-DEV fue liberado en 2006

CMMI para la adquisicin (CMMI for Acquisition). Es un modelo enfocado hacia la
adquisicin de productos y trata los procesos relacionados con el gobierno, con la
industria, la gestin de cadenas de suministros, adquisicin y contratacin externa. Este
modelo fue liberado en el noviembre 2007 (Sanz, 2009).

25
CMMI para los servicios (CMMI for Services). Este modelo est enfocado hacia la
gestin, establecimiento y entrega de servicios. Fue liberado en febrero de 2009 (Sanz,
2009).

CMMI-DEV tiene 2 elementos bsicos:

Modelos. Descripcin de las mejores prcticas para procesos que permiten la
consecucin de objetivos de negocio. Define el qu hacer.

Mtodos de evaluacin. Permiten medir los procesos de una organizacin a travs de
unos estndares: niveles de madurez y capacidad de un rea de proceso.

Este modelo propone un conjunto de prcticas que se deben realizar para lograr mejorar
los procesos de una organizacin e incrementar su productividad. Estas prcticas estn
asignadas a determinadas reas de procesos los cuales estn dentro de ciertos niveles de
madurez (Chrisis y cols., 2009). La Figura 5 muestra los niveles de madurez
establecidos por CMMI.

Nivel de madurez 1 (Inicial). Las organizaciones que generalmente se encuentran en este
nivel tienen procesos ad-hoc y caticos. Adems, suelen no proporcionar un entorno
estable para dar soporte a los procesos y su xito radica en la competencia y heroicidad
de su personal y no en el uso de procesos probados. Se caracterizan por una tendencia a
comprometerse en exceso y a abandonar los procesos en tiempos de crisis.

Toda organizacin que desarrollo software, para CMMI, se considera como mnimo en
un nivel de madurez 1 segn la representacin por etapas.

Nivel de madurez 2 (Gestionado). La obtencin de este nivel permite a las
organizaciones planificar sus procesos, estos se realizan de acuerdo a sus polticas e
involucran las partes interesadas relevantes. El nivel de madurez 2 ayuda a asegurar que

26
las prcticas existentes se mantengan en tiempo de estrs, lo que permite que sus
productos de trabajo y servicios satisfagan las especificaciones de estndares y
procedimientos.

Figura 5. Niveles de madurez de CMMI.

Nivel de madurez 3 (Definido). Los procesos son bien caracterizados y comprendidos,
se describen en estndares, procedimientos, herramientas y mtodos. El conjunto de
procesos estndar de la organizacin es la base del nivel de madurez 3, el cual se
establece y mejora a lo largo del tiempo.

Nivel de Madurez 4 (Gestionado cuantitativamente). Los procesos se controlan
utilizando tcnicas cuantitativas.

Nivel de madurez 5 (Optimizado). Este nivel cumple con todas las condiciones
establecidas por los niveles anteriores, adems, de forma sistemtica se revisan y
modifican sus procesos para lograr los objetivos de la organizacin.

En cuanto a las reas de proceso que evala CMMI en el mejoramiento de una
organizacin se tienen veintids (22), las cuales son: CAR (Anlisis causal y
resolucin), CM (Gestin de configuracin), DAR (Anlisis de decisiones y resolucin),
IPM + IPPD (Gestin integrada del proyecto + IPPD), MA (Medicin y anlisis), OID
(Innovacin y despliegue en la organizacin), OPD + IPPD (Definicin de procesos de

27
la organizacin + IPPD), OPF (Enfoque en procesos de la organizacin), OPP
(Rendimiento del proceso de la organizacin), OT (Formacin organizativa), PI
(Integracin de producto), PMC (Monitorizacin y control del proyecto), QPM (Gestin
cuantitativa de proyecto), RD (Desarrollo de requisitos), REQM (Gestin de requisitos),
RSKM (Gestin de riesgos), SAM (Gestin de acuerdos con proveedores), TS (Solucin
tcnica), PP (Planificacin de proyectos), PPQA (Aseguramiento de la calidad de
productos y procesos), VAL (Validacin) y VER (Verificacin). Estas reas de proceso
pueden ser agrupadas segn los niveles de madurez como se muestran en la Figura 6.

Figura 6. reas de procesos por cada nivel de madurez de CMMI.

De la misma forma, pueden ser agrupadas segn la categora a la que pertenecen. Esta
visin es utilizada por aquellas organizaciones que desean mejorar una o varias
categoras en especfico. En las Figuras 7 se presentan las reas de proceso agrupadas
segn el nivel al que pertenecen.

Sin importar la visin que sea utilizada (por niveles o categoras) CMMI predefine un
conjunto de prcticas que permitirn lograr los objetivos de cada una de las reas de
proceso mencionadas anteriormente. Las reas de procesos de CMMI se definen como
un grupo de prcticas relacionadas en un rea que, cuando se implementan de forma
conjunta, satisfacen un grupo de objetivos considerados importantes para la mejora en
esa rea (Chrisis y cols., 2009). La Figura 8 muestra la visin de CMMI en niveles de
madurez.

28

Figura 7. reas de procesos grupadas por categora de CMMI.

La representacin por etapas evala las reas de proceso en niveles de madurez, para que
las reas de proceso alcancen los niveles de madurez se deben cumplir dos tipos de
objetivos que se detallan a continuacin:

Objetivo especfico. Este tipo de objetivo se aplica a una nica rea de proceso y deben
ser alcanzados para cumplir el propsito del rea de proceso (Sanz, 2009).

Figura 8. Visin CMMI en niveles de madurez.

29
Objetivo genrico. Son los objetivos que la organizacin debe alcanzar en el nivel de
madurez donde est por lo que se puede encontrar el mismo objetivo en diferentes reas
de proceso (Sanz, 2009).

Por otra parte tanto los objetivos especficos como los genricos se enumeran
secuencialmente. Cada objetivo especfico empieza con el prefijo SG, por ejemplo SG 1.
Por su parte cada objetivo genrico comienza con el prefijo GG, es decir GG 2.

Para alcanzar tanto los objetivos especficos como genricos CMMI especifica un
conjunto de prcticas que a continuacin se mencionan:

Prcticas especficas. Son las actividades que se realizan para cumplir un objetivo
especfico (Sanz, 2009).

Prcticas genricas. Estas prcticas pueden aplicarse en cualquier rea de proceso para
alcanzar los objetivos genricos (Sanz, 2009).

Del mismo modo para enumerar una prctica especfica se debe comenzar con el prefijo
SP, seguido por un nmero en la forma x.y, por ejemplo SP 1.1. La x es el mismo
nmero del objetivo especfico a la que pertenece la prctica especfica. La y es el
nmero de secuencia de la prctica especfica. En el caso de la prctica genrica empieza
con el prefijo GP, seguido por un nmero en la forma x.y, en consecuencia seria GP 1.1.
La x corresponde al nmero del objetivo genrico. La y es el nmero de secuencia de la
prctica genrica.

Son el cumplimiento o ausencia de estas prcticas las que permitirn conocer el estado
de madurez con la que la organizacin objeto de estudio realiza sus procesos.
Presentando posteriormente los resultados del comportamiento inicial de las lneas base
de la organizacin, lo que guiar el diseo de una propuesta SPI que eleve los procesos
que no hayan cumplido con un nivel de madurez aceptable (nivel de madurez 2).

30
Para la realizacin de una propuesta de SPI final, la fase de diagnstico establece como
criterio de entrada el funcionamiento de la infraestructura de SPI, especialmente la
creacin del Grupo Directivo de Gestin (MSG) y el Grupo de Procesos de Ingeniera de
Software (SEPG) a los cuales les sern asignadas responsabilidades distintas que les
permitirn mantener el proceso en tiempo de crisis. Por otra parte deben estar
disponibles los recursos para llevar a cabo el diagnstico en las lneas base. En esta fase
el MSG debe actualizar el plan de accin estratgico teniendo e cuenta que la visin de
la organizacin y el plan de negocio son sinrgicos.

Como criterios de salida de la fase se tiene que los resultados obtenidos mediante el
diagnstico en las lneas base son entregados en un informe de recomendacin al MSG
para posteriormente desarrollar un borrador del plan de accin estratgico de SPI.

Para que el desarrollo de la propuesta final y el mejoramiento de los procesos de la
organizacin sea un xito es de vital importancia que la recoleccin de informacin de
cada una de las lneas base se realice con extremo cuidado. Para esto la fase de
diagnostico estable un conjunto de tareas que indicamos en la Tabla 3.

Tabla 3. Tareas de la fase de diagnstico.
Fase Tareas
Diagnstico
2.1 Determinar qu lnea base(s) son necesarias.
2.2 Plan para la lnea base(s).
2.3 Estado de lneas base(s).
2.4 Presentar los resultados.
2.5 Desarrollar conclusiones y recomendaciones finales.
2.6 Comunicar las conclusiones y recomendaciones a la
organizacin.

Fase de establecimiento

Durante la fase de establecimiento, se da prioridad a los temas que la organizacin ha

31
decidido abordar con sus actividades de mejora, las estrategias para perseguir las
soluciones tambin son desarrollados. El plan de accin de proyecto se completar de
acuerdo con la visin de la organizacin, el plan estratgico del negocio, las lecciones
aprendidas y los esfuerzos por mejorar en el pasado, los puntos claves de negocio frente
a la organizacin y las metas de largo alcance (McFeeley, 2009).

En la fase de establecimiento, entre sus objetivos principales se encuentra desarrollar a
largo plazo (de tres a cinco aos) un plan de accin estratgico de SPI que abarque todas
las actividades de mejora de procesos de software de la organizacin y los integra con
cualquier otra iniciativa de calidad ya planificada o en curso. De la misma forma se debe
desarrollar a corto plazo (un ao) los objetivos de la propuesta de SPI.

Adems se establece que las recomendaciones y conclusiones que se determinaron en la
fase de diagnstico sean integradas con el plan de accin estratgico de la
propuesta SPI y ste a su vez debe ser relacionado con el plan de negocio, la visin y la
misin para lograr la mejora de procesos que se ha propuesto la organizacin.

El modelo IDEAL plantea como criterios de entrada en la fase de establecimiento que
los resultados del diagnstico realizado a las lneas base sean refinados y entregados, y
que la infraestructura creada en la fase anterior se encuentre en funcionamiento. Por su
parte como criterios de salida especifica que el plan de accin estratgico debe ser
terminado y relacionado con la visin de la organizacin y el plan del negocio.

Para lograr el desarrollo del plan de accin estratgico as como los dems objetivos que
establece esta fase, En la Tabla 4 se presentan enumeradas cada una de la fase de
establecimiento.

Tabla 4. Tareas de la fase de establecimiento.
Fase Tareas
Establecimiento 3.1 Establecer prioridades.

32
Fase Tareas
Establecimiento
3.2 Seleccionar y obtener capacitacin en un proceso de
planificacin estratgica.

3.3 Visin crtica de la organizacin.
3.3

Revisin del plan empresarial de la organizacin.
3.4

Determinar las necesidades claves del negocio.
3.5

Revisar esfuerzos de mejora anteriores.
3.6

Describir las motivaciones para la mejorar.
3.7 Identificar actuales y futuros esfuerzos de mejora.
3.8 Finalizacin de funciones y responsabilidades de las
diferentes entidades de infraestructura.

3.9 desarrollar la propuesta SPI.
3.10 Conciliar los esfuerzos de mejora existentes con los
resultados del diagnstico.

3.11 Transformar los objetivos generales de SPI en objetivos
especficos.

3.12 Crear el plan de accin estratgico.
3.13 Revisar y aprobar el plan de accin estratgico SPI.
3.14 Forma el Grupo de Trabajo Tcnico (GTT).

Fase de actuacin

En la fase de actuacin del modelo IDEAL, las soluciones para hacer frente a las reas
de mejora descubiertas durante la fase de diagnstico se crean, se ponen a prueba, se
despliegan en toda la organizacin y se elaborarn planes pilotos para ejecutar, probar y
evaluar los nuevos procesos (McFeeley, 2009).

Dentro de esta fase se tienen como objetivos elaborar y perfeccionar los procesos de
desarrollo de software tomando en cuenta su prioridad en el plan de accin, integrar las
mejoras de los procesos de desarrollo con los planes ya existentes, supervisar y apoyar a

33
la organizacin en la utilizacin de los procesos nuevos, validar, evaluar y refinar la
solucin.

En este caso se especifica en los criterios de entrada que debe existir una descripcin de
alto nivel de los procesos que realiza la organizacin y deben estar definidas las metas
propuestas durante la fase de establecimiento. De esta forma el grupo que trabaja en la
mejora tendr una visin en comn de hacia dnde quiere ir la organizacin y enfocarn
sus esfuerzos en base a esto.

Por lo que respecta a los criterios de salida, en esta fase se establece que la propuesta
final de SPI que guiar a la organizacin a mejorar sus procesos y por ende desarrollar
mejores productos tiene que ser entregada al grupo de SEPG y ste debe realizar un
proceso de institucionalizacin de los nuevos procesos de desarrollo que se
implementarn, obteniendo como resultado un proceso de calidad alineado con la visin
de la empresa lo que permitir a la organizacin alcanzar los objetivos que se
propusieron a futuro. En la Tabla 5 se muestran las tareas que establece esta fase.

Tabla 5. Tareas de la fase de actuacin.
Fase Tareas
Actuacin
4.1 Probar la solucin.
4.2 Refinar la solucin.
4.3 Implementar la solucin.
4.4 Soluciones pilotos.
4.5 Seleccin de los proveedores de soluciones.
4.6 Establecer el apoyo a largo plazo.
4.7 Desarrollar la plantilla del plan estratgico de despliegue.
4.8 Paquete de mejoramiento
4.9 Disolver el GTT.
4.10 Implantacin de las soluciones.
4.11 Transicin de asistencia a largo plazo.

34
Fase de aprovechamiento

El propsito de esta fase es hacer que el siguiente paso a travs del modelo IDEAL sea
ms eficaz. En este momento las soluciones han sido desarrolladas, las lecciones han
sido aprendidas, y las mtricas de desempeo y los logros de los objetivos se han
recogido. Estos artefactos se aaden a la base de datos del proceso y se convertirn en
una fuente de informacin para el personal involucrado (McFeeley, 2009).

En cuanto a los objetivos, esta fase establece que se incorporan las lecciones aprendidas
en las fases anteriores, debe existir una visibilidad de la propuesta final de SPI, se
reafirma el patrocinio, se identifica si existen nuevas lneas base que puedan ser
mejoradas y por ltimo se crea un plan para guiar a la organizacin a travs de un nuevo
ciclo del modelo IDEAL.

Como criterios de entrada a la fase de aprovechamiento se debe haber realizado un
informe de todas la lecciones aprendidas durante las fases anteriores y los artefactos
producidos mediante el desarrollo de la propuesta final de SPI tienen que estar
disponibles. Por lo que se refiere a los criterios de salida, las lecciones aprendidas
durante las fases anteriores son analizadas e incorporadas a la propuesta final de SPI.
Por ltimo, se presentan las tareas de la fase de aprovechamiento que establece el
modelo IDEAL en la Tabla 6.

Tabla 6. Tareas de la fase de aprovechamiento.
Fase Tareas
Aprovechar
5.1 Reunir las lecciones aprendidas.
5.2 Actualizar las lecciones aprendidas.
5.3 Revisar el enfoque de la organizacin.
5.4 Revisar el patrocinio y el compromiso.
5.5 Establecer los objetivos de alto nivel.
5.6 Analizar y validar.
5.7 Proponer futuras acciones.

35
La sumatoria de cada una de las tareas correspondientes a las cinco (5) fases del modelo
IDEAL permite que una organizacin gue sus procesos de mejora y que stos se
establezcan de manera progresiva sin afectar el funcionamiento de la misma.

36
CAPITULO III. DESARROLLO

Este captulo est enfocado en el desarrollo de una propuesta de SPI, la cual se bas en
la aplicacin del modelo IDEAL. A continuacin se detalla la forma en que fue
instanciado el modelo a travs de la descripcin de sus fases y las tareas desarrolladas
dentro de stas para la elaboracin del trabajo de investigacin.

3.1 Fase de inicio

En esta fase se plantearon los acuerdos y se realizaron las investigaciones sobre los
antecedentes de mejoras pasadas, se propuso un modelo a utilizar por la organizacin y
se realiz una propuesta de SPI. En la Tabla 7 se detallan cada una de las tareas que se
realizaron en esta fase.

Tabla 7. Actividades realizadas en la fase de inicio.
Fase Actividades
Inicio
Primeros pasos.
Identificar las necesidades comerciales y las guas para la
mejora.

Construir una propuesta inicial SPI.
Obtener la aprobacin del SPI.
Definicin de los objetivos generales de la SPI.

3.1.1 Primeros pasos

En la actualidad las empresas desarrolladoras de software se encuentran en un punto
donde los productos que deben entregar son ms complejos y su tiempo es limitado,
originando que deban ofrecer sus productos en menor tiempo, en ocasiones stas
subcontratan servicios a otras empresas por lo que no slo deben ser capaces de generar
software, sino que tambin deben poder integrar sus productos y mantener su calidad

37
La generacin de software es un proceso complejo, han transcurrido dcadas y aun se
cometen los mismos errores. La utilizacin de un modelo de calidad disminuye la
probabilidad de cometer errores que puedan ocasionar que un proyecto no se culmine. A
nivel internacional existen organizaciones encargadas de medir la calidad con que se
desarrolla software en la actualidad. Una de ellas es Chaos Report, grupo estadstico
encargado de generar reportes en esta rea, entre algunos de los tems que expresan los
reportes suministrados se encuentran:

El alcance del fracaso de los proyectos de software.
Los principales factores que hacen que los proyectos de software fallen.
Los ingredientes claves que pueden reducir errores en los proyectos.

Segn el informe realizado en abril del 2009 por Chaos Report, muestra que los
proyectos de software tenan una tasa de xito del 32% frente al 35% del estudio anterior
realizado en el 2006, mientras que en 1994 la tasa de xito era de 16%. Por otro lado, el
44% de los proyectos fueron impugnados (tardo, por encima del presupuesto y/o con
menos de las caractersticas requeridas y funciones) mientras que el 24% fracas (Grupo
Trput, 2012).

En Venezuela existen organizaciones enfocadas en la consultora de mejora de procesos
de software, las cuales tienen como finalidad, que otras organizaciones alcancen niveles
de calidad en la prestacin de servicios, tal es el caso de DBACCESS, la cual es una
organizacin latinoamericana de proyeccin global, establecida en 1988 como
proveedora de servicios de Tecnologa de la Informacin (TI), y ms de 1000 proyectos
ejecutados en 15 pases de todo el mundo (DBACCESS, 2009).

Es por ello que, y con el objetivo de guiar a las organizaciones a un proceso de mejora,
fueron creados diferentes modelos de calidad que definen cules son las mejores
prcticas que una organizacin debe implementar para el desarrollo de software y las
caractersticas que deben cumplir. En definitiva, existen un nmero importante de

38
modelos de calidad, unos enfocados a los procesos, otros a los productos, orientados a
empresas pequeas y otros a organizaciones grandes.

En el caso del CMMI se encuentra entre los modelos que ha logrado integrar con xito
diferentes reas del proceso de desarrollo de un producto. Existen antecedentes que
demuestran que el CMMI mediante una instanciacin puede ser aplicado a empresas
pequeas con xito (Garzas, 2009). Basados en esto se decidi que el modelo para
realizar la propuesta seria CMMI debido a que proporciona mltiples beneficios a
cualquier tipo de organizacin (grande, mediana, PYME) y que predefine un camino que
ha sido probado y evaluado.

3.1.2 Identificar las necesidades comerciales y las guas para la mejora

Con el pasar de los aos el software evoluciona rpidamente, en la actualidad los
sistemas se componen por miles de lneas de cdigo, dentro de su desarrollo se
encuentran diferentes personas involucradas, haciendo que los procesos de su desarrollo
de no ser planificados se vuelva una tarea engorrosa, el retraso de los proyectos de una
empresa constituyen una gran prdida para la misma, si un proyecto se retrasa un ao,
este se exceder en un 100% del presupuesto, lo que representa que cuando el sistema
est listo, habrn cambiado las condiciones iniciales y sus requerimientos originales ya
no sern relevantes.

Esto trae como consecuencia la cancelacin de proyectos antes que stos se concluyan.
El Instituto Tecnolgico la Lagunita en el 2010, plante que estadsticamente un 25% de
los proyectos en organizaciones grandes jams se concluyen, algunas de las razones
pueden ser las siguientes:

Problemas tcnicos.
Problemas administrativos.
Personal sin experiencia.

39
Falta de tiempo para poder llevar a cabo un buen trabajo de anlisis y diseo.
Falta de participacin de la administracin y de los usuarios.

Por tal razn, a la hora de desarrollar software se necesita un equipo no slo con
conocimientos en la utilizacin de herramientas para el desarrollo, sino que tambin
deben poseer conocimientos en diferentes reas en el desarrollo para lograr la liberacin
con xito de un producto (Chrisis y cols., 2009).

Se presentan como ejemplos del claro aumento de la complejidad en el desarrollo de
software, haber pasado de desarrollar sistemas ms o menos de 1 milln de lneas de
cdigo en 1990 a sistemas que en 2010 llegan a los 100 millones de lneas de cdigo
(Sanz, 2009). A continuacin se tienen algunos datos de los sistemas operativos ms
conocidos en la actualidad:

Windows 3.11 = 3 millones de lneas de cdigo.
Windows 95 = 15 millones de lneas de cdigo.
Windows 98 = 18 millones de lneas de cdigo.
Windows XP = 40 millones de lneas de cdigo.
Windows Vista = 50 millones de lneas de cdigo.
Ubuntu = 120 millones de lneas de cdigo.
Debian 4.0 = 283 millones de lneas de cdigo.

Evidencindose un claro aumento en la complejidad en el desarrollo de software, es
necesario un cambio, debido a esto se han desarrollado diversos procesos de desarrollo
de software que faciliten la creacin de productos de calidad en las organizaciones. Sin
embargo existe una clara tendencia entre las empresas en abandonar los procesos de
desarrollo en tiempo de crisis dando como resultado la liberacin de un software con
problemas, en el peor de los casos estos productos no son liberados debido a que su
liberacin representan mayor prdida (Sanz, 2009).

En el caso particular de SIM C.A., es una empresa que cuenta con cinco (5) aos en la

40
prestacin de servicios. Dicha empresa tiene como visin ser una empresa reconocida
nacional e internacionalmente en el rea de prestacin de servicios orientados al
desarrollo de software. Sin embargo mediante la aplicacin de un conjunto de
entrevistas se evidenciaron diferentes problemas que presenta esta empresa incubada en
la CPTO a la hora de desarrollar software, los cuales se mencionan:

La empresa no cuenta con una estructura de procesos clara que les facilite la
planificacin de sus proyectos.
Incumple con las fechas pautadas, generando un retraso con las metas
establecidas por la organizacin en cuanto a la entrega de sus productos lo que
ocasiona insatisfaccin por parte de sus clientes.
Carece de criterios de medicin que permitan determinar la calidad de sus
productos (si los productos desarrollos actualmente superan en calidad a los
desarrollados con posterioridad).

Por consiguiente se plante una solucin basada en el CMMI que propone el desarrollo
de siete (7) reas de procesos para que una organizacin pueda alcanzar el nivel de
madurez dos (2). Se realiz un diagnstico en cada una de las reas funcionales de la
empresa SIM C.A. lo que permiti determinar qu prcticas, de las establecidas por el
modelo, la organizacin no cumple. Al conocer cules prcticas no son realizadas, se
analizaron dando como resultado una matriz FODA donde se presentan las debilidades,
amenazas, oportunidades y fortalezas encontradas en la organizacin y a partir de esto se
gener el diseo de una propuesta de SPI que guiar los cambios que se deben efectuar
para alcanzar el nivel de madurez propuesto.

3.1.3 Construir una propuesta inicial SPI

Una propuesta de SPI es un conjunto integrado de iniciativas cuya objetivo es el
mejoramiento de las actividades de desarrollo y/o mantenimiento de productos basados
en software. Tiene como caractersticas principales el compromiso, un programa

41
estratgico bien planificado y medicin de beneficios (indicadores), sin estas
caractersticas es probable que el programa de mejora fracase (Scanziani, 2008).

Se determin realizar una propuesta de proceso de mejora de software a los incubados
TIC de la CPTO, que permitir elevar sus procesos de desarrollo de software a un nivel
dos (2) segn CMMI para el desarrollo versin 1.2. La obtencin de este nivel hace
posible que la empresa realice sus proyectos con procesos que se planifican de acuerdo a
sus polticas; la disciplina del proceso reflejada por el nivel 2 de madurez asegura que
las prcticas existentes se mantengan durante tiempos de estrs y se pueda cumplir con
el presupuesto y tiempo inicialmente establecido por la empresa (Chrisis y cols., 2009).

El uso del nivel dos (2) de CMMI proporciona ciertos beneficios en el desarrollo de
proyectos, como por ejemplo:

Un punto de partida.
Beneficios de experiencias pasadas de la comunidad.
Un lenguaje comn y una visin compartida.
Un marco para priorizar las mejoras.

Los modelos de desarrollo de software proporcionan una gua de cmo las
organizaciones deben realizar sus procesos para que sean eficientes, sin embargo se debe
tener claro que los cambios deben ser realizados de forma progresiva, produciendo el
menor impacto posible en la organizacin durante el tiempo de cambio (McFeeley,
2009). La implementacin y transformacin de los procesos de una organizacin tardan
un promedio de 12 a 24 meses por lo que este trabajo se delimitar a mostrar los
aspectos que coartan a la organizacin y que deben ser mejorados para alcanzar un nivel
de madurez dos (2).

3.1.4 Obtener la aprobacin del SPI

Una iniciativa de mejora sin el apoyo de la direccin se encuentra destinada antes de su

42
comienzo al fracaso por lo que resulta de vital importancia que la direccin de la
organizacin preste todo el apoyo procurando que haya una comunicacin fluida de lo
que est pasando y porqu se est realizando.

Este paso se bas en obtener la aprobacin de la propuesta, lo que fue posible mediante
la realizacin de reuniones con el personal de SIM C.A., estas reuniones tuvieron como
objetivo dejar en claro qu se va hacer?, cmo?, por qu? y cules eran los
beneficios? Este conjunto de reuniones se mantuvo durante todo el proceso de desarrollo
de la propuesta SPI, debido a que la organizacin debe estar enterada de lo que est
sucediendo, as disminuye la incertidumbre y se mantiene un ambiente armnico.

3.1.5 Definicin de los objetivos generales de la SPI

Los objetivos que la organizacin busca alcanzar mediante la implementacin de un
modelo de calidad son mencionados a continuacin:

Mejorar la satisfaccin del cliente

CMMI-DEV propone que si el proceso de desarrollo de software se encuentra bien
definido sin importar las personas que laboren en la organizacin, entendindose que se
encuentra un grupo preparado, el tiempo en desarrollar el producto disminuir,
permitiendo cumplir con el tiempo pautado para la entrega del producto. Por otra parte,
si los procesos de modelado de requisitos, validacin, verificacin, entre otros, son
mejorados, se obtendr un producto que cumplir con las expectativas de los clientes por
lo que no habr que continuar con un proceso de mantenimiento/reparacin del producto
o en el peor de los escenarios desecharlo perdiendo la inversin.

Reduccin de ciclos

Todos los ciclos realizados mediante el desarrollo de software pueden ser mejorados,
esto puede constituir una disminucin del tiempo invertido para realizar sus tareas. Por

43
otro lado la mejora de todos los ciclos significar una mejora global que ocasionar
mltiples beneficios a la organizacin.

Mejorar el lanzamiento al mercado

Una organizacin debe tener en cuenta que no solo es de vital importancia que el
producto sea lanzado al mercado, que el producto sea lanzado en el tiempo indicado es
igual de relevante, esto puede significar una gran ventaja en comparacin con sus
competidores pues se estar ofreciendo un producto que ellos an no poseen.

Mejorar la gestin de requisitos

La gestin de requisitos es un proceso de vital importancia dentro del desarrollo de
software, es el encargado de la identificacin, asignacin, verificacin, y modificacin
de los requisitos a lo largo del ciclo de vida del software. Una gestin exitosa de
requisitos permite la creacin de un producto de software que cumplir con los
requisitos del cliente. En el desarrollo de software hay que tener en cuenta que un error
cometido durante las ltimas fases del desarrollo constituir una prdida de tiempo y
dinero menor a aquellas que se cometan a comienzos del mismo.

Mejorar la verificacin del producto

La verificacin es un proceso que asegura que el software cumple con su especificacin,
contesta a la pregunta de se est construyendo el producto correctamente?. La
verificacin es un proceso incremental, ocurre a lo largo del desarrollo del producto,
empezando en la verificacin de los requisitos, avanzando a la verificacin de la
evolucin del mismo y finalizando mediante la verificacin del producto una vez est
completo.

44
Mejorar la validacin del producto

La validacin es un proceso de control que asegura que el producto cumple con las
necesidades del usuario, responde a la pregunta se est realizando el producto correcto?
y evala al producto en funcin a las necesidades del cliente.

3.2 Fase de diagnstico

Esta fase se bas en comprender el funcionamiento de los procesos actuales que SIM
C.A. realiza para desarrollar software. El CMMI establece un conjunto de procesos que
una organizacin debe realizar para ser considerada en un nivel dos (2) de madurez, a
continuacin se detallan el conjunto de actividades que permitieron determinar el estado
actual de los procesos de la organizacin, incluyendo las debilidades y fortalezas con
que cuenta la misma. En la Tabla 8 se detallan cada una de las actividades que se
realizaron durante la fase de diagnstico.

Tabla 8. Actividades realizadas en la fase de diagnstico.
Fase Actividades
Diagnstico
Determinar las lneas bases que son necesarias para realizar la
propuesta de SPI.

Determinar la conducta de las lneas.
Presentar los resultados.
Conclusiones finales y recomendaciones.

3.2.1 Determinar las lneas bases que son necesarias para realizar la propuesta
de SPI

El CMMI plantea un conjunto de niveles de madurez donde ubica a las empresas, como
se indic anteriormente una organizacin por el simple hecho de desarrollar software es
considerada por el CMMI en un nivel uno (1), por lo general estas organizaciones se
caracterizan por tener procesos de desarrollo caticos. Cuando una organizacin alcanza
un nivel de madurez dos (2), significa que cuenta con:

45
Una disciplina para la gestin de proyectos.
Polticas organizativas que sern monitorizadas.
Visibilidad en las actividades realizadas.
Un plan de proyecto que especfica qu hacer.

Por lo que llevar a una organizacin de un nivel uno (1) a un nivel dos (2) de madurez,
es uno de los cambios ms difciles que plantea CMMI, debido que pasar a una
organizacin que no cuenta con disciplinas para gestionar sus proyectos entre otros
aspectos, a una que gestiona, mantiene visibilidad y tiene una especificacin clara de los
responsables de los procesos que realizan, este cambio tarda estadsticamente entre 12 y
24 meses, dependiendo del apoyo de la direccin y de la aceptacin de los empleados de
la organizacin (Chrisis y cols., 2009). El nivel dos (2) es la base para los niveles
posteriores, los cuales para ser alcanzados ser necesario realizar slo pequeos
cambios.

En cuanto a las reas de proceso que estable CMMI para alcanzar el nivel dos (2), son
siete (7), las cuales se mencionan a continuacin:

REQM.
PP.
PMC.
MA.
SAM.
CM.
PPQA.

A continuacin se presentan cada una de las reas asociadas al nivel dos (2) de madurez
de CMMI, los objetivos especficos y genricos que permiten que estas reas obtengan
dicho nivel as como las prcticas que se plantean para alcanzar cada objetivo asociado a
un rea.

46
REQM

El rea de REQM se fundamenta en mantener un control sobre los requisitos de la
organizacin. Por consiguiente, los requisitos deben ser bien definidos, siendo
comprensibles para todas las partes relevantes en el desarrollo de un producto
(software).

Por otra parte, REQM busca mantener un control sobre los cambios que se realizan en
los requisitos, manteniendo la trazabilidad, permitiendo conocer de donde viene el
requisito, cuando fue cambiado y la relacin entre requisitos de alto nivel y bajo nivel.
Con esto se pretende que las operaciones realizadas sobre los requisitos no afecten otras
reas de procesos o se ponga en riesgo la integridad del desarrollo.

El propsito de esta rea es gestionar los requisitos y los componentes de los productos
del proyecto e identificar inconsistencias entre esos requerimientos, los planes y
productos de trabajo del proyecto. La Tabla 9 muestra el objetivo conjuntamente con su
prctica especfica del rea de REQM.

Tabla 9. Objetivos y prcticas especficas de REQM.
Objetivos Descripcin Prcticas Descripcin
SG 1
Gestionar los
requerimientos
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 los cambios que se realizan 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.

47
PP

La PP busca mantener un orden durante el desarrollo de un proyecto, esta rea est muy
relacionada con REQM debido a que es en el rea de REQM donde el usuario especifica
el producto que quiere, el grupo de desarrollo determina entonces el alcance del
proyecto. Por lo tanto en la PP se disea un plan de desarrollo que tiene como base los
requisitos obtenidos durante REQM. La Tabla 10 representa los tres (3) objetivos que la
conforman conjuntamente con sus prcticas especficas.

En el plan de desarrollo se realizan estimaciones del proyecto, lo que determina cunto
va a costar, se define el ciclo de vida para establecer que se va hacer, se determinan los
riesgos que puedan afectar el desarrollo del proyecto y se obtiene un compromiso de
todos los involucrados. Es importante acotar que el plan de desarrollo no es algo fijo,
ste debe ser modificado de acuerdo a la fase donde se encuentre el proyecto
adaptndose a la realidad.

El propsito del rea de PP es establecer y mantener planes que definan las actividades
del proyecto.

Tabla 10. Objetivos y prcticas especficas de PP.
SG 1
Establecer
estimaciones
SP 1.1 Estimar el alcance del proyecto.
SP 1.2
Establecer las estimaciones de los
atributos del producto de trabajo y de las
tareas.

SP 1.3
Definir el ciclo de vida del proyecto.
SP 1.4

Determinar las estimaciones de esfuerzo
y de costo.

SG 2
Desarrollar un
plan de proyecto
SP 2.1
Establecer el presupuesto y el calendario.

48
SG 2
Desarrollar un
plan de proyecto
SP 2.2
Identificar los riesgos del proyecto.
SP 2.3
Planificar la gestin de los datos.
SP 2.4
Planificar los recursos del proyecto.
SP 2.5

Planificar el conocimiento y las
habilidades necesarias.

SP 2.6

Planificar la involucracin de las partes
interesadas.

SP 2.7 Establecer el plan de proyecto.
SG 3
Obtener el
compromiso con
el plan
SP 3.1
Revisar los planes que afectan al
proyecto.

SP 3.2
Reconciliar los niveles de trabajo y de
recursos.

SP 3.3 Obtener el compromiso con el plan.

PMC

El PMC es el rea de proceso encargada de controlar el plan de proyecto mediante la
monitorizacin de las horas de trabajo, los informes sobre los avances, entre otros
puntos. Esto permitir que la organizacin pueda anticipar los problemas y tomar
acciones correctivas en el momento adecuado si el desarrollo se desva de lo planeado y
no al final donde ser ms difcil ajustarlo al plan de proyecto.

El propsito del PMC es proporcionar una comprensin del progreso del proyecto para
que se puedan tomar las acciones correctivas apropiadas, cuando el rendimiento del
proyecto se desve significativamente del plan. En la Tabla 11 se visualizan los
correspondientes objetivos y prcticas especficas de esta rea de proceso.

MA

Para mejorar algo, debe ser posible medir ese algo desde un estado inicial y pasar a otro

49
donde mejore. El rea de MA pretende desarrollar una capacidad de medicin con la que
se pueda obtener la informacin requerida. Es aqu donde se indica el procedimiento
para la obtencin, almacenamiento y modificacin de los datos. Estos deben tener
relacin con los objetivos de la organizacin para que la informacin sea til.

Tabla 11. Objetivos y prcticas especficas del PMC.
SG 1
Monitorizar el
proyecto frente
al plan
SP 1.1
Monitorizar los parmetros de
planificacin del proyecto.

SP 1.2 Monitorizar los compromisos.
SP 1.3 Monitorizar los riesgos del proyecto.
SP 1.4 Monitorizar la gestin de datos.
SP 1.5
Monitorizar la involucracin de las partes
interesadas.

SP 1.6
Llevar a cabo revisiones de progreso.
SP 1.7
Llevar a cabo revisiones de hitos.

SG 2
Gestionar las
acciones
correctivas hasta
su cierre
SP 2.1 Analizar problemas.
SP 2.2 Llevar a cabo las acciones correctivas.
SP 2.3 Gestionar las acciones correctivas.

Las 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.).

El propsito del rea de MA es desarrollar y sustentar una capacidad de medicin que se
utiliza para poder dar soporte a las necesidades de informacin de la gerencia. La Tabla
12 muestra, al igual que las anteriores reas de procesos, los objetivos y las prcticas
especficas de rea de MA

50
Tabla 12. Objetivos y prcticas especficas de MA.
SG 1
Alinear las
actividades de
medicin y
anlisis
SP 1.1 Establecer los objetivos de medicin.
SP 1.2 Especificar las medidas.
SP 1.3
Especificar los procedimientos de
recogida y de almacenamiento de datos.

SP 1.4
anlisis.

SG 2
Proporcionar los
resultados de la
medicin
SP 2.1 Recoger los datos de la medicin.
SP 2.2 Analizar los datos de la medicin.
SP 2.3
recogida y de almacenamiento de datos.

SP 2.4 Comunicar los resultados.

SAM

En el rea de SAM se basa en controlar todo lo referente con los proveedores, por lo que
se tiene un control de cules son y qu ofrecen. Estos proveedores sern evaluados y
segn su constancia se elegir la mejor opcin. Es necesario acotar que no todos los
proveedores son externos a la organizacin, puede darse el caso donde un producto para
un proyecto sea el resultado de otro proyecto, por lo que se tratarn los acuerdos igual
que con proveedores.

El propsito de la SAM es gestionar la compra de productos. Los objetivos y prcticas
especficas de esta rea se pueden observar en la Tabla 13.

Tabla 13. Objetivos y prcticas especficas de SAM.
SG 1
Establecer los
acuerdos con
proveedores
SP 1.1 Determinar el tipo de compra.
SP 1.2 Seleccionar los proveedores.

51
SG 1 Establecer los
acuerdos con
proveedores
SP 1.3
Establecer los acuerdos con el
proveedor.

SG 2
Satisfacer los
acuerdos del proyecto
y de los proveedores
SP 2.1 Realizar acuerdos con los proveedores.
SP 2.2
Monitorizar los procesos para
seleccionar proveedores.

SP 2.3
Evaluar los productos de trabajo del
proveedor seleccionado.

SG 2
Satisfacer los
acuerdos del proyecto
y de los proveedores
SP 2.4 Aceptar los productos adquiridos.
SP 2.5 Transferir los productos.

CM

El rea de proceso de CM pretende mantener un control de los elementos que componen
el proyecto, sean entregables o no. Para ello se debe mantener la integridad sobre todos
los elementos del proyecto. Esta es una de las reas de procesos que ms les cuenta
implementar a las organizaciones debido a que se les dificulta mantener un control sobre
las versiones que realizan.

El propsito de la CM es establecer y mantener la integridad de los productos de trabajo
utilizando la identificacin, el control, el registro del estado y las auditoras de la
configuracin. La Tabla 14 muestra los objetivos y prcticas especficas del rea de CM.

Tabla 14. Objetivos y prcticas especficas de CM.
SG 1
Establecer lneas
base
SP 1.1
Identificar los elementos de
configuracin.

SP 1.2
Establecer un sistema de gestin de
configuracin.

SP 1.3 Crear o liberar lneas base.

52
SG 2
Seguir y controlar
los cambios
SP 2.1 Seguir las peticiones de cambio.
SP 2.2
Controlar los elementos de
configuracin.

SG 3
Establecer la
integridad
SP 3.1
Establecer registros de gestin de
configuracin.

SP 3.2 Realizar auditoras de configuracin.

PPQA

En esta rea se asegura que los estndares y procesos establecidos se cumplan, 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. De ser negativa la evaluacin, se notificar a las personas
correspondientes para subsanar el problema.

El propsito del PPQA es proporcionar al personal y a la gerencia una visin objetiva de
los procesos y de los productos de trabajo asociados. Ver Tabla 15.

Tabla 15. Objetivos y prcticas especficas del PPQA.
SG 1
Evaluar
objetivamente los
procesos y los
productos de
trabajo.

SP 1.1 Evaluar objetivamente los procesos.
SP 1.2
Evaluar objetivamente los productos de
trabajo y los servicios.
SG 2
Proporcionar una
visin objetiva.
SP 2.1
Comunicar y asegurar la resolucin de
las no conformidades.

SP 2.2 Establecer registros.

Como se mencion en el captulo 2, CMMI tambin establece un conjunto de objetivos

53
genricos que se encuentran presente en cada una de las reas nombradas anteriormente.
En el caso de la representacin por etapa slo se realiza el objetivo 2 tal como se
muestra en la Tabla 16.

Tabla 16. Objetivos y prcticas genricas del nivel de madurez 2 de CMMI.
GG 2
Institucionalizar un
proceso
administrado
GP 2.1 Establecer una poltica organizacional.
GP 2.2 Planificar el proceso.
GP 2.3 Proveer recursos.
GP 2.4 Asignar las responsabilidades.
GP 2.5 Entrenar a las personas.
GP 2.6 Administrar las configuraciones.
GP 2.7
Identificar e involucrar a los
stakeholders relevantes.

GP 2.8 Monitorear y controlar el proceso.
GP 2.9 Evaluar objetivamente la adherencia.
GP 2.10
Revisar el estado con la administracin
superior.

3.2.2 Determinar la conducta de las lneas bases

Para la realizacin de una propuesta de SPI es primordial conocer el estado de los
procesos que ejecuta la organizacin y en base a esto formular las mejoras que sean
necesarias basadas en el modelo CMMI. Por lo cual, esta actividad se bas en
determinar las fortalezas y debilidades de los procesos de desarrollo de la organizacin
con respecto al modelo CMMI. Para esto fue necesaria la realizacin de un conjunto de
instrumentos de evaluacin que se basaron en evaluar las subprcticas que establece
CMMI para alcanzar un nivel de madurez 2 (dos) en un rea de proceso. Esta evaluacin
se realiz a travs de una lista de verificacin que fue tomada como referencia del
trabajo de maestra realizado por Sanz en el ao 2009.

54
Una lista de verificacin consiste en evaluar las habilidades, capacidades, conductas
entre otros aspectos, mediante un conjunto de preguntas que dejaran en evidencia la
presencia o ausencia de los mismos (Guzmn, 2010).

Estos cuestionarios fueron los encargados de evaluar cada una de las reas de procesos
que plantea CMMI para obtener un nivel de madurez dos (2), por lo que se formularon
un conjunto de preguntas que evaluaron cada una de las prcticas que permiten el
cumplimiento de los objetivos de una determinada rea. Las preguntas que fueron
contestadas con un no, fueron evaluadas con cero (0) mientras que aquellas que
fueron respondidas afirmativamente, es decir con un si, se les otorgo uno (1) . Los
cuestionarios tendrn un apartado donde los encuestados podrn comentar las practicas
que realiza su organizacin.

En la Figura 9 se presenta la estructura en que se basaron las listas de verificacin.

Fecha de la evaluacin:
Nombre del evaluador:
Nombre del evaluado:
Nombre de la evaluacin: SI/NO

Figura 9. Estructura de la lista de verificacin.

55
Una vez definida la forma en que se evaluaron los cuestionarios, fue necesario para
comenzar la evaluacin, reunir a los miembros de SIM C.A. y explicarles cul era el
propsito de aplicar los cuestionarios, esto permiti obtener una evidencia objetiva
(resultados de la aplicacin de las prcticas) lo que permitir a la organizacin tomar
decisiones acerca de la los cambios que se realizarn a futuro. Los cuestionarios
aplicados para determinar el estado inicial de la organizacin se encuentran en el
apndice A.

3.2.3 Presentar los resultados

Para determinar el estado de las reas de proceso de la organizacin objeto de estudio, se
utiliz el modelo CMMI, el cual proporcion un conjunto de subprcticas que a travs
de su evaluacin se pudo determinar el grado de madurez donde se encuentran.

Como se muestra en la Tabla 17, el 23% de las prcticas que especfica CMMI en el rea
de REQM son realizadas por los incubados SIM C.A. mientas que el 77% de ellas no.

Tabla 17. SP correspondientes al rea de REQM.
Respuestas Cantidad
Afirmativamente (si) 3
Negativamente (no) 10
Total de preguntas 13

En la Figura 10 se muestran los porcentajes del nmero de respuestas positivas y
negativas respondidas en las entrevistas aplicadas en la organizacin objeto de estudio.

En el caso de las prcticas correspondientes a PP el 45% de stas son realizadas y el
55% no. Ver Figura 11.

56
Tabla 18. SP correspondientes al rea de PP.
Respuestas Cantidad

Figura 10. Grfica de porcentajes de respuestas del rea de REQM.

Figura 11. Grfica de porcentajes de respuestas del rea de PP.

Los incubados SIM C.A. de la CPTO realizan solo el 32% de las prcticas asociadas al
PMC, el 68% de las dems prcticas no son ejecutadas tal como se representan
conjuntamente en la Tabla 19 y la Figura 12.

Afirmativas Negativas

57
Tabla 19. SP correspondientes al rea de PMC.
Respuestas Cantidad

Figura 12. Grfica de porcentajes de respuestas del rea de PCM.

La organizacin en el rea de proceso de MA muestra slo una realizacin del 3% de las
prcticas por lo que el otro 97% son de las prcticas no realizadas, tal como se visualiza
tanto en la Tabla 20 y la grfica de la Figura 13.

Tabla 20. SP correspondientes al rea de MA.
Respuestas Cantidad

En el rea de gestin de SAM el 28% de las prcticas se ejecutan, por consiguiente el
72% de las prcticas no son ejecutadas. La Tabla 21 y Figura 14 representan dichos
resultados.


58

Figura 13. Grfica de porcentajes de respuestas del rea de MA.

Tabla 21. SP correspondientes al rea de SAM.
Respuestas Cantidad

Figura 14. Grfica de porcentajes de respuestas del rea de SAM.

En la Tabla 22 correspondiente al rea de gestin de CM, se observa que solo 2
respuestas que representan el 7% de las prcticas se ejecutan mientras que el 93% de las
prcticas no son realizadas por los incubados SIM C.A. de la CPTO debido a las 27

59
preguntas contestadas negativamente. Ver Figura 15.

Tabla 22. SP correspondientes al rea de CM.
Respuestas Cantidad

Figura 15. Grfica de porcentajes de respuestas del rea de CM.

En el caso del rea de procesos de PPQA el 100% de las prcticas no son realizadas. Ver
acotaciones y resultados en la Tabla 23 y Figura 16.

Tabla 23. SP correspondientes al rea de PPQA.
Respuestas Cantidad

En cuanto a las prcticas genricas, los incubados SIM C.A. de la CPTO solo realizan el
57% de dichas prcticas mientras que el 43% restante no, representados por la Tabla 24
y Figura 17 respectivamente.


60

Figura 16. Grfica de porcentajes de respuestas del rea de PPQA.

Tabla 24. Prcticas genricas.
Respuestas Cantidad

Figura 17. Grfica de porcentajes de respuestas de las prcticas genricas.

3.2.4 Anlisis de los resultados

En las Figuras 11, 13, 14, 15 y 16 se puede observar que las reas de proceso de REQM,
MA, SAM, CM y PPQA, evaluadas a los incubados SIM C.A. de la CPTO se encuentran

61
deficientes, por consiguiente le fue asignado el nivel de madurez establecido por el
modelo (nivel de madurez uno (1)). Por otra parte, en las reas de procesos como PP y
PMC se ejecutan un nmero significativo de subprcticas, lo que permite determinar que
aunque no se encuentran en un nivel de madurez dos (2), se hayan encaminados hacia el
desarrollo de proyectos y su control. Seguidamente se determin que la organizacin
cumple en su mayora con las prcticas genricas que se encuentran en cada una las
reas de procesos que se evaluaron, tal como lo mostr la Figura 17, resultando en gran
beneficio para la organizacin debido a que estas subprcticas deben ser realizadas en
cada una de las reas de procesos que establece CMMI para alcanzar el nivel de madurez
2.

Es importante acotar que el anlisis de la situacin actual de la organizacin permiti
presentar una matriz FODA a los incubados SIM C.A. donde se presentaron las
fortalezas, oportunidades, debilidades y amenazas que se observaron en la organizacin,
en la Tabla 25, lo que permitir mejorar la situacin de la entidad en el futuro a travs
del desarrollo de una propuesta de SPI.

Tabla 25. Matriz FODA de los incubados SIM C.A. de la CPTO.
Elemento de la matriz Descripcin
Fortalezas
La organizacin realiza tcnicas como estructuras de
desglose de trabajo (ETD) para determinar los work
products que sern generados en sus proyectos y que es
utilizado como base para determinar el costo y tiempo de
sus proyectos.

Se encuentran encaminados hacia la gestin de proyectos.
Cuentan con mecanismos para la revisin de los productos
que desarrollan.

Se realizan estimaciones de tiempo en la realizacin de sus
productos.

Se identifican las necesidades del personal segn el
proyecto a realizar.

62
Fortalezas
El personal se encuentra en un constante aprendizaje.
Recurso humano motivado.
Alianza con la CPTO.

Oportunidades
Mediante la implementacin del modelo CMMI, la
organizacin SIM C.A. mejorara los procesos que realizan,
aumentando la probabilidad de desarrollar software de
calidad.

Mediante la certificacin para los incubados SIM C.A. se
garantizara la calidad de los productos a sus clientes,
mejorando la confianza por parte de los mismos.

Debilidades
No se cuenta con una gestin de requisitos que controle los
mismos desde su obtencin hasta el cierre del proyecto.

No se cuenta con una estructura clara de control de cambios
sobre los elementos que interactan en un proyecto.

El presupuesto y el calendario no se mantienen a lo largo del
proyecto por falta de monitorizacin.

No existen criterios de desviacin significativos que
indiquen a la organizacin qu debe replanificar en sus
proyectos.

No existe una definicin de los roles de las personas que
interactan en un proyecto.

No se realizan mediciones sobre los procesos, work
products o entregables.

No se cuenta con mecanismos que permitan la
monitorizacin de los work products o elementos crticos
del proyecto.

No se realizan prcticas que indiquen que la organizacin
desarrolla productos bajo estndares de calidad.

63
Debilidades
No existe un plan bien definido que gue la adquisicin de
productos externos con proveedores.

No existen criterios, estndares ni procedimientos en la
organizacin para el desarrollo de productos de calidad.

Amenazas
Existe una gran competencia en el mercado de desarrollo de
software debido a que existen empresas de trayectoria que
se encuentran desarrollando software con xito.

3.3 Fase de establecimiento

El desarrollo de esta fase consisti en la elaboracin de una propuesta de SPI que
proporcion una gua para que la organizacin implemente mejoras futuras en sus
procesos y puedan alcanzar el nivel de madurez propuesto. En la Tabla 26 se presentan
las actividades que conforma dicha fase del modelo IDEAL.

Tabla 26. Actividades realizadas en la fase de establecimiento.
Fase Actividades
Establecimiento
Establecer prioridades

Desarrollar la propuesta SPI

3.3.1 Establecer prioridades

En esta actividad se establecen las prioridades para proponer los cambios. Para ello se
consideran: los recursos, las dependencias existentes entre las actividades recomendadas,
los factores internos que puedan intervenir y las prioridades de la organizacin.

El desarrollo de la propuesta de SPI para SIM C.A. se enfoc en las reas de proceso
donde, segn el diagnostico realizado, la organizacin se encuentra deficiente y por lo
tanto impide que sus procesos de desarrollo pueden alcanzar el nivel de madurez
propuesto.

64
3.3.2 Desarrollar la propuesta SPI

La propuesta de SPI se basa en la elevacin de los procesos de desarrollo de software
que realizan los incubados TIC SIM C.A. de la CPTO, teniendo como referencia el
modelo CMMI. A travs de la aplicacin de una serie de cuestionarios (lista de
verificacin) se determin cules eran las prcticas que la organizacin objeto de estudio
no cumplen segn dicho modelo, en tal sentido, se busc dar respuesta a todas aquellas
debilidades evidenciadas durante el diagnstico de las amenazas para que se conviertan
en fortalezas. La propuesta SPI proporciona un camino que la organizacin puede seguir
para la mejora de sus procesos de desarrollo segn sus metas establecidas.

A continuacin se presentan las preguntas que fueron contestadas negativamente en cada
prctica especifica perteneciente a las reas de procesos, realizando de esta forma un
anlisis terico sobre dicha pregunta y anexndole las recomendaciones que debe tomar
la organizacin para alcanzar los objetivos planteados para establecerse en el nivel de
madurez dos (2) del CMMI.

3.3.2.1 Gestin de requisitos

(1) SP 1.1: Mediante la realizacin de un proyecto se determina quienes son los
proveedores de requisitos autorizados (cliente externo, interno, usuario final)?.

Durante el desarrollo de un sistema, la recoleccin de la informacin en algunos casos
resulta un proceso complejo, por ello, este proceso debe realizarse siguiendo un camino
ordenado y bien planificado, asegurando que la informacin obtenida sea til para el
sistema que se desea implementar.

Durante este proceso, se deben tomar en cuenta tres aspectos fundamentales: la fuente de
informacin, el mtodo de bsqueda y la tcnica a implementar. La fuente de
informacin ms importante en un sistema son los usuarios. Durante un proceso de
desarrollo se deben determinar las fuentes de informacin y qu se debe obtener de cada

65
una de ellas, por lo que el analista de requisitos debe identificar quienes son los usuarios
autorizados para proveer requisitos (fuentes de informacin). De esta forma el equipo
desarrollador conjuntamente con los usuarios autorizados podrn llegar a un consenso de
cules son los problemas que presenta la organizacin y cules sern las soluciones
(requisitos) (Barranco, 2001).

Las fuentes de requisitos deben ser documentadas razn por la cual en el anexo A se
muestra un formato que consta de dos partes, la primera parte (Figura A.1) es para la
identificacin de los interesados, donde se determinan a aquellos vinculados con el
desarrollo del proyecto, en esta planilla se identificarn las fuentes de informacin
aprobadas por la organizacin; y en la segunda parte (Figura A.2) se determinan los
diferentes perfiles de los interesados, estos perfiles estn clasificados en instituciones,
departamentos o divisiones dentro de la organizacin del cliente o cualquier
organizacin asociada al desarrollo del proyecto.

(2) SP 1.1: Existen criterios objetivos para establecer la aceptacin de los requisitos
(ej.: claro y adecuadamente definido, completo, consistente con otros requisitos,
identificado unvocamente, implementable adecuadamente, testeable, trazable)?.

Durante el desarrollo de un proyecto de software, los requisitos sern los encargados de
definir las necesidades del producto que se desea desarrollar. Por ello durante la fase de
anlisis de un proyecto de desarrollo de software, se obtiene como resultado un
documento de especificacin de requisitos (ERS). Por lo cual no se trata nicamente de
una actividad de anlisis sino tambin de sntesis. Este documento debe ser legible y no
debe prestarse a ambigedades. (Universitat Jaume I, 2001).

Por otra parte, una lista de especificacin de requisitos debe cumplir con ciertas
caractersticas, segn Chalpeta en el 2000, la descripcin de estos requisitos deben ser:
correcta, no ambigua, completa, verificable, consistente, clasificada, modificable,
explorable y utilizable durante las tareas de mantenimiento y uso (Universitat Jaume I,
2001).

66
CMMI 1.2 para el desarrollo tambin establece un conjunto de criterios para la
aceptacin, todo requisito suministrado por los proveedores autorizados deben cumplir
con estas caractersticas (Chrisis y cols., 2009). Los criterios para la aceptacin de
requisitos son: claramente y correctamente establecidos, completos, consistentes unos
con otros, identificados de forma nica, apropiados para implementar, verificables (que
se pueden probar y trazables).

El establecimiento de criterios de aceptacin de requisitos evitar ambigedades y
verificaciones innecesarias que le resultarn en gran costo a la organizacin.

(3) SP 1.1: Se analizan los requisitos garantizando que los criterios establecidos se
cumplen?.

Todos los requisitos suministrados por los proveedores autorizados debern cumplir con
los criterios establecidos con anterioridad, puesto que de poco servir que la
organizacin establezca requisitos de aceptacin si estos no sern usados. Si los
requisitos suministrados por los proveedores no cumplen con los criterios establecidos,
se debe comunicar a los proveedores para que sean modificados de manera que cumplan
con los criterios. Es posible que la organizacin acepte requisitos que no cumplan con
los criterios establecidos, en este caso la organizacin debe ser capaz de conllevar los
posibles inconvenientes que se ocasionen durante el desarrollo del proyecto (Sanz,
2009).

(6) SP 1.2: Existe un registro del personal encargado de implementar los requisitos
(ej.: firma del plan de proyecto, actas de la reunin de lanzamiento o de las reuniones
internas de requisitos, atributo en la base de datos de requisitos para reflejar el estado
de revisin/compromiso)?.

Los requisitos durante el desarrollo de un sistema evolucionan por lo que se hace
necesario realizar acuerdos y compromisos entre los interesados (clientes) y aquellos que

67
tienen que llevar a cabo las actividades necesarias para implementarlos. Esta prctica
permite a los participantes del proyecto comprometerse con los requisitos actuales que
hayan sido aprobados, con los cambios que puedan surgir y con las actividades que se
realizaran.

Durante esta prctica se tiene como criterio de entrada el documento de ERS y como
criterios de salida el documento de compromisos que se muestra en el anexo B. esta
actividad se puede realizar mediante una reunin donde estarn presentes los interesados
(proveedores de requisitos) y los interesados de la organizacin los cuales negociaron
los requisitos a desarrollar. Es posible que el documento de compromiso de las partes no
sea el nico documento de salida, el documento de especificacin de requisitos puede
ser actualizado durante esta reunin.

(7) SP 1.3: Se registran las peticiones de cambios de los requisitos (fuente, razn de
cambio, en relacin con otros requisitos a los que afecte)?.

Los requisitos de software hacen referencia a las caractersticas del sistema que
condicionan un parmetro de cumplimiento del producto a desarrollar conforme a las
necesidades manifestadas por el interesado en ste. El conjunto de criterios es compilado
en un documento ERS, el cual es tomado por los desarrolladores a fin de corroborar si el
producto elaborado satisface los tems acordados.

Posteriormente este documento pasara a ser la lnea base que los desarrolladores
tomarn como referencia para desarrollar el producto. Una lnea base es un conjunto de
productos de trabajo o especificaciones que se han revisado y acordado formalmente.
Este documento solo podr ser cambiado mediante un proceso de control de cambios
legalmente establecidos. El cambio es inherente durante el desarrollo de software y
genera confusin entre los desarrolladores de un proyecto, para evitarla, los cambios
beben ser analizados antes de realizarlos, se registran antes de implementarlos y se
reporta a quienes deben saberlo (Oviedo, 2010).

68
Segn las organizaciones involucradas en el desarrollo de software los cambios que se
realizan a los requisitos implican, modificaciones en el tiempo y prepuesto establecido
para implementar una caracterstica en particular (requisito) y aun con la posibilidad de
que dicho cambio impacte a otro requisito (Pinzn y Flrez, 2010).

Para el registro del control de cambio de requisitos se muestra una planilla en el anexo
C, la cual permitir llevar un control de los cambios propuestos y aprobados.

(8) SP 1.3: Se ha determinado el o los responsables de aprobar o desaprobar los
cambios en requisitos?.

A fin de disminuir los escenarios de riesgo, asegurar la estabilidad de los requisitos y las
lneas bases, se hace necesaria la creacin de un grupo de control de cambios (GCC) el
cual tendr como misin efectuar el respectivo anlisis y la toma de decisiones en cuanto
a los cambios requeridos en el documento de ERS de un proyecto partiendo de las
solicitudes de cambio previamente solicitadas. Aquellas organizaciones que han
alcanzado diferentes niveles de madurez con respecto a modelos como CMMI, definen
sus procesos, los roles y las interacciones entre estos. En Tabla 27 se muestra los
posibles roles que interactan en un proceso de control de cambio (Pinzn y Flrez,
2010).

Tanto los roles como los encargados de ejecutarlo se deben plasmar en la plantilla de los
perfiles de interesados, la cual se muestra en el anexo A.2.

Tabla 27. Roles que interactan en un proceso de control de cambio.
Rol Descripcin
GCC
Grupos de personas que deciden aprobar o rechazar las
peticiones de cambios para un proyecto especfico.

Promotor del cambio
Persona autorizada que solicita la peticin de cambios de
requisitos.

69
Rol Descripcin
Evaluador
Persona que analiza el impacto de la peticin de cambio
(tcnico, del grupo de mercadeo, el cliente o combinacin
de las anteriores).

Modificador
Persona que realiza el cambio como consecuencia de una
peticin aprobada.

Verificador
Persona que verifica que el cambio fue realizado
correctamente.

Validador
Persona del cliente que valida la implementacin del
cambio realizado.

(9) SP 1.3: Se han establecido criterios para aprobar o desaprobar los cambios
propuestos?.

La peticin de un cambio parte del anlisis de los requisitos frente a diferentes
situaciones que pueden presentarse durante el desarrollo de software. Durante este
proceso es importante determinar cules son las causas que originan la motivacin del
cambio, una vez realizado el anlisis se determina el impacto que producir dicho
cambio, para ello se determina la cantidad de requisitos que afectar y cunto cuesta.

As mismo para establecer un control de cambios de deben definir acciones como:

Definir procedimientos que establezcan los pasos y los anlisis que se realizaran
antes de aceptar los cambios propuestos.
Cambiar los atributos de los requisitos afectados.
Mantener la trazabilidad hacia atrs y hacia delante y entre requisitos.
Versionar el documento de especificaciones de requisitos.

Entre los aspectos que se deben tomar en cuenta para la realizacin de un cambio se
encuentra:

70
Impacto del cambio en el costo y en las funcionalidades del sistema.
Impacto para el cliente e interesados externos.
Desestabilizacin potencial del sistema que pudiera ocasionar un cambio (riesgos
asociados).

Los cambios aprobados deben ser documentados, por lo tanto debe actualizarse el
documento de ERS as como tambin debe quedar un registro de los cambios realizados.

(11) SP 1.3: Existen procesos, procedimientos, plantillas, herramientas para gestin de
requisitos? La utilizan en los proyectos?.

La gestin de requisitos o administracin de requisitos es aquella actividad cuyo
propsito es gestionar los requerimientos de los productos y de los componentes del
producto del proyecto e identificar inconsistencias entre esos requerimientos, los planes
y productos de trabajo del proyecto (Chrisis y cols., 2009).

Para la gestin de requisitos se deben determinar los requerimientos a realizar, para ello
se propone una plantilla para la ERS en el anexo D, durante el anlisis de los requisitos
se determinan las inconsistencias para ello se propone en el anexo E una planilla para
especificar inconsistencias, para mantener los cambios y futuras actualizaciones que se
originen en la ERS se propone la planilla de control de cambios en el anexo C y por
ltimo se tiene una planilla en el anexo B donde cada participante se compromete con
los requisitos a realizar. Estas planillas y plantillas pueden ser modificadas segn la
necesidad de la organizacin.

(12) SP 1.4: Se tiene una trazabilidad (ej.: matriz de trazabilidad) entre los requisitos y
su relacin con objetos, personas, interfaces, procesos, work products y funciones?.

Determinar la trazabilidad en una ERS tiene como objetivo proveer una relacin entre
los requisitos, el diseo, y la implementacin final del sistema (Pinzn y Flrez, 2010).

71
Cuando los requerimientos se gestionan bien, la trazabilidad puede establecerse desde el
requerimiento fuente hasta sus requerimientos de ms bajo nivel y desde los
requerimientos de ms bajo nivel de vuelta hasta su fuente. La trazabilidad bidireccional
ayuda a determinar que todos los requerimientos fuente se han tratado totalmente y que
todos los requerimientos de nivel ms bajo pueden trazarse hacia una fuente vlida

La trazabilidad se necesita particularmente cuando se lleva a cabo la evaluacin del
impacto de los cambios de los requerimientos sobre las actividades y los productos de
trabajo del proyecto (Chrisis y cols., 2009). Para realizar la trazabilidad de un proyecto
existen diferentes mtodos y herramientas que cada organizacin desarrolladora de
software utiliza segn sus necesidades. En este caso particular se propone una matriz de
requerimientos la cual se puede observar en el anexo F, esta matriz especifica el
requisito a implementar, lo que se espera del requisito, sus relaciones con los casos de
uso del sistema y con otros requisitos.

Para establecer la trazabilidad entre los casos de uso, modelos de clases, prototipos del
sistema y todos aquellos elementos que estableci la organizacin para realizar su
trazabilidad se recomienda utilizar herramientas como Enterprise Architect, Rational
RequisitePro, SmarTTrace, los cuales permiten realizar la traza de los elementos
anteriormente nombrados entre sus mltiples funciones.

(13) SP 1.5: Se identifican incoherencias entre los requisitos, los planes de proyecto y
los work products, se documentan y se toman medidas correctivas?.

Mediante esta prctica se debe realizar un anlisis de los requisitos para determinar
posibles incoherencias entre los requisitos, planes del proyecto y los work products.
Cuando se determina una incoherencia, se debe indagar su origen y la razn por la que
se da, posteriormente se identifican los cambios que se deben realizar y en algunos casos
puede eliminarse el requisito causante de la incoherencia (Sanz, 2009). Todos estos

72
cambios deben ser documentados.

En el anexo E se muestra un formato para documentar las inconsistencias y especificar
las acciones correctivas que tomara el equipo de desarrollo.

3.3.2.2 Planificacin de proyectos

(2) SP 1.1: Se identifican los paquetes de trabajo con suficiente detalle como para
precisar estimaciones de las tareas del proyecto, responsabilidades y calendario?.

En preguntas anteriores se determin que la organizacin cuenta con una Work
Breakdown Structure (WBS) o por sus silabas en espaol, estructura de desglose de
trabajo (EDT) que se puede definir como: es una descripcin jerrquica del trabajo que
se debe realizar para completar un proyecto la cual constituye una de las principales
aportaciones a la administracin de proyectos por parte del Project Management
Institute (PMI) que es considerado la principal asociacin profesional para la gestin de
proyectos (Daz, 2010).

Dentro de los principales objetivos que se plantea una organizacin mediante la
construccin de una EDT, se encuentran: detectar hitos y actividades, asignar
responsabilidades, asignar recursos a las actividades, analizar riesgos, realizar
estimaciones de costo, tiempo y recursos ms exactas y pensar en todos los elementos
del proyecto que deben ser incluidos.

Por lo que mediante la realizacin de una EDT bien detalla, con la ayuda de tcnicas de
planificacin como por ejemplo: descomposicin, la organizacin puede lograr
alcanzar los objetivos mencionados. No existe una nica forma de crear una EDT, sin
embargo de forma general segn (PMI, 2004), a continuacin se mencionan los pasos
para la creacin de una EDT:

Paso 1: Identificar el(los) producto(s) final(es) del proyecto, que debe entregarse para

73
alcanzar el xito del proyecto. Se recomienda una revisin completa de alcance del
proyecto para asegurar la consistencia entre las EDT y los requerimientos del proyecto.

Paso 2: Definir los entregables principales del producto; los entregables predecesores
necesarios para el proyecto pero que por s mismos no satisfacen una necesidad
comercial (por ejemplo, una especificacin de diseo).

Paso 3: Descomponer los entregables principales a un nivel de detalle apropiado que
permita gestionar con eficacia y eficiencia.

Paso 4: Revisar y refinar la EDT hasta que los involucrados con el proyecto estn de
acuerdo que el proyecto planificado, pueda completarse satisfactoriamente y que la
ejecucin y el control producirn los resultados deseados.

Para ayudar a la planificacin y determinar actividades que tal vez no se obtuvieron con
la ETD se utiliza el mtodo denominado camino crtico (CPM) el cual permite
determinar interrelaciones entre actividades y una cuantificacin ms detallada de la
duracin de las mismas. Dentro del desglose de las actividades se identifican las
actividades crticas que se pueden definir como aquellas que no se pueden retrasar sin
poner en peligro la conclusin del proyecto por lo que requieren mayor atencin por
parte de la direccin de la organizacin ya que pueden significar el xito o fracaso del
mismo.

Despus de haber determinado a travs del CPM la cantidad de rutas crticas del
proyecto y como resultado las actividades antes mencionadas se obtiene un cronograma
del proyecto que incluya la secuencia de actividades desarrolladas, con fecha de inicio y
fecha de fin.

(4) SP 1.1: Se identifican los work products que sern reutilizados?.

74
Los beneficios de la reutilizacin han sido reconocidos durante muchos aos, sin
embargo no ha sido hasta esta dcada donde ha existido una transicin gradual del
desarrollo original al basado en la reutilizacin. La ingeniera de software basada en la
reutilizacin es una estrategia de la ingeniera comparable en la que el proceso de
desarrollo es adaptado a la reutilizacin del software existente (Daz, 2010).

Las unidades de software que se pueden reutilizar durante el desarrollo de un proyecto
pueden ir desde un sistema de aplicaciones hasta la implementacin de una nica
funcin. Vale acotar que los work products no son solo cdigo, pueden ser manuales,
bases de datos, componentes, entre otros, por lo que el grupo de desarrollo debe tener en
cuenta lo existente y que puedan reutilizar durante un proyecto (Sanz, 2009).

Para que el proceso de reutilizacin en una organizacin sea exitoso se deben tener en
cuenta ciertos aspectos como el tamao del software (pequeo o grande) esto debido a
que en un desarrollo grande se recomienda utilizar una reutilizacin sistemtica que
implica que todo componente reutilizado debe ser ideado, a priori, para ser reutilizado,
mientras que en el desarrollo de un software pequeo la reutilizacin oportunista permite
al desarrollador determinar que piezas se ajustan a su problema (Daz, 2010).

La reutilizacin es un proceso que permite reducir tiempo y costo durante el desarrollo
de software aunque su utilizacin desordenada durante el desarrollo podra traer
inconvenientes y no ventajas.

(10) SP 2.1: Se determinan las actividades sobre las cules existen pocos datos de
estimacin disponibles para identificar el nivel de incertidumbre en el calendario
global?.

Al comienzo de un proyecto el nivel de incertidumbre por lo general es alto, por otra
parte el impacto de la manifestacin del riesgo al principio es bajo, el nivel de
incertidumbre disminuir a medida que avance el proyecto, sin embargo al principio

75
puede que no sea posible la descomposicin de un producto para llegar a su mnima
expresin (paquete), generalmente, el equipo de direccin del proyecto espera hasta que
se aclare el producto entregable o subproyecto, de modo que puedan desarrollarse los
detalles de la EDT. Esta tcnica se denomina planificacin gradual, implica que la EDT
no es esttica, sino que es revisada, ampliada y corregida, por lo que el nivel de
incertidumbre puede irse despejando a nivel que avance el proyecto (PMI, 2004).

(13) SP 2.1: Se establece y mantiene el presupuesto del calendario general a lo largo
del proyecto?.

Durante el desarrollo de un proyecto de ingeniera es de vital importancia desarrollar una
gestin de costos mediante un proceso de planificacin, la gestin de costos consistir en
la estimacin, preparacin y el control de los costes asignados al proyecto que
conforman el presupuesto. Una tcnica fundamental para el seguimiento y control del
presupuesto asignado a un proyecto es la gestin de valor ganado EVM, del ingls
Earned Value Management, la cual permite monitorear como ha sido invertido el
presupuesto y si presenta alguna desviacin (PMI, 2004).

Para establecer un sistema de valor ganado se debe hacer uso de las mejores prcticas de
planificacin que tiene la gerencia de proyectos; por ejemplo mediante la realizacin de
la EDT se obtienen los productos o subsistemas, con ayuda del CPM es posible asignar
tiempo y costos a cada una de los paquetes que conforme un producto, la sumatoria de
todos los paquetes permitir obtener el presupuesto global del proyecto (PMI, 2004).

Valor ganado maneja tres variables importantes para realizar el seguimiento de un
proyecto; entre estas se encuentra el valor planeado es cual no es ms que el costo del
trabajo presupuestado de un proyecto en un periodo de tiempo, esto se traduce en un
proyecto, en el presupuesto. Monitorizando el valor planeado en un periodo de tiempo,
permite determinar que un proyecto se encuentra encaminado y que no presenta
desviaciones significativas (PMI, 2004).

76
(14) SP 2.1: Se ha establecido un criterio de lo que constituye una desviacin
significativa respecto al plan de proyecto (este criterio define cundo deberamos
replanificar el proyecto y por lo tanto renegociar)?.

La EVM es un mtodo que permite medir el desempeo y el alcance del proyecto. Esta
gestin requiere la constitucin de una lnea base integrada con respecto a la cual se
puede medir el desempeo. La EVM monitorea tres valores durante el seguimiento de
un proyecto y puede informar de su comportamiento a la direccin de la organizacin
semanal o mensualmente, estos son:

Valor planeado (VP): Indica el monto presupuestado de todo lo que se tiene planificado
hacer. Su valor es la sumatoria de las cantidades planeadas por los costos estimados en
el presupuesto.

Valor ganado (VG): Representa el monto presupuestado del trabajo efectivamente
realizado. ste proviene de la medicin fsica de lo se ha hecho. Su valor es la suma de
las cantidades instaladas por los costos estimados en el presupuesto.

Valor real (VR): Indica cuanto ha costado hasta ahora el trabajo que se ha hecho hasta la
fecha. Su valor es la sumatoria de todas las cantidades ya instaladas por su costo de
adquisicin.

De la misma forma se monitorean las variables con respecto a las lneas bases
aprobadas, estas son; Variacin del Cronograma (SV) que indica el avance logrado en
un proyecto en comparacin con el avance planificado y Variacin del Costo (CV) que
indica el valor del trabajo completado, en comparacin con el costo o avance real del
proyecto. Estas variables proporcionan indicadores del desempeo con que se maneja el
presupuesto y si se encuentran dentro del cronograma del proyecto (PMI, 2004).

(15) SP 2.2: Se analizan y se describen los riesgos de forma comprensible, de manera

77
que puedan ser analizadas para su posterior correccin segn lo apropiado?.

En primer lugar en el desarrollo de software se entiende como riesgo a un evento o
condicin incierto que, si se produce, tendr un efecto positivo o negativo sobre al
menos un objetivo del proyecto, como tiempo, coste, alcance o calidad, es decir, cuando
el objetivo de tiempo de un proyecto es cumplir con el cronograma acordado; el riesgo
que impactara este objetivo es el retraso en la entrega de los paquetes identificados en la
EDT (Instituto Nacional de Tecnologa de la Comunicacin, 2008).

La gestin de riesgos est compuesta por un conjunto de actividades, las cuales deben
desarrollarse y se nombran a continuacin: desarrollar un plan de gestin de riesgos,
identificar riesgos, analizar riesgos, planificar la respuesta de riesgos, controlar y
monitorizar riesgos y cierre de la gestin de riesgos.

Identificar los riesgos, consiste en determinar qu riesgos pueden afectar al proyecto y
documentar sus caractersticas, en la gestin de riesgos existen diferentes tcnicas para
una identificacin acertada de riesgos. Entre las tcnicas de recopilacin de informacin
se encuentran; tormenta de ideas que es una herramienta de trabajo grupal que facilita el
surgimiento de ideas sobre un tema. La lluvia o tormenta de ideas, habitualmente
conocida como brainstorming tiene como meta obtener una lista completa de los
riesgos del proyecto. Por otra parte existe la tcnica de la bsqueda de consenso entre
especialistas (expertos) sobre eventos futuros, se basa en que expertos en riesgos de
proyectos participan de forma annima, mientras que un facilitador emplea un
cuestionario con definicin clara de objetivos y resultados deseados, para solicitar ideas
acerca de los riesgos importantes del proyecto. De la misma forma se pueden utilizar
buenas prcticas para la identificacin de riesgos, entre las ms cocidas se encuentra la
estructura de desglose de riesgos (EDR) que se define como un agrupamiento de los
riesgos del proyecto orientado a sus fuentes que organiza y define la exposicin total de
riesgo del proyecto y donde cada subnivel representa una descripcin cada vez ms

78
detallada de las fuentes del riesgo (Instituto Nacional de Tecnologa de la
Comunicacin, 2008).

En algunos casos la identificacin de los riesgos poder ser excesiva, imposibilitando al
equipo a realizar una gestin efectiva de riesgo, en este caso la matriz de probabilidad e
impacto permite realizar un anlisis de riesgos y priorizar sus efectos sobre los objetivos
del proyecto, medir la probabilidad e impacto por lo que el grupo de desarrollo podr
enfocarse en los riegos que tengan mayor probabilidad de ocurrencia (Instituto Nacional
de Tecnologa de la Comunicacin, 2008).

Una vez identificados los riesgos estos deben ser documentados de forma comprensible,
para esto se utilizara una matriz para la especificacin de riesgos la cual se muestra en el
anexo G.

(16) SP 2.2: Se revisa y se mantiene actualizada la lista de riesgos (de identificarse
nuevos riesgos estos sern aadidos a la lista)?.

La gestin de riesgos es un proceso iterativo y recurrente a lo largo de toda la vida del
proyecto, tiene como propsito minimizar la probabilidad de consecuencias de los
riesgos negativos y maximizar la probabilidad y ocurrencia de los riesgos positivos.
Cuando los riesgos se gestionan de forma efectiva, se logra cumplir con los objetivos del
proyecto y se evitan problemas que pudieran causar prdidas inesperadas y no
planificadas (PMI, 2004).

Los riesgos identificados deben ser registrados y expuestos de forma clara y concisa de
manera que el equipo de desarrollo puedan entender el riesgos cuando haya pasado el
tiempo, en la descripcin del riesgo se debera incluir el evento relacionado y el impacto
del mismo (Instituto Nacional de Tecnologa de la Comunicacin, 2008).

Durante el registro se debe evitar realizar grandes listados de riesgos introduciendo
riesgos insignificantes, las amenazas y oportunidades que tengan una baja probabilidad

79
de ocurrencia o que tengan un bajo impacto deberan ser tenidas en cuenta en futuras
consideraciones. El registro de los riesgos, segn INTECO en el 2008, debe contener los
siguientes datos, aunque es necesario acotar que durante las primeras etapas del ciclo de
vida puede existir dificultad para completar todos los datos del registro.

Identificador del riesgo: es un identificador nico para cada riesgo.
Estado del riesgo: debe contener algunas de las siguientes etiquetas para
comunicar el estado actual del riesgo.
Identificado: el riesgo ha sido identificado pero no ha sido analizado ni
evaluado.
Evaluado: un riesgo identificado que actualmente no tiene un plan de
respuesta.
Planificado: un riesgo identificado con un plan de respuesta.
En proceso: un riesgo donde la respuesta al riesgo est siendo ejecutada.
Cerrado: un riesgo que ocurri y que ha sido cerrado.
No ocurrido: un riesgo que fue identificado pero que no ocurri. Este estado
es utilizado para diferenciar entre aquellos riesgos que fueron identificados,
evaluados y gestionados hasta su cierre y aquellos que fueron identificados
pero que nunca ocurrieron.
Descripcin del riesgo: la descripcin del riesgo debera incluir el evento, el
momento en que ocurri y el impacto.

Durante el proceso de seguimiento y control de riesgos se deben actualizar los riesgos,
los planes de respuesta, monitorizarlos, identificar los disparadores y nuevos riesgos por
lo cual la lista de riesgos debe ser actualizada durante las diferentes fases del desarrollo
del proyecto (Instituto Nacional de Tecnologa de la Comunicacin, 2008). Ver anexo G.

(17) SP 2.2: Se obtiene un acuerdo en forma de documento con las partes interesadas
sobre la correccin de los riegos documentados?.

80
Durante la gestin de riesgos, las partes interesadas en el proyecto deben tener
conocimiento de los riesgos asociados y deben comprometerse con dichos riesgos para
la continuacin, reformacin o cancelacin del proyecto. Para el compromiso de las
partes se recomienda utilizar una plantilla de compromiso de riesgos donde se deja
asentado el conocimiento y la parte interesada que se hace responsable por la correccin
de riesgo y el impacto si llegara a ocurrir. En el anexo H se muestra una plantilla para el
compromiso con los riesgos.

En el mismo orden de ideas, la organizacin puede llevar un registro de los esfuerzos de
respuesta de riesgos para generar un histrico de las acciones y resultados obtenidos. De
esta manera los jefes de proyecto pueden aprender de experiencias pasadas, como por
ejemplo, podrn conocer qu estrategias y acciones llevadas a cabo funcionaron y cules
no (Instituto Nacional de Tecnologa de la Comunicacin, 2008).

(18) SP 2.3: Se establecen procedimientos para garantizar la privacidad y seguridad
de documentos del proyecto?.

Toda empresa tiene la libertad de calificar como confidencial, cualquier documento o
informacin, que a su juicio, influya directa o indirectamente en el desarrollo de su
negocio: estrategias empresariales, mtodos de negocio, documentos contractuales,
propiedad intelectual, patentes, desarrollo de nuevos productos, entre otros. Por lo que
las organizaciones deben establecer lo que consideran confidencial para evitar difusin,
filtracin o divulgacin a terceros en una empresa de desarrollo de software, por ejemplo
si una estrategia empresarial es divulgada a su competencia, la empresa perdera dinero,
tiempo y la oportunidad de lograr objetivos que se hubiera planteado, una de las
principales causas de xito en el desarrollo de software, no es solo ser liberado, es
importante que salga en el momento idneo y la divulgacin de una estrategia o
propuesta de marketing para liberar un software pude ser fatal para una organizacin.

Para evitar estos inconvenientes que podran ser fatales para las organizaciones, muchas

81
han optado por realizar acuerdos de confidencialidad con sus trabajadores donde se
establece claramente sus obligaciones y pautas a seguir en el tratamiento de la
informacin, los lmites establecidos, pudiendo, con esta medida, reducir algunas
prcticas que se dan en el mundo empresarial (Gonzlez, 2011).

Por otra parte, CMMI-DEV establece que deben ser implementados procedimientos
para garantizar la privacidad y confidencialidad de los datos. Se deben establecer
quienes tendrn autorizacin a los datos y que procedimientos sern establecidos para
identificar quin tiene acceso a qu datos, as como tambin cundo tienen acceso ellos.

(19) SP 2.3: Se establecen mecanismos para almacenar y para acceder a los datos del
proyecto?.

En cualquier desarrollo de proyectos de software, los datos que son recolectados del
funcionamiento del negocio o del problema es de vital importancia ya que los mismos,
una vez agrupados, se transforman en informacin la cual ser posteriormente analizada
para convertirse en conocimiento tanto para el grupo de desarrollo como tambin para la
organizacin. El conocimiento es un bien imprescindible para las empresas y en vista de
estos, para hacer un uso correcto de la misma existe la gestin del conocimiento la cual
es un instrumento bsico para la gestin empresarial que permite identificar, encontrar,
clasificar, proyectar, presentar y usar de un modo ms eficiente el conocimiento y la
experiencia del negocio, acumulada en la organizacin, de forma que mejore el alcance
del empleado para conseguir ventajas competitivas.

Dado que a nivel mundial para que una empresa u organizacin se mantenga dentro del
mercado competitivo, estas deben poseer un buen sistema de gestin de conocimiento
que integre las herramientas tales como: bibliotecas digitales, bases de datos, sistemas de
expertos (las bases del conocimiento estn relacionadas con la inteligencia artificial),
bases documentales, intranets y software. Estas herramientas sirven para digitalizar y
hacer accesible el conocimiento recogido, permiten un tratamiento verstil del

82
conocimiento, que enlazan con los documentos asociados, permiten la difusin y rpido
acceso al conocimiento. El valor del conocimiento aumenta nicamente si es accesible a
la organizacin, sin esta condicin, el conocimiento no podra convertirse en una ventaja
competitiva.

Cada uno de los aspectos mencionados tratan de tener una idea clara de todo el
patrimonio intelectual que se almacena en la organizacin y de ubicarlo de forma que el
acceso sea rpido, lo importante es saber dnde se encuentra, para qu sirve y cmo
utilizarlo. Un ejemplo de estas fuentes de conocimiento son los: manuales de cursos,
conferencias, software, patentes, prcticas y normas, rutinas organizacionales, procesos,
know-how tcnico, diseo de productos y servicios, estrategias de marketing,
comprensin del cliente, experiencia aplicada, relaciones con los consumidores y
contactos empresariales, as como la creatividad personal y la innovacin.

(20) SP 2.3: Se determinan los datos del proyecto a recopilar, identificar y distribuir?.

Durante el desarrollo de un proyecto se genera una gran cantidad de documentacin que
puede llegar a ser til para la organizacin, por lo cual se hace necesario identificar que
datos requerirn ser guardados para su posterior anlisis o para la supervisin de otras
personas. De igual forma se debe identificar la forma en que se guardara esta
informacin, ya sea mediante la utilizacin de repositorios, email o destinando un
archivo fsico en la empresa (Sanz, 2009).

(24) SP 2.6: Se definen los roles y las responsabilidades de las partes interesadas? 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.

Durante el proceso de gestin de riesgos, los expertos en la materia recomiendan crear
roles en especfico, donde se describen las responsabilidades asignadas. A continuacin,

83
en la Tabla 28 se muestran los roles ms relevantes que se deben establecer durante las
actividades que se realizan para llevar a cabo la gestin de riesgos de un proyecto
(Instituto Nacional de Tecnologa de la Comunicacin, 2008).

Tabla 28. Roles relevante para la gestin de riesgos.
Actividad Rol Descripcin
Desarrollo del plan de
gestin de riesgos
Jefe del proyecto
Desarrolla y mantiene el plan de
gestin de riesgos.

Involucrados en el
negocio
Proporciona informacin acerca del
nivel de riesgo que se considera
aceptable.

Aceptador
Proporciona entradas sobre los
criterios de aceptacin de los
entregables que puedan influenciar
sobre el riesgo del proyecto.

Identificacin de
riesgos.
Jefe del proyecto. Identifica los riesgos del proyecto.
Involucrados en el
negocio.
Proporciona informacin de
histricos que sirvan de ayuda para
la identificacin de riesgos del
proyecto.

Expertos en la materia.
Proporciona informacin de
histricos que sirvan de ayuda para
la identificacin de riesgos del
proyecto.

Equipo del proyecto.
Trabajo con el jefe del proyecto
para la identificacin de riesgos.

Anlisis de riesgos.
Jefe del proyecto.
Analiza los riesgos del proyecto.
Involucrados en el
negocio.
Valida las suposiciones realizadas
durante la planificacin de proyecto
y proporciona entradas sobre las
probabilidades e impacto del riesgo.

84
Actividad Rol Descripcin
Anlisis de riesgos.
Expertos en la materia.
Valida las suposiciones realizadas
durante la planificacin de proyecto
y proporciona entradas sobre las
probabilidades e impacto del riesgo.

Planificacin de
respuestas de riesgos.
Jefe del proyecto.
Dirige el proceso de planificacin
de respuestas, identifica a los
participantes y define los planes de
respuestas de riesgos con ayuda del
equipo del proyecto.

Involucrados en el
negocio.
Participan en el desarrollo de los
planes de respuesta de cada riesgo
individual y asumen la
responsabilidad de sus planes.

Control y
monitorizacin de
riesgos.
Jefe del proyecto.
Responsable final de la
monitorizacin y control de riesgos.
Es responsable del mantenimiento
del plan de riesgos.

Involucrado en el
negocio.
Identifican nuevos riesgos y riesgos
que han cambiado; evalan la
efectividad de la gestin de riesgos,
los planes de respuesta y cualquier
accin de respuesta.

Responsable de un
riesgo.
Responsable del plan de respuesta
de un riesgo.

Cierre de la gestin
de riesgos.
Jefe del proyecto.
Registra las lecciones aprendidas
durante la gestin de riesgos y
proporciona los resultados durante
el cierre del proyecto.

(25) SP 2.7: Se ha documentado un plan general de proyecto que integre de forma
lgica todos los aspectos de la gestin de proyectos?.

85
El desarrollo de un plan de gestin de proyectos as como el contenido variar de
acuerdo con la complejidad del mismo. El plan de gestin del proyecto define cmo se
ejecuta, se supervisa, controla y se cierra el proyecto. El proceso de desarrollo del plan
de gestin del proyecto incluye las acciones necesarias para definir, integrar y coordinar
todos los planes subsidiarios en un plan de gestin del proyecto (PMI, 2004).

Entre los planes subsidiarios para la gestin de proyecto se encuentran:

Plan de gestin del alcance del proyecto.
Plan de gestin del cronograma.
Plan de gestin de costes.
Plan de gestin de calidad.
Plan de mejoras del proceso.
Plan de gestin de personal.
Plan de gestin de las comunicaciones.
Plan de gestin de riesgos.
Plan de gestin de las adquisiciones.

Por otro lado en la direccin de proyectos es necesario la integracin de los procesos que
se realizan, los procesos en un plan de gestin de proyectos no deben interactuar de
forma aislada, por ejemplo una estimacin de costes necesaria para un plan para
contingencias implica la integracin de los procesos de planificacin que se describen
con ms detalle en los procesos de gestin de los costes del proyecto, los procesos de
gestin del tiempo del proyecto y los procesos de gestin de los riesgos del proyecto.
Cuando se identifican riesgos adicionales asociados con las distintas alternativas de
personal, se deben revisar uno o ms procesos. Tambin es necesario que los productos
entregables del proyecto se integren con las operaciones de la organizacin ejecutante o
de la organizacin del cliente, o con la planificacin estratgica a largo plazo, que tiene
en cuenta los problemas y las oportunidades futuras (PMI, 2004).

86
Los expertos en la gestin de proyectos estipulan que no existe una nica forma de
gestionar un proyecto ni de integrarlo. Sin embargo PMI proporciona un marco de
trabajo en los que se podra integrar los diferentes procesos en la integracin de un
proyecto.

(27) SP 3.1: Existen evidencias de la coordinacin entre los involucrados en el plan de
proyecto a travs de reuniones y acuerdos?.

Durante el desarrollo de un proyecto, es necesario llevar un control sobre las reuniones
establecidas con involucrados en el proyecto. Para ello se puede hacer uso de una minuta
de reuniones donde se establecen los presentes, la fecha, temas tratados y acuerdos a los
cuales se llegaron (Sanz, 2009). Ver anexo I.

(28) SP 3.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?.

Por medio de la utilizacin de la gestin del valor ganado el lder del proyecto podr
rastrear problemas desde el comienzo del proyecto, permitindole tomar decisiones de
una manera oportuna. El ncleo de la EVM lo constituye la tcnica de anlisis, que es
una interrelacin tridimensional entre lo planeado (VP), el trabajo efectivamente
realizado (VG) y los costos reales incurridos en el proyecto (VR).

Un ejemplo claro de esto es cuando se tiene una planificacin para la entrega de un
sistema de informacin administrativo en un nmero determinado de meses, dada la
naturaleza de la aplicacin sta estar constituida por varios mdulos lo cual generara
perdidas, tanto econmicas como de trabajo, el mal funcionamiento de cualquier
modulo, en este caso al aplicar las tcnicas de la EVM se puede evidenciar a travs de
los valores arrojados para las variables del VP, VG y VR conjuntamente con su anlisis

87
grafico si el proyecto es factible econmicamente a partir del punto de evaluacin o si es
considerado un fracaso debido a que se han sobrepasado los criterios de valores en las
variables de la EVM.

La EVM utiliza los datos suministrados en la EDT, el cronograma y del presupuesto
planeado, para que as se establezcan puntos de control donde se integran el alcance,
tiempo y costo y se compara el presupuesto de lo planeado (PMB) con el VR y la
medicin del VG. Con esta informacin se determinan las variaciones en el costo y el
cronograma (en trminos de costo), se evalan ndices de desempeo y finalmente se
estiman las proyecciones del proyecto que permitirn a los gerentes identificar
desviaciones y realizar actividades para mitigarlas mientras sea posible.

(29) SP 3.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.?.

Durante el desarrollo un proyecto es de vital importancia que los involucrados tengan
conocimiento e interaccin en los procesos de su desarrollo desde el comienzo hasta el
fin, por lo que se han establecido un conjunto de prcticas en el rea de planificacin que
garantizan las interacciones de los involucrados en el proyecto. Para la evidencia de los
acuerdos y compromisos entre las partes se hace referencia a la minuta de compromisos
en el anexo I.

3.3.2.3 Monitorizacin y control de proyectos

(1) SP 1.1: Existen informes del estado del proyecto que recojan los valores actuales
VS planificados respecto al calendario?.

Durante el desarrollo de un proyecto es vital realizar un seguimiento a las actividades e
hitos cada cierto tiempo para determinar que lo planeado se ajusta a la realidad. Este

88
debe hacerse de forma regular y consistente determinando posibles desviaciones del plan
del proyecto. Cuando el plan del proyecto presenten una desviacin significativa de lo
planteado se debe notificar a travs de informes permitiendo a la direccin realizar
acciones correctivas (Len, 2010).

VS planificados respecto a los costes y el esfuerzo?.

Los informes de estado del presupuesto del proyecto son de vital importancia tanto para
el patrocinador como para la direccin del proyecto. Estos permiten conocer de manera
general el estado del proyecto y por tanto como est siendo utilizado el presupuesto.
Para determinar que el costo y el esfuerzo invertido se ajustan a lo planeado, se mide de
forma peridica el esfuerzo, el costo y el personal asignado y se compara con las
estimaciones y el presupuesto documentado inicialmente en el plan de proyecto, de
percibir una desviacin significativa la direccin podr tomar a tiempo acciones
correctivas que no representen prdidas para la organizacin. Estos informes tomarn la
informacin de la aplicacin de tcnicas de control de presupuesto que permitirn
implementar una estrategia que corrija desviaciones en el presupuesto del proyecto
(Len, 2010).

VS planificados de los atributos de los work products y las tareas?.

Los work products y las tareas son fundamentales en el desarrollo de un proyecto,
durante la planeacin indican la magnitud y la aproximacin del tiempo que se invertira
en el proyecto, por tal razn estos deben ser controlados constantemente determinando s
la planeacin inicial se mantiene o existen desviaciones. Los informes permitirn a la
direccin y al resto de los involucrados conocer acerca del avance del proyecto (Sanz,
2009).

89
VS planificados respecto a los recursos utilizados?.

La direccin de una organizacin realiza un estimado de los recursos que necesita al
comienzo de un proyecto, las empresas deben monitorizar los cursos que actualmente
estn usando con los que se planifica en el plan del proyecto, en algunos casos donde el
lder del proyecto necesite ms personas para entregar los productos en el tiempo
establecido la direccin debe tener conocimiento de esta situacin.

Entre los recursos que deben ser monitoreados se encuentran instalaciones fsicas,
ordenadores, perifricos y software usados en el diseo, fabricacin, pruebas y
operacin, redes, entornos de seguridad, personal del proyecto y procesos.

VS planificados respecto a los conocimientos del personal?.

Al principio del desarrollo de un proyecto se especifican los conocimientos que el
personal debe tener o adquirir para que ste sea culminado. En el caso de que el personal
no posea estos conocimientos deben ser adquiridos en un periodo de tiempo determinado
y por mecanismos que haya establecido la organizacin.

Los conocimientos que debe poseer el personal de la organizacin segn lo que se
estableci en cada fase del desarrollo del proyecto sern evaluados, esto con el objetivo
de que no se atrase el mismo, de detectarse alguna desviacin en los conocimientos y
habilidades que debe poseer el personal se tendrn que tomar medidas correctivas para
solucionarlos.

(6) SP 1.1: Se documentan las desviaciones significativas de parmetros analizados?.

Durante el desarrollo de un proyecto de software es necesario controlar las actividades,
hitos, tareas, costo, esfuerzo, recursos, productos de trabajo y el conocimiento que debe

90
poseer el personal. La monitorizacin de estos elementos tiene el objetivo de encontrar
desviaciones que afecten el calendario y el presupuesto. Estas desviaciones sern
documentadas y el documento deber ser actualizado siempre que se hallen nuevas
desviaciones.

(7) SP 1.2: Se identifican y documentan los compromisos no satisfechos (o que corren
riesgo de no ser satisfechos)?.

Los compromisos adquiridos al principio del proyecto deben ser monitorizados,
determinar cules no han sido satisfechos y cuales corren el riesgo de no cumplirse,
estos compromisos sern documentados en un acta de compromiso donde se especifica
cules no han sido satisfechos, cuales corren riesgos y las razones que han originado su
incumpliendo o riesgo para que se tomen medidas correctivas.

(9) SP 1.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)?.

El plan del proyecto debe ser revisado peridicamente en el contexto del estado del
proyecto y segn las circunstancia en la que se encuentre, es decir segn en la etapa de
desarrollo en las que se encuentre el proyecto se monitorearan los riesgos que se
determinaron. A medida que se va obteniendo informacin se actualiza el plan de
riesgos que fue especificado en el plan de proyecto segn la desaparicin, surgimientos
de nuevos riesgos o cambios en estos y posteriormente se da a conocer a las partes
relevantes el estado de cada uno.

(11) SP 1.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?.

91
Los datos sujetos a LOPD, se refieren aquellos que por sus caractersticas estn sujetos a
la Ley Orgnica de Proteccin de Datos de Carcter Personal (LOPD) la cual tiene como
objetivo proteger y garantizar los derechos, la privacidad e intimidad y honor de las
personas fsicas. Por lo tanto la organizacin tiene el deber de establecer procedimientos
que garanticen lo antes mencionado. Se debe determinar quin tiene acceso a los datos,
cmo y cundo. Se monitoriza que los procedimientos establecidos se cumplan.

(12) SP 1.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?.

Al principio de cada proyecto se identifican y documentan las partes interesadas y su
interaccin con ste. Las actividades que estos deban realizar y que fueron
documentadas sern monitorizadas para determinar que se cumple lo establecido al
principio. Estas revisiones se realizan peridicamente y deben ser documentadas
incluyendo los problemas y el impacto que causan las interacciones para que se tomen
medidas correctivas.

(16) SP 2.1: Se documenta el anlisis y las razones por las que el problema requiere o
no accin correctiva?.

Aquellos problemas que se hayan detectado durante el proceso de monitorizacin sern
analizados y solo aquellos que ameriten su intervencin sern tratados. Hay problemas
que para efectos de la planificacin del proyecto no ser necesario realizar acciones
correctivas, sin embargo aquellos problemas que representen un riesgo para el proyecto
sern tratados con el fin de ser mitigados o corregidos. Cualquier sea el caso, deber ser
analizado y expuestas las razones por la cual sern tratados o no, esto ser presentado en
las reuniones con las partes interesadas para la resolucin de problemas y se realizarn
acuerdos para tomar las medidas correctivas. Tanto las razones como el anlisis de los
problemas detectados sern documentados.

92
(17) SP 2.2: Se determinan y registran las acciones correctivas (ej.: renegociar
calendarios, aadir recursos) destinadas a resolver el problema?.

La monitorizacin tiene como objetivo determinar a tiempo los problemas que puedan
afectar la planificacin inicial del proyecto en desarrollo. Una vez detectado el problema
se acuerdan con las partes interesadas las acciones correctivas que se realizarn.

Segn CMMI entre las acciones correctivas que se pueden tomar se encuentran:

Modificar la declaracin de trabajo.
Modificar los requerimientos.
Corregir las estimaciones y los planes.
Renegociar los compromisos.
Aadir recursos.
Cambiar los procesos.
Corregir los riesgos del proyecto.

La organizacin no podr realizar ninguna accin correctiva sin antes llegar a un
acuerdo con las partes interesadas. Las acciones correctivas acordadas a realizar deben
ser documentadas para ser monitorizadas posteriormente.

(18) SP 2.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.)?.

Una vez identificado los problemas que ameritan acciones correctivas, las mismas deben
ser monitorizadas hasta el final para lograr determinar el estado en que se encuentran
(abiertas/cerradas, pendientes, en proceso, etc.) y la eficacia para resolver el problema

93
Esto quiere decir que para la monitorizacin de las acciones correctivas se debe disponer
de un registro que permita consultar como se mencion anteriormente, el estado actual
en que se encuentran las acciones correctivas y finalizada la realizacin de estas se
procede a realizar un anlisis para determinar la eficacia para resolver el problema
detectado al principio y si es necesario la ejecucin de nuevas acciones correctivas. Las
lecciones aprendidas como resultado de tomar una accin correctiva para la resolucin
de un problema pueden ser entradas a los procesos de planificacin y de gestin de
riesgos.

3.3.2.4 Medicin y anlisis

(1) SP 1.1: La direccin establece peridicamente cules son los objetivos estratgicos
de la organizacin? (p. ej.: aumentar rentabilidad, aumentar satisfaccin del cliente,
aumentar calidad del producto, etc.).

Ante todo un objetivo estratgico puede definirse como: los resultados que, a largo
plazo, la empresa espera alcanzar, realizando acciones que le permitan cumplir con su
misin, eso quiere decir, que cuando se hable de un objetivo estratgico, se est
hablando de un resultado que se quiere alcanzar a largo plazo (ms de un ao) inspirados
en la visin para cumplir con la misin (ITNACAP, 2010).

Los objetivos estratgicos pretenden materializar la misin que se ha planteado una
organizacin, no dejndolo como palabras bonitas que se plantearon en un papel. Los
expertos en la materia indican que aquellas empresas que se plantearon objetivos por
cada rea de la organizacin alcanzaron mejores resultados que aquellos que
simplemente a partir de su visin tuvieron buenas intenciones y esperan lo mejor. Por lo
cual aquellas empresas que desean mantenerse en un mercado competitivo y mejorar sus
resultados con respecto a sus competidores deben plantearse objetivos estratgicos
(ITNACAP, 2010).

94
(2) SP 1.1: Se priorizan las necesidades de informacin u objetivos segn su
importancia y siempre ajustndolo a los lmites posibles?.

Durante el desarrollo de software se debe indicar la informacin que se considera
relevante para la culminacin con xito del proyecto (planificacin de tiempos, equipo
de trabajo y asignacin de responsabilidades, hitos de control, entre otros) y se debe
comprobar que esto progresa segn lo acordado en el plan de proyecto, para ello, se
efectuar un seguimiento peridico (a lo largo de toda su vida) y completo sobre las
necesidades de informacin que haya priorizado la empresa, de tal forma que se cubran
todos los factores crticos (eficacia y eficiencia) para su xito y se asegure que las
posibles desviaciones puedan ser detectadas y corregidas a tiempo.

De igual forma la organizacin deber priorizar los objetivos que desea medir y verificar
que se estn realizando los procesos adecuados para conseguirlos.

(3) SP 1.1: Se definen y documentan objetivos operativos de medicin para la unidad
de desarrollo alineados a los objetivos estratgicos de la organizacin? (p. ej: objetivo
estratgico-aumentar satisfaccin del cliente, objetivo operativo para la unidad de
desarrollo-reducir errores en produccin).

Los objetivos de medicin documentan la motivacin existente para llevar a cabo la
medicin y el anlisis, y especifican los tipos de acciones que se pueden tomar
basndose en los resultados del anlisis de los datos.

Segn CMMI entre las fuentes de los objetivos de medicin se pueden encontrar las
necesidades de:

Gestin.
Tcnicas.
Del proyecto.

95
Del producto.
Implementacin.
Del proceso.

Una vez establecido los objetivos que la organizacin desea alcanzar, se determinan
cules son las necesidades de informacin de la misma para medir si los objetivos estn
siendo logrados. Por otro lado, las necesidades de informacin y los objetivos pueden
cambiar como consecuencia del proceso que se realiza o por los resultados de la
medicin y el anlisis.

Segn CMMI las fuentes de las necesidades de informacin y de los objetivos incluyen:

Planes del proyecto.
Monitorizacin del rendimiento del proyecto.
Entrevistas con los gestores y otros que tengan necesidades de informacin.
Objetivos de gestin establecidos.
Planes estratgicos.
Planes de negocio.
Requerimientos formales u obligaciones contractuales.
Problemas recurrentes o de gestin o tcnicos.
Experiencias de otros proyectos o unidades de la organizacin.
Comparativas con empresas del sector.
Planes de mejora del proceso.

(4) SP 1.1: Se dispone una trazabilidad entre las necesidades de informacin y los
objetivos?.

Dentro de una organizacin es importante saber porque se estn realizando las tareas, en
el caso de las mediciones de los objetivos an ms, de esta forma los esfuerzos estarn

96
dirigidos a lo que se desea lograr. Para esta prctica se recomienda realizar una tabla en
donde en un eje se definan las necesidades de informacin y en otro los objetivos. De
esta forma se podr observar que se est midiendo y porqu (Sanz, 2009).

(5) SP 1.1: Se revisan peridicamente los indicadores y se actualizan en caso
necesario?.

Los indicadores establecidos por la organizacin en un periodo de tiempo no son
permanentes, estos deben ser revisados y actualizados peridicamente segn la
necesidad y cambios que haya sufrido la organizacin.

Los indicadores de una organizacin deben dar respuesta a las siguientes preguntas:
qu debemos medir?, dnde es conveniente medir?, cundo hay que medir? en qu
momento o con qu frecuencia?, quin debe medir?, cmo se debe medir?, cmo se
van a difundir los resultados? y quin y con qu frecuencia se va a revisar y/o auditar el
sistema de obtencin de datos?

En el caso del desarrollo de software si la direccin de la organizacin actualmente
desea saber cuntos defectos se generan, por trmino medio, en cada fase del proyecto?
o para un proyecto nuevo, cunto esfuerzo y tiempo se debe planificar para el retrabajo
derivado de la resolucin de defectos?, necesidades de informacin que en un principio
no fueron especificadas o no se consideraron relevantes pero son de gran inters en ese
momento para la direccin, por lo que deben agregarse indicadores que den respuesta a
estas preguntas.

(6) SP 1.2: Existe una definicin operativa clara y sin ambigedades para cada
indicador (p.ej.: descripcin del indicador, frmula, unidades de medicin, etc.)?.

Los indicadores deben tener estructuras operativas precisas y no ambiguas, estos deben
abarcar dos (2) criterios importantes que son; la comunicacin donde se especifica qu

97
se mide?, cmo se mide? y en qu unidades? y la repetitividad que indica si se puede
repetir la medicin utilizando la misma definicin y obtener los mismos resultados?.

Una estructura clara de los indicadores es vital debido a que en la mayora de las
ocasiones las personas que toman las decisiones estratgicas basadas en estos
indicadores no son las mismas que las aplican, por lo tanto si no se tiene claro que se
est midiendo las decisiones que se tomen pueden ser herradas.

(7) SP 1.2: Se identifican medidas candidatas basadas en los objetivos y se clasifican?.

Las medidas que desee implementar una organizacin deben estar enfocadas a medir el
desarrollo y cumplimiento tanto de los objetivos de la organizacin como de los
proyectos de desarrollo que se realizan. Adems estas mediciones deben ser clasificadas
y especificadas por nombre y unidades de medida.

(8) SP 1.2: Se identifican medidas ya existentes que se ocupen ya de los objetivos en el
proyecto o en otros de la organizacin?.

Para evitar el retrabajo se deben identificar entre las medidas utilizadas y aprobadas en
otros proyectos algunas que puedan ser utilizadas nuevamente. Este es un beneficio que
ha trado la reutilizacin, en el caso de encontrar medidas que se puedan reutilizar, estas
se deben revisar y verificar si necesitan alguna modificacin para su utilizacin.

(9) SP 1.3: Se identifican las fuentes existentes de datos que se generan en la labor
actual?.

Una vez que la organizacin haya identificado las necesidades de informacin,
posteriormente se debe identificar las fuentes que facilitaran los datos para las medidas,
entre las fuentes de datos se pueden encontrar: plan de proyecto, presupuesto y
encuestas.

98
(10) SP 1.3: Se identifican las medidas que son necesarias pero que no estn
disponibles an?.

En algunas ocasiones los datos para realizar las medidas especificadas no estarn
disponibles o no se contarn con los recursos necesarios para realizar la medicin, sin
embargo las medidas deben ser identificadas, de este modo se podrn realizar cuando
estn dadas las condiciones.

(11) SP 1.3: Los procedimientos de recogida y almacenamiento de los indicadores son
estndar para todos los proyectos?.

Las organizaciones deben contar con un nico proceso de medicin que les permita
simplificar la recogida de datos y reducir la duplicidad. Estas medidas son documentadas
en un plan de medicin del proyecto. Los analistas del proyecto deben recopilar los
datos de su propio proyecto y la organizacin debe contar con un repositorio donde se
almacenarn estas medidas para su consolidacin y anlisis. Es necesario que la
organizacin establezca un proceso para el almacenamiento de los datos en el
repositorio.

(12) SP 1.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? (p.ej.: de dnde obtener los datos de entrada al indicador, forma
de clculo, posibles procedimientos y herramientas para su obtencin).

Durante el proceso de medicin, para cada indicador se debe especificar una estructura
operativa donde se determina su objetivo, frmula de clculo, origen de los datos, datos
de entrada, criterios de anlisis. Por otro lado segn CMMI establece que se debe
especificar cmo, dnde, cundo se recogern los datos y responsable de obtenerlos.

Entre las preguntas tpicas a considerar en este proceso segn CMMI se incluyen: se ha

99
determinado la frecuencia de recogida y los puntos en el proceso donde se harn las
mediciones?, se ha establecido el cronograma que se requiere para trasladar los
resultados de la medicin desde los puntos de recogida hasta los repositorios, otras bases
de datos o usuarios finales?, quin es el responsable de obtener los datos?, quin es el
responsable del almacenamiento, recuperacin y seguridad de los datos? y se han
desarrollado o adquirido las herramientas de soporte necesarias?

(13) SP 1.3: Existen herramientas que ayuden a la recogida y clculo automtico de
los indicadores?.

Automatizar el proceso de recogida de datos es vital, siempre cuando esto sea posible.
Es importante establecer bien los mecanismos de presentacin de informes tanto a nivel
de proyectos como a nivel de organizacin. Durante el proceso de recoleccin de datos
se puede hacer uso, segn CMMI, de formularios y plantillas manuales o automatizadas.
En el caso de anlisis de los datos se pueden hacer uso los siguientes mtodos:

Anlisis pareto.
Anlisis causa-efecto (Fishbone/Ishikawa Diagram).
Anlisis de tipos de fallos y efectos (FMEA - Failure Mode and Effects
Analysis).
Funcin de calidad de despliegue (QFD - Quality Function Deployment).
Diagrama de flujo de procesos.
Pruebas de correlacin.
Anlisis estadstico de datos.

(14) SP 1.3: Existen procesos, procedimientos, plantillas, herramientas para medicin
y anlisis? la utilizan los proyectos?.

Durante el proceso de medicin y anlisis se debe establecer un proceso claro y preciso
de cmo se realizar la recoleccin y almacenamientos de los datos e igualmente se

100
especifica un procedimiento para el almacenamiento de estos en el repositorio. Por otro
lado se har uso de formularios y plantillas manuales o automatizadas para la
recoleccin de los datos y deben existir registros de cules son las medidas que la
organizacin realizar, quien es el encargado de recoger los datos, cundo, y por qu,
informacin a la cual el personal autorizado por la organizacin pueda acceder para
monitorizar el proceso.

(15) SP 1.3: Se revisan y actualizan los procesos de recogida de datos para una
posible mejora?.

Una vez se haya determinado que datos recoger y dnde durante el proceso de medicin
y anlisis, el siguiente paso es establecer donde se almacenarn los datos y cmo sern
utilizados. Por ltimo, es necesario que los procesos de captura de datos como el
rendimiento de los mismos sean mejorados (INTECO, 2008).

Los procedimientos utilizados para la recogida de datos deben ser revisados por las
personas encargadas de recoger y almacenar los mismos, estas determinarn si son
apropiados y factibles. De igual forma estas personas pueden realizar recomendaciones
de cmo mejorar los procesos existentes segn su perspectiva o realizar sugerencias en
la utilizacin de nuevas medidas o anlisis tiles (Chrisis y cols., 2009).

(16) SP 1.3: Se valora las medidas segn su esfuerzo en obtenerlas o su importancia y
se actualizan?.

Segn las necesidades de informacin de la organizacin en un determinado momento y
los beneficios con respecto al costo que ofrezcan las medidas, la organizacin valorar,
actualizar as como tambin descartar algunas medias que estn realizando.

Segn CMMI-DEV, las prioridades de las medidas realizadas en una organizacin son
reajustadas en base a los siguientes criterios:

101
La importancia de las medidas. Esto implica que tan necesarios son estas
medidas, son vitales?, cules son los beneficios que le ofrecen a la
organizacin?, en base a esto se puede establecer su importancia.
La cantidad de esfuerzo requerido para obtener los datos. Es necesario establecer
si el esfuerzo requerido para la obtencin de los datos es justificado por los
beneficios que otorgan las medidas, descartando as cualquier prdida en cuanto
a tiempo y dinero en mediciones que no ofrecen los beneficios esperados.

Algunas consideraciones incluyen si seran requeridos nuevos formularios, herramientas
o formacin para obtener los datos.

(17) SP 1.4: Se especifica el procedimiento de anlisis y los informes que se
prepararn?.

Durante el proceso de medicin y anlisis es vital determinar la forma en que se
analizarn y presentarn los resultados. El procedimiento a utilizar para el anlisis de los
datos obtenidos debe ser especificado en etapas tempranas para asegurar un correcto
anlisis de los objetivos de medicin documentos. Por otra parte, tanto el anlisis como
la presentacin deben cumplir con los siguientes criterios segn lo establecido en
CMMI:

La presentacin de los resultados es claramente entendible por las audiencias a
las que se dirigen los resultados.
Los anlisis tratan de manera explcita los objetivos de medicin documentados.

En cuanto a la presentacin de los resultados se debe especificar quienes sern los
encargados de comunicarlos, en que forma sern presentados (por ejemplo informes de
progreso, memos, informes escritos, reuniones de la plantilla, diagramas de torta, de
barras, histogramas, diagramas de radar, grficos de lneas, ejes cartesianos o tablas)

102
asegurando la precisin y el entendimiento por parte de aquellos que deban hacer uso de
la informacin.

(18) SP 1.4: Se analizan los datos de acuerdo al procedimiento de anlisis definido
(responsable de anlisis, forma de anlisis, frecuencia)?.

El procedimiento de anlisis establecido en la organizacin tiene que ser cumplido, sino
que caso tendra establecerlo, este procedimiento incluye los siguientes aspectos segn
lo establecido en CMMI:

Identificacin de las personas y de los grupos responsables de analizar los datos y
de presentar los resultados, solo las personas autorizadas por la organizacin
sern los encargados de analizar e informar los resultados obtenidos evitando
cualquier confusin que pueda existir a causa de un proceso desorganizado.
Determinacin de la lnea de tiempo para analizar los datos y presentar los
resultados, se estableci con anterioridad un plan donde se especifica cada cuanto
tiempo son analizados y presentados los resultados.

(19) SP 1.4: Para cada indicador, se ha especificado quin y a quines se han de
comunicar los resultados de la medida?.

Como se mencion anteriormente se ha establecido un procedimiento para la
comunicacin de los datos, en este procedimiento se define quien o quienes son los
encargados de presentar los resultados y como sern presentados (Chrisis y cols., 2009).
En la presentacin de los resultados se debe tomar en cuenta la poblacin a quien va
dirigida para hacer un uso eficiente de la forma que sern presentados para asegurar un
mejor entendimiento.

(20) SP 1.4: Se revisan los contenidos y formatos de los anlisis e informes para una
posible actualizacin?.

103
En el proceso de medicin y anlisis las necesidades de informacin guan el anlisis de
los datos, en el caso de la actualizacin de los criterios se debe tener sumo cuidado ya
que estos pueden afectar las mediciones que se realicen. Las actualizaciones que se
deban realizar sobre algunas medidas pueden refinarse a posteriori sobre la base de las
especificaciones establecidas para los procedimientos de anlisis de datos. En otros
casos puede que se determinen que algunas medidas ya no son necesarias y por otra lado
surjan nuevas y que si son de relevancia para la organizacin o un jefe de departamento.

El ejercicio de especificar cmo sern analizadas e informadas las medidas puede
sugerir tambin la necesidad de refinar los objetivos de la medicin en s mismos por lo
cual la actualizacin del anlisis e informes es vital para que este proceso tenga xito.

(21) SP 1.4: Se especifican los criterios para evaluar la utilidad de los anlisis?.

Los anlisis realizados en la organizacin deben ser evaluados con el fin de determinar
si son tiles y generan beneficios econmicos a la organizacin. CMMI establece un
conjunto de criterios que permiten evaluar el anlisis que se realiza los cuales son
mencionados a continuacin:

Los resultados deben ser proporcionados a tiempo. Esto indica que no tiene
sentido presentar resultados de situaciones que han cambiado y de implementar
alguna solucin estara fuera de lugar.
Los resultados deben ser comprensibles y utilizados para la toma de decisiones.
La presentacin de los resultados debe estar acorde a la poblacin que va a
recibir la informacin para que se pueda hacer uso de la misma en la toma de
decisiones, de lo contrario todo el trabajo realizado seria en vano.
El trabajo a realizar no cuesta ms que lo que pueda ser justificado por los
beneficios que produce. Se debe determinar si las mediciones realizadas estn
generando beneficios a la organizacin envs de prdidas.

104
(22) SP 2.1: Se realizan controles de integridad de los datos lo ms cercano posible a
la fuente?.

Es importante realizar controles de integridad sobre las mediciones, ya que estas estn
sujetas a errores en su especificacin o registro y es conveniente que estos errores sean
solucionados en las fuentes lo antes posible en el ciclo de medicin y anlisis. Las
comprobaciones pueden incluir exploraciones para datos perdidos, valores de datos fuera
de lmites y patrones y correlaciones entre medidas inusuales.

En estos casos CMMI recomienda tomar en cuenta los siguientes aspectos:

Probar y corregir inconsistencias de clasificaciones hechas por el juicio humano,
es decir, determinar con qu frecuencia la gente toma decisiones de clasificacin
distintas en base a la misma informacin, de otra manera conocido como
fiabilidad entre codificadores.
Examinar empricamente las relaciones entre las medidas que se utilizan para
calcular medidas derivadas adicionales. Hacindolo as, se puede asegurar que no
se pasan por alto distinciones importantes y que las medidas derivadas transmiten
sus significados deseados, de otro modo conocido como validez de criterio.

(23) SP 2.2: Se interpretan los resultados de los datos y se sacan conclusiones?.

Los resultados de los datos en pocas ocasiones son evidentes, por lo que es necesario
realizar conclusiones sobre los resultados obtenidos. Para ello la organizacin debe
establecer de manera explcita los criterios que sern utilizados para interpretar los
resultados y obtener las conclusiones evitando de esa forma que los mismos datos
puedan generar resultados diferentes (Chrisis y cols., 2009).

(24) SP 2.2: Se realizan mediciones adicionales si son necesarias para la presentacin
de los resultados?.

105
En algunas ocasiones ser necesario realizar mediciones adicionales, estas se realizan
cuando los anlisis planificados requieran o exijan nuevas mediciones para una mejor
comprensin de los resultados. En otros casos, es posible que se identifiquen nuevas
necesidades que permitan refinar las medidas ya existen, derivadas o medidas bases
adicionales. Una simple presentacin de los resultados puede sugerir realizar nuevos
anlisis que permitan dar cumplimiento a lo planificado (Chrisis y cols., 2009). En
cualquiera de los casos se debe realizar un estudio de los beneficios sobre el costo que
conllevar realizar medidas adicionales.

(25) SP 2.2: Antes de una presentacin ms amplia, se examinan los datos junto con
las personas interesadas de las mediciones?.

Es recomendable realizar reuniones con los usuarios finales, patrocinadores previstos,
analistas y suministradores de datos con el fin de revisar las interpretaciones iniciales y
la manera como sern presentados los datos antes de realizar una publicacin y
comunicacin ms amplia de los resultados de los anlisis obtenidos. Esto contribuir a
evitar malas interpretaciones y puede ayudar a refinar el anlisis de la presentacin de
los datos (Chrisis y cols., 2009).

(26) SP 2.2: Se perfeccionan los criterios para la validez de las necesidades de
informacin y de los objetivos?.

La realizacin del anlisis y presentacin de resultados dotarn al personal que los
realiza de conocimientos que les permitirn llegar a conclusiones valiosas que podrn
mejorar los esfuerzos futuros que se proponga la organizacin. Anlogamente para
mejorar las especificaciones de medicin y procedimientos de recogida de datos pueden
llegar a ser evidentes, como lo pueden ser ideas para refinar las necesidades de
informacin y los objetivos identificados, aunque segn la experiencia del personal
puede llegar a hacer un proceso sencillo o engorroso (Chrisis y cols., 2009).

106
(27) SP 2.2: En caso de identificar desviaciones significativas durante la medicin y
anlisis se emprenden acciones para solucionar la causa de la desviacin?.

Si durante el proceso de medicin y anlisis se identifican desviaciones significativas,
estas deben ser comunicadas a travs de informes al personal encargado de la
monitorizacin y control los cuales sern los encargados de tomar acciones correctivas
que permitan solucionar el problema. Para ello los resultados de las mediciones deben
ser comunicados a tiempo y de forma efectiva para su pronta solucin, en el rea de
monitorizacin y control de procesos se especifican cmo son tratadas y comunicadas
las desviaciones encontradas durante el proceso de medicin y anlisis.

(28) SP 2.3: Se examinan los datos histricos para asegurar su integridad, exactitud y
extensin?.

La definicin de un proceso ptimo para el almacenamiento y acceso de las mtricas en
un repositorio es esencial, por lo tanto es necesario implementar una prctica en SIM
C.A. que permita revisar los datos para asegurar que estn siendo almacenados
completos, ntegros, precisos y actuales. Esto asegurar que los datos y resultados
histricos estarn disponibles y accesibles para uso futuro de forma fiable, lo que le
permitir a la organizacin hacer referencia a la informacin que necesita para
comprender, interpretar las medidas, evaluarlas para su aplicabilidad y determinar
posibles acontecimientos repetitivos con respecto a otros proyectos. Tambin es
necesaria la informacin para proporcionar un contexto adecuado para la interpretacin
de los datos, los criterios de medicin y los resultados del anlisis. Segn (Chrisis y
cols., 2009) la informacin almacenada debe incluir normalmente:

Planes de medicin.
Especificaciones de medidas.
Conjuntos de datos que han sido recogidos.
Informes de anlisis y presentaciones.

107
(30) SP 2.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?.

Los resultados del proceso de medicin y anlisis deben ser comunicados a las partes
interesadas relevantes (usuarios previstos, patrocinadores, analistas de datos y a los
proveedores de datos) y sern comunicados de forma que puedan ser utilizados
oportunamente para soportar la toma de decisiones y ayudar a determinar las correctivas
a realizar. Es de vital importancia que estos resultados sean distribuidos a tiempo a
aquellas personas que necesitan conocer los resultados de las mediciones. Los usuarios
que harn uso de los resultados de las mediciones deben mantenerse comunicados sobre
cmo se encuentra el proceso y los resultados intermedios que les permitan tomar
acciones correctivas a tiempo.

(31) SP 2.5: Se ayuda a las partes interesadas de las mediciones y anlisis a su
comprensin?

Para ayudar a la comprensin de los resultados de anlisis, estos deben ser informados
de forma clara y concisa y siempre teniendo en cuenta los conocimientos que poseen las
partes interesadas relevantes. De igual forma deben estar expresados de manera
comprensible, de fcil interpretacin y claramente ligados a las necesidades y objetivos
de informacin identificados. Segn CMMI las elecciones de medicin deberan ser
explcitamente claras en:

Cmo y por qu las medidas base y derivadas fueron especificadas.
Cmo fueron obtenidos los datos.
Cmo interpretar los resultados en base a los mtodos de anlisis de datos que
fueron usados.
Cmo los resultados cubren las necesidades de informacin.

108
3.3.2.5 Gestin de acuerdos con proveedores

(1) SP 1.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? (p.e: Hardware (
HW), software (SW), producto comercial o comercial off the shelf (COTS), diseos
grficos, mdulos, entre otros).

Cuando se desea adquirir un producto externo es conveniente disponer de un listado
donde se evalu cual es la opcin que mejor se adapta a las necesidades del proyecto, de
la misma forma se debe tener en cuenta los aspectos de propiedad intelectual y la
disponibilidad del producto a la hora de elegir.

(2) SP 1.2: Existe una lista de proveedores homologados de los que realizar
adquisiciones?.

Algunas organizaciones optan por un nico proveedor, sea el caso un proveedor o una
lista se debe documentar los argumentos y motivaciones para la eleccin de los
proveedores potenciales, especialmente en el caso de un nico proveedor. Sin embargo
con el propsito de crear un entorno competitivo las organizaciones elaboran un listado
de proveedores ya que esto mejorar las opciones de que el solicitante logre los
objetivos fijados para la adquisicin.

Para la elaboracin del listado de proveedores la organizacin debe identificar
proveedores de una variedad de fuentes: Internet, no slo en pginas de empresas,
tambin a travs de directorios; empleados o compaeros del sector, bases de datos de la
propia empresa adquiridora, asociaciones del sector, organizaciones empresariales,
consultoras, entre otras. Las empresas suelen disponer de un listado de proveedores
calificados con informacin de contacto, histricos de experiencias pasadas y otra
informacin til.

109
(3) SP 1.2: Existen criterios que determinen qu proveedores seleccionar?.

Las organizaciones deben establecer criterios que les permitan evaluar a los proveedores
de tal forma que puedan determinar cuales se ajustan mejor a sus objetivos. Entre los
criterios para evaluar a los proveedores se encuentran, segn la INTECO en su gua para
la gestin con proveedores, lo siguiente:

Obligatorios: Constituyen el primer filtro que los proveedores deben superar de
no ser as deben ser rechazados, entre los criterios obligatorios se encuentran
acreditaciones de calidad, existencia de localizaciones geogrficas especficas,
viabilidad financiera, respuesta completa, entre otros.
Cualitativos: Las respuestas que pasan los criterios obligatorios pasan a ser
evaluadas frente a los criterios cualitativos. Estos criterios recogen un conjunto
de atributos de la adquisicin no relativos al precio, que representan la parte de
valor de la ecuacin de valor/coste.
Coste: Representan la parte de coste de la ecuacin valor/coste y pueden tener un
peso importante dentro del conjunto de criterios a considerar.

Existen otros criterios que la organizacin puede utilizar como el rendimiento en el
pasado con ese proveedor.

(4) SP 1.2: Se evala el riesgo de seleccionar uno u otro proveedor? se incluye ese
riesgo en la seccin de riesgos del plan de proyecto?.

Los riesgos asociados a la eleccin de un proveedor se identifican y describen de forma
concisa en la seccin de riesgos de plan de proyecto para que se puedan gestionar
apropiadamente de ser necesario. Hay que tener en cuenta qu pasara si el producto
solicitado no es entregado a tiempo o existen fallas en el mismo, la organizacin debe
estar preparada para este tipo de riesgos y debe ser capaz de gestionarlos sin poner en
peligro el proyecto.

110
(6) SP 1.3: Se especifica en el contrato un plan de seguimiento sobre el proveedor?
(p.ej.: informes de progreso, reuniones de seguimiento, etc).

A la hora de contratar a un proveedor se debe realizar a travs de acuerdos formales. Un
acuerdo formal es cualquier acuerdo legal entre la organizacin (representando al
proyecto) y el proveedor. Este acuerdo puede ser un contrato, una licencia, un acuerdo
de nivel de servicio o un memorndum de acuerdo. En ste se debe especificar las
revisiones, la monitorizacin, las evaluaciones y las pruebas de aceptacin a realizar. A
travs del contrato se puede realizar presin sobre el proveedor para que cumpla lo
establecido de lo contrario entrara en acciones legales.

A continuacin se nombran los trminos con mayor frecuencia negociados para el
establecimiento de acuerdo entre adquiridores y proveedores. Estos datos proceden de
una encuesta llevada a cabo por la Asociacin Internacional para la Gestin de Contratos
y Comercial o International Association for Contract and Commercial Management
(IACCM) en el ao 2005:

Lmites de responsabilidad.
Indemnizaciones.
Propiedad intelectual.
Pagos.
Garantas.
Precio y ajustes de precio.
Terminacin.
Confidencialidad y proteccin de datos.
Entrega y aceptacin.

(7) SP 1.3: Se identifica quienes sern los responsables de posibles cambios en el
contrato y como sern comunicados?.

111
El acuerdo realizado con el proveedor debe incluir una declaracin de las actividades,
especificaciones con que debe cumplir el producto, los trminos y condiciones, una lista
de entregables, calendario, presupuesto y un proceso de aceptacin definido. Adems se
debe identificar por parte del proveedor y por la organizacin quienes pueden realizar
cambios en el contrato, esto evitar confusiones en cuanto al estado de ste ya que solo
las personas con autoridad pueden solicitar y notificar posibles cambios.

(9) SP 1.3: Se revisa nuestro plan de proyecto para alinearlo con el del proveedor?.

El plan de proyecto debe ser alineado con las actividades que realiza el proveedor, esto
se debe a que existe un calendario donde se establecieron fechas para la realizacin de
las pruebas y entregas con el cliente, los productos que suministra un proveedor en
algunos casos tendrn que ser integradas con productos realizados en el proyecto, por lo
tanto se deben controlar y en algunos casos sin los producto del proveedor no se podr
entregar el producto final al cliente, entonces se puede determinar que el acuerdo con el
proveedor y el plan de proyecto no son dos elementos aislados, al contrario las
actividades deben estar alineadas, sobre todo si una es predecesora de la otra.

(10) SP 1.3: Se da seguimiento formal al progreso del proveedor para ver si se ajusta a
lo planificado?.

Cuando se realizan acuerdos con proveedores la organizacin debe realizar un
seguimiento de las actividades previas al producto a adquirir, se debe comunicar con
regularidad el estado de las actividades establecidas previamente a la adquisicin del
producto y documentar posibles desviaciones en cuanto a las fechas o actividades
establecidas. Esto es aplicable siempre y cuando estas actividades de seguimiento se
ajusten al producto que va adquirir, sin embargo independientemente del producto, se
debe revisar peridicamente el acuerdo con el proveedor para asegurarse de que refleja
con precisin lo establecido en el proyecto.

112
(11) SP 1.3: Se reflejan los posibles cambios en el proceso o en los productos del
proveedor?.

Habiendo establecido quienes son las personas autorizadas para realizar y proponer
cambios, el prximo paso es que a travs del proceso de seguimiento por parte de la
organizacin al detectarse posibles desviaciones en lo planificado se tomen medidas que
permitan reajustar los acuerdos realizados entre ambas partes a principio del proceso.

(12) SP 2.1: Se realizan revisiones tcnicas de seguimiento?.

Las revisiones tcnicas de seguimiento se deben realizar con el fin de transmitir al
proveedor las necesidades y deseos de los clientes. Adems se debe verificar que los
procedimientos tcnicos se estn realizando y son acordes con las necesidades
planteadas, otro de los propsitos de estas revisiones es verificar como se estn
comunicando los problemas que se puedan presentar con los requisitos solicitados y cul
es la va de comunicacin para la resolucin de los inconvenientes presentados.

(13) SP 2.1: Se da seguimiento y analizan los procesos del proveedor para ver si se
ajustan a los requisitos del acuerdo establecido?.

Los procesos realizados por los proveedores deben ser revisados a travs de un
seguimiento, debido a que los procesos que estos utilizan para la elaboracin de los
productos que ofrecen son proporcionales a la calidad de los mismos, por tanto, si estos
procesos no se llevan a cabo correctamente segn lo establecido en el acuerdo con el
proveedor podran llevar a la cancelacin de la adquisicin del producto.

(14) SP 2.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?.

113
Mediante el desarrollo de proyectos grandes donde es necesario la subcontratacin, se
puede dar el caso de una alineacin estrecha entre los procesos que realiza el proveedor
y los del proyecto, en estos casos se debe realizar una monitorizacin con el propsito de
evitar inconvenientes en el avance del proyecto.

La monitorizacin se debe realizar con sumo cuidado, evitando ser invasiva y gravosa, o
en el otro extremo no ser informativa ni eficaz. La monitorizacin se realiza para
detectar los problemas, tan pronto como sea posible, que puedan afectar a la capacidad
del proveedor para satisfacer los requerimientos del acuerdo. El anlisis de los procesos
seleccionados involucra la toma de datos obtenidos de la monitorizacin de los procesos
y su anlisis para determinar si hay problemas graves que puedan afectar el proyecto.

(15) SP 2.2: Se toman acciones correctivas ante los desvos en los procesos?.

En el acuerdo con el proveedor se especific cules eran los procesos que se realizan
para la elaboracin de los productos que estos ofrecen, si durante la monitorizacin de la
elaboracin del producto se determina que no cumplen los procesos, o no se encuentran
en las fases establecidas en el acuerdo para la fecha, se realizar un llamado de atencin
al proveedor para que realicen las acciones correctivas, de no ser as esto podra traer
sanciones legales estipuladas en el contrato, esto permite a la organizacin establecer
presin sobre el proveedor para que cumpla con el acuerdo establecido.

(16) SP 2.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?.

Los productos crticos producidos por el proveedor deben ser evaluados para determinar
problemas lo antes posible. Estos productos proporcionan informacin de la calidad del
mismo adems de la verificacin de que estos cumplen con los requisitos solicitados.

114
Entre los productos crticos segn CMMI que deben ser evaluados se encuentran:
requerimientos, anlisis, arquitectura y la documentacin.

(19) SP 2.4: Se han establecido criterios, tests y procedimientos para la aceptacin del
producto?.

En el acuerdo realizado con el proveedor se estableci un protocolo para la aceptacin
del producto, la organizacin debe realizar revisiones, pruebas de aceptacin y auditoras
de configuracin antes de aceptar el producto segn se estableci en dicho acuerdo.

Si el producto entregado por el proveedor no aprueba el protocolo de aceptacin se debe
evaluar y tomar la decisin que mejor convenga a la organizacin, es decir, se debe
decidir si aceptar el producto, solicitar el cambio o rechazarlo, en el caso que el requisito
faltante sea vital se debe pedir el cambio, evaluando que no asuma un gran costo
temporal el proyecto. Si el requisito faltante es de suma importancia y el costo que debe
asumir el proyecto es alto, por lo que no se puede realizar, se debe rechazar el producto
debido a que ocasionara problemas futuros en el producto final.

(21) SP 2.4: Se documentan los resultados de los test de aceptacin?.

Antes de aceptar el producto, se realizan revisiones, pruebas de aceptacin y auditoras
de configuracin segn lo establecido con el proveedor. Los test de aceptacin permiten
verificar que la versin nueva de un producto sigue comportndose igual que la anterior
pero con las mejoras solicitadas dado el caso, estos resultados deben ser documentados
para determinar si el producto sigue cumpliendo con los requisitos o bien si se puede
utilizar para proyectos similares.

(22) SP 2.4: Se ha establecido un plan de accin con el proveedor para cualquier work
product que no pasa las pruebas de aceptacin?.

115
Se ha determinado desde el inicio cuales son las caractersticas del producto, cmo debe
ser entregado y cmo sern las pruebas de aceptacin que se realizarn, sin embargo,
establecer y obtener el acuerdo con el proveedor sobre un plan de accin para cualquier
producto de trabajo adquirido que no pase su revisin o prueba de aceptacin tambin es
vital (Chrisis y cols., 2009). Rechazar drsticamente el producto que el proveedor nos
ofrece podra retrasar el calendario del proyecto poniendo en peligro todo el proyecto, se
debe acordar un plan que permita que el proveedor pueda realizar las mejoras que le
sean solicitadas, para ello se debe tener cuidado que las fechas de entrega del producto
suministrado por el proveedor, la integracin con los dems componentes y entre las
pruebas existe cierta holgura que permite realizar planes de contingencia para que el
producto sea entregado en la fecha acordada con el cliente.

(25) Existen procesos, procedimientos, plantillas, herramientas para la gestin de
acuerdos con proveedores? la utilizan los proyectos?.

Para el rea de gestin de acuerdo con proveedores debe existir un contrato que detalle
las caractersticas del producto que se va adquirir, una constancia de quienes son las
personas encargadas de interactuar por parte de la organizacin y por el proveedor y
cules son sus funciones, la documentacin de las pruebas que le sern realizadas a los
productos que suministra el proveedor y por ltimo el plan de accin que se realizar si
un producto no cumple con las especificaciones acordadas.

3.3.2.6 Gestin de configuracin

(1) SP 1.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 las descripciones de proceso, requisitos, manuales, interfaces,
cdigo fuente, etc.

El rea de control de configuracin se basa en administrar y evaluar mediante un

116
proceso controlado los productos que se generan durante todo el ciclo de vida y el cual
tiene como objetivo la generacin de productos de calidad. Para que esto sea posible se
deben realizar cierto conjunto de actividades, entre las primeras actividades que
encuentra la identificacin (Prez, 2009).

La identificacin se basa en determinar de forma inequvoca de la estructura del
software y los elementos que estarn designados como una entidad para la gestin de
configuracin, esto permitir posteriormente controlar la versin en que se est
trabajando, cuales estn optimas, cumplen con los estndares para integrar al producto
final, que cambios se han realizado y conocer exactamente que le fue entregado al
cliente. Nada de lo mencionado anteriormente ser posible si primero no se identifican
los elementos que formaran parte de la lnea base de los elementos de la configuracin
(Prez, 2009).

Segn INTECO en el 2008, algunos criterios que se pueden tener para determinar los
elementos para la gestin de configuracin pueden ser:

Productos de trabajo que vayan a ser utilizados por dos o ms grupos.
Productos de trabajo que puedan cambiar con el tiempo debido a cambios en
requisitos o errores.
Productos que dependan de otros en el sentido de que un cambio en uno de ellos
implique un cambio en los otros.
Productos de trabajo que sean crticos para el proyecto.

(2) SP 1.1: Para la identificacin de las entidades para la gestin de configuracin se
han tenido en cuenta una serie de criterios bien documentados?.

Al momento de seleccionar las entidades que estarn bajo la gestin de configuracin se
deben utilizar criterios que ayuden a la identificacin de dichas entidades, estas
entidades segn la naturaleza del proyecto pueden variar (INTECO, 2008). A

117
continuacin se mencionan algunos criterios que pueden tomarse como referencia:

Productos de trabajo que vayan a ser utilizados por dos o ms grupos.
Productos de trabajo que puedan cambiar con el tiempo debido a cambios en
requisitos o errores.
Productos que dependan de otros en el sentido de que un cambio en uno de ellos
implique un cambio en los otros.
Productos de trabajo que sean crticos para el proyecto.

(3) SP 1.1: Se le asignan identificadores nicos a las entidades para la gestin de
configuracin?.

Todos los elementos que estarn bajo la gestin de configuracin deben ser identificados
de forma inequvoca, a fin de evitar posibles errores. Con este propsito, le debern ser
asignados identificadores nicos a cada uno de los elementos facilitando el
reconocimiento de aquellos que se encuentran siendo monitoreados en el rea de control
de configuracin (INTECO, 2008). De igual forma le debern ser asignadas propiedades
a los elementos, este tema se plantea en la pregunta cuatro (4) de la SP: 1.1.

(4) SP 1.1: Se especifican caractersticas importantes de las entidades para la gestin
de configuracin (p.ej.: el autor, lenguaje de programacin, nombre archivo, etc.?.

Como se mencion anteriormente, todos los elementos que sern gestionados debern
tener asignado un identificador nico para determinar que estos elementos sern
monitoreados hasta terminar el proyecto. Los elementos no slo contarn con un
identificador, debern contar con propiedades tales como: autor, tipo de documento,
persona responsable de la configuracin, entre otras caractersticas que la organizacin
considere conveniente (INTECO, 2008).

(5) SP 1.1: Se identifica y documenta cuando cada entidad de configuracin estar

118
bajo la gestin de configuracin?.

En la gestin de configuracin se identifican los elementos que van a ser controlados, se
establecen esquemas para la identificacin de los elementos y sus versiones, y se
determinan las herramientas y tcnicas a usar para adquirir y gestionar los elementos
controlados (INTECO, 2008).

Entre las principales actividades para la identificacin se encuentran:

Identificar los productos que se van a mantener bajo gestin de configuracin
para el proyecto, como por ejemplo el documento de requisitos, ya que este
documento sufre modificaciones a lo largo del proceso de desarrollo de software.
Una vez identificados los elementos que estarn bajo la gestin de configuracin,
se procede a establecer la documentacin de los mismos a travs de la asignacin
de identificadores nicos para cada elemento de configuracin y propiedades
como autor, tipo de documento o fichero y el responsable de ese elemento de
configuracin; as como tambin definir una estructura de almacenamiento lo
cual facilita el acceso a dichos productos conjuntamente con la definicin de
niveles de control de acceso de los miembros del equipo sobre la infraestructura
de almacenamiento.

(6) SP 1.1: Se identifica el responsable de la configuracin de cada entidad?.

Durante el proceso de gestin de configuracin es necesario identificar al o los
responsables de realizar las actividades para gestionar los productos. Al tener asignados
responsables a las actividades se evitarn posibles confusiones de quines eran
responsables de realizar los seguimientos (INTECO, 2008).

(7) SP 1.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

119
de control ms complejos con la participacin del cliente.

Los niveles de control de las entidades que estn bajo la gestin de control pueden variar
por diferentes causas, tales como: los objetivos del proyecto, los recursos asignados y los
ciclos de vida del proyecto. Por lo cual, segn Sanz en el 2009, existen diferentes niveles
de control, por ejemplo:

Creacin: donde el elemento de configuracin es controlada por el autor de los
componentes que lo forman.
Ingeniera: se efecta control cuando existan cambios en el elemento de control y
se notificar a las personas interesadas de saberlo.
Desarrollo: se tiene un menor nivel de control bajo Change Control Board
(CCB) o junta de control de cambio.
Formal: mayor nivel de control de la CCB con la participacin del cliente.

(8) SP 1.2: Existe un sistema de control de versiones para controlar los work products
bajo la gestin de configuracin?.

Durante la gestin de control de versiones es importante implementar mecanismos
eficientes para la gestin de cambios, es decir, se debe tener la capacidad de estructurar
adecuadamente el histrico de cambios de un proyecto, las modificaciones y la
informacin adecuada de cada fase; por lo que los sistemas de control de cambio son
necesarios ya que permiten conocer las versiones por las que pasa el proyecto
(Rodrguez, 2010).

Entre los sistemas para el control de versiones se pueden encontrar, Baazar y Mercurial
los cuales son sistemas distribuidos, es decir, donde cada usuario tiene libertad de
establecer su propio repositorio y cuando lo decidan pueden sincronizarlo con los
usuarios restantes. Por otro lado estn los sistemas centralizados como Concurrent
Versions System (CVS) y Subversion los cuales cuentan con un nodo central para

120
albergar todo el cdigo que est a disposicin de todos los usuarios, el cual se almacena
en un nico directorio, normalmente alojado en un servidor y todos los desarrolladores
que trabajen sobre el mismo deben pedirle al servidor una copia para el trabajo local
(Rodrguez, 2010).

(9) SP 1.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?.

Un sistema de gestin de configuracin incluye medios de almacenamiento,
procedimientos y estrategias (Chrisis y cols., 2009). Si la organizacin ha establecido un
sistema para mantener un control en el desarrollo de software (sistema de gestin de
configuracin) todos los miembros de la organizacin desde los niveles ms altos
(directivos) hasta los ms bajos (empleados) deben utilizarlo, esto traer mltiples
beneficios en cuanto a la asignacin de actividades, visualizacin y control en los
productos que estn desarrollndose.

De nada servir que la organizacin contenga polticas y herramientas para el control de
versiones si no son utilizados.

(10) SP 1.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?.

Los sistemas de control de cambios permiten aadir mensajes (logs) cada vez que se
aade una versin nueva al repositorio. Estos mensajes pueden describir los cambios
realizados y porqu fueron hechos. Esto permitir a los desarrolladores conocer qu
contiene cada una de las versiones que se encuentran en el repositorio, resultando
tambin una forma efectiva de comunicacin y bsqueda (Departamento de Sistemas
Telemticos y Computacin, 2008).

121
(11) SP 1.2: Se dispone de un sistema para registrar las peticiones de cambio a los
work products bajo la gestin de configuracin?.

Todas las peticiones de cambio deben ser registradas, por lo que se debe contar con una
trazabilidad de las acciones que se realizan sobre los elementos que estn bajo la gestin
de configuracin. Un sistema que almacene los registros en la base de datos o bien
tenerlos en documentos fsicos permite realizar ese control. Independientemente del
sistema utilizado se debe contar con un control sobre el estado de las peticiones de
cambio (aceptada, en curso, rechazada, entre otras) (Sanz, 2009).

(12) SP 1.2: Se ha establecido un sistema de copias de seguridad y recuperacin para
preservar el contenido del sistema de gestin de configuracin?.

Como se mencion anteriormente los sistemas de control de cambios permiten conocer
el histrico de los estados por los que han pasado los elementos, es decir, se puede
volver a cualquier estado anterior de ser necesario. Esta es una de las razones
fundamentales de utilizar un sistema de control de cambios (Rodrguez, 2010).

(13) SP 1.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.

Los productos que se encuentran bajo la gestin de configuracin deben pasar a una
lnea base, para formar parte de una lnea base no solo deben estar identificados, deben
cumplir condiciones mnimas como estar terminados y haber sido aprobados. A partir de
que el producto forma parte de la lnea base para ser modificado debe pasar por el
proceso formal de control de cambios que la organizacin estableci (INTECO, 2008).

122
Los elementos de configuracin se colocan bajo control de la gestin de configuracin
en distintos momentos, es decir, se incorporan a una lnea base en un momento concreto
del ciclo de vida del software. El evento que desencadena esta incorporacin a la lnea
base es la realizacin de alguna tarea de aceptacin formal del elemento de
configuracin, como una revisin formal. A continuacin se detalla en la Figura 18
como se incorporan los elementos en un ciclo de vida en cascada (INTECO, 2008).

Figura 18. Incorporacin de los elementos a una lnea base en un ciclo de vida en
cascada.

(14) SP 1.3: Est definido claramente quin est autorizado para crear/liberar una
lnea base?.

Durante el proceso de control de configuracin de los elementos se debe dejar en claro
quines pueden crear/liberar una lnea base, esto evitara malos entendidos y confusiones
que puedan ocasionar una sobrecargada de trabajo. En la planilla de perfil de los
interesados, del apndice A (Figura A.2), se debe especificar quien podr realizar estas
actividades desde el comienzo del proceso (Pinzn y Flrez, 2010).

(15) SP 1.3: El conjunto de las lneas base son de fcil acceso?.

Durante el desarrollo de software es necesario establecer una estructura de

123
almacenamiento de versiones de aquellos elementos que estn bajo la gestin de
configuracin ya que esto permitir al grupo de desarrollo consultar o acceder a
cualquier lnea base previamente establecidas cuando sea necesario.

(16) SP 2.1: Existe algn procedimiento escrito que establezca cmo se gestionan las
peticiones de cambio?.

Las peticiones de cambios sobre cualquier elemento que forme parte de una lnea base
deben pasar un proceso formal de control de cambios, estas peticiones sern analizadas
para determinar el impacto y como afectara el calendario, el presupuesto y los work
products relacionados. Segn lo planteado por Sanz en 2009, existen cuatro fases para
gestionar una peticin de cambio:

Fase 1: Se registran las solicitudes de cambio.
Fase 2: Se analiza el impacto de los cambios de las solicitudes de cambio
efectuadas. Los cambios sern evaluados a travs de actividades que aseguren
que son compatibles con los actuales requisitos del proyecto y sus tcnicas.
Fase 3: Se examinarn las peticiones de cambio aceptadas para comprobar cules
de ellas sern abordadas en la siguiente lnea base. Esto se acordar con las
personas pertinentes obteniendo un acuerdo.
Fase 4: Se realizar un seguimiento hasta el cierre para comprobar que se ha
introducido correctamente en el sistema.

(17) SP 2.1: El registro de las peticiones de cambio incluye campos que permiten la
adecuada gestin de las mismas (p.ej.: estado de la peticin, productos afectados,
esfuerzo estimado, responsable asignado, etc.)?.

Las peticiones de cambios deben realizarse de manera formal mediante una minuta,
sistema manual o automatizado donde se especifique el identificador del elemento,
autor, quin solicita el cambio, tipo de lnea base (funcional, desarrollo, otras), estado en

124
que se encuentra, descripcin, prioridad, etc. Esto permitir realizar un control adecuado
por parte de grupo de control de cambios y por quienes lo han solicitado (Pinzn y
Flores, 2010).

(18) SP 2.1: Se realiza un adecuado seguimiento del estado de las peticiones de
cambio hasta su cierre?.

Una de las formas de mantener el control sobre el estado de las solicitudes de cambio, es
que a partir que una solicitud de cambio es realizada, es comunicada al equipo de control
de cambios, el estado de esta peticin al principio se encuentra en propuesto,
posteriormente cuando el equipo evala y acepta la peticin deber cambiar su estado a
activo. En ese momento la persona que solicit el cambio puede realizar las tareas y
seguidamente las pruebas de implementacin y la solicitud pasar a un estado de
resuelto. Para finalizar, cuando el equipo de control haya validado el cambio y certifique
que fue realizado correctamente, el estado de la solicitud pasar ha cerrado. En la Figura
19 se muestra el estado por las que pasa una solicitud de cambio (Garca, 2009).

Figura 19. Estado de solicitudes de cambio.

(19) SP 2.1: Se analiza el impacto de los cambios y las correcciones al proyecto?.

125
El grupo de control de cambios evaluar el impacto antes de tomar cual decisin acerca
de la solicitud de cambios, estos determinaran el impacto sobre el tiempo, el presupuesto
y los productos que se puedan ver afectados. En base a los anteriormente dicho se
decidir si el cambio es aprobado o es rechazada y cerrada la peticin (Burgun, 2008).

(20) SP 2.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?.

Antes de que un elemento de la configuracin se convierta en una lnea base es posible
realizar cambios de manera rpida, sin embargo posteriormente no es as, cuando el
elemento pasa a formar parte de la lnea base, metafricamente pasa a travs de una
puerta giratoria de una sola direccin. Si los pasos sucesivos ameritan cambios en estos
elementos se requerir de una revisin formal justificando todo los cambios que se
realicen y un acurdo entre todas las partes interesadas (Cabrera, 2007).

(21) SP 2.2: Se tiene un control de los elementos de configuracin durante toda la vida
til del producto?.

La gestin de configuracin de software permite identificar, controlar, auditar e informar
modificaciones que invariablemente ocurren mientras se desarrolla el software y despus
de que ste se libera a un cliente. Este proceso est conformado por varias tareas que
incluyen; identificar los elementos para la configuracin del software, gestionar los
cambios de dichos elementos, facilitar la construccin de diferentes versiones de una
aplicacin y garantizar que la calidad del software se conserva conforme la
configuracin evoluciona a lo largo del tiempo. Por lo que los elementos que estn bajo
la gestin de configuracin dejaran de ser monitoreados cuando el producto final sea
entregado al usuario final y sea aprobado por este (Cabrera, 2007).

(22) SP 2.2: Antes de cambiar una configuracin se obtiene la autorizacin de la

126
persona apropiada?.

De acuerdo con lo dicho anteriormente, durante el proceso de gestin de configuracin
de los elementos se identifican quienes pueden liberar o crear una lnea base entre otras
funcionalidades. Habiendo establecidos quienes y qu responsabilidades tienen en el
desarrollo del proyecto se debe solicitar autorizacin a la persona apropiada si los
elementos a modificar forman parte de una lnea base (INTECO, 2008).

(23) SP 2.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?.

Con el fin de evitar conflictos al compartir archivos cuando dos o ms personas trabajan
en l, ocasionando cambios descontrolados, existen mecanismos como check-out el cual
permite adquirir la exclusiva de los recursos bloqueando el elemento cuando otros
usuarios quieran acceder a l o check-in que permite liberar el elemento cuando el
usuario que realiz el check-out guardo la ltima versin (Oviedo, 2010).

El objetivo de estos mecanismos es que siempre se realice una modificacin sea en la
ltima versin que ha sido trabajada. En la Figura 20 se muestra un ejemplo de cmo
trabajan estos mecanismos (Oviedo, 2010).

Figura 20. Modelo bloquear, modificar, desbloquear.

(24) SP 2.2: Se hace una evaluacin de los cambios para comprobar que no se han

127
causado efectos no deseados sobre la lnea de base (p.ej.: comprometer la seguridad del
sistema?.

Cuando se realiza una peticin de cambio el equipo evala el impacto desde diferentes
ngulos (presupuesto, horas hombre, elementos que afecta, calendario, otros) y si esta
rechazada o aprobada. En el caso que se acepte la solicitud y el elemento sea modificado
el equipo nuevamente debe evaluar si los cambios se hicieron correctamente y si no
afecta a los elementos que dependen de l; de ser as el grupo se debe reunir para realizar
acciones correctivas (Cabrera, 2007).

(25) SP 3.1: Se detallan las versiones especficas de los elementos de configuracin
que conforman una lnea base particular?.

Durante la gestin de configuracin se debe detalla la versin de los elementos que
forman parte de una lnea base (elemento estable y aprobado) debido a que no todos los
elementos forman parte de una lnea base desde el comienzo ya que cada producto
(cdigo, documentacin tcnica, documentacin de gestin, etc.) puede ser incorporado
en distintas fases del proyecto. Para mantener un control sobre stos se debe establecer
cuales son estables y cuales an requieren modificaciones sin afectar a las versiones que
ya forman parte de la lnea base.

(26) SP 3.1: Es posible recuperar una versin antigua?.

Los repositorios de los sistemas de gestin de configuracin permiten almacenar las
diferentes versiones de un elemento por lo que de ser necesario se puede acceder a una
versin anterior. Esta no es la nica funcionabilidad que ofrecen actualmente algunos
repositorios, se pueden determinar las dependencias y variantes de los diferentes
elementos que se encuentran en el repositorio (Cabrera, 2007).

(27) SP 3.1: Se especifica la versin ms actual del elemento de configuracin?.

128
Es importante conocer cul es la ltima versin del elemento que est bajo la gestin de
configuracin, existen diferentes formas de realizar este control, mecanismos como
bloqueo, modificacin y desbloqueo pueden ayudar a controlar los elementos. Otra
forma de realizarlo es teniendo una carpeta donde se guardara la ltima versin y otra
con las versiones anteriores y de esta forma poder acceder fcilmente a la versin actual
y anterior de un elemento (Sanz, 2009).

(28) SP 3.1: Se especifican las diferencias entre sucesivas lneas base?.

Se deben establecer diferencias entre los elementos que conforman las lneas bases, por
ejemplo s se da el caso de que un grupo de desarrollo desea volver a un versin anterior
del elemento que conforma la lnea base, para ello se debe conocer que contiene cada
una de las versiones. En estos casos y como se mencion antes los logs permiten
conocer que contiene cada versin y resultan tiles en este tipo de bsquedas
(Departamento de Sistemas Telemticos y Computacin, 2008).

(29) SP 3.2: Se evala la integridad de las lneas base y se confirma el correcto
seguimiento de los procedimientos y cumplimiento de los requisitos?.

A travs del uso de las auditorias se puede determinar la integridad de las lneas base,
esto con el objetivo de establecer si los procesos realizados y la documentacin se
ajustan a las normas que ha establecido la organizacin. Segn Sanz en el ao 2009, se
pueden realizar en estos casos diferentes auditorias, como por ejemplo:

Configuracin de auditoras funcionales: se comprueba que las caractersticas
funcionales de los elementos de configuracin satisfacen los requisitos
especificados en la lnea base, que el apoyo operativo es el correcto y que su
documentacin es correcta y satisfactoria.
Configuracin fsica de auditora: se comprueba que la construccin del elemento
de configuracin se ajusta a las especificaciones tcnicas.

129
Auditorias de gestin de configuracin: se confirma que la gestin de registros de
configuracin son completos, coherentes y exactos.

Estas auditoras debern ser documentadas para su posterior anlisis y de ser el caso
realizar acciones correctivas.

(30) SP 3.3: Existen procesos, procedimientos, plantillas, herramientas para la gestin
de la configuracin? la utilizan los proyectos?.

Al respecto de las herramientas, procesos, plantillas o procedimientos, la organizacin
que desea implementar esta rea de proceso debe contar con procesos bien definidos
para el control de cambio, un sistema para gestionar eficazmente los elementos que estas
bajo el uso de la gestin de configuracin y utilizar mecanismos como check-in y check-
on que permitirn mantener un control sobre las versiones realizadas.

3.3.2.7 Aseguramiento de la calidad de productos y procesos

(1) SP 1.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?.

El SEI ha detectado tres dimensiones crticas en las que se deben enfocar las
organizaciones para mantener productos y servicios de calidad, entre los cuales se
pueden mencionar: las personas, los mtodos y procedimientos, herramientas y
equipamiento. Pero son los procedimientos utilizados al desarrollar software los que
sustentan todo el conjunto, permitiendo alinear el modo en que opera la organizacin,
evolucionar e incorporar nuevos conocimientos de cmo hacer mejor las cosas Estos
pueden ser observados en la Figura 21 (Chrisis y cols., 2009).

Aquellas organizaciones que han alcanzado cierto nivel de madurez y cuentan con

130
procedimientos de aseguramiento de calidad estableciendo planes, procesos, normas y
procedimientos que le dan un valor aadido a sus proyectos deben ser capaces de
evaluar si se cumplen. De nada le sirve a una organizacin establecer procesos de
calidad de desarrollo de software cuando estos no son ejecutados, por ello se hace
necesario que un grupo auditor realice una evaluacin objetiva del cumplimiento de los
elementos de calidad que haya definido la empresa, estas evaluaciones debern ser
documentadas, se especificar si se cumplen o no los procedimientos y se tomarn
acciones correctivas de ser negativa la evaluacin (Sanz, 2009).

Figura 21. Las tres dimensiones crticas.

(2) SP 1.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?.

Una auditoria es un proceso sistemtico, independiente y documentado para obtener
evidencia de la misma y as evaluarla objetivamente para determinar la medida en la
cual se cumplen los criterios (ISO 19011, 2011). Una auditoria debe contar con una
estructura clara y precisa que facilite a la organizacin saber qu se est evaluando y
porqu. Una estructura de una autora segn la normativa ISO 1911 se podra presentar
de la siguiente forma:

Alcance.

131
Referencias normativas.
Trminos y definiciones.
Criterios.
Hallazgos.
Conclusiones entre otros puntos.

Los criterios en una auditoria forman parte fundamental de stas y deben ser definidos
desde el principio. Los criterios definen el deber ser de la organizacin y proveen los
parmetros para evaluar las prcticas que se realizan y determinar si la organizacin
cumple o no con las normas, metas, planes, programas u objetivos establecidos (Castro y
Sarmiento, 2011). Algunos criterios que se pueden establecer durante la realizacin de
una autora pueden ser: qu ser evaluado?, cundo se realizar la evaluacin?, cmo
se realizar la evaluacin? y quin la realizar la evaluacin?.

(3) SP 1.2: Se registran las no conformidades de las auditoras a procesos de forma
que puedan ser gestionadas y se les pueda dar seguimiento?.

Durante el establecimiento de una autora se determinan los criterios por los cuales se
regir est. Los criterios proporcionarn una referencia de cmo se deben realizar los
procesos en la organizacin. Si el equipo auditor determina que estos criterios no se
cumplen debern ser registrado en un informe que le ser dado a la direccin de la
organizacin notificndoles cuales criterios no se cumplen y estos puedan realizar su
posterior correccin (Calianes, 2010).

El registro de las no conformidades es una de las razones fundamentales por lo que las
organizaciones realizan las auditorias puesto que les permiten conocer donde estn
fallando, mejorar sus procesos tomando como base las fallas y medir el grado en que han
mejorado fijndose una fecha como referencia a travs de otros registros de autoras
realizados anteriormente.

132
(4) SP 1.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?.

Las auditorias de software no slo pueden ser realizadas a los procesos que realizan la
organizacin, los work products pueden ser auditados para confirmar que estos cumplen
los criterios establecidos por la organizacin. De la misma forma que pasa con los
procesos cuando son auditados, si los work products no cumplen con los criterios, estas
anomalas se registran en un documento de no conformidad, como el que se muestra en
el anexo J, y se notifica a la direccin para que realice las correcciones pertinentes
(Sanz, 2009).

(5) SP 1.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).

Independientemente de la auditoria a realizar, se deben establecer desde el principio los
criterios que establecern los procedimientos y las referencias para evaluar lo que la
organizacin haya estipulado. Los work products no son la excepcin a la regla, para
realizarles una auditoria se deben establecer criterios de evaluacin al igual que todos los
dems puntos que establecen las normas, tales como ISO 19011 que estipula ciertos
aspectos para realizar una auditora (Calianes, 2010).

(6) SP 1.2: Se registran las no conformidades de las auditoras a work products de
forma que puedan ser gestionadas y se les pueda dar seguimiento?.

Para lograr el mejoramiento de los work products, se hace necesario documentar todas
aquellas no conformidades que hayan sido detectadas durante las auditoras realizadas.
Las no conformidades sern enumeradas y entregadas en un informe donde la

133
organizacin podr ver en que estn fallando y optimizar sus proyectos a travs del
mejoramiento de los work products del proyecto (Calianes, 2010).

(7) SP 1.2: Se han prefijado unos puntos (calendario) a lo largo de la vida (fases ms
crticas, hitos, entregas al cliente, etc.) del proyecto en los qu auditar los productos de
trabajo?.

En ningn caso las auditorias deben realizarse en forma sorpresiva, cada rea, actividad,
proceso o work products a auditar debe ser notificado con anterioridad, especificando
fecha y alcance de la auditoria. Las auditorias deben ser realizadas de forma sistemtica,
planificadas y programadas por lo que se debe fijar un calendario donde se establezcan
las fechas en que se realizarn las auditorias para comprobar la calidad de los work
products antes de que sean mostrados al cliente o integrados al proyecto (Asociacin
Espaola para la Calidad, 2013).

(8) SP 2.1: Se determinan y registran acciones correctivas destinadas a resolver las no
conformidades?.

Uno de los objetivos de la auditoria es determinar las discrepancias o las no
conformidades que existen segn las polticas, procedimientos o criterios que se hayan
propuestos la organizacin. La auditora no se basa en encontrar errores para culpar a las
personas, es sencillamente una herramienta que permite verificar que el trabajo se est
haciendo conforme a lo establecido (Asociacin Espaola para la Calidad, 2013)

Despus de haber detectado las no conformidades el equipo autor y en un consenso con
el responsable del rea auditada debern realizar un informe donde muestren la realidad
del rea y las recomendaciones para la mejora en el caso que los objetivos de la auditoria
lo indique. Posteriormente el responsable del rea debe verificar que se realicen las
correcciones y que no son interrumpidas de manera injustificada, para ello se debe
realizar un seguimiento y verificacin de las acciones recomendadas en el informe

134
(Asociacin Espaola para la Calidad, 2013).

(9) SP 2.1: Se da un seguimiento apropiado (p.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?.

Como ya se ha sealado, en una auditoria despus de determinar las inconformidades se
estipulan un conjunto de recomendaciones que debern ser acatadas por el responsable
del rea auditada (Asociacin Espaola para la Calidad, 2013).

Para llevar un control sobre las soluciones recomendadas, es necesario que se fije un
calendario donde quedar acentuado cundo debern estar resultas las inconformidades,
de igual forma se deben estipular un conjunto de revisiones peridicas donde se
verifique que se estn llevando a cabo las actividades que permitirn que las
inconformidades sern resueltas para la fecha establecida (Sanz, 2009).

(10) SP 2.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?.

Mediante las auditorias se realizan evaluaciones de la evidencia encontrada en relacin
con los criterios para determinar la conformidad o no conformidad de los criterios de
auditora o especificaciones del sistema de gestin de la calidad. Una vez determinadas
las no conformidades la organizacin deber presentar y ejecutar un conjunto de
acciones correctivas para resolverlas, en el caso de que la organizacin no logre sus
objetivos en cuanto a las no conformidades, deber solicitar los servicios de un equipo
externo que gua a la organizacin en la resolucin de estas (Asociacin Espaola para
la Calidad, 2013).

(11) SP 2.1: Se asegura de que las partes interesadas son conscientes de los resultados

135
de las evaluaciones y las tendencias de la calidad de forma oportuna?.

Los resultados de las evaluaciones deben ser presentados a los auditados y a las partes
interesadas a travs de las reuniones de cierre realizadas por el lder del equipo auditor
que se basan en la presentacin e informe de los hallazgos y conclusiones de la auditora
(Asociacin Espaola para la Calidad, 2013).

(12) SP 2.2: Se desarrollan informes de auditora que reflejen el resultado de las
revisiones de aseguramiento de la calidad en los proyectos: n de no conformidades
detectadas por proceso, n de no conformidades abiertas, cerradas, etc.?.

Durante el desarrollo de las auditorias y segn los objetivos que se hayan planteado
antes de la ejecucin de la misma se desarrollan diferentes informes; de la misma forma
durante y despus de esta. Algunos de los informes que se pueden realizar en una
auditoria, segn Chrisis y colaboradores en el 2009, son:

Informes de evaluacin.
Informes de no conformidad.
Registro de opiniones.
Acciones correctivas.

En los informes se dejar claro que se evala, quien evala, cuales es el alcance y
mtodo, entre otros puntos. Por otro lado se deben documentar en un informe las no
conformidades donde se establecern el nmero encontrado y se evaluarn por parte del
auditado y el auditor para asegurar el entendimiento y el acuerdo, de existir un
inconveniente con respecto a alguna no conformidad deber quedar un registro. As
mismo se presentaran las acciones correctivas que darn solucin a las no
conformidades y por otra parte se deber registrar y llevar una evaluacin del proceso de
la ejecucin de la soluciones de las no conformidades. En el anexo J se muestra un
formato de un registro de no conformidad.

136
(13) SP 2.2: Existen procesos, procedimientos, plantillas, herramientas para el
aseguramiento de la calidad de los procesos y productos? la utilizan en los proyectos?.

En esta rea de proceso se generan diferentes tipos de documentacin entre los cuales se
encuentran diversos tipos de informes. Entre los informes se pueden mencionar los
siguientes:

Informes de evolucin.
Registro de opiniones.
Acciones correctivas.
Informes de resultados de acciones correctivas.

3.3.2.8 Prcticas genricas

(1) GP 2.1: Se definen de antemano las expectativas de la organizacin en todos los
procesos y se hace visibles a los involucrados?.

La organizacin debe definir de antemano las expectativas que tienen en relacin con un
proceso y hacerlas visibles para aquellos que se vean afectados. Para ello la direccin se
encargar de establecer y comunicar los principios, guas, orientacin y expectativas que
esperan de un proceso, con el objetivo de crear una poltica de cmo se deben planificar
y realizar sus procesos.

No toda orientacin que ofrezca la direccin llevar la etiqueta poltica, lo que se
busca es la existencia de una orientacin apropiada por parte de la organizacin,
independientemente de cmo sea llamada o comunicada.

(6) GP 2.5: Se da una formacin adecuada a las personas que realizan el proceso?.

Las personas que realizan los procesos establecidos por la organizacin deben contar

137
con las habilidades y experiencia necesaria para realizar o dar soporte a los procesos, por
lo tanto la organizacin debe proporcionar una formacin adecuada a estas personas.
Entre los mtodos que pueden recurrir las organizaciones para forman a su personal se
encuentran: autoestudio, auto formacin dirigida, instruccin programada, formacin en
el puesto de trabajo y tutora y formacin formal en el aula.

La formacin ayuda a realizar los procesos satisfactoriamente ya que proporciona una
comprensin comn del proceso, impartiendo habilidades y conocimientos necesarios
para la realizacin de estos.

(8) GP 2.6: Se tiene un control de versiones con los cambios realizados de los
productos del proceso?.

Todo producto realizado debe pasar por un control durante su desarrollo, existen
diferentes tipos de control, en el caso de algunos productos es suficiente con mantener
un control de versiones, es decir, la versin del producto de trabajo en uso en un
momento dado, pasado o presente, se conoce y los cambios se incorporan de una forma
controlada, en otros casos ser necesario realizar un control de configuraciones, este tipo
de control incluye en la definicin y el establecimiento de lneas base en puntos
predeterminados. Estas lneas base se revisan y acuerdan formalmente y sirven como
base para desarrollos posteriores de los productos de trabajo designados.

La organizacin debe determinar, basado en la utilizacin de criterios, cuales productos
estarn bajo un control de versiones y cuales ameritan estar bajo la gestin de
configuraciones.

(11) GP 2.8: Se identifican y evalan las desviaciones del plan?.

Para la identificacin y posterior evaluacin de las desviaciones del plan se hace
necesario monitorizar y realizar un control del proceso el cual incluye medir los
atributos apropiados de los procesos o de los productos.

138
La organizacin debe establecer cundo se realizarn las monitorizaciones y cmo, se
deber identificar el rendimiento real frente a lo planeado y de existir alguna desviacin
se evaluarn los efectos y las acciones correctivas que correspondan a cada caso,
tomando en cuenta los riesgos que implican en ocasiones la implementacin de estas
acciones correctivas.

(12) GP 2.8: Se toman medidas para corregir los problemas del plan o las
desviaciones del plan mediante correcciones del plan, aumento de recursos,
negociacin de compromisos, aumentar el esfuerzo?.

Por medio de la monitorizacin el lder del proyecto ser capaz de identificar las
desviaciones que presente el proyecto, as ste tendr la faculta de realizar las acciones
correctivas que considere pertinentes. Entre las acciones correctivas que el lder de
proyecto puede tomar se encuentran:

Tomar acciones correctoras para reparar los productos de trabajo o los servicios
defectuosos.
Cambiar el plan del proceso.
Ajustar los recursos incluyendo personas, herramientas y otros recursos.
Negociar los cambios de los compromisos establecidos.

(14) GP 2.10: Se realizan valoraciones de los procesos para los altos cargos segn sus
necesidades para que le ayuden a la hora de tomar decisiones?.

Los altos directivos de la organizacin deben tener una visibilidad apropiada del proceso
segn sus funciones, por lo que se recomienda que las revisiones de los procesos sean
realizadas peridicamente o por eventos y debern suministrar informacin sobre la
planificacin, realizacin y estado del proceso, lo que permitir tomar decisiones a la
alta gerencia basada en la informacin suministrada.

139
Los altos directivos segn CMMI incluyen a aquellos niveles de gerencia en la
organizacin situados por encima del nivel inmediato de gerencia responsable de los
procesos.

140
CONCLUSIONES

El modelo CMMI para el desarrollo 1.2 en su representacin por etapas, propuesto por la
Carnegie Mellon (Chrisis y cols., 2009), est compuesto por modelos que definen el qu
hacer y por mtodos de evaluacin que miden los procesos de la organizacin a travs de
un conjunto de estndares (niveles de madurez) lo que en conjunto proporciona un
framework bien definido que permiti proponer las mejoras de los procesos de
desarrollo de software en SIM C.A. de la CPTO de una forma organizada.

Las organizaciones pequeas que se encuentran iniciando sus funciones en el desarrollo
de software se hallan con un mercado competitivo donde la experiencia y
reconocimiento son parte fundamental para que clientes potenciales depositen su
confianza en ellos. Al ser emprendedores en el desarrollo de software en ocasiones
carecen de ambos. La mayora de estas empresas nacen y mueren en su primer ao de
vida, algunas de las razones son porque sus procesos son reactivos lo que impide que
estas cumplan con las metas establecidas al principio de su planificacin. El CMMI para
el desarrollo en su representacin por etapas le permite a empresas jvenes conocer el
estado en que se encuentran sus procesos y les ofrece un camino que permite mejorar
progresivamente sin necesidad de que desaparezcan. CMMI permite a las empresas
planear, medir, controlar y evaluar sus productos a travs de las mejores prcticas que se
encuentran establecidas en el modelo, lo que garantiza un presupuesto estable, un
producto de calidad y un cliente satisfecho.

La utilizacin del CMMI, no solo garantiza la generacin de un producto de la calidad,
su utilizacin en empresas TIC incubadas disminuye la posibilidad de mortandad de las
mismas ya que al ser un modelo reconocido a nivel mundial le otorga a las
organizaciones cierto estatus y garantiza a sus clientes que aunque sea un empresa
pequea ofrecen productos de excelencia, por otra parte, los directivos de estas
organizaciones tienen la posibilidad a travs de la visibilidad que le ofrecen las reas

141
como MA y CM de tomar decisiones acertadas que eviten atrasos y prdidas durante el
desarrollo de sus proyectos.

La implementacin del modelo IDEAL facilit un marco para que los cambios a
proponer mediante la utilizacin del CMMI se realizarn de forma eficaz, ya que el
modelo proporciona un camino para guiar la mejora de los procesos de software desde el
inicio hasta el fin y debido a su recursividad y esencia los procesos pueden ser
mejorados continuamente, lo que guiar a SIM C.A. durante la aplicacin de la
propuesta y posteriormente la realizacin de posibles mejoras sobre la misma.

142
RECOMENDACIONES

Para la implementacin de la propuesta de SPI es necesario completar el ciclo del
modelo IDEAL a travs de la realizacin de las actividades que establece en las fases de
actuacin y aprovechamiento, esto con la finalidad de obtener una propuesta que ser
probada y refinada, adaptndose a las necesidades de la organizacin y que podr ser
continuamente mejorada. El modelo IDEAL es un modelo cclico, por concerniente,
para terminar un ciclo se detallan las fases y las actividades necesarias que deben ser
realizadas en SIM C.A., por lo cual se recomienda:

En la fase de actuacin deben ejecutar todo lo planeado durante la fase de
establecimiento tomando como referencia todo lo descrito en este trabajo de
investigacin. Durante esta fase se debe realizar una prueba piloto de la mejora
conceptualizada, luego una vez probada y aprobada debe ser distribuida a todos los
procesos que realiza la organizacin. Entre las actividades que se deben realizar en esta
fase se encuentran: implementar la solucin, probar la solucin y refinar la solucin.

Con respecto a la fase de aprovechamiento, la cual completa el ciclo de mejoramiento
del modelo IDEAL y permite mejorar el proceso de desarrollo continuamente, el
objetivo es que cada iteracin sobre el modelo sea ms efectiva, al final se evalan si las
metas fueron logradas, se almacenan los resultados y se aplican las posibles mejoras en
las prximas iteraciones. Entre las actividades a ejecutar se encuentran: analizar y
validar, proponer futuras acciones.

La implementacin de las mejoras establecidas en la propuesta de SPI deben realizarse
de manera progresiva y respetando la esencia de los modelos utilizados, esto quiere decir
que la organizacin debe ir mejorando cada una de las reas de proceso que estable el
CMMI segn la representacin por etapas para alcanzar un nivel de madurez dos (2).
Para la elevacin del nivel de un rea de proceso se debe completar el ciclo definido en

143
el modelo IDEAL y una vez obtenido el nivel y los resultados esperados procedern al
mejoramiento de la siguiente rea.

Las organizaciones pueden definir cmo realizar las mejores prcticas establecidas por
el CMMI a travs del uso de metodologas como el Proceso Unificado (UP),
Programacin Extrema (XP), Scrum, Watch, entre otras, segn las necesidades de la
organizacin. En algunas ocasiones los modelos como CMMI no son concebidos para su
utilizacin con procesos de desarrollo de software, sin embargo esto es una percepcin
errada, los modelos de calidad como CMMI solo indican que se debe hacer, por otro
lado, los procesos de desarrollo indican cmo, lo que los ubica en diferentes niveles de
abstraccin posibilitando el uso en conjunto de stos (Garzas, 2009).

144
BIBLIOGRAFA

Asociacin Espaola para la Calidad (AEC). (2013). Calidad Asociacin espaola
para la calidad. Auditoria de calidad. < http://www.aec.es/web/guest/centro-
conocimiento/auditoria-de-calidad > (04/09/2013).

Barranco, J. (2001). Metodologa del Anlisis estructurado de Sistemas.Segunda edicin
Madrid Espaa.

Burgun, I. (2008). Gestin del cambio. Slideshare. < http://www.slideshare.net/i m
burg uan /gestin-del-cambio-del-software > (17/09/2013).

Cabrera, F. (2007). Gestin de cambio. MYGET. < http://www.mygnet.net/ arti cul
os/ software/ gestion_del_cambio.1082 > (17/09/2013).

Calianes, V. (2010). Auditorias de calidad. Slideshare. < http://www.slideshare.
Net /verogali /auditorias- de-calidad-8208993 > (02/09/2013).

Carnegie Mellon. (2002). Migration from the SW-CMM to CMMI. Software
Engineering Institute. <http://www.sei.cmu.edu/cmmi/adoption/migration.html>
(18/03/2011).

Castro, R. y Sarmiento A. (2011). Aseguramiento de calidad del proceso y del producto
(PPQA). Primera edicin. Madrid. Espaa.

Chrisis, M., Konrad, M. y Shrum, S. (2009). Gua para la integracin de procesos y la
mejora de productos. Segunda edicin. Madrid. Espaa.

Corporacin Parque Tecnolgico de Mrida Venezuela. 2011. Parque Tecnolgico de
Merida Venezuela. Parque Tecnolgico de Mrida Venezuela. <http://www.
cptm.ula. ve/index.php?Funcion=ConsultarPagina Detallada& IdPagina=3>
(26/10/2011).

Corporacin Parque Tecnolgico de Oriente. 2010. Corporacin Parque Tecnolgico de
Oriente. CPTO. <http://www.rectoria.udo.edu.ve/index.php?option= com_ content
&task=view &id=14> (27/10/2011).

Cueva, J. (1999). Calidad de software. Primera edicin.Madrid Espaa.

145
DBACCS. (2009). DBACCS. Un vistazo a DBACCESS. < http://www.dbaccess.
com/spanish/ > (08/10/2012).

De Luna, H. (2009). Beneficios del CMMI. Notas de Ingeniera de Software.
<http://swnotes.wordpress.com/ 2009/08/18/beneficios-del-cmmi/> (27/10/2011).

Departamento de Sistemas Telemticos y Computacin (GSyC). (2008). Sistemas de
control de versiones. Creative. <http://creativecommons.org/licenses/by-sa/2.1/es>
(14/09/2013).

Daz, J. (2010). Reutilizacin del software. Slideshare. <http://www.slideshare.net/
pto0404/seminario-3-reutilizacin-del-software> (11/07/2013).

Garca, J. (2009). Solicitud de cambio CMMI. MSDN. < http://msdn. Microsoft
.com/es -es/library/ee332482.aspx> (14/09/2013).

Garzas, J. (2009). Javiergarzas. Agilizando CMMI. < http://www. javiergarzas
.com/2009/12/agilizando-cmmi-charla-en-la-asignatura-de-fabricas-software-de-la-uni
versidad-rey-juan-carlos.html > (25/ 09/ 2013).

Gonzales, M. (2011). Pymes y autnomos. Microsoft. < http://www.microsoft. com/
business /es-es/content/paginas/article.aspx?cbcid=313> (18/07/2013).

Grupo Trput. (2012). Teora de restricciones. Sabe qu probabilidad tiene su
prximo proyecto de ser exitoso?. <http://grupotruput.com/2013/> (08/10/2012).

Guzmn, K. (2010). Manual para la elaboracin de lista de cotejo. Slideshare.
<http://www.slideshare.net/claudiaplata54/lista-de-cotejo-16072391> (08/10/2012).

Instituto Nacional de Tecnologa de la Comunicacin (INTECO). (2008). Gestin de
configuracin. Primera edicin. Madrid Espaa.

Instituto Nacional de Tecnologa de la Comunicacin (INTECO). (2008). Gua avanzada
de gestin de riesgos. Primera edicin. Madrid Espaa.

Instituto Nacional de Tecnologa de la Comunicacin (INTECO). (2009). Ingeniera de
software metodologas y ciclos de vida. Primera edicin. Madrid Espaa.

146
ISO 19011. (2011). Directrices para la auditoria de normas de gestin. Segunda edicin.

Len, D. (2010). Evolucin de proyectos. Slideshare. <http://www.
slideshare.net/ddjdlc /seguimiento-y-control-de-un-proyecto> (19/09/2013).

McFeeley, B. (2009). IDEAL
SM
: A Users Guide for Software Process Improvement.
Manual CMU/SEI-96-HN-001. Universidad de Carnegie Mellon. Pittsburgh,
Pensilvania. Estados Unidos.

Menndez, R. (2004). Informtica aplicada a la gestin pblica. Facultad de derecho.
UMU. Universidad de Murcia. <http://www.fdi.ucm.es/profesor/ricardo /ei2/ crisis.
pdf> (09/03/2011).

Monferrer, R. (2001). Especificacin de Requisitos Software segn el estndar de IEEE
830. Universitat Jaume I. Espaa.

Oviedo, J. (2010). Control de versiones. Consultora informtica. <http://
juanoviedo.wordpress.com/> (18/09/2013).

Pea, R. (2010). La crisis del software: aos 1960s y 1970s. Primera edicin. Pentice
Hall. Madrid. Espaa.

Prez, C. (2009). Que significa CMMI. Administracin de la configuracin. <http://
asprotech.blogspot.com/2009/06 /administracion-de-la-configuracion.html>
(14/09/20 13).

Pinzn, M. y Flrez J. 2010. Administracin y desarrollo de requisitos de Sistemas de
Software con UML. Trabajo de posgrado. Universidad Industrial de Santander.
Colombia.

Portal de la ISO en espaol. (2011). Calidad de software. La norma ISO 15504
SPICE. < http://www.iso15504.es/index.php/la-norma-iso-15504-spice.html> (06/ 11/
12).

Project Management Institute (PMI). (2004). Fundamentos de la direccin de proyectos
(PMBOK). Tercera edicin.

Quispe, R. (2007). Calidad. Computacin e Informtica. < http://www. Rodolf

147
foquispe.org/blog/que-es-la-calidad-de-software.php > (03/11/2012).

Real Academia Espaola. (2006). Organizacin. Pgina Web de la Real Academia
Espaola <http: // buscon . rae . es / draeI / SrvltConsulta ? TIPO_BUS = 3 & LEMA =
organizacin> (28/02/2011).

Rodrguez, J. (2008). Factibilidad de Implementacin del nivel 2 de CMMI en una
Organizacin de Software Pequea: Caso Divisin de Sistemas. Universidad
Francisco de Paula Santander. Colombia.

Rodrguez, J. (2010). Tecnologa de software. Sistema de control de versiones.
http://davidjguru.com/2010/03/03/sistemas-de-control-de-versiones-i-unaintroduccio n/
(14/09/2013).

Sabino, C. 2000. El proceso de investigacin. Editorial Panapo. Venezuela.

Sanz, S. (2009). Implantacin de CMMI en pequeas empresas de desarrollo de
software. Trabajo de posgrado. Universidad Politcnica de valencia. Espaa.

Scanziani, S. (2008). fundamentals of exploration and production y logistics.
slideshare.<http://www.slideshare.net/Saulsknz/mejora-de-procesos-de-softwarepre
sentation> (09/08/2012).

Sommerville, I. (2005). Ingeniera del software. Sptima edicin. Pearson. Madrid.

Universidad Nacional de Pampa. (1999). Calidad de software. Primera edicin. Madrid
Espaa.

Universidad Tecnolgica de Chile Instituto Profesional (INAPAP). (2010). Determinar
objetivos. Slideshare. <http://www.slideshare.net/squall835/unidad-3-determinar-
objetivos> (23/07/2013).

148

APNDICES

149
NDICE

Pg.
Apndice A. Listas de verificacin aplicada a los incubados SIM C.A. de la CPTO ... 150

150
Apndice A. Listas de verificacin aplicada a los incubados SIM C.A. de la CPTO.

Nombre del evaluador: Eliana Daz
Nombre del evaluado: Soluciones Informtica Manzanares C.A.
Nombre de la evaluacin: Prcticas especficas (SP) correspondientes al
rea de Gestin de requisitos REQM

SI/NO
(1) SP 1.1: Mediante la realizacin de un proyecto se determina quienes
son los proveedores de requisitos autorizados (cliente externo, interno,
usuario final)?

NO

(2) SP 1.1: Existen criterios objetivos para establecer la aceptacin de
los requisitos (p. ej.: claro y adecuadamente definido, completo,
consistente con otros requisitos, identificado unvocamente,
implementable adecuadamente, testeable, trazable)?

NO

(3) SP 1.1: Se analizan los requisitos garantizando que los criterios
establecidos se cumplen?

NO

(4) SP 1.1: Existe un registro donde se recopilen los requisitos del
proyecto?

SI

(5) SP 1.2: Se llega a un conjunto de requisitos donde ambas partes
(desarrolladores y usuarios) estn comprometidos?

SI

(6) SP 1.2: Existe un registro del personal encargado de implementar
los requisitos (p.ej.: firma del plan de proyecto, actas de la reunin de
lanzamiento o de las reuniones internas de requisitos, atributo en la base
de datos de requisitos para reflejar el estado de revisin/compromiso)?

NO

(7) SP 1.3: Se registran las peticiones de cambios de los requisitos
(fuente, razn de cambio, en relacin con otros requisitos a los que
afecte)?

NO

(8) SP 1.3: Se ha determinado el o los responsables de aprobar o
desaprobar los cambios en requisitos?

NO

(9) SP 1.3: Se han establecido criterios para aprobar o desaprobar los
cambios propuestos?

NO

151
(10) SP 1.3: Existen atributos que indiquen el estado actual de los
requisitos (p.ej.: aprobado, rechazado, implementado, propuesto, entre
otros)?

SI

(11) SP 1.3: Existen procesos, procedimientos, plantillas, herramientas
para gestin de requisitos? la utilizan en los proyectos?

NO

(12) SP 1.4: Se mantiene una trazabilidad de los requisitos fuentes a sus
derivadas (matriz de trazabilidad)?

NO

(13) SP 1.5: Se identifican incoherencias entre los requisitos, los planes
de proyecto y los work products, se documentan y se toman medidas
correctivas?

NO

Figura A.1. Respuestas de las prcticas especificas del rea de procesos de REQM.

rea de Planificacin de Proyectos PP

SI/NO
(1) SP 1.1: Se cuenta con una estructura de trabajo jerrquica (WBS)
para realizar una estimacin inicial de los proyectos?

SI

(2) SP 1.1: Se identifican los paquetes de trabajo con suficiente detalle
como para precisar estimaciones de las tareas del proyecto,
responsabilidades y calendario?

NO

(3) SP 1.1: Se identifican los productos que se adquirirn
externamente?

SI

(4) SP 1.1: Se identifican los work products que sern reutilizados? NO

(5) SP 1.2: Se realiza un planteamiento tcnico donde se define una
estrategia de alto nivel para el desarrollo del proyecto (la estrategia
define: la arquitectura desarrollo (distribuido o cliente/servidor) estado
del arte o tecnologas establecidas para aplicarse, tales como robtica,
materiales compuestos o inteligencia artificial; y la amplitud de la
funcionalidad esperada en los productos finales, tales como la seguridad,
la proteccin y la ergonoma.)

SI

152

(6) SP 1.2: Se establecen estimaciones de los work products?, se
pueden realizar estimaciones de costo 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.

SI

(7) SP 1.3: Se determina el ciclo de vida del proyecto? SI

(8) SP 1.4: Se realiza una estimacin de las horas de trabajo y el coste
del proyecto tomando en cuenta los atributos de los work products, las
necesidades de infraestructura, etc.?

SI

(9) SP 2.1: Se identifican los hitos principales del proyecto? SI

(10) SP 2.1: Se determinan las actividades sobre las cules existen
pocos datos de estimacin disponibles para identificar el nivel de
incertidumbre en el calendario global?

NO

(11) SP 2.1: Se identifican las limitaciones que se tienen en cuanto al
tiempo y los recursos con que se cuenta?

SI

(12) SP 2.1: Se identifican las tareas predecesoras y sucesoras para
determinar un orden optimo a travs de la aplicacin de herramientas
como CPM o PERT?

SI

(13) SP 2.1: Se establece y mantiene el presupuesto y el calendario
general a lo largo del proyecto?

NO

(14) SP 2.1: Se estableci un criterio de lo que constituye una
desviacin significativa respecto al plan de proyecto (este criterio define
cundo deberamos replanificar el proyecto y por lo tanto renegociar)?

NO

(15) SP 2.2: Se analizan y se describen los riesgos de forma
comprensible, de manera que puedan ser analizados para su posterior
correccin segn lo apropiado?

NO

(16) SP 2.2: Se revisa y se mantiene actualizada la lista de riesgos (de
identificarse nuevos riesgos estos sern aadidos a la lista)?

NO

(17) SP 2.2: Se obtiene un acuerdo en forma de documento con las
partes interesadas sobre la correccin de los riesgos documentados?

NO

153

(18) SP 2.3: Se establecen procedimientos para garantizar la privacidad
y seguridad de documentos del proyecto?

NO

(19) SP 2.3: Se establecen mecanismos para almacenar y para acceder a
los datos del proyecto?

NO

(20) SP 2.3: Se determinan los datos del proyecto a recopilar,
identificar y distribuir?

NO

(21) SP 2.4: Se definen las necesidades de personal del proyecto (p.ej.:
necesito dos (2) analistas y cuatro (4) programadores)?

SI

(22) SP 2.4: Se definen las necesidades de infraestructura del proyecto
(p.ej.: equipamiento, HW, SW, instalaciones)?

SI

(23) SP 2.5: Se identifican los conocimientos necesarios para la
realizacin de un proyecto y se da formacin al personal en las reas con
poco conocimiento (cursos, autoformacin, entre otros)?

SI

(24) SP 2.6: Se definen los roles y las responsabilidades de las partes
interesadas? se definen las interacciones entre las partes interesadas?
una buena forma de tener esto es con una matriz bidimensional con las
partes interesadas en un eje y las actividades del proyecto en otro eje

NO

(25) SP 2.7: Se ha documentado un plan general de proyecto que
integre de forma lgica todos los aspectos de la gestin de proyectos?

NO

(26) SP 3.1: Se revisan los planes del proyecto para un total
entendimiento entre todas las partes involucradas?

SI

(27) SP 3.1: Existen evidencias de la coordinacin entre los
involucrados en el plan de proyecto a travs de reuniones y acuerdos?

NO

(28) SP 3.2: En caso necesario, se modifica/ajusta el plan de proyecto
para adaptarlo a los recursos disponibles (p.ej.: se renegocian
presupuestos, se revisan calendarios, se renegocian los acuerdos con las
partes interesadas)? quedan evidencias de las acciones anteriores?

NO

(29) SP 3.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, email, etc.?

NO

154

Figura A.2. Respuestas de las prcticas especificas del rea de procesos de PP.

rea de Planificacin de Proyectos PMC

SI/NO
(1) SP 1.1: Existen informes del estado del proyecto que recojan los
valores actuales VS planificados respecto al calendario?

NO

valores actuales VS planificados respecto a los costes y el esfuerzo?

NO

valores actuales VS planificados de los atributos de los work products y
las tareas?

NO

valores esperados VS planificados respecto a los recursos utilizados?

NO

valores actuales VS planificados respecto a los conocimientos del
personal?

NO

(6) SP 1.1: Se documentan las desviaciones significativas de
parmetros analizados?

NO

(7) SP 1.2: Se identifican y documentan los compromisos no
satisfechos (o que corren riesgo de no ser satisfechos)?

NO

(8) SP 1.2: Se documentan los resultados de las revisiones realizadas? SI

(9) SP 1.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 (p.ej.: pueden surgir nuevos riesgos, desaparecer
otros, cambiar la probabilidad o impacto de un riesgo segn cambian las
circunstancias del proyecto)?

NO

(10) SP 1.3: De existir riesgos se comunican a las partes interesadas? SI

155

(11) SP 1.4: En caso de datos sensibles (p.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?

NO

(12) SP 1.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 esta cumpliendo?

NO

(13) SP 1.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?

SI

(14) SP 1.7: Se revisan peridicamente los logros y resultados de
ciertos hitos seleccionados, identificando posibles problemas contra el
plan definido? se documenta el resultado?

SI

(15) SP 2.1: Se lleva un registro de los problemas mas 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.)?

SI

(16) SP 2.1: Se documentan el anlisis y las razones por las que el
problema requiere o no accin correctiva?

NO

(17) SP 2.2: Se determinan y registran las acciones correctivas (p.ej.:
renegociar calendarios, aadir recursos) destinadas a resolver el
problema?

NO

(18) SP 2.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 procesos, etc.)?

NO

para el seguimiento y control de proyecto? la utilizan los proyecto?

SI

Figura A.3. Respuestas de las prcticas especificas del rea de procesos de PMC.

156
rea de Medicin y Anlisis MA

SI/NO
(1) SP 1.1: La direccin establece peridicamente cuales son los
objetivos estratgicos de la organizacin? (p.ej.: aumentar rentabilidad,
aumentar satisfaccin del cliente, aumentar calidad de producto, etc.)

NO

(2) SP 1.1: Se priorizan las necesidades de informacin u objetivos
segn su importancia y siempre ajustndolo a los limites posibles?

NO

(3) SP 1.1: Se definen y documentan objetivos operativos de medicin
para la unidad de desarrollo alineados a los objetivos estratgicos de la
organizacin? (p.ej.: objetivo estratgico - aumentar satisfaccin del
cliente, objetivo operativo para la unidad de desarrollo reducir errores
en produccin)

NO

(4) SP 1.1: Se dispone una trazabilidad entre las necesidades de
informacin y los objetivos?

NO

(5) SP 1.1: Se revisan peridicamente los indicadores y se actualizan en
caso necesario?

NO

(6) SP 1.2: Existe una definicin operativa clara y sin ambigedades
para cada indicador? (p.ej.: descripcin del indicador, formula, unidades
de medicin, etc.)

NO

(7) SP 1.2: Se identifican medidas candidatas basadas en los objetivos y
se clasifican?

NO

(8) SP 1.2: Se identifican medidas ya existentes que se ocupen ya de los
objetivos en el proyecto o en otros de la organizacin?

NO

(9) SP 1.3: Se identifican las fuentes existentes de datos que se generan
en la labor actual?

NO

(10) SP 1.3: Se identifican las medidas que son necesarias pero que no
estn disponibles an?

NO

(11) SP 1.3: Los procedimientos de recogida y almacenamiento de los
indicadores son estndar para todos los proyectos?

NO

157

(12) SP 1.3: Para cada indicador, se ha especificado como calcular la
medida, la frecuencia de clculo, quien es el responsable de tomar la
medida y donde se ha de guardar su resultado? (p.ej.: de dnde obtener
los datos de entrada al indicador, forma de clculo, posibles
procedimientos y herramientas para su obtencin)

NO

(13) SP 1.3: Existen herramientas que ayuden a la recogida y calculo
automtico de los indicadores?

NO

(14) SP 1.3: Existen procesos, procedimientos, planillas, herramientas
para medicin y anlisis? la utilizan los proyectos?

NO

(15) SP 1.3: Se revisan y actualizan los procesos de recogida de datos
para una posible mejora?

NO

(16) SP 1.3: Se valoran las medidas segn su esfuerzo en obtenerlas o
su importancia y se actualizan?

NO

(17) SP 1.4: Se especifica el procedimiento de anlisis y los informe
que se prepararan?

NO

(18) SP 1.4: Se analizan los datos de acuerdo al procedimiento de
anlisis definido (responsable de anlisis, forma de anlisis, frecuencia)?

NO

(19) SP 1.4: Para cada indicador, Se ha especificado quien y a quienes
se han de comunicar los resultados de la medida?

NO

(20) SP 1.4: Se revisan los contenidos y formatos de los anlisis e
informes para una posible actualizacin?

NO

(21) SP 1.4: Se especifican los criterios para evaluar la utilidad de los
anlisis?

NO

(22) SP 2.1: Se realizan controles de integridad de los datos los ms
cercano posible a la fuente?

NO

(23) SP 2.2: Se interpretan los resultados de los datos y se sacan
conclusiones?

NO

(24) SP 2.2: Se realizan mediciones adicionales si son necesarias para
la presentacin de los resultados?

NO

158
(25) SP 2.2: Antes de una presentacin ms amplia, Se examinan los
datos junto con las personas interesadas de las mediciones?

NO

(26) SP 2.2: Se perfeccionan los criterios para la validez de las
necesidades de informacin y de los objetivos?

NO

(27) SP 2.2: En caso de identificar desviaciones significativas durante la
medicin y anlisis se emprenden acciones para solucionar la causa de
la desviacin?

NO

(28) SP 2.3: Se examinan los datos histricos para asegurar su
integridad, exactitud y extensin?

NO

(29) SP 2.3: Se asegura la seguridad sobre el acceso a los datos (uso
exclusivo de algn grupo o personal, uso indebido)?

SI

(30) SP 2.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?

NO

(31) SP 2.5: Se ayuda a las partes interesadas de las mediciones y
anlisis, a su comprensin?

NO
Figura A.4. Respuestas de las prcticas especificas del rea de procesos de MA.

rea de Gestin de Acuerdos con Proveedores SAM

SI/NO
(1) SP 1.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 adquisicin
posibles para los proyectos? (p.ej.: HW, SW: COTS, diseos grficos,
mdulos, entre otros).

NO

(2) SP 1.2: Existe una lista de proveedores homologados de los que
realizar adquisiciones?

NO

(3) SP 1.2: Existen criterios que determinen que proveedores
seleccionar?

NO

159

(4) SP 1.2: Se evala el riesgo de seleccionar uno u otro proveedor? se
incluye ese riesgo en la seleccin de riesgos del plan de proyecto?

NO

(5) SP 1.3: Se especifica claramente en el contrato los requisitos que
el/los work products deben contener?

SI

(6) SP 1.3: Se especifica en el contrato un plan de seguimiento sobre el
proveedor? (p.ej.: informes de progreso, reuniones de seguimiento, etc)

NO

(7) SP 1.3: Se identifica quienes sern los responsables de posibles
cambios en el contrato y como sern comunicados?

NO

(8) SP 1.3: Se identifican las responsabilidades del proveedor con
respecto a sus productos y su mantenimiento?

SI

(9) SP 1.3: Se revisa nuestro plan de proyecto para alinearlo con el del
proveedor?

NO

(10) SP 1.3: Se da seguimiento formal al progreso del proveedor para
ver si se ajusta a lo planificado?

NO

(11) SP 1.3: Se reflejan los posibles cambios en el proceso o en los
productos del proveedor?

NO

(12) SP 2.1: Se realizan revisiones tcnicas de seguimiento? NO

(13) SP 2.1: Se da seguimiento y analizan los procesos del proveedor
para ver si se ajustan a los requisitos del acuerdo establecido?

NO

(14) SP 2.2: Se monitorizan algunos procesos claves del proveedor para
ver su rendimiento a fin de detectar posibles problemas que puedan
afectar a cumplir los requisitos del acuerdo?

NO

(15) SP 2.2: Se toman acciones correctivas ante los desvos en los
procesos?

NO

(16) SP 2.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?

NO

(17) SP 2.3: Se toman acciones correctivas para solucionar las
deficiencias?

SI

160

(18) SP 2.4: Se han establecido criterios, test y procedimientos para la
aceptacin del producto?

NO

(19) SP 2.4: Se verifica que el producto cumple los requisitos para la
aceptacin?

SI

(20) SP 2.4: Se documentan los resultados de los test de aceptacin? NO

(21) SP 2.4: Se ha establecido un plan de accin con el proveedor para
cualquier work product que no pasa las pruebas de aceptacin?

NO

(22) SP 2.4: Se asegura que se reciben todos los productos de trabajo
especificados en el acuerdo de servicio?

SI

(23) SP 2.5: Se ha planificado la transicin/integracin del producto del
proveedor en nuestro desarrollo?

SI

(24) SP 2.5: Se asegura que se imparte la apropiada formacin para
aquellos involucrados en la recepcin, almacenamiento, uso y
mantenimiento de los productos adquiridos?

SI

para la gestin de acuerdos con proveedores? la utilizan los proyectos?

NO

Figura A.5. Respuestas de las prcticas especificas del rea de procesos de SAM.

Nombre del evaluado: Soluciones Informtica Manzanares
rea de Gestin de Configuracin CM

SI/NO
(1) SP 1.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 las descripciones
de proceso, requisitos, manuales, interfaces, cdigos fuente, etc.

NO

(2) SP 1.1: Se le asignan identificadores nicos a las entidades para la
gestin de configuracin?

NO

161
(3) SP 1.1: Se especifican caractersticas importantes de las entidades
para la gestin de configuracin, como por ejemplo el autor, lenguaje de
programacin, nombre del archivo, etc.?

NO

(4) SP 1.1: Se identifica y documenta cuando cada entidad de
configuracin estar bajo la gestin de configuracin?

NO

(5) SP 1.1: Se identifica el responsable de la configuracin de cada
entidad?

NO

(6) SP 1.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 mas complejos con la
participacin del cliente

SI

(7) SP 1.2: Existe un sistema de control de versiones para controlar los
work products bajo la gestin de configuracin?

NO

(8) SP 1.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?

NO

(9) SP 1.2: Cuando se guarda una versin es posible etiquetarla
describiendo exactamente que contiene?, es decir, es posible saber que
cambios, que funciones concretas incluye una versin de una fecha
concreta?

NO

(10) SP 1.2: Se dispone de un sistema para registrar las peticiones de
cambio a los work products bajo la gestin de configuracin?

NO

(11) SP 1.2: Se ha establecido un sistema de copias de seguridad y
recuperacin para preservar el contenido del sistema de gestin de
configuracin?

NO

(12) SP 1.3: Se han identificado y documentado los productos de
trabajo que conformaran cada lnea base? aclaracin: en la 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.

NO

162
(13) SP 1.3: Esta definido claramente quien esta autorizado para
crear/liberar una lnea base?

NO

(14) SP 1.3: El conjunto de las lneas base son de fcil acceso? NO

(15) SP 2.1: Existe algn procedimiento escrito que establezca como se
gestionan las peticiones de cambio?

NO

(16) SP 2.1: El registro de las peticiones de cambio incluyen campos
que permiten la adecuada gestin de las mismas (p.ej.: estado de la
peticin, productos afectados, esfuerzo estimado, responsable asignado,
etc.)?

NO

(17) SP 2.1: Se realiza un adecuado seguimiento del estado de las
peticiones de cambio hasta su cierre?

NO

(18) SP 2.1: Se analiza el impacto de los cambios y las correcciones al
proyecto?

SI

(19) SP 2.1: Se examinan las solicitudes de cambio que se abordaran en
la siguiente lnea base, obteniendo un acuerdo entre las partes
implicadas y justificando toda decisin?

NO

(20) SP 2.2: Se tiene un control de los elementos de configuracin
durante toda la vida til del producto?

NO

(21) SP 2.2: Antes de cambiar una configuracin se obtiene la
autorizacin de la persona apropiada?

NO

Figura A.6. Respuestas de las prcticas especificas del rea de procesos de CM.

rea de Aseguramiento de la Calidad de Productos y Procesos PPQA

SI/NO
(1) SP 1.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?

NO

163

(2) SP 1.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)?

NO

(3) SP 1.2: Se registran las no conformidades de las auditorias a
procesos de forma que puedan ser gestionadas y se les pueda dar
seguimiento?

NO

(4) SP 1.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?

NO

(5) SP 1.2: Se 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)?

NO

(6) SP 1.2: Se registran las no conformidades de las auditorias a work
products de forma que puedan ser gestionadas y se les pueda dar
seguimiento?

NO

(7) SP 1.2: Se han prefijado unos puntos (calendario) a lo largo de la
vida (fases ms crticas, hitos, entregas al cliente, etc.) del proyecto en
los que auditar los productos de trabajo?

NO

(8) SP 1.2: Se determinan y registran acciones correctivas destinadas a
resolver las no conformidades?

NO

(9) SP 2.1: Se da un seguimiento apropiado (p.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?

NO

(10) SP 2.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?

NO

(11) SP 2.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?

NO

164
(12) SP 2.2: Se desarrollan informes de auditoria que reflejen el
resultado de las revisiones de aseguramiento de la calidad en los
proyectos: n de no-conformidades detectadas por proceso, n de no-
conformidades abiertas, cerradas, etc.?

NO

para el aseguramiento de la calidad de los procesos y productos? la
utilizan los proyectos?

NO

Figura A.7. Respuestas de las prcticas especificas del rea de procesos de PPQA.

Nombre de la evaluacin: Prcticas Genricas
SI/NO
(1) GP 2.1: Se definen de antemano las expectativas de la organizacin
en todos los procesos y se hacen visibles a los involucrados?

NO

(2) GP 2.2: Se define un plan para los procesos con la descripcin del
proceso; normas y requisitos para los trabajos y servicios del proceso;
objetivos especficos para la realizacin del proceso; dependencias entre
trabajos, servicios y recursos; recursos necesarios; asignacin de
responsabilidades, formacin necesaria; productos del trabajo y su nivel
de control; mtricas para proporcionar detalles sobre el rendimiento del
proceso; participacin de los interesados; actividades de supervisin del
proceso; revisin de objetivos de las actividades del proceso; evaluacin
de la gestin de las actividades del proceso y los work products?

SI

(3) GP 2.3: Se dispone de los recursos necesarios (financiacin,
herramientas, personal, etc.) para realizar los procesos cuando se
necesitan?

SI

(4) GP 2.4: Se asignan para cada proceso responsables para realizar el
proceso y que archiven los resultados especficos? esto se guardara o
bien con una descripcin detallada de los puestos de trabajo o bien en un
documento vivo como el plan de proceso.

SI

(5) GP 2.4: Se asignan responsables generales para los procesos y
responsables para cosas especificas del proceso adems de que todos
ellos lo entienden y lo aceptan?

SI

165

(6) GP 2.5: Se da una formacin adecuada a las personas que realizan
el proceso?

NO

(7) GP 2.5: Se da una formacin por encima a las personas que
interactan con el proceso?

SI

(8) GP 2.6: Se tiene un control de versiones con los cambios realizados
de los productos del proceso?

NO

(9) GP 2.7: Se identifican los participantes de un proceso? SI

(10) GP 2.8: Se supervisan los procesos midiendo los atributos
adecuados y midiendo el rendimiento real comparndolo con el plan?

SI

(11) GP 2.8: Se identifican y evalan las desviaciones del plan? NO

(12) GP 2.8: Se toman medidas para corregir los problemas del plan o
las desviaciones del plan mediante correcciones del plan, aumento de
recursos, negociacin de compromisos, aumentar el esfuerzo?

NO

(13) GP 2.9: Se evala el cumplimiento del proceso por personal
interno de la empresa pero ajeno al proceso o proyecto, o bien por
personal externo a la empresa?

SI

(14) GP 2.10: Se realizan valoraciones de los procesos para los altos
cargos segn sus necesidades para que le ayuden a la hora de tomar
decisiones?

NO

Figura A.8. Respuestas de las prcticas genricas.

166

ANEXOS

167
NDICE
Pg.
Anexo A. Formato para la documentacin de las fuentes de requisitos ........................ 168
Anexo B. Documento de compromiso de las partes interesadas ................................... 169
Anexo C. Planilla de gestin de cambios de requisitos ................................................. 170
Anexo D. Plantilla para la ERS ..................................................................................... 171
Anexo E. Planilla para especificacin de inconsistencias de requisitos ........................ 173
Anexo F. Matriz de requerimientos ............................................................................... 174
Anexo G. Matriz para la especificacin de riesgos ....................................................... 175
Anexo H. Compromiso con los riesgos ......................................................................... 176
Anexo I. Minuta de acuerdos y compromisos ............................................................... 177
Anexo J. Informe de no conformidad ............................................................................ 178

168
Anexo A. Formato para la documentacin de las fuentes de requisitos.

Figura A.1. Identificacin de los interesados. Tomado de la planilla del perfil de los
interesados del proyecto (Pinzn y Flrez, 2010).

Figura A.2. Perfil de los interesados. Tomado de la planilla de identificacin de las
personas que interactan en el proyecto (Pinzn y Flrez, 2010).

169
Anexo B. Documento de compromiso de las partes interesadas.
Figura B.1. Planilla de acuerdo de las partes (Pinzn y Flrez, 2010).

170
Anexo C. Planilla de gestin de cambios de requisitos.
Figura C.1. Planilla de identificacin de las personas que interactan en el proyecto
(Pinzn y Flrez, 2010).

171
Anexo D. Plantilla para la ERS.

1. Introduccin
1.1. Objetivo
1.1.1. Propsito del documento
1.1.2. Audiencia a la que va dirigido
1.2. Alcance
1.2.1. Identificacin del producto mediante un nombre
1.2.2. Qu hace y no hace el producto
1.2.3. Aplicaciones del software: beneficios, objetivos y metas
1.3. Definiciones, acrnimos y abreviaturas
1.4. Referencias
1.5. Visin general
1.5.1. Descripcin del contenido del resto del documento
1.5.2 Organizacin del documento

2. Descripcin general
2.1. Perspectiva del producto
2.1.1. Indicar si es un producto independiente o parte de un sistema mayor
2.1.2. Interfaces de sistema
2.1.3. Limitaciones de memoria
2.1.4. Operaciones
2.1.4.1. Modos de operacin de los distintos grupos de usuarios
2.1.4.2. Periodos de operaciones interactivas y automticas
2.1.4.3. Funciones respaldo del procesamiento de datos
2.1.4.4. Operaciones de backup y recuperacin
2.1.5. Requerimientos para adaptarse a la ubicacin
2.1.5.1. Indicar cualquier dato o secuencia de inicializacin especfico de
cualquier lugar, modo de operacin.
2.1.5.2. Caractersticas que deben ser modificadas para una instalacin en
particular.
2.2. Funciones del producto
2.3. Caractersticas de usuario
2.4. Restricciones
2.5. Suposiciones y dependencias
2.6. Requisitos para futuras versiones del sistema

3. Requisitos especficos
3.1. Requisitos de interfaz externo
3.1.1. Interfaces de usuario
3.1.2. Interfaces hardware
3.1.3. Interfaces software
3.1.4. Interfaces de comunicaciones
3.2. Requisitos funcionales

172
3.2.1. Flujos de informacin
3.2.2. Descripcin de procesos
3.2.3. Diccionario de datos
3.3. Requisitos de rendimiento
3.4. Restricciones de diseo
3.5. Atributos de sistemas software
3.6. Otros requisitos

173
Anexo E. Planilla para especificacin de inconsistencias de requisitos.

Figura E.1. Planilla para la especificacin de inconsistencias de requisitos.

174

Anexo F. Matriz de requerimientos.

Figura F.1. Planilla de matriz de requerimientos.

ID Requerimiento Descripcin Resultado Esperado Caso de Uso Relacionado Prioridad Riesgo Tipo Relacin

175

Anexo G. Matriz para la especificacin de riesgos.

Figura G.1. Planilla de matriz para especificacin de riesgos.

199
Anexo H. Compromiso con los riesgos.

Figura H.1. Planilla de matriz de compromiso de riesgos.

177
Anexo I. Minuta de acuerdos y compromisos.

Tema:
Fecha de reunin: Hora de inicio: Hora fin:
Nombre Cargo Asiste

Punto Temas tratados
<<N>> <<Detalle de los temas tratados>>
Punto Acuerdos
<<N>> <<Detalle de los acuerdos>>
Compromisos
Que Quien Cuando Estado Detalles Nombre Fecha

Figura I.1. Planilla para la minuta de reunin.

178
Anexo J. Informe de no conformidad.

Figura J.1. Planilla de informe de no conformidad.

179

HOJA DE METADATOS

180
Hoja de Metadatos para Tesis y Trabajos de Ascenso 1/6

Ttulo
Mejora de procesos de desarrollo de software en incubados TIC de la
Corporacin Parque Tecnolgico de Oriente tomando como
referencia el modelo CMMI
Subttulo

Autor(es)
Apellidos y Nombres Cdigo CVLAC / e-mail
Daz Herrera, Eliana del
Carmen.
CVLAC 19.762.780
e-mail jelianad@hotmail.com
e-mail jelianad@gmail.com

Palabras o frases claves:

181

Lneas y sublneas de investigacin:

rea Subrea
CIENCIAS Informtica

Resumen (abstract):

Se desarroll una propuesta de Procesos de Mejora de Software (SPI) para elevar los
procesos de desarrollo que realizan las empresas de Tecnologas de la Informacin y la
Comunicacin (TIC) incubadas en la Corporacin Parque Tecnolgico de Oriente. El
diseo de esta propuesta permitir en este caso a los incubados TIC de Soluciones
Informticas Manzanares C.A. determinar cules son los procesos en el desarrollo de
software en los que se encuentran deficientes segn el Modelo Integrado de Madurez y
Capacidad (CMMI), posteriormente fueron planteadas mejoras que les permitirn
alcanzar en un futuro un nivel de madurez dos (2) que garantice la planificacin y el
cumplimiento de los procesos que establezca la organizacin. Se tom el modelo IDEAL
como gua proponer los cambios en la empresa, por otra parte se plante como modelo
de referencia para evaluar y determinar las mejoras a realizar el modelo CMMI para el
desarrollo versin 1.2 (Chrisis y cols., 2009). Durante el desarrollo de la propuesta
fueron evaluadas las siete (7) reas de proceso establecidas en CMMI para alcanzar un
nivel de madurez dos (2), mediante la aplicacin de las listas de verificacin tomadas de
(Sanz, 2009) titulado Implantacin de CMMI en Pequeas Empresas de Desarrollo de
Software, luego se determinaron qu prcticas se encuentran deficientes en la
organizacin y en base a esto se propusieron las mejoras a implementar para alcanzar el
nivel propuesto. Las evaluaciones y las mejoras propuestas en este trabajo pueden ser
ejecutadas en cualquier empresa pequea de desarrollo de software que desee alcanzar
un nivel de madurez dos (2) segn el modelo CMMI.

182

Contribuidores:

Apellidos y Nombres ROL / Cdigo CVLAC / e-mail
Joyce Urbina
ROL

CA AS X TU JU

CVLAC
e-mail @hotmail.com
e-mail @gmail.com
Ramn Gorrin
ROL

CA AS X TU JU

CVLAC
e-mail @hotmail.com
e-mail @gmail.com

ROL

CA AS TU JU X

CVLAC
e-mail @hotmail.com
e-mail @gmail.com

ROL

CA AS TU JU X

CVLAC

183
e-mail @hotmail.com
e-mail @gmail.com

Fecha de discusin y aprobacin:

Ao Mes Da
2014

Lenguaje: Espaol__

184

Archivo(s):

Nombre de archivo Tipo MIME
Tesis_Eliana_Diaz.doc Aplication/Word

Alcance:

Espacial: __________Universal______________(Opcional)

Temporal: ________Intemporal______________(Opcional)

Titulo o Grado asociado con el trabajo:

Licenciado en Informtica_______________________________________________

Nivel Asociado con el Trabajo:

Licenciado___________________________________________________________

rea de Estudio:

185

_______________________________

Institucin(es) que garantiza(n) el Titulo de grado:

____________________________________________________________________
_______________________________________________________________________
_________________________________________________________________

UNIVERSIDAD DE ORIENTE (UDO)

186

187

Derechos:

Artculo 41 del REGLAMENTO DE TRABAJO DE PREGRADO (vigente a partir
del II Semestre 2009, segn comunicacin CU-034-2009): los Trabajos de Grado
son de la exclusiva propiedad de la Universidad de Oriente, y slo podrn ser utilizados
para otros fines con el consentimiento del Consejo de Ncleo respectivo, quien deber
participarlo previamente al Consejo Universitario para su autorizacin.

______________________
Autor

______________________ ______________________
ASESOR INSTITUCIONAL ASESOR ACADMICO

Tesis Eliana (1.5) Con Formato PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Eliana (1.5) Con Formato PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE ORIENTE

También podría gustarte