Prototipo De Herramienta Web Para La Realización y Control De Retrospectivas Ágiles Sobre Requerimientos De Software

Texto completo

(1)FACULTAD DE INEGNIERIA. TESIS PROYECTO DE GRADO ESPECIALIZACION EN INGENIERIA DE SOFTWARE. PROTOTIPO DE HERRAMIENTA WEB PARA LA REALIZACIÓN Y CONTROL DE RETROSPECTIVAS ÁGILES SOBRE REQUISITOS DE SOFTWARE. Autor: Jorge Bula Gómez Diretor: Sandro Bolaños Revisor: Joaquin Javier Meza. Bogotá - Colombia Mayo 2018.

(2) Índice general 0.1. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . .. 1. I CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN 2 1. DESCRIPCION DE LA INVESTIGACIÓN 1.1. Planteamiento/Identificacion del problema . . . . . . . 1.1.1. Formulación del problema . . . . . . . . . . . . 1.1.2. Sistematización del problema . . . . . . . . . . 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Objetivo general . . . . . . . . . . . . . . . . . 1.2.2. Objetivos especı́ficos . . . . . . . . . . . . . . . 1.3. Justificación del trabajo/investigación . . . . . . . . . . 1.4. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . 1.5.1. Marco Teórico . . . . . . . . . . . . . . . . . . . 1.5.2. Marco Conceptual . . . . . . . . . . . . . . . . 1.6. Metodologı́a de la investigación . . . . . . . . . . . . . 1.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . 1.6.2. Método de investigación . . . . . . . . . . . . . 1.6.3. Fuentes y técnicas de recolección de información 1.7. Alcance,limitaciones y resultados esperados . . . . . . . 1.7.1. Alcance . . . . . . . . . . . . . . . . . . . . . . 1.7.2. Limitaciones . . . . . . . . . . . . . . . . . . . . 1.7.3. Resultados esperados . . . . . . . . . . . . . . . 1.8. Estudio de sistemas previos . . . . . . . . . . . . . . . 1.9. Cronograma y Presupuesto . . . . . . . . . . . . . . . 1.9.1. Cronograma . . . . . . . . . . . . . . . . . . . . 1.9.2. Presupuesto . . . . . . . . . . . . . . . . . . . .. i. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. 3 3 4 4 5 5 5 6 6 7 7 14 17 17 18 18 19 19 19 19 21 22 22 23.

(3) ÍNDICE GENERAL. II. ii. DESARROLLO DE LA INVESTIGACIÓN. 2. EMPRESA 2.1. Introdución . . . . . . 2.2. Misión y visión . . . . 2.2.1. Misión . . . . . 2.2.2. Visión . . . . . 2.3. Organigrama . . . . . 2.4. Objetivos Estratégicos 2.5. Productos y Servicios .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 3. RECOLECCIÓN Y TABULACIÓN 3.1. Introdución . . . . . . . . . . . . . 3.2. Recolección de Datos . . . . . . . . 3.3. Tabulación de Datos . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 24 . . . . . . .. . . . . . . .. . . . . . . .. 25 25 25 25 25 26 26 27. DE DATOS 28 . . . . . . . . . . . . . . . 28 . . . . . . . . . . . . . . . 28 . . . . . . . . . . . . . . . 30. 4. ARQUITECTURA EMPRESARIAL 4.1. Introdución . . . . . . . . . . . . . . 4.2. ADM - Archimate . . . . . . . . . . . 4.2.1. Capa de Negocio: . . . . . . . 4.2.2. Capa de Aplicación: . . . . . 4.2.3. Capa de Tecnologı́a: . . . . . 4.2.4. Capa de Motivación: . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 5. NEGOCIO 5.1. Introdución . . . . . . . . . . . . . . . . . . . . 5.2. Punto de Vista de Organización . . . . . . . . . 5.2.1. Modelo . . . . . . . . . . . . . . . . . . . 5.2.2. Caso de Estudio . . . . . . . . . . . . . . 5.3. Punto de Vista de Cooperación de Actor . . . . 5.3.1. Modelo . . . . . . . . . . . . . . . . . . . 5.3.2. Caso de Estudio . . . . . . . . . . . . . . 5.4. Punto de Vista de Función de Negocio . . . . . 5.4.1. Modelo . . . . . . . . . . . . . . . . . . . 5.4.2. Caso de Estudio . . . . . . . . . . . . . . 5.5. Punto de Vista de Proceso de Negocio . . . . . 5.5.1. Modelo . . . . . . . . . . . . . . . . . . . 5.5.2. Caso de Estudio . . . . . . . . . . . . . . 5.6. Punto de Vista Cooperacion Proceso de Negocio 5.6.1. Modelo . . . . . . . . . . . . . . . . . . . 5.6.2. Caso de Estudio . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . .. 34 34 35 35 40 43 45. . . . . . . . . . . . . . . . .. 47 47 48 48 49 50 50 51 52 52 53 54 54 55 56 56 57.

(4) ÍNDICE GENERAL. iii. 5.7. Punto de Vista deProducto . . . . . . . . . . . . . . . . . . . 58 5.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.7.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 59 6. APLICACIÓN 6.1. Introdución . . . . . . . . . . . . . . . . . . . . . 6.2. Punto de Vista de Cooperacion de Aplicación . . 6.2.1. Modelo . . . . . . . . . . . . . . . . . . . . 6.2.2. Caso de Estudio . . . . . . . . . . . . . . . 6.3. Punto de Vista de Comportamiento de Aplicación 6.3.1. Modelo . . . . . . . . . . . . . . . . . . . . 6.3.2. Caso de Estudio . . . . . . . . . . . . . . . 6.4. Punto de Vista de Estructura de Aplicación . . . 6.4.1. Caso de Estudio . . . . . . . . . . . . . . . 6.5. Punto de Vista de Uso de Aplicación . . . . . . . 6.5.1. Modelo . . . . . . . . . . . . . . . . . . . . 6.5.2. Caso de Estudio . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 60 60 61 61 62 63 63 64 65 66 67 67 68. 7. MOTIVACIÓN 7.1. Introdución . . . . . . . . . . . . . . . . . . 7.2. Punto de Vista stakeholder . . . . . . . . . . 7.2.1. Modelo . . . . . . . . . . . . . . . . . 7.2.2. Caso de Estudio . . . . . . . . . . . . 7.3. Punto de Vista de Realización de Objetivos 7.3.1. Modelo . . . . . . . . . . . . . . . . . 7.3.2. Caso de Estudio . . . . . . . . . . . . 7.4. Punto de Vista de Motivación . . . . . . . . 7.4.1. Modelo . . . . . . . . . . . . . . . . . 7.4.2. Caso de Estudio . . . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 72 72 73 73 74 75 75 76 77 77 78. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 8. METODOLOGÍA SCRUM 79 8.1. Introdución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 8.2. Historias de Usuarios . . . . . . . . . . . . . . . . . . . . . . . 80 9. DISEÑO DE SOFTWARE 9.1. Introdución . . . . . . . . . . . . . . . . . . . . . . . 9.2. Herramientas metodológicas utilizadas . . . . . . . . 9.3. Casos de Uso RetroWeb . . . . . . . . . . . . . . . . 9.3.1. Caso de uso Registrar Requisitos de Software 9.3.2. Caso de uso Registrar Equipos de Desarollo . 9.3.3. Caso de uso Registrar Sprints de Desarollo . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 85 85 85 86 86 87 87.

(5) ÍNDICE GENERAL. iv. 9.3.4. Caso de uso Consultar Sprints de Desarollo . . 9.3.5. Caso de uso Registrar Tareas de Sprint . . . . 9.3.6. Caso de uso Asociar Impedimentos a Tareas . 9.3.7. Caso de uso Generar Retrospectivas de Sprint 9.4. Modelo de Datos . . . . . . . . . . . . . . . . . . . . 9.5. Arquitectura de la Aplicación . . . . . . . . . . . . . 9.5.1. Diseño de Aplicación . . . . . . . . . . . . . . 9.5.2. Diseño capa de presentación . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 88 88 89 89 90 93 94 95. 10.IMPLEMENTACIÓN 98 10.1. Prototipo funcional . . . . . . . . . . . . . . . . . . . . . . . . 98. III. CIERRE DE LA INVESTIGACIÓN. 104. 11.RESULTADOS Y DISCUSIÓN 12.CONCLUSIONES 12.1. Verificación,contraste y evaluación de los objetivos 12.2. Sı́ntesis del modelo propuesto . . . . . . . . . . . 12.3. Aportes originales . . . . . . . . . . . . . . . . . . 12.4. Trabajos o Publicaciones derivadas . . . . . . . .. 105. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 107 . 107 . 108 . 109 . 109.

