desarrollodeunprototipode softwareparalaadaptacióndel...

Desarrollo de un Prototipo deSoftware para la Adaptación delMarco de Trabajo SCRUM en

COLDINAMIC S.A.S.

Ing. Jorge Armando Martínez Sánchez 20172099025

Ing. Carolina Mateus Pérez 20171099012

Universidad Distrital Francisco José de Caldas

Proyecto de investigación Especialización en Ingeniería de Software

Bogotá D.C, 2018

Desarrollo de un Prototipo deSoftware para la Adaptación delMarco de Trabajo SCRUM en

COLDINAMIC S.A.S.

Ing. Jorge Armando Martínez Sánchez 20172099025

Ing. Carolina Mateus Pérez 20171099012

Tesis presentada como requisito para optar al título de:

Especialista en Ingeniería de Software

Director:

Ing. Alexandra Abuchar Porras, MS.

Revisor:

Ing. Jose Ignacio Palacios Osma, Ph.D

Línea de Investigación:

Metodologías de Gestión de Proyectos

Universidad Distrital Francisco José de Caldas

Proyecto de investigación Especialización en Ingeniería de Software

Bogotá D.C, 2018

Indice

I Fundamentación de la Investigación 3

1. Descripción de la Investigación 4

1.1. Título y definición del tema de investigación . . . . . . . . . . . . 5

1.2. Estudio del problema de investigación . . . . . . . . . . . . . . . 5

1.2.1. Descripción de la empresa objeto de estudio. . . . . . . . 6

1.2.2. Planteamiento del Problema . . . . . . . . . . . . . . . . 11

1.2.3. Formulación del Problema . . . . . . . . . . . . . . . . . 12

1.2.4. Sistematización del problema . . . . . . . . . . . . . . . . 12

1.3. Objetivos de la investigación . . . . . . . . . . . . . . . . . . . . 14

1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . 14

1.3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . 14

1.4. Justificación de la investigación . . . . . . . . . . . . . . . . . . . 15

1.4.1. Justificación teórica . . . . . . . . . . . . . . . . . . . . . 17

1.4.2. Justificación metodológica . . . . . . . . . . . . . . . . . 20

1.5. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2. MARCO REFERENCIAL 22

2.1. Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

ii

INDICE iii

2.1.1. Metodología XP . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1.3. Evaluación de la calidad del software . . . . . . . . . . . 37

2.1.4. Arquitectura Empresarial . . . . . . . . . . . . . . . . . . 41

2.1.5. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.1.5.1. Capa de Negocio . . . . . . . . . . . . . . . . . 46

2.1.5.2. Capa de Aplicación . . . . . . . . . . . . . . . . 49

2.1.5.3. Capa de Infraestructura . . . . . . . . . . . . . . 51

2.1.5.4. Capa Motivacional . . . . . . . . . . . . . . . . . 54

2.1.5.5. Puntos de Vista . . . . . . . . . . . . . . . . . . 56

2.1.5.6. Punto de Vista Organización . . . . . . . . . . . 56

2.1.5.7. Punto de Vista Cooperación del Actor . . . . . . 57

2.1.5.8. Punto de Vista Función del Negocio . . . . . . . 57

2.1.5.9. Punto de Vista Procesos de Negocio . . . . . . 58

2.1.5.10. Punto de Vista Cooperación Procesos de Negocio 58

2.1.5.11. Punto de Vista de Comportamiento de Aplicación 60

2.1.5.12. Punto de Vista de Cooperación de Aplicación . . 61

2.1.5.13. Punto de Vista de Estructura de Aplicación . . . 61

2.1.5.14. Punto de Vista de Uso de Aplicación . . . . . . . 62

2.1.5.15. Punto de Vista de Infraestructura . . . . . . . . 62

2.1.5.16. Punto de Vista de Uso de Infraestructura . . . . 63

2.1.5.17. Punto de Vista de Organización e Implementación 63

2.1.5.18. Punto de Vista de Estructura de Información . . 64

2.1.5.19. Punto de Vista de Realización del Servicio . . . 64

2.1.5.20. Punto de Vista de Interesados . . . . . . . . . . 64

INDICE iv

2.1.5.21. Punto de Vista de Realización de Objetivos . . . 65

2.1.5.22. Punto de Vista de Contribución . . . . . . . . . . 65

2.1.5.23. Punto de Vista de Principios . . . . . . . . . . . 66

2.1.5.24. Punto de Vista de Realización de Requerimientos 66

2.1.5.25. Punto de Vista de Motivación . . . . . . . . . . . 67

2.1.5.26. Punto de Vista de Proyecto . . . . . . . . . . . . 67

2.1.5.27. Punto de Vista de Migración . . . . . . . . . . . 67

2.1.5.28. Punto de Vista de Migración e Implementación . 68

2.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.3. Marco Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.4. Marco Legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.4.0.1. Obligación de confidencialidad . . . . . . . . . . 73

3. ASPECTOS METODOLÓGICOS 75

3.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.2. Método de investigación . . . . . . . . . . . . . . . . . . . . . . . 76

3.3. Fuentes y técnicas para la recolección de la información . . . . . 76

II Desarrollo de la Investigación 77

4. Análisis 78

4.1. Evaluación del proceso de desarrollo de software actual de Col-

dinamic S.A.S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2. Comparación Scrum y el proceso de desarrollo actual de Coldi-

namic S.A.S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.3. Elaboración del nuevo proceso ajustado para Coldinamic S.A.S 84

INDICE v

5. Arquitectura empresarial AgileQA 90

5.1. Capa de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.1.1. Punto de vista de organización . . . . . . . . . . . . . . . 91

5.1.2. Punto de vista de cooperación de actor . . . . . . . . . . 91

5.1.3. Punto de vista de función de negocio . . . . . . . . . . . 92

5.1.4. Punto de vista de proceso de negocio . . . . . . . . . . . 92

5.1.5. Punto de vista de cooperación de proceso de negocio . . 93

5.1.6. Punto de vista de producto . . . . . . . . . . . . . . . . . 93

5.2. Capa de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.2.1. Punto de Vista de Comportamiento de Aplicación . . . . . 94

5.2.2. Punto de Vista de Estructura de Aplicación . . . . . . . . 94

5.2.3. Punto de Vista de Cooperación de Aplicación . . . . . . . 95

5.2.4. Punto de Vista de Uso de aplicación . . . . . . . . . . . . 95

5.3. Capa de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . 96

5.3.1. Punto de vista Infraestructura . . . . . . . . . . . . . . . . 96

5.3.2. Punto de vista Uso de Infraestructura . . . . . . . . . . . 96

5.3.3. Punto de vista Estructura de Información . . . . . . . . . 97

III Cierre de Investigación 98

5.4. Prototipo AgileQA . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.5. Resultados de la prueba piloto . . . . . . . . . . . . . . . . . . . 104

5.6. Validación de la hipótesis . . . . . . . . . . . . . . . . . . . . . . 109

5.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.8. Trabajos de investigación futuros . . . . . . . . . . . . . . . . . . 110

Lista de Figuras

1.1. Organigrama Coldinamic S.A.S. Fuente: Elaboración propia . . . 7

1.2. Metodología actual de desarrollo de software en la compañía

Coldinamic. Fuente: Elaboración propia . . . . . . . . . . . . . . 10

1.3. Tamaño Equipos. [Gayane, 2011] . . . . . . . . . . . . . . . . . . 16

1.4. Metodologías usadas. [Gayane, 2011] . . . . . . . . . . . . . . . 16

1.5. Herramientas de gestión para proyectos ágiles. [Gayane, 2011] . 17

1.6. Cantidad de empresas de software según el número de emplea-

