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

Dedico

A mi hija Karen con todo mi amor.

A mis padres por ser el pilar

fundamental de mi formación.

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


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


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.


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.


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.


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.


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


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.


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.


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)


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


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


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


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


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.


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.


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.


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.


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

%


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

%


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


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.


CMMI

Figura 4-5 Actividades Económicas por empresa


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


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.


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


Desarrollo de software y de de aplicaciones

informáticas. 38%


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%


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


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.

https://sas.cmmiinstitute.com/pars


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)


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



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.

http://www.sei.cmu.edu/cmmi/start/faq/appraisals-faq.cfm

http://sas.sei.cmu.edu/pars/pars.aspx

https://sas.cmmiinstitute.com/pars/pars.aspx


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.

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


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


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.


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


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


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


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


CMMI

Figura 5-6 Monitorización y control del proyecto CMMI-DEV y SCRUM


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


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


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


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


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


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


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.


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

Figura 5-12 Product Owner

Fuente: Elaboración propia Modelación CMMI-SCRUM

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:


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.

Figura 5-13 ScrumMaster


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.

Figura 5-14 Development Team


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.


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


Planificación del Proyecto (PP)



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)



CMMI

Monitoreo y Control del Proyecto (PMC)

La integración de metodologías ágiles con modelos de calidad está determinado por la


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)


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


Resultados 122

Figura 5-17 Monitoreo y Control del Proyecto (PMC)


Resultados

Medición y Análisis (MA)



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


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


Resultados 124

Figura 5-18 Medición y Análisis (MA)


Resultados

Aseguramiento de la Calidad de Productos y Procesos (PPQA)



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)


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


Resultados 126

Figura 5-13 Aseguramiento de la Calidad de Productos y Procesos (PPQA)


Resultados

Gestión de la Configuración (CM)



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)


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


Resultados 128

Figura 5-19 Gestión de la Configuración (CM)


Resultados

Gestión de Acuerdos con Proveedores (SAM)



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)


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


Figura 5-20 Gestión de Acuerdos con Proveedores (SAM)


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.


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


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.

Scientia et Technica Año XV, (42), 172–176. Wells, don. (2009). Extreme Programming: A Gentle Introduction. Retrieved November

23, 2017, from http://www.extremeprogramming.org/

Análisis y diseño de un modelo con integración de una...

Documents

Transcript of Análisis y diseño de un modelo con integración de una...