(6) Índice de figuras 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.. Reporte de la Chaos 1 . . . . . . . . . Reporte de la Chaos 2 . . . . . . . . . Reporte de la Chaos 3 . . . . . . . . . Reporte de la Chaos sobre proyectos en Cronograma de trabajo . . . . . . . . . Presupuesto de Proyecto . . . . . . . .. . . . . . . . . . 2015 . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . 8 . 9 . 9 . 10 . 22 . 23. 2.1. Estructura Oranizacional SHA . . . . . . . . . . . . . . . . . 26 2.2. Productos y servicios SHA . . . . . . . . . . . . . . . . . . . 27 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8.. Cumplimiento de requerimientos . . . . . . . . . . . . . . . . Impedimentos en Sprints de Desarrollos de Software . . . . . Tiempos de gestión tareas de desarrollo . . . . . . . . . . . . Frec.Absoluta del cumplimiento de requerimientos . . . . . . Frec.Relativa del cumplimiento de requerimientos . . . . . . Frec.Absoluta impedimentos en desarrollos de software . . . Frec.Relativa impedimentos en desarrollos de software . . . . Frec.Absoluta tareas con mayor gestión durante fase de construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9. Frec.Relativa tareas con mayor gestión durante fase de construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. 4.1. 4.2. 4.3. 4.4. 4.5.. ADM . . . . Metamodelo Metamodelo Metamodelo Metamodelo. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 35 36 40 43 45. 5.1. 5.2. 5.3. 5.4.. Metamodelo de oranización . . . . . . . . . . . Punto de vista organización . . . . . . . . . . . Metamodelo cooperación de Actor . . . . . . . Punto de vista cooperacion de Actor RetroWeb. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 48 49 50 51. . . . . . . . . . . . capa de negocios . capa de aplicación capa de tecnologı́a capa de motivación. v. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 29 29 30 30 31 31 32. . 32 . 33.

(7) ÍNDICE DE FIGURAS. vi. 5.5. Metamodelo función de Negocio . . . . . . . . . . 5.6. Punto de vista funcion de Negocio RetroWeb . . . 5.7. Metamodelo proceso de Negocio . . . . . . . . . 5.8. Punto de vista proceso de Negocio RetroWeb . . . 5.9. Metamodelo cooperación de proceso de Negocio . 5.10. Punto de vista cooperación de proceso de Negocio 5.11. Metamodelo cooperación de proceso de Negocio . 5.12. Punto de vista producto RetroWeb . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RetroWeb . . . . . . . . . . . .. . . . . . . . .. 52 53 54 55 56 57 58 59. 6.1. Metamodelo Cooperación de Aplicación . . . . . . . . . . . . 6.2. Punto de Vista Cooperación de Aplicación . . . . . . . . . . . 6.3. Metamodelo Comportamiento de Aplicación . . . . . . . . . . 6.4. Punto de vista Comportamiento de Aplicación . . . . . . . . 6.5. Metamodelo Comportamiento de Aplicación . . . . . . . . . . 6.6. Punto de vista Estructura de Aplicación . . . . . . . . . . . . 6.7. Metamodelo Uso de Aplicación . . . . . . . . . . . . . . . . . 6.8. Proceso de registrar requerimiento . . . . . . . . . . . . . . . 6.9. Proceso de crear y asociar equipos a requerimiento . . . . . . 6.10. Proceso creación de Sprint de desarrollo . . . . . . . . . . . . 6.11. Proceso creación de tareas de desarrollo en Sprint . . . . . . . 6.12. Proceso asociar impedimentos a tareas de desarrollo en Sprint 6.13. Proceso de generar retrospectiva virtual para impedimentos asociados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61 62 63 64 65 66 67 68 69 69 70 70. 7.1. 7.2. 7.3. 7.4. 7.5. 7.6.. Metamodelo de los stakeholders . . . . . . . . . . . . Punto de vista stakeholders de RetroWeb . . . . . . . Metamodelo de realización de objetivos . . . . . . . Punto de vista realización de objetivos de RetroWeb Metamodelo motivacional . . . . . . . . . . . . . . . Punto de vista motivacional RetroWeb . . . . . . . .. 9.1. Registrar requisitos de software . . . . . . . . . 9.2. Registrar equipos de desarrollo . . . . . . . . . . 9.3. Registrar Sprints de desarrollo . . . . . . . . . . 9.4. Consultar Sprints de Desarollo . . . . . . . . . . 9.5. Registrar tareas de sprint . . . . . . . . . . . . . 9.6. Asociar Impedimentos a Tareas . . . . . . . . . 9.7. Generar Retrospectivas de Sprint . . . . . . . . 9.8. Modelo de datos RetroWeb . . . . . . . . . . . . 9.9. Modelo de Datos Gestion de usuarios RetroWeb 9.10. Modelo de Datos lógica de negocio RetroWeb .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 71. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 73 74 75 76 77 78. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 86 87 87 88 88 89 89 90 91 92.

(8) ÍNDICE DE FIGURAS 9.11. Arquitectura de la aplicación . . . . . . . . . 9.12. Maquetado home en RetroWeb . . . . . . . 9.13. Maquetado gestión de tareas en RetroWeb . 9.14. Maquetado gestión de usuarios en RetroWeb. vii . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 94 95 96 97. 10.1. Página principal del prototipo RetroWeb . . . . . . . . 10.2. Módulo de registro de requerimientos . . . . . . . . . . . 10.3. Módulo de registro de equipos de desarrollo . . . . . . . 10.4. Módulo de registro Sprints de desarrollo . . . . . . . . . 10.5. Módulo de registro tareas de desarrollo . . . . . . . . . . 10.6. Consultar tarea de desarrollo para asociar impedimentos 10.7. Asociar impedimentos a tareas de desarrollo . . . . . . . 10.8. Generación de retrospectiva . . . . . . . . . . . . . . . . 10.9. Generación de retrospectiva . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 98 99 100 100 101 102 102 103 103. 12.1. Modelo de Datos lógica de negocio RetroWeb . . . . . . . . . 113 12.2. Arquitectura de aplicación RetroWeb . . . . . . . . . . . . . . 114 12.3. EDT Proyecto de Investigación . . . . . . . . . . . . . . . . . 115.

(9) Índice de cuadros 4.1. 4.2. 4.3. 4.4.. Elementos Elementos Elementos Elementos. de de de de. capa de negocio . . Capa de Aplicacion Capa de Tecnologı́a Capa de Motivación. 8.1. 8.2. 8.3. 8.4.. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Historia de Usuario HUO1 - Crud de requerimientos de software Historia de Usuario HUO2 - Crud equipos de desarrollo . . . . Historia de Usuario HUO3 - Crud de sprints de desarrollo . . . Historia de Usuario HUO4 - Registrar y gestionar tareas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5. Historia de Usuario HUO5 - Registar y controlar impedimentos de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6. Historia de Usuario HUO6 - Generar de retrospectivas . . . . 8.7. Historia de Usuario HUO7 - Consultar retrospectivas por Sprint 8.8. Historia de Usuario HUO8 - Login de usuarios . . . . . . . . . 8.9. Historia de Usuario HUO9 - Gestión de permisos y roles de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.10. Historia de Usuario HHU10 - Registrar categorias de impedimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. viii. 39 42 44 46 80 80 81 81 82 82 83 83 84 84.

(10) ÍNDICE DE CUADROS. 0.1.. 1. INTRODUCCIÓN. Este trabajo de investigación propone una forma estratégica de llevar a cabo la realización de retrospectivas ágiles en los equipos de desarrollo de software que trabajan bajo metodologı́as agiles, debido a que actualmente se ha observado que durante la resolución de requerimientos y proyectos de software no se está brindando la importancia requerida a una fase de retrospección, reflexión e identificación de dificultades de manera anticipada conocida como retrospectiva, de tal forma que se logren tomar decisiones y acciones correctivas que permitan reducir los ı́ndices de incumplimiento en las entregas de las soluciones de software para dichos requerimientos o proyectos, ası́ mismo que permitan mejorar la fiabilidad en los desarrollos e implementación de tales soluciones, todo esto en pro de lograr en primer lugar la mejora continua en los equipos de desarrollo y en segundo obtener una mayor satisfacción de los clientes. Cabe mencionar que bajo el modelo de metodologı́as ágiles para desarrollo de software las retrospectivas constituyen una fase fundamental ya que son consideradas como el corazón de la mejora continua y las prácticas emergentes, los equipos reflexionan y hacen retrospección sobre los acontecimientos sucedidos en cada iteración o sprint definido de forma sistemática para lograr cumplir con la entrega de un producto con incrementos funcionales satisfactorios para un cliente. En el presente documento se pretende describir la efectividad y resultados positivos que se pueden obtener con la posibilidad de poder facilitarle a los lı́deres de proyectos y equipos de desarrollo una herramienta tecnológica que les permita obtener modelos o estructuras de retrospectivas a partir del tipo de necesidades, dificultades o debilidades identificadas en equipos de desarrollo de software durante la implementación de soluciones, adicionalmente que esta propuesta puede permitir obtener beneficios tales como una mejor administración de los tiempos de entrega comprometidos y a su vez poder resolver anticipadamente obstáculos que pueden llegar a entorpecer la entrega de software funcional con valor y en su defecto el buen rumbo de un proyecto o determinados requerimientos..