dos, [Cuéllar, ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1. Resolución de proyectos de software [The Standish Group Inter-

national, 2009] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2. Ciclo de desarrollo XP [Zhamungui, 2013] . . . . . . . . . . . . . 32

2.3. Ciclo de desarrollo Scrum [Canive, 2017] . . . . . . . . . . . . . 34

2.4. Fases de ISO/IEC 14598 [Lozano, 2013] . . . . . . . . . . . . . 38

2.5. Medidas de calidad software ISO 25010 [Mellon, 2004] . . . . . 40

2.6. Línea de Tiempo de una Arquitectura Empresarial. Fuente: [Vi-

llalpando, 2014] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.7. Correspondencia entre TOGAF y el Ciclo ADM de Archimate in-

cluyendo las extensiones. Fuente: Capítulo 2 [Group, 2013] . . . 45

2.8. Integración del ADM con ArchiMate. Fuente: [Villalpando, 2014] . 46

vi

LISTA DE FIGURAS vii

2.9. Conceptos Pasivos de la Capa de Negocio en Archimate. Fuen-

te: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.10.Conceptos Activos de la Capa de Negocio en Archimate. Fuente

[Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.11.Conceptos Informativos de la Capa de Negocio en Archimate.

Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . 49

2.12.Elementos Estructurales de la Capa deAplicación enArchimate.

Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . 50

2.13.Elementos Comportamentales de la Capa de Aplicacíon en Ar-

chimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . 51

2.14.Elementos de la Capa de Infraestructura en Archimate. Fuente:

[Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.15.Continuación elementos de la Capa de Infraestructura en Archi-

mate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . 53

2.16.Elementos de la Capa deMotivación enArchimate. Fuente: [Group,

2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.17.Punto de Vista Organización. Fuente [Group, 2013] . . . . . . . 56

2.18.Punto de Vista Cooperación del Actor. Fuente [Group, 2013] . . 57

2.19.Punto de Vista Función del Negocio. Fuente [Group, 2013] . . . 57

2.20.Punto de Vista Procesos de Negocio. Fuente [Group, 2013] . . . 58

2.21.Punto de Vista Cooperación Procesos deNegocio. Fuente [Group,

2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.22.Punto de Vista deComportamiento deAplicación. Fuente [Group,

2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.24.Punto de Vista de Estructura de Aplicación. [Group, 2013] . . . . 61

2.25.Punto de Vista de Uso de Aplicación. Fuente [Group, 2013] . . . 62

2.26.Punto de Vista de Infraestructura. Fuente [Group, 2013] . . . . . 62

2.27.Punto de Vista de Uso de Infraestructura. Fuente [Group, 2013] 63

2.28.Punto de Vista deOrganización e Implementación. Fuente [Group,

2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

LISTA DE FIGURAS viii

2.29.Punto de Vista de Estructura de Información. Fuente [Group, 2013] 64

2.30.Punto de Vista de Realización del Servicio. Fuente [Group, 2013] 64

2.31.Punto de Vista de Interesados. Fuente [Group, 2013] . . . . . . 65

2.32.Punto de Realización de Objetivos. Fuente [Group, 2013] . . . . 65

2.33.Punto de Vista de Contribución. Fuente [Group, 2013] . . . . . . 65

2.34.Punto de Vista de Principios. Fuente [Group, 2013] . . . . . . . . 66

2.35.Punto de Vista deRealización deRequerimientos. Fuente [Group,

2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.36.Punto de Vista de Motivación. Fuente [Group, 2013] . . . . . . . 67

2.37.Punto de Vista de Proyecto. Fuente [Group, 2013] . . . . . . . . 67

2.38.Punto de Vista de Migración. Fuente [Group, 2013] . . . . . . . . 67

2.39.Punto de Vista de Migración e Implementación. Fuente [Group,

2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1. Distribución del riesgo en un desarrollo ágil. [Pilar, 2008] . . . . . 84

4.2. Distribución del riesgo en un modelo convencional. [Pilar, 2008] 84

4.3. Desarrollo por ciclos de corta duración [Luis, 2017] . . . . . . . . 85

4.4. Pila del producto y del Sprint. [Menzinsky, 2018] . . . . . . . . . 86

4.5. Ilustra requerimiento adjuntar documentación historia de usua-

rio. [SIA, 2014] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.6. Tablón de Scrum. [Miguel, 2015] . . . . . . . . . . . . . . . . . . 87

4.7. Monitoreo de HU por Punto de Control. [Mitre, 2014] . . . . . . . 88

4.8. Prácticas de Scrum. Elaboración Propia . . . . . . . . . . . . . . 89

5.1. Punto de vista de organización Coldinamic . . . . . . . . . . . . 91

5.2. Punto de vista cooperación actor . . . . . . . . . . . . . . . . . . 91

5.3. Punto de función de negocio . . . . . . . . . . . . . . . . . . . . 92

5.4. Punto de vista de negocio . . . . . . . . . . . . . . . . . . . . . . 92

LISTA DE FIGURAS ix

5.5. Punto de vista proceso de negocio . . . . . . . . . . . . . . . . . 93

5.6. Punto de vista de producto . . . . . . . . . . . . . . . . . . . . . 93

5.7. Diagrama Punto de Vista Comportamiento de Aplicación . . . . . 94

5.8. Punto de Vista de Estructura de Aplicación . . . . . . . . . . . . 94

5.9. Punto de Vista de Cooperación de Aplicación . . . . . . . . . . . 95

5.10.Punto de Vista de Uso de aplicación . . . . . . . . . . . . . . . . 95

5.11.Punto de vista Infraestructura . . . . . . . . . . . . . . . . . . . . 96

5.12.Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . 97

5.13.Punto de vista Estructura de Información . . . . . . . . . . . . . 97

5.14.AgileQA. Fuente: Elaboración propia . . . . . . . . . . . . . . . . 99

5.15.Módulos del prototipo AgileQA. Fuente: Elaboración propia . . . 99

5.16.Administración de proyectos AgileQA. Fuente: Elaboración propia100

5.17.Detalle del proyecto AgileQA. Fuente: Elaboración propia . . . . 100

5.18.Indicadores del proyecto. AgileQA. Fuente: Elaboración propia . 100

5.19.Pila del producto AgileQA. Fuente: Elaboración propia . . . . . . 101

5.20.Tablero del Sprint AgileQA. Fuente: Elaboración propia . . . . . 101

5.21.Detalle del Sprint. Fuente: Elaboración propia . . . . . . . . . . . 102

5.22.Detalle de historia. AgileQA. Fuente: Elaboración propia . . . . . 102

5.23.Historia de usuario - Notas- AgileQA. Fuente: Elaboración propiar 103

5.24.Historia de usuario - Documentación adjunta. AgileQA. Fuente:

Elaboración propiar. . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.25.Métricas de calidad AgileQA. Fuente: Elaboración propia . . . . 104

5.26.Reporte. AgileQA. Fuente: Elaboración propia . . . . . . . . . . . 104

5.27.Información básica del proyecto. Fuente: Elaboración propia . . 105

5.28.Equipo scrum. Fuente: Elaboración propia . . . . . . . . . . . . . 105

5.29.Primera iteración. Fuente: Elaboración propia . . . . . . . . . . . 106

LISTA DE FIGURAS x

5.30.Iteraciones finales. Fuente: Elaboración propia . . . . . . . . . . 106

5.31.Indicadores evaluados en el proyecto. Fuente: Elaboración propia107

5.32.Métrica fallos del sistema. Fuente: Elaboración propia . . . . . . 107

5.33.Tiempos de respuesta. Fuente: Elaboración propia . . . . . . . . 108

5.34.Funciones evidentes. Fuente: Elaboración propia . . . . . . . . . 108

5.35.Tiempo entrega. Fuente: Elaboración propia . . . . . . . . . . . . 109

Lista de Tablas

1.1. Tabla de cargos y formación académica profesional de la com-

panía Coldinamic. Fuente: Elaboración propia . . . . . . . . . . . 9

4.1. Evaluación cuantitativa de la escala. Fuente: Elaboración propia 79

4.2. Resumen del resultado de evaluación de la eficacia de las prác-

ticas empleadas para la gestión de proyectos. Fuente: Elabora-

ción propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3. Resumen del resultado de evaluación de la calidad de los pro-

ductos de software. Fuente: Elaboración propia . . . . . . . . . . 81

4.4. Resumen de resultado de la evaluación de satisfacción del clien-

te. Fuente: Elaboración propia . . . . . . . . . . . . . . . . . . . 82

4.5. Desarrollo actual Coldinamic vs marco de trabajo Scrum . . . . . 83

xi

Resumen

El presente proyecto de investigación describe los pasos, las metodologías

utilizadas, los enfoques teóricos necesarios para su conceptualización, y el

ejercicio de planificación previsto para la obtención del resultado esperado,

que consiste en el desarrollo de un prototipo de software, que permita ade-

cuar la estructura organizacional de la empresa Coldinamic S.A.S al modelo

de desarrollo Scrum, incluyendo módulos generales de gestión para el marco

de trabajo Scrum y un módulo para administración de la calidad de software

basado en la series de normas ISO/IEC 25000 que aportan valor adicional a

la realización de cada uno de los proyectos de software de la compañía. De

igual forma se busca establecer indicadores sobre la ejecución del proyecto

que permiten realizar retroalimentación del proceso, necesario en el contex-

to del mercado Colombiano de la industria del software, buscando alternativas

que permitan adecuar las acciones operativas y administrativas hacia la optimi-

zación de su desempeño, en un entorno y ecosistema favorable pero altamente

competitivo.

Abstract

The present research project describes the steps, the methodologies used,

the theoretical approaches necessary for its conceptualization, and the planned

planning exercise to obtain the expected result, consisting of the development

of a software prototype, which allows to adapt the structure organization of the

company Coldinamic SAS to the Scrum development model, including gene-

ral management modules for the Scrum framework and a module for software

quality management based on the ISO / IEC 25000 series of standards that

add additional value to the implementation of each of the company’s software

projects. In the same way, it is sought to establish indicators on the execution of

the project that allow feedback of the process, necessary in the context of the

Colombian market of the software industry, looking for alternatives that allow to

adapt the operative and administrative actions towards the optimization of its

performance, in a favorable but highly competitive environment and ecosystem.

Introducción

La competitividad que demanda en la actualidad el sector del software, genera

retos encaminados a proporcionar las mejores soluciones de software de la

manera más efectiva posible.

La terminación oportuna de productos de software, con la calidad esperada

es uno de los principales requisitos del cliente. El incumplimiento en la entrega o

de los requerimientos de un proyecto, no sólo puede significar la perdida de un

cliente, es un cliente que puede dar malas referencias, perjudicando la imagen

de la compañía, lo que puede suponer la pérdida de clientes potenciales.

Este es el caso de Coldinamic S.A.S, una casa de desarrollo de software

que divide sus esfuerzos entre desarrollos a la medida para diferentes secto-

res, soporte y mantenimiento a productos propios. La presencia en el mercado

de software Colombiano de Coldinamic, se ha visto marcado por la perdida

continua de clientes debido básicamente a disconformidad por retrasos e in-

cumplimiento de requisitos impuestos por el cliente.

De esta manera la organización se ha planteado entre sus principales ob-

jetivos a corto plazo; controlar la productividad de su equipo de desarrollo y

mejorar la calidad de sus productos.

En el presente trabajo se plantea el desarrollo de un prototipo llamada Agi-

leQA para apoyo a la gestión de proyectos a través de buenas prácticas, el

prototipo también debe permitir verificar la calidad de los proyectos de softwa-

re antes de una entrega final al cliente y establecer medidas para verificar el

cumplimiento de entregas y la satisfacción del cliente.

El desarrollo de esta investigación busca extraer información de la ejecu-

ción actual del proceso de desarrollo de software en Coldinamic, con base en

esta información adaptar el marco de trabajo Scrum para el desarrollo de un

prototipo que permita apoyar la gestión de proyectos, el cual además integre un

módulo de calidad para medir indicadores en cada proyecto basado en la serie

de normas ISO 25000 y evaluar el grado de satisfacción del cliente, en favor

de mejorar continuamente el proceso de desarrollo de software y mantenerse

en el mercado gracias a la fidelización de sus clientes.

2

Parte I

Fundamentación de la

Investigación

3

Capítulo 1

Descripción de la

Investigación

En este capítulo se incluye los conceptos preliminares que generan la ne-

cesidad del desarrollo de la investigación.

4

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN 5

1.1. Título y definición del tema de investigación

El título del trabajo de investigación propuesto es: Desarrollo de un prototi-

po de software para la adaptación del marco de trabajo Scrum en Coldinamic

S.A.S.

Comprende varios tipos de acciones investigativas orientadas a la imple-

mentación en un entorno de producción real, la propuesta del modelo y con-

ceptualización que se realiza como ejercicio académico son derivadas de las

demandas concretas del programa de formación en Especialización en Inge-

niería de Software, para el cual se orienta la producción del presente proyecto.

Más allá del producto final que sugiere el título del proyecto, la investiga-

ción propuesta busca indagar sobre la viabilidad, pertinencia y limitaciones,

que pueden surgir al momento de definir los requerimientos para el proceso de

ajuste a un paradigma específico de modelo de desarrollo de software en una

microempresa, puesto que el proceso de producción de software va a deman-

dar ajustes requeridos en los modelos de gestión empresarial, estas definicio-

nes necesariamente impactarán su modelo de negocio.

De esta manera es necesario medir el proceso de desarrollo de software

durante el proceso mismo de producción del prototipo, así como documentar

las falencias y aciertos que pueden encontrarse o presentarse durante el ejerci-

cio de implementación con la empresa, constituyen una fuente de información

invaluable, que debe permitir retroalimentar la adecuación del prototipo como

la metodología (Scrum) misma lo señala.

Al mismo tiempo debe poner en evidencia el valor agregado por esta sis-

tematización que cobra vida en una solución informática. Medir el valor que

agrega un determinado desarrollo en su propia empresa, debe permitir a su

vez, medir en los ejercicios de desarrollo posterior de productos externos des-

tinados a los clientes, el dimensionamiento de estas variables como un valor

fundamental para el posicionamiento de la empresa en un mercado altamente

competitivo.

1.2. Estudio del problema de investigación

A continuación se presenta el dimensionamiento inicial de la investigación,

permitiendo delimitar la intervención, el alcance y los marcos de solución iden-

tificados en el ejercicio de preparación del proceso investigativo, se describe la

organización en conjunto para identificar una posible adopción del prototipo.


1.2.1. Descripción de la empresa objeto de estudio.

Dimensión de la empresa: Coldinamic S.A.S es una microempresa con

tres años de experiencia en el sector del software. Su sede principal está ubi-

cada en la ciudad de Bogotá D.C, cuenta con una planta de personal de diez

trabajadores, en su mayoría dedicada al desarrollo de software dado que es

su principal producto. Cuenta también con otros servicios como: outsourcing,

consultoría y asesoría en sistemas de información, soporte y mantenimiento

especializado de software.

El objetivo principal de la empresa y su organización interna, es proporcio-

nar herramientas informáticas para el control y flujo de información con solu-

ciones a la medida de acuerdo a las necesidades del cliente. El trabajo de la

compañía no solo consiste en proporcional al cliente una aplicación ajustada

para el desarrollo de sus actividades, el proceso incluye orientación y acompa-

ñamiento al cliente en la implementación de los productos.

El conjunto de clientes de la compañía abarcan diferentes sectores entre

ellos: industrial, construcción y seguros. La demanda de nuevo software y man-

tenimiento de las soluciones propias ha sido amplia, pero en los primeros acer-

camientos con el personal y el cuerpo directivo de la empresa, se puede indicar

que la satisfacción de los clientes no ha alcanzado los niveles esperados.

Misión: Ser una compañía reconocida a nivel nacional e internacional por

nuestros servicios y soluciones informáticas de alta calidad.

Visión: Ser reconocidos como un líder en el desarrollo de Software gracias

a nuestra experiencia, efectividad y cumplimento. Esta labor se debe desem-

peñar de forma satisfactoria para nosotros y nuestros clientes para quienes

permitirá competir con éxito en un mercado cada vez más dinámico y globali-

zado ver figura 1.1


Figura 1.1: Organigrama Coldinamic S.A.S. Fuente: Elaboración propia

Sus instalaciones productivas cuentan con la infraestructura tecnológica ne-

cesaria para el desarrollo de su principal actividad. A continuación se relaciona

la infraestructura de la organización:

Infraestructura de procesamiento

Equipos personales: Equipo: Lenovo ideapad 500 Memoria: 16 GB Pro-

cesador: AMD A10-8700P Radeon R6, 10 Compute Cores 4C+6G × 4 Gráfi-

cos: Gallium 0.4 on AMD CARRIZO (DRM 3.1.0, LLVM 3.8.0) Disco: 500 GB

Sistema operativo Debian

Servidor SAMBA:Equipo: HPProLiant DL380G7Memoria: 18 x 8GBPC3-

10600, Reg. Procesador: 2 x 2.66Ghz X5650 Six Core Disco duro: 12 x 160GB

SSD SATA 2.5 Interfaz de Red: 4 x Gigabit Ethernet Tarjeta de video integrada

Sistema operativo Ubuntu Server

Red de datos: Se cuenta con una red LAN privada que conecta los equipos

de la compañía

Ancho de banda: Canal dedicado de 30 MB

Inventario de Infraestructura de Datos

Bases de datos: Mongo DB - NoSQL, MySQL, María DB, PostgreSQL.

Periodos de recolección: Back up mensuales de la información.

Equipo de Desarrollo


El desarrollo de las aplicaciones está a cargo de un equipo de nueve per-

sonas, distribuidas en diferentes cargos o roles, de los cuales se describen sus

funciones:

Gerente de proyectos: Cuenta con una persona encargada de la gestión

de proyectos. El proceso va desde la definición inicial, hasta la presentación del

proyecto final al cliente. El gerente de proyectos debe, una vez definido el pro-

yecto, establecer las fechas, plazos y costos. Otra tarea fundamental que debe

realizar el gerente de proyectos es la definición de los objetivos del proyecto

en función de los requerimientos del cliente.

Líder técnico: Responsable de verificar cada uno de los proyectos, así

como revisar los productos de software realizados. Tiene la función principal

de servir de intermediario entre el gerente de proyecto y los desarrolladores.

Realiza reuniones técnicas con el gerente de proyecto para compresión de

especificaciones durante la etapa de desarrollo.

Desarrolladores Senior: En este cargo se encuentran a la fecha cuatro

profesionales senior hacen parte de la organización, entre las principales fun-

ciones de los desarrolladores senior se encuentra: Análisis, diseño, programa-

ción, mantenimiento y documentación de aplicaciones. Se espera que constru-

yan software nuevo, mejoren y corrijan aplicaciones ya existentes. Debe contar

con habilidades técnicas y creativas que le permitan realizar desarrollos com-

plejos.

Desarrolladores Junior: En este rol se ubican tres programadores juniors

quienes están vinculados a Coldinamic. Tienen las mismas funciones que un

desarrollador senior, pero no lasmismas responsabilidades. En este caso, cada

profesional que se desempeña como desarrollador junior cuenta con el acom-

pañamiento y asistencia constante del desarrollador senior en todas las funcio-

nes, con el objetivo de garantizar la calidad en el desarrollo de sus actividades.

Esto bajo el supuesto que su experiencia no es amplia, lo que puede generar

retrasos o dificultades en los tiempos de desarrollo o en la optimización de las

soluciones.

Resumen de cargos en relación con la formación académica de los(as)

profesionales y su experiencia:

En la siguiente tabla se presenta la información de manera general del perfil

de los profesionales del área de producción de la organización:


CARGO PERFIL ACADÉMICO EXPERIENCIA

Gerente de

proyectos

El gerente de proyecto ac-

tual cuenta con el título pro-

fesional de Ingeniería de Sis-

temas.

Tiene certificación profesional

en Dirección de Proyectos del

PMI y dominio de inglés 80%.

Cinco años de expe-

riencia en administra-

ción y control de pro-

yectos de software.

Líder técnico Especialista en gerencia de

proyectos, certificado en Di-

rección de Proyectos.

Dominio de inglés 60%.

Presenta experiencia

en seguimiento y plani-

ficación de proyectos,

diseño y control de

presupuestos. Dos

años de experiencia

específica en gestión

de proyectos de desa-

rrollo de Software.

Desarrollador

Senior

Profesionales en ingeniería

de sistemas, conocimiento y

dominio avanzado de lengua-

jes de programación orienta-

do a objetos. Conocimientos

en manejo de base de datos

y en diseño de aplicaciones

web. Todos tienen un dominio

de inglés técnico cercano al

50%.

El mínimo de experien-

cia con que cuentan

los desarrolladores se-

nior de la compañía es

de cuatro años en sis-

tema Java, web servi-

ces y base de datos

Desarrollador

Junior

Los programadores tienen

conocimientos sobre manejo

de repositorios y control de

versiones, herramientas de

debug y pruebas unitarias,

conocimiento java y bases de

datos.

El mínimo de experien-

cia con que cuenta los

profesionales junior es

de la compañía es de

un año en desarrollo.

Cuadro 1.1: Tabla de cargos y formación académica profesional de la companía

Coldinamic. Fuente: Elaboración propia


Tiempos de reuniones y frecuencia de reunión: No existen una frecuen-

cia determinada de reuniones que se llevan a cabo al interior de la compañía.

Generalmente se realizan reuniones esporádicas, sobre todo cuando hay re-

trasos en los proyectos o inconvenientes con el cliente por alguna funcionali-

dad que presenta fallos. Las reuniones internas, se limitan en su mayoría a los

asuntos específicos de cada proyecto. Tienen una duración máxima de treinta

minutos, dado los tiempos limitados de cada uno de los integrantes del equipo

de desarrollo. Las reuniones con cada cliente, a diferencia de las reuniones

internas, pueden ser extensas. Asisten a estas reuniones el gerente de pro-

yectos, el cliente y en algunas ocasiones el líder técnico. Estas se programan

con mínimo ocho días de anticipación.

Metodología aplicada a los desarrollo actuales: En la actualidad los pro-

yectos se desarrollan con base en los documentos que proporciona el cliente.

Se pueden diferenciar algunas etapas en la ejecución de cada proyecto en la

organización, la etapa inicial es el análisis y diseño, en la cual se debe enten-

derse toda la información del proyecto, construcción de un modelo a partir de

los requisitos y definición de las funciones o tareas realizar. En la siguiente eta-

pa implementación se producen los módulos necesarios y se asegura que el

sistema sea operacional. Finalmente se realizan algunas pruebas de funciona-

miento del software.

Figura 1.2: Metodología actual de desarrollo de software en la compañía Col-

dinamic. Fuente: Elaboración propia

En este proceso puede ser necesario cambiar en alguna medida los requi-

sitos establecidos en la etapa inicial del proyecto, cuando se encuentra en una

de las etapas finales de ejecución del proyecto, lo cual significa que se harán

los cambios necesarios en la codificación y se tendrán que realizar de nuevo

las pruebas, es decir, si se tiene que volver a una de las etapas anteriores hay

que recorrer de nuevo el resto de las etapas.


Para Coldinamic el desarrollo de proyectos mediante estas etapas ha ge-

nerado inconvenientes grandes con los mismos, cuando surjen necesidades

imprevistas o cuando se cometen errores en una fase inicial, es difícil volver

atrás, con el consiguiente gasto inútil de recursos y retrasos en los tiempos

establecidos, este modelo puede resultar lento para la necesidades del cliente

y el coste puede ser mayor debido a que se requiere un entendiendo completo

del proyecto en la etapa inicial, es decir el cliente debe tener perfectamen-

te definidas las especificaciones del sistema y por el contrario los clientes de

Coldinamic según información aportada por el personal de la organización, no

saben exactamente qué es lo que necesita en las fases iniciales del proyecto.

Evaluación de calidad de productos finales: Se realizan pruebas unita-

rias por parte del desarrollo, las cuales no son garantía total de la calidad del

producto entregado al cliente y no tiene bases sólidas asociada con mejores

prácticas o estándares internacionales para su evaluación.

Verificación de satisfacción del cliente: Una vez que el cliente ha recibido

el producto o servicio solicitado, la organización carece de mecanismos para

medir la satisfacción del cliente, si el cliente no manifiesta su satisfacción o

inconformismo con la solución proporcionada los niveles de satisfacción no

son establecidos, ni evaluados para mejorar continuamente.

1.2.2. Planteamiento del Problema

A finales del año 2016 Coldinamic S.A.S. enfrenta una fuerte crisis, reflejo

de una mayor presión competitiva por parte de empresas innovadoras que in-

gresan al mercado con productos de calidad que proporcionan valor en menor

tiempo.

Uno de los problemas de la compañía es el retraso en la entrega de proyec-

tos y el incumplimiento de requisitos del cliente. Estos aspectos se establecen

como las principales causas de la crisis señalada, la situación que observan

sus dueños, les lleva a determinar que buena parte del problema, es la meto-

dología usada para la gestión de proyectos, que no permite tener visibilidad de

la evolución de cada proyecto para realizar proyecciones, control y medición

sobre los mismos.

Un ejercicio de planeación y definición de estrategias, que les permita po-

der cumplir con sus compromisos comerciales, así como también, estar a la

vanguardia del mercado con productos de calidad y valor para su clientes.

El problema a resolver por medio de la investigación, tiene dos componen-

tes fundamentales:

1. Un componente técnico instrumental (Prototipo de Software); y 2. Un

componente holístico organizacional.


El primer componente se pretende abordar mediante el desarrollo del pro-

totipo de software que le da título al proyecto, el cual incluye un módulo para

medir y evaluar la gestión del proyecto y la calidad del producto final.

El segundo componente es un tipo de intervención que le apunta a la mo-

dificación de la cultura organizacional, centrado en la adopción real de la men-

talidad ágil para mejorar continuamente diversos aspectos relacionados con el

proceso de desarrollo de software como: la productividad del equipo, calidad

de las entregas, satisfacción del cliente a través de la alineación de equipo

y cliente. Modificar prácticas organizativas con base en técnicas, modelos y

estándares internacionales para obtener el mejor resultado posible de un pro-

yecto.

Estos dos componentes, hacen parte de un mismo objetivo que apunta a

resolver el problema identificado, al tiempo que deben guiar el desarrollo de la

herramienta resultante.

1.2.3. Formulación del Problema

En el primer componente, la investigación pretende abordar la siguiente pre-

gunta: ¿Cómo la adopción del marco de trabajo Scrum puede ayudar a mejorar

la gestión de proyectos de la empresa Coldinamic S.A.S?.

En el segundo componente, se pretende identificar las métricas e indica-

dores para evaluar tanto la gestión del proyecto como la calidad del producto

final, dado los problemas actuales de la compañía por baja calidad e incumpli-

miento de tiempos en productos entregados, en estas circunstancias es posible

plantearse otra pregunta: ¿Cómo evaluar el progreso del trabajo y la calidad

del producto entregado al cliente para garantizar la satisfacción del cliente, con

base en normas aceptadas internacionalmente?

Estas preguntas son el núcleo para el desarrollo del proyecto de investi-

gación, sobre ellas girará toda la labor que sea realizada, buscando avanzar

desde la identificación de los enfoques apropiados para la adopción de marco

de trabajo Scrum y la construcción de parámetros demedición para la evolución

de cada proyecto y evaluación de calidad de productos, hasta el diseño de un

prototipo para la gestión eficaz de las mismas, que permita obtener para cada

proyecto resultados alineados con las necesidades reales de cada cliente.

1.2.4. Sistematización del problema

¿La revisión del estado del arte realizada permite la construcción de una

base de conocimiento sólida para la detección de las problemáticas de la em-

presa Coldinamic S.A.S. en el área de gestión de proyectos?


¿Es posible generar un propuesta que permita adaptar el marco de trabajo

Scrum al entorno de la empresa Coldinamic S.A.S.?

¿Cómo la adopción del marco de trabajo Scrum puede ayudar a mejorar

la gestión de proyectos de la empresa Coldinamic S.A.S. y la calidad de los

productos generados en este proceso?

¿Cuáles son las ventajas que un prototipo de software le brindan a la em-

presa Coldinamic S.A.S. en el área de gestión de proyectos y calidad de sus

productos?

¿Cómo evaluar el proceso de evolución y la capacidad de satisfacer las

necesidades del cliente de cada proyecto desarrollado en Coldinamic teniendo

en cuenta criterios aceptados internacionalmente para generar confianza en la

evaluación?


1.3. Objetivos de la investigación

1.3.1. Objetivo General

Desarrollar un prototipo de software para la adopción del marco de trabajo

Scrum e integración de evaluación de proyectos a través de la adecuacion de

las normas ISO/IEC 25000, con el fin de incrementar la capacidad de Coldina-

mic para cumplir los requisitos del cliente en cada proyecto ejecutado.

1.3.2. Objetivos específicos

Investigar la metodología de gestión y desarrollo de proyectos de la em-

presa Coldinamic S.A.S para identificar su estado actual mediante entre-

vistas y revisión de los datos existentes.

Establecer con claridad y de manera conjunta (Investigador - Empresa)

los elementos de Scrum y de la familia de normas ISO/IEC 25000, que se

ajusten a las necesidades de Coldinamic como estrategia para afrontar

los problemas actuales de la organización.

Desarrollar un prototipo de soporte para la gestión de proyectos teniendo

en cuenta las buenas prácticas del marco de trabajo Scrum y la familia de

normas ISO/IEC 25000 para mejorar el proceso de gestión de proyectos.


1.4. Justificación de la investigación

La Industria del software en Colombia tiene un amplio margen de competiti-

vidad, pero también de competencia, principalmente de empresas extranjeras

con músculo económico, pero sin conocimiento del mercado específico. Es a

través de la innovación que las PYMES de la industria del software podrá com-

petir en el escenario del mercado.

”La entrada de muchas compañías extranjeras, quienes con el fin de par-

ticipar en el mercado Colombiano ofrecen en los proyectos de desarrollo de

software tarifas hora / ingeniero(a) muy bajas, condujo a que las tarifas de las

compañías Colombianas de software se redujeran. Estas últimas con el fin de

ser competitivas y conseguir un valor hora / ingeniería más bajo, han decidi-

do innovar organizacionalmente creando desde hace varios años unidades de

trabajo en ciudades intermedias donde los profesionales en Ingeniería de Sis-

temas son muy competentes y la mano de obra es menos costosa.”(Cuellar,

2013, pág. 87)

Por lo cual se hace necesario que Coldinamic S.A.S. innove no solo en

la estructura organizativa para la ejecución de cada proyecto, también imple-

mentando un software para apoyo a la gestión de sus procesos misionales,

que además permita la continua revisión y medición de la evolución de cada

proyecto y de la calidad de productos entregados, para lograr mejorar conti-

nuamente y proporcionar al cliente el mejor producto posible. Así es validado

el refrán que dice ”Lo que no se mide, no se puede mejorar. Lo que no se

mejora, se degrada siempre”

El desarrollo ágil requiere innovación y mantenerse receptivo, está basado

en generar y compartir conocimiento entre el grupo de desarrollo y con el clien-

te. Los desarrolladores de software ágil hacen uso de las fortalezas de clientes,

usuarios y desarrolladores, encontrando un proceso suficiente para balancear

calidad y agilidad (Cockburn [Cockburn, 2006])

Existe gran variedad de metodologías ágiles. De manera que es posible

complementar unas con otras, dado que el enfoque en cada una puede ser

diferente. Por ejemplo XP se centra en la programación y Scrum en la admi-

nistración.

Muchas organizaciones están utilizando el marco de trabajo Scrum, como

por ejemplo: Google, Canon, NEC, Seros, Fuji, Oracle, Toyota, Honda, Nokia,

Yahoo, Microsoft, HP, 3M, Sun, Epson. Con base en la información proporcio-

nada en el sitio de casos de estudio para Scrum [Studies, 2018].

En relación con las metodologías ágiles, el artículo IEEE ”Survey of Agi-

le Tool Usage and Needs” [Gayane, 2011] reporta el resultado de encuestas

aplicadas en 120 compañías de 35 países. En el cual más de la mitad de los

encuestados dijo que personalmente había seguido las prácticas ágiles des-

de hace 2 años, y una tercera ha llevado la metodología ágil con ellos a otra


empresa. Casi dos tercios de los encuestados dijo que hasta la mitad de los

proyectos de su empresa se realizaron utilizando ágil, y que su empresa ha

adoptado las prácticas ágiles a través de 3 o más equipos.

A continuación semuestran algunos de los datos extraídos de las encuestas

[Gayane, 2011] y posteriormente se presentan algunos gráficos asociados a

estas encuestas:

La mayoría de las compañías tienen equipos pequeños como muestra la fi-

gura 1.3. El 60% de las compañías estudiadas tienen equipos pequeños(Small

Collocated Teams), 7% utilizan equipos distribuidos(Distributed Teams) y tan

solo el 3% tienen grandes equipos(Large Collocated Teams).

Figura 1.3: Tamaño Equipos. [Gayane, 2011]

Con respecto a las metodologías ágiles usadas, Scrum se muestra como

una de los más usados con 54%, seguido con un 32% por una combinación

de Scrum con XP, XP puro 11%, lo cual muestra la alta aceptación de Scrum

en el mercado. Es importante notar el porcentaje total suma 114% significando

que algunas compañías usan más de una metodología en sus proyectos como

se muestra en la figura 1.4.

Figura 1.4: Metodologías usadas. [Gayane, 2011]


En la figura 1.5 se presentan las herramientas usadas en distintas com-

pañías, dentro de las más usadas esta el tablero físico con tarjetas que re-

presentan las historias con un 26%, la segunda herramienta es una hoja de

calculo con 23% seguida por 8% de uso para MS Project, luego se tiene las

herramientas propias (in-house tools) que tiene una participación del 5%, es

importante notar que una herramienta como Jira la cual es un referente bien

definido en el sector tenga una participación de 2%, una de las razones para

esta tasa puede deberse a su alto costo.

Figura 1.5: Herramientas de gestión para proyectos ágiles. [Gayane, 2011]

A nivel personal, ésta investigación nos permite poner en práctica los co-

nocimientos adquiridos dentro de nuestra formación académica y profesional

fortaleciendo prácticas colaborativas de aprendizaje en aras del crecimiento e

innovación de la industria y del gremio.

1.4.1. Justificación teórica

Coldinamic S.A.S. es una empresa que se puede clasificar en el rango de

las pequeñas y medianas empresas (PYME) como se advierte en la figura 1.6,

donde se ubica el grueso de las empresas del sector, por lo que la solución

propuesta, permite proyectar su implementación a un conjunto importante de

empresas del sector. El impacto de la investigación, cobra valor por su posible

aplicación a otras empresas con situaciones similares. La empresa tuvo un

crecimiento sostenido hasta el año 2015, a partir del año 2016 se registra un

notable decremento de clientes y la continuidad de los principales proyectos se

ve afectada por los retrasos en la entrega de los mismos y en general la baja

satisfacción de sus clientes.


Figura 1.6: Cantidad de empresas de software según el número de empleados,

[Cuéllar, ]

En relación con el estado financiero de la compañía, el área financiera afir-

ma que los últimos años ha tenido una distribución casi equitativa entre el pa-

sivo y el patrimonio. Los ingresos operacionales de la empresa durante el pe-

riodo comprendido entre 2015 y 2016, crecieron en 6% para el primer año y

aproximadamente un 4% para el segundo1. Como toda empresa que se crea

en el país, aún se encuentra en el periodo crítico de sobrevivencia de la enti-

dad, puesto que el mayor número de empresas que quiebran o se liquidan, se

encuentran en un periodo de 4 a 5 años. Una vez superado este umbral, se

incrementa ostensiblemente la probabilidad de permanencia y equilibrio.

”La tasa de supervivencia de las empresas colombianas a los 5 años de

nacer es inferior a la observada en países de la OCDE como Francia (52,7%),

Italia (48,3%), España (39,9%) y Reino Unido (37,5%). Esta baja tasa de

supervivencia de las empresas colombianas se explica principalmente por el

comportamiento observado en las empresas matriculadas como personas na-

turales (76% del total) las cuales registran porcentajes de supervivencia del

25,2%, 1,7 veces por debajo de la tasa registrada por las sociedades que es

del 42,8%.”( Confecamaras, 2016)

1Fuente: Informe Perdidas y Ganancias Coldinamic S.A.S


Gráfico 1. Tomado de Informe Nacimiento y Supervivencia de las Empresas

en Colombia, (Confecamaras, 2016, pág. 28)

Sumado a esto (nivel de supervivencia de las empresas) el sector de la

industria del software es un sector que compite con estándares y precios inter-

nacionales lo que lo hace sensible tanto a los cambios como a los desarrollos

de un mercado abierto a la competencia global, donde las variables del costo

país no se ligan a las capacidades de la empresa sino al ecosistema inmediato

(local y nacional), así como a las variaciones en temas de regulación, o los cos-

tos de formación de talento humano, que afectan los costos de producción, así

como la convergencia de clusters productivos, en un entorno que se entiende

como poco especializado, lo que ya le otorga unas características concretas al

ecosistema Bogotano-Colombiano.

A partir de la investigación realizada fue posible identificar las debilidades

y fortalezas que presenta actualmente la industria del software en Colombia.

Esta identificación se hizo mediante la comparación con otros países con eco-

nomías emergentes tales como las 3I’s (India, Irlanda, Israel), China, y en La-

tinoamericana con países como Brasil, Argentina, México y Chile. Se observó

que Colombia posee desventajas frente a competidores pioneros, principal-

mente debido a las barreras creadas de acuerdo con el orden de entrada a un

mercado. Estas desventajas están relacionadas con la estructura de costos,

la experiencia de los competidores pioneros en las ventas de sus productos

y el tiempo que tienen para incrementar las interacciones con la red. No obs-

tante, fue posible observar que las firmas de ingreso tardío pueden formular

varias estrategias para ingresar al mercado exitosamente. Estas estrategias


están orientadas en primera instancia a tener presencia en más de una línea

de productos o nichos de mercado dentro de un mismo sector. Igualmente, te-

niendo en cuenta que este sector no haya sido dominado por firmas pioneras,

las firmas entrantes pueden apuntar a la creación de productos con alta calidad

mediante la inversión en capacidades de innovación que les permitan competir

exitosamente con las firmas pioneras.

La problemática de la industria del software en Colombia se resume bási-

camente en: precios poco competitivos para el mercado internacional, bajos

estándares de calidad, inconveniente con el idioma de los países a exportar,

poco personal especializado, poca experiencia en mercados internacionales.”

(Palomino, 2011. pág. 69)

De esta manera es necesario en la compañías de software implementen

modelos que estén a las vanguardia de las necesidades actuales del mercado,

los cuales permiten mejorar cada día costos, calidad y tiempo de respuesta de

los proyectos.

Entregar valor al cliente durante todo el desarrollo del proyecto, es primor-

dial para garantizar la satisfacción de las necesidades del mismo a través de

un entorno de transparencia en la comunicación, responsabilidad colectiva y

progreso continuo.

1.4.2. Justificación metodológica

Existen varias metodologías de software, pero es importante tener en cuen-

ta las características generales de los modelos y su relación con el proyecto a

desarrollar para aplicar la más conveniente.

Es por ello que, para poder entender cuál es la interrelación que existe

entre los principales factores que influyen en el desarrollo de software y cuáles

son los principales efectos, es necesario conocer las características de manera

general de los modelos tradicionales y los actuales para lograr la selección

de un modelo que permite optimizar y agilizar el proceso de desarrollo, dado

los tiempos limitados para ejecución del mismo, sin dejar de lado la calidad

requerida en cada desarrollo.

Características modelos de desarrollo de software

1. Modelo en cascada

a) Necesario tener todos los requisitos al inicio del proyecto

b) Se tiene el producto hasta el final del proyecto

c) Ausencia de indicadores del progreso del proyecto

d) Más lento que los demás modelos


2. Aproximación prototipo

a) Los usuarios finales, ven el prototipo y no consideran que no es la

versión definitiva, no tienen encuentan aspectos de calidad

b) Cambios en el prototipo son solicitados continuamente, lo que ge-

nera avance lento

3. Aproximación espiral

a) Desde el punto de vista organizativo: Los costos son altos y el tiempo

empleado.

b) Debido a su elevada complejidad no se aconseja utilizarlo en peque-

ños sistemas.

4. Metodologías ágiles

a) Rápida respuesta a los cambios solicitados por el cliente

