Análisis y diseño de un modelo con integración de una ...
Transcript of Análisis y diseño de un modelo con integración de una ...
Análisis y diseño de un modelo con integración de una metodología ágil
en el nivel 2 de CMMI
HERNANDO RODRÍGUEZ GONZÁLEZ
Universidad Nacional de Colombia
Facultad de Ingeniería
Maestría en Ingeniería – Telecomunicaciones
Bogotá, Colombia
2017
Análisis y diseño de un modelo con integración de una metodología ágil
en el nivel 2 de CMMI
HERNANDO RODRÍGUEZ GONZÁLEZ
TRABAJO FINAL DE MAESTRÍA
MAGÍSTER EN INGENIERÍA TELECOMUNICACIONES
DIRECTORA:
Ph.D., SONIA ESPERANZA MONROY VARELA
LÍNEA DE INVESTIGACIÓN:
GESTIÓN Y GERENCIA DE TELECOMUNICACIONES
UNIVERSIDAD NACIONAL DE COLOMBIA
FACULTAD DE INGENIERÍA
MAESTRÍA EN INGENIERÍA – TELECOMUNICACIONES
BOGOTÁ, COLOMBIA
2017
Agradecimientos
Agradezco a mis padres por inspirar la disciplina, pasión y persistencia en realizar cada
una de mis actividades.
Agradezco a mi asesora del trabajo de maestría, Profesora Sonia Esperanza Monroy
Varela, Directora Instituto de Extensión e Investigación, por su valiosa orientación en
elaborar un trabajo que concierna en el desarrollo de sociedad.
Agradezco a los Profesores y a cada una de las personas que aportaron en la construcción
de este documento.
Por último, agradezco a las empresas que facilitaron la realización de esta investigación.
Resumen
La implementación de metodologías tradicionales por las empresas desarrolladoras de
software en Colombia ha mostrado inconvenientes en la comprensión de las necesidades
del cliente, tiempos largos de entrega, baja eficiencia y altos precios. En consecuencia, los
productos en muchas ocasiones no son de la entera satisfacción del cliente y se llega
incluso a procesos legales y en algunos casos al cierre de las empresas desarrolladoras
de software implicadas. A nivel país esto se evidencia como una baja competitividad de las
empresas desarrolladoras de software. En este contexto se planteó un modelo híbrido que
se nutre de la definición de las áreas estratégicas y procesos de madurez provistas por el
modelo CMMI DEV (Capability Maturity Model Integration for development) y las
estrategias de aplicación específicas provistas por la metodología de desarrollo de
software ágil Scrum. El modelo fue propuesto siguiendo las necesidades específicas de la
empresa CLTech, que fue elegida entre 28 compañías evaluadas en una fase preliminar.
Esta empresa contaba con un nivel de acreditación 2 en la escala CMMI, lo que provee
una apertura por parte de la empresa a metodologías nuevas y a su vez un estado
intermedio en la complejidad de los proyectos desarrollados. El modelo planteado requiere
de un experto en el funcionamiento del modelo capaz de articular a los diferentes grupos
de trabajo de la organización al igual que su entrenamiento. Además, plantea el desarrollo
de los proyectos de una manera modular o por bloques que son evaluados periódicamente
por los clientes, lo cual permite alta flexibilidad y pertinencia con los productos
desarrollados.
.
Palabras clave: Requerimientos, Metodologías ágiles, Desarrollo de Software, CMMI-
DEV, Tecnologías de la Información, Scrum, artefactos.
X Análisis y diseño de un modelo con integración de una metodología ágil en el
nivel 2 de CMMI
Abstract
Application of traditional strategies by the software development companies in Colombia
historically showed poor comprehension of client needs, long delivery times, low efficiency
and high prices. As a consequence the software products don’t match the client
expectations to the point that even legal processes are initiated. As a consequence, some
of the companies enter in bankrupt and the competitively of the software development
companies in the country is very low. In this context a hybrid model that takes advantages
of the CMMI DEV (Capability Maturity Model Integration for development) and the Scrum
methodology was proposed. The CMMI DEV model deals with the definition of the process
and main strategies (The what), while the Scrum methodology establishes specific modes
of implementation (The how). The model was proposed based on the specific needs of the
company CL Tech, which was chosen among 28 evaluated companies. CLTech was
certified with the level 2 of the CMMI scale, which implies that the company is opened to
the implementation of new methodologies of work and is already familiar with the CMMI
DEV model. In addition, this company manages projects of intermediate complexity and
stays in a transition state between a small company and a big company. The proposed
model requires of an expert (product owner) capable of the articulation and training of the
different teams in the organization. It also proposes the development of the project in
blocks that can be evaluated by the client periodically. Such a model allows high flexibility
and relevance in the process and the final product, which translates into the client
satisfaction.
Keywords: Requirements, agile methodologies, software development, CMMI-DEV,
information technology, Scrum, artifacts.
Contenido XI
Contenido
1. Antecedentes .......................................................................................................... 21 1.1 Elementos para mejorar la calidad de desarrollo de software ........................... 25
1.1.1 Alcanzar la satisfacción del cliente................................................................. 25 1.1.2 Reducir ciclos. ............................................................................................... 25 1.1.3 “Alcanzar el “lanzamiento al mercado” ........................................................... 25 1.1.4 Mejorar la gestión de requerimientos funcionales y no funcionales ................ 26 1.1.5 Implementar procesos de calidad para mejorar la verificación del producto con el cliente ................................................................................................................... 26
2. Marco Conceptual .................................................................................................. 27 2.1 Ingeniería de Software ..................................................................................... 28
2.1.1 Compromiso con la calidad ............................................................................ 28 2.1.2 Proceso ......................................................................................................... 29
Comunicación ............................................................................................... 29 Planeación .................................................................................................... 29 Modelado ...................................................................................................... 30 Construcción ................................................................................................. 30 Despliegue .................................................................................................... 30
2.1.3 Métodos ......................................................................................................... 31 2.1.4 Herramientas. ................................................................................................ 31
2.2 Metodologías para desarrollo de software ........................................................ 32 2.2.1 Modelos de proceso prescriptivo ................................................................... 32
Modelo Lineal en Escala ............................................................................... 33 Modelos de Proceso Incremental .................................................................. 35 Modelos de Proceso Evolutivo ...................................................................... 35 Modelo prototipo ........................................................................................... 36 Modelo en espiral ......................................................................................... 37 Modelos concurrentes................................................................................... 38
2.2.2 Modelos de proceso especializado ................................................................ 39 Desarrollo basado en componentes (COTS) ................................................ 39 Modelo de método formales.......................................................................... 40 Desarrollo orientado a aspectos (DSOA - aspect-oriented programming (POA)) ................................................................................................................. 40
2.2.3 Proceso Unificado (PU) ................................................................................. 40 2.2.4 Modelos del Proceso Personal y del Equipo .................................................. 41 2.2.5 Modelos ágiles ............................................................................................... 41
Proceso ágil .................................................................................................. 42
XII Análisis y diseño de un modelo con integración de una metodología ágil en el
nivel 2 de CMMI
Manifiesto ágil ............................................................................................... 43 Principios del manifiesto ágil ......................................................................... 44
2.2.6 Metodologías Ágiles ...................................................................................... 45 Extreme Programming (XP)........................................................................... 48 Adaptative Software Development (ASD) ...................................................... 49 Dynamic Solutions Delivery Model (DSDM) ................................................... 50 Cristal Methods (CM)..................................................................................... 51 Modelo ISO/ IEC 15504 (SPICE) ................................................................... 52 Modelo IT-MARK ........................................................................................... 53 ISO 9001:2000 .............................................................................................. 54 COBIT 5 - Control Objectives for Information and related Technology ........... 55 SCRUM ......................................................................................................... 56
Pilares de Scrum ................................................................................ 57 Valores de Scrum ............................................................................... 57
2.3 Características entre modelos de TI ................................................................. 58 2.4 Características de metodologías ágiles y metodologías tradicionales ............... 60 2.5 CMMI-DEV Capability Maturity Model Integration ............................................. 62 2.6 Áreas de proceso .............................................................................................. 62
2.6.1 Nivel 2 Gestionado ........................................................................................ 63 2.7 Interpretando CMMI-DEV al utilizar enfoques ágiles ......................................... 63
3. Objetivos. ............................................................................................................... 65 3.1 Objetivo General ............................................................................................... 65 3.2 Objetivo Específicos ......................................................................................... 65
4. Metodología ............................................................................................................ 67 4.1 Caracterización de empresas de tecnología en Colombia ................................. 67
4.1.1 Empresas colombianas de Tecnología por regiones ..................................... 68 4.1.2 Tamaño de Empresas colombianas por Ventas ............................................ 69 4.1.3 Productos y Servicios de Tecnología de Empresas colombianas .................. 69 4.1.4 Adopción de modelos de calidad en empresas de tecnología colombianas ... 70
4.2 Clasificación de Empresas Colombianas y la implementación de metodologías ágiles 71 4.3 Caracterización de los Actores.......................................................................... 71
4.3.1 Población del estudio .................................................................................... 71 4.3.2 Actividades Económicas Escogidas .............................................................. 73 4.3.3 Clasificación de las empresas por Actividades Económicas .......................... 73 4.3.4 Participación porcentual de las Actividades Económicas que desarrollan las empresas de TI colombianas ................................................................................... 75 4.3.5 Implementación de modelos de metodologías ágiles..................................... 77 4.3.6 Empresas con valoración CMMI Dev V1.3 por SCAMPI (SAS) ..................... 79
5. RESULTADOS ........................................................................................................ 85 5.1 Empresa de desarrollo de software con valoración en procesos en gestión nivel 2 CMMI-DEV. .............................................................................................................. 86
5.1.1 Evaluación del recurso humano .................................................................... 88 5.1.2 Recurso humano requerido para implementar CMMI-DEV. ........................... 89
5.2 Metodologías ágiles .......................................................................................... 90 5.3 Integración de CMMI-DEV con Scrum .............................................................. 94
Contenido XIII
5.3.1 Fases determinadas en el modelo para lograr la integración de CMMI-DEV y SCRUM .................................................................................................................... 94
Planificación del proyecto: ............................................................................ 94 Gestión de Requerimientos:.......................................................................... 94 Gestión de Riesgos: ..................................................................................... 95 Monitorización y control del proyecto: ........................................................... 95 Gestión de la configuración:.......................................................................... 96 ........................................................................................................................... 96 Medición y Análisis: ...................................................................................... 96 Verificación: .................................................................................................. 97
5.3.2 Roles para la implementación CMMI-DEV y Scrum ....................................... 99 Líder de proyecto .......................................................................................... 99 Administrador de planificación ...................................................................... 99 Administrador de configuración ..................................................................... 99 Administrador de calidad .............................................................................100 Administrador de desarrollo .........................................................................100
5.4 Modelamiento ágil ...........................................................................................100 5.5 Mapa conceptual .............................................................................................101
5.5.1 Descripción del Modelo ................................................................................ 103 ROLES ........................................................................................................105
Stakeholders ..................................................................................... 105 Product Owner .................................................................................. 106 ScrumMaster ..................................................................................... 110 Development Team ........................................................................... 113
ÁREAS DE PROCESO ................................................................................116 Gestión de Requerimientos (REQM) ................................................. 116 Planificación del Proyecto (PP) ......................................................... 119 Monitoreo y Control del Proyecto (PMC) ........................................... 121 Medición y Análisis (MA) ................................................................... 123 Aseguramiento de la Calidad de Productos y Procesos (PPQA) ....... 125 Gestión de la Configuración (CM) ..................................................... 127 Gestión de Acuerdos con Proveedores (SAM) .................................. 129
6. Conclusiones y recomendaciones ...................................................................... 131 6.1 Conclusiones ...................................................................................................131 6.2 Trabajos futuros ..............................................................................................132
7. REFERENCIAS...................................................................................................... 133
XI
V
Análisis y diseño de un modelo con integración de una metodología ágil en el
nivel 2 de CMMI
Lista de figuras
Figura 2-1 Capas de la Ingeniería de Software ............................................................... 28
Figura 2-2 Modelo Lineal – Flujo de Proceso .................................................................. 33
Figura 2-3 Modelo en Cascada ....................................................................................... 33
Figura 2-4 Modelo en V ................................................................................................... 34
Figura 2-5 Modelo iterativo e incremental – Flujo de proceso ......................................... 35
Figura 2-6 Modelo Evolutivo - Flujo de Proceso .............................................................. 36
Figura 2-7 Modelo inicial o prototipo ............................................................................... 37
Figura 2-8 Esquema del modelo de ciclo de vida en espiral ............................................ 38
Figura 2-9 Actividad de modelado ................................................................................... 39
Figura 2-10 Fases del PU ............................................................................................... 40
Figura 2-11 Proceso de software XP ............................................................................... 48
Figura 2-12 Modelo ASD ................................................................................................. 49
Figura 2-13 Proceso de desarrollo de DSDM .................................................................. 50
Figura 2-14 Estructura de la norma ISO 15504/IEC ........................................................ 53
Figura 2-15 Principios de COBIT 5 .................................................................................. 55
Figura 2-16 Pilares del Scrum ......................................................................................... 57
Figura 4-1 Participación de Empresas por Región .......................................................... 68
Figura 4-2 Tamaño de las empresas por ventas ............................................................. 69
Figura 4-3 Productos y Servicios de Tecnología ............................................................. 70
Figura 4-4 Porcentaje Participación Metodologías .......................................................... 71
Figura 4-5 Actividades Económicas por empresa ........................................................... 74
Figura 4-6 Clasificación por actividad económica ............................................................ 76
Figura 4-7 Tipos de certificaciones .................................................................................. 78
Figura 4-8 Empresas apoyadas por el convenio con certificación CMMI Dev v1.3 .......... 83
Contenido XV
Figura 5-1 Empresas por ejecutor .................................................................................. 89
Figura 5-2 Modelo de procesos de SCRUM ................................................................... 93
Figura 5-3 Planificación de proyecto CMMI-DEV ............................................................ 94
Figura 5-4 Gestión de riesgos CMMI-DEV y SCRUM ..................................................... 95
Figura 5-5 Gestión de riesgo CMMI-DEV y SCRUM ....................................................... 95
Figura 5-6 Monitorización y control del proyecto CMMI-DEV y SCRUM ......................... 96
Figura 5-7 Gestión de la configuración CMMI-DEV y SCRUM ........................................ 96
Figura 5-8 Medición y análisis CMMI-DEV y SCRUM ..................................................... 97
Figura 5-9 Verificación CMMI-DEV y Scrum ................................................................... 97
Figura 5-10 Mapa Conceptual integración CMMI-DEV NIVEL 2 Y SCRUM ...................101
Figura 5-11 Modelo de integración CMMI-DEV nivel 2 y SCRUM .................................104
Figura 5-12 Product Owner ...........................................................................................107
Figura 5-13 ScrumMaster ..............................................................................................111
Figura 5-14 Development Team ....................................................................................114
Figura 5-15 Gestión de Requerimientos REQM.............................................................118
Figura 5-16 Planificación del Proyecto (PP) ..................................................................120
Figura 5-17 Monitoreo y Control del Proyecto (PMC) ...................................................122
Figura 5-18 Medición y Análisis (MA) ...........................................................................124
Figura 5-19 Gestión de la Configuración (CM)...............................................................128
Figura 5-20 Gestión de Acuerdos con Proveedores (SAM) ...........................................130
Contenido XVI
Lista de tablas
Tabla 2-1 Metodologías ágiles de desarrollo ................................................................... 47
Tabla 2-2 Características de modelos de Gestión de TI .................................................. 59
Tabla 2-3 Características entre metodologías tradicionales y metodologías ágiles ......... 61
Tabla 4-1 Empresas Objeto del Estudio .......................................................................... 72
Tabla 4-2 Actividades Económicas ................................................................................. 73
Tabla 4-3 Certificación CMMI-DEV V1.3 Año 2014 ......................................................... 79
Tabla 4-4 Certificación CMMI-DEV V1.3 Año 2015 ......................................................... 80
Tabla 4-5 Certificación CMMI-DEV V1.3 Año 2016 ......................................................... 81
Tabla 4-6 Certificación CMMI-DEV V1.3 Año 2017 ......................................................... 82
Tabla 5-1 Empresa avalada por el SEI Nivel 2 ................................................................ 86
Tabla 5-2 Empresa avalada por el SEI Nivel 3 ................................................................ 87
Tabla 5-3 Factores de Evaluación de la empresa ........................................................... 88
Tabla 5-4 Relación de CMMI-DEV con SCRUM .............................................................. 98
Tabla 5-5 Gestión de Requerimientos (REQM) ............................................................. 117
Tabla 5-6 Planificación del Proyecto (PP) ..................................................................... 119
Tabla 5-7 Monitoreo y Control del Proyecto (PMC) ....................................................... 121
Tabla 5-8 Medición y Análisis MA ................................................................................. 123
Tabla 5-9 Aseguramiento de la Calidad de Productos y Procesos (PPQA) ................... 125
Tabla 5-10 Gestión de la Configuración (CM) ............................................................... 127
Tabla 5-11 Gestión de Acuerdos con Proveedores (SAM) ............................................ 129
Contenido 17
Lista de abreviaturas
AUP Agile Unified Process.
ASD Adaptive Software Development.
BPO Business Process Outsourcing.
BSP Business Systems Planning.
CASE Computer Assisted Software Engineering.
CMMI Capability Maturity Model Integration.
CMMI-DEV Capability Maturity Model Integration for Development.
DAD Distributed Agile Development.
DSDM Dynamic Systems Development Method.
FDD Feature-Driven Development.
FITI Fortalecimiento de la Industria de Tecnologías de la Información.
ITO Information Technology Outsourcing.
KPO Knowledge Process Outsourcing.
MinTIC Ministerio de Tecnologias Información y Comunicaciones
P-CMMI People Capability Maturity Model.
PPS Proceso Personal del software.
PRU o RUP Racional Unificado.
QIP Quality Improvement Paradigm.
RAD Application Development.
SSM Business Systems Planning
TDD Test-Driven Development.
UML Lenguaje de Modelado Unificado (UML).
XP Extreme Programming.
Introducción
Los orígenes de las metodologías ágiles surgieron en los años `90s, entre las cuales están
Extreme Programming (XP), Scrum, Software Craftmanship, Lean Software Development,
etc. Hoy en día son una alternativa válida para organizaciones que desarrollan software.
Estas metodologías han sido aprovechadas por desarrolladores de aplicaciones
informáticas y de software, debido a que pueden acoplar adecuadamente las
características especiales de este tipo.
Los modelos de madurez como CMMI-DEV, se centran en la mejora de los procesos que
aportan valor a la empresa consolidando sus productos, servicios y contribuyen en el
aseguramiento de la calidad en todos los niveles de la organización además de fortalecer
su recurso humano.
La gestión de procesos y procedimientos, el uso de metodologías de desarrollo de software
documentadas y estructuradas aportan valor porque disminuyen el tiempo de ejecución de
los proyectos de desarrollo. El uso de metodologías ágiles es indispensable en proyectos
de complejidad inherente en el dominio complejo como la gestión de proyectos de
innovación tan relevantes en nuestros entornos.(“Caracterización General del sector BPO,
KPO e ITO en Colombia,” 2013).
Se realizó una revisión de literatura, nacional e internacional que ilustra la evolución en el
correcto desarrollo de software dada su madurez en procesos, además se cuenta con
informes de las empresas contratantes que evalúan y acreditan el producto o servicio y
sus recursos invertidos, se realizaron entrevistas abiertas, con guía previamente elaborada
a actores claves que conocen de CMMI y Scrum.
Los resultados muestran que la implementación de un modelo de madurez es baja, por
todos los roles de expertos que participan y el costo asociado al proceso, pero es relevante
mencionar que Colombia es líder en la región en desarrollo de software acreditado a nivel
20 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
mundial por entidades como IT Mark y CMMI entre otros, por lo tanto los actores
recomiendan que el desarrollo de software desde su concepción se realice integrando un
modelo de madurez con metodologías ágiles y que, a su vez, tenga el componente de
proyectos inmerso con el fin de ser competitivo.
Este trabajo final de maestría se desarrolla de la siguiente manera: En el capítulo 1, se
describen los antecedentes, que comprenden las mejoras evolutivas en la construcción de
software; el Capítulo 2, se refiere al marco conceptual (importancia de los modelos y
metodologías); el Capítulo 3, contiene los Objetivos del estudio; el Capítulo 4, la
Metodología utilizada en el documento del trabajo; el Capítulo 5,se presentan los
Resultados; en el capítulo 6 se plantean las Conclusiones y Recomendaciones,
respectivamente. Así mismo, se incluyen las referencias.
1. Antecedentes
Durante el desarrollo de la humanidad, el hombre ha sido gestor y creador de soluciones
a los problemas, para ello ha encontrado herramientas que le facilitan la adaptación al
mundo cambiante y acelerado que se le presenta día a día, a su vez, él ha tenido que
enfrentar de nuevos retos ampliando su visión y adaptación.
Una de las herramientas utilizadas en los últimos años ha sido la utilización del software
en la creación de productos y servicios, siempre buscando mejoras, adaptando mejores
técnicas y habilidades, adoptando buenas prácticas que le conduzcan a su
aprovechamiento. En ese suceder ha aprovechado las ventajas, ha corregido errores, ha
fortalecido debilidades y ha contado con soluciones que le han permitido esa adaptación
a las necesidades actuales mejorando su entorno y haciendo más fácil su enfrentamiento
al diario vivir. El creciente desarrollo tecnológico y la fabricación de computadores han
impactado significativamente en el desarrollo del software y la utilización de nuevas
metodologías.
En la década de los años 60’s con las limitaciones de los mainframes, el código
desarrollado era limitado, corto pero eficiente para ese momento. La creación de nuevos
computadores exigía que el código creado fuera productivo optimizando la memoria de los
computadores. Se crearon los lenguajes de alto nivel que perduraron en el tiempo, sin
embargo, llegó a ser más costoso el mantenimiento del software que el costo del hardware.
Esta situación fue denominada como la “Crisis del software”, por científicos cómo Friedrich
L. Bauer 1y Edsger Wybe Dijkstra2.
1 Científico de la computación y profesor alemán. Nació el 10 de junio de 1924 y murió el 26 de marzo de 2015. 2 Científico holandés, pionero en áreas de investigación de la ciencia de la computación. Nació el 11 de mayo de 1930 y murió el 6 de agosto de 2002.
22 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Como resultado de abrir los ojos a la situación presente y constante se formularon varias
premisas como:
El coste del desarrollo inicial debe ser relativamente bajo.
El software debe ser fácil de mantener.
El software debe de ser portable a nuevo hardware.
El software debe hacer lo que el cliente quiere (Carvajal Riola, 2008, p.62).
Dijkstra estableció las bases de la programación estructurada la cual da inicio a la
formulación de metodologías de desarrollo de software, creando lo que hoy llamamos
ingeniería de software. (Carvajal Riola, 2008).
En la década de los años 70’s se formuló el ciclo de vida de desarrollo de un sistema de
software con la aparición del modelo en cascada o waterfall, el cual se hizo globalmente
utilizado ubicándolo dentro de las denominadas metodologías tradicionales; con la
utilización del modelo los desarrolladores imprimieron mejoras al modelo inicial, generando
nuevas metodologías.
Las corrientes que siguieron se enfocaron unas en mejorar el modelo de escala y otras en
crear otro tipo de modelo, se esbozaron los conceptos de modelos entidad relación,
normalización, diagramas de flujos de datos, diagramas estructurados y entidades de
ciclos de vida, surgieron las herramientas Computer Assisted Software Engineering
(CASE). Consideradas como mejoras del modelo de escala, especialmente del ciclo de
vida estas fueron: Merise, SSADM o Yourdon System Method(Carvajal Riola, 2008, p. 64).
Las metodologías que cambiaban completamente el esquema de cascada fueron
desarrolladas durante la década de los años 80’s, algunas de ellas fueron: Soft Systems
Methodologies (SSM), Business Systems Planning (BSP), ETHICS, Rapid Application
Development (RAD).
En la década de los años 90’s surgieron metodologías orientadas a objetos, involucrando
la relación desarrolladores y usuarios, el enfoque se basó en reutilización de código y los
objetos fueron considerados entidades del mundo real(Carvajal Riola, 2008, p. 65).
Antecedentes 23
Otras de las metodologías que se crearon en esta época fueron las clasificadas como
evolutivas e incrementales a partir de código existente y mejorado. Dentro de este grupo
se encuentra la metodología Dynamic System Development Method (DSDM), también se
crearon metodologías con enfoque de temas específicos.
A pesar de que las metodologías en desarrollo de software facilitaban la consecución de
resultados, seguía existiendo inconformidad de los clientes porque consideraban que las
soluciones brindadas no cubrían totalmente sus necesidades, fue entonces cuando se
presentó el nacimiento de metodologías completamente apartadas de lo establecido hasta
ese momento.
Los creadores de estas nuevas metodologías debían imprimir en ellas, factores que
permitieran vencer los desafíos existentes como:
Estas nuevas metodologías debían superar circunstancias ya conocidas como la
productividad no se logra incrementar dado a que las herramientas eran difíciles de utilizar
y se requería habilidades para su uso al intentar implementar nuevas metodologías
generaban costos significativos a pesar de que el resultado final no cumplía los
requerimientos de los clientes dado que no se realizaba comunicación con el cliente ni
usuario final.
En resumen, las nuevas metodologías utilizadas en el desarrollo del software deben
romper estos paradigmas permitiendo la adaptación al cambio, disminución de tiempos de
respuesta, trabajar conjuntamente con el cliente, reducir costos, conocer los riesgos e
idear soluciones para disminuirlos, fortalecer el código ante riesgos de seguridad, entre
otros, todo eso con el fin de ofrecer soluciones de calidad de productos y servicios para
que tanto clientes como desarrolladores se enfrenten y sobrevivan a la competencia global,
se obtengan ganancias financieras, se aumente la productividad entre otros.
Ahora, más que nunca, las compañías desean entregar mejores productos y servicios en
menos tiempo y más baratos. Sin embargo, las soluciones creadas de productos y
servicios son más complejas. (Nohemí, Meneses, Juan, & Mora, 2014).
24 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Cómo respuesta a esto se presenta el surgimiento de las metodologías denominadas
ágiles. Las compañías desarrolladoras utilizan componentes creados internamente y
creados por terceros integrándolos para sacar un producto o servicio final.
Todas las organizaciones deben ser capaces de manejar y controlar todos los factores
involucrados en el proceso de desarrollo y mantenimiento del software. (Chrissis, Konrad,
& Shrum, 2009), por lo que es necesaria la integración en el mercado actual de modelos
de madurez, estándares, metodologías y guías. Esto no siempre se cumple, porque la
mayoría de las organizaciones centran su objetivo en una parte específica de su actividad,
se concentran en mejorar un área de negocio y se alejan de una solución a los problemas
a los que se enfrentan, porque perpetúan canales y barreras existentes en el seno de las
organizaciones. (M., Machado, & Morimitsu, 2008).
Las organizaciones deben trabajar en las áreas de proceso de alta madurez con el fin de
realizar mejoras que reflejen las buenas prácticas del sector, se incluyan metas específicas
y varias prácticas particulares especialmente en el área de procesos de Innovación y
despliegue en la organización, nombrada como Gestión del Rendimiento de la
Organización (A. M. Serna & Itilview, n.d.).
Los modelos de madurez que se basan en mejoramiento de la organización, continuo y por
etapas, valoran la importancia en el software; hay propuestas existentes en el mercado que
pueden ser adoptadas por las organizaciones. Es en este sentido que las empresas
desarrolladoras de software se han apoyado en metodologías ágiles por considerar que las
partes principales de CMMI pueden llegar a tener relación con las metodologías y buenas
prácticas del “Qué” y no del “Cómo” realizar el desarrollo de software en el país.
El Gobierno Colombiano ha estado interesado en fortalecer la industria del sector del
software y para ello ha establecido una estrategia de Fortalecimiento de la Industria de
Tecnologías de Información – FITI, la cual viene operando desde el mes de abril del año
2011, realizando una gestión sin interrupciones, en pro del progreso de las empresas que
conforman la industria TI del país. En este tiempo se ha podido posicionar a FITI en el
ámbito nacional, como una estrategia líder para contribuir a la transformación de la
industria TI en un sector de competitividad mundial (Fiti, 2012).
Antecedentes 25
1.1 Elementos para mejorar la calidad de desarrollo de
software
1.1.1 Alcanzar la satisfacción del cliente
Para lograr esto se debe evaluar, validar y verificar constantemente los requerimientos
directamente con el cliente, de esta manera el producto o servicio obtenido se acerca a lo
que realmente se esperaba, adicionalmente se debe seguir un proceso de mantenimiento
sobre el producto terminado. Los procesos de desarrollo de software utilizados redundan
en mejoras tanto en el rendimiento del equipo como en la reducción del tiempo utilizado
para el desarrollo del producto y/o servicio. (Sanz Moyano, 2009, p. 10).
1.1.2 Reducir ciclos.
Uno de los factores en los que las metodologías ágiles se enfocan, es la reducción del
tiempo, por lo que tanto el grupo de desarrollo cómo el cliente, deben aplicar mejoras y
definir cortas tareas que impacten de manera significativa y se vean evidenciados en
beneficios de madurez en el desarrollo de la gestión de las empresas.
Para la implementación de metodologías ágiles los ciclos deben ser repetibles y ejecutar
procesos estrictamente necesarios y llevados a cabo por equipos multidisciplinarios que
trabajen de manera conjunta.(Sanz Moyano, 2009, p.10).
1.1.3 “Alcanzar el “lanzamiento al mercado”
Si durante el desarrollo del proyecto, se involucra directamente al cliente y se logra la
satisfacción del cliente, la factibilidad del lanzamiento del producto y/o servicio al mercado
es total y permite a las empresas enfrentarse a la competencia. No se debe dar lugar para
el incumplimiento porque puede ocasionar la cancelación de contratos que impacten
significativamente a la empresa.
26 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
1.1.4 Mejorar la gestión de requerimientos funcionales y no funcionales
Las empresas están adoptando el modelo porque al mejorar lo relacionado con los
requerimientos no funcionales como son, la interoperabilidad, la virtualización, la
plataforma tecnológica y los funcionales como son la disponibilidad, la
documentación. Las necesidades del cliente, definen mejor el alcance del proyecto y
permiten lograr el mayor beneficio que se pueda obtener como es contar con un
cliente satisfecho.
1.1.5 Implementar procesos de calidad para mejorar la verificación del producto con el cliente
Se puede observar según los trabajos desarrollados por académicos y empresas,
(Valencia, Villa, & Ocampo, 2009) que generan metodologías, que se hace necesario
implementar procesos de madurez que permitan brindar soluciones a los problemas tales
como:
Improvisación en el desarrollo por falta de mano de obra.
Altos costos, por largos plazos de entrega.
Calidad insuficiente, por premura en la entrega al cliente.
Procesos escasamente repetibles, porque no existen los controles adecuados.
Modelos de gestión organizacional no desarrollados en su totalidad.
Estructura reducida y carencia de personal cualificado en gestión empresarial por alta
rotación de personal debido a salarios no justos.
Al evaluar el producto con base en las necesidades del cliente se asegura la satisfacción
del cliente porque el producto cumple con los requerimientos para los cuales se diseñó.
Las etapas de validación y verificación llevan a cabo actividades de pruebas, análisis e
inspecciones ejecutadas de forma recurrente.
Estos proceso constantes ocurren a lo largo del desarrollo del producto, se deben validar
los requerimientos funcionales y seguir con la verificación y evolución del mismo, f inaliza
con la recepción a satisfacción por parte del cliente (Sanz Moyano, 2009, p.11).
2. Marco Conceptual
El hombre desde sus inicios ha buscado la simplificación de la vida diaria, a raíz de esa
inquietud constante por aprender, crear y poner en práctica sus logros, creó la tecnología.
Uno de los principales componentes para su desarrollo es el software, y la ingeniería de
software puso la ingeniería al servicio del ser humano.
Pero ¿qué es software? Software es el conjunto de instrucciones que conforman los
programas para los computadores junto con la configuración y la documentación, con el
fin de crear un producto o un servicio. En la época actual no hay que desconocer que el
software también es un producto.(Pressman, 2010, p.29).
El principal desafío del desarrollo del software consiste en lograr que el producto o servicio
terminado tenga la aprobación total del cliente y las especificaciones estén totalmente
cubiertas. Cómo son muchos los factores que intervienen para contar con la satisfacción
del cliente, se ha visto a lo largo de casi tres décadas cambios significativos en la utilización
de metodologías para el desarrollo del software.
Las características deseables del software, deben ser:
Eficiente.
Confiable.
Fácil de mantener.
Evolutivo.
Portable.
Reutilizable.
Robusto.
Utilizable.
Marco Conceptual 28
También hay elementos que influyen directamente en el software, como son:
Costo de la Inversión.
Tiempo Utilizado.
El costo de la inversión, no debe superar los costos de la infraestructura para operar y se
espera que el tiempo utilizado en el desarrollo sea muy corto.
2.1 Ingeniería de Software
La ingeniería de software ha establecido las directrices que guían la utilización de las
metodologías al servicio del hombre, se convirtió en una disciplina que abarca todo lo
relacionado con la producción del software en todas sus etapas..(Sommerville & Ian, 2005).
En la figura 2-1, se muestran las capas de la ingeniería de software.
Figura 2-1 Capas de la Ingeniería de Software
Fuente: (Departamento de Sistemas Informáticos y Computación. & Universidad
Politécnica de Valencia, 1985).
2.1.1 Compromiso con la calidad
La calidad es un factor esencial por lo que se convirtió en la base de la ingeniería de
software, las organizaciones que contemplan una relación con la calidad logran una cultura
de mejora continua.
Marco Conceptual 29
2.1.2 Proceso
El proceso contiene un conjunto de actividades, acciones y tareas que al integrarse
permiten que el resultado sea un producto y/o un servicio. A continuación, se presenta una
definición que describe cada una de sus partes.
“Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan
cuando va a crearse algún producto del trabajo. Una actividad busca lograr un
objetivo amplio (por ejemplo, comunicación con los participantes) y se desarrolla
sin importar el dominio de la aplicación, tamaño, del proyecto, complejidad del
esfuerzo o grado de rigor con el que se usará la ingeniería de software. Una acción
(diseño de la arquitectura) es un conjunto de tareas que producen un producto
importante del trabajo (por ejemplo, un modelo del diseño de la arquitectura). Una
tarea se centra en un objetivo pequeño pero bien definido (por ejemplo, realizar una
prueba unitaria) que produce un resultado tangible.(Pressman, 2010, p.39).
Un proceso se compone de cinco (5) actividades estructurales que forman la base para la
administración de los proyectos de software y establece los métodos que proporcionan la
experiencia técnica para la creación del software
Comunicación
La relación que tiene que existir entre el cliente y todos los participantes del proceso, es
fundamental en la definición de los objetivos y los requerimientos necesarios para la
definición de las características y funciones del software.
Planeación
La principal actividad es crear un plan que guíe el equipo y defina las tareas por realizar,
los riesgos, los requerimientos, los artefactos, la programación de la ejecución de las
actividades y el producto esperado.
30 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Modelado
El modelo ayuda a mejorar los requerimientos del software y el diseño que los satisfaga.
Construcción
En esta actividad contempla la creación del código y el diseño de las pruebas.
Despliegue
Actividad que se presenta una vez el producto es entregado, puesto en funcionamiento,
la validación, las pruebas y la realimentación que sirve para la mejora del producto.
Estas actividades se deben aplicar iterativamente y su ejecución es repetida. En cada
iteración se produce un incremento del software que hace que cubra totalmente los
requerimientos.
Existen otras actividades complementarias, denominadas actividades sombrilla, que se
aplican a lo largo del proyecto ayudando a administrar, a controlar el avance, la calidad, el
cambio y el riesgo.
Las actividades sombrilla son:
Seguimiento y control del proyecto de software
Es la acción llevada a cabo por el equipo de software para evaluar el progreso y verificar
con el plan definido previamente.
Administración del riesgo
Las acciones que se desarrollen para analizar los riesgos potenciales a que se enfrenta el
proyecto.
Aseguramiento de la calidad del software
Corresponden a las actividades encargadas de asegurar la calidad en el software:
Marco Conceptual 31
Revisiones técnicas
Son las actividades para detección de errores y sus correcciones, en cada etapa a fin de
ser corregidas.
Medición
Define y agrupa los resultados de las mediciones del proceso, del proyecto y el producto
con el fin de entregar un software que genere satisfacción la involucrar totalmente las
necesidades del cliente.
Administración de la configuración del software
Administra cada cambio que se hace y sus efectos durante el tiempo que dure el proceso.
Administración de la reutilización
Se administran los criterios que se establecen en la reutilización futura del software y sus
componentes.
Preparación y producción del producto del trabajo
Se agrupan las actividades necesarias para los resultados del trabajo.
2.1.3 Métodos
Son enfoques estructurados para el desarrollo de software que incluyen la comunicación
que debe existir entre los integrantes del proyecto, el análisis de los requerimientos de los
clientes, el diseño del proyecto, la construcción de los programas, las pruebas de
funcionamiento y el soporte que se debe brindar.
2.1.4 Herramientas.
Las herramientas conforman los utilitarios computacionales utilizados para elaborar el
desarrollo del software, la ejecución de las pruebas, la puesta a producción y la
realimentación del software.
32 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
2.2 Metodologías para desarrollo de software
Aunque esta área ha sido abarcada en su totalidad por la ingeniería de software, no
podemos desconocer su utilización en todas las áreas de desarrollo del hombre.
Uno de los objetivos de la utilización de una metodología es establecer directrices en la
construcción de un producto o servicio, con el fin de que el desarrollo del proceso sea el
adecuado y se adapte totalmente al ambiente deseado.
Independientemente del tipo de metodología utilizada, tienen en común fases de
especificación de requerimientos tanto funcionales como no funcionales, elaboración del
diseño, la construcción directa del software, los controles, las verificaciones, la ejecución
de pruebas, las validaciones, de forma tal que si son aprobadas por el cliente se llega a
las fases de Instalación, adaptación y mantenimiento.
Las metodologías han adoptado cambios que lograron romper paradigmas que por más
de un siglo estuvieron presentes, se ha fortalecido la toma de decisiones y la creación de
estrategias para llevar a cabo el desarrollo satisfactoriamente. Se han adicionado
actividades en busca de cumplir con los objetivos propuestos como creación de creado
roles y perfiles de acuerdo con habilidades específicas, clasificación de entregables
denominados artefactos, adopción de herramientas para control, seguimiento, medición y
perfeccionamiento, aplicación de principios de calidad, manejo de riesgos y adopción de
mejores prácticas.
Los modelos han tenido transformaciones a lo largo del tiempo, tendientes a la mejora de
los resultados obtenidos, a la consecución de beneficios, corrigiendo errores, fortaleciendo
el código y la adaptación al cambio.
2.2.1 Modelos de proceso prescriptivo
Estos modelos se crearon para ordenar el caos reinante en el ambiente de desarrollo de
software por lo que establecen una relación de todos los elementos del proceso y definen
un flujo para el desarrollo del trabajo.
Marco Conceptual 33
Modelo Lineal en Escala
Este modelo propuesto por Winston Royce3 ha sido llamado también “Ciclo de Vida
Clásico” y sus actividades son desarrolladas en forma lineal, siguen pasos sucesivos con
un orden determinado y completando cada etapa antes de comenzar la siguiente. La figura
2-2 nos muestra las actividades estructurales en un modelo lineal o de cascada.
Figura 2-2 Modelo Lineal – Flujo de Proceso
Fuente: (Arturo & Fernández, 2009)
La figura 2-3 muestra el orden de sus etapas y cada etapa hace concordancia con las
actividades estructurales. En etapa de requerimientos se debe concertar todo lo que se
requiere del sistema y lo pactado será lo que seguirá en las siguientes etapas.
Figura 2-3 Modelo en Cascada
Fuente: Barry Boehm 1986
3 Computólogo americano. Nació en 1929 y murió el 7 de junio de 1995
Marco Conceptual 34
El modelo en V, (Ver figura 2-4) es una variación del modelo en cascada, y realiza una
relación entre las actividades de la comunicación, el modelado y la construcción, la
ejecución de las actividades van en una secuencia de las actividades desde el modelado
hasta la generación del código (derecha a izquierda) y posteriormente se ejecutan las que
trascurren desde pruebas unitarias hasta las pruebas de aceptación. (subiendo de
izquierda a derecha).
Figura 2-4 Modelo en V
Fuente: (García Rodríguez, 2015)
Este modelo ha perdido fuerza porque el desarrollo de los proyectos no avanza de una
forma rígida como es mostrado, sino que en cada etapa existen eventos o requerimientos
que impactan directamente, lo cual le impide a este modelo avanzar, causando “estados
de bloqueo” 4que retrasan el proyecto y al final el producto resultante no cubre totalmente
las necesidades reales de los clientes.
4“En este modelo los miembros del equipo de proyecto deben esperar a otros a fin de terminar
tareas interdependientes. ¡En realidad, el tiempo de espera llega a superar al dedicado al trabajo productivo! Los estados de bloqueo tienden a ocurrir más al principio y al final de un proceso secuencial lineal
Marco Conceptual 35
Modelos de Proceso Incremental
El modelo de proceso incremental se lleva a cabo como un modelo lineal que al finalizar
las etapas hasta que se tenga un producto listo para operar, genera mejoras que van
incrementando el código con los resultados de la evaluación. En este modelo la utilización
de personal es mínima y en la medida de su crecimiento aumenta el número de
trabajadores. (Ver Figura 2-5).
Figura 2-5 Modelo iterativo e incremental – Flujo de proceso
Fuente: (Moreno García, n.d.)
Modelos de Proceso Evolutivo
Los modelos incrementales, también son llamados de procesos evolutivo, porque en cada
iteración evolucionan y generan una versión más completa del software en el tiempo
conforme los cambios del entorno. El flujo de proceso se muestra en la Figura 2-6.
36 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Figura 2-6 Modelo Evolutivo - Flujo de Proceso
Fuente: (Méndez, 2006).
Modelo prototipo
Es un modelo evolutivo donde la comunicación con el grupo del proyecto es vital, se
definen los objetivos para la formulación de los requerimientos del software que contenga
aspectos visibles a los usuarios finales en un diseño rápido ejecutado en un tiempo muy
corto. Se formula una iteración para hacer el prototipo.
El prototipo se crea con el requerimiento inicial del cliente y debe servir como mecanismo
para identificar los requerimientos del software, puede construirse complementándolo con
otro software existente y la utilización de herramientas que generen un producto funcional
rápidamente. Si el cliente lo aprueba se realimenta y el prototipo se convierte en insumo
para las siguientes versiones. Ver Figura 2-7.
Marco Conceptual 37
Figura 2-7 Modelo inicial o prototipo
Fuente: (Ruiz & González Harbour -IS, n.d.).
Modelo en espiral
Este modelo fue propuesto por Barry Boehm5, como una mejora del modelo evolutivo, el
elemento fundamental en este modelo es el análisis del riesgo, En la porción circular se
representa el esfuerzo realizado en el desarrollo.
En la figura 2-8, se muestra la iteración de las cuatro fases, en la comunicación se
determinan objetivos, alternativas y restricciones, en la fase de planeación, se hace la
estimación, programación y análisis del riesgo, en la fase de modelado se ejecutan
actividades de análisis y diseño, en la fase construcción se desarrolla el código y se pone
a prueba y en la fase del despliegue, se hace la entrega y existe la realimentación.
5 Ingeniero informático estadounidense. Nació el 16 de mayo de 1935
38 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Figura 2-8 Esquema del modelo de ciclo de vida en espiral
Fuente: (Moreno García, n.d.).
Modelos concurrentes
En la ingeniería de software se definen los modelos concurrentes como ingeniería
concurrente, porque se pueden representar elementos iterativos de cualquier modelo de
los procesos descritos anteriormente y de cada una de las actividades estructurales.
La figura 2-9 muestra la actividad de modelado. Este modelo constituye redes entre las
actividades, acciones y tareas y cada una puede existir al mismo tiempo con otras
actividades, acciones o tareas y se presentan transiciones entre un estado y otro por los
eventos generados.
Marco Conceptual 39
Figura 2-9 Actividad de modelado
Fuente: (Méndez, 2006).
2.2.2 Modelos de proceso especializado
Este tipo de modelo se caracteriza con un conjunto de técnicas o metodología para
alcanzar una meta.
Desarrollo basado en componentes (COTS)
Los componentes comerciales de software, son un modelo evolutivo e iterativo, utiliza
muchas de las características del modelo en espiral. Construye software a partir de
software prefabricado o reutiliza el software impactando directamente en el ciclo de tiempo
del desarrollo como en el costo. Incorpora etapas como investigación y evaluación,
integración de componentes, diseño de la arquitectura ajustada a la reutilización,
integración de los componentes de reutilización y pruebas exhaustivas.
40 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Modelo de método formales
Agrupa actividades que conllevan a especificaciones matemáticas, emplean técnicas y
herramientas matemáticas para aplicar técnicas de prueba y potencialmente
automatizados, su función es garantizar que el funcionamiento y el desempeño del
software sean correctos. Es utilizado en proyectos médicos y científicos.(E. Serna &
Candidato, 2010).
Desarrollo orientado a aspectos (DSOA - aspect-oriented programming (POA))
Este modelo proporciona un proceso y enfoque de método para definir, especificar, diseñar
y construir aspectos para una adecuada modulación de las aplicaciones y posibilita una
mejor separación de responsabilidades.
2.2.3 Proceso Unificado (PU)
Conocido como Proceso Racional Unificado (PRU o RUP), en la década de 1990 James
Rumbaugh 6, Grady Booch 7 e Ivar Jacobson8, crearon el Lenguaje de Modelado Unificado
(UML), herramienta práctica para la ingeniería de software, pero no guiaba a los equipos
del proyecto, trabajaron rescatando los mejores rasgos y características de los modelos
tradicionales, implementando muchos de los mejores principios del desarrollo ágil de
software. (Ver figura 2-10).
Figura 2-10 Fases del PU
6 Científico americano de la computación y metodólogo de objeto. Nació el 22 de agosto de 1947. 7 Científico americano de la computación, metodólogo y entusiasta del diseño de patrones. Nació el 27 de febrero de 1955. 8 Científico sueco de la computación e ingeniero de software. Nació el 2 de septiembre de 1939.
Marco Conceptual 41
Fuente: (García Rodríguez, 2015).
La comunicación con el cliente es fundamental utilizando métodos de comunicación
directos entre los miembros del equipo, da especial importancia a la arquitectura de
software y orienta al arquitecto proponiendo un flujo iterativo incremental de un proceso
evolutivo.
Los requerimientos se describen mediante casos de uso preliminares donde se detallan
características y funciones que desean los diferentes clientes. Ha sido esencial en la
transformación del software para adaptarse a la era actual.
2.2.4 Modelos del Proceso Personal y del Equipo
Este tipo de modelo trabaja en dos líneas, la primera basa su fundamento en la creación
de un proceso para que se ajuste a los requerimientos cubriendo las necesidades del
equipo y la organización, se denomina Proceso Personal del software (PPS); y en el
segundo el equipo crea un proceso propio para satisfacer las necesidades de clientes y las
de la organización, se denomina Proceso del equipo de software (PES) (Pressman, 2010).
2.2.5 Modelos ágiles
Las metodologías ágiles surgieron como la combinación de lineamientos de desarrollo,
poniendo énfasis en la comunicación continua entre desarrolladores y clientes, la
satisfacción del cliente, la entrega rápida de software incremental, la formación de equipos
pequeños y motivados, los métodos informales, los productos de trabajo y r la calidad de
los productos.
Estos métodos están enmarcados como modelos de calidad del software y son cualidades
medibles y específicas que buscan minimizar los problemas del pasado y su ajuste a las
exigencias actuales de la sociedad y apoyados con herramientas tecnológicas actuales y
sin perder el horizonte de contar con la satisfacción del cliente. Se atribuyó el término
agilidad al proceso de software moderno que corresponde a estos principios junto con el
trabajo en equipo y el aprovechamiento de las habilidades, capacidad y conocimiento del
grupo con una meta común.
42 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Proceso ágil
Un proceso ágil debe tener los siguientes requerimientos: adaptabilidad, la cual debe ser
incremental, realimentación continua con el cliente mediante la institución de una
estrategia de desarrollo incremental, entregar incrementos de software en periodos cortos
de tiempo a ritmo con el cambio, debe permitir la evaluación regular del cliente en cada
incremento del software y realimentarse generando cambios y adaptaciones en el proceso.
En el 2001 en una reunión celebrada en Utah–EEUU, participaron 17 expertos de la
industria del software para formular valores y principios que ayudaran a los equipos de
desarrollo, a responder rápida y eficiente a los cambios generados durante el transcurso
del proyecto.
Se creó “The Agile Alliance” para promover los conceptos relacionados con el desarrollo
ágil de software.
Marco Conceptual 43
Manifiesto ágil Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.”(Beck et al., 2001).
Marco Conceptual 44
Principios del manifiesto ágil Principios del Manifiesto Ágil
Seguimos estos principios:
Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
Aceptamos que los requerimientos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.
Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.
Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.
Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
El software funcionando es la medida principal de
progreso.
Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.
La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.
Las mejores arquitecturas, requerimientos y diseños
emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.(The Agile Alliance, 2001).
Marco Conceptual 45
2.2.6 Metodologías Ágiles
En la tabla 2-1 se presenta una lista de las principales metodologías ágiles que se están
implementando en la actualidad para enfrentar los grandes retos de las organizaciones.
Tabla 2-1 Metodologías ágiles de desarrollo Metodología Acrónimo Creación Tipo de modelo Característica
Evolutionary
Project
Management
EVO Gilb 1976. Framework adaptativo. Primer método ágil
Existente.
Microsoft
Solutions
Framework
MSF Microsoft 1994. Lineamientos, disciplinas,
prácticas.
Framework de
desarrollo de
soluciones.
Scrum Scrum Sutherland 1994
Schwaber 1995.
Proceso – framework de
management.
Complemento de otros
métodos, ágiles o no.
Rapid
Development
RAD McConnell 1996. Survey de técnicas y
modelos.
Selección de best
practices, no método.
Dynamic
Solutions Delivery
Model
DSDM Stapleton 1997. Framework/modelo de
ciclo de vida.
Creado por 16
expertos en RAD.
Cristal Methods CM Cockbum 1998. Familia de metodologías. Metodología ágil con
énfasis en modelo de
ciclos.
Agile RUP dX Booch, Martin,
Newkirk 1998.
Framework/Disciplina. XP dado vuelta con
artefactos RUP.
eXtreme
Programming
XP Beck 1999. Disciplina en prácticas de
ingeniería.
Método ágil radical.
Feature- Driven
Development
FDD De Luca & Coad
1998 Palmer &
Felsing 2002.
Metodología. Método ágil de diseño
y Construcción.
Adaptative
Software
Development
ASD Highsmith 2000. Prácticas + ciclo de vida. Inspirado en sistemas
adaptativos complejos.
Lean
Development
LD Charette 2001 Mary
y Tom Poppendieck.
Forma de pensar –
modelo logístico.
Metodología basada
en procesos
productivos.
Agile Modeling AM Ambler 2002. Metodología basada en la
práctica.
Suministra modelado
ágil a otros métodos.
Fuente: Elaboración propia con base en (García Rodríguez, 2015)
48 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Extreme Programming (XP)
Este modelo usa un enfoque orientado a objetos mediante un conjunto de reglas y
prácticas que ocurren en el contexto de 4 actividades estructurales: planeación, diseño,
codificación y pruebas. (Ver figura 2-11). (Beck & Andrés, 2005).
Figura 2-11 Proceso de software XP
Fuente: (Wells, 2009)
Planeación. Es la actividad encargada de escuchar para hacer el compendio de las
necesidades del usuario y diseñar la funcionalidad del software a elaborar. En grupo
conformado por el cliente y los miembros del equipo XP valoran las historias del cliente
asignándole valores por función y por costo. Las entregas son incrementales y ayudan a
definir el cálculo de la velocidad del proyecto.
Diseño. El diseño XP debe ser sencillo y mantenerse, si se presenta dificultad en el diseño
de una historia se recomienda la creación de un prototipo operativo para esa parte del
diseño. Posteriormente se implementa y evalúa el prototipo denominado solución en punta.
Se espera la disminución del riesgo en la implementación definitiva.
Marco Conceptual 49
Codificación. La codificación no empieza inmediatamente, solo se hace después de la
ejecución de pruebas unitarias a cada una de las historias que se van a incluir en la entrega
en curso (incremento de software). Luego se trabaja en la llamada programación por
parejas conde la solución contempla el aseguramiento de la calidad a los problemas en
tiempo real, este estado se conoce como “integración continua”, esto ayuda a evitar los
problemas de compatibilidad e interfaces y brinda un ambiente de “prueba de humo” que
ayuda a descubrir a tiempo los errores.
Pruebas Las pruebas unitarias se ejecutan antes de la codificación, se deben implementar
con el uso de una estructura que permita automatizarlas para repetirlas fácilmente.”.
Adaptative Software Development (ASD)
Este modelo fue propuesto por Jim Highsmith 9como una técnica para elaborar software y
sistemas complejos. Los fundamentos filosóficos del ASD se fundamentan en la
colaboración y la organización del equipo. Define un “ciclo de vida” (Ver Figura 2-12) e
incorpora tres fases: especulación, colaboración y aprendizaje.
Figura 2-12 Modelo ASD
Fuente: (Amaro Calderón & Valverde Rebaza, 2007)
9 Ingeniero de software americano. Nació en 1945
50 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Dynamic Solutions Delivery Model (DSDM)
Este modelo proporciona una estructura para construir y dar mantenimiento a sistemas
que cumplen restricciones apretadas de tiempo mediante la realización de prototipos
incrementales en un ambiente controlado. Es un proceso iterativo de software en el que
cada iteración sigue la “regla de Pareto”10 Es custodiado por el grupo DSDM
Consortium tomaron las mejores prácticas conocidas en los años 90’s, define cinco fases
en la construcción de un sistema. (Ver Figura 2-13).
Figura 2-13 Proceso de desarrollo de DSDM
Fuente: (Amaro Calderón & Valverde Rebaza, 2007).
Estudio de factibilidad: Se formulan requerimientos y restricciones básicas de las
necesidades del cliente asociados con el producto y evaluar si la aplicación es un candidato
viable para aplicarle el proceso DSDM.
10 El nombre de este método se debe a Vilfredo Pareto, economista y sociólogo del siglo XX. En Italia, por aquel entonces, el 20% de la población acaparaba el 80% del capital económico (Rodríguez Castro, n.d.)
Marco Conceptual 51
Estudio del negocio: Establece los requerimientos e información funcionales que
permitirán la aplicación para dar valor al objetivo para el cual el producto se va a desarrollar,
la arquitectura básica de la aplicación e identifica los requerimientos para darle
mantenimiento.
Iteración del modelo funcional: El objetivo de este ciclo iterativo es afinar
requerimientos adicionales por medio de la realimentación de los usuarios cuando utilicen
el prototipo.
Diseño e iteración de la construcción: Ejecuta una revisión de los prototipos construidos
durante la iteración del modelo funcional para garantizar que cada iteración contenga lo
esencial para ofrecer valor operativo del negocio a los usuarios finales; la iteración, el
diseño e iteración de la construcción del software se ejecutan concurrente.
Implementación: Se encarga de poner a disposición de producción el software con la
aplicación de cambios que constituye un incremento. Adicionalmente se aclara lo brindado
en cada incremento no corresponde al 100% final y que se siguen aceptando cambios aun
cuando el incremento se saque de operación. Es un método versátil en cada iteración.
Cristal Methods (CM) Metodología creada por Alistair Cockburn11, se fundamenta en que cada proyecto de
software puede caracterizarse según dos dimensiones, tamaño y criticidad, asemejándose
a los minerales que se caracterizan por dos dimensiones, color y dureza. Cada proyecto
utiliza una metodología diferente y se considera como eje central para el éxito o fracaso,
las personas.
Es una metodología que asocia los colores de oscuros a claros, un proyecto grande o los
que sean más susceptibles de que un fallo cause mayores problemas, por lo tanto,
necesitan más coordinación y comunicación, los asocia con colores más oscuros.
La familia de metodologías, se describe así:
11 Científico americano de la computación y uno de los creadores del movimiento ágil. Nació el 19 de noviembre de 1953
52 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Clear: Para equipos de hasta 8 personas o menos.
Amarillo: Entre 10 y 20 personas.
Naranja: Para equipos entre 20 y 50 personas.
Roja: Entre 50 y 100 personas, entre otras.
A más personas en el proyecto, más coordinación. A más criticidad en el software, más
rigurosidad en el proceso. El factor más determinante es la comunicación entre los
participantes en el proyecto. El método debe cumplir siete propiedades.
Entregas frecuentes. Ciclo de vida iterativo e incremental, entregas semanales hasta
trimestrales.
Mejora reflexiva. Mejora continua. En cada iteración se produce un ajuste al proyecto.
Comunicación osmótica. El equipo debe estar ubicado geográficamente en el mismo
sitio.
Seguridad personal. Libre expresión.
Enfoque. Debe tener períodos donde no existan interrupciones al equipo (2 horas), los
objetivos y prioridades deben ser suficientemente claros con definición de tareas
concretas.
Fácil acceso a usuarios expertos. Esta metodología no exige que los usuarios estén
continuamente junto al equipo de proyecto, pero se deben reunir una vez por semana como
mínimo.
Entorno técnico con pruebas automatizadas, gestión de la configuración e
integración continua. Prácticas comunes.(Garzás, 2012).
Modelo ISO/ IEC 15504 (SPICE) Software Process Improvement Capability o Determinación de la Capacidad de Mejora
del Proceso de Software, es un modelo para la mejora y evaluación de los procesos de
desarrollo y mantenimiento de sistemas de información y productos de software. Cuenta
con la norma ISO 15504 SPICE para evaluar y mejorar la capacidad y madurez de los
procesos. (SENA, 2014).
Marco Conceptual 53
La norma ISO 15504 proporciona un marco de trabajo para la evaluación de la madurez
en las organizaciones. Evaluando la organización y los niveles de proceso. (Ver figura 2-
14). Esta norma a su vez está apoyada en la norma ISO/IEC 12207 propia del software.
Figura 2-14 Estructura de la norma ISO 15504/IEC
Fuente: (SENA, 2014).
Modelo IT-MARK Metodología desarrollada por el European Software Institute (ESI), primer modelo de
calidad internacional diseñado en particular para las micro y pequeñas empresas,
escalable con énfasis en brindar calidad para las micro y pequeñas empresas de
tecnologías de la información interesadas en acreditar su capacidad y madurez.
Considera fundamental la mejora de la efectividad organizacional y que el mejoramiento
de procesos garantiza el éxito en el mercado. Mediante la mejora de sus procesos.
El esquema IT-Mark cuenta con tres niveles de acreditación y más complejos de alcanzar.
I.T. Mark acredita a las empresas que reconocen problemas relacionados con gestión
técnica, de seguridad y del negocio, bajo un ambiente controlado. La revisión Clase C,
se asemeja al trabajo que se hace sobre los procesos técnicos de CMMI Nivel 2 y por
54 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
medio de evaluaciones rápidas orientadas fundamentalmente a la identificación de
debilidades.
I.T. Mark Premium acredita a una empresa que ha adquirido buena madurez en los
mismos procesos evaluando el desarrollo que tengan. Se asemejan a CMMI utilizando
una evaluación bastante detallada de Clase B sobre CMMI Nivel 2.
I.T. Mark Elite acredita a una empresa que ha conseguido un nivel Superior en la
definición e institucionalización de los mismos procesos asegurando la calidad debido
a la madurez de sus procesos y a la mejora continua. Comparándolo con CMMI, la
exigencia es similar al Nivel 3.
IT-MARK es mundialmente reconocido y se basa en la formulación de modelos cómo:
Gestión de Negocios (EFQM, ISO 9001); Gestión de la Seguridad de la Información (ISO
27000); Desarrollo de Sistemas de Software (CMMI-DEV; ISO 15504 / SPICE) y Provisión
de Servicios de TI (ISO 20000)(Valencia, Villa, & Ocampo, 2009)
ISO 9001:2000 El más conocido es ISO 9001:2000, un estándar internacional que puede ser aplicado a
cualquier tipo de organización, establece requerimientos que debe cumplir un sistema
genérico orientado a la gestión de la calidad Quality Management System (QMS), se usa
para mejorar procesos internos, para obtener una certificación o para establecer relaciones
contractuales.
Los requerimientos de la norma se agrupan en cinco capítulos:
Sistema de gestión de calidad.
Responsabilidad de la dirección.
Gestión de recursos.
Realización del producto.
Medición, análisis y mejora. Dentro de cada uno de ellos encontraremos las cláusulas que
describen los requerimientos que deben satisfacerse para cumplir con el modelo(Isabel &
Sanchez, 2004).
Marco Conceptual 55
La norma ISO 9001:2000 y el CMMI-DEV tienen varios puntos en común, lo cual permite
integrarlas en beneficio de la PyME. Si bien es necesario analizar las situaciones caso por
caso, se puede decir que una organización deseosa de certificar el estándar debería
cumplir con las áreas de proceso de nivel 2 y nivel 3, además de algunas de las
correspondientes a los niveles cuatro y cinco.
COBIT 5 - Control Objectives for Information and related Technology Se ha creado para que las organizaciones se mantengan equilibradamente en la
consecución de los intereses, la disminución de los riesgos y la óptima utilización de los
recursos.
COBIT ayuda a la administración gerencial en la organización, incluyendo el alcance
completo de todas las áreas de responsabilidad funcionales y de negocios(ISACA, 2015).
Los principios de COBIT, son genéricos y útiles para diferentes organizaciones de
cualquier tamaño y de cualquier actividad económica e independiente del sector ya sea
público o privado (Ver figura 2-15).
Figura 2-15 Principios de COBIT 5
Fuente: COBIT® 5, Figura 2. © 2012 ISACA® Todos los derechos reservados
56 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
SCRUM Es una forma de interactuar entre individuos con un propósito y roles definidos, que se
puede tomar de partida para el desarrollo del proceso en la ejecución de un proyecto
(Schwaber & Sutherland, 2013).
El término surgió a principios de los 80, por el análisis que hicieron Ikujiro Nonaka12 e
Hirotaka Takeuchi13 a empresas de manufactura tecnológica como Fuji-Xerox, Canon,
Honda, NEC, Epson, Brother, 3M y Hewlett-Packard.
“The Scrum Guide” define a Scrum como:
“Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el
desarrollo de productos complejos desde principios de los años 90. Scrum no es un
proceso o una técnica para construir productos; en lugar de eso, es un marco de
trabajo dentro del cual se pueden emplear varios procesos y técnicas. Scrum
muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas
de desarrollo de modo que podamos mejorar(Schwaber & Sutherland, 2013).
12 Teorista organizacional japonés, profesor emérito conocido por su estudio administración del conocimiento. Nació en Tokio el 10 de mayo de 1935. 13 Decano y profesor japonés, con reconocimientos muy grandes en escuela de negocios. Nació en Tokio el 16 de octubre de 1946
Marco Conceptual 57
Pilares de Scrum
La implementación de procesos en Scrum se soporta en tres pilares: (Ver Figura 2-16)
Figura 2-16 Pilares del Scrum
Figura: Kent Beck (n. 1961)
Transparencia. Los aspectos significativos del proceso deben ser visibles para los que
son responsables del resultado, con el fin de compartir un entendimiento común.
Inspección Los usuarios de Scrum deben realizar verificaciones constantemente sin
interferir en el trabajo, se debe realizarse por personas expertas en el tema, tanto en los
artefactos como en el progreso y que se cumpla los objetivos.
Adaptación. Si durante la verificación se encuentran desvíos que afecten el resultado, el
proceso deberá acondicionarse lo más rápido posible, para minimizar desviaciones.
Valores de Scrum
Tiene cinco valores, que, al incorporarse con los pilares, se genera confianza en todo el
grupo que son:
Compromiso.
Coraje.
Foco.
Apertura.
Respeto.
58 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
2.3 Características entre modelos de TI
En la tabla 2-2 se muestran las principales características de los modelos de gestión de
tecnología en el área de desarrollo de software.
Tabla 2-2 Características de modelos de Gestión de TI
CMMI-DEV ISO 9001 CobIT ITIL eSCM-SP
Tipo de
Organización
Organizaciones de desarrollo
de sistemas basados en
software, adquisición
desarrollo de producto,
adquisiciones e ingeniería de
sistemas.
Empresas de
cualquier tipo de
producto o
servicio.
Organizaciones de
servicios de tecnología.
Proveedores de servicios de IT Proveedores de servicios
basados en IT.
Función Proveer las mejores prácticas
para el desarrollo de software,
sistemas, productos y
procesos integrados, y
adquisición.
Genera las
pautas para
establecer un
sistema de
calidad.
Auditoría y control de
sistemas de información.
Alineamiento y gobierno
de tecnóloga de
información.
Marco de trabajo para
organizar los procesos de
provisión de servicios de IT.
Desarrollar y mejorar las
habilidades del proveedor
para cumplir con las
necesidades del cliente
durante todo el ciclo de
vida.
Áreas de
Trabajo
328 prácticas en 22 áreas de
proceso.
51 cláusulas. 4 dominios, 34 procesos
de IT y 318 objetivos de
control.
10 procesos. 84 prácticas en 10 áreas
de capacidad.
Certificación Reporte de evaluación; no hay
certificación formal.
Certificación por
entes
autorizados.
Certificación formal. Es un modelo de referencia y
una descripción de procesos al
mismo tiempo. No se certifica
ni se evalúa formalmente. El
nuevo estándar ISO 20000 está
inspirado en él
Certificación de CMU.
Fuente: De la Cruz, Angela; Cruz, Angela De la; Mauricio, David (16 de mayo de 2014).
2.4 Características de metodologías ágiles y metodologías tradicionales
Las características de las metodologías ágiles de desarrollo de software se basan en los
individuos, éstos que son los que logran focalizar el interés de la compañía en los
diferentes procesos, la colaboración es directa con el cliente, se adaptan los
requerimientos a sus necesidades, pero no basan el desarrollo a un contrato en particular,
para lograrlo, se disminuye la utilización de recursos de personas gerenciales que no
intervengan en el desarrollo.
Tabla 2-3 Características entre metodologías tradicionales y metodologías ágiles
Metodologías tradicionales Metodologías ágiles
Se planifican las actividades en forma secuencial
definiendo levantamiento de requerimientos,
tiempos, costos, recursos humanos, pruebas,
implementación, y soporte que presentan a la
organización para su aprobación.
Durante la planificación se verifica la
aprobación del proyecto junto con su
financiamiento.
Se hace la negociación y se firma el contrato para
la ejecución.
Se aseguran los elementos necesarios para
la ejecución como infraestructura, el recurso
humano, las herramientas.
Se ejecuta el contrato de manera secuencial y de
acuerdo a las especificaciones iniciales
formuladas.
El proyecto se desarrolla de acuerdo a etapas
cortas, repetitivas, incrementales
El cliente interactúa con el equipo de desarrollo en
la definición de requerimientos y en la ejecución de
las pruebas.
El cliente está permanentemente
interactuando con el grupo de desarrollo a fin
de definir cambios y ejecutarlos.
Una vez se entrega el software se cierra el
proyecto.
Se hacen entregas permanentemente luego
de haber efectuado los cambios y los ajustes
necesarios.
No se aceptan cambios Los cambios alimentan el producto final.
El grupo de desarrollo puede estar compuesto por
un número más grande entre analistas,
diseñadores, desarrolladores.
Generalmente los grupos de desarrollo son
pequeños y se aumentan en la medida del
tamaño de la empresa del cliente.
Manejan pocos artefactos o
direccionamientos Al existir un grupo pequeño los roles de los
integrantes del proyecto son pocos.
Fuente: Elaboración propia con base en información secundaria.
62 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
2.5 CMMI-DEV Capability Maturity Model Integration CMMI-DEV Es un modelo de madurez que permite a las empresas medir e incorporar
mayores niveles de eficacia en sus procesos de desarrollo y mantenimiento de software y
está considerado como uno de los mayores referentes mundiales en cuanto a producción
de software.
Este modelo proporciona a las organizaciones los recursos específicos para definir
procesos eficientes, ayuda a incorporar procesos organizativos a nivel general, promueve
objetivos y prioridades aumentando progresivamente los procesos, proporciona una guía
para la calidad de los procesos y se convierte en un referente para evaluar lo procesos que
la organización ejecuta.
El trabajo de la organización consiste en definir el proceso productivo de manera que
cumpla con las prácticas específicas, propuestos por el modelo. Plantea que los límites
varíen dentro de rangos conocidos, generando procesos estándares formalizados.
2.6 Áreas de proceso Las áreas de proceso son un conjunto de actividades que se agrupan por niveles y facilitan
progresivamente la madurez de la organización logrando la capacidad de la organización.
Dentro de cada una de las áreas del modelo existe un conjunto de objetivos específicos y
genéricos que deben cumplir.
En cuando a los niveles de capacidad CMMI-DEV define 4 niveles:
Nivel 0. Incompleto.’Los procesos que se hacen no tienen ningún control.
Nivel 1.- Realizado. Se realiza con procesos particulares que ejecuta la organización.
Nivel 2.- Gestionado. Ya se cuenta con procedimientos administrados.
Nivel 3. Definido. Ya está estandarizado y es fácilmente repetible.
La capacidad hace referencia al cumplimiento de la mejora de procesos de una
organización en áreas de proceso individuales.
Metodología 63
Los niveles de madurez CMMI contienen 5 niveles de madurez, los cuales progresivamente
conllevan a la mejora de los procesos de la organización, definiendo áreas de proceso y
prácticas específicas en cada nivel madurez.
Los niveles son:
Inicial.
Gestionado.
Definido.
Gestionado cuantitativamente.
Optimización.
El nivel de madurez en el que se basa el trabajo es el nivel 2, el gestionado, un proceso
gestionado es un proceso que es planeado y ejecutado de acuerdo con las políticas de la
empresa, utiliza personal que tiene los recursos adecuados para producir resultados
controlados, involucra al personal interesado, es monitorizado, controlado y revisado;
también se asegura de llevar a cabo la descripción del proceso. La disciplina de proceso
reflejado por el nivel 2 ayuda a asegurar que las prácticas existentes sean seguidas en los
tiempos de estrés (“CMMI® for Development, Version 1.3 Software Engineering Process
Management Program,” 2010).
2.6.1 Nivel 2 Gestionado En este nivel los compromisos adquiridos con las personas involucradas en el proyecto se
definen y son controlados, el modelo permite actuar en cuatro entidades de conocimiento
distintos: Ingeniería de Software, Ingeniería de Sistemas, desarrollo integrado de
productos y procesos, y adquisición.
2.7 Interpretando CMMI-DEV al utilizar enfoques ágiles CMMI-DEV y los métodos ágiles se complementan entre sí, creando uniones que
benefician a las empresas que los utilizan. Los métodos ágiles proveen un “¿Cómo?”, que
funciona bien especialmente con equipos pequeños y que se encuentran en la misma
ubicación, por el contrario, CMMI-DEV aporta las prácticas de ingeniería de software que
permiten el uso de los métodos ágiles en proyectos grandes. CMMI-DEV también aporta
la gestión del proceso y las prácticas que ayudan a implementar, sostener y mejorar
continuamente la implementación de los métodos ágiles en cualquier organización.
64 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Las áreas de proceso de CMMI-DEV están diseñadas para proporcionar valor en diferentes
circunstancias, por lo tanto, se expresan en términos generales. Dado que CMMI no
plantea ninguna metodología para implementar los procesos se hace difícil adoptar el
modelo por encontrarse poco intuitivo en su implementación; pero inmerso se encuentra
referencias introductorias a procesos ágiles para áreas de proceso en particular.
Para cualquier enfoque de desarrollo o de gestión que se adhiera al Manifiesto para el
Desarrollo Ágil se caracterizan por lo siguiente:
Inclusión directa del cliente en el desarrollo del producto.
Creación de un repositorio de soluciones claramente definidas de iteraciones de
desarrollo para aprender y evolucionar el producto.
Intervención activa de ls partes involucradas durante el desarrollo del proyecto.
Integración de varios enfoques de desarrollo de gestión que permitan compartir una o
más de estas características y aun así no son llamadas “ágiles”.
Como su nombre lo indica metodología ágil ayuda a un modelo como CMMI que no dice
el “cómo” hacer el desarrollo en las diferentes áreas de proceso y al ser compatibles se
llega a la conclusión que entre CMMI-DEV y metodología ágil son dos elementos que
pueden ser usados de forma simultánea (Glazer, Dalton, Anderson, Konrad, &Shrum,
2008).
CMMI-DEV es un modelo que establece objetivos a alcanzar, pero no es un estándar
o metodología que explique cómo alcanzarlos.
CMMI-DEV define áreas de procesos, pero no procedimientos, con el único propósito
que los objetivos de cada área deben de ser alcanzados.
En Las metodologías ágiles predomina la disciplina y el control.
En las metodologías ágiles se pueden realizar progresiones.
3. Objetivos.
Los objetivos generales y específicos definidos para este estudio se han planteado en los
siguientes términos.
3.1 Objetivo General Proponer un modelo que incluya la integración de una metodología ágil en los procesos y
la implementación del modelo de madurez CMMI-DEV como guía para la certificación en
empresas de desarrollo de software.
3.2 Objetivo Específicos Caracterizar a las empresas de desarrollo de software certificadas en nivel 2 y
seleccionar la empresa que será objeto de estudio.
Identificar las mejores prácticas asociadas al contexto que permitan implementar la
integración de metodología ágil con CMMI-DEV.
Identificar los mejores procedimientos ágiles en la apropiación e implementación de
los procesos para la eficiencia en el desarrollo de software.
Diseñar el modelo de integración de metodología ágil y del proceso de análisis de requerimientos
para proyectos de desarrollo de software.
4. Metodología
En este capítulo se presenta la orientación metodológica y las técnicas utilizadas para
desarrollar el trabajo, aborda el problema y una aproximación a la forma en que dicha
información se desagregó para alcanzar los objetivos específicos. Así mismo, se detallan
los procesos en cuanto a su estructura, aplicabilidad y oportunidad.
El estudio se centró en analizar el desarrollo de software de empresas de tecnología y
proponer una mejora en la implementación de sus procesos, ya que, en el mundo de
tecnología, si no se quiere perecer, es necesario ser competitivo e innovador. Está a
disposición diferentes tecnologías para aprovecharlas y apropiarse para su respectiva
implementación. Es por ello el interés de integrar metodologías ágiles, con el modelo
CMMI-DEV como una guía para la valoración de los procesos en empresas de desarrollo
de software.
Este trabajo pretende ser un aporte significativo para impulsar el fortalecimiento del
desarrollo de software, en conceptos fundamentales de diferentes metodologías. Para que
los actores puedan implementar soluciones de acuerdo con sus organizaciones, enfocado
principalmente en desarrollo de software y que el modelo que establezcan responda
adecuadamente a sus necesidades.
4.1 Caracterización de empresas de tecnología en Colombia
Las empresas colombianas del sector tecnológico de desarrollo de software en lo que va
corrido del siglo XXI, han crecido y se ha fortalecimiento considerable posicionando a
Colombia en un nivel competitivo en el mercado internacional al contar con muchas
empresas valoradas con procesos de calidad.
68 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
El objetivo particular del MinTIC, es fortalecer la industria de las tecnologías de la
información en áreas que den valor, identificando necesidades de transformación para
generar impacto y aumentar la competitividad de la empresa que a su vez permita
fortalecer la industria TI nacional y se acerque al mayor número de personas en el país.
4.1.1 Empresas colombianas de Tecnología por regiones De acuerdo con el “Censo MinTIC 2014”, el sector TI cuenta con 4.016 empresas a nivel
nacional.
En la figura 4-1 se muestra la participación de las regiones de Colombia donde
Cundinamarca y Bogotá D.C. con 2621 empresas tiene una participación del 64% del
mercado nacional, en segundo lugar está el departamento de Antioquia con 614 empresas
y una participación del 15%, en tercer lugar la región Pacífico con 347 empresas participa
con el 7% del total.(Observatorioti, 2015)
Figura 4-1 Participación de Empresas por Región
Fuente: Elaboración propia con información del Censo Mintic 2014.
15% 0%
5%
64%
4% 0%
7% 4%1%
Antioquia
Boyacá
Caribe
Cundinamarca y Bogotá D.C.
Eje Cafetero
Meta
Pacífico
Santanderes
Otras
Metodología 69
Como se puede identificar el 80% de las empresas está concentrado en dos regiones de
Colombia con tendencia por el uso de las tecnologías de información y en ofrecer
soluciones.
4.1.2 Tamaño de Empresas colombianas por Ventas En la clasificación de las empresas en censo Mintic y Fedesoft (Observatorioti, 2015) ver
figura 4-2.
Se clasificaron las empresas por tamaño de sus ventas, aunque hubo un porcentaje del
34% que no se obtuvo información, se clasificó 40% correspondiente a ventas inferior a
294 Millones de pesos anualmente y sólo el 3% de las empresas tuvo unas ventas
superiores a los 17.000 Millones de pesos.
Figura 4-2 Tamaño de las empresas por ventas
Fuente: Elaboración propia con información del Censo Mintic 2014.
4.1.3 Productos y Servicios de Tecnología de Empresas colombianas
La figura 4-3 presenta los principales servicios que ofrecen las empresas de tecnología
colombianas. El servicio principal es el Manejo de datos en Centros de Cómputo con un
total de 851 compañías y un porcentaje del 25% sobre un total de 3370 empresas que
respondieron todo el estudio. El segundo servicio ofrecido es Desarrollo de Software como
soporte o desarrollo a la medida con 772 empresas estudiadas y una participación del 23%.
0%
10%
20%
30%
40%
50%
294M 294-3000M 3001-17000M 17000M NPI
Menos Entre Entre Mas Sin ubicar
%
70 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Figura 4-3 Productos y Servicios de Tecnología
Fuente: Censo Mintic 2014.
4.1.4 Adopción de modelos de calidad en empresas de tecnología colombianas
Para determinar el porcentaje de utilización de metodologías de calidad, el estudio del
gobierno, tomó el resultado de las empresas que atendieron la encuesta, la muestra
correspondió a 566 empresas.
En la Figura 4-4 se observa que los modelos de metodologías ágiles están cogiendo fuerza
por el apoyo que brinda el Gobierno y actualmente presenta un porcentaje del 34%, sobre
el 12% y el 11% de metodologías IT Mark e ISO respectivamente las empresas que
respondieron a la encuesta muestran la identificación de adoptar y subsistir en desarrollo
de software.
Metodología 71
Figura 4-4 Porcentaje Participación Metodologías
Fuente: Elaboración propia con datos Censo Mintic 2014.
4.2 Clasificación de Empresas Colombianas y la implementación de metodologías ágiles
Colombia a través de entidades estatales como Colciencias, el Ministerio de Tecnologías
de la Información y las Comunicaciones – MINTIC, en acompañamiento de resultados
generados por Fedesoft y el SENA, presenta los estudios correspondientes para enmarcar
políticas que ayuden a mejorar el desarrollo de tecnologías en el país.
Con base en información de Fedesoft se formularon programas orientados a impulsar el
desarrollo de la infraestructura tecnológica y de conectividad en las empresas cómo son:
“Plan Vive Digital”, Programa de Transformación Productiva – PTP y el programa de
fortalecimiento de la industria de tecnologías de la información – FITI.
4.3 Caracterización de los Actores Para caracterizar las empresas de desarrollo de software y de aplicaciones informáticas
que utilizan tecnologías ágiles se contó con esta información y sus índices estadísticos.
4.3.1 Población del estudio Para el presente trabajo se tomó como población de estudio la lista de 28 empresas
presentada en la tabla 4-1 que fueron seleccionadas del programa de Colciencias y el
Mintic, en la “Convocatoria para promover modelos de calidad mundialmente reconocidos
en la industria de TI colombiana”.(Colciencias - a, 2015).
0%
10%
20%
30%
40%
CMMI ISO IT MARK Moprosoft MPS.BR Otras
Metodologías
%
72 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Tabla 4-1 Empresas Objeto del Estudio
Empresas Objeto de Estudio
AMERICAN SMART SYSTEMS & NETWORKS LTDA
ANALITICA SAS
ASESOFTWARE SAS
ASSIST CONSULTORES
BUSINES INFORMATION TECHNOLOGY & SYSTEMS SAS
CCTI SAS
CNT SISTEMAS DE INFORMACION S.A
COLVISTA S.A.S
CONTROL ONLINE SAS
DESYSTEC SAS
DIGITALWARE
EFFECTIVE COMPUTER SOLUTIONS SAS
GRUPO CUBO LTDA
ICONOI SA
IMAGE QUALITY OUTSOURCING SAS
IMECTECH SOLUTIONS SAS
LA CADENA RETAIL SOLUTIONS LTDA
MAREIGUA LIMITADA
MICROSITIOS SAS
NOVASEC SAS
NOVATEC SOLUTIONS LTDA
PRIMESTONE SAS
CLTECH LTDA
SISTEMAS , GESTION Y CONSULTORIA - ALFA GL SAS
SISTEMAS GYG S.A
SMART BUSINESS INTEGRATORS - (SBI)
SOFTWEB ASESORES SAS - B-SECURE
SOLUCIONES GLOBALES SAS
Fuente: Elaboración propia con base en información secundaria.
Metodología 73
4.3.2 Actividades Económicas Escogidas Las empresas nombradas en la tabla 4-1 fueron seleccionadas adicionalmente porque
desarrollan actividades económicas descritas en la tabla 4-2.
Tabla 4-2 Actividades Económicas
Actividades Económicas
Desarrollo de software.
Desarrollo de aplicaciones informáticas.
Diseño y desarrollo de páginas web.
Administración de bases de datos.
Testing, entendido como los servicios orientados a la realización de pruebas a los sistemas de información.
Tercerización de servicios relacionados con las tecnologías de información (ITO).
Alojamiento de datos.
Gerencia de proyectos de TI
Actividades de consultoría informática y actividades de administración de instalaciones informáticas.
Diseño y desarrollo de video juegos.
Fuente: Elaboración con base en (Colciencias & Mintic, 2015)
4.3.3 Clasificación de las empresas por Actividades Económicas Las empresas seleccionadas cuentan con el desarrollo de actividades dentro del marco
avalado para el apoyo empresarial por parte del gobierno colombiano, tal y como se ve
en la figura 4-5.
74 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Figura 4-5 Actividades Económicas por empresa
Fuente: Elaboración propia con base en información secundaria.
0% 20% 40% 60% 80%100%
AMERICAN SMART SYSTEMS &…
ASESOFTWARE SAS
BUSINES INFORMATION TECHNOLOGY &…
CNT SISTEMAS DE INFORMACION S.A
CONTROL ONLINE SAS
DIGITALWARE
GRUPO CUBO LTDA
IMAGE QUALITY OUTSOURCING SAS
LA CADENA RETAIL SOLUTIONS LTDA
MICROSITIOS SAS
NOVATEC SOLUTIONS LTDA
PROCESSA S.A.S.
SISTEMAS GYG S.A
SOFTWEB ASESORES SAS - B-SECURE Desarrollo de software y aplicacionesinformáticas
Diseño y desarrollo de páginas web.
Administración de bases de datos.
Testing, entendido como los serviciosorientados a la realización de pruebas a lossistemas de información.
Tercerización de servicios relacionados conlas tecnologías de información (ITO).
Alojamiento de datos.
Gerencia de proyectos de TI
Actividades de consultoría informática yactividades de administración deinstalaciones informáticas.
Metodología 75
4.3.4 Participación porcentual de las Actividades Económicas que desarrollan las empresas de TI colombianas
En la figura 4-6 se muestra el porcentaje de participación por actividad económica en las
empresas objeto del estudio en el área de tecnología en Colombia.
De la muestra seleccionada encontramos que las actividades económicas que más
desarrollan las empresas colombianas son Desarrollo de Software y Desarrollo de
Aplicaciones Informáticas, con una participación del 38% por ciento del total de 28
empresas seleccionadas.
La consultoría informática le sigue en segundo lugar con el 21% las actividades de
administración de instalaciones informáticas y desarrollo web, el 11% tercerización de
servicios relacionados con las tecnologías de información ITO, con el 9% actividades de
Diseño y desarrollo de páginas web, 6% Actividades de administración de bases de Datos,
el 15 % restante en actividades se dividen en Gerencia de proyectos de TI, Testing o
pruebas a los sistemas de información y alojamiento de datos, con este resultado se
evidencia la necesidad de llevar a cabo la apropiación de modelos de madurez que les
permita mantenerse en el mercado y ser competitivos.
Figura 4-6 Clasificación por actividad económica
Fuente: Elaboración propia con base en información secundaria.
Desarrollo de software y de de aplicaciones
informáticas. 38%
Diseño y desarrollo de páginas web.
9%
Administración de bases de
datos. 6%
Testing, entendido como los servicios
orientados a la realización de pruebas a
los sistemas de información.
5%
Tercerización de servicios
relacionados con las
tecnologías de información
(ITO). 11%
Alojamiento de datos. 4%
Gerencia de proyectos de TI
6%
Actividades de consultoría informática
y actividades de administración de
instalaciones informáticas.
21%
Diseño y desarrollo de video juegos
0%
4.3.5 Implementación de modelos de metodologías ágiles La figura 4-7 nos muestra que la utilización de metodologías ágiles y que las empresas
se han obtenido más certificaciones en IT Mark, con un porcentaje del 28%, le siguen
otras certificaciones no especificadas con el 16%, con un tercer lugar del 13% en
utilización de la metodología CMMI-DEV, demostrando el interés que está tomando la
aplicación de metodologías ágiles en los procesos empresariales y el empleo del modelo
de madurez CMMI-DEV para ser competitivas.
Figura 4-7 Tipos de certificaciones
Fuente: Elaboración propia con base en información secundaria.
TECNOLOGIAS AGILES APLICADAS
16%
CERTIFICACION CMMI13%
CERTIFICACION AGILE SCRUM
7%CERTIFICACION ITMARK
28%
CERTIFICACION ISO 9001:2008
3%
CERTIFICACION ISO 27001:2013
3%
CERTIFICACION ISO 140013%
CERTIFICACION OHSAS3%
CERTIFICACION ITIL3%
CERTIFICACION IEEE3%
CERTIFICACION IQ6%
CERTIFICACION BUREAU VERITAS
6%
CERTIFICACION MICROSOFT6%
4.3.6 Empresas con valoración CMMI Dev V1.3 por SCAMPI (SAS) Desde el año 2014 el instituto ha certificado 76 empresas colombianas en Nivel 3, y 2 en
el Nivel 2 de CMMI Dev y 3 del total de 4016 empresas de tecnología existentes en
Colombia, el porcentaje de participación de las empresas certificadas apoyadas por el
MinTIC y Colciencias correspondió al 1,89%.
En el año 2014 se certificaron en el nivel 3 de CMMI-DEV V1.3, 6 empresas
correspondientes al, 0,1494%. (Ver tabla 4-3)
Tabla 4-3 Certificación CMMI-DEV V1.3 Año 2014
Año CMMI-DEVv1.3 Empresa Mintic Colciencias
2014 Level 3 Indra No
2014 Level 3 Perceptio S.A.S. No
2014 Level 3 Pragma S.A. No
2014 Level 3 SoftManagement S.A. No
2014 Level 3 Tecnoevolución Ltda No
2014 Level 3 Unisys de Colombia S A No Fuente: Elaboración propia con información de https://sas.cmmiinstitute.com/pars
En el año 2015 se certificaron 40 empresas colombianas, una en el nivel 2 y 39 en nivel 3.
La participación de empresas colombianas correspondió al 0,99%.
Sólo una de las empresas que fueron avaladas por el Mintic y Colciencias para apoyar la
implementación de metodologías ágiles fue certificada en Nivel 3. Ver Tabla 4-4.
Tabla 4-4 Certificación CMMI-DEV V1.3 Año 2015
Año CMMI-DEVv1.3
Empresa Mintic - Colciencias
2015 Level 2 Semicrol, S.L. No
2015 Level 3 4SIGHT Technologies SAS No
2015 Level 3 Accenture No
2015 Level 3 Actsis Ltda No
2015 Level 3 Casa de Software Prosof S.A.S. No
2015 Level 3 CASEWARE No
2015 Level 3 Clinical Laboratory Technology (CLTech) No
2015 Level 3 COBISCORP No
2015 Level 3 CODESA No
2015 Level 3 Cognox S.A.S. No
2015 Level 3 COLSIN SAS No
2015 Level 3 DAT@CENTER S.A. No
2015 Level 3 Everis Colombia No
2015 Level 3 Expert Information SAS No
2015 Level 3 GEMINUS SOFTWARE DE COLOMBIA SAS No
2015 Level 3 GEOTECH SOLUTIONS S.A. No
2015 Level 3 Globant No
2015 Level 3 Ingeneo S.A.S. No
2015 Level 3 Ingenian Software S.A.S. No
2015 Level 3 Intelecto Soluciones y Tecnología Ltda No
2015 Level 3 INTERSOFT S.A No
2015 Level 3 Ip Total Software S.A. No
2015 Level 3 Koombea No
2015 Level 3 Lucasian Labs SAS No
2015 Level 3 Nexura Internacional S.A.S. No
2015 Level 3 Oasis IT S.A.S. No
2015 Level 3 Oficina de Cooperación Universitaria (OCU) No
2015 Level 3 OLSoftware SAS No
2015 Level 3 Quipux S.A.S. No
2015 Level 3 RSN Computación Ltda. No
2015 Level 3 Servinte S.A. No
2015 Level 3 SoftCaribbean S.A. No
2015 Level 3 SoftComputo Ltda. No
2015 Level 3 SOFTVALORES S. A. No
2015 Level 3 Software Estratégico S.A.S No
2015 Level 3 Stack Pointer S.A.S. No
2015 Level 3 SYSMAN SAS No
2015 Level 3 Tecnologías Sinergia S.A.S. No
2015 Level 3 Tiqal SAS No
2015 Level 3 COLVISTA S.A.S. SI Fuente: Elaboración con información de https://sas.cmmiinstitute.com/pars
Metodología 81
En el año 2016 se certificaron 7 empresas colombianas, 2 en el nivel 2 y 5 en el nivel 3.
La participación de empresas colombianas correspondió al 1,74%.(Ver Tabla 4-5)
Tabla 4-5 Certificación CMMI-DEV V1.3 Año 2016
Año CMMI-DEV v1.3
Empresa Min TIC Colciencias
2016 Level 2 Flag Soluciones S.A.S No
2016 Level 2 Cltech Ltda No
2016 Level 3 Fiserv Colombia Ltda No
2016 Level 3 Flag Soluciones S.A.S No
2016 Level 3 Jaime Torres C. y S.A. No
2016 Level 3 SOPHOS BANKING SOLUTIONS SAS No
2016 Level 3 Vector ITC Group No Fuente: Elaboración con información de https://sas.cmmiinstitute.com/pars
En el año 2017 se certificaron 24 empresas colombianas en nivel 3. La participación de
empresas colombianas correspondió al 0,59%.
De las empresas avaladas por el Mintic y Colciencias para apoyar la implementación de
metodologías ágiles certificadas en Nivel 3, tuvieron una participación del 32% sobre las
28 empresas con apoyo gubernamental (Ver Tabla 4-6).
Tabla 4-6 Certificación CMMI-DEV V1.3 Año 2017
Año CMMI-DEV v1.3
Empresa Mintic - Colciencias
2017 Level 3 ADA S.A. No
2017 Level 3 ADN Software S.A.S. No
2017 Level 3 Data Tools S.A. No
2017 Level 3 Facture SAS No
2017 Level 3 Informatica y Tecnologia Stefanini Colombia S.A. No
2017 Level 3 iQ Outsourcing SAS No
2017 Level 3 ITAC S.A. No
2017 Level 3 JAIVANA SAS No
2017 Level 3 Land Software and Technology S.A.S. No
2017 Level 3 MAYASOFT INGENIERIA LTDA No
2017 Level 3 Palmerasoft S.A.S No
2017 Level 3 PRONOSTICA S.A.S No
2017 Level 3 SBI S.A.S. No
2017 Level 3 SETI S.A.S. No
2017 Level 3 Soluciones Innovadoras en Tecnología Empresarial S.A.S. No
2017 Level 3 American Smart Systems & Networks AS-NET SI
2017 Level 3 ANALITICA S.A.S. SI
2017 Level 3 CCTI SAS SI
2017 Level 3 CNT Sistemas de Informacion S.A. SI
2017 Level 3 Desystec SAS SI
2017 Level 3 ICONOI S.A. SI
2017 Level 3 La Cadena Retail Solutions Ltda. SI
2017 Level 3 Micrositios S.A.S. SI
2017 Level 3 Sistemas, Gestión y Consultoría Alfa GL S.A.S. SI Fuente: Elaboración propia con información de https://sas.cmmiinstitute.com/pars
Las empresas que tuvieron apoyo de Mintic-Colciencias presentaron una participación del
3.57% del total, las que se certificaron en CMMI DEV v1.3 Nivel 3. (Ver Figura 4-8).
Figura 4-8 Empresas apoyadas por el convenio con certificación CMMI Dev v1.3
Fuente: Elaboración con información de https://sas.cmmiinstitute.com/pars.
EMPRESA CERITIFICACION CMMI; 0.00%
AMERICAN SMART SYSTEMS & NETWORKS LTDA CMMI-DEV
v1.3(Continuous):Maturity Level 3; 3.57% ANALITICA SAS
CMMI-DEV v1.3(Staged):Maturit
y Level 3; 3.57%
ASESOFTWARE SAS NPI; 0.00%
ASSIST CONSULTORES
NPI; 0.00%
BUSINES INFORMATION TECHNOLOGY &
SYSTEMS SAS NPI; 0.00%
CCTI SAS CMMI-DEV v1.3(Staged):Maturity
Level 3; 3.57%
CNT SISTEMAS DE INFORMACION S.A CMMI-DEV v1.3(Staged):Maturity
Level 3; 3.57%
COLVISTA S.A.S CMMI-DEV v1.3(Staged):Maturity
Level 3; 3.57%
CONTROL ONLINE SAS NPI; 0.00%
DESYSTEC SAS CMMI-DEV v1.3(Staged):Maturity
Level 3; 3.57%
DIGITALWARE NPI; 0.00%
EFFECTIVE COMPUTER SOLUTIONS SAS NPI; 0.00%
GRUPO CUBO LTDA NPI; 0.00%
ICONOI SA CMMI-DEV v1.3(Staged):Maturity
Level 3; 3.57%
IMAGE QUALITY OUTSOURCING SAS NPI; 0.00%
IMECTECH SOLUTIONS SAS NPI; 0.00%
LA CADENA RETAIL SOLUTIONS LTDA CMMI-
DEV v1.3(Continuous):Maturity
Level 3; 3.57%
MAREIGUA LIMITADA NPI;
0.00%
MICROSITIOS SAS CMMI-DEV v1.3(Staged):Maturity Level 3;
3.57%
NOVASEC SAS NPI;
0.00%
NOVATEC SOLUTIONS LTDA NPI;
0.00%
PRIMESTONE SAS NPI;
0.00%
Cltech Ltda CMMI-DEV v1.3(Staged):Maturity
Level 2; 3,57%
SISTEMAS , GESTION Y CONSULTORIA - ALFA GL SAS CMMI-DEV v1.3(Staged):Maturity
Level 3; 3.57%
SISTEMAS GYG S.A NPI; 0.00%
SMART BUSINESS INTEGRATORS - (SBI) NPI;
0.00% SOFTWEB ASESORES SAS - B-SECURE NPI; 0.00%
SOLUCIONES GLOBALES SAS NPI;
3.57%
5. RESULTADOS
Este capítulo muestra el avance para obtener el modelo de integración entre CMMI-DEV y
Scrum, en cumplimiento de los objetivos específicos. Primero se caracterizan las empresas
que cumplen con valoración de nivel 2 de CMMI, segundo se identifica la metodología ágil
adecuada, tercero se evalúan los procedimientos ágiles que soportaran la implementación
con CMMI-DEV, por último, se muestra el análisis con un mapa conceptual que integra el
nivel 2 de CMMI con la metodología que plantea Scrum y se concluye con el modelo
integrado.
El organismo que regula y del que es propiedad el modelo CMMI es el SEI (Software
Engineering Institute). El SEI, no es una entidad que expresa un certificado a las
organizaciones evaluadas de manera aprobatoria, sólo acredita a los auditores (los
llamados “lead appraisers” en terminología CMMI). En términos corrientes, esos auditores
elaboran un documento análogo a una certificación (un diploma), en el que se muestran
los datos y resultados de la auditoría, pero no es un documento oficial (SCAMPI Team &
CMMI Institute, 2014).
El único documento oficial que indica resultados de la evaluación es el que se denomina
“Appraisal Disclosure Statement”, estos resultados se obtienen al final de la auditoría,
contiene los datos (organización, patrocinador, participantes, fechas, modelo de madurez
etc.), que elabora el auditor, lo firma, el responsable de la organización evaluada, y es el
que se envía al SEI; con el fin que en su Web aparezca la organización evaluada
(https://sas.cmmiinstitute.com/pars/pars.aspx), la cual estará presente en dicha Web
durante tres años.
Las empresas en Colombia (3) evaluadas y valoradas por CMMI-DEV en el nivel 2 basan
sus resultados en las siguientes áreas de proceso.
86 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Gestión de Requerimientos (REQM).
Planificación del Proyecto (PP).
Monitorización y Control del Proyecto (PMC).
Gestión de Acuerdos con Proveedores (SAM).
Medición y Análisis (MA).
Aseguramiento de la Calidad del Proceso y del Producto (PPQA).
Gestión de Configuración (CM).
5.1 Empresa de desarrollo de software con valoración en procesos en gestión nivel 2 CMMI-DEV.
La empresa seleccionada fue Clinical Laboratory Technology (CLTech), el estudio
realizado fue del área de desarrollo de software. Esta empresa cuenta con 16 años de
experiencia en el desarrollo de software, CLTECH ofrece desarrollo de software para la
sistematización del Laboratorio Clínico y procesos en el área de la salud.
Scampi avaló las áreas de procesos de Nivel 2 correspondiente a CMMI-DEV V1.3 como
se ve en la Tabla 5-1 a excepción del proceso SAM.
Tabla 5-1 Empresa avalada por el SEI Nivel 2
Resultado de la evaluación de gestión nivel 2 CMMI-DEV
Empresa Ciudad Proyectos Evaluados
Persona Participantes Áreas Aprobadas
Cltech Ltda Bogotá 60 73
REQM Satisfecho
PP Satisfecho
PMC Satisfecho
SAM No aplicable
MA Satisfecho
PPQA Satisfecho
CM Satisfecho Fuente: https://sas.cmmiinstitute.com/pars/pars_detail.aspx?a=25403.
Metodología 87
CLTECH también tiene avalado el Nivel 3 de CMMI-DEV V1.3. Se evaluaron las aéreas de
proceso de nivel 3 y arrojó que todos los procesos fueron valorados positivamente (Ver
Tabla 5-2), por el periodo comprendido entre el 30 de octubre de 2015 al 30 de octubre de
2018.
Los resultados de la auditoría respecto a cada una de las áreas de procesos condujeron a
que el tamaño no es relevante y se utilizan los mismos procesos para el desarrollo de
software, independientemente del tamaño del programa o de la unidad básica.
La estructura gerencial de CLTECH no interfiere y se procede independientemente en los
procesos para el desarrollo de software.
Tabla 5-2 Empresa avalada por el SEI Nivel 3
Resultado de la evaluación de gestión nivel 3 CMMI-DEV
Empresa Ciudad Proyectos Evaluados
Persona Participantes
Areas Aprobadas
Cltech Ltda Bogotá 60 73
RD Satisfecho
TS Satisfecho
PI Satisfecho
VER Satisfecho
VAL Satisfecho
OPF Satisfecho
OPD Satisfecho
OT Satisfecho
IPM Satisfecho
RSKM Satisfecho
DAR Satisfecho Fuente: elaboración propia con base en https://sas.cmmiinstitute.com/pars/pars_detail.aspx?a=25403.
Los diferentes proyectos se resuelven con los mismos procesos gestionados para el
desarrollo de software independientemente del tipo de trabajo.
Al evaluar a CLTECH se tuvo en cuenta a toda la Unidad Organizativa, y se descubrió que
una parte de la empresa contiene todos los proyectos de software de desarrollo, el resto
del personal se encarga de áreas diferentes al desarrollo de software. (Ver tabla 5-3).
Tabla 5-3 Factores de Evaluación de la empresa
Nombre Clinical Laboratory Technology (CLTech)
Unidad Organización Área de Desarrollo de Software
Lugar de la Evaluación Bogotá (Colombia)
Unidades Funcionales Organización de tecnología
Analistas Funcionales
Entrenamiento organizacional
Banco de Datos
Organización a nivel Web
Grupo de Calidad
Servicio al Cliente
Descripción del alcance
El portafolio incluye 5 unidades básicas categorizadas en: Desarrollo de Proyectos usando plataforma Java y Desarrollo de Proyectos usando Microsoft.Net Marco de trabajo
Tecnalia y SCAMPI selecciona 3 unidades básicas y 5 funciones de soporte con el fin de obtener información organizacional, la importancia del producto de software y el estado de los proyectos (finalizados o por finalizar).
Método de Evaluación SCAMPI V1.3 A
Modelo Ágil CMMI-DEV v1.3
Factores simples: No relevantes
Ubicación: Empresa multinacional con la fábrica de software está centralizada en Bogotá.
Cliente: Productos estándares para todos sus clientes con tamaño del producto igual. Excepciones personalizaciones particulares con el núcleo igual.
Tamaño: Independientemente del tamaño, los proyectos de la organización se administran de la misma manera.
Estructura organizacional: La fábrica de software centralizado y áreas especializadas que realizan desarrollos para todos los productos que se implementan en los clientes.
Tipo de trabajo: Actividad principal - Desarrollo de software
Tecnología: Plataforma tecnológica productos desarrollados con Java y VS.Net.
Factores de Valor
Proyectos de Java (Tecnología): Java es un lenguaje de programación de computadora de propósito general que es concurrente, basado en clases, orientado a objetos y diseñado específicamente para tener la menor cantidad de dependencias de implementación posible.
Proyectos .Net (Tecnología): Microsoft .NET es un marco de trabajo que permite utilizar diferentes plataformas de hardware facilitando la programación del software.
Subgrupos
Proyectos JAVA: proyectos de desarrollo con plataforma Java
9 personas 3 unidades básicas
Proyectos de Java.
Proyectos .Net: proyectos de desarrollo que utilizan Microsoft .Net framework
10 Personas, 2 unidades básicas:
Proyectos .Net: Fuente: Elaboración propia con información de https://sas.cmmiinstitute.com/pars
5.1.1 Evaluación del recurso humano Para la valoración de los diferentes niveles de madurez de CMMI se hace preciso identificar
el recurso de personal requerido para implantar el modelo de madurez por lo tanto se
realizó un análisis de las empresas que prestan servicios de consultoría para el
aprovisionamiento de las áreas de procesos de los niveles de madurez de CMMI DEV v1.3.
En seguida se evaluó el requerimiento de talento humano para implementar Scrum y
CMMI.
Metodología 89
Sabiendo que el Gobierno Colombiano apoya el desarrollo tecnológico y uno de los
proyectos fue el de “Fortalecer la competitividad de empresas que conforman la Industria
de Tecnologías de Información TI, a través de la adopción de modelos de gestión de
calidad mundialmente reconocidos como en el sector. IT Mark y CMMI-DEV” (Colciencias
- a, 2015).
El proyecto se dividió en empresas Beneficiarias y empresas Ejecutoras. Las empresas
Beneficiarias seleccionadas fueron veintiocho (28) y las ejecutoras fueron seleccionadas
siete (7), acogiendo Fourtelco SAS 1 empresa, GT Consulting SAS 2 empresas, Procesix
Colombia 7 empresas, Seonti 8 empresas, SRC Soluciones & CIA Ltda 4 empresas,
Tecnalia Colombia 5 empresas y Vennex Innevo Axon360 Group 1 empresa. (Ver figura
5-1).
Figura 5-1 Empresas por ejecutor
Fuente: Elaboración propia con base en información secundaria.
5.1.2 Recurso humano requerido para implementar CMMI-DEV. Se pudo identificar que para una solución integral en la mejora de procesos y calidad del
software. Las soluciones para las áreas de tecnología se deben encaminar en los procesos
y desarrollo humano. Para ello se debe contar con personal especializado que imparta
capacitación, apoyo en la implementación y evaluaciones de procesos de software.
0 1 2 3 4 5 6 7 8 9
FOURTELCO SAS
GT CONSULTING SAS
PROCESIX COLOMBIA SAS
SEONTI
SRC SOLUCIONES & CIA LTDA - PRAXISCOLOMBIA
TECNALIA COLOMBIA
VENNEX INNEVO AXON360 GROUP
EMPRESAS por EJECUTOR
90 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Las tecnologías que deben conocer los líderes de procesos para realizar una
implementación en modelos de calidad como CMMI-DEV, para desarrollo, mantenimiento,
software, sistemas e ingeniería también deben conocer de evaluaciones como SCAMPI de
CMMI, Scrum y Control Estadístico de Procesos.
Recurso humano para la implementación de modelos de calidad necesarios para un logro
de los objetivos de las empresas a valorar.
Los roles que con los que se debe partir al implementar una metodología ágil en una
empresa que cuenta con procesos en CMMI-DEV son:
Tutor de dedicación de medio tiempo o más para hacer el seguimiento de la
implementación del proyecto.
Un responsable, coordinador con asignación de medio tiempo y como tal facilitador
durante la implementación.
Equipos de trabajo para la definición de procesos de tiempo completo en toda la
implementación del proyecto, para ello se formarán diferentes equipos de trabajo de
asignaciones temporales para aspectos de definición de procesos y evoluciones de las
soluciones en las áreas de procesos, incluidos en CMMI-DEV.
Los requerimientos anteriores son para empresas que solo intentan certificarse en CMMI-
DEV.
5.2 Metodologías ágiles Como se mencionó en el Capítulo 4, las técnicas más utilizadas dentro de las metodologías
ágiles son Scrum y Programación Extrema estas permiten trabajar por bloques en ciclos
cortos. La compilación entre diferentes métodos está siendo implementada en empresas
que apuestan por innovar y mejorar la gestión de sus proyectos. El objetivo es tomar lo
mejor de las herramientas a disposición y adecuarlas a la organización.
La tendencia en el uso de las diferentes metodologías ágiles es Scrum, éste método es el
más aceptado por gran parte de los desarrolladores de software. Scrum define un marco
de trabajo en el desarrollo de proyectos de software, se ha utilizado con éxito durante los
Metodología 91
últimos 20 años en proyectos con un rápido cambio de requerimientos. Las características
principales se pueden resumir en dos.
El desarrollo de software se realiza mediante iteraciones, denominadas Sprint, con una
duración de 4 semanas. El resultado de cada Sprint es un incremento en el desarrollo de
la aplicación que se muestra al cliente.
La segunda característica corresponde a las reuniones a lo largo del proyecto, entre ellas
destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e
integración(Orjuela Duarte & Rojas, 2008).
El desarrollo de un proyecto con Scrum sería el siguiente:
El propietario de producto crea el Backlog con la priorización de las tareas a ejecutar
para el funcionamiento apropiado del producto deseado. Estos elementos son descritos
en forma de historias que serán descompuestos en tareas durante el ciclo de vida.
Todos los participantes del equipo Scrum se reúnen para una junta de Planificación del
Sprint, en esta junta se determina por parte del propietario del producto qué elementos
del Backlog serán comprometidos por el equipo para su construcción.
Durante el Sprint, estos elementos son descompuestos en tareas conforme se van
descubriendo los elementos necesarios para satisfacer la elaboración del avance del
desarrollo de software.
Para realizar seguimiento del desarrollo del proyecto diariamente, los desarrolladores
trabajan para crear los elementos del Incremento y realizan reuniones llamadas Scrum
Diario, en el cual se resuelven las dudas y los impedimentos que existen para poder
continuar con el trabajo, estas reuniones no deben superar los 15 minutos y después
de iniciada no se debe cambiar además de tratar de realizarla en el mismo lugar y a la
misma hora.
92 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
En estas reuniones se tienen unas guías específicas, todos los participantes del
proyecto pueden ingresar, pero solo los involucrados en el proyecto; en particular el
equipo de desarrollo y Scrum Master. En la reunión el equipo contesta a tres preguntas.
¿Qué ha hecho desde ayer?
¿Qué es lo que hará hoy?
¿Qué problema o impedimento tiene para alcanzar el objetivo hasta el próximo sprint diario?
Al final del Sprint se realizan las juntas de revisión y de retrospectiva. En las reuniones
de seguimiento el propietario del producto verifica los desarrollos a conformidad y en
la junta de retrospectiva se evalúa el trabajo realizado por el equipo de desarrollo para
optimizar el proceso ya que todos los miembros del equipo dejan sus impresiones sobre
el sprint.
El desarrollo realizado para cada Sprint es un incremento, el cual deberá tener la
calidad y funcionalidad para el cliente. Si se decide que será usado, se implementa en
producción para su uso.
Posteriormente se verifica la programación del siguiente Sprint y se inicia otro ciclo
para crear un nuevo incremento. (Schwaber & Sutherland, 2011)
A continuación se modela el marco de trabajo SCRUM (Ver Figura 5-2) donde se muestra
al propietario del proyecto la visión global a desarrollar y hace participe al Scrum Master
para lograr el incremento proyectado con el equipo de desarrollo el cual notificara el
alcance a cada backlog para obtener el incremento para el próximo Sprint, de esta manera
retorna al dueño del producto y realiza los cambios pertinentes para cumplir con los
compromisos adquiridos.
Figura 5-2 Modelo de procesos de SCRUM
Fuente: Elaboración propia con base en información secundaria.
5.3 Integración de CMMI-DEV con Scrum
5.3.1 Fases determinadas en el modelo para lograr la integración de CMMI-DEV y SCRUM
Planificación del proyecto: Esta fase contempla el establecimiento y el mantenimiento del presupuesto y el calendario.
Se Identifican los riesgos del proyecto para determinar los compromisos y que éstos
queden plenamente identificados. Esta fase es responsable de establecer el plan para la
gestión de los datos y del proyecto. (Ver Figura 5-3).
Figura 5-3 Planificación de proyecto CMMI-DEV
Fuente: Elaboración propia con base en información secundaria.
Gestión de Requerimientos:
Fase que involucra la comprensión, obtención y entendimiento de los requerimientos, el
gestionamiento de sus cambios con los participantes autorizados, mantiene la trazabilidad
bidireccional e identifica inconsistencias entre el avance del proyecto y los requerimientos
ajustados según la necesidad. (Ver Figura 5-4).
Metodología 95
Figura 5-4 Gestión de riesgos CMMI-DEV y SCRUM
Fuente: Elaboración propia, con base en información secundaria
Gestión de Riesgos:
Fase donde se dan a conocer con detalles todos los requerimientos y tiempos de
desarrollo para poder identificar los posibles retrasos antes de que ocurran. (Ver Figura
5-5).
Figura 5-5 Gestión de riesgo CMMI-DEV y SCRUM
Fuente: Elaboración propia con base en información secundaria.
Monitorización y control del proyecto:
Fase donde se involucran las actividades de monitoreo de los parámetros de planificación
del proyecto, los compromisos, los riesgos del proyecto, la gestión de datos y la
participación de los Stakeholders. (Ver Figura 5-6).
96 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Figura 5-6 Monitorización y control del proyecto CMMI-DEV y SCRUM
Fuente: Elaboración propia con base en información secundaria.
Gestión de la configuración:
Fase donde se efectúa el control de versiones de acuerdo a la base de entregas acordadas
por medio de un sistema de administración de la configuración, los cambios son
monitoreados y controlados mediante la gestión de cambios, el control de liberaciones y la
gestión de la construcción. (Ver Figura 5-7).
Figura 5-7 Gestión de la configuración CMMI-DEV y SCRUM
Fuente: Elaboración propia con base en información secundaria.
Medición y Análisis:
Metodología 97
Fase para el desarrollo de la capacidad de medición en el desarrollo de software, para ello
se elabora un plan de métricas que permita medir la productividad para satisfacer las
necesidades del cliente, las maneras de obtener las métricas se basan en los
procedimientos de desarrollo, aplicaciones y orígenes de datos. (Ver Figura 5-8).
Figura 5-8 Medición y análisis CMMI-DEV y SCRUM
Fuente: Elaboración propia con base en información secundaria.
Verificación:
Fase para verificar que el módulo del producto final se desarrolle de acuerdo a los
requerimientos especificados. (Ver Figura 5-9).
Figura 5-9 Verificación CMMI-DEV y Scrum
Fuente: Elaboración propia con base en información secundaria.
En la tabla 5-4 se establece la relación entre CMMI-DEV y SCRUM
Tabla 5-4 Relación de CMMI-DEV con SCRUM CMMI-DEV Prácticas de Scrum
Planificación de Proyecto Planificación del Sprint
Backlog del Producto
Backlog del Sprint
Ciclo de vida Scrum
Gráficos Burndown
Históricos de backlogs
Monitoreo y Control de Proyecto Gráficos Burndown
Reuniones Diarias
Reuniones de Revisión
Reuniones Retrospectivas
ScrumMaster
Medición y Análisis Reuniones Diarias
Reuniones retrospectivas
Reunión de Revisión
Planificación del Sprint
ScrumMaster
Propietario de Proyecto
Gestión de Requerimientos Backlog del Producto
Backlog del Sprint
Planificación del Sprint
Reunión de Revisión
Reuniones retrospectivas
Propietarios del Producto
Cliente in-situ
Gestión de la Configuración Reuniones Diarias
Gestión de Riesgos Reuniones Diarias
Revisión de Sprint
ScrumMaster
Propietarios del producto
Fuente: Elaboración propia con base en información secundaria.
Metodología 99
5.3.2 Roles para la implementación CMMI-DEV y Scrum
Para implementar modelos de madurez de manera eficiente es imprescindible que los
integrantes de la empresa conozcan plenamente las características de los marcos de
referencia, en este caso CMMI-DEV y metodología ágil Scrum; los roles deben ser muy
completos, para ello se tuvo como referente empresas que conviven con CMMI-DEV y
Scrum en el desarrollo de software. Los roles definidos son:
Líder de proyecto.
Administrador de planificación.
Administrador de desarrollo.
Administrador de calidad.
Administrador de configuración.
Líder de proyecto
Rol designado para dirigir al equipo, verificar que todos reporten y cumplan con sus
trabajos asignados y que las actividades realizadas por el equipo estén enmarcadas en la
calidad pactada en el plan del proyecto además de encargarse de la motivación
permanente del equipo.
Administrador de planificación
Rol para generar la planificación de todo el equipo en común acuerdo, realizar el
seguimiento del trabajo, hacer cumplir el calendario, facilitar y dirigir al equipo de
planificación, además de solucionar los conflictos que se presenten.
Administrador de configuración
Rol para establecer el control de versiones de acuerdo a la base de entregas acordadas
por medio de un sistema de administración de la configuración, monitorear y controlar los
cambios, controlar liberaciones y gestionarla construcción, apoyar el equipo para obtener
100 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
las herramientas para que pueda realizar su trabajo. Conseguir lo necesario para crear un
plan de configuración para ejecutar su gestión.
Administrador de calidad
Rol que se encarga de apoyar al equipo en la estandarización de procedimientos para
obtener un trabajo uniforme, gestionar el plan de calidad, modelar las revisiones de los
productos generados y determinar las necesidades en los procesos de calidad del
producto.
Administrador de desarrollo
Rol cuya función es la de guiar y dirigir el equipo de desarrollo, integrar el trabajo en la fase
de diseño, implementar y encargarse de la ejecución de pruebas de desarrollo de un
producto.
Se encarga de dirigir el diseño, la implementación y ejecución de pruebas del proyecto
como también la realización de las fases de desarrollo siguiendo los estándares propuestos
y generando los productos en cada fase.
5.4 Modelamiento ágil
Los procedimientos ágiles en la implementación con eficiencia en el desarrollo de
proyectos de software son conocidos porque están definidos en el manifiesto ágil.
De acuerdo al análisis de los diferentes marcos de trabajo se concluye que Scrum es la
metodología del “Cómo” implementar desarrollo de software el cual es pertinente para
desarrollar el “Qué” de CMMI-DEV en nivel 2 y 3.
5.5 Mapa conceptual Figura 5-10 Mapa Conceptual integración CMMI-DEV NIVEL 2 Y SCRUM
Fuente: Elaboración propia con base en información secundaria.
En la figura 5-10 se muestra el mapa conceptual definido para la Integración de Modelo de
Madurez de Capacidades con el marco de desarrollo ágil de software.
El modelo CMMI-DEV brinda una orientación de desarrollo de buenas prácticas en el nivel
2 gestionado por etapas.
Este nivel está conformado por siete áreas de proceso y a su vez categorizadas en gestión
de proyectos y gestión de soporte. En la gestión de proyectos se agrupan: Gestión de
Requerimientos, Planificación del Proyecto, Monitorización y Control de Proyecto y Gestión
de Acuerdos de Proveedores, y en la gestión de soporte se agrupan Gestión de la
Configuración, Medición y Análisis Aseguramiento de la Calidad del Proceso y del
Producto.
SCRUM marca las pautas de cómo implementar el desarrollo del software con los procesos
que suministra el modelo CMMI-DEV nivel 2, cuenta con los actores Product Owner,
ScrumMaster, Development Team y los Stakeholders.
Stakeholders son los interesados directos; son el objetivo para el que cual se crea un
producto o servicio que tienen un interés en el proyecto y participan junto con el Product
Owner en la Gestión de los Requerimientos, la Gestión de la Configuración, los
Acuerdos de Niveles de Servicio.
Product Owner ayuda a definir la sucesión de pedidos del equipo de Scrum, ayuda a
priorizar las unidades de trabajo del equipo de Scrum y comunicar continuamente el
progreso a los interesados, para ello promueve determinadas áreas de los procesos
de CMMI-DEV como identificación de los Requerimientos, la Planeación del Proyecto,
la Monitorización y Control del Proyecto, Medición y Análisis, en el Aseguramiento de
la Calidad del Proceso y del Producto y en los Acuerdo de Niveles de Servicio.
El Product Owner es el dueño del proyecto e interactúa con él cliente como parte de
los Stakeholders.
Metodología 103
ScrumMaster facilita y participa en la Planeación del Proyecto, Monitorización y Control
del Proyecto, la Medición y Análisis, en el Aseguramiento de la Calidad del Proceso y
del Producto, Gestión de la Configuración y en los Acuerdo de Niveles de Servicio.
Development Team trabaja en la Planeación del Proyecto, la Monitorización y Control
del Proyecto, Medición y Análisis, y en el Aseguramiento de la Calidad del Proceso y
del Producto.
5.5.1 Descripción del Modelo
El modelado de la integración de CMMI-DEV nivel 2 y SCRUM está organizado en una
matriz donde las filas representan los roles 1) Stakeholders, 2) Product Owner, 3)
ScrumMaster y 4) Development Team y las columnas representan las siete áreas de
proceso 1) Gestión de Requerimientos, 2) Planificación del Proyecto, 3) Monitoreo y
Control de Proyecto, 4) Medición y Análisis 5) Aseguramiento de la Calidad del Proceso y
del Producto 6) Gestión de la Configuración y 7) Gestión de Acuerdos de Proveedores
(Figura 5-11).
Figura 5-11 Modelo de integración CMMI-DEV nivel 2 y SCRUM
Fuente: Elaboración propia con base en información secundaria
ROLES
Stakeholders
El cliente crea y gestiona la lista de requerimientos del producto o proyecto, donde quedan
reflejadas sus expectativas, valor, costo y entregas, posteriormente participa en los
requerimientos gestionados por el Product Owner, y se identifican las inconsistencias que
afectan a los planes y otros artefactos del proyecto.
Las prácticas específicas a tener en cuenta son:
Entender claramente el significado de los requerimientos sin ambigüedades para que
estos sean los correctos y adecuados.
Conseguir el compromiso de los participantes y/o interesados. Gestionar cambios a los
requerimientos por personas responsables.
Conservar la trazabilidad bidireccional de los requerimientos dada una comunicación
pertinente.
Igualar inconsistencias entre los requerimientos y otros productos del proyecto
evaluándolos con todos los miembros relevantes dentro de la organización.
En las áreas de proceso los stakeholders participan de la siguiente forma:
En Gestión de la Configuración proveen el informe preciso acerca del estado de la
configuración a todos los interesados, lo que implica identificar los ítems de configuración,
realizar sobre ellos cambios de manera controlada para satisfacer la configuración. Con el
fin de lograr los objetivos se realizan las siguientes prácticas:
Revisar productos adquiridos internos y externos al desarrollo con responsabilidad.
Ejecutar acuerdos con proveedores incluso dentro de la organización en diferentes
áreas en cuanto tiempo, costo, calidad.
Aceptar el producto adquirido que cumpla con las respectivas especificaciones ya
convenidas.
Validar por etapas de los productos que periódicamente deben conseguir.
106 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
En Gestión de Acuerdo con Proveedores; deben comunicar el grado de satisfacción del
proyecto y por los proveedores. Las actividades ejecutadas son:
Revisar productos adquiridos según especificaciones técnicas definidas y valoradas.
Ejecutar acuerdos con proveedores costo, calidad y tiempo de entrega.
Aceptar el producto adquirido si cumple acuerdos previos.
Validación por etapas de los productos que requiera el desarrollo.
Product Owner
El Product Owner es la persona encargada de guiar el éxito del desarrollo de software, de
acuerdo a lo requerido por los Stakeholders. Sus principales responsabilidades están en
la revisión del Sprint junto a los miembros del Equipo de Desarrollo y así obtener
retroalimentación que garantice conformidad de todos los interesados también se encarga
de direccionar para donde el equipo de desarrollo dirige su esfuerzo, recolecta los
requerimientos identificando las características funcionales y da la prioridad
correspondiente, los convierte en un backlog por lo tanto genera las prioridades da las
fechas de entrega y contenidos de cada una, al finalizar acepta o rechaza el producto
cuando realiza la entrega en cada Sprint
Participa a lo largo del proyecto en diferentes áreas de procesos entre las cuales se
encuentra la definición de los requerimientos con las siguientes prácticas:
Percibir el significado de los requerimientos sin ambigüedades.
Conseguir compromiso de los participantes/interesados y que los requerimientos sean
los correctos y adecuados.
Gestionar cambios a los requerimientos por personas responsables.
Conservar la trazabilidad bidireccional de los requerimientos dad una comunicación
pertinente.
Igualar inconsistencias entre los requerimientos y otros productos del proyecto
evaluándolos con todos los miembros relevantes dentro de la organización.
El Product Owner participa en las áreas de proceso así:
En Planeación del Proyecto establece estimaciones de las dimensiones del proyecto
mediante la ejecución de las siguientes prácticas específicas:
Estimar el alcance del proyecto.
Estimar atributos de las tareas y de los productos del proyecto.
Definir el ciclo de vida del proyecto.
Estimar esfuerzo y costo del proyecto.
Desarrolla el plan de proyecto mediante un plan que es empleado para administrar el
proyecto con las siguientes prácticas:
Establecer el cronograma y el presupuesto del proyecto.
Identificar los riesgos del proyecto.
Planificar la administración de datos del proyecto.
Planificar recursos necesarios para el proyecto.
Planificar la adquisición de conocimiento y habilidades.
Planificar la participación de los interesados en el proyecto.
Establecer el plan del proyecto.
Metodología 109
El Product Owner obtiene el compromiso de los interesados acerca del plan de proyecto
establecido y seguidos a lo largo del proyecto, las prácticas para verificar son:
Reconocer todos los planes que puedan afectar al proyecto.
Concertar el plan de proyecto para reflejar recursos estimados vs. Disponibles.
Conseguir responsabilidades respecto al plan.
En el área de Monitoreo y Control del Proyecto gestiona las acciones correctivas cuando
los resultados se desvían significativamente del plan las prácticas empleadas en:
Analizar temas pendientes.
Ejecutar acciones correctivas.
Administrar acciones correctivas.
En Medición y Análisis alinea las actividades de medición y análisis con los objetivos y
necesidades de información con las siguientes prácticas:
Establecer objetivos de las mediciones
Especificar métricas
Especificar procedimientos de recolección y almacenamiento de datos
Especificar procedimientos de análisis.
En Aseguramiento de la Calidad de Productos y Procesos Evalúa imparcialmente,
estándares y descripciones de procesos vigentes, al final de cada iteración el equipo
demuestra al cliente los requerimientos que ha conseguido completar. Tras una inspección
del resultado real del proyecto hasta ese momento, y considerando el esfuerzo que ha sido
necesario para realizarlo, el cliente solicita los cambios que necesita y vuelve a planifica el
proyecto, las prácticas son:
Evaluar procesos objetivamente.
Evaluar productos y servicios objetivamente.
En Gestión de la Configuración establece líneas base para los artefactos propuestos bajo
la administración de la configuración las prácticas son:
110 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Identificar ítems de configuración.
Establecer un sistema de administración de la configuración.
Crear o liberar líneas base.
En Gestión de Acuerdos con Proveedores se establecen y se mantienen los respectivos
acuerdos las prácticas utilizadas son:
Determinar tipo de adquisición.
Seleccionar proveedores.
Establecer acuerdos con proveedores.
No solamente los acuerdos con los proveedores son externos también existen los acuerdos
internos los niveles de acuerdos de operación (OLA) con las prácticas.
Determinar tipo de adquisición.
Seleccionar proveedores adentro de la organización.
Establecer acuerdos con proveedores adentro de la organización.
ScrumMaster
El ScrumMaster es el profesional responsable que se use Scrum, es él diplomático del
equipo y es quien ayuda a alcanzar el máximo nivel de productividad posible.
Verifica que todos los miembros asistan a tiempo a las diferentes actividades Scrum
acordadas.
Se encarga de proteger al equipo de desarrollo para que nadie interfiera en su forma de
trabajar, quita impedimentos que se presenten dentro de los integrantes del equipo Scrum.
Acompaña al equipo de desarrollo día a día asegurando la cooperación interna y externa
al equipo, apoya la multifuncionalidad para el crecimiento particular.
Participa a lo largo del proyecto en diferentes áreas de procesos, entre las cuales se
encuentran Planificación y el objetivo es lograr el compromiso de los interesados acerca
del plan de proyecto plenamente establecido y son mantenidos a lo largo del proyecto y
las prácticas para verificar son:
Revisar todos los planes que puedan afectar al proyecto y gestionar la solución.
Ajustar el plan de proyecto para reflejar recursos estimados vs. Disponibles.
Obtener compromisos respecto al plan de toda la organización.
La participación del Scrum Master en las áreas de proceso corresponde a:
En el área de Monitoreo y Control del Proyecto, se encarga del monitoreo respecto a lo
establecido en el plan del proyecto las prácticas empleadas son:
Monitorear los parámetros de planificación del proyecto.
Monitorear los compromisos.
Monitorear los riesgos del proyecto.
Monitorear la gestión de datos del proyecto.
Monitorear la participación de los interesados.
Conducir revisiones de avance.
Conducir revisiones de cumplimiento de hitos.
En Medición y Análisis del Proyecto provee los resultados de la medición que satisface las
necesidades y objetivos de información las prácticas empleadas son:
Recolectar datos.
Analizar datos.
Almacenar datos y resultados.
Comunicar resultados.
En Aseguramiento de la Calidad de Productos y Procesos, es necesario que el
ScrumMaster provea la realimentación objetiva respecto al no cumplimiento de los
estándares descriptores de proceso, comunicando a las áreas encargadas para su
corrección y obtener una resolución asegurada las prácticas empleadas son:
Metodología 113
Comunicar y asegurar la resolución de cuestiones de calidad.
Establecer y mantener registros de las actividades de aseguramiento de la calidad.
En Gestión de la Configuración es responsabilidad del ScrumMaster verificar los artefactos
monitorearlo y controlarlos las prácticas empleadas son:
Monitorear pedidos de cambio.
Controlar ítems de configuración.
En Administración de Acuerdos con Proveedores se encarga de satisfacer los acuerdos y
que los proveedores sean satisfechos las prácticas empleadas son:
Revisar productos adquiridos.
Ejecutar acuerdos con proveedores.
Aceptar el producto adquirido.
Validación por etapas de los productos.
Development Team
El equipo de desarrollo está conformado por todas las personas requeridas para para el
desarrollo del producto. Es el único responsable por la construcción y calidad del producto.
El equipo de desarrollo es autónomo en su proceder. Significa que no existe un gerente de
proyecto interno o externo que asigne y supervise las tareas, ni que determine como se
debe resolver el trabajo asignado. El equipo es quien determina cómo realizará el trabajo
y qué hacer ante las diferentes adversidades que se generen, el objetivo es generar
software funcionando y con valor para el cliente, lo que conduce a un software incremental.
El equipo de desarrollo está conformado por desarrolladores de software encargados en
la construcción del producto además de estar completamente comprometido. Es el equipo
el responsable por la calidad del producto para logarlo debe realizar prácticas específicas:
Comprender el significado de los requerimientos.
Obtener compromiso de los participantes/interesados acerca de los requerimientos.
Administrar cambios a los requerimientos.
Mantener la trazabilidad bidireccional de los requerimientos.
Identificar inconsistencias entre los requerimientos y otros productos del proyecto.
El equipo de desarrollo cuenta con responsabilidades a satisfacer:
Calcular el tiempo de desarrollo requerido para cada uno de los módulos de producto
a desarrollar.
Asegurar al comienzo de cada Sprint la construcción de un conjunto determinado de
avances en determinado tiempo.
Responsable por la entrega del producto terminado en cada Sprint de forma periódica
hasta la entrega final.
El rol de Development Team en las áreas de proceso se refleja en: El área de Monitoreo y Control del Proyecto por parte del Equipo de Desarrollo gestiona
acciones correctivas cuando los resultados del proyecto se desvían, lo realiza midiendo el
avance respecto a lo establecido en el plan del proyecto las prácticas específicas son:
Analizar temas pendientes
Realiza revisiones de avance
Realiza revisiones de cumplimiento de hitos
Ejecutar acciones correctivas
Administrar acciones correctivas
En el área de Medición y Análisis del Proyecto el Equipo de Desarrollo se ajusta para
obtener niveles de aceptación específicas cuenta para ello:
Métricas que permitan determinar si se cumplen o no con los objetivos.
Elementos de obtención de las métricas.
116 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
En Aseguramiento de la Calidad de Productos y Procesos el Equipo de Desarrollo una vez
establecidos los procesos estándares, realiza prácticas específicas para garantizar la
calidad de la siguiente manera:
Evalúa los procesos realizados, los artefactos producidos de proceso aplicables.
Identifica no conformidades, comunicar a los responsables, y asegurar su resolución.
Informar a los interesados (ScrumMaster, Product Owner) el resultado de las
actividades de aseguramiento de la calidad.
ÁREAS DE PROCESO
Gestión de Requerimientos (REQM)
La integración de metodologías ágiles con modelos de calidad está determinada por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia. La gestión de requerimientos la realiza el Product Owner con el
Stakeholder determinado y lo materializa en el backlog este a su vez busca maximizar la
rentabilidad del producto beneficiando todas las partes.
Las asignaciones de los requerimientos se ajustan a la planificación realizada con los
tiempos asignados a cada requerimiento de acuerdo a lo determinado por el equipo de
desarrollo. La trazabilidad y la consistencia entre los requerimientos y los productos de
trabajo lo determinaran en cada sprint como las reuniones de retrospectiva.
Metodología 117
En la tabla 5-5 se presentan los objetivos específicos asociados a prácticas específicas.
Tabla 5-5 Gestión de Requerimientos (REQM)
Objetivo Específico Prácticas Específicas
SG 1 Gestión Requerimientos
Los requerimientos son administrados, y
se identifican las inconsistencias entre los
requerimientos y los planes y otros
artefactos del proyecto.
SP 1.1 Comprender el significado de los
requerimientos
SP 1.2 Obtener compromiso de los
participantes/interesados acerca de los
requerimientos
SP 1.3 Administrar cambios a los
requerimientos
SP 1.4 Mantener la trazabilidad
bidireccional de los requerimientos
SP 1.5 Identificar inconsistencias entre los
requerimientos y otros productos del
proyecto
Fuente: (Software Engineering Institute, 2010)
Figura 5-15 Gestión de Requerimientos REQM
Fuente: Elaboración propia con base en información secundaria
Planificación del Proyecto (PP)
La integración de metodologías ágiles con modelos de calidad está determinada por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia en la planificación del proyecto, los equipos estimarán,
planificarán y llevarán a cabo el trabajo real de un incremento o iteración a la vez.
Dado que el equipo de desarrollo se compromete a realizar determinadas iteraciones por
día de acuerdo a lo planteado en el backlog que es generado por él Product Owner es
necesario validar que se realice el seguimiento de avance establecido en el plan del
proyecto.
Tabla 5-6 Planificación del Proyecto (PP)
Objetivos Específicos Prácticas Específicas
SG 1 Monitorear el Proyecto El avance y la
performance del proyecto se monitorean
respecto a lo establecido en el plan de
proyecto.
SP 1.1 Monitorear los parámetros de
planificación del proyecto
SP 1.2 Monitorear los compromisos
SP 1.3 Monitorear los riesgos del proyecto
SP 1.4 Monitorear la gestión de datos del
proyecto
SP 1.5 Monitorear la participación de los
interesados
SP 1.6 Conducir revisiones de avance
SP 1.7 Conducir revisiones de cumplimiento
de hitos
SG 2 Gestionar Acciones Correctivas Cuando
los resultados o la performance del proyecto
se desvían significativamente del plan se
gestionan acciones correctivas.
SP 2.1 Analizar temas pendientes
SP 2.2 Ejecutar acciones correctivas
SP 2.3 Administrar acciones correctivas
Fuente: (Software Engineering Institute, 2010).
Figura 5-16 Planificación del Proyecto (PP)
Fuente: Elaboración propia con base en información secundaria
121 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
Monitoreo y Control del Proyecto (PMC)
La integración de metodologías ágiles con modelos de calidad está determinado por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia en el monitoreo y control se realiza con lo establecido en el plan
del proyecto identificando los parámetros, compromisos, riesgos, datos del proyecto que
conlleven a revisiones de cumplimiento en diferentes fases como los realizados por el
ScrumMaster diariamente o las evaluaciones por parte del Producto Owner y el cliente en
cada iteración de Sprint.
Tabla 5-7 Monitoreo y Control del Proyecto (PMC)
Objetivos Específicos Prácticas Específicas
SG 1 Monitorear el Proyecto El avance y la
performance del proyecto se monitorean
respecto a lo establecido en el plan de
proyecto.
SP 1.1 Monitorear los parámetros de
planificación del proyecto
SP 1.2 Monitorear los compromisos
SP 1.3 Monitorear los riesgos del proyecto
SP 1.4 Monitorear la gestión de datos del
proyecto
SP 1.5 Monitorear la participación de los
interesados
SP 1.6 Conducir revisiones de avance
SP 1.7 Conducir revisiones de cumplimiento
de hitos
SG 2 Gestionar Acciones Correctivas
Cuando los resultados o la performance del
proyecto se desvían significativamente del
plan se gestionan acciones correctivas.
SP 2.1 Analizar temas pendientes
SP 2.2 Ejecutar acciones correctivas
SP 2.3 Administrar acciones correctivas
Fuente: (Software Engineering Institute, 2010).
Resultados 122
Figura 5-17 Monitoreo y Control del Proyecto (PMC)
Fuente: Elaboración propia con base en información secundaria
Resultados
Medición y Análisis (MA)
La integración de metodologías ágiles con modelos de calidad está determinado por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia, en la medición y análisis los encargados de generar las métricas
es él Product Owner y él ScrumMaster entre los dos generan las actividades de medición
acordes con la planificación del proyecto, recolectando, analizando y comunicando datos
con el fin de establecer métricas que satisfagan las necesidades y objetivos de información.
Los objetivos y prácticas incluidas en entornos ágiles de Scrum con la involucración
continua del cliente y de los usuarios finales son fundamental para el éxito de cualquier
proyecto.
Tabla 5-8 Medición y Análisis MA
Objetivos Específicos Prácticas Específicas
SG 1 Alinear actividades de medición
y análisis Las actividades de medición
y análisis están alineadas con los
objetivos y necesidades de
información.
SP 1.1 Establecer objetivos de las
mediciones
SP 1.2 Especificar métricas
SP 1.3 Especificar procedimientos de
recolección y almacenamiento de
datos
SP 1.4 Especificar procedimientos de
análisis
SG 2 Proveer los resultados de la
medición Se proveen mediciones que
satisfacen necesidades y objetivos de
información.
SP 2.1 Recolectar datos
SP 2.2 Analizar datos
SP 2.3 Almacenar datos y resultados
SP 2.4 Comunicar resultados
Fuente: (Software Engineering Institute, 2010).
Resultados 124
Figura 5-18 Medición y Análisis (MA)
Fuente: Elaboración propia con base en información secundaria.
Resultados
Aseguramiento de la Calidad de Productos y Procesos (PPQA)
La integración de metodologías ágiles con modelos de calidad está determinado por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia, con el aseguramiento de calidad, en productos y procesos son
tanto el Product Owner y él ScrumMaster los que evalúan objetivamente los procesos y
estándares vigentes, visualizando una mejora continua con la divulgación de la calidad
requerida y determinando las actividades de aseguramiento, las evaluaciones objetivas se
realizan en procesos y productos de trabajo que serán evaluados, e integrando los
resultados de las evaluaciones en la dinámica de trabajo del equipo con herramientas y
retrospectivas constantes.
Tabla 5-9 Aseguramiento de la Calidad de Productos y Procesos (PPQA)
Objetivos Específicos Prácticas Específicas
SG 1 Evaluar objetivamente procesos y
artefactos. Se evalúa objetivamente la
adhesión de los procesos y artefactos a
los estándares y descripciones de
proceso vigentes.
SP 1.1 Evaluar procesos objetivamente
SP 1.2 Evaluar productos y servicios
objetivamente
SG 2 Proveer realimentación
objetivamente El no cumplimiento de los
estándares y descripciones de proceso
es objetivamente comunicado y su
resolución asegurada.
SP 2.1 Comunicar y asegurar la
resolución de cuestiones de calidad
SP 2.2 Establecer y mantener registros
de las actividades de aseguramiento de
la calidad
Fuente: (Software Engineering Institute, 2010).
Resultados 126
Figura 5-13 Aseguramiento de la Calidad de Productos y Procesos (PPQA)
Fuente: Elaboración propia con base en información secundaria
Resultados
Gestión de la Configuración (CM)
La integración de metodologías ágiles con modelos de calidad está determinada por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia, la gestión de la configuración por medio del Producto Owner
establece las líneas base para los diferentes artefactos, de esta manera establece un
sistema de gestión y monitorea la configuración.
La gestión de la configuración está afinadamente integrada a los ritmos de cada equipo
con el fin de minimizar la distracción y logar que realice el trabajo de acuerdo a estándares
establecidos.
Tabla 5-10 Gestión de la Configuración (CM)
Objetivos Específicos Prácticas Específicas
SG 1 Establecer líneas base Se establecen líneas base de los
artefactos puestos bajo gestión de la
configuración.
SP 1.1 Identificar ítems de configuración
SP 1.2 Establecer un sistema de gestión
de la configuración
SP 1.3 Crear o liberar líneas base
SG 2 Monitorear y controlar cambios
Los cambios a los artefactos son
monitoreados y controlados.
SP 2.1 Monitorear pedidos de cambio
SP 2.2 Controlar ítems de configuración
Fuente: (Software Engineering Institute, 2010).
Resultados 128
Figura 5-19 Gestión de la Configuración (CM)
Fuente: Elaboración propia con base en información secundaria
Resultados
Gestión de Acuerdos con Proveedores (SAM)
La integración de metodologías ágiles con modelos de calidad está determinado por la
implementación particular de cada empresa, la cual determinará el grado de inmersión en
cada marco de referencia, en la gestión de acuerdos con proveedores es crucial el uso
metodologías agiles como Scrum, permanente la comunicación fluye con el cliente, dando
flexibilidad a los requerimientos que se manejan por medio del Product Owner por lo tanto
se encarga de establecer y mantener los acuerdos pero en desarrollo, conllevando a poder
variar los requerimientos para adaptarse a las necesidades del cliente y ganar en términos
económicos para las partes.
Tabla 5-11 Gestión de Acuerdos con Proveedores (SAM)
Objetivos Específicos Prácticas Específicas
SG 1 Establecer acuerdos con proveedores Se establecen y mantienen acuerdos con proveedores.
SP 1.1 Determinar tipo de adquisición
SP 1.2 Seleccionar proveedores
SP 1.3 Establecer acuerdos con proveedores
SG 2 Satisfacer acuerdos con proveedores Los acuerdos con los proveedores son satisfechos por el proyecto y por los proveedores.
SP 2.1 Revisar productos adquiridos
SP 2.2 Ejecutar acuerdos con proveedores
SP 2.3 Aceptar el producto adquirido
SP 2.4 Transicionar productos
Fuente: (Software Engineering Institute, 2010).
Figura 5-20 Gestión de Acuerdos con Proveedores (SAM)
Fuente: Elaboración propia con base en información secundaria
6. Conclusiones y recomendaciones
6.1 Conclusiones
En Colombia aproximadamente el 60% de las empresas de Tecnología no cuentan con
marcos de referencia de calidad avalados internacionalmente; la implementación de
modelos de madurez como CMMI tardan entre 12 y 18 meses, es indispensable hacer uso
de metodologías ágiles para minimizar el tiempo de la adopción de los diferentes modelos
de calidad.
La Integración de modelos de madurez de capacidades se ve influenciado por las
metodologías ágiles en particular la de Scrum.
El modelo CMMI-DEV en integración con la metodología Scrum se concibe como una
composición estable y duradera al permitir que ambas propuestas aporten lo mejor de cada
una y permita beneficios para las empresas que opten por implantar el modelo unificado.
Así, Scrum proporciona la metodología para implementar el proceso de CMMI-DEV en
áreas relacionadas con el nivel de madurez gestionado y deja la base sólida para
implementar el nivel definido. Esta alternativa es útil para las empresas que están
acoplando métodos ágiles buscando la valoración oficial SCAMPI a CMMI-DEV en los
diferentes niveles de madurez.
La implementación de modelos de madurez requiere para el logro de sus objetivos la
técnica del direccionamiento estratégico, táctica en acciones de trasferencia además de
un seguimiento permanente y una realimentación constante.
132 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
6.2 Trabajos futuros
Diseñar una estrategia que permita fusionar las diferentes metodologías ágiles en los
modelos de calidad, detallando los procedimientos en el direccionamiento estratégico en
proyectos de inversión minimizando el riesgo.
Referencia 133
7. REFERENCIAS
Amaro Calderón, S. D., & Valverde Rebaza, J. C. (2007). Metodologías Ágiles. Retrieved from https://uvirtual.unet.edu.ve/pluginfile.php/268695/mod_resource/content/1/Metodologias Agiles.pdf
Arturo, H., & Fernández, F. (2009). Procesos de ingeniería de software. Retrieved from http://virtual-test.fukl.edu/images/investigaciones/matematicas/ingenieria_de_software.pdf
Beck, K., & Andrés, C. (2005). Praise for Extreme Programming Explained, Second Edition. Retrieved from http://ptgmedia.pearsoncmg.com/images/9780321278654/samplepages/9780321278654.pdf
Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., … Dave, T. (2001). Manifiesto por del Desarrolo Ágil de Software.
Caracterización General del sector BPO, KPO e ITO en Colombia. (2013). Retrieved from https://www.ptp.com.co/documentos/2 IDC_PTP_1_EntregableI_PublicadoII.pdf
Carvajal Riola, J. C. (2008). Metodologías ágiles: herramientas y modelo de desarrollo para aplicaciones Java EE como metodologia empresarial. Retrieved from http://upcommons.upc.edu/handle/2099.1/5608
Chrissis, M. B., Konrad, M., & Shrum, S. (2009). Guía para la integración de procesos y la mejora de productos. Retrieved from http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf
CMMI ® para Desarrollo, Versión 1.3 Mejora de los procesos para el desarrollo de mejores productos y servicios Software Engineering Process Management Program. (2010). Retrieved from http://www.sei.cmu.edu
Colciencias - a. (2015). Convocatoria para promover modelos de calidad mundialmente reconocidos en la industria de TI colombiana | COLCIENCIAS.
Colciencias, & Mintic. (2015). Convocatoria para promover modelos de calidad mundialmente reconocidos en la industria de TI Colombiana. Retrieved from http://www.colciencias.gov.co/sites/default/files/upload/convocatoria/tdr-y-Anexos.pdf
Departamento de Sistemas Informáticos y Computación., & Universidad Politécnica de Valencia. (1985). Proceso de Desarrollo de Software. Retrieved from http://www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Fiti. (2012). Estrategia De Fortalecimiento De la Industria de Tecnologías de Información, 1–35.
García Rodríguez, M. J. (2015). Estudio comparativo entre las metodologías ágiles y las metodologías tradicionales para la gestión de proyectos software, 115. Retrieved from http://digibuo.uniovi.es/dspace/handle/10651/32457
Garzás, J. (2012). Las metodologías Crystal. Otras metodologías ágiles que, quizás te puedan encajar más que Scrum. Retrieved from
134 Análisis y diseño de un modelo con integración de una metodología ágil en el nivel 2 de
CMMI
http://www.javiergarzas.com/2012/09/metodologias-crystal.html Isabel, M., & Sanchez, A. (2004). No Title, 1–57. ISACA. (2015). COBIT 5 Gobierno electronico de las TI de la Empresa. M., C. P., Machado, N. M. V., & Morimitsu, G. T. (2008). Análisis descriptivo del proceso
de implementación del nivel 2 del modelo CMMI en una empresa regional de desarrollo de software. Sistemas & Telemática, 6(12), 89–109. Retrieved from http://www.icesi.edu.co/revistas/index.php/sistemas_telematica/article/view/1001
Méndez, E. M. (2006). Modelo de Evaluación de Metodologías para el Desarrollo de Software. Retrieved from http://biblioteca2.ucab.edu.ve/anexos/biblioteca/marc/texto/AAQ7365.pdf
Moreno García, M. N. (n.d.). TEMA 2 Modelos de proceso del software Contenidos Contenidos. Retrieved from http://avellano.usal.es/~mmoreno/ASTema2.pdf
Nohemí, Y., Meneses, G., Juan, J., & Mora, H. (2014). Análisis del Estado Actual de Certificaciones Mundial y en México, 79, 121–134.
Observatorioti. (2015). CARACTERIZACIÓN DE PRODUCTOS Y SERVICIOS DEL SECTOR DE TECNOLOGÍAS DE INFORMACIÓN EN COLOMBIA 2015. Retrieved from http://observatorioti.co/wp-content/uploads/2016/02/EstudiodeCaracterización2015.pdf
Orjuela Duarte, A., & Rojas, M. (2008). The Methodologies of Agile Development like an Opportunity for the Engineering of Educative Software, 5(2), 14.
Pressman, R. S. (2010). Ingeniería de Software Un enfoque práctico. (Mc Graw Hill, Ed.) (Séptima Edicion). Retrieved from http://cotana.informatica.edu.bo/downloads/ld-Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF
Rodríguez Castro, M. (n.d.). Principio de Pareto o regla de 80/20: ¿qué es y cuál es su utilidad? Retrieved November 21, 2017, from https://psicologiaymente.net/organizaciones/principio-pareto-regla-80-20
Ruiz, F., & González Harbour -IS, M. (n.d.). INGENIERÍA DEL SOFTWARE I. Retrieved from https://www.ctr.unican.es/asignaturas/is1/is1-t02-trans.pdf
Sanz Moyano, S. (2009). Implantación De Cmmi En Pequeñas Empresas De Desarrollo De Software.
SCAMPI Team, & CMMI Institute. (2014). Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Version 1.3b: Method Definition Document for SCAMPI A, B, and C, (December), 277. https://doi.org/CMU/SEI-2011-HB-001
Schwaber, K., & Sutherland, J. (2013). The Scrum GuideTM. Retrieved from http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
SENA. (2014). Modelos de calidad en el desarrollo de software. Colombia. Serna, A. M., & Itilview, C. (n.d.). OTRS: la gestión libre del servicio de TI. Serna, E., & Candidato, M. (2010). Métodos formales e Ingeniería de Software Formal
Methods and Software Engineering Méthodes formelles et génie logiciel, (30), 158–184. Retrieved from http://revistavirtual.ucn.edu.co/index.php/RevistaUCN/article/viewFile/62/129
Software Engineering Institute. (2010). CMMI for Development, Version 1.3. Carnegie Mellon University, (November), 482. https://doi.org/CMU/SEI-2010-TR-033 ESC-TR-2010-033
Sommerville, & Ian. (2005). Ingeniería del software. Retrieved from https://ingenieriasoftware2011.files.wordpress.com/2011/07/ingenieria-de-software-ian-sommerville-7ma-edicion-prentice-hall.pdf
The Agile Alliance. (2001). Principios del Manifiesto Ágil. Valencia, L. S., Villa, P. A., & Ocampo, C. A. (2009). Modelo de calidad de software.