(11) Parte I CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN. 2.

(12) Capı́tulo 1 DESCRIPCION DE LA INVESTIGACIÓN 1.1.. Planteamiento/Identificacion del problema. Es importante resaltar inicialmente que las retrospectivas no son algo exclusivo del mundo del software, o de los proyectos ágiles, las podemos aplicar para la vida personal,profesional, a proyectos de servicios, de sistemas, entre otras. En el contexto del desarrollo de software simplificadamente, son una reunión al final de un proyecto, iteración, sprint o reléase, cuyos objetivos primordiales podemos decir que son aprender para mejorar y la mejora continua, es decir hacer una revisión para aprender de la experiencia y de cómo nos ha ido durante la marcha, mediante el análisis y valoración de estrategias que permitan generar cambios, esto es acciones de mejoramiento para obtener incrementos efectivos en pro de los resultados deseados. La problemática evidenciada en la organización ATH radica en que además de que existe un desconocimiento en la gestión de retrospectivas ágiles, se evidencia la manera poco eficiente en cómo las retrospectivas se vienen generando y realizando desde que se adoptó metodologı́a agile scrum para la gestión y ejecución del ciclo de vida de desarrollo de software, aportando poco valor para mejorar el cumplimiento en la entrega de las soluciones de software en los tiempos definidos y a su vez la calidad de dichas soluciones, ya que aun ası́ con esa nueva metodologı́a se siguen presentando porcentajes altos de incidencias(bugs) evidenciadas durante la fase de pruebas de certificación (testing) y peor aún porcentaje alto del indicador de reversos en ambientes productivos por afectación y fallas de funcionalidades existentes y nuevas. Se observa que las retrospectivas han sido enfocadas como una simple reunión 3.

(13) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 4. más, sin dinamismo y enfoque, se ha identificado que no se están usando para propiciar acciones de mejora, para lograr descubrir las falencias, eventos y actividades que afectan el cumplimiento a los clientes con entregas de software funcional, al igual que la elaboración de software fiable, siendo estos criterios elementos fundamentales en el contexto de desarrollo de software con metodologı́as agiles, se evidencia que no se llevan a cabo tareas esenciales como recabar datos, decidir qué hacer y definir los cambios y correctivos que permitan mitigar los riesgos de entrega de software sin calidad e inoportuno o aún peor no realizar entregas continuas de software con valor a los clientes.. 1.1.1.. Formulación del problema. ¿Cuál es la estrategia cognitiva que permite hacer efectiva la retrospectiva ágil en la organización SHA, cuyo dominio es el desarrollo de soluciones tecnológicas y software de alta calidad?. 1.1.2.. Sistematización del problema. 1. ¿Cuáles son los eventos y actividades proclives del incumplimiento en la elaboración de software fiable? 2. ¿Cómo valorar para categorizar y/o ponderar las entidades de freno al proceso de desarrollo de software? 3. ¿Cuáles indicadores en rojo deben ser atendidos para evitar el enlentecimiento del proceso de desarrollo de software? 4. ¿Cuál es el porcentaje de mejora en el desarrollo de los requisitos y proyectos de software posterior a la ejecución de retrospectivas agiles?.

(14) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.2. 1.2.1.. 5. Objetivos Objetivo general. Fortalecer la fase de implementación de software en la organización SHA mediante la aplicabilidad de un prototipo web que permita realizar y controlar de forma efectiva retrospectivas ágiles para mejorar el cumplimiento y fiabilidad en los requerimientos de software.. 1.2.2.. Objetivos especı́ficos. Realizar encuestas a los equipos de desarrollo mediante el uso de herramientas web para determinar los eventos e impedimentos que influyen en la implementación de software fiable e incumplimiento en las entregas de requerimientos. Definir las categorı́as a las cuales serán asociadas los eventos e impedimentos que influyen en el incumplimiento de la entrega de software fiable, para fijarlos modelos de retrospectivas virtuales que contiene las posibles acciones correctivas. Validar las asociaciones entre los modelos de retrospectivas virtuales y las categorı́as de referencia definidas previamente, para verificar el impacto en el mejoramiento del incumplimiento en las entregas de requerimientos e implementación de software fiable. Implementar producto tecnológico que permita controlar y generar modelos de retrospectivas ágiles para verificar el mejoramiento en la fase de implementación de software fiable y cumplimento en las entregas de requerimientos a los clientes..

(15) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.3.. 6. Justificación del trabajo/investigación. Esta investigación se realiza debido a que existe la necesidad de mejorar el nivel de cumplimiento de los requisitos y proyectos de software solicitados a la organización SHA, ası́ mismo poder mejorar la fiabilidad en la elaboración de software que se lleva a cabo en las plataformas virtuales de internet que se manejan en dicha organización, esto en base a que no existe el conocimiento para trazar la cadena de producción de una retrospectiva ágil efectiva, por tal motivo es de manifestar que la propuesta de este estudio tiene enmarcado colaborar con reducir este desconocimiento para llevar a cabo la fase de retrospección de manera efectiva, de tal forma que se logre evolucionar positivamente con entregas de software fiable a los clientes sobre los tiempos pactados, y en su defecto lograr disminuir las cifras de incidentes que se presentan en las plataformas virtuales de internet sobre los entornos productivos de acceso público. Es preciso resaltar que se pretende generar un impacto positivo en los equipos de desarrollo ya que en primera instancia se busca mejorar el desconocimiento que se presenta hoy en dı́a para la ejecución de retrospectivas ágiles, teniendo en cuenta la metodologı́a ágil scrum que ha adoptado la organización SHA en su actualidad para la gestión, planeación y control de su proceso de desarrollo de software, en segunda instancia identificar y controlar a tiempo las fallas, obstáculos o dificultades que vengan presentando los equipos de desarrollo en la ejecución de los denominados sprints generados a partir de los backlog definidos para cada requisito o proyecto en curso, de tal manera que se puedan solucionar y lograr cumplir con efectividad las entregas de software acordadas con los clientes.. 1.4.. Hipótesis. La realización adecuada y el control estratégico de las retrospectivas ágiles mediante la implementación de una herramienta tecnológica web permitirá promover la mejora continua en los equipos de desarrollo de software del área de portales transaccionales de la organización SHA, para mejorar el cumplimiento en las entregas de requerimientos y a su vez la fiabilidad en las soluciones de software implementadas..

(16) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.5. 1.5.1.. 7. Marco referencial Marco Teórico. De la secuencialidad a la iteración El desarrollo de software no es una disciplina sencilla. En las últimas décadas los lenguajes estructurados modernos, de modelado (UML) y posteriormente varias herramientas intentaron sin éxito posicionarse como las ”balas de plata”4 para resolver algunos de sus problemas. Incluso se habı́a llegado a contar con herramientas poderosas y procesos de modelado y diseño sin tener muy en claro cómo aplicarlos a la hora de construir el software. No fue sino hasta la adopción amplia y consciente de un tercer elemento injustamente relegado a un papel secundario, las metodologı́as de desarrollo, que se encontraron soluciones adecuadas a muchos problemas. La mayorı́a de estas metodologı́as fueron introducidas desde la ingenierı́a civil, lo que resultó en un exhaustivo control sobre los procesos y las tareas. El Modelo Secuencial de Procesos, también conocido como Waterfall Model o Modelo en Cascada, se convirtió en el modelo metodológico más utilizado dentro de la industria. Data de principios de los años setenta y tiene sus orı́genes en los ámbitos de la manufactura y la construcción, ambientes fı́sicos altamente rı́gidos donde los cambios se vuelven prohibitivos desde el punto de vista de los costos, sino prácticamente imposibles. Como no existı́a proceso alguno en la industria del software, esta condición no impidió su adopción. La primera mención pública (reconocida) de este tipo de metodologı́as fue realizada en un artı́culo que data de 1970 donde el Dr. Winston W. Royce presenta -sin mencionar la palabra ”Waterfall un modelo secuencial para el desarrollo de software que comprendı́a las siguientes fases: Especificación de requerimientos Diseño Implementación (también conocida como construcción o codificación) Integración Verificación o prueba y debugging Instalación Mantenimiento El proceso Waterfall sugiere una evolución secuencial. Por ejemplo: primero se realiza la fase de especificación de requerimientos. Una vez que se encuentra completa se procede a un ”sign-off”(firma/aprobación) que congela.