b) Intervención del cliente en el proceso de forma activa para opinar

sobre los resultados

c) Eliminación de tareas innecesarias, las cuales no tienen mayor peso

en el desarrollo del proyecto

Los requisitos del proyecto no están definidos es su totalidad en la fase ini-

cial, pueden ser cambiantes según los hallazgos que se produzcan en el análi-

sis al modelo actualmente empleado en la organización para ejecución de sus

proyectos. Es así como se hará uso de Scrum como metodología para poder

no solo garantizar optimizar y agilizar el desarrollo del producto, también para

recibir constante retroalimentación por parte de los futuros usuarios del siste-

ma y aportar mayor valor al negocio con la concepción de módulos flexibles

que se ajusten a las necesidades de Coldinamic.

1.5. Hipótesis

La adaptación del marco de trabajo Scrum incorporando la evaluación de

calidad de productos del proceso de desarrollo de software, influye significativa-

mente sobre el incremento de la calidad y reducción en los tiempos de entrega

de los proyectos ejecutados en Coldinamic S.A.S.

A través de la puesta en marcha del prototipo de software basado en la

adaptación anteriormente planteada (Scrum e incorporación de buenas prac-

ticas basadas en la familia de normas ISO/IEC 25000), permitirá un alto in-

cremento de enfoque ágil en la organización, lo que conlleve a lograr mayor

eficiencia por parte del equipo y calidad de las pre-entregas y entregas finales.

Representando un incremento en el retorno a la inversión (ROI) y la fidelización

de sus clientes.

Capítulo 2

MARCO REFERENCIAL

22

CAPÍTULO 2. MARCO REFERENCIAL 23

2.1. Marco teórico

Metodologías de desarrollo de software tradicionales

En las empresas del sector de software las metodologías tradicionales son

usadas ampliamente, de manera general puede describirse los modelos tra-

dicionales como basados en la división de un proyecto en una secuencia de

actividades que se ejecutan de forma coordinada y estricta hasta conseguir los

objetivos planteados. Los procesos de desarrollo de software se ejecutan en

función del ciclo de vida del software que se describe a continuación:

1. Análisis:: Etapa inicial del proyecto la cual incluye definición y la cons-

trucción de un modelo a partir de los requisitos.

2. Diseño:: Construcción de diseños para ejecutar cada uno de los compo-

nentes del proyecto y planificación de tareas para alcanzar el objetivo.

3. Implementación: Construcción del sistema, codificación.

4. Pruebas: Se verifica el sistema cumple con los requerimientos plantea-

dos y se realizan las correcciones necesarias .

5. Entrega: Se considera el proyecto culminado y se entrega al cliente el

producto final.

Las metodologías de gestión de proyectos son importantes porque ayudan

en la organización, estructuración y ejecución de un proyecto. Las metodo-

logías tradicionales basan su filosofía en el modelo en cascada enfocado en

completar cada paso con un alto grado de exactitud, antes de iniciar el siguien-

te.

El modelo en cascada trabaja con una serie de documentos, que para al-

gunos autores lo hacen riguroso y poco práctico. La entrega y salida de cada

una de las fases de la metodología es un tipo de documento. Los documentos

manejados son:

Análisis: Documento de descripción en lenguaje natural de lo que quiere

el cliente. Produce el documento de requerimientos del software.

Diseño: Produce el documento de diseño del software

Implementación: Produce la documentación del software

Pruebas: Documento de casos de prueba.

Entrega: Manual de usuario y configuración del sistema.

El modelo en cascada ha sido el más utilizado en los últimos años, se es-

tima que el 90% de los sistemas han sido desarrollados con esto modelo de

desarrollo de software.


A continuación se presenta los resultados del informe Chaos publicados

por The Standish Group en 2009 [The Standish Group International, 2009], en

el cual se presenta la situación del software entre los años 2000 a 2008, se

realiza la categorización de los proyectos en:

Exitosos (Suceceeded): El proyecto es entregado cumpliendo los requi-

sitos del cliente, en el tiempo pactado.

Fallidos (Failed): Proyectos cancelados sin terminarse.

Con problemas (Challenged): El proyecto puede tener sobre costos y/o

con menos funcionalidades de las requeridas. [The Standish Group Inter-

national, 2009]

Figura 2.1: Resolución de proyectos de software [The Standish Group Interna-

tional, 2009]

El porcentaje de proyectos que son fallidos es alto, entre los motivos consi-

derados en su momento para que la mayoría de proyectos de software fraca-

saran en ese momento fue la forma tradicional que se desarrollaban, las cuales

no son consideradas idóneas para los tipos tradicionales de proyectos en los

cuales el cliente no sabe realmente que quiere en las etapas iniciales.

Para encajar mejor en este tipo de proyectos de software, surgen las me-

todologías livianas, que permiten entregas tempranas del software con valor

para generar retroalimentación con el cliente o usuario final.


“Desde hace unos pocos años ha habido un interés creciente en lasmetodo-

logías ágiles (léase ”livianas”). Caracterizadas alternativamente como antídoto

a la burocracia, han suscitado interés en el panorama del software.” [Fowler,

1999]

Metodologías ágiles

Tal como lomencionaMartin Fowler en su artículo ”NewMethodology” [Fow-

ler, 2005], podría decirse que el desarrollo de software es una actividad caótica,

frecuentemente caracterizada por la frase ”codifica y corrige”.

El software se escribe con un plan de desarrollo, y el diseño del sistema se

estructura con muchas decisiones a corto plazo. Esto generalmente funciona

bien cuando se desarrollan proyecto pequeños, pero conforme el sistema es

más grande y complejo adicionar nueva funcionalidad se vuelve difícil y más

caótico. Además el mantenimiento se convierte en una tarea cada vez más

difícil de realizar.

Aunque este estilo de desarrollo es el más utilizado por las organizaciones,

también han surgido alternativas desde hace mucho tiempo. Metodologías que

incorporan procesos disciplinados sobre el desarrollo de software, con énfasis

en la planeación. Dichos procesos definen artefactos de desarrollo, documen-

tación, actividades, herramientas, roles y notaciones a ser utilizadas. Como

resultado, los procesos generan documentación con el fin de facilitar el enten-