(17) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 8. dichos requerimientos, y es recién aquı́ cuando se inicia la fase de diseño del software, fase donde se produce un plano o ”blueprint”del mismo para que los codificadores/programadores lo implementen. Hacia el final de la fase de implementación, diferentes componentes desarrollados son integrados con el fin de pulir las interfaces entre ellos. El siguiente paso es la fase de verificación en la que los testers someten el sistema a diferentes tipos de pruebas funcionales mientras los programadores corrigen el código donde sea necesario. Una vez que el sistema responde satisfactoriamente a la totalidad de las pruebas, se inicia una etapa de instalación y mantenimiento posterior. Los problemas detectados en los modelos tradicionales o de tipo Waterfall se fundamentan, por un lado, en el entorno altamente cambiante propio de la industria, y por el otro, en el proceso mismo de desarrollo de software donde el resultado depende de la actividad cognitiva de las personas más que de las prácticas y controles empleados. A medida que han pasado los años, y con el advenimiento de las economı́as globalizadas y los entornos web, el contexto de negocio de los sistemas ha pasado de ser relativamente estable a convertirse en un contexto altamente volátil, donde los requerimientos expresados hoy, en muy pocas oportunidades son válidos unos meses más tarde. Bajo esta nueva realidad, las metodologı́as Waterfall resultaron muy “pesadas” y prohibitivas para responder satisfactoriamente a los cambios de negocio. En el año 1994 el Standish Group publicó un estudio conocido como el ÇHAOS Report”6 donde se encontró la siguiente tasa de éxito en los proyectos de desarrollo de software en general: 31.1 52.7 16.2 Los datos publicados, entre otros, mostraron estos ı́ndices:. Figura 1.1: Reporte de la Chaos 1 Las conclusiones de la investigación sugieren que el involucramiento del usuario y el empleo de periodos de tiempo más cortos son claves para incrementar las tasas de proyectos exitosos Bajo este contexto surgieron nuevas metodologı́as, como, por ejemplo:.

(18) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 9. Figura 1.2: Reporte de la Chaos 2. Figura 1.3: Reporte de la Chaos 3 Metodologı́as en Espiral Metodologı́as Iterativas Metodologı́as Ágiles Tanto las Metodologı́as en Espiral como las Metodologı́as Iterativas se encuentran fuera del alcance de este trabajo, por lo que pasaremos directamente a entender las Metodologı́a Ágiles..

(19) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 10. Figura 1.4: Reporte de la Chaos sobre proyectos en 2015 El origen de las Metodologı́as Ágiles En los 90s surgieron varios movimientos identificados con el nombre de Metodologı́as Livianas (LightweightMethodólogies). Entre estos se encuentran Extreme Programming (XP), Scrum, Software Craftmanship, Lean Software Development, etc. Más tarde, en febrero de 2001, se reunieron en Utah (EEUU) un grupo de diecisiete profesionales reconocidos del desarrollo de software, y referentes de las metodologı́as livianas existentes al momento, con el objetivo de determinar los valores y principios que les permitirı́an a los equipos desarrollar software de forma más acertada con las necesidades del cliente y responder mejor a los cambios que pudieran surgir a lo largo de un proyecto de desarrollo. Se pretendı́a ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por la rigidez y dominados por la documentación. En esta reunión se creó la Agile Alliance7, una organización sin fines de lucro cuyo objetivo es el de promover los valores y principios de la filosofı́a ágil y ayudar a las organizaciones en su adopción. También se declaró la piedra angular del movimiento ágil, conocida como Manifiesto Ágil. (Alaimo,2013, p.12). Las retrospectivas Ágiles Para Alaimo (2013) en un método empı́rico como Scrum, la retrospección del equipo es el corazón de la mejora continua y las prácticas emergentes. Mediante el mecanismo de retrospección, el equipo reflexiona sobre la forma en la que realizó su trabajo y los acontecimientos que sucedieron en el Sprint que acaba de Proyectos Ágiles con Scrum concluir para mejorar sus prácticas. Todo esto sucede durante la reunión de retrospectiva. Valiéndose de técnicas de facilitación y análisis de causas raı́ces, se buscan tanto fortalezas como oportunidades de mejora. Luego, el Equipo Scrum decide por.

(20) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 11. consenso cuáles serán las acciones de mejora a llevar a cabo en el siguiente Sprint. Estas acciones y sus impactos se revisarán en la próxima reunión de retrospectiva Con base a lo anterior me permito referenciar el siguiente cuestionamiento sobre el cual está guiado este estudio de investigación, una vez que tenemos claro que una retrospectiva nos ayudará en la mejora continua, ¿cómo la llevamos a cabo? El objetivo es analizar cómo fue la última iteración, cómo trabajamos, qué problemas tuvimos, qué cosas funcionaron bien y cuáles no. Y con todo esto ver hacia dónde queremos ir, sacar acciones concretas que cada uno pueda realizar durante la siguiente iteración para solucionar los problemas encontrados, mejorar la forma de trabajo y conseguir el objetivo propuesto. Para ello, podemos simplificar la reunión planteando estas preguntas en el siguiente orden: ¿Cómo fue el sprint pasado? ¿Qué problemas tuvimos? ¿Qué hicimos bien? ¿Qué queremos mejorar? ¿Qué vamos a hacer para conseguirlo? Alguien del equipo liderará la retrospectiva formulando estas preguntas. El resto del equipo irá contestando y debatiendo cada uno de los puntos. El objetivo final es conseguir acciones que cada uno pueda realizar durante el siguiente sprint para mejorar. ¿Qué problemas podemos encontrar con este formato? 1. No todo el mundo habla. Siempre hay personas en el equipo con más capacidad de comunicación o con más personalidad capaces de acaparar una reunión mientras que otros apenas hablan, el no ser propositivo puede generar que no se menciones dificultades o situaciones que pueden llegar a incidir en el logro de los objetivos, como lograr elaborar soluciones con calidad o poder realizar entregas de software funcional en los tiempos pactados con clientes. 2. Reuniones repetitivas. Se repiten los mismos resultados retrospectiva tras retrospectiva, es decir persiste una continuidad de las dificultades y del problema, la calidad de las retrospectivas no es apropiada y efectiva 3. Sentimiento de pérdida de tiempo. Algunos miembros del equipo pueden sentir que están perdiendo el tiempo porque no se tratan o no.

(21) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 12. se profundiza en los temas que creen que son importantes, es decir se maneja poco interés por el deseo y logro de alcanzar objetivos y satisfacción de clientes, esto es ambientes pobres. 4. Evitar temas conflictivos. Puede que haya temas más delicados que no lleguen a tratarse por miedo o por no saber cómo plantearlos o abordarlos. 5. Reuniones incómodas. Pueden darse momentos de más tensión durante el desarrollo de nuestro proyecto y esto se puede trasladar a la reunión de retrospectiva haciendo que ésta sea un tanto incómoda o que salgamos de ella desmotivados, esto puede traducirse como la falta de un liderazgo apropiado, el cual se presenta por no orientar las retrospectivas de forma estratégica y con la motivación e importancia necesaria. Estrategias para ayudar a su equipo a avanzar con Retrospectivas Ágiles Esther Derby y Diana Larsen (2010) señalan en su libro Agile Retrospectives Makinggood teams great señalan estrategias que se pueden plantear para desatascar a los equipos de desarrollo cuando presentan mal funcionamiento afectando la evolución de los proyectos requerimientos de software: Se requiere disponer un miembro que pueda ejercer liderazgo en las etapas de retrospectivas, que puede ayudar a restaurar sus jugos creativos haciendo preguntas como como estos: 1. ¿Qué hemos probado antes? ¿Qué pasó? ¿Qué te gustarı́a para que suceda de manera diferente? 2. Si tuviéramos eso, ¿qué ganarı́amos? 3. ¿Alguna vez has intentado esto de una manera diferente? ¿Qué pasó? Usted puede pedir más opiniones, especialmente de personas que han sido pensando más que hablando. Puede sugerir investigaciones adicionales antes de comprometerse con una solución. Usted puede quitar el sombrero de lı́der retrospectivo y ofrecer contenido conocimiento de la experiencia personal. Podrı́as decirle al equipo qué hacer, pero solo si quieres engañar a aprendizaje. Psicologı́a profunda de las retrospectivas Agiles Varios años de experiencia en retrospectivas en diferentes culturas han dado como resultado algunas técnicas interesantes para mejorar el rendimiento de tu equipo y entender más sobre el funcionamiento humano. En esta entrada te lo mostraré desde el punto de vista de un Scrum Master, pero podrı́a ser aplicada y brindada al grupo por cualquier integrante. (Bühler, 2013, Psicologı́a profunda de las retrospectivas Agile)..