dimiento en el equipo de trabajo. Aunque existen varios procesos de desarrollo

(proceso Unificado, modelo V, etc) [Ivar, 1999], etc., la mayoría de estos pro-

cesos se derivan del Modelo de Cascada propuesto por Boehm [W., 1976].

Los modelos tradicionales han mostrado ser eficientes en casos particula-

res por ejemplo proyecto grandes con requerimientos claro y estables desde

etapas tempranas. El principal problema de estas metodologías son los buro-

cráticos los procesos que siguen, hacen estosmodelos lentos y poco eficientes.

Fowler afirma que, hay tanto que hacer para seguir la metodología que el

ritmo entero del desarrollo se retarda. Sin embargo, debido a entornos comer-

ciales más competitivos, conducidos por la rapidez para producir y entregar

servicios [Ridderstrale, 2000], de esta manera el enfoque propuesto por estas

metodologías tradicionales no resulta el más adecuado.

Los nuevos entornos se caracterizan por el desarrollo de proyectos don-

de los requerimientos del sistema son desconocidos en etapas iniciales, las

necesidades son cambiantes e inestables, en los cuales se esperan tiempos

cortos de desarrollo, al mismo tiempo, producción de productos de alta calidad,

además garanticen mínimo riesgo ante la necesidad de incluir cambios a los

requisitos del sistema.

Ante estas nuevas necesidades de proceso de desarrollo de software y los

inconvenientes de los modelos tradicionales (pesados, complejos, estructuras

estrictas, sobrecarga de procesos y documentación), surgen alrededor de los

años 90 un grupo de modelos conocidos inicialmente como metodologías lige-


ras, pero aceptadas como el termino metodologías ágiles definido por la Agile

Alliance.

Estas metodologías ágiles tienen como objetivo principal realizar entregas

rápidas, por ello, definen características relevantes que el software debe cum-

plir bajo el alcance de un tiempo determinado.

Indicadas para productos cuya definición inicial no es detallada, clara, com-

pleta, en los cuales resulta crucial para el proyecto agregar valor iterativamente

con continua retroalimentación por parte del cliente.

Aunque incluyen prácticas esenciales de las metodologías tradicionales, las

metodologías ágiles intentan trabajar con un mínimo de documentación ne-

cesaria, centrando sus objetivos en la comunicación directa entre todos los

integrantes del equipo, software funcionando, la colaboración con el cliente,

responder antes los cambios en lugar de seguir un plan estricto de ejecución

del proyecto.

Entre sus principales características están:

Colaboración con cliente: Cooperación activa de los usuarios durante

las fase de ejecución del proyecto

Software funcionando: El desarrollo iterativo e incremental del software

permite entregas de software con funcionalidad disponible en cada entre-

ga

Reducir los tiempos de entrega: Bajar los tiempos de desarrollo gracias

al enfoque en realizar entregar de software funcionando en cada etapa,

dejando de lado la documentación extensiva y optimización del uso de

recursos disponibles

Responde a los cambios: En lugar de seguir un plan estricto de desarro-

llo, responder a los cambios de manera eficaz y minimizando el número

de errores, que su vez permite mantener una alta grado de calidad del

producto y satisfacción del cliente.

Aunque no se deben dejar de lado algunos elementos en el proceso de

desarrollo de software como la documentación, los planes de trabajo se debe

valorar más los elementos que permiten mejorar la calidad de los productos y

los tiempos de respuesta.

Esto características permite un punto medio entre la burocracia de los pro-

cesos y la ausencia de procesos, para tener simplemente lo necesario, como

dice Fowler, el esfuerzo valga la pena.

De esta manera, el concepto de modelado liviano cobra sentido por las ca-

racterísticas anteriormente mencionadas, definiendo la forma de abordar un

proceso de desarrollo de software de forma ágil y liviana, a través de la des-

cripción de prácticas y principios.


Hacia el siglo XX, miembros prominentes de la comunidad se reunieron en

Snowbird, Utah, y adoptaron el nombre de ”metodologías ágile” y definieron el

manifiesto ágil. Poco después, conformaron la Agile Alliance, organización que

apoya a las entidades personas que investigan y aplican los valores, practi-

cas, enfoques ágiles, aplicado a las soluciones de software. Cabe aclarar que

muchos métodos ágiles se originan antes del 2000 como: Scrum (1986), pro-

gramación extrema o XP (1996), desarrollo de software adaptativo, Método de

desarrollo de sistemas dinámicos (1995), entre otros.

El manifiesto ágil

Creado por un grupo de expertos y críticos de la industria de software,

conformado por 17 representantes de procesos de desarrollo livianos. Las 17

personas fueron Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cock-

burn, Ward Cunningham, Martin Fowler, James Grenning, Jim Hihsmith, An-

drew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J.

Mellor, Ken Schwaber, Jeff Sutherland, Dave “Pragmatic” Thomas. El manifies-

to ágil es un resumen de los principios sobre los que se basan las metodologías

ágiles.

Los integrantes llevaron a cabo una reunión para identificar aspectos en co-

mún para las diferentes metodologías livianas que se habían concebido has-

ta el momento: Adaptative Software Development, XP, Scrum, Crystal, FDD,

DADM y Pragmatic Programming. Tal como lo aclara Cockburn [Cockburn,

2007], ninguno estaba interesado en combinar las prácticas para crear una

Metodología Liviana Unificada (Unified Light Methodology – ULM).

En esta reunión se genero un documento en el cual se basan los méto-

dos ágiles, denominado como Manifiesto Ágil [Kent, 2001]. El Manifiesto Ágil

incluye cuatro postulados y una serie de principios asociados. Tal como hace

observar Alistair CockBurn [Cockburn, 2007], el manifiesto inicia informando

que se están sacando a la luz mejores formas de desarrollar software, no las

están inventando.

Además, que el resultado se obtuvo de la experiencia directa y la reflexión

sobre la experiencia y que se reconoce valor a las herramientas, procesos,

documentación, contratos y planes, si bien ponen mayor énfasis en otros va-

lores. Por esto razón se puede decir que las metodologías ágiles cambiaron

significativamente los énfasis de las modelos tradicionales.

Sus postulados son:

1. Valorar al individuo y a las interacciones del equipo de desarrollo por en-

cima del proceso y las herramientas. Este postulado enuncia que las per-

sonas son componentes primordiales en cualquier desarrollo [Cockburn,

1999]. Tres premisas sustentan este postulado:

a) Los integrantes del equipo son el factor principal de éxito.

b) Es más importante construir el equipo de trabajo que construir el

entorno.


c) Es mejor crear el equipo y que éste configure el entorno con base a

sus necesidades [Mendes Calo, 2010].

Se presta atención a las personas en el equipo como opuesto a los roles

en un diagrama de proceso, donde las personas son reemplazables. Y

por otro lado se presta atención a la interacción de los individuos. Es

preferible un proceso no documentado con buenas interacciones que un

proceso bien documentado con interacciones hostiles [Cockburn, 2007].

2. Valorar el desarrollo de software que funcione por sobre una documenta-

ción exhaustiva. El postulado se basa en la premisa que los documentos

no pueden sustituir ni ofrecer el valor agregado que se logra con la co-

municación directa entre las personas a través de la interacción con los

prototipos. Se debe reducir al mínimo indispensable el uso de documen-

tación que genera trabajo y que no aporta un valor directo al produc-

to [Mendes Calo, 2010].

El sistema funcionando es lo único que muestra lo que el equipo ha desa-

rrollado. Correr código es honestidad implacable. La documentación la

utiliza el equipo para reflexionar, como pistas de lo que se debería reali-

zar. El acto completo de reunir requerimientos, diseñar, codificar, probar

el software revela información del equipo, el proceso, y la naturaleza del

problema a resolver. Esto, junto con la posibilidad de correr el resultado

final, provee la única medida confiable de la velocidad del equipo, y un

vistazo de lo que el equipo deberían estar desarrollando. Los documen-

tos pueden ser útiles pero deben usarse en la “medida justa” o “apenas

suficiente” [Cockburn, 2007].

3. Valorar la colaboración con el cliente por sobre la negociación contrac-

tual. En el desarrollo ágil el cliente se integra y colabora con el equipo de

trabajo. Se asume que el contrato en sí, no aporta valor al producto, sino

que es sólo un formalismo que establece líneas de responsabilidad entre

las partes [Mendes Calo, 2010]. Es muy importante la relación entre la

persona que quiere el software y los que la construyen. La Colaboración

se refiere a amigabilidad, toma de decisiones conjuntas, comunicación

rápida, y conexiones de interacción entre individuos. Aunque a veces los

contratos son útiles, la colaboración fortalece el desarrollo tanto cuando

hay un contrato como cuando no existe el contrato [Cockburn, 2007].

4. Valorar la respuesta al cambio por sobre el seguimiento de un plan. La

evolución rápida y continua deben ser factores inherentes al proceso de

desarrollo. Se debe valorar la capacidad de respuesta ante los cambios

por sobre la capacidad de seguimiento y aseguramiento de planes pre-

establecidos [Mendes Calo, 2010].

El valor final se refiere a la rapidez para ajustarse a los cambios del pro-

yecto. Construir un plan es útil y cada metodología ágil contiene activida-

des de planificación específicas. Pero también tienen mecanismos para

manejar cambios de prioridades.

Los marcos de trabajo Scrum, DSDM, Adaptative Software Development

adoptan un desarrollo basado en períodos fijos (timebox) con planeación pos-


terior a cada periodo fijo (timebox), en cambio la metodología XP si permite

planeación durante los periodos fijos que van desde dos a cuatro semanas.

La iteraciones regulares permite que el equipo tenga tiempo suficiente para

desarrollar una funcionalidad, en este tiempo no se permiten cambios en la

iteración o en la conformación del equipo. Al trabajar con iteraciones cortas,

los sponsors del proyecto pueden cambiar las prioridades para que reflejen

sus necesidades [Cockburn, 2007].

Los postulados descriptos anteriormente, permiten diferenciar un proceso

ágil de uno tradicional. Los doce principios del Manifiesto Ágil son las carac-

terísticas que lo diferencias, dos de ellos hacen referencias a generalidades,

cuatro estas relaciones con las metas, organización del equipo de desarrollo,

los seis restantes con el proceso de desarrollo, a continuación se presentar los

doce principios del manifiesto ágil [Kent, 2001].

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega tem-

prana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desa-

rrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ven-

taja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos

meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de

forma cotidiana durante todo el proyecto.

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

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

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo

constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la

Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado,

es esencial.

11. Lasmejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo

para a continuación ajustar y perfeccionar su comportamiento en conse-

cuencia. [Kent, 2001]


Los enunciados anteriormente mencionados describen la idea de ágil con

mayor detalle, cabe aclarar que cada metodología considerada como ágil aun-

que se basa en estos principios, tiene sus características propias, con aspectos

más específicos.

En el manifiesto ágil no se incluye la necesidad de adaptar la metodología a

cada tipo de proyecto, es decir no es lo mismo un proyecto con tiempo de eje-

cución de un año con más de treinta recursos, a un proyecto de diez recursos

para unos cuantos meses.Aunque algunos autores recomienda la metodología

ágil para proyectos en los cuales la incertidumbre es la principal característi-

ca, para Cockburn, en su propia experiencia aún sirvió esta metodología en

proyectos supuestamente estables.

En el manifiesto no se encuentra la necesidad de diferentes formas de tra-

bajar en diferentes situaciones, pero Jim Highsmith y Alistar Cockburn [Cock-

burn, 2007] aconsejan tener esta idea en mente.


2.1.1. Metodología XP

Programación extrema pertenece al conjunto de metodologías ágiles, sus

principales objetivos son: aumentar la productividad en el desarrollo de softwa-

re, mejora continua al usuario, el trabajo en equipo, adaptabilidad y garantizar

la calidad de software desarrollado.

Los principales enfoques de la metodologías son:

Favorecer las relaciones interpersonales.

Fomentar el trabajo en equipo.

Aprendizaje continuo de los desarrolladores.

Retroalimentación entre el cliente y el equipo.

Clima de trabajo apropiado.

Comunicación apropiada entre los involucrados.

Clima de trabajo apropiado.

Soluciones implementadas caracterizadas por su simplicidad.

Ímpetu para enfrentar los cambios.

XP engloba un conjunto de prácticas y reglas para desarrollar software ba-

sada en diversas maneras de enfrentar ambientes muy cambiantes. Algunas

de las reglas son: clientes bien definidos, equipos pequeños y muy integrados

(máximo 12 personas) con formación elevada.

Doce prácticas básicas de la programación extrema:

1. Equipo completo

2. Planificación

3. Pruebas del cliente

4. Versiones pequeñas

5. Diseño simple

6. Pareja de programadores

7. Desarrollo guiado por las pruebas automáticas

8. Integración continua

9. El código es de todos

10. Normas de codificación


11. Metáforas

12. Ritmo sostenible

XP en comparación de las metodologías tradicionales es mas rápida, por-

que conlleva menos protocolo, evita que existan jerarquías en el grupo, facili-

tando la participación de cualquier integrante del grupo.

Algunos autores coinciden en que esta metodología es recomendable solo

para proyecto a corto plazo, los resultados que se generan a lo largo de la

implementación se validan al instante y de existir algún error se realizan las

mejoras en el momento.

Así los resultados son verificados por el cliente para aprobación del produc-

to, permitiendo garantizar cumple con los requisitos el resultado final. De esta

manera se logra satisfaces las necesidades del usuario en un alto grado.

XP se centra centran en los requisitos del cliente para lograr un producto de

alta calidad, cumpliendo los tiempos establecidos que deben ser cortos, ajusta

estrictamente a una serie de reglas lo cual la hace menos flexible.

El ciclo de desarrollo consiste de manera general en los siguientes pro-

cesos: exploración, planeamiento, producción, mantenimiento y muerte. [Zha-

mungui, 2013]

Figura 2.2: Ciclo de desarrollo XP [Zhamungui, 2013]

En todas las iteraciones de este ciclo el cliente y el desarrollador de soft-

ware aprenden. El cliente gestiona el ámbito de entrega del producto y debe

asegurarse que el software tenga el mayor valor de negocio posible en cada

iteración realizada por el equipo de trabajo.

Ventajas

1. Productos funcionales en menor tiempo. Proceso de integración conti-


nuo, de esta manera el tiempo empleado al final en integración es míni-

mo.

2. Programación organizada.

3. Menor tasa de errores, gracias al diseño de las pruebas antes de la co-

dificación y a la programación en parejas.

4. Mayor satisfacción del cliente, ya que se atienden las necesidades del

usuario con mayor precisión.

5. Gracias al refactoring”1 es más fácil el modificar los requerimientos del

usuario.

Desventajas

1. Recomendable emplearlo solo para proyectos a corto plazo.

2. La planeación del proyecto incluido costos y la duración del mismo son

complicados de calcular.

3. El uso de medidas para conocer el avance del proyecto es difícil.

4. Altos costos asociados a la falla en la implementación.

2.1.2. Scrum

”Un marco de trabajo en el que las personas pueden hacer frente a pro-

blemas complejos adaptables, mientras que de manera productiva y creativa

entregan productos del mayor valor posible. Scrum es: Ligero, fácil de enten-

der, dificil de dominar” [schwaber and jeff sutherland, 2011]

’Scrum es un marco de trabajo basado en un conjunto de valores, principios

y prácticas que suministran los fundamentos para que cada organización le

agregue su implementación única” [Rubin, 2011]

Es el método ágil más popular en el momento, puede ser adaptado no solo

a procesos de desarrollo de software, en general a diferentes tipos de activida-

des. El marco de trabajo se enfoca en las personas, quienes trabajan de forma

auto dirigida, a través de prácticas colaborativas para minimizar los riesgos en

la ejecución de cada proyecto.

Permite gestionar las expectativas de los clientes de manera regular a tra-

vés de cada una de las iteraciones. Enfatiza en los valores (honestidad, aper-

tura, esfuerzo, respecto, confianza, colaboración, entre otros), las prácticas de

1Concepto descrito por Matin Flowler [Fowler, 1999]


gestión y cuestiones técnicas de desarrollo que permiten aumentar la produc-

tividad del desarrollo y la calidad de los productos.

Proceso de desarrollo en Scrum

Enfocada en la organización del equipo de trabajo, divide el proyecto en

periodos de una a cuatro semanas denominados Spring, cada equipo recibe

una lista de actividades a ejecutar en un Sprint, lo cual se conoce como la pila

del Sprint.

Ciclo de Scrum

El desarrollo de un producto tiene un ciclo de vida en la metodología Scrum.

En el ciclo de vida de scrum intervienen unas actividades, roles y artefactos

definidos por el marco de trabajo. A continuación se muestre el ciclo de vida

Scrum y posterior se describen cada unos de los elementos que interactúan en

el ciclo. [Canive, 2017]

Figura 2.3: Ciclo de desarrollo Scrum [Canive, 2017]

Eventos de Scrum

Scrum define seis eventos: sprint, planeación del sprint, reunión diaria, re-

visión del sprint, retrospectiva del sprint y refinamiento de la pila del producto.

Sprint

Período en el cual se crea algo de valor tangible para el usuario y/o cliente,

la iteración que lleva a cabo el trabajo en sí. Se recomienda iteraciones regu-

lares con una duración de dos a cuatro semanas, definida por el equipo con

base en su propia experiencia y en el ritmo del equipo.

Durante el sprint no se deben permitir cambios el la pila del sprint o en el

equipo, a menos que su no inclusión amenace el éxito del proyecto. Al finalizar

el sprint, se debe tener un producto que genere valor y se pueda entregar al

cliente.


Planeación del Sprint

En la reunión de planeación se define el objetivo y entregable del Sprint,

determinado los elementos de la pila del producto que el equipo de desarrollo

implementara.

Los elementos tomados de la pila de producto deben ser los de más alta

prioridad, estos se dividen en tareas y determinan la pila del Sprint.

La reunión tiene una duración de ocho horas para un Sprint de un mes, y

asi proporcionalmente según la duración del Sprint.

Reunión diaria

El equipo se reune para conocer el estado del proyecto, tiene una duración

máxima de quince minutos. El evento fomenta el trabajo colaborativo y permite

tener visibilidad de la evolución del proyecto.

El equipo de desarrollo es el responsable de dirigir la reunión diaria y el

Scrum Master debe asegurarse de que la reunión se realice cada día, solo los

involucrados en el proyecto pueden hablar, se recomienda que los miembros

del equipo de desarrollo respondan tres preguntas:

1. ¿Qué has hecho desde ayer?

2. ¿Qué es lo que haré hoy?

3. ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?.

El objetivo de este evento es que cada involucrado identifique si se están

cumpliendo con los plazos determinados para el Sprint.

Retrospectiva del Sprint

El propósito es la mejora continua del proceso. Se lleva a cabo después

de cada Sprint y se enfoca en identificar cuán colaborativo y productivo fue el

equipo y cómo mejorar.

Duración aproximada de tres horas para un Sprint de un mes y así propor-

cionalmente, al final todos los miembros del equipo dejan presentan su impre-

sión sobre el sprint y se comprometen con acciones para mejorar el proceso.

Revisión del Sprint

El propósito es presentar las funcionalidades que fueron desarrolladas en

el Sprint. Duración máxima de cuatro horas para un sprint de un mes, a este

evento deben asistir todos los involucrados relevantes, para retroalimentación

y poder adaptar los hallazgos encontrados a los siguientes Sprints.

Refinamiento de la pila del producto


Revisión de la pila de producto para identificar nuevas prioridades, adición

y/o eliminación de elementos, este evento es liderado por el propietario del

producto quien es el responsable de cualquier cambio en la pila del producto y

de la toma de decisiones.

Artefactos

Scrum define tres artefactos que serán descritos a continuación

Pila del Producto

Se puede definir como un documento de alto nivel para la ejecución del

proyecto. Son las características requeridas para la realización del producto.

Se busca realizar el trabajo más valioso en la etapa inicial según su retorno

sobre la inversión (ROI).

Determina lo qué va a ser construido en su totalidad, la pila del producto en

el desarrollo del proyecto se puede alimentar con nuevas características, sufrir

modificaciones a sus características, correcciones de incidencias reportadas,

mejoras técnicas y/o adquisición de conocimiento.

Pila del Sprint

Subconjunto de requisitos implementados durante un Sprint. Al definir la

pila del Sprint, se determina la velocidad del equipo para establecer el tiempo

para desarrollo del Sprint y se describe cómo el equipo va a implementar estos

requisitos.

Los elementos de la pila del producto son divididos en tareas, para asignar-

les horas de trabajo, estas tareas no deben ser asignadas son tomadas por los

involucradas según sus habilidades.

Incremento del producto

Parte del producto listo para ser entregado, funcionalidad de valor para el

negocio.

Roles

En Scrum se identifican tres roles.

Propietario del producto

Encargado de gestionar el producto y el retorno a la inversión ROI. Empo-

derado para ser el punto central, debe comunicar a los miembros lo que se

espera obtener.

Scrum Master

Es un facilitador ayuda a los miembros del equipo a resolver cualquier impe-


dimento para la realización de sus actividades. Gestiona el proceso ayudando

al equipo a alcanzar un alto desempeño.

Equipo de desarrollo

Desarrolla el producto y es auto dirigido. Debe ser multifuncional es decir,

los miembros deben contar con todas las habilidades necesarias para gene-

rar un producto funcional. Es recomendable un equipo de desarrollo con un

tamaño entre tres y nueve miembros.

Ventajas

1. Gestiona los requisitos de los usuarios y/o clientes de manera regular

2. Permite obtener productos de valor para el negocio desde las primeras

iteraciones

3. Optimiza el uso de recursos y aumenta la productividad

4. Permite administrar la complejidad de los proyectos

5. Disminuye el número de errores

6. Incrementa la calidad del producto final

Desventajas

1. Alta disponibilidad del cliente

2. Relación con el cliente basada en principios de colaboración

2.1.3. Evaluación de la calidad del software

En los últimos años en el sector de las tecnologías de software, se ha gene-

rado la necesidad de evaluar la calidad de los productos desarrollos para lograr

satisfacer las necesidades de sus usuarios. Siguiendo estas necesidades en

los productos de software, surgen algunos modelos, normas y/o estándares de

calidad.

Norma ISO/IEC 9126

Es un estándar internacional para la evaluación de productos de software.

Clasifica la calidad del software en seis características:

1. Funcionalidad: El aseguramiento que el producto funciona tal como esta-

ba especificado, proporcionando las funciones que satisfacen los reque-

rimientos explícitos e implícitos. Incluye las siguiente subcaracterísticas:


cumplimiento con la funcionalidad, apropiabilidad, exactitud e interopera-

bilidad.

2. Confiabilidad: La capacidad que tiene un producto de software para pro-

porcionar consistencia de los resultados que presenta, mantiendo un alto

nivel de desempeño cuando es usado en condiciones limite. Subcaracte-

risticas asociadas: cumplimiento con la confiabilidad, madurez, tolerancia

a fallas y recuperabilidad.

3. Usabilidad: La facilidad con que las personas pueden utilizar el produc-

to de software, subcaracteristicas que lo componen: cumplimiento con

la usabilidad, comprensibilidad, facilidad de aprendizaje, operabilidad y

atractivo.

4. Eficiencia: Proporcionar el desempeño adecuado relacionado a la can-

tidad de recursos usados, bajo condiciones determinadas. Subcaracte-

rísticas asociadas: cumplimiento con la eficacia, comportamiento en el

tiempo y utilización de recursos.

5. Facilidad de Mantenimiento: Facilidad para modificar un producto sin ge-

nerar mayores contratiempos. Incluye las siguientes subcaracterísticas:

cumplimiento con la facilidad de mantenimiento, trazabilidad, estabilidad,

facilidad de cambio y ensayo.

6. Portabilidad: Capacidad del producto para ser transferido de forma efec-

tiva y eficiente de un entorno hardware, software, operacional o de utili-

zación a otro. Subcaracterísticas: cumplimiento con la portabilidad adap-

tabilidad, coexistencia, reemplazabilidad e instalabilidad.

Norma ISO/IEC 14598

Norma para la evaluación de productos de software, es un estándar para la

evaluación de la calidad de cualquier tipo de producto software, establece los

parámetros para el proceso de evaluación e incluye los métodos de medición.

La norma abarca todo el proceso de desarrollo de software a través de seis

partes, ver figura 2.4.

Figura 2.4: Fases de ISO/IEC 14598 [Lozano, 2013]

1. ISO/IEC 14598-1 Visión General: establece un resumen de las otras cin-

co etapas, explica la relación entre la evaluación del producto software


y el modelo de calidad. Actividades: (Establecer los requerimientos de

evaluación, Especificar la evaluación, Planear la evaluación, Ejecutar la

evaluación). [Lozano, 2013]

2. ISO/IEC 14598-2 Planificación y Gestión: contiene requisitos y guías pa-

ra las funciones de soporte tales como la planificación y gestión de la

evaluación del producto del software. Actividades: (Preparación de políti-

cas, definición de objetivos, Identificación de la tecnología, Asignación de

responsabilidades, Evaluación de software desarrollado y adquirido). [Lo-

zano, 2013]

3. ISO/IEC 14598-3 Proceso de desarrolladores: Lo utiliza las organizacio-

nes que planean desarrollar un producto o mejorar uno existente, reali-

za evaluaciones de producto utilizando indicadores que puede predecir

la calidad de los productos finales. Actividades: (Organización, Planea-

miento, Especificaciones, Diseño, Montaje) [Lozano, 2013]

4. ISO/IEC 14598-4 Proceso de comparadores: Lo utilizan las organizacio-

nes que pretenden comparar o rehusar un producto de software existen-

te, se aplica con el propósito de aceptación de un producto. Actividades:

(Requerimientos, Especificación evaluación, Diseño evaluación, Ejecu-

ción evaluación). [Lozano, 2013]

5. ISO/IEC 14598-5 Proceso evaluadores: este proceso es utilizado por or-

ganizaciones encargadas de evaluar, provee los requisitos y guías para

la evaluación del producto software. Promueve las siguientes característi-

cas de proceso (repetible, Reproducible; Imparcial, Objetivo) Actividades:

(Trazabilidad, Resultados, Problemas, Mejoras, Conclusiones) [Lozano,

2013]

6. ISO/IEC 14598-6 Modulo evaluación: Especifica las mediciones que van

a ser tomadas sobre los atributos de calidad que se definieron en la etapa

anterior, provee las guías para la documentación de la evaluación. Acti-

vidades: (Introducción, Alcance, Entradas, Resultados) [Lozano, 2013]

Familia de Normas ISO/IEC 25000

Es un esfuerzo para reunir las normas ISO 9126 e ISO 14598, las cuales

describen las características de unmodelo de calidad y el proceso de evalución

de productos de software respectivamente.

La guía proporciona los lineamientos internacionales para orientar el desa-

rrollo de software mediante la especificación de requisitos y evaluación calidad

de productos de software. Permite organizar y unificar los procesos de medi-

ción de calidad de software, con criterios estandarizados de evaluación.

Esta norma se encuentra dividida como sigue:

ISO/IEC 2500n. Gestión de calidad: Establece los modelos, términos y

referencias.


ISO/IEC 2501n. Modelo de calidad: Guía para el modelo de calidad de

manera detallada, incluye características para la calidad interna, externa

y en uso, ver figura 2.5.

ISO/IEC 2502n.Mediciones de calidad: Incluye los estándares demodelo

de referencia de calidad del producto software, definiciones y guía para

aplicación de matemáticas de las métricas de calidad en características

de calidad interna, externa y de uso.

ISO/IEC 2503n. Requisitos de calidad: Principal objetivo es la especifica-

ción de los requisitos de calidad.

ISO/IEC 2504n. Evaluación de la calidad: Recomendaciones para la eva-

luación de un producto de software.

ISO/IEC 25050–25099. Estándares de extensión SQuaRE: Reservado

para normas y/o reportes técnicos que abarcan dominios de aplicación

específicos.

La norma anteriormente describa se origina como respuesta a la necesi-

dad de establecer criterios sólidos de evaluación del software para favorecer

la constitución de productos con altos niveles de calidad, sostenibles y renta-

bles.

Figura 2.5: Medidas de calidad software ISO 25010 [Mellon, 2004]


2.1.4. Arquitectura Empresarial

El conceptoArquitectura Empresarial se origina por Jhon Zachman en 1984,

publicado por IBM en 1987 [Zachman, 1987]. El enfoque es garantizar que to-

dos los elementos o recursos de una empresa estén bien organizados y rela-

cionados como un sistema integral.

La arquitectura empresarial es la organización de los componentes, inter-

relaciones internas, externas y gobernabilidad de un sistema. Esto quiere decir

que se tiene en cuenta el modelo de negocio y de operaciones, la estructura or-

ganizacional, procesos de negocio, datos, aplicaciones y tecnología. [Bellman

and Griesi, 2015] Se puede decir que una arquitectura es el diseño y descrip-

ción de una organización o entidad como un sistema en términos de sus com-

ponentes y relaciones y que la arquitectura empresarial es construir modelos

(modelamiento) de la realidad. Estos modelos se reflejan en los entregables.

La arquitectura empresarial permite adquirir un discurso para adentrarse al

alma de la organización y convencerlos que TI no es una muleta o soporte. A

demás permite adquirir una forma de comunicación de alto nivel para que las

personas comprendan los términos según su nivel. La palabra alto nivel es muy

recurrente en arquitectura y permite hacer abstracciones muy sintetizadas.

Arquitectura de Conceptos Básicos Cuando se conversa sobre arquitec-

tura empresarial es válido plantear las siguiente preguntas: [Lengerke, 2013]

¿Cuál es el objetivo de la Arquitectura Empresarial?

Integrar los componentes que conforman a nuestra empresa, creando un

ambiente capaz de responder a las necesidades del cambio, utilizando

TIC (Tecnologías de la Información Computacional) como un factor clave

del éxito.

¿Cuál es la definición de Arquitectura Empresarial?

Integrar los componentes que conforman a nuestra empresa, creando

un ambiente capaz de responder a las necesidades del cambio, utilizan-

do TIC (Tecnologías de la Información Computacional) como un factor

clave del éxito. Es la organización lógica de procesos de negocio e in-

fraestructura de tecnologías de la información que refleja la integración y

estandarización de los requerimientos de nuestro modelo operativo.

¿Cómo fue la evolución de la Arquitectura Empresarial?

La línea de tiempo de una arquitectura muestra el proceso que se lleva

a cabo desde el concepto de empresa hasta la migración ver figura 2.6.

Formas de ver una Arquitectura Existen tres formas de ver una arquitec-

tura las cuales son: disciplina, producto y proceso.

Disciplina: Gobierna los cambios de la arquitectura.


Figura 2.6: Línea de Tiempo de una Arquitectura Empresarial. Fuente: [Villal-

pando, 2014]

Producto :Diseño que muestra la coherencia entre los productos, proce-

sos, organización, suministro de información y la infraestructura, basado

en una visión y ciertos puntos de partida, principios y preferencias.

Proceso : Indica la gente, recursos y define la forma de trabajo.


Arquitectura Empresarial en el contexto de TOGAF

El grupo abierto (The Open Group) [Group, 2016] es un consorcio a nivel

mundial que mediante IT posibilita el cumplir y alcanzar los objetivos de los

negocios. Este grupo ofrece un conjunto de servicios para mejorar la eficien-

cia,gestionar los requerimientos actuales y emergentes a demás de establecer

políticas y compartirlas mediante las mejores prácticas.

TOGAF (en inglés TheOpenGroupArchiteceture Framework) [Group, 2011]

es un consorcio formado por profesionales en tecnologías de información con

el objetivo de entregar estándares en el mundo de la arquitectura de tecnolo-

gías de información.

ISO/IEC 42010:2007 [Emery and Hilliard, 2009] define “arquitectura” como:

”La organización fundamental de un sistema, compuesta por sus componentes,

las relaciones entre ellos y su entorno, así como los principios que gobiernan

su dise˜no y evolución.”

TOGAF adopta y amplía esta definición. En TOGAF, “arquitectura” tiene dos

significados según el contexto:

1. Una descripción formal de un sistema, o un plano detallado del sistema

al nivel de sus componentes para orientar su implementación.

2. La estructura de componentes, sus interrelaciones, y los principios y guías

que gobiernan su dise˜no y evolución a través del tiempo.


2.1.5. Archimate

Este framework de arquitectura empresarial fue desarrollado por The Open

Group, su nombre TOGAF proviene de las siglas (The Open GroupArchitecture

Framework). Su primer desarrollo se dio en 1995 basado en TAFIM (”Technical

Architecture Framework for InformationManagement”) unmodelo de referencia

para arquitectura empresarial desarrollado por el Departamento de Defensa de

los Estados Unidos [Josey, 2013].

El lenguajeArchiMate, complementa a TOGAF brindando independencia de

vendedor, y se centra en los conceptos, incluyendo representaciones gráficas

que ayudan a crear consistencia e integración a través de las diferentes figuras

y vistas de TOGAF.

Archimate representa los conceptos de las capas mediante grafos, algunos

tomados del lenguaje unificado de modelado del inglés Unified Modeling Lan-

guage (UML) y los presenta en distintos colores. Los colores son para generar

conceptos similares en las capas y su trazabilidad.

Correspondencia entre Archimate y TOGAF Archimate está relacionado

con TOGAF, pero no es TOGAF aunque se mezclan muy bien ambos. En la

figura 2.7 es fácil de identificar la correspondencia entre el cicloADM (izquierda)

y TOGAF (derecha), debido al uso de colores:

La fase A, H junto con Requerimientos y Preliminar agrupadas de color

lila, representan lo motivación y nos responde el porqué vamos a hacer

la arquitectura.

Las fases B, C y D agrupadas cada una de tres colores que representan la

información (Verde), el comportamiento (Amarillo) y la estructura (Azul),

nos responde el qué vamos a hacer.

Las fases E, F y G agrupadas de color rojo representan la migración y

nos responde el cómo vamos a hacer la arquitectura.

El Ciclo ADM

El Método de Desarrollo de la Arquitectura en inglés Architecture Develop-

ment Method (ADM), permite iniciar la arquitectura desde una línea base o

estado actual (AS-IS) hacia una arquitectura objetivo o futura (TO-BE).

Fases del CicloADM El métodoADM consta de ocho fases identificadas por

las letras A, B, C, D, E, F, G y H, y dos secciones: Preliminar y Administración

de Requerimientos. Ver figura 2.7.

La fase A define la visión de la arquitectura, alcance y punto al que se

quiere llegar. En esta fase se presentan el diagrama del estado actual


Figura 2.7: Correspondencia entre TOGAF y el Ciclo ADM de Archimate inclu-

yendo las extensiones. Fuente: Capítulo 2 [Group, 2013]

(AS-IS) de la arquitectura del negocio, aplicación y/o infraestructura y el

estado al que quiero llegar o estado futuro (TO-BE).

Las fases B, C, D son los niveles de abstracción del negocio, aplicación o

infraestructura en más detalle. Cada fase puede estar representada por

puntos de vista, como se verá mas adelante. La fase E lista las opor-

tunidades y soluciones3 para lograr el objetivo o estado futuro (TO-BE)

propuesto en la arquitectura empresarial.

En la fase F se identifican y seleccionan los activos para llevar a cabo

la arquitectura de un estado AS-IS a un estado TO-BE. Como en las an-

teriores se identifica que se pacta, que se modifica y que se elimina, los

activos pueden ser los diagramas o entregables candidatos, clasificados

en paquetes de trabajo para ver como impactan la organización u otras

arquitecturas.

Las fases G y H son la gobernabilidad y gestión de control de cambios de

la arquitectura empresarial antes, durante y después de cada iteración

entre el estado AS-IS a TO-BE.

Archimate y su Integración con el ADM ArchiMate cuenta con 43 ele-

mentos gráficos, los cuales se distribuyen en 3 capas (Negocio, Aplicaciones e

Infraestructura Tecnológica) y 2 extensiones (Extensión de Motivación y Exten-

sión de Implementación y Migración). Además cuenta con 12 relaciones, todos