(22) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 13. La retrospectiva Robot Especialmente para los recién entrados en la dinámica Agile (aunque también lo he visto en grupos que llevan ya cierto tiempo), las retrospectivas se convierten en reuniones muy automáticas (“robóticas”) y siempre al final del ciclo; esto es: 1. Se plantea lo que se hizo mal 2. Se indica lo que se podrı́a mejorar 3. Se comenta lo que se hizo bien 4. Se ponen ciertas medidas o ajustes y finalmente se da por acabada la reunión. El mayor problema es que esta modalidad en el largo plazo puede ocasionar más inconvenientes que soluciones. El primer punto a entender es porqué se llevan adelante las reuniones en Agile/Scrum y cuál es el fin de realizar ciertas preguntas. El hecho de que las preguntas estén allı́ no es primordialmente para para conocer información acerca del resultado de los procesos, sino que principalmente para modelar un comportamiento, esto es, poner a los individuos dentro de cierto patrón de pensamiento y acción. “Las preguntas en las reuniones Agile se efectúan para modelar un comportamiento” Por supuesto que de forma secundaria está el obtener información y hacer algo con ella, como ser remover obstáculos, cambiar un proceso, etc. La retrospectiva es algo entonces que no debe ser tomada a la ligera ya que es el único punto donde el grupo puede radicalmente cambiar su dirección mediante la toma de decisiones, adoptar medidas y aprender para el mediano y largo plazo. Podrı́as pensar que la reunión Standup diaria tiene un fin similar, no obstante, ésta última ataca obstáculos relacionados principalmente con las historias de usuarios y no del grupo en sı́. La mayor carencia con la modalidad de reunión “robot” es que existen infinidad de problemas que no pueden ser sacados a la luz a no ser que se empleen técnicas que apunten estos inconvenientes de forma directa pero despersonalizada. Acuérdate que el trabajo del último ciclo es siempre: 1. Reciente 2. Involucra a todos en forma grupal y principalmente personal 3. Las personas se sienten orgullosas de lo que desarrollaron Es ası́ que varios problemas pueden esconderse bajo formas de trabajo no adecuadas que muten ciclo a ciclo con el fin de poder “ocultarse” de la vista.

(23) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 14. de un simple mortal. Estructura de las retrospectivas Para Gabardini (2013) las retrospectivas se pueden estructurar con las siguientes partes: 1. Preparar el escenario: lograr que las personas se focalicen en los objetivos de la reunión, en el tiempo estipulado y con una dinámica productiva. 2. Recabar datos: lograr una visión común de la situación a analizar, tanto con datos objetivos como subjetivos. Es la base común de hechos, eventos y sentimientos que permitirá tener una comunicación efectiva durante el resto de la reunión. 3. Generar entendimiento profundo: entender el por qué, tanto lo que anduvo mal como lo que anduvo bien. Ir más allá de la primera apariencia, para encontrar las causas profundas que hay que sostener y mejorar o cambiar. 4. Decidir qué hacer: teniendo una lista de posibles experimentos que el equipo puede realizar para mejorar, es el momento de elegir, ya que no todo se puede hacer para el siguiente sprint. 5. Cierre: finalizar claramente la retrospectiva, con una nota positiva y ganas de realizar los experimentos que se encontraron.. 1.5.2.. Marco Conceptual. ¿Qué es Scrum? Scrum es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación. No es un proceso completo, y mucho menos, una metodologı́a. En lugar de proporcionar una descripción completa y detallada de cómo deben realizarse las tareas de un proyecto, genera un contexto relacional e iterativo, de inspección y adaptación constante para que los involucrados vayan creando su propio proceso. Esto ocurre debido a que no existen ni mejores ni buenas prácticas en un contexto complejo. Es el equipo de involucrados quien encontrará la mejor manera de resolver sus problemáticas. Este tipo de soluciones serán emergentes. El equipo de desarrollo se encuentra apoyado en dos roles: el ScrumMaster y el Product Owner. El ScrumMaster es quien vela por la utilización de Scrum, la remoción de impedimentos y asiste al equipo a que logre su mayor nivel de performance posible. Puede ser considerado un coach.

(24) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 15. o facilitador encargado de acompañar al equipo de desarrollo. El Product Owner es quien representa al negocio, stakeholders, cliente y usuarios finales. Tiene la responsabilidad de conducir al equipo de desarrollo hacia el producto adecuado. Proyectos Ágiles con Scrum 22 El progreso de los proyectos que utilizan Scrum se realiza y verifica en una serie de iteraciones llamadas Sprints. Estos Sprints tienen una duración fija, pre-establecida de no más de un mes. Al comienzo de cada Sprint el equipo de desarrollo realiza un compromiso de entrega de una serie de funcionalidades o caracterı́sticas del producto en cuestión. Al finalizar el Sprint se espera que estas caracterı́sticas comprometidas estén terminadas, lo que implica su análisis, diseño, desarrollo, prueba e integración al producto. En este momento es cuando se realiza una reunión de revisión del producto construido durante el Sprint, donde el equipo de desarrollo muestra lo construido al Product Owner y a cualquier stakeholder interesado en participar. El feedback obtenido en esta reunión puede ser incluido entre las funcionalidades a construir en futuros Sprints. Sprint Backlog: El Sprint Backlog es el conjunto de PBIs que fueron seleccionados para trabajar en ello durante un cierto Sprint, conjuntamente con las tareas que el equipo de desarrollo ha identificado que debe realizar para poder crear un incremento funcional potencialmente entregable al finalizar el Sprint. “El resultado de cada Sprint debe ser un incremento funcional potencialmente entregable.” Sprint (Iteración): Las iteraciones en Scrum se conocen como Sprints. Scrum, como todos los enfoques ágiles, es un proceso de desarrollo incremental e iterativo. Esto significa que el producto se construye en incrementos funcionales entregados en periodos cortos para obtener feedback frecuente. En general, Scrum recomienda una duración de Sprint de entre 1 y 4 semanas, siendo 2 o 3 semanas lo más habitual que encontraremos en la industria. Una de las decisiones que debemos tomar al comenzar un proyecto o al adoptar Scrum es justamente la duración de los Sprints. Luego, el objetivo será mantener esta duración constante a lo largo del desarrollo del producto, lo que implicará que la duración de una iteración no cambie una vez que sea establecida. Sprint Planning(Planificación de Sprint): Al comienzo de cada Sprint se realiza una reunión de planificación del Sprint donde serán generados los acuerdos y compromisos entre el equipo de desarrollo y el Product Owner sobre el alcance del Sprint. Esta reunión de planificación habitualmente se divide en dos partes con finalidades diferentes: una primera parte estratégica y enfocada en el “qué”, y una segunda parte táctica cuyo hilo conductor principal es el “cómo”. Parte uno ¿Qué trabajo será realizado? Podrı́amos decir que se trata de.

(25) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 16. un taller donde el Product Owner expone todos y cada uno de los PBIs que podrı́an formar parte del Sprint, mientras que el equipo de desarrollo realiza todas las preguntas que crea necesarias para conocer sus detalles y ası́ corroborar o ajustar sus estimaciones. Parte dos ¿Cómo será realizado el trabajo? Durante este espacio de tiempo el equipo de desarrollo determinará la forma en la que llevará adelante el trabajo. Esto implica la definición inicial de un diseño de alto nivel, el cual será refinado durante el Sprint mismo y la identificación de las actividades que el equipo en su conjunto tendrá que llevar a cabo. Scrum Diario: Uno de los beneficios de Scrum está dado por el incremento de la comunicación dentro del equipo de proyecto. Esto facilita la coordinación de acciones entre los miembros del equipo de desarrollo y el conocimiento “en vivo” de las dependencias de las actividades que realizan. Por otro lado, se requiere además aumentar y explicitar los compromisos asumidos entre los miembros del equipo de Proyectos Ágiles con Scrum 48 desarrollo y dar visibilidad a los impedimentos que surjan del trabajo que está siendo realizando y que muchas veces nos impiden lograr los objetivos. Estos tres objetivos: 1) incrementar la comunicación 2) explicitar los compromisos y 3) dar visibilidad a los impedimentos, son logrados mediante las reuniones diarias de Scrum (Daily Scrums). Estas reuniones tienen, como su nombre lo indica, una frecuencia diaria y no deberı́an llevar más de 15 minutos. Estos 15 minutos son un timebox, es decir, que no se pueden superar. Revisión de Sprint: Al finalizar cada Sprint se realiza una reunión de revisión del Sprint (Sprint Review), donde se evalúa el incremento funcional potencialmente entregable construido por el equipo de desarrollo (el “qué”). En esta reunión el Equipo Scrum y los Stakeholders revisan el resultado del Sprint. Cuando decimos “resultado” hablamos de “producto utilizable” y “potencialmente entregable” que el los interesados utilizan y evalúan durante esta misma reunión, aceptando o rechazando ası́ las funcionalidades construidas. Retrospectiva: En un método empı́rico como Scrum, la retrospección del equipo es el corazón de la mejora continua y las prácticas emergentes. Mediante el mecanismo de retrospección, el equipo reflexiona sobre la forma en la que realizó su trabajo y los acontecimientos que sucedieron en el Sprint que acaba de Proyectos Ágiles con Scrum concluir para mejorar sus prácticas. Todo esto sucede durante la reunión de retrospectiva. Valiéndose de técnicas de facilitación y análisis de causas raı́ces, se buscan tanto fortalezas como oportunidades de mejora. Luego, el Equipo Scrum decide por consenso cuáles serán las acciones de mejora a llevar a cabo en el siguiente Sprint. Estas acciones y sus impactos se.