los elementos están en un 99% alineado al Framework TOGAF.A continuación

se verán como se agrupan las fases del ciclo ADM en capas y extensiones. Ver

figura 2.8


Figura 2.8: Integración del ADM con ArchiMate. Fuente: [Villalpando, 2014]

2.1.5.1. Capa de Negocio

Es una de las capas más importantes debido a que el lenguaje que se uti-

liza, permite hablar en términos de las entidades del negocio, por lo que es

importante distribuir adecuadamente la semántica. Esta capa gira en torno a

tres dimensiones de comportamiento: procesos, servicios y producto (centro

del negocio). La indagación que uno hace al modelar esta capa es convertirla

en software. Las capas agregan conceptos que soportan las etapas delADM de

TOGAF en las fases B, C y D que se encuentran relacionadas con el negocio,

aplicación o datos e infraestructura.


Conceptos Pasivos

Es la dimensión estructural con entidades del negocio que se etiquetan con

sustantivos, cuyo concepto más importante es el actor. Ver figura: 2.9

Figura 2.9: Conceptos Pasivos de la Capa de Negocio en Archimate. Fuente:

[Group, 2013]


Conceptos Activos

Es la dimensión que representan el comportamiento o acciones de las es-

tructuras del negocio y se etiquetan con verbos. El concepto más importante

es el paradigma de procesos. Ver figura: 2.10

Figura 2.10: Conceptos Activos de la Capa de Negocio en Archimate. Fuente

[Group, 2013]


Conceptos Informativos

Es la dimensión que representan la información que gira alrededor del pro-

ducto cuyo concepto más importante es el producto. Ver figura: 2.11

Figura 2.11: Conceptos Informativos de la Capa de Negocio en Archimate.

Fuente: [Group, 2013]

2.1.5.2. Capa de Aplicación

Es una de las capas más interesantes debido a que el lenguaje que se

utiliza nos permite hablar de componentes de software. Recordemos que la

arquitectura de software hereda y basa su modelo de las arquitecturas, utili-

zando el concepto de componente. Basta con saber que se le debe pasar al

componente para tener una estructura que garantice el ciclo de vida.

Esta capa maneja un lenguaje de descripción de arquitectura en inglés Ar-

chitecture Description Languaje - ADL, utiliza los siguientes elementos: com-


ponentes, interfaces, conectores y restricciones. Esta capa tiene dos dimen-

siones: la dimensíon estructural y la dimensíon de comportamiento. Sus con-

ceptos se representan de color azul celeste.

Dimensíon Estructural

A continuación los elementos estructurales de la capa de aplicación: Ver

Figura:

Figura 2.12: Elementos Estructurales de la Capa de Aplicación en Archimate.

Fuente: [Group, 2013]

Dimensión de comportamiento A continuación los elementos comporta-

mentales de la capa de aplicación: Ver Figura: 2.13


Figura 2.13: Elementos Comportamentales de la Capa de Aplicacíon en Archi-

mate. Fuente: [Group, 2013]

2.1.5.3. Capa de Infraestructura

Esta capa representa sus conceptos en color verde. Acá el concepto de

infraestructura de servicio es clave.

A continuación los elementos de la capa de infraestructura: Ver figuras: 2.14

y 2.15


Figura 2.14: Elementos de la Capa de Infraestructura en Archimate. Fuente:

[Group, 2013]


Figura 2.15: Continuación elementos de la Capa de Infraestructura en Archi-

mate. Fuente: [Group, 2013]


2.1.5.4. Capa Motivacional

En esta capa encontramos conceptos que amplían y ayudan a la nocíon

que tenemos de la organizacíon. Aclarar y definir estos conceptos nos ayudan

a entender la organizacíon de forma más sencilla.

Tiene un enfoque de objetivos. La parte más importante son las personas

directamente interesadas e involucradas con el resultado de la arquitectura. El

color es fucsia porque hace alusíon a la parte motivacional.

A continuacíon se presentan los elementos de la capa de motivacional que

generan conceptos hacia la organizacíon buscando que el sistema se comien-

ce a entender cómo la organizacíon misma. Ver figura 2.16


Figura 2.16: Elementos de la Capa de Motivación en Archimate. Fuente:

[Group, 2013]


2.1.5.5. Puntos de Vista

En la realidad una organización puede llegar a tener muchos objetivos, pro-

blemas a resolver e interesados que se pueden representar mediante los pun-

tos de vista. Los puntos de vista son diagramas que representa una parte de

la realidad que estoy modelando. Por lo tanto en Archimate tenemos las vistas

que permiten modelar la realidad, mediante lenguajes simbólicos, que contie-

nen una semántica y manejan unos conceptos.

A continuación se detallan cada uno de los puntos de vista que Archimate

[Group, 2013] permite modelar como herramienta para definir un concepto en

diferentes contextos.

Punto de Vista Preliminar

Es utilizado al inicio de un diseño cuando no todo tiene que ser detallado.

Este punto de vista permite explicar a los no arquitectos debido a su notación

sencilla, simple e intuitiva. Por ejemplo: Una nube representaría una red y las

relaciones se representan con líneas simples, a excepción de las relaciones de

”disparo y realización”.

2.1.5.6. Punto de Vista Organización

Representa modelos desde la perspectiva del interior de la organización.

Por ejemplo: organigrama. Ver figura ??.

Figura 2.17: Punto de Vista Organización. Fuente [Group, 2013]


2.1.5.7. Punto de Vista Cooperación del Actor

Representa la relación de los actores entre sí y con su entorno. Ejemplo: un

diagrama de contexto, conformado por: la organización, clientes, proveedores,

productos o servicios. Por ejemplo: organigrama. Ver figura 2.18.

Figura 2.18: Punto de Vista Cooperación del Actor. Fuente [Group, 2013]

2.1.5.8. Punto de Vista Función del Negocio

A continuación se presentan las principales funciones primarias u opera-

ciones generales del negocio de una organización y sus relaciones como los

flujos de información, valor y otras. Ver figura 2.19.

Figura 2.19: Punto de Vista Función del Negocio. Fuente [Group, 2013]


2.1.5.9. Punto de Vista Procesos de Negocio

En este punto de vista se representa la estructura de alto nivel y la composi-

ción de uno o más procesos de negocio. Por ejemplo: los servicios que ofrece

un proceso en el exterior, como un proceso contribuye en la realización de pro-

ductos, procesos asignados a roles, información utilizada por los procesos. Ver

figura 2.20.

Figura 2.20: Punto de Vista Procesos de Negocio. Fuente [Group, 2013]

2.1.5.10. Punto de Vista Cooperación Procesos de Negocio

Se utiliza para representar las relaciones entre procesos y su entorno. Ejem-

plo: relaciones entre procesos de negocio, procesos en las funciones de nego-

cio, procesos en la realización de servicios ver figura 2.21.


Figura 2.21: Punto de Vista Cooperación Procesos de Negocio. Fuente [Group,

2013]


2.1.5.11. Punto de Vista de Comportamiento de Aplicación

Figura 2.22: Punto de Vista de Comportamiento de Aplicación. Fuente [Group,

2013]


2.1.5.12. Punto de Vista de Cooperación de Aplicación

Aparece el concepto de localización. Se categorizan los componentes en

el front office. Estos componentes deben ser diseñados por profesionales que

tengan conocimientos en usabilidad, caso contrario del back office que es di-

señado por arquitectos de datos ver

figura 5.9.

Figura 2.23:

2.1.5.13. Punto de Vista de Estructura de Aplicación

Se centra fuertemente en el componentes y unión de las interfaces ver

figura 5.8.

Figura 2.24: Punto de Vista de Estructura de Aplicación. [Group, 2013]


2.1.5.14. Punto de Vista de Uso de Aplicación

Figura 2.25: Punto de Vista de Uso de Aplicación. Fuente [Group, 2013]

2.1.5.15. Punto de Vista de Infraestructura

Figura 2.26: Punto de Vista de Infraestructura. Fuente [Group, 2013]


2.1.5.16. Punto de Vista de Uso de Infraestructura

Figura 2.27: Punto de Vista de Uso de Infraestructura. Fuente [Group, 2013]

2.1.5.17. Punto de Vista de Organización e Implementación

Figura 2.28: Punto de Vista de Organización e Implementación. Fuente [Group,

2013]


2.1.5.18. Punto de Vista de Estructura de Información

Figura 2.29: Punto de Vista de Estructura de Información. Fuente [Group, 2013]

2.1.5.19. Punto de Vista de Realización del Servicio

Figura 2.30: Punto de Vista de Realización del Servicio. Fuente [Group, 2013]

2.1.5.20. Punto de Vista de Interesados

Luego de analizar el negocio y encontrar los puntos de vista del negocio,

los interesados se concretan y descomponen a groso modo ver figura 2.31


Figura 2.31: Punto de Vista de Interesados. Fuente [Group, 2013]

2.1.5.21. Punto de Vista de Realización de Objetivos

Figura 2.32: Punto de Realización de Objetivos. Fuente [Group, 2013]

2.1.5.22. Punto de Vista de Contribución

Figura 2.33: Punto de Vista de Contribución. Fuente [Group, 2013]


2.1.5.23. Punto de Vista de Principios

En este punto de vista solo esta el objetivo y los principios. Los principios

son de tipo sujeto, por ejemplo: confianza, oportunidad, etc. Ver

figura 2.34.

Figura 2.34: Punto de Vista de Principios. Fuente [Group, 2013]

2.1.5.24. Punto de Vista de Realización de Requerimientos

Figura 2.35: Punto de Vista de Realización de Requerimientos. Fuente [Group,

2013]


2.1.5.25. Punto de Vista de Motivación

Figura 2.36: Punto de Vista de Motivación. Fuente [Group, 2013]

2.1.5.26. Punto de Vista de Proyecto

Esta capa nos lleva al nivel de contextualizado dejando de lado la abstrac-

ción. Para llegar a este nivel es importante jugar con los roles del negocio. Ver

figura 2.37.

Figura 2.37: Punto de Vista de Proyecto. Fuente [Group, 2013]

2.1.5.27. Punto de Vista de Migración

Figura 2.38: Punto de Vista de Migración. Fuente [Group, 2013]


2.1.5.28. Punto de Vista de Migración e Implementación

La capa de migración e implementación en el meta modelo de extensivo

representa el comportamiento que puede tener el proceso que se implementa

mediante un entregale asociado a una brecha.

Figura 2.39.

Figura 2.39: Punto de Vista de Migración e Implementación. Fuente [Group,

2013]


2.2. Marco Conceptual

Proyecto de software: “Un proyecto software es un esfuerzo temporal

que se lleva a cabo para crear un producto software, servicio TI o resul-

tado único.” [Herrera, 2010]

Metodología de software: Entorno aplicado para organizar, planear y

controlar el proceso de desarrollo de software.

Artefacto: “Es un producto tangible resultante del proceso de desarrollo

de software.” [Wikipedia, 2017]

Historia de usuario Scrum: Descripción de un requirimiento para desa-

rrollar dentro de un Sprint, expresa el valor del negocio para los elementos

de la pila del producto.

Tablero de trabajo Scrum: Es una herramienta para visualizar el flujo

de trabajo, en la cual se ubican las historias de usuario según su estado

(pendiente, en curso y terminado).

Hecho Scrum: Concepto para determinar cuando en consenso un pro-

ducto esta listo.

Calidad de producto del software: “Grado en que dicho producto sa-

tisface los requisitos de sus usuarios, aportando de esta manera un va-

lor.” [McCall, 1978]

Requisitos de calidad externos: “Especifican el nivel de calidad reque-

rido desde la vista externa.” [ISO, 2000]

Requisitos de calidad internos: “Especifican el nivel de calidad reque-

rido desde la vista interna del producto. Los requisitos de calidad inter-

na se utilizan para especificar las propiedades de los productos interme-

dios.” [ISO, 2000]

Calidad en uso: “Es la visión del usuario de la calidad del producto de

software cuando se utiliza en un entorno específico y en un contexto es-

pecífico de uso.” [ISO, 2000]

Calidad en uso: “Es la visión del usuario de la calidad del producto de

software cuando se utiliza en un entorno específico y en un contexto es-

pecífico de uso.” [ISO, 2000]

Conceptos básicos arquitectura empresarial [Group, 2013]

Empresa: Organización que tienen metas y resultados comunes.

Arquitectura: Operación de una empresa, sistemas y tecnologías de in-

formación que la componen.

Formas de ver una Arquitectura: Existen tres formas: disciplina, pro-

ducto y proceso.


Disciplina: : Gobierna los cambios de la arquitectura.

Producto:: Diseño que muestra la coherencia entre los productos, pro-

cesos, organización, suministro de información e infraestructura, basado

en una visión y ciertos puntos de partida.

Proceso: Incluye el personal y los recursos para definir la forma de tra-

bajo.

Modelo: Abstracción del mundo real.

Metamodelo: Abstracción que sobresalta las características de un mo-

delo en sí mismo.


2.3. Marco Histórico

En la cultura del desarrollo de software los métodos tradicionales de desa-

rrollo basados en cascada han soportado la gestión de proyectos por varios

años y su implementación se ha dado en la mayoría de empresas del sector

de software, pero dado los problemas que han ido presentando los proyectos

desarrollados bajo esta metodologías, aparecen las metodologías livianas que

al parecer encajan mejor en los proyectos software.

A continuación se presentan la evolución de algunas metodologías o mo-

delos para el desarrollo de software:

Metodología en cascada

En 1970 Winston Royce introduce el enfoque metodológico denominado

modelo en cascada, el cual ordena rigurosamente las etapas para el proceso

de desarrollo, es concebida como una técnica rígida para mejorar la calidad y

reducir los costos del desarrollo de software.

El modelo permite realizar iteraciones, uno de los principales inconvenien-

tes se encuentra cuando durante las etapas de mantenimiento se hacen modi-

ficaciones al diseño, lo cual implica regresar a las etapas iniciales del proceso

y recorrer de nuevo todas las etapas lo que conlleva sobrecosto en el proceso

y retrasos en las entregas.

Aunque es un modelo ampliamente aceptado en la industria del software,

en la actualidad se ha comprobado que este enfoque no es idóneo para las

necesidad de los proyectos, en los cuales se requiere software cada vez más

especializados que satisfagan las necesidades de usuarios exigentes.

Marco de trabajo Scrum

Scrum fue mostrada por primera vez a mediados de los ochenta como nue-

va práctica de producción alcanzado por empresas de desarrollo tecnológico

como Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard,

y que fue estudiada por Hirotaka Takeuchi e Ikujijo Nonaka.

Con el artículo titulado “The New Product Development Game”, Ikujiro &

Takeuchi dieron continuación a otro artículo escrito con Kenichi Imai, llamado

“Managing the New Product Development Process: How Japanese Companies

Learn and Unlearn”. En estos expusieron una nueva práctica en el desarrollo

de productos tecnológicos desplegada en Japón, resaltando el solapamiento

de las fases de desarrollo como su principal característica, en contraste con

los métodos clásicos, los cuales emplean desarrollos “secuenciales”, pero que

en la práctica son en realidad “secuenciales con solapamiento”.

En 1991 Peter DeGrace y Leslie Stahl hacen referencia al proceso mencio-

nado por Takeuchi y Nonaka con el término “Scrum” en su libro Wicked Pro-


blems, Righteous Solutions (A problemas malvados, soluciones virtuosas), vo-

cablo que fue tomado del juego del rugby para describir procesos adaptativos,

autoorganizativos y sin elementos innecesarios, y que ya había sido utilizado

por estos últimos.

A partir del trabajo realizado por Hirotaka Takeuchi e Ikujijo Nonaka, Jeff

Sutherland aplicaría los principios de Scrum al desarrollo de Software en 1993

en Easel Corporation (actual Ascential Software Corporation), publicando en

1996 junto con Ken Schwaber, las prácticas que empleaba como válidas pa-

ra gestionar el desarrollo de software OOPSLA 96 (Schwaber & Sutherland,

1996).

Paralelo a este proceso, a mediados de la década del 90’, se dio la de-

finición de desarrollo ágil de software como una forma de contravenir hasta

ese momento las metodologías clásicas, las cuales se consideraban excesiva-

mente pesadas y rígidas por su carácter normativo y dependencia fuerte de las

planificaciones detalladas. Fue así como en 2001 miembros destacados de la

comunidad de software, creadores e impulsores de las nuevas metodologías

de desarrollo, de los cuales hacían parte Schwaber y Sutherland, bautizaron la

nueva corriente de metodologías de desarrollo como “Metodologías Ágiles”.

En el mismo año 2001 fue constituida la “Alianza ágil”, una organización

sin animo de lucro que promueve el desarrollo ágil de aplicaciones y del que

Scrum hace parte como modelo para gestionar el desarrollo de software.

Aunque la selección de un buena metodología para adaptar el proceso de

desarrollo es crucial en el éxito en la realización de un proyecto, no es el único

aspecto prioritario a tratar en el desarrollo del mismo. Un modelo de calidad

que permite tener directrices para gestionar y evaluar la calidad de productos

de desarrollo del software también favorece la capacidad de construcción de

un producto de alto nivel y rentable.

Así, se introducen algunas modelos que han surgido en las últimas déca-

das, para evaluar la calidad de los productos.

Modelos de calidad para el desarrollo del software

Modelo MCCALL: Desarrollado en 1977 por James “Jim” A. McCall para

la Fuerza Aérea de los Estados Unidos, implemento una metricas de calidad

que aun se mantiene vigentes, baso su enfoque en tres aspectos principales

de las calidad de un producto que son: revisión, transición y operaciones del

producto.

El objetivo principal era: “cerrar la brecha entre los usuarios y los desarro-

lladores” [McCall, 1978]

Modelo FURPS+:Propuesto en 1987 Robert Grady ejerció como empleado

en la compañía Hewlett Packard. El nombre del nombre representan las carac-

terísticas que se deben tener en cuenta para evaluar la calidad de software las

cuales son: funcionalidad, usabilidad, confiabilidad, rendimiento y facilidad de


mantenimiento.

ModeloDROMEY:Propuesto en 1995 por R. Geoff Dromey (Dromey, 1995).