(26) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 17. revisarán en la próxima reunión de retrospectiva. Las Retrospectivas Ágiles En el contexto del Desarrollo Ágil de Software, las retrospectivas se aplican en distintos momentos y con distinta frecuencia (final del sprint, final del release,final del proyecto), incluyendo incluso a distintos grupos de involucrados (sólo el equipo de desarrollo, el equipo completo). Adicionalmente, cada equipo es distinto y tiene necesidades de aprendizajes, tiempo disponible y energı́as diferentes en distintos momentos. Por ello, antes de la reunión de retrospectiva se debe: Definir el objetivo de la retrospectiva Identificar a las personas que deben estar Identificar y recolectar datos necesarios Comunicar todo lo anterior a todos los participantes También debe definirse la estructura de la retrospectiva, la duración y qué herramientas se usarán.. 1.6. 1.6.1.. Metodologı́a de la investigación Tipo de estudio. El tipo de estudio para ésta investigación es de tipo proyectivo, debido a que se busca especificar las caracterı́sticas y debilidades que presentan los equipos de desarrollo bajo metodologı́a agile durante la fase de implementación de software de requerimientos o proyectos solicitados por clientes, especı́ficamente en la ejecución de retrospectivas, es decir someter a un análisis las caracterı́sticas, variables y propiedades obtenidas de unos grupos de personas seleccionados mediante la recolección de información, para este caso los equipos de desarrollo del área de plataformas virtuales transaccionales. Ası́ mismo se propone implementar un producto tecnológico, especificamente una aplicación web que permite ofrecer modelos de retrospectivas ágiles virtuales las cuales tienen como objetivo apoyar y suministrar las acciones correctivas para resolver los eventos e impedimentos que se presentan en los equipos de desarrollo durante la fase de implementación y que influyen en el cumplimiento adecuado de las entregas de requerimientos y en paralelo a la implementación de soluciones de software más fiable..

(27) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.6.2.. 18. Método de investigación. El método de investigación seleccionado para este estudio de investigación es de tipo inductivo, mediante el cual se llevarán a cabo los siguientes pasos primordiales: Observación y registro de los hechos y situaciones a identificar que están directamente relacionadas con nuestro problema de investigación. Análisis y clasificación de los hechos. Derivación inductiva hacia conclusiones generales a partir de los hechos. Se realizará diseño experimental con el área de portales transaccionales que pertenece a la dirección de canales virtuales , cuyo equipo de desarrollo está compuesto por 20 miembros, todos con perfil de desarrolladores de software. Serán seleccionados para la prueba de nuestro diseño experimentan 3 requerimientos de software: 2 de complejidad alta y 1 de complejidad media.. 1.6.3.. Fuentes y técnicas de recolección de información. Las técnicas de recolección de la información que se usaran para la descripción de caracterı́sticas y variables relacionadas con nuestro problema de investigación son: Observación directa sobre la ejecución de las fases de desarrollo por parte de los equipos de desarrollo de plataformas virtuales, lı́deres de proyecto y directores de desarrollo. Fuentes Primarias: Encuestas a los integrantes de los equipos de desarrollo de portales transaccionales, lı́deres de proyectos y directores de desarrollo, como fuentes primarias de recolección de datos. Análisis y tabulación de datos recopilados, de tal forma que se logre obtener frecuencias distribuidas como frecuencias absolutas y relativas de las categorias de datos determinadas y medidas de tendencia central como moda y media..

(28) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.7. 1.7.1.. 19. Alcance,limitaciones y resultados esperados Alcance. El alcance de este proyecto de investigación está descrito ası́: 1. Con este proyecto de investigación se busca mediante la implementación de un prototipo de herramienta web apoyar y mejorar de forma efectiva la realización y control de retrospectivas ágiles dentro de los equipos desarrollo de software de plataformas virtuales de la organización SHA durante la fase de implementación de software de los requerimientos solicitados por los clientes y en este sentido lograr fortalecer el ciclo de vida de desarrollo de software que se maneja hoy en dı́a. 2. Es importante resaltar que dentro del alcance se encuentra como aspecto fundamental la medición y verificación de los indicadores de cumplimiento y fiabilidad en las soluciones de software apoyadas con el uso de este prototipo de aplicación web. 3. La verificación del impacto y resultados obtenidos con el uso del prototipo web (RetroWeb) será sobre la fase de testing o pruebas de las soluciones de software implementadas, entregadas al área encargada conocida como “pruebas de certificación” o popularmente como QA.. 1.7.2.. Limitaciones. Dentro de los lı́mites de este proyecto se tienen: 1. Se someterá solamente la implementación del prototipo de herramienta web para los equipos de desarrollo de software de las plataformas virtuales transaccionales que existen hoy en dı́a en la organización SHA. 2. Se verificarán los indicadores de cumplimiento y calidad de las soluciones de software durante la fase de pruebas de certificación o testing y de esta forma medir el impacto de prototipo web en el mejoramiento de dichos indicadores y a su vez valorar el fortalecimiento del ciclo de vida de desarrollo de software soportado hoy en dı́a bajo metodologı́a agile Scrum.. 1.7.3.. Resultados esperados. Tras el desarrollo del proyecto de investigación, se espera:.

(29) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 20. 1. Conocer las principales y dificultades que presentan los equipos de desarrollo que afectan el cumplimiento a los clientes de los requerimientos y proyectos de software. 2. Fortalecer el modelo de realización de retrospectivas agiles que se maneja hoy en dı́a, mediante el apoyo del prototipo de herramienta web propuesto. 3. Verificar durante la fase pruebas de certificación el mejoramiento en el incumplimiento y fiabilidad en las soluciones de software desarrolladas e implementadas. 4. Fortalecer y mejorar los indicadores de cumplimiento y fiabilidad en las entregas de soluciones de software, entendiendose cumplimiento en entregar las soluciones en los tiempos previamente pactados y planeados y fiabilidad como reducir la cantidad de inidencias detectadas en las pruebas de certificación de dichas soluciones de software..

(30) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.8.. 21. Estudio de sistemas previos. Entre los sistemas que comparten la misma necesidad enncontramos etromat”, el cual es un sitio web cuya razón de ser es ofrecer una colección de actividades para retrospectivas. Su creador principal Corinna Baldauf propone una estraegaia similar donde se pueden generar modelos de retrospectivas cuyo diseño esta enfocado en actividades estratégicas y estructuradas con el objetivo se ofrecer a los usuarios formas de solucionar problemáticas o dificultades que se presenten en los equipos de desarrollo de software que trabajen con metogologı́a agile y a su vez proporcionar una base sólida para mejorar la efectividad en cada iteración. Este producto Retromat”tiene como inspiración darle un giro diferente a la forma de ejecutar retrospectivas agiles, sin duda alguna se percibe en la industria de software y en su interacción con metodologias agiles que las retrospectivas son tomadas como una forma repetitiva de discrutir los mismos temas con las mismas conclusiones una y otra vez, con Retromat”se busca cambiar el modelo de generar retrospectivas de una forma mas estrategica y dinamica basada en actividaes lúdico-cognitivas. Se puede consultar en: https://plans-for-retrospectives.com/en/?id=52-11074-88-45.

(31) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.9. 1.9.1.. Cronograma y Presupuesto Cronograma. Figura 1.5: Cronograma de trabajo. 22.

(32) CAPÍTULO 1. DESCRIPCION DE LA INVESTIGACIÓN. 1.9.2.. Presupuesto. Figura 1.6: Presupuesto de Proyecto. 23.

(33) Parte II DESARROLLO DE LA INVESTIGACIÓN. 24.

(34) Capı́tulo 2 EMPRESA 2.1.. Introdución. SHA es una compañia cuya razón de ser es ofrecer a nuestros clientes y sus clientes los mejores servicios de tecnologı́as de información, mediante el apoyo y trabajo de todos sus colaboradores siempre centra sus esfuerzos en apalancar las estrategias de negocio de sus clientes en su mayoria del sector financiero, a traves de las evoluciones tecnológicas, el desarrollo de soluciones de software e innovcion digital. Toda iniciativa o proyecto digital debe estar alineado en base a la misión visión, objetivos estratégicos y productos/servicios que conforman el modelo de negocio de la compañia sobre la cual se pretende ejecutar dicha iniciativa o proyecto.. 2.2. 2.2.1.. Misión y visión Misión. Somos el Centro de Servicios Compartidos que provee, administra y gestiona integralmente servicios de tecnologı́as de información , de manera eficiente y segura, ofreciendo altos estándares de calidad a nuestros clientes y a sus clientes, generando valor a nuestros accionistas y colaboradores.. 2.2.2.. Visión. Ser el aliado de la estrategia digital y los servicios compartidos de nuestros clientes comerciales y financieros.. 25.

(35) CAPÍTULO 2. EMPRESA. 2.3.. 26. Organigrama. Figura 2.1: Estructura Oranizacional SHA. 2.4.. Objetivos Estratégicos. CULTURA DE CALIDAD Y SERVICIO Permanente búsqueda de la excelencia en lo que hacemos, a todo nivel, con resultados sobresalientes, que nos permita ser reconocidos como la mejor opción para nuestros clientes y accionistas. Crear servicios para nuestros clientes y sus clientes promoviendo la investigación, la gestión de ideas e iniciativas. Mejorar los servicios existentes con el fin de lograr la evolución de los canales administrados. Innovar en procesos de la Organización buscando eficiencia, oportunidad y calidad en los resultados. COLABORADORES APASIONADOS Y COMPETENTES Equipo altamente productivo, en permanente desarrollo, motivado y con las habilidades necesarias para asegurar el logro de los objetivos de la compañı́a..

(36) CAPÍTULO 2. EMPRESA. 27. Desarrollar y fortalecer en los colaboradores las competencias con énfasis en la orientación al servicio para el logro de los resultados de la organización. Construir un ambiente de trabajo que nos permita estar motivados y apasionados por lo que hacemos, sintiendo orgullo por nuestra empresa. Desarrollar integralmente a nuestros colaboradores contribuyendo en su crecimiento personal y en el bienestar de sus familias.. 2.5.. Productos y Servicios. Se describen los principales productos y servicios de negocio que apalanca la compañia SHA.. Figura 2.2: Productos y servicios SHA.

(37) Capı́tulo 3 RECOLECCIÓN Y TABULACIÓN DE DATOS 3.1.. Introdución. La recolección de datos se refiere al uso de una gran variedad de técnicas y herramientas utiles para recoger datos que permitan obtener informacion relevante sobre el problema de investigación que se esté abordando. Existen 2 tipos de fuentes de recolección de datos: las fuentes primarias y las fuentes secundarias. La información de fuentes primarias es obtenida por contacto directo con el sujeto de estudio por medio de observación, cuestonarios, encuestas,entrevistas,etc. La información de fuentes secundarias es recogida a partir de investigaciones ya hechas por otros ivestigadores con propósitos diferentes.. 3.2.. Recolección de Datos. La recopilación de datos fue realizada a través de la fuente primaria que fueron llevadas a cabo en una muestra de 14 personas distribuidas entre lı́deres y analistas de desarrollo de software del área de portales transaccionales de la organización SHA. A continuación las evidencias de los datos recopilados: .encuestas”,. 28.

(38) CAPÍTULO 3. RECOLECCIÓN Y TABULACIÓN DE DATOS. Figura 3.1: Cumplimiento de requerimientos. Figura 3.2: Impedimentos en Sprints de Desarrollos de Software. 29.

(39) CAPÍTULO 3. RECOLECCIÓN Y TABULACIÓN DE DATOS. 30. Figura 3.3: Tiempos de gestión tareas de desarrollo. 3.3.. Tabulación de Datos. Se presenta la tabulación de los datos recopilados en la muestra de 14 personas(lı́deres y analistas de desarrollo) a las que se les aplicó como técnica de recolección encuestas para identificar principalmente los factores proclives en el incumplimiento de entregas de soluciones de software. A continuación frecuencias absolutas y relativas de los datos recopilados:. Figura 3.4: Frec.Absoluta del cumplimiento de requerimientos.

(40) CAPÍTULO 3. RECOLECCIÓN Y TABULACIÓN DE DATOS. Figura 3.5: Frec.Relativa del cumplimiento de requerimientos. Figura 3.6: Frec.Absoluta impedimentos en desarrollos de software. 31.

(41) CAPÍTULO 3. RECOLECCIÓN Y TABULACIÓN DE DATOS. 32. Figura 3.7: Frec.Relativa impedimentos en desarrollos de software. Figura 3.8: Frec.Absoluta tareas con mayor gestión durante fase de construcción.

(42) CAPÍTULO 3. RECOLECCIÓN Y TABULACIÓN DE DATOS. 33. Figura 3.9: Frec.Relativa tareas con mayor gestión durante fase de construcción.

(43) Capı́tulo 4 ARQUITECTURA EMPRESARIAL 4.1.. Introdución. Las organizaciones necesitan adaptarse cada vez más rápido y anticiparse a las cambiantes necesidades de los clientes y los objetivos comerciales. Esta necesidad influye en toda la cadena de actividades de una empresa, desde la estructura organizativa hasta la infraestructura de red. ¿Cómo puedes controlar el impacto de estos cambios? La arquitectura puede ser la respuesta. La arquitectura es un conjunto consistente de principios, métodos y modelos que se utilizan en el diseño y la realización de la estructura organizativa, los procesos comerciales, los sistemas de información y la infraestructura. Sin embargo, estos dominios no se abordan de forma integrada, lo que dificulta juzgar los efectos de los cambios propuestos. Cada dominio habla su propio idioma, dibuja sus propios modelos y utiliza sus propias técnicas y herramientas. La comunicación y la toma de decisiones entre dominios se ve seriamente afectada. ArchiMate proporciona esta integración, es un lenguaje de modelado de arquitectura empresarial y técnicas de visualización que representan estos dominios y sus relaciones y que permite el análisis y la visualización de la arquitectura dentro y entre los dominios de negocios. El lenguaje Archimate sirve para dise nar Arquitecturas Empresariales que faciliten la adopción de tecnologı́a en las empresas, vinculando los procesos de negocio con los activos tecnolóogicos. facilita la administración de proyectos de tecnologı́a y cambio organizacional, permitiendo que los expertos de negocio puedan priorizar los requerimientos de alto nivel y generar proyectos que impacten positivamente la organización.. 34.

(44) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 4.2.. 35. ADM - Archimate. El lenguaje ArchiMate, como se describe en este estándar técnico, complementa a TOGAF en que proporciona un conjunto de conceptos independiente del proveedor, incluida una representación gráfica, que ayuda a crear un modelo consistente e integrado que se puede representar en la forma de vistas TOGAF. TOGAF en tárminos simples es una herramienta para asistir en la aceptación, creación, uso y mantenimiento de arquitecturas. Basado en un modelo iterativo de procesos apoyado por las mejores prácticas y un conjunto reutilizable de activos arquitectónicos existentes. Se puede utilizar para desarrollar una amplia variedad de arquitecturas empresariales; además complementa y se puede usar en conjunto con otros marcos de referencia que están basados en entregables especı́ficos para sectores particulares. La clave de TOGAF es el método de desarrollo de la arquitectura (ADM), para desarrollar una arquitectura empresarial que aborda las necesidades de negocio. La estructura del lenguaje principal ArchiMate se corresponde estrechamente con las tres principales arquitecturas como se abordan en TOGAF ADM.. Figura 4.1: ADM En este contexto, distinguimos las capas principales de ArchiMate:. 4.2.1.. Capa de Negocio:. Trata sobre procesos de negocios, servicios, funciones y eventos de unidades de negocios. Esta capa .ofrece productos y servicios a los clientes que se realizan en la organización mediante procesos comerciales realizados por.

(45) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 36. actores y roles de negocios. El aspecto estructural en la capa de negocio se refiere a la estructura estática de una organización,en términos de las entidades que conforman la organización y sus relaciones. Se distinguen dos tipos de entidades: Las entidades activas que son los sujetos (por ejemplo, actores empresariales o roles comerciales) que realizan funciones como procesos o funciones empresariales (capacidades). Los actores empresariales pueden ser personas individuales (por ejemplo, clientes o empleados), sino también grupos de personas como (Unidades de la organización) y recursos que tienen un estatus permanente (o al menos a largo plazo) dentro de las organizaciones. Ejemplos tóicos de estos últimos son un departamento u unidad de negocio. Las entidades pasivas (objetos de negocio) que son manipuladas por comportamientos tales como procesos o funciones. Estas entidades pasivas representan los conceptos importantes en los que el negocio piensa en un dominio.. Figura 4.2: Metamodelo capa de negocios Las descripciones arquitectónicas se centran en la estructura, lo que significa que las interrelaciones de las entidades dentro de una organización juega un papel importante. Para hacer esto explı́cito, el concepto de negocio.

(46) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 37. colaboración ha sido introducida. Las colaboraciones comerciales se han inspirado en colaboraciones como se define en el estándar UML 2.0, aunque las colaboraciones de UML se aplican a componentes en la capa de aplicación. Además, el concepto de colaboración empresarial ArchiMate tiene una gran semejanza con el concepto de çomunidad”tal como se define en el lenguaje Enterprise de RM-ODP , ası́ como al concepto de ”punto de interacción”, definido en Amber [11] como el lugar donde las interacciones ocurren. El concepto de interfaces de negocios se introduce para modelar explı́citamente el (lógico o fı́sico) ubicaciones o canales donde se puede acceder a los servicios que una función ofrece al entorno. El mismo servicio se puede ofrecer en varias interfaces diferentes; por ejemplo, por correo, por teléfono, o a través de Internet. A diferencia del modelado de aplicaciones, es poco común en los negocios actuales enfoques de modelado de capas para reconocer el concepto de interfaz de negocios. La tabla que a continuación se muestra, da un acercamiento de los conceptos en la capa de negocio, con sus denotaciones:.