Enfocado en el producto, concibe los criterios de evaluación de la calidad de

software de manera dinamica para que logre adaptarse a cada tipo de produc-

to.

El modelo plantea un conjunto de atributos y suba-tributos los cuales se de-

ben seleccionar teniendo en cuenta las características del producto para reali-

zar la respectiva evaluación de calidad del software.

ISO/IEC 9126: Publicado en 1992 como “Information technology. –Software

product evaluation: Quality characteristics and guidelines for their use”. Este

compendio de normas establece la características de calidad para software.

ISO/IEC 25000: ISO 2005 establece un modelo de calidad basado en mo-

delos de calidad propuestos en años previos, entre las cuales se encuentra la

ISO 9126 y ISO 14598.

2.4. Marco Legal

2.4.0.1. Obligación de confidencialidad

Las partes acuerdan que toda la información de propiedad de Coldinamic

S.A.S o de sus clientes, a la que tenga acceso el equipo de trabajo de desarrollo

del prototipo de software para la adaptación del marco de trabajo scrum, en

virtud del vínculo laboral, tiene el carácter de información confidencial. En tal

virtud, el equipo de trabajo se obliga a no revelar, divulgar, exhibir, comunicar,

utilizar y/o emplear dicha información en provecho suyo o de un tercero y a

protegerla para evitar su divulgación no autorizada.

En consecuencia, la información confidencial solo podrá ser utilizada por el

equipo de trabajo para desarrollar el objeto de proyecto anteriormente mencio-

nado.

El equipo de trabajo no está obligado a cumplir con la obligación de confi-

dencialidad cuando:

1. Exista previa autorización escrita de Coldinamic S.A.S

2. La revelación de la información se haga en desarrollo de orden de auto-

ridad competente en ejercicio de sus funciones legales

3. Cuando se trate de información conocida por el equipo de trabajo antes

de haber iniciado el proyecto


4. Cuando la información sea o se vuelva de dominio público

Capítulo 3

ASPECTOS

METODOLÓGICOS

75

CAPÍTULO 3. ASPECTOS METODOLÓGICOS 76

3.1. Tipo de estudio

Tomando como base los objetivos, la investigación planteada en este do-

cumento se clasifica de tipo propositivo, porque permitirá conocer comporta-

miento del proceso de gestión de proyectos en Coldinamic S.A.S y proponer

un marco de trabajo Scrum adaptado a su entorno a tráves del prototipo que se

va a desarrollar, pero no sólo se pretende adaptar el marco de trabajo Scrum

también reconciliar la visión de calidad en las metodologías ágiles en la orga-

nización, integrando a la adopción de normas y estándares de evaluación de

calidad de software basado en la ISO/IEC 25000.

3.2. Método de investigación

En un contexto de ingeniería y por consiguiente un problema planteado

en este mismo, es clave contar con una definición clara del problema puesto

que de lo contrario la propuesta dará solución a necesidades inexistentes, así

como también es clave el diseño que le permite al ingeniero pensar, proyectar

y maquetar un artefacto que beneficie a las personas.

Bajo la premisa que un ingeniero cuenta con un método de diseño de una

solución, se considera el método de análisis el más cercano al objetivo de este

proyecto, puesto que permite identificar los componentes que interactúan en

el problema y validar la relación causa - efecto en un entorno empresarial.

3.3. Fuentes y técnicas para la recolección de la

información

En la etapa inicial se utilizaran las entrevista y las reuniones con la gerencia

de Coldinamic S.A.S y el personal asignado para el proyecto.

Se establece también un trabajo de campo en las instalaciones de Coldi-

namic S.A.S con el fin de identificar los principales procesos relacionados con

los objetivos del proyecto que permita consolidar la fuentes primarias para la

ejecución del mismo.

Parte II

Desarrollo de la

Investigación

77

Capítulo 4

Análisis

4.1. Evaluación del proceso de desarrollo de soft-

ware actual de Coldinamic S.A.S

En esta sección se presenta la evaluación de la situación actual del proceso

de desarrollo de software en la companía Coldinamic como etapa preliminar

para generar un proceso mejorado.

Los factores analizados se utilizan para evaluar dos aspectos críticos para

la organización, dadas los problemas encontrados; calidad del producto y efec-

tividad del proceso de desarrollo. La valoración se aplico para todo el personal

de la organización y se tuvo en cuenta la siguiente escala de valoración Cuadro

No. 4.1.

Se pidió realizar la valoración de manera imparcialidad y objetiva, ya que

no se contó con la experiencia de los clientes de la organización para realizar

la evaluación, fue necesario basarse en la experiencia del talento humano de

Coldinamic.

78

CAPÍTULO 4. ANÁLISIS 79

Respuesta Valor

Nunca o casi nunca 1

Algunas veces 2

Bastantes veces 3

Siempre o casi siempre 4

Cuadro 4.1: Evaluación cuantitativa de la escala. Fuente: Elaboración propia

Se cuenta con el promedio de respuestas dadas en cada uno de las afirma-

ciones. Las siguientes afirmaciones evalúan aspectos relaciones con la gestión

de los proyectos. Cuadro No. 4.2.


Proceso Valoración Promedio

Realización de tareas según lo previsto 2

Cumplimiento de estimación del tiempo de ejecución del

proyecto

1

Ejecución presupuestal de acuerdo a lo planeado 2

Seguimiento y control a la ejecución de proyectos 2

Conocimiento de avance del proyecto 2

Ejecución del proyecto según cronograma 2

Retroalimentación del proceso de ejecución del proyecto 2

Requerimientos estables 2

Tiempo de capital humano empleado según planeación 2

Diseño del producto sin cambios en la evolución del pro-

yecto

2

Comunicación eficaz con el cliente a lo largo del desarrollo

del proyecto

2

Coincide el esfuerzo real del trabajo del personal con el

esfuerzo planeado

2

Gestión eficaz en el manejo de impedimentos para desa-

rrollo de actividades durante los proyectos

3

Cierre de los proyectos sin contratiempos 2

Cumplimiento de los objetivos de los proyectos 2

Cuadro 4.2: Resumen del resultado de evaluación de la eficacia de las prácticas

empleadas para la gestión de proyectos. Fuente: Elaboración propia

Interpretación de los resultados para la valoraciones obtenidas en las

prácticas de gestión de proyectos

Tiene un máximo de 60 puntos y un mínimo de 15 puntos. Se establecieron

los rangos de valoración de los resultados de la siguiente manera: Entre 15 y

30: Se evidencia graves problemas en la gestión y administración de los pro-


yectos que no permiten generar productos de valor para el cliente. Entre 31 y

45: Existen problemas que impiden una adecuada gestión de los proyectos y

requiere mejorar algunos procesos. Entre 46 y 60: procesos adecuados para

la gestión de proyectos.

En la valoración se obtuvo un puntaje de 29, indicando que los procesos

actuales para gestión de proyectos requieren mejoras a profundidad, para al-

canzar los objetivos de la compañía.

En los siguientes items se evalúan algunas características de las soluciones

entregadas a los cliente. Cuadro No. 4.3


Ausencia de deuda técnica 2

Mantiene el nivel de rendimiento por cierto tiempo 3

Reutilización de componentes 1

Cumplimiento funcional 2

Cumplimiento de los niveles de respuesta requeri-

dos

2

Mínimo de reportes de errores en el sistema 1

Control de la detección de errores y recuperación 2

Productos de fácil acceso 3

El sistema presenta resultados correctos 2

Cuadro 4.3: Resumen del resultado de evaluación de la calidad de los produc-

tos de software. Fuente: Elaboración propia

Interpretación de los resultados para la valoraciones obtenidas en las

caracteristicas de calidad de los productos de Coldinamic


los rangos de valoración de los resultados de la siguiente manera: Entre 9 y 18:

No cumple con los requisitos mínimos de calidad. Entre 19 y 28: algunos requi-

sitos de calidad no son satisfechos. Entre 29 y 36: cumplen con los requisitos

del cliente.

En la valoración se obtuvo un puntaje de 18, el incumplimiento con los re-

querimientos del cliente es siempre un problema grave para cualquier compa-

ñía y Coldinamic se ha visto fuertemente afectada por esta situación.

Para describir la situación actual de los proyectos realizados por Coldinamic

es necesario determinar según el talento humano de la compañía la percepción


de satisfacción de los clientes. Cuadro No. 4.4


Respuesta oportunas de las solicitudes de cambios 3

Cumplimiento de tiempos de entrega 2

Ausencia de quejas y/o reclamos del cliente 3

Agradecimientos y/o felicitaciones por parte del

cliente

1

Respuesta oportuna de soporte técnico 3

Aceptación del producto por parte del cliente 2

Pocos proyectos entregados sin llegar a utilizar su

producto resultante.

2

Ausencia de conflictos legales con clientes por in-

cumplimiento

2

Proyectos entregados con todas las funcionalidades

de las esperadas.

2

Cuadro 4.4: Resumen de resultado de la evaluación de satisfacción del cliente.

Fuente: Elaboración propia

Interpretación de los resultados para la valoraciones obtenidas para

la satisfacción del cliente


los rangos de valoración de los resultados de la siguiente manera: Entre 9 y 18:

clientes insatisfechos y que pueden llegar a no utilizar el producto generado.

Entre 19 y 28: condiciones aceptables de satisfacción pero no son garantía de

utilización del producto. Entre 29 y 36: clientes satisfechos que aprueban el

producto y lo utilizan.

En la valoración se obtuvo un puntaje de 20, el criterio ausencia de que-

jas y/o reclamos obtuvo una valoración aceptable, pero bajo otras condiciones

analizadas en la compañía, que los clientes no expresen sus quejas puede no

ser tan bueno, ya que algunos estudios plantean que un cliente insatisfecho en

la mayoría de ocasiones no se queja. Dada la ausencia de mecanismo para

medir la satisfacción de los clientes, esto podría estar ocurriendo lo cual per-

judica a la organización porque no contaría con una base de información para

establecer sus prioridades de mejora.


4.2. Comparación Scrum y el proceso de desarro-

llo actual de Coldinamic S.A.S

La información suministrada sobre la calidad del producto generada y el

proceso de desarrollo empleado permitió obtener conclusiones sobre los mis-

mos para lograr las decisiones necesarias para la adopción de un marco que

se adopten más a las necesidades de las características de los proyectos.

A continuación se presenta un cuadro comparativo de las características

de los proyectos de Coldinamic y las ventajas o desventajas que podría sus-

citar el marco de trabajo Scrum frente a la cultura tradicional empleada en la

organización. Cuadro No. 4.5

Propiedades de los proyectos Marco de trabajo ScrumMetodología empleada en Coldinamic

(Adaptación modelo en cascada)

Requerimientos cambiantes Adaptación y evolución en el cambio Resistencia a los cambios

Documentación Minima necesaria Extensa

Planificación Por cada Sprint Completa

Entrega de software con valor Cada Sprint Al final del proyecto

Retroalimentación del proceso Al final de cada Sprint Al final del proyecto

Comunicación con el cliente Continuas integración con el equipoMínima reuniones tradicionales de toma

de requerimientos y entrega final

Conocimiento de la evolución del proyecto

Alta gracias a los eventos que permiten

el manejo de desarrollo del proyecto de

manera transparente y visible para los

involucrados en el proyecto

Baja en etapas finales del proyecto

Evaluación del proceso y mejora continuaAl final de cada Sprint a través de eventos

como reunión de restropectivaAl final del proyecto

Proyectos pequeños y tiempos de desarrollo

cortosGrupo y proyectos pequeños, entregas rápidas Ideal para grupos y proyectos grandes

Cuadro 4.5: Desarrollo actual Coldinamic vs marco de trabajo Scrum

Los proyectos del Coldinamic se han visto afectados por un alto número de

factores, entre ellos el riesgo o dificultad presentada en los proyectos por la

lentitud en el proceso de desarrollo que repercute en retrasos en la entrega.

Estos riesgos generalmente son detectados al final del proyecto y pueden llevar

a la cancelación de los proyectos.

En este sentido es importante mostrar como la modelos ágiles proporcionan

una distribución uniforme a lo largo de realización, lo que permite identificarlos

en etapas tempranas. En la figura No. 4.1 se identifica esta distribución.


Figura 4.1: Distribución del riesgo en un desarrollo ágil. [Pilar, 2008]

Para los proyectos con metodologías tradicionales de implementación, los

riesgos se acumulan al final del proyecto que puede conducir al fracaso. (Ver

figura No. 4.2)

Figura 4.2: Distribución del riesgo en un modelo convencional. [Pilar, 2008]

4.3. Elaboración del nuevo proceso ajustado para

Coldinamic S.A.S

Una de los puntos críticos en el uso del modelo en cascada adaptado en la

organización Coldinamic para la gestión de sus proyectos, es el incremento en

el tiempo de entrega de los productos, que se produce en ocasiones por mal

entendimiento de las necesidades del cliente, lo que conlleva a reprocesos en

las etapas de desarrollo.

De esta manera se considero uno de los primeros requisitos en la mejora

del proceso de desarrollo, la distribución del proceso de ejecución del proyec-

to, en ciclos de corta duración lo cual favorece la identificación temprana de

problemas o riesgos y su posterior reporte, manejo y/o mitigación a lo largo del

desarrollo del producto. (Ver figura No. 4.3)


Figura 4.3: Desarrollo por ciclos de corta duración [Luis, 2017]

En el modelo propuesto se recomienda administrar estos tiempos de ejecu-

ción en periodos no mayores a 4 semanas(Duración máxima por Sprint), razón

por la cual el prototipo se estableció este periodo como la duración máxima

para el desarrollo de una funcionalidad que de valor al proyecto.

De los análisis realizados en la organización, se encontró que en la mayoría

de proyectos existen desfases de días en los tiempos propuestos para realizar

cada unas de actividades. Así resulta de vital importancia presentar alertas al

usuario cuando la planeación de un Sprint se desfasa por el incumplimiento de

la realización de alguna actividad.

En este aspecto la organización también requiere contar en el prototipo

con un módulo que permite conocer el estado del proyecto, a través del cual

se debe identificar:

1. Todos los Sprints asociados al proyecto

2. Estado de cada Sprint

3. Historias asociadas al Sprint con su respectivo estado.

4. Responsables por historia

5. Estimación en puntos de esfuerzo del desarrollo

Así, los involucrados pueden conocer el progreso del proyecto y el estado

actual de manera detallada, en el modelo se debe integrar esta información en

un componente visual. (Ver figura. 4.4)


Figura 4.4: Pila del producto y del Sprint. [Menzinsky, 2018]

En el desarrollo de cualquier proyecto de software en general se requiere

calidad, ágilidad y costos bajos, para poder competir en el mercado nacional e

internacional. Estos aspectos son factores claves que han constituido la pérdi-

da de clientes en Coldinamic.

En este sentido la mayoría de proyectos presenta retrasos por los retroce-

sos que ocurren cuando se realizan cambios a los requerimientos en etapas

finales de desarrollo.

Por lo cual es necesario trabajar en conjunto con el cliente y el equipo de

desarrollo comunicándose directa para evitar malentendidos, de esta forma la

organización debe buscar canales de comunicación directa a través de reunio-

nes cortas pero concretas que permitan revisar las entregas y retroalimentación

continua de la ejecución del proyecto.

Los eventos planteados en Scrum permiten un acercamiento más directo

del equipo de desarrollo y el cliente, de esta manera es necesario que se agen-

den reuniones en los tiempos establecidos en el marco de trabajo Scrum para

lograr mejorar la comunicación con el cliente.

En el modelo se plantea incorporar la medición de la satisfacción del clien-

te tomando información de encuestas evaluadas por los clientes, esto también

permite un acercamiento al cliente para entender sus necesidades, expectati-

vas y aciertos alcanzados en la realización del producto.

Resulta importante para el equipo contar en el módulo de gestión de histo-

rias de usuarios con funcionalidad que permite adjuntar documentación soporte

para realización de la historia, ya que esta información es considera básicas

para realización de sus actividades, además permite la consolidación de in-

formación de manera central. (Figura No. 4.5 ilustra el requerimiento de docu-

mentación en las historias de usuarios).


Figura 4.5: Ilustra requerimiento adjuntar documentación historia de usuario.

[SIA, 2014]

El prototipo cuanta con una herramienta llamada tablero del Sprint la cual

proporciona una visión global para cada Sprint con información detalla en la que

se incluye: información de los estados de las historias usuarios, estimación de

esfuerzo y responsable.

El tablero debe ajustarse a las prácticas establecidas en el marco de trabajo

Scrum, donde se identifican los siguientes estados: pendiente, en progreso

y completada. Los estados suspendido y cancelado deben ser incluidos, ya

que son estados que en la actualidad se presentan en la compañía y podrían

presentarse en el nuevo modelo. (Ver figura No. 4.6)

Figura 4.6: Tablón de Scrum. [Miguel, 2015]

Finalmente el modelo debe incorporar métricas para evaluar y controlar el

proceso de desarrollo de software, la calidad del software y la satisfacción del

cliente, de esta forma se puede:

Controlar y realizar seguimiento a la gestión del proyecto

Detectar y corregir los riesgos en etapas tempranas.

Conocer el avance del proyecto.


Identificar retrasos y estado de cada proyecto.

Indicar la calidad del producto.

Indicar la satisfacción del cliente.

Con esta información debe ser posible generar informes consolidados pa-

ra conocer los atributos del proyecto relacionados con tiempos planeados y

reales, entre otras características. (Ver figura 4.7)

Figura 4.7: Monitoreo de HU por Punto de Control. [Mitre, 2014]

Los aspectos anteriormente planteados son requeridos en la adaptación

del marco de trabajo Scrum, de igual forma la evaluación de métricas para la

calidad de productos de software, basada en la familia de normas ISO 25000,

estos puntos fueron identificados como medidas para lograr la mejora continua

del proceso de desarrollo, que permitan avanzar hacia la ejecución efectiva del

proceso.

En el modelo también se consideran otras prácticas Scrum, como los roles

definidos en el marco de trabajo, algunas actividades y artefactos, los cuales

se establecen de manera implícita en el prototipo. En la siguiente figura se pre-