(47) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL Elemento. Definición. Actor de Negocio. Una entidad de negocio que es capaz de realizar un comportamiento.. Rol de Negocio. Colaboración Negocio. de. Interfaz de Negocio. Localización. Objeto de Negocio. Proceso de Negocio. Función de Negocio. Interacción de Negocio. La responsabilidad de realizar un comportamiento especı́fico, al cual un actor puede ser asignado, o la parte que un actor juega en una acción o evento particular. Una agregación de dos o más Elementos de estructura activos internos de negocio, que trabajan juntos para realizar un comportamiento colectivo Un punto de acceso donde un servicio de negocio está disponible al entorno Un lugar o posición donde elementos de estructura pueden ser ubicados o puede realizarse un comportamiento Representa un concepto usado dentro de un dominio de negocio particular. Representa una secuencia de comportamientos de negocio que logra un resultado especı́fico tal como un conjunto de productos o servicios de negocio definidos Una colección de comportamientos de negocio basada en un conjunto seleccionado de criterios (tı́picamente recursos y/o competencias requeridas), estrechamente alineados a una organización, pero no necesariamente explı́citamente gobernados por la organización. Una unidad de comportamiento colectivo de negocio realizada por (a colaboración de) dos o más roles de negocio. Sigue en la página siguiente.. 38 Notación.

(48) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL Elemento. Definición Un elemento de comportamiento de negocio que denota un cambio de esEvento de Negocio tado organizacional. Puede originarse y ser resuelto dentro o fuera de la organización Representa un comportamiento de Servicio de Negocio negocio explı́citamente definido que es expuesto Representa una forma perceptible de Representación la información que lleva consigo un objeto de negocio Representa el conocimiento o experiencia presente en, o la interpretaSignificado ción dada a un elemento central en un contexto particular Representa el valor relativo, benefiValor cio, utilidad o importancia de un servicio de negocio o producto Representa una colección coherente de servicios y/o elementos de estructura pasivos acompañados por Producto un contrato/conjunto de acuerdos, el cual es ofrecido como un todo a los clientes (internos o externos) Representa una especificación formal o informal de un acuerdo entre un proveedor y un consumidor que Contrato especifica los derechos y obligaciones asociados con un producto y establece parámetros para interacción funcionales y no-funcionales. Cuadro 4.1: Elementos de capa de negocio. 39 Notación.

(49) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 4.2.2.. 40. Capa de Aplicación:. El metamodelo de la capa de aplicación y sus relaciones están inspirados en gran parte en el estándarUML 2.0, por ser un lenguaje dominante y el estándar para describir aplicaciones de software. Cada concepto en el lenguaje puede tener relaciones de composición, agregación y especialización con conceptos del mismo tipo. Además, existen relaciones indirectas que pueden derivarse.. Figura 4.3: Metamodelo capa de aplicación.

(50) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 41. El concepto estructural principal para la capa de aplicación es el componente de aplicación. Este concepto se utiliza para modelar cualquier entidad estructural en la capa de aplicación: no solo componentes de software (reutilizables) que pueden ser parte de una o más aplicaciones, sino también aplicaciones completas de software, sub-aplicaciones o sistemas de información. Es muy similar al UML 2.0 sin embargo nuestro concepto de componente modela estrictamente el aspecto estructural de una aplicación: su comportamiento es modelado por una relación explı́cita con los conceptos conductuales. También en la arquitectura de la aplicación, las interrelaciones de los componentes son un ingrediente esencial. Por lo tanto, también introducimos el concepto de colaboración de aplicaciones aquı́,de nido como un colectivo de componentes de aplicación que realizan interacciones de aplicaciones. En el sentido puramente estructural, una interfaz de aplicación es el canal (lógico) a través del cual se puede acceder a los servicios de un componente. En un sentido más amplio (tal como se utiliza en,entre otros, el UML 2.0), una interfaz de aplicación de algunas caracterı́sticas de comportamiento elementales: de el conjunto de operaciones y eventos que se proporcionan por el componente, o los que se requieren desde el entorno, describiendo la funcionalidad de un componente. Se puede hacer una distinción entre una interfaz proporcionada y una interfaz requerida. El concepto de interfaz de aplicación se puede utilizar para modelar interfaces de aplicación a aplicación que ofrecen servicios de aplicaciones internas y aplicaciones a interfaces de negocio (y / o interfaces de usuario)que ofrecen servicios de aplicaciones externas. También en la capa de aplicación, distinguimos la contraparte pasiva del componente, que llamamos objeto de datos. Este concepto se utiliza de la misma manera que los objetos de datos (o tipos de objetos) en enfoques de modelado de datos bien conocidos, especialmente el concepto de clase en los diagramas de clases de UML. Un objeto de datos puede ser visto como una representación de un objeto de negocio, como una contrapartida del concepto de representación en la capa de negocio..

(51) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 42. La tabla que a continuación se mostrará, da un acercamiento de los conceptos en la capa de aplicación, con sus definiciones: Elemento Componentes aplicación. de. Colaboración aplicación. de. Interfaces de aplicación. Definición Una parte de sistema de software, modular, desplegable y reemplazable,que encapsula sus datos y expone su comportamiento a través desus interfaces. Un agregado de dos o más componentes de aplicaciones que trabajan juntos para optimizar el comportamiento colectivo. Un punto de acceso donde un servicio de aplicación está disponible para usuarios u otras aplicaciones. Un elemento pasivo, sustituible para procesos automatizados.. Objeto de datos. Función de aplicación Interacción de aplicación Servicio de aplicación. Un comportamiento de elementos que automatizan comportamientos de grupo que pueden ser optimizados por un componente de aplicación. Un elemento de comportamiento que describe el comportamiento de una colaboración de aplicación. Un servicio que expone un comportamiento automatizado.. Cuadro 4.2: Elementos de Capa de Aplicacion. Notación.

(52) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL. 4.2.3.. 43. Capa de Tecnologı́a:. El nodo es el concepto principal clave para la capa tecnológica, este concepto comparte el mismo significado que en UML 2.0. Es estrictamente usado para modelos que representan los aspectos estructurales de un sistema. Su comportamiento es modelado por una relación explı́cita de conceptos conductuales. Una Interface de infraestructura, es el acceso a los servicios ofrecidos por el nodo desde otros nodos o componentes de la capa de aplicación. Existen dos tipos de nodos: dispositivos y sistemas de software,ambos son tomadas de UML2.0. Un dispositivo es el modelo de un recurso fı́sico, sobre el cual se pueden desplegar artefactos para su ejecución. Tı́picamente, un nodo consiste un número de sub-nodos; por ejemplo, un dispositivo tal como un servidor y un sistema de software como un modelo de un sistema operativo.. Figura 4.4: Metamodelo capa de tecnologı́a Las interrelaciones de componentes en la capa de tecnologı́a están principalmente formadas por comunicaciones de infraestructura. Los modelos de comunicación es la relación entre dos o mas nodos, a través de estos nodos se puede intercambiar información. Las realización fı́sica de las rutas de comunicación son modeladas con una red y un medio de comunicación entre dos o más dispositivos. El cuadro a continuación, brinda una visión general de los conceptos de la capa de tecnologı́a con sus de nociones:.

(53) CAPÍTULO 4. ARQUITECTURA EMPRESARIAL Elemento Nodo. Dispositivo. Red. Definición Recurso computacional sobre el cual pueden almacenarse o desplegarse artefactos para su ejecución Recurso de hardware sobre el cual pueden almacenarse o desplegarse artefactos para su ejecución Medio de comunicación entre dos o mas dispositivos.. Un enlace entre dos o más nodos, a través del cual estos nodos pueden intercambiar datos. Un punto de acceso donde los servicios de infraestructura ofrecidos por Interfaz de Infraesun nodo pueden ser accedidos por tructura otros nodos y componentes de la aplicación. Un entorno de software para tipos Software del siste- especı́ficos de componentes y objetos ma que se despliegan en él en formade artefactos. Un elemento de comportamiento que Función de Infraes- agrupa el comportamiento de infratructura estructura que puede ser realizado por un nodo. Una unidad de funcionalidad visible externamente, proporcionada Servicio de Infraespor uno o más nodos, expuesta a tructura través de interfaces bien de nidas y significativa para el entorno. Una pieza fı́sica de datos que se utiliza o se produce en un proceso de Artefacto desarrollo de software, o mediante el despliegue y la operación de un sistema. Cuadro 4.3: Elementos de Capa de Tecnologı́a Ruta de comunicación. 44 Notación.