senta de manera general las prácticas Scrum en las cuales se baso el modelo

y el diseño del prototipo. (Ver figura 4.8)


Figura 4.8: Prácticas de Scrum. Elaboración Propia

Capítulo 5

Arquitectura empresarial

AgileQA

En la fase se estudia la arquitectura empresarial, donde se identifica a Col-

dinamic S.A.S como una organización en su contexto de negocio en el que sus

procesos misionales se enfocan en el desarrollo de sistemas de información y

aplicaciones, por lo que en sus actividades se identifica al equipo de desarrollo

y a sus clientes como los actores principales en dichos procesos.

El presente análisis esta basado el proceso organizacional seleccionado en

fases anteriores el cual es desarrollo de soluciones.

90

CAPÍTULO 5. ARQUITECTURA EMPRESARIAL AGILEQA 91

5.1. Capa de Negocio

5.1.1. Punto de vista de organización

Figura 5.1: Punto de vista de organización Coldinamic

5.1.2. Punto de vista de cooperación de actor

Figura 5.2: Punto de vista cooperación actor


5.1.3. Punto de vista de función de negocio

Figura 5.3: Punto de función de negocio

5.1.4. Punto de vista de proceso de negocio

Figura 5.4: Punto de vista de negocio


5.1.5. Punto de vista de cooperación de proceso de negocio

Figura 5.5: Punto de vista proceso de negocio

5.1.6. Punto de vista de producto

Figura 5.6: Punto de vista de producto


5.2. Capa de Aplicación

El punto de vista de comportamiento, cooperación y estructura de aplicación

contiene las aplicaciones y componentes, y sus relaciones mutuas; el punto de

vista de uso de aplicación se refiere a aplicaciones para su uso, por ejemplo,

procesos de negocio. Además, el punto de vista de la aplicación trata acerca

de las aplicaciones de software que soportan los componentes del negocio con

servicios de aplicaciones, componentes de aplicación reusables, e interfaces

de comunicación para estos componentes.

5.2.1. Punto de Vista de Comportamiento de Aplicación

Figura 5.7: Diagrama Punto de Vista Comportamiento de Aplicación

5.2.2. Punto de Vista de Estructura de Aplicación

Figura 5.8: Punto de Vista de Estructura de Aplicación


5.2.3. Punto de Vista de Cooperación de Aplicación

Figura 5.9: Punto de Vista de Cooperación de Aplicación

5.2.4. Punto de Vista de Uso de aplicación

Figura 5.10: Punto de Vista de Uso de aplicación


5.3. Capa de Infraestructura

Muchos de los conceptos de esta capa han sido inspirados en UML 2.0, y

este es el dominio de este lenguaje en efecto describe las aplicaciones de soft-

ware y la infraestructura, esta capa busca dibujar la analogía entre el negocio

y la capa de aplicación.

5.3.1. Punto de vista Infraestructura

La figura 5.11 muestra el diagrama del punto de vista infraestructura don-

de se modela la estructura de AgileQA, la cual se encuentra instalada en un

servidor principal dotado con una base de datos, y los distintos clientes que

acceden a AgileQA.

Figura 5.11: Punto de vista Infraestructura

5.3.2. Punto de vista Uso de Infraestructura

La figura 5.12 muestra el diagrama del punto de vista de uso de aplicación

donde se modela uso de la infraestructura dispuesta para la aplicación, con los

respectivos componentes, como se puede observar la aplicación modelada es

web y cuenta con capacidad de atender usuarios simultáneamente.


Figura 5.12: Punto de vista Uso de Infraestructura

5.3.3. Punto de vista Estructura de Información

La figura 4.14 muestra el diagrama del punto de vista de las diferentes es-

tructuras de información administrada por AgileQA, se encuentran objetos de

datos tales como Proyecto, Sprint, Historia, Métricas y Equipo relaciones de

campos los cuales soportan las diversas funcionalidades de la herramienta.

Figura 5.13: Punto de vista Estructura de Información

Parte III

Cierre de Investigación

98

99

5.4. Prototipo AgileQA

Desde la creación de los proyectos de la compañía hasta la evaluación de

calidad y gestión de los proyectos es posible con AgileQA.

El sistema permite realizar diferentes actividades siguiendo los lineamientos

del marco de trabajo Scrum y directrices consignadas en la norma ISO/IEC

25000 para gestión de calidad de productos de software. 5.14

Figura 5.14: AgileQA. Fuente: Elaboración propia

AgileQA cuenta con los siguientes módulos:

Configuración y parametrización

Gestión de proyectos

Scrum

Métricas e indicadores

A través de los cuales se realizan tareas como: registro de proyectos con

información detallada, asignación de usuarios para cada proyecto con sus res-

pectivos roles, administración de pila del producto y Sprint, revisión y ejecución

de las mismas, entre otras actividades que serán detalladas a continuación.

Figura 5.15: Módulos del prototipo AgileQA. Fuente: Elaboración propia

Gestión de proyectos: Fuente de información para cada proyecto, permite

la creación, modificación, revisión y ejecución de cada proyecto. Figura 5.16

100

Figura 5.16: Administración de proyectos AgileQA. Fuente: Elaboración propia

Es posible conocer el detalle del proyecto, equipo que lo conforma, evaluar

la calidad y gestión del proyecto a través de la opción Revisión del Proyecto,

que proporciona AgileQA. Figura 5.17

Figura 5.17: Detalle del proyecto AgileQA. Fuente: Elaboración propia

Aunque los indicadores se agregan a un proyecto para ser evaluados, es

importante aclarar que estos se crean para el sistema y configuran de manera

específica para cada proyecto. Figura 5.18

Figura 5.18: Indicadores del proyecto. AgileQA. Fuente: Elaboración propia

101

Scrum: Integra los principales artefactos y actividades de la metodología

ágil. Mediante la opción ejecutar en cada uno de los proyectos es posible nave-

gar a través de las secciones de administración de: la pila del producto, Sprints

e historias de usuarios.

En la pila del producto se identifica los Sprints con su respectivo estado e

historias asociadas con información básica (puntos, estado, responsable, etc).

Figura 5.19

Figura 5.19: Pila del producto AgileQA. Fuente: Elaboración propia

El tablero del Sprint se utiliza para la planificación, seguimiento y control del

Sprint. En esta sección se administra de manera fácil y flexible cada una de las

historias que componen un Sprint y se puede establecer de manera rápida el

estado actual del Sprint identificando cada una de las historias en que estado

se encuentran (Pendiente, en progreso o completada). Figura 5.20

Figura 5.20: Tablero del Sprint AgileQA. Fuente: Elaboración propia

La administración del Sprint se realiza en la sección Sprint, la cual permite

el ingreso de información general. Figura 5.21

Entre los recursos empleados por la metodología ágil se encuentran las

historias de usuarios, las cuales en AgileQA son fáciles de administrar.

102

Figura 5.21: Detalle del Sprint. Fuente: Elaboración propia

Además de la gestión de información de las historias, enAgileQA se cuenta

con funcionalidades para administración de documentación de las historias de

usuarios y registro de observaciones o notas de las historia. Figuras 5.22, 5.23

y 5.24

Figura 5.22: Detalle de historia. AgileQA. Fuente: Elaboración propia

103

Figura 5.23: Historia de usuario - Notas- AgileQA. Fuente: Elaboración propiar

Figura 5.24: Historia de usuario - Documentación adjunta. AgileQA. Fuente:

Elaboración propiar.

Métricas e indicadores de calidad: Proporcionan un indicio de la ges-

tión del proceso de desarrollo, calidad del producto desarrollado y el nivel de

satisfacción del cliente. Su estructura se basa en la clasificación proporciona

por la norma ISO/IEC 9126, la cual establece una serie características, sub-

características y métricas para evaluar el software.

AgileQA proporciona además para cada una de las evaluaciones a tráves

de métricas e indicadores de calidad, reportes para interpretar más fácil la in-

formación. Figuras 5.25, 5.26

104

Figura 5.25: Métricas de calidad AgileQA. Fuente: Elaboración propia

Figura 5.26: Reporte. AgileQA. Fuente: Elaboración propia

5.5. Resultados de la prueba piloto

El proceso propuesto fue probado en la realización del prototipo AgileQA

para el soporte a la gestión de proyectos ágiles integrando la visión de calidad.

Este proyecto fue elegido debido a sus características como volatilidad de

sus requerimientos, corta duración y equipo pequeño de trabajo. El tiempo para

el desarrollo del proyecto permitió la adopción del proceso y varias iteraciones.

A continuación se presenta la información general del proyecto. Figura 5.27

105

Figura 5.27: Información básica del proyecto. Fuente: Elaboración propia

El equipo esta integrado por dos desarrolladores (autores del proyecto de

investigación), el dueño del producto (talento humano de Coldinamic) y el faci-

litador (talento humano Coldinamic). Figura 5.28

Figura 5.28: Equipo scrum. Fuente: Elaboración propia

Se realizaron varias iteraciones, de esta manera se logra entregar produc-

tos desde el final de la primera iteración facilitando el proceso de validación de

los requisitos. Ver figuras 5.29

106

Figura 5.29: Primera iteración. Fuente: Elaboración propia

Figura 5.30: Iteraciones finales. Fuente: Elaboración propia

En la prueba piloto se solicita valorar algunos indicadores de calidad para

el proyecto, teniendo en cuenta factores como: Tiempo de respuesta, reporte

de fallos y capacidad del producto para ser entendido y usado. En las siguien-

tes figuras 5.31, 5.32, 5.33 y 5.34 se obtiene los resultados de la evaluación

realizada por el talento humano de la compañía.

107

Figura 5.31: Indicadores evaluados en el proyecto. Fuente: Elaboración propia

Figura 5.32: Métrica fallos del sistema. Fuente: Elaboración propia

Los resultados son positivos para la prueba piloto, a pesar de no contar aún

con el hardware requerido para el funcionamiento del software, los tiempos

de respuesta son buenos. El nivel de incidencias reportadas es aceptable y

los usuarios que realizaron la evaluación consideran en un indice alto que la

solución es entendible.

108

Figura 5.33: Tiempos de respuesta. Fuente: Elaboración propia

Figura 5.34: Funciones evidentes. Fuente: Elaboración propia

El gráfico Tiempo de Entrega para el proyecto AgileQA se genera de infor-

mación de ejecución del proyecto, el tiempo real utilizado vs el tiempo asig-

nado no presentan un comportamiento distante, lo cual refleja aumento de la

productividad y mejora considerable en los tiempos de ejecución del proyecto.

Ver figura 5.35

109

Figura 5.35: Tiempo entrega. Fuente: Elaboración propia

5.6. Validación de la hipótesis

En este punto se encontró la validez de la hipótesis general de la investiga-

ción referida a: “Desarrollo de un prototipo de software para la adaptación del

marco de trabajo scrum en Coldinamic S.A.S”. Para poder validar la hipótesis

se presentaron tres indicadores en la evaluación de calidad, los cuales miden;

la satisfacción del cliente, los tiempos de desfases en la ejecución del proyecto

de la prueba piloto y la calidad interna del software a través del compendio de

datos que se obtienen en el desarrollo del proyecto. A través de estos indicado-

res se pudo identificar como la organización incrementa de manera sustancial

la productividad de sus procesos y la calidad.

5.7. Conclusiones

A partir de los resultados obtenidos a través de las métricas empleadas

para evaluar la calidad del software y controlar el proceso de desarrollo en la

prueba piloto, se considera que la metodología se adapta a las necesidades

de los diferentes tipos de proyectos que maneja la organización incrementando

las posibilidades de éxito.

La reconciliación de la visión de la calidad con la metodología ágil empleada

en la organización, permitió aumentar la productividad del equipo de desarrollo

110

y la calidad de los productos entregados al cliente.

La gestión de las métricas orientadas en el estándar internacional ISO/IEC

25000 permitió evaluar la calidad de los entregables intermedios y predecir la

calidad del producto final, para aplicar correcciones en las siguientes etapas

de desarrollo y plantear oportunidades de mejora.

Aunque no existe una herramienta o procedimiento unificado que permi-

ta evaluar la calidad de software, el enfoque empleado a través de la norma

ISO/IEC 25000 permite establecer la base para identificar característica ge-

nerales de los productos de software que pueden ser aplicadas con criterios

particulares para cada proyecto, por lo tanto se definió un modelo de evalua-

ción para medir la calidad configurable para cada tipo de proyecto.

Se logra un avance en el proceso de desarrollo con la implementación del

prototipo, pero es importante lograr encaminar la mentalidad de los equipos

involucrados hacia el enfoque ágil.

Es importante que los involucrados en el proceso de desarrollo reconozcan

la importancia de tener los requisitos necesarios a tiempo, sobre funcionalidad

adicional que provoque retrasos.

5.8. Trabajos de investigación futuros

El presente proyecto puede ser tomado como apertura a la implementación

en diferentes compañías para soporte de sus procesos de desarrollo, o incluso

a herramientas de soporte a la gestión de proyectos y de calidad con escenarios

diferentes al desarrollo de software.

Dentro del proceso de gestión de proyectos se obtiene a través del prototipo

AgileQA indicadores para evaluar su funcionamiento, con la aplicación de téc-

nicas de minería de datos se puede llegar a entregar información más exacta,

completa y oportuna.

Por otro lado, el proyecto puede ser extendido en su implementación para

adaptarse a otras plataformas móviles como Android.

Bibliografía

[Bellman and Griesi, 2015] Bellman, B. and Griesi, K. (2015). Enterprise ar-

chitecture advances in technical communication. 2015 IEEE International

Professional Communication Conference (IPCC), pages 1–5.

[Canive, 2017] Canive, T. (2017). Metología scrum.

[Cockburn, 1999] Cockburn, A. (1999). haracterizing People as Non-Linear,

First-Order Components in Software Development. Agile Software Develop-

ment Series. Pearson Education.

[Cockburn, 2006] Cockburn, A. (2006). Agile Software Development: The

Cooperative Game. Agile Software Development Series. Pearson Educa-

tion.

[Cockburn, 2007] Cockburn, A. (2007). Agile Software Development: The

Cooperative Game, 2nd Edition. Agile Software Development Series. Pear-

son Education.

[Cuéllar, ] Cuéllar, M. C.

[Emery and Hilliard, 2009] Emery, D. and Hilliard, R. (2009). Every architecture

description needs a framework: Expressing architecture frameworks using

iso/iec 42010. WICSA/ECSA 2009. Joint Working IEEE/IFIP Conference,

9:33–44.

[Fowler, 1999] Fowler, M. (1999). Addison-Wesley, Boston, MA, USA.

[Fowler, 2005] Fowler, M. (2005). The new methodology. martinfowler.com.

[Gayane, 2011] Gayane,A. (2011). Survey of agile tool usage and needs. IEEE

2011 Agile Conference, 1.

[Group, 2011] Group, T. O. (2011). Togaf 9.1.

[Group, 2013] Group, T. O. (2013). Archimate 2.1 specification motivation ex-

tension.

[Group, 2016] Group, T. O. (2016).

111

BIBLIOGRAFÍA 112

[Herrera, 2010] Herrera, M. (2010). Métodos y técnicas para la gestión de pro-

yectos de software.

[ISO, 2000] ISO (2000). ISO/IEC FDIS 9126-1. ANSI.

[Ivar, 1999] Ivar, J. (1999). The Unified Software Development Process.

[Josey, 2013] Josey, A. (2013). TOGAF version 9.1.

[Kent, 2001] Kent, B. (2001). Manifesto for agile software development.

[Lengerke, 2013] Lengerke, O. (2013). Arquitectura empresarial, el camino ha-

cia un gobierno integrado. Cio@Gov, 2.

[Lozano, 2013] Lozano, L. (2013). Estándares de calidad de software.

[Luis, 2017] Luis, V. G. (2017). Los sprints y su planeación.

[McCall, 1978] McCall (1978).

[Mellon, 2004] Mellon, C. (2004). Software quality requirements and evalua-

tion, the iso 25000 series. Software Quality Requirements and Evaluation,

the ISO 25000 Series, 1:15.

[Mendes Calo, 2010] Mendes Calo, K. (2010). Wicc 2010 - xii workshop de

investigadores en ciencias de la computación. Evaluación de Metodologías

Ágiles para Desarrollo de Software, 1.

[Menzinsky, 2018] Menzinsky, A. (2018). Scrum y kanban.

[Miguel, 2015] Miguel (2015). Segumiento del progreso del sprint en scrum.

[Mitre, 2014] Mitre, H. (2014). Estimación y control en métodos ágiles.

[Pilar, 2008] Pilar, R. G. (2008). Estudio de la aplicación de metodologías ági-

les para la evolución de productos de software.

[Ridderstrale, 2000] Ridderstrale, J. (2000). Funky business. Talent makes ca-

pital dance. Prentice Hall.

[Rubin, 2011] Rubin, K. S. (2011). Essential Scrum: A Practical Guide to

the Most Popular Agile Process. Addison-Wesley Signature Series (Cohn).

Addison-Wesley.

[schwaber and jeff sutherland, 2011] schwaber, K. and jeff sutherland (2011).

The definitive guide to scrum: the rules if the game. University of St Andrews.

[SIA, 2014] SIA (2014). Sistema de información y atención al cliente.

[Studies, 2018] Studies, S. C. (2018). Scrum case studies.

[The Standish Group International, 2009] The Standish Group International, I.

(2009). Chaos summary 2009. CHAOS Summary 2009. The 10 Laws of

CHAOS, 1:1–2.

[Villalpando, 2014] Villalpando, A. (2014). Arquitectura empresarial, architect,

archimate y togaf.

BIBLIOGRAFÍA 113

[W., 1976] W., B. B. (1976). Software engineering. IEEE TRANSACTIONS ON

COMPUTERS, C-25,.

[Wikipedia, 2017] Wikipedia (2017). Artefacto.

[Zachman, 1987] Zachman, J. A. (1987). A framework for information systems

architecture. IBM Systems Journal, 26(3):276–292.

[Zhamungui, 2013] Zhamungui, C. (2013). Metodologías ágiles.

desarrollodeunprototipode softwareparalaadaptacióndel...

Documents