prototipo de herramienta web para la realizacion y...

FACULTAD DE INEGNIERIA

TESIS PROYECTO DE GRADO

ESPECIALIZACION EN INGENIERIA DE SOFTWARE

PROTOTIPO DE HERRAMIENTA WEB

PARA LA REALIZACION Y CONTROL

DE RETROSPECTIVAS AGILES SOBRE

REQUISITOS DE SOFTWARE

Autor: Jorge Bula GomezDiretor: Sandro Bolanos

Revisor: Joaquin Javier Meza

Bogota - ColombiaMayo 2018

Indice general

0.1. INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . 1

I CONTEXTUALIZACION DE LA INVESTIGA-CION 2

1. DESCRIPCION DE LA INVESTIGACION 31.1. Planteamiento/Identificacion del problema . . . . . . . . . . . 3

1.1.1. Formulacion del problema . . . . . . . . . . . . . . . . 41.1.2. Sistematizacion del problema . . . . . . . . . . . . . . 4

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . 51.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . 5

1.3. Justificacion del trabajo/investigacion . . . . . . . . . . . . . . 61.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . 71.5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . 14

1.6. Metodologıa de la investigacion . . . . . . . . . . . . . . . . . 171.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . 171.6.2. Metodo de investigacion . . . . . . . . . . . . . . . . . 181.6.3. Fuentes y tecnicas de recoleccion de informacion . . . . 18

1.7. Alcance,limitaciones y resultados esperados . . . . . . . . . . . 191.7.1. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . 191.7.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . 191.7.3. Resultados esperados . . . . . . . . . . . . . . . . . . . 19

1.8. Estudio de sistemas previos . . . . . . . . . . . . . . . . . . . 211.9. Cronograma y Presupuesto . . . . . . . . . . . . . . . . . . . 22

1.9.1. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . 221.9.2. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . 23

i

INDICE GENERAL ii

II DESARROLLO DE LA INVESTIGACION 24

2. EMPRESA 252.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2. Mision y vision . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.1. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.2. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3. Organigrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4. Objetivos Estrategicos . . . . . . . . . . . . . . . . . . . . . . 262.5. Productos y Servicios . . . . . . . . . . . . . . . . . . . . . . . 27

3. RECOLECCION Y TABULACION DE DATOS 283.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2. Recoleccion de Datos . . . . . . . . . . . . . . . . . . . . . . . 283.3. Tabulacion de Datos . . . . . . . . . . . . . . . . . . . . . . . 30

4. ARQUITECTURA EMPRESARIAL 344.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2. ADM - Archimate . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1. Capa de Negocio: . . . . . . . . . . . . . . . . . . . . . 354.2.2. Capa de Aplicacion: . . . . . . . . . . . . . . . . . . . 404.2.3. Capa de Tecnologıa: . . . . . . . . . . . . . . . . . . . 434.2.4. Capa de Motivacion: . . . . . . . . . . . . . . . . . . . 45

5. NEGOCIO 475.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. Punto de Vista de Organizacion . . . . . . . . . . . . . . . . . 48

5.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 49

5.3. Punto de Vista de Cooperacion de Actor . . . . . . . . . . . . 505.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 51

5.4. Punto de Vista de Funcion de Negocio . . . . . . . . . . . . . 525.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 53

5.5. Punto de Vista de Proceso de Negocio . . . . . . . . . . . . . 545.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 55

5.6. Punto de Vista Cooperacion Proceso de Negocio . . . . . . . . 565.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.6.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 57

INDICE GENERAL iii

5.7. Punto de Vista deProducto . . . . . . . . . . . . . . . . . . . 585.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.7.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 59

6. APLICACION 606.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2. Punto de Vista de Cooperacion de Aplicacion . . . . . . . . . 61


6.3. Punto de Vista de Comportamiento de Aplicacion . . . . . . . 636.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 64

6.4. Punto de Vista de Estructura de Aplicacion . . . . . . . . . . 656.4.1. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 66

6.5. Punto de Vista de Uso de Aplicacion . . . . . . . . . . . . . . 676.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.5.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 68

7. MOTIVACION 727.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2. Punto de Vista stakeholder . . . . . . . . . . . . . . . . . . . . 73


7.3. Punto de Vista de Realizacion de Objetivos . . . . . . . . . . 757.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.3.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 76

7.4. Punto de Vista de Motivacion . . . . . . . . . . . . . . . . . . 777.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.4.2. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 78

8. METODOLOGIA SCRUM 798.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.2. Historias de Usuarios . . . . . . . . . . . . . . . . . . . . . . . 80

9. DISENO DE SOFTWARE 859.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859.2. Herramientas metodologicas utilizadas . . . . . . . . . . . . . 859.3. Casos de Uso RetroWeb . . . . . . . . . . . . . . . . . . . . . 86

9.3.1. Caso de uso Registrar Requisitos de Software . . . . . 869.3.2. Caso de uso Registrar Equipos de Desarollo . . . . . . 879.3.3. Caso de uso Registrar Sprints de Desarollo . . . . . . . 87

INDICE GENERAL iv

9.3.4. Caso de uso Consultar Sprints de Desarollo . . . . . . . 889.3.5. Caso de uso Registrar Tareas de Sprint . . . . . . . . . 889.3.6. Caso de uso Asociar Impedimentos a Tareas . . . . . . 899.3.7. Caso de uso Generar Retrospectivas de Sprint . . . . . 89

9.4. Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . 909.5. Arquitectura de la Aplicacion . . . . . . . . . . . . . . . . . . 93

9.5.1. Diseno de Aplicacion . . . . . . . . . . . . . . . . . . . 949.5.2. Diseno capa de presentacion . . . . . . . . . . . . . . . 95

10.IMPLEMENTACION 9810.1. Prototipo funcional . . . . . . . . . . . . . . . . . . . . . . . . 98

III CIERRE DE LA INVESTIGACION 104

11.RESULTADOS Y DISCUSION 105

12.CONCLUSIONES 10712.1. Verificacion,contraste y evaluacion de los objetivos . . . . . . . 10712.2. Sıntesis del modelo propuesto . . . . . . . . . . . . . . . . . . 10812.3. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . 10912.4. Trabajos o Publicaciones derivadas . . . . . . . . . . . . . . . 109

Indice de figuras

1.1. Reporte de la Chaos 1 . . . . . . . . . . . . . . . . . . . . . . 81.2. Reporte de la Chaos 2 . . . . . . . . . . . . . . . . . . . . . . 91.3. Reporte de la Chaos 3 . . . . . . . . . . . . . . . . . . . . . . 91.4. Reporte de la Chaos sobre proyectos en 2015 . . . . . . . . . . 101.5. Cronograma de trabajo . . . . . . . . . . . . . . . . . . . . . . 221.6. Presupuesto de Proyecto . . . . . . . . . . . . . . . . . . . . . 23

2.1. Estructura Oranizacional SHA . . . . . . . . . . . . . . . . . 262.2. Productos y servicios SHA . . . . . . . . . . . . . . . . . . . 27

3.1. Cumplimiento de requerimientos . . . . . . . . . . . . . . . . . 293.2. Impedimentos en Sprints de Desarrollos de Software . . . . . . 293.3. Tiempos de gestion tareas de desarrollo . . . . . . . . . . . . . 303.4. Frec.Absoluta del cumplimiento de requerimientos . . . . . . . 303.5. Frec.Relativa del cumplimiento de requerimientos . . . . . . . 313.6. Frec.Absoluta impedimentos en desarrollos de software . . . . 313.7. Frec.Relativa impedimentos en desarrollos de software . . . . . 323.8. Frec.Absoluta tareas con mayor gestion durante fase de cons-

truccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.9. Frec.Relativa tareas con mayor gestion durante fase de cons-

truccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1. ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2. Metamodelo capa de negocios . . . . . . . . . . . . . . . . . . 364.3. Metamodelo capa de aplicacion . . . . . . . . . . . . . . . . . 404.4. Metamodelo capa de tecnologıa . . . . . . . . . . . . . . . . . 434.5. Metamodelo capa de motivacion . . . . . . . . . . . . . . . . . 45

5.1. Metamodelo de oranizacion . . . . . . . . . . . . . . . . . . . 485.2. Punto de vista organizacion . . . . . . . . . . . . . . . . . . . 495.3. Metamodelo cooperacion de Actor . . . . . . . . . . . . . . . 505.4. Punto de vista cooperacion de Actor RetroWeb . . . . . . . . 51

v

INDICE DE FIGURAS vi

5.5. Metamodelo funcion de Negocio . . . . . . . . . . . . . . . . . 525.6. Punto de vista funcion de Negocio RetroWeb . . . . . . . . . . 535.7. Metamodelo proceso de Negocio . . . . . . . . . . . . . . . . 545.8. Punto de vista proceso de Negocio RetroWeb . . . . . . . . . . 555.9. Metamodelo cooperacion de proceso de Negocio . . . . . . . . 565.10. Punto de vista cooperacion de proceso de Negocio RetroWeb . 575.11. Metamodelo cooperacion de proceso de Negocio . . . . . . . . 585.12. Punto de vista producto RetroWeb . . . . . . . . . . . . . . . 59

6.1. Metamodelo Cooperacion de Aplicacion . . . . . . . . . . . . 616.2. Punto de Vista Cooperacion de Aplicacion . . . . . . . . . . . 626.3. Metamodelo Comportamiento de Aplicacion . . . . . . . . . . 636.4. Punto de vista Comportamiento de Aplicacion . . . . . . . . 646.5. Metamodelo Comportamiento de Aplicacion . . . . . . . . . . 656.6. Punto de vista Estructura de Aplicacion . . . . . . . . . . . . 666.7. Metamodelo Uso de Aplicacion . . . . . . . . . . . . . . . . . 676.8. Proceso de registrar requerimiento . . . . . . . . . . . . . . . 686.9. Proceso de crear y asociar equipos a requerimiento . . . . . . 696.10. Proceso creacion de Sprint de desarrollo . . . . . . . . . . . . 696.11. Proceso creacion de tareas de desarrollo en Sprint . . . . . . . 706.12. Proceso asociar impedimentos a tareas de desarrollo en Sprint 706.13. Proceso de generar retrospectiva virtual para impedimentos

asociados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1. Metamodelo de los stakeholders . . . . . . . . . . . . . . . . . 737.2. Punto de vista stakeholders de RetroWeb . . . . . . . . . . . . 747.3. Metamodelo de realizacion de objetivos . . . . . . . . . . . . 757.4. Punto de vista realizacion de objetivos de RetroWeb . . . . . 767.5. Metamodelo motivacional . . . . . . . . . . . . . . . . . . . . 777.6. Punto de vista motivacional RetroWeb . . . . . . . . . . . . . 78

9.1. Registrar requisitos de software . . . . . . . . . . . . . . . . . 869.2. Registrar equipos de desarrollo . . . . . . . . . . . . . . . . . . 879.3. Registrar Sprints de desarrollo . . . . . . . . . . . . . . . . . . 879.4. Consultar Sprints de Desarollo . . . . . . . . . . . . . . . . . . 889.5. Registrar tareas de sprint . . . . . . . . . . . . . . . . . . . . . 889.6. Asociar Impedimentos a Tareas . . . . . . . . . . . . . . . . . 899.7. Generar Retrospectivas de Sprint . . . . . . . . . . . . . . . . 899.8. Modelo de datos RetroWeb . . . . . . . . . . . . . . . . . . . . 909.9. Modelo de Datos Gestion de usuarios RetroWeb . . . . . . . . 919.10. Modelo de Datos logica de negocio RetroWeb . . . . . . . . . 92

INDICE DE FIGURAS vii

9.11. Arquitectura de la aplicacion . . . . . . . . . . . . . . . . . . . 949.12. Maquetado home en RetroWeb . . . . . . . . . . . . . . . . . 959.13. Maquetado gestion de tareas en RetroWeb . . . . . . . . . . . 969.14. Maquetado gestion de usuarios en RetroWeb . . . . . . . . . . 97

10.1. Pagina principal del prototipo RetroWeb . . . . . . . . . . . 9810.2. Modulo de registro de requerimientos . . . . . . . . . . . . . . 9910.3. Modulo de registro de equipos de desarrollo . . . . . . . . . . 10010.4. Modulo de registro Sprints de desarrollo . . . . . . . . . . . . 10010.5. Modulo de registro tareas de desarrollo . . . . . . . . . . . . . 10110.6. Consultar tarea de desarrollo para asociar impedimentos . . . 10210.7. Asociar impedimentos a tareas de desarrollo . . . . . . . . . . 10210.8. Generacion de retrospectiva . . . . . . . . . . . . . . . . . . . 10310.9. Generacion de retrospectiva . . . . . . . . . . . . . . . . . . . 103

12.1. Modelo de Datos logica de negocio RetroWeb . . . . . . . . . 11312.2. Arquitectura de aplicacion RetroWeb . . . . . . . . . . . . . . 11412.3. EDT Proyecto de Investigacion . . . . . . . . . . . . . . . . . 115

Indice de cuadros

4.1. Elementos de capa de negocio . . . . . . . . . . . . . . . . . . 394.2. Elementos de Capa de Aplicacion . . . . . . . . . . . . . . . . 424.3. Elementos de Capa de Tecnologıa . . . . . . . . . . . . . . . . 444.4. Elementos de Capa de Motivacion . . . . . . . . . . . . . . . . 46

8.1. Historia de Usuario HUO1 - Crud de requerimientos de software 808.2. Historia de Usuario HUO2 - Crud equipos de desarrollo . . . . 808.3. Historia de Usuario HUO3 - Crud de sprints de desarrollo . . . 818.4. Historia de Usuario HUO4 - Registrar y gestionar tareas de

desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.5. Historia de Usuario HUO5 - Registar y controlar impedimen-

tos de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.6. Historia de Usuario HUO6 - Generar de retrospectivas . . . . 828.7. Historia de Usuario HUO7 - Consultar retrospectivas por Sprint 838.8. Historia de Usuario HUO8 - Login de usuarios . . . . . . . . . 838.9. Historia de Usuario HUO9 - Gestion de permisos y roles de

usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848.10. Historia de Usuario HHU10 - Registrar categorias de impedi-

mentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

viii

INDICE DE CUADROS 1

0.1. INTRODUCCION

Este trabajo de investigacion propone una forma estrategica de llevar acabo la realizacion de retrospectivas agiles en los equipos de desarrollo desoftware que trabajan bajo metodologıas agiles, debido a que actualmentese ha observado que durante la resolucion de requerimientos y proyectos desoftware no se esta brindando la importancia requerida a una fase de re-trospeccion, reflexion e identificacion de dificultades de manera anticipadaconocida como retrospectiva, de tal forma que se logren tomar decisionesy acciones correctivas que permitan reducir los ındices de incumplimientoen las entregas de las soluciones de software para dichos requerimientos oproyectos, ası mismo que permitan mejorar la fiabilidad en los desarrollose implementacion de tales soluciones, todo esto en pro de lograr en primerlugar la mejora continua en los equipos de desarrollo y en segundo obteneruna mayor satisfaccion de los clientes. Cabe mencionar que bajo el modelode metodologıas agiles para desarrollo de software las retrospectivas cons-tituyen una fase fundamental ya que son consideradas como el corazon dela mejora continua y las practicas emergentes, los equipos reflexionan y ha-cen retrospeccion sobre los acontecimientos sucedidos en cada iteracion osprint definido de forma sistematica para lograr cumplir con la entrega deun producto con incrementos funcionales satisfactorios para un cliente. Enel presente documento se pretende describir la efectividad y resultados po-sitivos que se pueden obtener con la posibilidad de poder facilitarle a loslıderes de proyectos y equipos de desarrollo una herramienta tecnologica queles permita obtener modelos o estructuras de retrospectivas a partir del tipode necesidades, dificultades o debilidades identificadas en equipos de desa-rrollo de software durante la implementacion de soluciones, adicionalmenteque esta propuesta puede permitir obtener beneficios tales como una mejoradministracion de los tiempos de entrega comprometidos y a su vez poder re-solver anticipadamente obstaculos que pueden llegar a entorpecer la entregade software funcional con valor y en su defecto el buen rumbo de un proyectoo determinados requerimientos.

Parte I

CONTEXTUALIZACION DELA INVESTIGACION

2

Capıtulo 1

DESCRIPCION DE LAINVESTIGACION

1.1. Planteamiento/Identificacion del proble-

ma

Es importante resaltar inicialmente que las retrospectivas no son algo ex-clusivo del mundo del software, o de los proyectos agiles, las podemos aplicarpara la vida personal,profesional, a proyectos de servicios, de sistemas, en-tre otras. En el contexto del desarrollo de software simplificadamente, sonuna reunion al final de un proyecto, iteracion, sprint o release, cuyos objeti-vos primordiales podemos decir que son aprender para mejorar y la mejoracontinua, es decir hacer una revision para aprender de la experiencia y decomo nos ha ido durante la marcha, mediante el analisis y valoracion de es-trategias que permitan generar cambios, esto es acciones de mejoramientopara obtener incrementos efectivos en pro de los resultados deseados. La pro-blematica evidenciada en la organizacion ATH radica en que ademas de queexiste un desconocimiento en la gestion de retrospectivas agiles, se evidenciala manera poco eficiente en como las retrospectivas se vienen generando yrealizando desde que se adopto metodologıa agile scrum para la gestion yejecucion del ciclo de vida de desarrollo de software, aportando poco valorpara mejorar el cumplimiento en la entrega de las soluciones de softwareen los tiempos definidos y a su vez la calidad de dichas soluciones, ya queaun ası con esa nueva metodologıa se siguen presentando porcentajes altosde incidencias(bugs) evidenciadas durante la fase de pruebas de certificacion(testing) y peor aun porcentaje alto del indicador de reversos en ambientesproductivos por afectacion y fallas de funcionalidades existentes y nuevas. Seobserva que las retrospectivas han sido enfocadas como una simple reunion

3

CAPITULO 1. DESCRIPCION DE LA INVESTIGACION 4

mas, sin dinamismo y enfoque, se ha identificado que no se estan usandopara propiciar acciones de mejora, para lograr descubrir las falencias, even-tos y actividades que afectan el cumplimiento a los clientes con entregas desoftware funcional, al igual que la elaboracion de software fiable, siendo es-tos criterios elementos fundamentales en el contexto de desarrollo de softwarecon metodologıas agiles, se evidencia que no se llevan a cabo tareas esencialescomo recabar datos, decidir que hacer y definir los cambios y correctivos quepermitan mitigar los riesgos de entrega de software sin calidad e inoportunoo aun peor no realizar entregas continuas de software con valor a los clientes.

1.1.1. Formulacion del problema

¿Cual es la estrategia cognitiva que permite hacer efectiva la retrospectivaagil en la organizacion SHA, cuyo dominio es el desarrollo de solucionestecnologicas y software de alta calidad?

1.1.2. Sistematizacion del problema

1. ¿Cuales son los eventos y actividades proclives del incumplimiento enla elaboracion de software fiable?2. ¿Como valorar para categorizar y/o ponderar las entidades de freno alproceso de desarrollo de software?3. ¿Cuales indicadores en rojo deben ser atendidos para evitar el enlenteci-miento del proceso de desarrollo de software?4. ¿Cual es el porcentaje de mejora en el desarrollo de los requisitos y pro-yectos de software posterior a la ejecucion de retrospectivas agiles?


1.2. Objetivos

1.2.1. Objetivo general

Fortalecer la fase de implementacion de software en la organizacionSHA mediante la aplicabilidad de un prototipo web que permita reali-zar y controlar de forma efectiva retrospectivas agiles para mejorar elcumplimiento y fiabilidad en los requerimientos de software.

1.2.2. Objetivos especıficos

Realizar encuestas a los equipos de desarrollo mediante el uso de herra-mientas web para determinar los eventos e impedimentos que influyenen la implementacion de software fiable e incumplimiento en las entre-gas de requerimientos.

Definir las categorıas a las cuales seran asociadas los eventos e impe-dimentos que influyen en el incumplimiento de la entrega de softwarefiable, para fijarlos modelos de retrospectivas virtuales que contiene lasposibles acciones correctivas.

Validar las asociaciones entre los modelos de retrospectivas virtualesy las categorıas de referencia definidas previamente, para verificar elimpacto en el mejoramiento del incumplimiento en las entregas de re-querimientos e implementacion de software fiable.

Implementar producto tecnologico que permita controlar y generar mo-delos de retrospectivas agiles para verificar el mejoramiento en la fasede implementacion de software fiable y cumplimento en las entregas derequerimientos a los clientes.


1.3. Justificacion del trabajo/investigacion

Esta investigacion se realiza debido a que existe la necesidad de mejorarel nivel de cumplimiento de los requisitos y proyectos de software solicitadosa la organizacion SHA, ası mismo poder mejorar la fiabilidad en la elabora-cion de software que se lleva a cabo en las plataformas virtuales de internetque se manejan en dicha organizacion, esto en base a que no existe el co-nocimiento para trazar la cadena de produccion de una retrospectiva agilefectiva, por tal motivo es de manifestar que la propuesta de este estudiotiene enmarcado colaborar con reducir este desconocimiento para llevar acabo la fase de retrospeccion de manera efectiva, de tal forma que se logreevolucionar positivamente con entregas de software fiable a los clientes sobrelos tiempos pactados, y en su defecto lograr disminuir las cifras de incidentesque se presentan en las plataformas virtuales de internet sobre los entornosproductivos de acceso publico. Es preciso resaltar que se pretende generar unimpacto positivo en los equipos de desarrollo ya que en primera instancia sebusca mejorar el desconocimiento que se presenta hoy en dıa para la ejecucionde retrospectivas agiles, teniendo en cuenta la metodologıa agil scrum queha adoptado la organizacion SHA en su actualidad para la gestion, planea-cion y control de su proceso de desarrollo de software, en segunda instanciaidentificar y controlar a tiempo las fallas, obstaculos o dificultades que ven-gan presentando los equipos de desarrollo en la ejecucion de los denominadossprints generados a partir de los backlog definidos para cada requisito o pro-yecto en curso, de tal manera que se puedan solucionar y lograr cumplir conefectividad las entregas de software acordadas con los clientes.

1.4. Hipotesis

La realizacion adecuada y el control estrategico de las retrospectivas agilesmediante la implementacion de una herramienta tecnologica web permitirapromover la mejora continua en los equipos de desarrollo de software delarea de portales transaccionales de la organizacion SHA, para mejorar elcumplimiento en las entregas de requerimientos y a su vez la fiabilidad en lassoluciones de software implementadas.


1.5. Marco referencial

1.5.1. Marco Teorico

De la secuencialidad a la iteracionEl desarrollo de software no es una disciplina sencilla. En las ultimas decadaslos lenguajes estructurados modernos, de modelado (UML) y posteriormen-te varias herramientas intentaron sin exito posicionarse como las ”balas deplata”4 para resolver algunos de sus problemas. Incluso se habıa llegado acontar con herramientas poderosas y procesos de modelado y diseno sin te-ner muy en claro como aplicarlos a la hora de construir el software. No fuesino hasta la adopcion amplia y consciente de un tercer elemento injusta-mente relegado a un papel secundario, las metodologıas de desarrollo, que seencontraron soluciones adecuadas a muchos problemas. La mayorıa de estasmetodologıas fueron introducidas desde la ingenierıa civil, lo que resulto enun exhaustivo control sobre los procesos y las tareas. El Modelo Secuencialde Procesos, tambien conocido como Waterfall Model o Modelo en Cascada,se convirtio en el modelo metodologico mas utilizado dentro de la industria.Data de principios de los anos setenta y tiene sus orıgenes en los ambitos dela manufactura y la construccion, ambientes fısicos altamente rıgidos dondelos cambios se vuelven prohibitivos desde el punto de vista de los costos, sinopracticamente imposibles. Como no existıa proceso alguno en la industria delsoftware, esta condicion no impidio su adopcion. La primera mencion publica(reconocida) de este tipo de metodologıas fue realizada en un artıculo quedata de 1970 donde el Dr. Winston W. Royce presenta -sin mencionar lapalabra ”Waterfall un modelo secuencial para el desarrollo de software quecomprendıa las siguientes fases:

Especificacion de requerimientos

Diseno

Implementacion (tambien conocida como construccion o codificacion)

Integracion

Verificacion o prueba y debugging

Instalacion

Mantenimiento

El proceso Waterfall sugiere una evolucion secuencial. Por ejemplo: primerose realiza la fase de especificacion de requerimientos. Una vez que se en-cuentra completa se procede a un ”sign-off”(firma/aprobacion) que congela


dichos requerimientos, y es recien aquı cuando se inicia la fase de diseno delsoftware, fase donde se produce un plano o ”blueprint”del mismo para quelos codificadores/programadores lo implementen. Hacia el final de la fase deimplementacion, diferentes componentes desarrollados son integrados con elfin de pulir las interfaces entre ellos. El siguiente paso es la fase de verifica-cion en la que los testers someten el sistema a diferentes tipos de pruebasfuncionales mientras los programadores corrigen el codigo donde sea nece-sario. Una vez que el sistema responde satisfactoriamente a la totalidad delas pruebas, se inicia una etapa de instalacion y mantenimiento posterior.Los problemas detectados en los modelos tradicionales o de tipo Waterfall sefundamentan, por un lado, en el entorno altamente cambiante propio de laindustria, y por el otro, en el proceso mismo de desarrollo de software dondeel resultado depende de la actividad cognitiva de las personas mas que de laspracticas y controles empleados. A medida que han pasado los anos, y con eladvenimiento de las economıas globalizadas y los entornos web, el contextode negocio de los sistemas ha pasado de ser relativamente estable a conver-tirse en un contexto altamente volatil, donde los requerimientos expresadoshoy, en muy pocas oportunidades son validos unos meses mas tarde. Bajoesta nueva realidad, las metodologıas Waterfall resultaron muy “pesadas” yprohibitivas para responder satisfactoriamente a los cambios de negocio. Enel ano 1994 el Standish Group publico un estudio conocido como el CHAOSReport”6 donde se encontro la siguiente tasa de exito en los proyectos dedesarrollo 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 investigacion sugieren que el involucramiento delusuario y el empleo de periodos de tiempo mas cortos son claves para incre-mentar las tasas de proyectos exitosos Bajo este contexto surgieron nuevasmetodologıas, como, por ejemplo:




Metodologıas en Espiral

Metodologıas Iterativas

Metodologıas Agiles

Tanto las Metodologıas en Espiral como las Metodologıas Iterativas se en-cuentran fuera del alcance de este trabajo, por lo que pasaremos directamentea entender las Metodologıa Agiles.


Figura 1.4: Reporte de la Chaos sobre proyectos en 2015

El origen de las Metodologıas AgilesEn los 90s surgieron varios movimientos identificados con el nombre de

Metodologıas Livianas (LightweightMethodologies). Entre estos se encuen-tran Extreme Programming (XP), Scrum, Software Craftmanship, Lean Soft-ware Development, etc. Mas tarde, en febrero de 2001, se reunieron en Utah(EEUU) un grupo de diecisiete profesionales reconocidos del desarrollo desoftware, y referentes de las metodologıas livianas existentes al momento,con el objetivo de determinar los valores y principios que les permitirıan alos equipos desarrollar software de forma mas acertada con las necesidadesdel cliente y responder mejor a los cambios que pudieran surgir a lo largo deun proyecto de desarrollo. Se pretendıa ofrecer una alternativa a los procesosde desarrollo de software tradicionales, caracterizados por la rigidez y domi-nados por la documentacion. En esta reunion se creo la Agile Alliance7, unaorganizacion sin fines de lucro cuyo objetivo es el de promover los valores yprincipios de la filosofıa agil y ayudar a las organizaciones en su adopcion.Tambien se declaro la piedra angular del movimiento agil, conocida comoManifiesto Agil. (Alaimo,2013, p.12).Las retrospectivas AgilesPara Alaimo (2013) en un metodo empırico como Scrum, la retrospecciondel equipo es el corazon de la mejora continua y las practicas emergentes.Mediante el mecanismo de retrospeccion, el equipo reflexiona sobre la for-ma en la que realizo su trabajo y los acontecimientos que sucedieron en elSprint que acaba de Proyectos Agiles con Scrum concluir para mejorar suspracticas. Todo esto sucede durante la reunion de retrospectiva. Valiendosede tecnicas de facilitacion y analisis de causas raıces, se buscan tanto for-talezas como oportunidades de mejora. Luego, el Equipo Scrum decide por


consenso cuales seran las acciones de mejora a llevar a cabo en el siguienteSprint. Estas acciones y sus impactos se revisaran en la proxima reunion deretrospectiva

Con base a lo anterior me permito referenciar el siguiente cuestionamientosobre el cual esta guiado este estudio de investigacion, una vez que tenemosclaro que una retrospectiva nos ayudara en la mejora continua, ¿como lallevamos a cabo? El objetivo es analizar como fue la ultima iteracion, comotrabajamos, que problemas tuvimos, que cosas funcionaron bien y cuales no.Y con todo esto ver hacia donde queremos ir, sacar acciones concretas quecada uno pueda realizar durante la siguiente iteracion para solucionar losproblemas encontrados, mejorar la forma de trabajo y conseguir el objetivopropuesto. Para ello, podemos simplificar la reunion planteando estas pre-guntas en el siguiente orden:

¿Como 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. Elresto del equipo ira contestando y debatiendo cada uno de los puntos. Elobjetivo final es conseguir acciones que cada uno pueda realizar durante elsiguiente sprint para mejorar. ¿Que problemas podemos encontrar con esteformato?

1. No todo el mundo habla. Siempre hay personas en el equipo con mascapacidad de comunicacion o con mas personalidad capaces de acapa-rar una reunion mientras que otros apenas hablan, el no ser propositivopuede generar que no se menciones dificultades o situaciones que pue-den llegar a incidir en el logro de los objetivos, como lograr elaborarsoluciones con calidad o poder realizar entregas de software funcionalen los tiempos pactados con clientes.

2. Reuniones repetitivas. Se repiten los mismos resultados retrospectivatras retrospectiva, es decir persiste una continuidad de las dificultades ydel problema, la calidad de las retrospectivas no es apropiada y efectiva

3. Sentimiento de perdida de tiempo. Algunos miembros del equipo pue-den sentir que estan perdiendo el tiempo porque no se tratan o no


se profundiza en los temas que creen que son importantes, es decir semaneja poco interes por el deseo y logro de alcanzar objetivos y satis-faccion de clientes, esto es ambientes pobres.

4. Evitar temas conflictivos. Puede que haya temas mas delicados queno lleguen a tratarse por miedo o por no saber como plantearlos oabordarlos.

5. Reuniones incomodas. Pueden darse momentos de mas tension duranteel desarrollo de nuestro proyecto y esto se puede trasladar a la reunionde retrospectiva haciendo que esta sea un tanto incomoda o que sal-gamos de ella desmotivados, esto puede traducirse como la falta de unliderazgo apropiado, el cual se presenta por no orientar las retrospecti-vas de forma estrategica y con la motivacion e importancia necesaria.

Estrategias para ayudar a su equipo a avanzar con RetrospectivasAgilesEsther Derby y Diana Larsen (2010) senalan en su libro Agile Retrospec-tives Makinggood teams great senalan estrategias que se pueden plantearpara desatascar a los equipos de desarrollo cuando presentan mal funciona-miento afectando la evolucion de los proyectos requerimientos de software:Se requiere disponer un miembro que pueda ejercer liderazgo en las etapasde retrospectivas, que puede ayudar a restaurar sus jugos creativos haciendopreguntas como como estos:

1. ¿Que hemos probado antes? ¿Que paso? ¿Que te gustarıa para quesuceda de manera diferente?

2. Si tuvieramos eso, ¿que ganarıamos?

3. ¿Alguna vez has intentado esto de una manera diferente? ¿Que paso?

Usted puede pedir mas opiniones, especialmente de personas que han sidopensando mas que hablando. Puede sugerir investigaciones adicionales antesde comprometerse con una solucion. Usted puede quitar el sombrero de lıderretrospectivo y ofrecer contenido conocimiento de la experiencia personal.Podrıas decirle al equipo que hacer, pero solo si quieres enganar a aprendizaje.

Psicologıa profunda de las retrospectivas AgilesVarios anos de experiencia en retrospectivas en diferentes culturas han dadocomo resultado algunas tecnicas interesantes para mejorar el rendimiento detu equipo y entender mas sobre el funcionamiento humano. En esta entradate lo mostrare desde el punto de vista de un Scrum Master, pero podrıaser aplicada y brindada al grupo por cualquier integrante. (Buhler, 2013,Psicologıa profunda de las retrospectivas Agile).


La retrospectiva RobotEspecialmente para los recien entrados en la dinamica Agile (aunque tam-bien lo he visto en grupos que llevan ya cierto tiempo), las retrospectivas seconvierten en reuniones muy automaticas (“roboticas”) y siempre al final delciclo; 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 lareunion.

El mayor problema es que esta modalidad en el largo plazo puede ocasionarmas inconvenientes que soluciones. El primer punto a entender es porquese llevan adelante las reuniones en Agile/Scrum y cual es el fin de realizarciertas preguntas. El hecho de que las preguntas esten allı no es primordial-mente para para conocer informacion acerca del resultado de los procesos,sino que principalmente para modelar un comportamiento, esto es, poner alos individuos dentro de cierto patron de pensamiento y accion.

“Las preguntas en las reuniones Agile se efectuan para modelar un com-portamiento” Por supuesto que de forma secundaria esta el obtener informa-cion y hacer algo con ella, como ser remover obstaculos, cambiar un proceso,etc. La retrospectiva es algo entonces que no debe ser tomada a la ligera yaque es el unico punto donde el grupo puede radicalmente cambiar su direccionmediante la toma de decisiones, adoptar medidas y aprender para el medianoy largo plazo. Podrıas pensar que la reunion Standup diaria tiene un fin si-milar, no obstante, esta ultima ataca obstaculos relacionados principalmentecon las historias de usuarios y no del grupo en sı. La mayor carencia con lamodalidad de reunion “robot” es que existen infinidad de problemas que nopueden ser sacados a la luz a no ser que se empleen tecnicas que apuntenestos inconvenientes de forma directa pero despersonalizada. Acuerdate queel trabajo del ultimo 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 noadecuadas que muten ciclo a ciclo con el fin de poder “ocultarse” de la vista


de un simple mortal.Estructura de las retrospectivasPara Gabardini (2013) las retrospectivas se pueden estructurar con las si-guientes partes:

1. Preparar el escenario: lograr que las personas se focalicen en los objeti-vos de la reunion, en el tiempo estipulado y con una dinamica produc-tiva.

2. Recabar datos: lograr una vision comun de la situacion a analizar, tan-to con datos objetivos como subjetivos. Es la base comun de hechos,eventos y sentimientos que permitira tener una comunicacion efectivadurante el resto de la reunion.

3. Generar entendimiento profundo: entender el por que, tanto lo que an-duvo mal como lo que anduvo bien. Ir mas alla de la primera apariencia,para encontrar las causas profundas que hay que sostener y mejorar ocambiar.

4. Decidir que hacer: teniendo una lista de posibles experimentos que elequipo puede realizar para mejorar, es el momento de elegir, ya que notodo se puede hacer para el siguiente sprint.

5. Cierre: finalizar claramente la retrospectiva, con una nota positiva yganas 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 practicas emer-gentes en dominios complejos, como la gestion de proyectos de innovacion.No es un proceso completo, y mucho menos, una metodologıa. En lugar deproporcionar una descripcion completa y detallada de como deben realizar-se las tareas de un proyecto, genera un contexto relacional e iterativo, deinspeccion y adaptacion constante para que los involucrados vayan creandosu propio proceso. Esto ocurre debido a que no existen ni mejores ni buenaspracticas en un contexto complejo. Es el equipo de involucrados quien encon-trara la mejor manera de resolver sus problematicas. Este tipo de solucionesseran emergentes. El equipo de desarrollo se encuentra apoyado en dos roles:el ScrumMaster y el Product Owner. El ScrumMaster es quien vela por lautilizacion de Scrum, la remocion de impedimentos y asiste al equipo a quelogre su mayor nivel de performance posible. Puede ser considerado un coach


o facilitador encargado de acompanar al equipo de desarrollo. El ProductOwner es quien representa al negocio, stakeholders, cliente y usuarios finales.Tiene la responsabilidad de conducir al equipo de desarrollo hacia el pro-ducto adecuado. Proyectos Agiles con Scrum 22 El progreso de los proyectosque utilizan Scrum se realiza y verifica en una serie de iteraciones llamadasSprints. Estos Sprints tienen una duracion fija, pre-establecida de no masde un mes. Al comienzo de cada Sprint el equipo de desarrollo realiza uncompromiso de entrega de una serie de funcionalidades o caracterısticas delproducto en cuestion. Al finalizar el Sprint se espera que estas caracterısticascomprometidas esten terminadas, lo que implica su analisis, diseno, desarro-llo, prueba e integracion al producto. En este momento es cuando se realizauna reunion de revision del producto construido durante el Sprint, donde elequipo de desarrollo muestra lo construido al Product Owner y a cualquierstakeholder interesado en participar. El feedback obtenido en esta reunionpuede ser incluido entre las funcionalidades a construir en futuros Sprints.

Sprint Backlog:El Sprint Backlog es el conjunto de PBIs que fueron seleccionados para tra-bajar en ello durante un cierto Sprint, conjuntamente con las tareas que elequipo de desarrollo ha identificado que debe realizar para poder crear unincremento funcional potencialmente entregable al finalizar el Sprint.

“El resultado de cada Sprint debe ser un incremento funcional potencial-mente entregable.”

Sprint (Iteracion):Las iteraciones en Scrum se conocen como Sprints. Scrum, como todos losenfoques agiles, es un proceso de desarrollo incremental e iterativo. Esto sig-nifica que el producto se construye en incrementos funcionales entregadosen periodos cortos para obtener feedback frecuente. En general, Scrum reco-mienda una duracion de Sprint de entre 1 y 4 semanas, siendo 2 o 3 semanaslo mas habitual que encontraremos en la industria. Una de las decisiones quedebemos tomar al comenzar un proyecto o al adoptar Scrum es justamente laduracion de los Sprints. Luego, el objetivo sera mantener esta duracion cons-tante a lo largo del desarrollo del producto, lo que implicara que la duracionde una iteracion no cambie una vez que sea establecida.

Sprint Planning(Planificacion de Sprint): Al comienzo de cada Sprintse realiza una reunion de planificacion del Sprint donde seran generados losacuerdos y compromisos entre el equipo de desarrollo y el Product Ownersobre el alcance del Sprint. Esta reunion de planificacion habitualmente sedivide en dos partes con finalidades diferentes: una primera parte estrategi-ca y enfocada en el “que”, y una segunda parte tactica cuyo hilo conductorprincipal es el “como”.

Parte uno ¿Que trabajo sera realizado? Podrıamos decir que se trata de


un taller donde el Product Owner expone todos y cada uno de los PBIsque podrıan formar parte del Sprint, mientras que el equipo de desarrollorealiza todas las preguntas que crea necesarias para conocer sus detalles yası corroborar o ajustar sus estimaciones.Parte dos ¿Como sera realizado el trabajo? Durante este espacio de tiempoel equipo de desarrollo determinara la forma en la que llevara adelante eltrabajo. Esto implica la definicion inicial de un diseno de alto nivel, el cualsera refinado durante el Sprint mismo y la identificacion de las actividadesque 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 comunica-cion dentro del equipo de proyecto. Esto facilita la coordinacion de accionesentre los miembros del equipo de desarrollo y el conocimiento “en vivo” delas dependencias de las actividades que realizan. Por otro lado, se requiereademas aumentar y explicitar los compromisos asumidos entre los miembrosdel equipo de Proyectos Agiles con Scrum 48 desarrollo y dar visibilidad alos impedimentos que surjan del trabajo que esta siendo realizando y quemuchas veces nos impiden lograr los objetivos. Estos tres objetivos: 1) in-crementar la comunicacion 2) explicitar los compromisos y 3) dar visibilidada los impedimentos, son logrados mediante las reuniones diarias de Scrum(Daily Scrums). Estas reuniones tienen, como su nombre lo indica, una fre-cuencia diaria y no deberıan llevar mas de 15 minutos. Estos 15 minutos sonun timebox, es decir, que no se pueden superar.

Revision de Sprint:Al finalizar cada Sprint se realiza una reunion de revision del Sprint (SprintReview), donde se evalua el incremento funcional potencialmente entregableconstruido por el equipo de desarrollo (el “que”). En esta reunion el EquipoScrum y los Stakeholders revisan el resultado del Sprint. Cuando decimos“resultado” hablamos de “producto utilizable” y “potencialmente entrega-ble” que el los interesados utilizan y evaluan durante esta misma reunion,aceptando o rechazando ası las funcionalidades construidas.

Retrospectiva:En un metodo empırico como Scrum, la retrospeccion del equipo es el corazonde la mejora continua y las practicas emergentes. Mediante el mecanismo deretrospeccion, el equipo reflexiona sobre la forma en la que realizo su trabajoy los acontecimientos que sucedieron en el Sprint que acaba de Proyectos Agi-les con Scrum concluir para mejorar sus practicas. Todo esto sucede durantela reunion de retrospectiva. Valiendose de tecnicas de facilitacion y analisisde causas raıces, se buscan tanto fortalezas como oportunidades de mejora.Luego, el Equipo Scrum decide por consenso cuales seran las acciones de me-jora a llevar a cabo en el siguiente Sprint. Estas acciones y sus impactos se


revisaran en la proxima reunion de retrospectiva. Las Retrospectivas AgilesEn el contexto del Desarrollo Agil de Software, las retrospectivas se aplicanen distintos momentos y con distinta frecuencia (final del sprint, final delrelease,final del proyecto), incluyendo incluso a distintos grupos de involu-crados (solo el equipo de desarrollo, el equipo completo). Adicionalmente,cada equipo es distinto y tiene necesidades de aprendizajes, tiempo disponi-ble y energıas diferentes en distintos momentos. Por ello, antes de la reunionde 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 Tambien debe de-finirse la estructura de la retrospectiva, la duracion y que herramientasse usaran.

1.6. Metodologıa de la investigacion

1.6.1. Tipo de estudio

El tipo de estudio para esta investigacion es de tipo proyectivo, debi-do a que se busca especificar las caracterısticas y debilidades que presentanlos equipos de desarrollo bajo metodologıa agile durante la fase de imple-mentacion de software de requerimientos o proyectos solicitados por clientes,especıficamente en la ejecucion de retrospectivas, es decir someter a un anali-sis las caracterısticas, variables y propiedades obtenidas de unos grupos depersonas seleccionados mediante la recoleccion de informacion, para este casolos equipos de desarrollo del area de plataformas virtuales transaccionales.Ası mismo se propone implementar un producto tecnologico, especificamen-te una aplicacion web que permite ofrecer modelos de retrospectivas agilesvirtuales las cuales tienen como objetivo apoyar y suministrar las accionescorrectivas para resolver los eventos e impedimentos que se presentan en losequipos de desarrollo durante la fase de implementacion y que influyen en elcumplimiento adecuado de las entregas de requerimientos y en paralelo a laimplementacion de soluciones de software mas fiable.


1.6.2. Metodo de investigacion

El metodo de investigacion seleccionado para este estudio de investiga-cion es de tipo inductivo, mediante el cual se llevaran a cabo los siguientespasos primordiales:

Observacion y registro de los hechos y situaciones a identificar que estandirectamente relacionadas con nuestro problema de investigacion.

Analisis y clasificacion de los hechos.

Derivacion inductiva hacia conclusiones generales a partir de los hechos.

Se realizara diseno experimental con el area de portales transacciona-les que pertenece a la direccion de canales virtuales , cuyo equipo dedesarrollo esta compuesto por 20 miembros, todos con perfil de desa-rrolladores de software. Seran seleccionados para la prueba de nuestrodiseno experimentan 3 requerimientos de software: 2 de complejidadalta y 1 de complejidad media.

1.6.3. Fuentes y tecnicas de recoleccion de informacion

Las tecnicas de recoleccion de la informacion que se usaran para la des-cripcion de caracterısticas y variables relacionadas con nuestro problema deinvestigacion son:

Observacion directa sobre la ejecucion de las fases de desarrollo porparte de los equipos de desarrollo de plataformas virtuales, lıderes deproyecto y directores de desarrollo.

Fuentes Primarias: Encuestas a los integrantes de los equipos de desa-rrollo de portales transaccionales, lıderes de proyectos y directores dedesarrollo, como fuentes primarias de recoleccion de datos.

Analisis y tabulacion de datos recopilados, de tal forma que se logreobtener frecuencias distribuidas como frecuencias absolutas y relativasde las categorias de datos determinadas y medidas de tendencia centralcomo moda y media.


1.7. Alcance,limitaciones y resultados espe-

rados

1.7.1. Alcance

El alcance de este proyecto de investigacion esta descrito ası:

1. Con este proyecto de investigacion se busca mediante la implementacionde un prototipo de herramienta web apoyar y mejorar de forma efectivala realizacion y control de retrospectivas agiles dentro de los equiposdesarrollo de software de plataformas virtuales de la organizacion SHAdurante la fase de implementacion de software de los requerimientossolicitados por los clientes y en este sentido lograr fortalecer el ciclo devida de desarrollo de software que se maneja hoy en dıa.

2. Es importante resaltar que dentro del alcance se encuentra como aspec-to fundamental la medicion y verificacion de los indicadores de cumpli-miento y fiabilidad en las soluciones de software apoyadas con el usode este prototipo de aplicacion web.

3. La verificacion del impacto y resultados obtenidos con el uso del pro-totipo web (RetroWeb) sera sobre la fase de testing o pruebas de lassoluciones de software implementadas, entregadas al area encargadaconocida como “pruebas de certificacion” o popularmente como QA.

1.7.2. Limitaciones

Dentro de los lımites de este proyecto se tienen:

1. Se sometera solamente la implementacion del prototipo de herramientaweb para los equipos de desarrollo de software de las plataformas vir-tuales transaccionales que existen hoy en dıa en la organizacion SHA.

2. Se verificaran los indicadores de cumplimiento y calidad de las solucio-nes de software durante la fase de pruebas de certificacion o testing yde esta forma medir el impacto de prototipo web en el mejoramientode dichos indicadores y a su vez valorar el fortalecimiento del ciclo devida de desarrollo de software soportado hoy en dıa bajo metodologıaagile Scrum.

1.7.3. Resultados esperados

Tras el desarrollo del proyecto de investigacion, se espera:


1. Conocer las principales y dificultades que presentan los equipos de desa-rrollo que afectan el cumplimiento a los clientes de los requerimientosy proyectos de software.

2. Fortalecer el modelo de realizacion de retrospectivas agiles que se ma-neja hoy en dıa, mediante el apoyo del prototipo de herramienta webpropuesto.

3. Verificar durante la fase pruebas de certificacion el mejoramiento en elincumplimiento y fiabilidad en las soluciones de software desarrolladase implementadas.

4. Fortalecer y mejorar los indicadores de cumplimiento y fiabilidad enlas entregas de soluciones de software, entendiendose cumplimiento enentregar las soluciones en los tiempos previamente pactados y planeadosy fiabilidad como reducir la cantidad de inidencias detectadas en laspruebas de certificacion de dichas soluciones de software.


1.8. Estudio de sistemas previos

Entre los sistemas que comparten la misma necesidad enncontramos -etromat”, el cual es un sitio web cuya razon de ser es ofrecer una coleccion deactividades para retrospectivas. Su creador principal Corinna Baldauf propo-ne una estraegaia similar donde se pueden generar modelos de retrospectivascuyo diseno esta enfocado en actividades estrategicas y estructuradas con elobjetivo se ofrecer a los usuarios formas de solucionar problematicas o dificul-tades que se presenten en los equipos de desarrollo de software que trabajencon metogologıa agile y a su vez proporcionar una base solida para mejorarla efectividad en cada iteracion. Este producto Retromat”tiene como inspi-racion darle un giro diferente a la forma de ejecutar retrospectivas agiles, sinduda alguna se percibe en la industria de software y en su interaccion conmetodologias agiles que las retrospectivas son tomadas como una forma repe-titiva de discrutir los mismos temas con las mismas conclusiones una y otravez, con Retromat”se busca cambiar el modelo de generar retrospectivas deuna forma mas estrategica y dinamica basada en actividaes ludico-cognitivas.Se puede consultar en: https://plans-for-retrospectives.com/en/?id=52-110-74-88-45


1.9. Cronograma y Presupuesto

1.9.1. Cronograma

Figura 1.5: Cronograma de trabajo


1.9.2. Presupuesto

Figura 1.6: Presupuesto de Proyecto

Parte II

DESARROLLO DE LAINVESTIGACION

24

Capıtulo 2

EMPRESA

2.1. Introducion

SHA es una compania cuya razon de ser es ofrecer a nuestros clientes ysus clientes los mejores servicios de tecnologıas de informacion, mediante elapoyo y trabajo de todos sus colaboradores siempre centra sus esfuerzos enapalancar las estrategias de negocio de sus clientes en su mayoria del sectorfinanciero, a traves de las evoluciones tecnologicas, el desarrollo de solucionesde software e innovcion digital. Toda iniciativa o proyecto digital debe estaralineado en base a la mision vision, objetivos estrategicos y productos/ser-vicios que conforman el modelo de negocio de la compania sobre la cual sepretende ejecutar dicha iniciativa o proyecto.

2.2. Mision y vision

2.2.1. Mision

Somos el Centro de Servicios Compartidos que provee, administra y ges-tiona integralmente servicios de tecnologıas de informacion , de manera efi-ciente y segura, ofreciendo altos estandares de calidad a nuestros clientes ya sus clientes, generando valor a nuestros accionistas y colaboradores.

2.2.2. Vision

Ser el aliado de la estrategia digital y los servicios compartidos de nuestrosclientes comerciales y financieros.

25

CAPITULO 2. EMPRESA 26

2.3. Organigrama

Figura 2.1: Estructura Oranizacional SHA

2.4. Objetivos Estrategicos

CULTURA DE CALIDAD Y SERVICIO Permanente busqueda de laexcelencia en lo que hacemos, a todo nivel, con resultados sobresalientes, quenos permita ser reconocidos como la mejor opcion para nuestros clientes yaccionistas.

Crear servicios para nuestros clientes y sus clientes promoviendo lainvestigacion, la gestion de ideas e iniciativas.

Mejorar los servicios existentes con el fin de lograr la evolucion de loscanales administrados.

Innovar en procesos de la Organizacion buscando eficiencia, oportuni-dad y calidad en los resultados.

COLABORADORES APASIONADOS Y COMPETENTES Equipo alta-mente productivo, en permanente desarrollo, motivado y con las habilidadesnecesarias para asegurar el logro de los objetivos de la companıa.

CAPITULO 2. EMPRESA 27

Desarrollar y fortalecer en los colaboradores las competencias con enfa-sis en la orientacion al servicio para el logro de los resultados de laorganizacion.

Construir un ambiente de trabajo que nos permita estar motivados yapasionados por lo que hacemos, sintiendo orgullo por nuestra empresa.

Desarrollar integralmente a nuestros colaboradores contribuyendo ensu crecimiento personal y en el bienestar de sus familias.

2.5. Productos y Servicios

Se describen los principales productos y servicios de negocio que apalancala compania SHA.

Figura 2.2: Productos y servicios SHA

Capıtulo 3

RECOLECCION YTABULACION DE DATOS

3.1. Introducion

La recoleccion de datos se refiere al uso de una gran variedad de tecnicasy herramientas utiles para recoger datos que permitan obtener informacionrelevante sobre el problema de investigacion que se este abordando. Existen2 tipos de fuentes de recoleccion de datos: las fuentes primarias y las fuentessecundarias. La informacion de fuentes primarias es obtenida por contac-to directo con el sujeto de estudio por medio de observacion, cuestonarios,encuestas,entrevistas,etc. La informacion de fuentes secundarias es recogidaa partir de investigaciones ya hechas por otros ivestigadores con propositosdiferentes.

3.2. Recoleccion de Datos

La recopilacion de datos fue realizada a traves de la fuente primaria.encuestas”, que fueron llevadas a cabo en una muestra de 14 personas distri-buidas entre lıderes y analistas de desarrollo de software del area de portalestransaccionales de la organizacion SHA. A continuacion las evidencias de losdatos recopilados:

28

CAPITULO 3. RECOLECCION Y TABULACION DE DATOS 29

Figura 3.1: Cumplimiento de requerimientos

Figura 3.2: Impedimentos en Sprints de Desarrollos de Software


Figura 3.3: Tiempos de gestion tareas de desarrollo

3.3. Tabulacion de Datos

Se presenta la tabulacion de los datos recopilados en la muestra de 14personas(lıderes y analistas de desarrollo) a las que se les aplico como tecnicade recoleccion encuestas para identificar principalmente los factores proclivesen el incumplimiento de entregas de soluciones de software. A continuacionfrecuencias absolutas y relativas de los datos recopilados:

Figura 3.4: Frec.Absoluta del cumplimiento de requerimientos


Figura 3.5: Frec.Relativa del cumplimiento de requerimientos

Figura 3.6: Frec.Absoluta impedimentos en desarrollos de software


Figura 3.7: Frec.Relativa impedimentos en desarrollos de software

Figura 3.8: Frec.Absoluta tareas con mayor gestion durante fase de construc-cion


Figura 3.9: Frec.Relativa tareas con mayor gestion durante fase de construc-cion

Capıtulo 4

ARQUITECTURAEMPRESARIAL

4.1. Introducion

Las organizaciones necesitan adaptarse cada vez mas rapido y anticiparsea las cambiantes necesidades de los clientes y los objetivos comerciales. Estanecesidad influye en toda la cadena de actividades de una empresa, desdela estructura organizativa hasta la infraestructura de red. ¿Como puedescontrolar el impacto de estos cambios? La arquitectura puede ser la respuesta.

La arquitectura es un conjunto consistente de principios, metodos y mo-delos que se utilizan en el diseno y la realizacion de la estructura organizativa,los procesos comerciales, los sistemas de informacion y la infraestructura. Sinembargo, estos dominios no se abordan de forma integrada, lo que dificultajuzgar los efectos de los cambios propuestos. Cada dominio habla su propioidioma, dibuja sus propios modelos y utiliza sus propias tecnicas y herramien-tas. La comunicacion y la toma de decisiones entre dominios se ve seriamenteafectada.

ArchiMate proporciona esta integracion, es un lenguaje de modelado dearquitectura empresarial y tecnicas de visualizacion que representan estosdominios y sus relaciones y que permite el analisis y la visualizacion de laarquitectura dentro y entre los dominios de negocios. El lenguaje Archimatesirve para dise nar Arquitecturas Empresariales que faciliten la adopcion detecnologıa en las empresas, vinculando los procesos de negocio con los activostecnoloogicos. facilita la administracion de proyectos de tecnologıa y cambioorganizacional, permitiendo que los expertos de negocio puedan priorizar losrequerimientos de alto nivel y generar proyectos que impacten positivamentela organizacion.

34

CAPITULO 4. ARQUITECTURA EMPRESARIAL 35

4.2. ADM - Archimate

El lenguaje ArchiMate, como se describe en este estandar tecnico, com-plementa a TOGAF en que proporciona un conjunto de conceptos indepen-diente del proveedor, incluida una representacion grafica, que ayuda a crearun modelo consistente e integrado que se puede representar en la forma devistas TOGAF. TOGAF en tarminos simples es una herramienta para asis-tir en la aceptacion, creacion, uso y mantenimiento de arquitecturas. Basadoen un modelo iterativo de procesos apoyado por las mejores practicas y unconjunto reutilizable de activos arquitectonicos existentes. Se puede utilizarpara desarrollar una amplia variedad de arquitecturas empresariales; ademascomplementa y se puede usar en conjunto con otros marcos de referencia queestan basados en entregables especıficos para sectores particulares. La clavede TOGAF es el metodo de desarrollo de la arquitectura (ADM), para desa-rrollar una arquitectura empresarial que aborda las necesidades de negocio.La estructura del lenguaje principal ArchiMate se corresponde estrechamentecon 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 uni-dades de negocios. Esta capa .ofrece productos y servicios a los clientes quese realizan en la organizacion mediante procesos comerciales realizados por


actores y roles de negocios. El aspecto estructural en la capa de negocio serefiere a la estructura estatica de una organizacion,en terminos de las entida-des que conforman la organizacion y sus relaciones. Se distinguen dos tiposde entidades: Las entidades activas que son los sujetos (por ejemplo, actoresempresariales o roles comerciales) que realizan funciones como procesos ofunciones empresariales (capacidades). Los actores empresariales pueden serpersonas individuales (por ejemplo, clientes o empleados), sino tambien gru-pos de personas como (Unidades de la organizacion) y recursos que tienenun estatus permanente (o al menos a largo plazo) dentro de las organiza-ciones. Ejemplos toicos de estos ultimos son un departamento u unidad denegocio. Las entidades pasivas (objetos de negocio) que son manipuladas porcomportamientos tales como procesos o funciones. Estas entidades pasivasrepresentan los conceptos importantes en los que el negocio piensa en undominio.

Figura 4.2: Metamodelo capa de negocios

Las descripciones arquitectonicas se centran en la estructura, lo que sig-nifica que las interrelaciones de las entidades dentro de una organizacionjuega un papel importante. Para hacer esto explıcito, el concepto de negocio


colaboracion ha sido introducida. Las colaboraciones comerciales se han ins-pirado en colaboraciones como se define en el estandar UML 2.0, aunque lascolaboraciones de UML se aplican a componentes en la capa de aplicacion.Ademas, el concepto de colaboracion empresarial ArchiMate tiene una gransemejanza con el concepto de comunidad”tal como se define en el lenguajeEnterprise de RM-ODP , ası como al concepto de ”punto de interaccion”,definido en Amber [11] como el lugar donde las interacciones ocurren. Elconcepto de interfaces de negocios se introduce para modelar explıcitamenteel (logico o fısico) ubicaciones o canales donde se puede acceder a los servi-cios que una funcion ofrece al entorno. El mismo servicio se puede ofrecer envarias interfaces diferentes; por ejemplo, por correo, por telefono, o a travesde Internet. A diferencia del modelado de aplicaciones, es poco comun en losnegocios actuales enfoques de modelado de capas para reconocer el conceptode interfaz de negocios.

La tabla que a continuacion se muestra, da un acercamiento de los con-ceptos en la capa de negocio, con sus denotaciones:


Elemento Definicion Notacion

Actor de NegocioUna entidad de negocio que es capazde realizar un comportamiento.

Rol de Negocio

La responsabilidad de realizar uncomportamiento especıfico, al cualun actor puede ser asignado, o laparte que un actor juega en una ac-cion o evento particular.

Colaboracion deNegocio

Una agregacion de dos o mas Ele-mentos de estructura activos inter-nos de negocio, que trabajan juntospara realizar un comportamiento co-lectivo

Interfaz de NegocioUn punto de acceso donde un servi-cio de negocio esta disponible al en-torno

LocalizacionUn lugar o posicion donde elementosde estructura pueden ser ubicados opuede realizarse un comportamiento

Objeto de NegocioRepresenta un concepto usado den-tro de un dominio de negocio parti-cular.

Proceso de Negocio

Representa una secuencia de com-portamientos de negocio que lograun resultado especıfico tal como unconjunto de productos o servicios denegocio definidos

Funcion de Negocio

Una coleccion de comportamientosde negocio basada en un conjunto se-leccionado de criterios (tıpicamenterecursos y/o competencias requeri-das), estrechamente alineados a unaorganizacion, pero no necesariamen-te explıcitamente gobernados por laorganizacion.

Interaccion de Ne-gocio

Una unidad de comportamiento co-lectivo de negocio realizada por (acolaboracion de) dos o mas roles denegocio.

Sigue en la pagina siguiente.



Evento de Negocio

Un elemento de comportamiento denegocio que denota un cambio de es-tado organizacional. Puede originar-se y ser resuelto dentro o fuera de laorganizacion

Servicio de NegocioRepresenta un comportamiento denegocio explıcitamente definido quees expuesto

RepresentacionRepresenta una forma perceptible dela informacion que lleva consigo unobjeto de negocio

Significado

Representa el conocimiento o expe-riencia presente en, o la interpreta-cion dada a un elemento central enun contexto particular

ValorRepresenta el valor relativo, benefi-cio, utilidad o importancia de un ser-vicio de negocio o producto

Producto

Representa una coleccion coheren-te de servicios y/o elementos de es-tructura pasivos acompanados porun contrato/conjunto de acuerdos, elcual es ofrecido como un todo a losclientes (internos o externos)

Contrato

Representa una especificacion for-mal o informal de un acuerdo entreun proveedor y un consumidor queespecifica los derechos y obligacionesasociados con un producto y estable-ce parametros para interaccion fun-cionales y no-funcionales.

Cuadro 4.1: Elementos de capa de negocio


4.2.2. Capa de Aplicacion:

El metamodelo de la capa de aplicacion y sus relaciones estan inspira-dos en gran parte en el estandarUML 2.0, por ser un lenguaje dominantey el estandar para describir aplicaciones de software. Cada concepto en ellenguaje puede tener relaciones de composicion, agregacion y especializacioncon conceptos del mismo tipo. Ademas, existen relaciones indirectas que pue-den derivarse.

Figura 4.3: Metamodelo capa de aplicacion


El concepto estructural principal para la capa de aplicacion es el compo-nente de aplicacion. Este concepto se utiliza para modelar cualquier entidadestructural en la capa de aplicacion: no solo componentes de software (reutili-zables) que pueden ser parte de una o mas aplicaciones, sino tambien aplica-ciones completas de software, sub-aplicaciones o sistemas de informacion. Esmuy similar al UML 2.0 sin embargo nuestro concepto de componente modelaestrictamente el aspecto estructural de una aplicacion: su comportamiento esmodelado por una relacion explıcita con los conceptos conductuales. Tambienen la arquitectura de la aplicacion, las interrelaciones de los componentes sonun ingrediente esencial. Por lo tanto, tambien introducimos el concepto decolaboracion de aplicaciones aquı,de

nido como un colectivo de componentes de aplicacion que realizan inter-acciones de aplicaciones. En el sentido puramente estructural, una interfazde aplicacion es el canal (logico) a traves del cual se puede acceder a losservicios de un componente. En un sentido mas amplio (tal como se utilizaen,entre otros, el UML 2.0), una interfaz de aplicacion de algunas carac-terısticas de comportamiento elementales: de el conjunto de operaciones yeventos que se proporcionan por el componente, o los que se requieren desdeel entorno, describiendo la funcionalidad de un componente. Se puede haceruna distincion entre una interfaz proporcionada y una interfaz requerida. Elconcepto de interfaz de aplicacion se puede utilizar para modelar interfacesde aplicacion a aplicacion que ofrecen servicios de aplicaciones internas yaplicaciones a interfaces de negocio (y / o interfaces de usuario)que ofrecenservicios de aplicaciones externas. Tambien en la capa de aplicacion, distin-guimos la contraparte pasiva del componente, que llamamos objeto de datos.Este concepto se utiliza de la misma manera que los objetos de datos (o tiposde objetos) en enfoques de modelado de datos bien conocidos, especialmenteel concepto de clase en los diagramas de clases de UML. Un objeto de datospuede ser visto como una representacion de un objeto de negocio, como unacontrapartida del concepto de representacion en la capa de negocio.


La tabla que a continuacion se mostrara, da un acercamiento de los con-ceptos en la capa de aplicacion, con sus definiciones:


Componentes deaplicacion

Una parte de sistema de software,modular, desplegable y reemplaza-ble,que encapsula sus datos y expo-ne su comportamiento a traves desusinterfaces.

Colaboracion deaplicacion

Un agregado de dos o mas compo-nentes de aplicaciones que trabajanjuntos para optimizar el comporta-miento colectivo.

Interfaces de apli-cacion

Un punto de acceso donde un servi-cio de aplicacion esta disponible pa-ra usuarios u otras aplicaciones.

Objeto de datosUn elemento pasivo, sustituible paraprocesos automatizados.

Funcion de aplica-cion

Un comportamiento de elementosque automatizan comportamientosde grupo que pueden ser optimizadospor un componente de aplicacion.

Interaccion de apli-cacion

Un elemento de comportamiento quedescribe el comportamiento de unacolaboracion de aplicacion.

Servicio de aplica-cion

Un servicio que expone un compor-tamiento automatizado.

Cuadro 4.2: Elementos de Capa de Aplicacion


4.2.3. Capa de Tecnologıa:

El nodo es el concepto principal clave para la capa tecnologica, este con-cepto comparte el mismo significado que en UML 2.0. Es estrictamente usadopara modelos que representan los aspectos estructurales de un sistema. Sucomportamiento es modelado por una relacion explıcita de conceptos conduc-tuales. Una Interface de infraestructura, es el acceso a los servicios ofrecidospor el nodo desde otros nodos o componentes de la capa de aplicacion. Existendos tipos de nodos: dispositivos y sistemas de software,ambos son tomadasde UML2.0. Un dispositivo es el modelo de un recurso fısico, sobre el cual sepueden desplegar artefactos para su ejecucion. Tıpicamente, un nodo consisteun numero de sub-nodos; por ejemplo, un dispositivo tal como un servidor yun 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 estan princi-palmente formadas por comunicaciones de infraestructura. Los modelos decomunicacion es la relacion entre dos o mas nodos, a traves de estos nodosse puede intercambiar informacion. Las realizacion fısica de las rutas de co-municacion son modeladas con una red y un medio de comunicacion entredos o mas dispositivos. El cuadro a continuacion, brinda una vision generalde los conceptos de la capa de tecnologıa con sus de

nociones:



NodoRecurso computacional sobre el cualpueden almacenarse o desplegarseartefactos para su ejecucion

DispositivoRecurso de hardware sobre el cualpueden almacenarse o desplegarseartefactos para su ejecucion

RedMedio de comunicacion entre dos omas dispositivos.

Ruta de comunica-cion

Un enlace entre dos o mas nodos, atraves del cual estos nodos puedenintercambiar datos.

Interfaz de Infraes-tructura

Un punto de acceso donde los servi-cios de infraestructura ofrecidos porun nodo pueden ser accedidos porotros nodos y componentes de laaplicacion.

Software del siste-ma

Un entorno de software para tiposespecıficos de componentes y objetosque se despliegan en el en formadeartefactos.

Funcion de Infraes-tructura

Un elemento de comportamiento queagrupa el comportamiento de infra-estructura que puede ser realizadopor un nodo.

Servicio de Infraes-tructura

Una unidad de funcionalidad vi-sible externamente, proporcionadapor uno o mas nodos, expuesta atraves de interfaces bien denidas y significativa para el entorno.

Artefacto

Una pieza fısica de datos que se uti-liza o se produce en un proceso dedesarrollo de software, o mediante eldespliegue y la operacion de un sis-tema.

Cuadro 4.3: Elementos de Capa de Tecnologıa


4.2.4. Capa de Motivacion:

Los conceptos de motivacion se utilizan para modelar las motivaciones, orazones, que subyacen en el diseno o cambio de alguna arquitectura empre-sarial. Estas motivaciones influyen, orientan y limitan el diseno. Es esencialcomprender los factores, que a menudo son referidos como conductores, queinfluyen en los elementos motivacionales. Pueden originarse desde dentro ofuera de la empresa. Los conductores internos, tambien llamados preocupa-ciones, estan asociados con los stakeholders, que pueden ser algun ser humanoindividual o algun grupo de seres humanos, como un equipo de proyecto, em-presa o sociedad. La siguiente fıgura muestra el modelo de la capa motivacio-nal. En el cual se aprecia que incluye motivaciones o intenciones actuales porejemplo Objetivos, prinicipios, requerimientos y restricciones y los orıgenesde esas intenciones (stakeholders, conductores y evaluaciones).

Figura 4.5: Metamodelo capa de motivacion


La siguiente tabla nos da una vision general de los conceptos motivacio-nales, con sus definiciones.


Stakeholder

El rol de una persona, equipo u orga-nizacion que representan sus intere-ses o preocupaciones relativas al re-sultado de la arquitectura

Driver.Algo que crea, motiva y alimenta elcambio en una organizacion.

Assessment.La salida de algun analisis de algundriver.

Goal.Un estadonal que un stakeholder pretende lo-grar.

Requirement.Una declaracion de necesidad tieneque ser realizada por un sistema.

Constraint.Una restriccion en la forma en que elsistema es desarrollado.

Principle.Una propiedad normativa de todoslos sistemas en un contexto dado, ola forma en que se realizan.

Cuadro 4.4: Elementos de Capa de Motivacion

Capıtulo 5

NEGOCIO

5.1. Introducion

Las descripciones arquitectonicas se centran en la estructura, lo que sig-nifica que las interrelaciones de las entidades dentro de una organizacionjuegan un papel importante. Para hacer esto explıcito, el concepto de cola-boracion de negocio ha sido introducido. Las colaboraciones empresarialesse han inspirado en colaboraciones como se define en el estandar UML 2.0,aunque las colaboraciones UML se aplican a componentes en la capa de apli-cacion. Ademas, el concepto de colaboracion de negocio en ArchiMate tieneun fuerte parecido al concepto de comunidad como se define en el LenguajeEmpresarial RM-ODP, ası como al concepto de ”punto de interaccion”, de

nido en Ambar como el lugar donde las interacciones ocurren. El conceptode interfaces de negocio es presentado para explıcitamente modelar lo logicoo fısico,de las posiciones o canales donde se puede acceder a los serviciosque una funcion ofrece al medio ambiente. Pueden ofrecer el mismo servicioen varios interfaces diferentes; por ejemplo: por correo,por telefono, o porla Internet. En contraste con el modelado de uso, es raro en los negociosactuales reconocer el concepto de interfaz de negocio. En contraste con losconceptos estructurales y de comportamiento, que se re

eren a la perspectiva operacional de una empresa, los conceptos infor-mativos se centran en lo que podrıamos llamar la perspectiva ıntencional”.Proporcionan una manera de vincular el lado operativo de una organizaciona los objetivos de negocio, y a los productos que una organizacion ofrece asus clientes. Nosotros tambien clasificamos el producto en si mismo, juntocon el concepto de contrato correspondiente, como conceptos.

47

CAPITULO 5. NEGOCIO 48

5.2. Punto de Vista de Organizacion

El punto de vista de la Organizacion se centra en la organizacion (interna)de una empresa, un departamento, una red de empresas, o de otra entidadorganizacional. Es posible presentar modelos en este punto de vista comodiagramas de bloques anidados, pero tambien de una manera mas tradicional,como graficos. El punto de vista de la organizacien es muy util para identi

car las competencias, autorida y responsabilidades en una organizacion.

5.2.1. Modelo

Figura 5.1: Metamodelo de oranizacion


5.2.2. Caso de Estudio

Figura 5.2: Punto de vista organizacion


5.3. Punto de Vista de Cooperacion de Actor

El punto de vista de la cooperacion actor se centra en las relaciones de losactores entre sı y su entorno. Un ejemplo comun de esto es el ”diagrama decontexto”, que posiciona una organizacion en su entorno, consiste en partesexternas tales como clientes, proveedores y otros socios comerciales. Es muyutil para determinar dependencias externas y colaboraciones y mostrar lacadena de valor o red en la que actua el actor. Otro uso importante delpunto de vista de la Cooperacion de Actor es mostrar como una serie deactores empresariales y / o componentes de la aplicacion realizan juntos unproceso de negocio. Por lo tanto, en este punto de vista, pueden ocurrir tantolos agentes comerciales como los roles y componentes de la aplicacion.

5.3.1. Modelo

Figura 5.3: Metamodelo cooperacion de Actor



Figura 5.4: Punto de vista cooperacion de Actor RetroWeb


5.4. Punto de Vista de Funcion de Negocio

El punto de vista funcion de negocio muestra las principales funcionesde negocio de una organizacion y sus relaciones en terminos de los flujos deinformacion, valor o bienes entre ellos. Las funciones de negocio se utilizanpara representar los aspectos mas estables de una empresa en terminos delas actividades que lleva a cabo, independientemente de los cambios organi-zativos o los avances tecnologicos. Por lo tanto, la arquitectura de la funcioncomercial de las empresas que operan en el mismo mercado a menudo mues-tran similitudes cercanas. Por consiguiente, el punto de vista de la funcionempresarial ofrece una vision de alto nivel en las operaciones generales dela empresa, y puede utilizarse para identificar las competencias necesarias opara estructurar una organizacion de acuerdo con sus principales actividades.

5.4.1. Modelo

Figura 5.5: Metamodelo funcion de Negocio



Figura 5.6: Punto de vista funcion de Negocio RetroWeb


5.5. Punto de Vista de Proceso de Negocio

El punto de vista de proceso de negocios se utiliza para mostrar la estruc-tura y composicion de alto nivel de uno o mas procesos de negocio. Junto a lospropios procesos, este punto de vista contiene otros conceptos directamenterelacionados, tales como:

La asignacion de los procesos de negocio a las funciones, lo que da unaidea de las responsabilidades de los actores asociados.

La informacion utilizada por el proceso de negocio.

5.5.1. Modelo

Figura 5.7: Metamodelo proceso de Negocio



Figura 5.8: Punto de vista proceso de Negocio RetroWeb


5.6. Punto de Vista Cooperacion Proceso de

Negocio

El punto de vista de Cooperacion de Procesos de Negocio se utiliza paramostrar las relaciones de uno o mas procesos empresariales entre sı y / o consu entorno. Puede ser utilizado para crear un diseno de alto nivel de los pro-cesos empresariales dentro de su contexto y proporcionar un administradoroperacional responsable para uno o mas de estos procesos con conocimientode sus dependencias.

5.6.1. Modelo

Figura 5.9: Metamodelo cooperacion de proceso de Negocio



Figura 5.10: Punto de vista cooperacion de proceso de Negocio RetroWeb


5.7. Punto de Vista deProducto

El punto de vista producto muestra el valor que estos productos ofrecena los clientes u otras partes externas implicadas y muestra la composicion deuno o mas productos en funcion de servicios (comerciales o de aplicacion), y elcontrato(s) asociado(s) u otros acuerdos. Tambien se puede usar para mostrarlas interfaces (canales) a traves de las cuales este producto es ofrecido, y loseventos asociados con el producto. Un punto de vista del producto se utilizatıpicamente en el desarrollo de productos para disenar un producto mediantela composicion de servicios existentes o mediante nuevos servicios que tienenque ser creados para este producto, dado el valor que un cliente espera de el.Eso puede servir como entrada para los arquitectos de procesos de negocio yotros que necesitan dise nar el proceso y TICs que realizan estos productos.

5.7.1. Modelo

Figura 5.11: Metamodelo cooperacion de proceso de Negocio



Figura 5.12: Punto de vista producto RetroWeb

Capıtulo 6

APLICACION

6.1. Introducion

El concepto estructural principal para la capa de aplicacion es el compo-nente de aplicacion. Este concepto se utiliza para modelar cualquier entidadestructural en la capa de aplicacion: no solo componentes de software (reutili-zables) que pueden ser parte de una o mas aplicaciones, sino tambien aplica-ciones completas de software, sub-aplicaciones o sistemas de informacion. Esmuy similar al UML 2.0 sin embargo nuestro concepto de componente modelaestrictamente el aspecto estructural de una aplicacion: su comportamiento esmodelado por una relacion explıcita con los conceptos conductuales. Tambienen la arquitectura de la aplicacion, las interrelaciones de los componentes sonun ingrediente esencial. Por lo tanto, tambien introducimos el concepto decolaboracion de aplicaciones aquı,definido como un colectivo de componentesde aplicacion que realizan interacciones de aplicaciones. En el sentido pura-mente estructural, una interfaz de aplicacion es el canal (logico) a traves delcual se puede acceder a los servicios de un componente. En un sentido masamplio (tal como se utiliza en, entre otros, el UML 2.0), una interfaz de apli-cacion define algunas caracterısticas de comportamiento elementales: deeneel conjunto de operaciones y eventos que se proporcionan por el componente,o los que se requieren desde el entorno, describiendo la funcionalidad de uncomponente.Se puede hacer una distincion entre una interfaz proporcionaday una interfaz requerida. El concepto de interfaz de aplicacion se puede utili-zar para modelar interfaces de aplicacion a aplicacion que ofrecen servicios deaplicaciones internas y aplicaciones a interfaces de negocio (y / o interfacesde usuario) que ofrecen servicios de aplicaciones externas.

60

CAPITULO 6. APLICACION 61

6.2. Punto de Vista de Cooperacion de Apli-

cacion

El punto de vista de la cooperacion de aplicacion describe las relacionesentre los componentes de las aplicaciones o en terminos de los flujos de infor-macion o en terminos de los servicios que ofrecen y utilizan. Este punto devista se suele utilizar para crear una vision general del entorno de aplicacionde una organizacion. Este punto de vista tambien se utiliza para expresarla cooperacion (interna) o orquestacion de servicios que juntos apoyan laejecucion de un proceso de negocio.

6.2.1. Modelo

Figura 6.1: Metamodelo Cooperacion de Aplicacion



Figura 6.2: Punto de Vista Cooperacion de Aplicacion


6.3. Punto de Vista de Comportamiento de

Aplicacion

El punto de vista del comportamiento de la aplicacion describe el compor-tamiento interno de una aplicacion; Por ejemplo, como se realiza uno o masservicios de aplicacion. Este punto de vista es util para disenar el comporta-miento principal de las aplicaciones, o en la identificacion de la superposicionfuncional entre las diferentes aplicaciones.

6.3.1. Modelo

Figura 6.3: Metamodelo Comportamiento de Aplicacion



Figura 6.4: Punto de vista Comportamiento de Aplicacion


6.4. Punto de Vista de Estructura de Aplica-

cion

El punto de vista de la estructura de la aplicacion muestra la estructurade una o mas aplicaciones o componentes. Este punto de vista es util paradisenar o comprender la estructura principal de aplicaciones o componentes ylos datos asociados; Por ejemplo, para descomponer la estructura del sistemaen construccion, o para identi

car componentes de aplicaciones heredados que son adecuados para mi-gracion/integracion.

Figura 6.5: Metamodelo Comportamiento de Aplicacion



Figura 6.6: Punto de vista Estructura de Aplicacion


6.5. Punto de Vista de Uso de Aplicacion

El punto de vista uso de la aplicacion describe como se utilizan las aplica-ciones para apoyar uno o varios procesos empresariales y como son utilizadospor otras aplicaciones. Se puede utilizar en el diseno de una aplicacion me-diante la identificacion de los servicios necesarios para los procesos de negocioy otras aplicaciones, o dise nando procesos de negocio que describen los ser-vicios que estan disponibles. Ademas, puesto que identi

ca las dependencias de los procesos de negocio en las aplicaciones, puedeser util para los administradores operacionales responsables de estos procesos.

6.5.1. Modelo

Figura 6.7: Metamodelo Uso de Aplicacion



Figura 6.8: Proceso de registrar requerimiento


Figura 6.9: Proceso de crear y asociar equipos a requerimiento

Figura 6.10: Proceso creacion de Sprint de desarrollo


Figura 6.11: Proceso creacion de tareas de desarrollo en Sprint

Figura 6.12: Proceso asociar impedimentos a tareas de desarrollo en Sprint


Figura 6.13: Proceso de generar retrospectiva virtual para impedimentos aso-ciados

Capıtulo 7

MOTIVACION

7.1. Introducion

Los conceptos de motivacion se utilizan para modelar las motivaciones,o razones, que subyacen al diseno o cambio de alguna arquitectura empre-sarial. Estas motivaciones influyen, orientan y limitan el diseno. Es esencialcomprender los factores, a menudo referidos como conductores, que influyenen los elementos motivacionales. Pueden originarse desde dentro o fuera de laempresa. Los conductores internos, tambien llamados preocupaciones, estanasociados con los stakeholders, que pueden ser un ser humano o algun grupode seres humanos, como un equipo de proyecto, empresa o sociedad. Ejem-plos de estos factores internos son la satisfaccion del cliente, el cumplimientode la legislacion o la rentabilidad. Es comun que las empresas realicen unaevaluacion de estos conductores; Por ejemplo, usando un analisis SWOT,con el fin de responder de la mejor manera. Las motivaciones reales estanrepresentadas por objetivos, principios, requisitos y limitaciones. Los objeti-vos representan algun resultado deseado - o final - que un interesado quierelograr; Por ejemplo, aumentando la satisfaccion del cliente en un 10 por cien-to. Los principios y requisitos representan las propiedades de soluciones - omedios - para alcanzar los objetivos. Los principios son pautas normativasque guardan el disenoo de todas las soluciones posibles en un contexto dado.Por ejemplo, el principio. Los datos deberan ser almacenados solo una vez-epresenta un medio para lograr el objetivo de consistencia en los datos 2seaplica a todos los posibles disenos de la arquitectura de la organizacion. Losrequisitos representan declaraciones formales de necesidad, expresada por losstakeholders, que tiene que cumplir la arquitectura o solucion.

72

CAPITULO 7. MOTIVACION 73

7.2. Punto de Vista stakeholder

7.2.1. Modelo

Figura 7.1: Metamodelo de los stakeholders



Figura 7.2: Punto de vista stakeholders de RetroWeb


7.3. Punto de Vista de Realizacion de Obje-

tivos

7.3.1. Modelo

Figura 7.3: Metamodelo de realizacion de objetivos



Figura 7.4: Punto de vista realizacion de objetivos de RetroWeb


7.4. Punto de Vista de Motivacion

7.4.1. Modelo

Figura 7.5: Metamodelo motivacional



Figura 7.6: Punto de vista motivacional RetroWeb

Capıtulo 8

METODOLOGIA SCRUM

8.1. Introducion

Se utilizo metogologıa agile, debido a la retroalimentacion que un proyec-to de este tipo requiere. Una de las ventajas de trabajar con esta metogologıaes que se permite tener respuestas a los cambios que surgen durante el trans-curso del proyecto, en pro de implementar software con valor y funcional,partiendo de la cultura de poder hacer seguimientos diarios o dailys, ejecutarunas review para controlar que todo este encamidado al resultado esperado.Cada iteracion(sprint) del proyecto ayuda a mitigar los errores que puedenencontrarse en la fase de desarrollo y a su vez optimizar funcionalidades re-queridas. De esta forma ası se finalicen historias de usuarios como por ejemploel modulo de iniciar sesion se podra realizar la entrega de este modulo ya quees independiente del resto.

79

CAPITULO 8. METODOLOGIA SCRUM 80

8.2. Historias de Usuarios

Historias de usuarios definidas para la implementacion del prototipo web:

NombreHUO1 - Crud de requerimientos de soft-ware

Como Lıder de desarrollo - Scrum master

QuieroRegistrar requerimientos de software yasignar a los equipos de desarrollo previa-mente creados

Para que pueda

Controlar y verificar el avance de unrequerimiento de software.

Definir los sprint de desarrollo nece-sarios para la implementacion de unrequerimiento de software.

Cuadro 8.1: Historia de Usuario HUO1 - Crud de reque-rimientos de software

Nombre HUO2 - Crud equipos de desarrolloComo Lıder de desarrollo - Scrum master

QuieroRegistrar los equipos de desarrollo de soft-ware involucrados.

Para que puedaControlar el registro de los equipos dedesarrollo que estaran involucrados en lassoluciones de software

Cuadro 8.2: Historia de Usuario HUO2 - Crud equiposde desarrollo


Nombre HUO3 - Crud de sprints de desarrolloComo Lıder de desarrollo - Scrum master

QuieroCrear y registrar los Sprint de desarrolloa ejecutar por cada equipo de desarrollopara un determinado requerimiento.

Para que puedaIdentificar los sprint de desarrollo que eje-cutaran los equipos de desarrollo para lasolucion de requerimientos.

Cuadro 8.3: Historia de Usuario HUO3 - Crud de sprintsde desarrollo

NombreHUO4 - Registrar y gestionar tareas dedesarrollo

Como Lıder de desarrollo - Scrum master

QuieroRegistrar las tareas asignadas a ejecutardurane un determinado sprint y asignadasa un equipo de desarrollo.

Para que pueda

Controlar las tareas definidas aejecutar durante un determinadosprint, para pode asociar impedi-mentos.

Consultar el estado de las tareas re-gistradas conforme a los impedimen-tos que les sean asociados..

Cuadro 8.4: Historia de Usuario HUO4 - Registrar y ges-tionar tareas de desarrollo


Nombre HUO5 - Asociar impedimentos a tareasComo Lıder de desarrollo - Scrum master

Quiero

Registrar los impedimentos y dificultadesasociadas a las tareas asignadas a un equi-po de desarrollo durante el transcurso deun sprint.

Para que puedaControlar los impedimentos obenidos yevidenciados en los equipos de desarrollodurante la ejecucion de tareas.

Cuadro 8.5: Historia de Usuario HUO5 - Registar y con-trolar impedimentos de tareas

Nombre HUO6 - Generar de retrospectivas

ComoColaboradores - lıder de desarrollo - scrummaster

Quiero

Generar modelos de retrospectivas al fina-lizar cada Sprint en base a los impedimen-tos evidenciados y asociados a las tareasejecutadas o por ejecutar de un equipo ocelula de desarrollo.

Para que pueda

Ofrecer modelo o tecnica de retrospectivaque pueden ejecutar los equipos de desa-rrollo en base a los impedimentos eviden-ciados para la ejecucion de las tareas defi-nidas en cada Sprint, con el objetivo de lo-grar la mejora continua y poder solucionarel requerimiento en los tiempos pactadosy con la fiabilidad requerida.

Cuadro 8.6: Historia de Usuario HUO6 - Generar de re-trospectivas


NombreHUO7 - Consultar retrospectivas porSprint

ComoColaboradores - lıder de desarrollo - scrummaster

QuieroConsultar las retrospectivas generadas encada Sprint.

Para que pueda

Poder conocer las retrospectivasofrecidas y generadas en cada sprint.

Conocer e identificar los impedimen-tos que se han presentado durante laejecucion de tareas en cada sprint.

Cuadro 8.7: Historia de Usuario HUO7 - Consultar re-trospectivas por Sprint

Nombre HUO8 - Login de usuarios

ComoColaboradores- lıder de desarrollo - scrummaster

QuieroPermitir la autenticacion y acces de usua-rios a la aplicacion web.

Para que pueda

Poder permitir ingresar usuario y clave re-gistrada previamente para lograr accedera la aplicacion web. Poder conocer e iden-tificar los impedimentos que se han pre-sentado durante la ejecucion de tareas encada sprint.

Cuadro 8.8: Historia de Usuario HUO8 - Login de usua-rios


NombreHUO9 - Gestion de permisos y roles deusuarios

Como Administrador

QuieroControlar los permisos de navegacionacorde a los roles de usuarios.

Para que pueda

Crear, modificar y elminar roles deusuarios.

Permitir controlar los permisos denavegacion de cada tipo de rol deusuario.

Cuadro 8.9: Historia de Usuario HUO9 - Gestion de per-misos y roles de usuarios

NombreHU10 - Registrar categorias de impedi-mentos

Como Lıder de Desarrollo - Scrum Master

QuieroControlar la creacion de categorias de im-pedimentos.

Para que pueda

Crear, modificar y elminar catego-rias de impedimentos.

Permitir controlar las categorias pa-dres a las cuales son asociadas losdistintos tipos de impedimentos quese presenten durante la ejecucicon detareas de desarrollo.

Cuadro 8.10: Historia de Usuario HHU10 - Registrar ca-tegorias de impedimentos

Capıtulo 9

DISENO DE SOFTWARE

9.1. Introducion

Para la implementacion del prototipo web se establece un diseno de soft-ware basado el patron de diseno MVC, con el cual se implementaran com-ponentes interrelacionados pero cada uno con una responsabilidad de capasdistintas, es decir componentes propios para la capa de vista o presentacion,capa de logica de negocio y capa de modelo o datos. Para la capa de presen-tacion y control de las peticiones de usuario se utiliza el framework AngularJS version 5.0, y en la capa de negocio(modelo) Sprint Boot.

9.2. Herramientas metodologicas utilizadas

Para la implementacion del prototipo web que se propone en la ejecucionde este proyecto desde el analisis de requerimientos hasta la puesta en marchase define el uso de las siguientes tecnologıas: Capa de presentacion

Html 5

Css 3

Bootstrap

Capa de control

Angular JS 5.0

Capa logica de negocio

JAVA EE 7.0

85

CAPITULO 9. DISENO DE SOFTWARE 86

Spring Boot

myBatis

Postgresql

9.3. Casos de Uso RetroWeb

Encontramos los siguientes casos de uso disenados acorde a las funcio-nalidades requeridas para el funcionamiento esperado e historias de usuariospreviamente definidas, que contienen una interrelacion directa con la formu-lacion del problema, objetivos e hipotesis de este proyecto de investigacion:

9.3.1. Caso de uso Registrar Requisitos de Software

Figura 9.1: Registrar requisitos de software


9.3.2. Caso de uso Registrar Equipos de Desarollo

Figura 9.2: Registrar equipos de desarrollo

9.3.3. Caso de uso Registrar Sprints de Desarollo

Figura 9.3: Registrar Sprints de desarrollo


9.3.4. Caso de uso Consultar Sprints de Desarollo

Figura 9.4: Consultar Sprints de Desarollo

9.3.5. Caso de uso Registrar Tareas de Sprint

Figura 9.5: Registrar tareas de sprint


9.3.6. Caso de uso Asociar Impedimentos a Tareas

Figura 9.6: Asociar Impedimentos a Tareas

9.3.7. Caso de uso Generar Retrospectivas de Sprint

Figura 9.7: Generar Retrospectivas de Sprint


9.4. Modelo de Datos

El modelo de datos de la aplicacion web implementada se soporta bajola propuesta de diseno por dependencias funcionales, la cual permite disenarbases de datos relacionales a partir de la logica y modelo de negocio quesostiene la razon de ser de dicha aplicacion, que nos permite establecer enti-dades y relaciones en base a lo que realmente se quiere controlar y a su vez enconformidad con la cadena del sistema de negocio que se pretende mejorar.De conformidad a lo anterior se precisa que es una base de datos relacio-

Figura 9.8: Modelo de datos RetroWeb

nal con sus respectivas entidades, relaciones y cardinalidad. Las principalesentidades y relaciones son:

requerimientos

impedimentos

patronImpedimentos

tareasSprint

retrospectiva


A continuacion de presenta el modelo entidad relacion(MER) de la basede datos en la cual se almacenan y gestionan los datos de la aplicacion web:

Figura 9.9: Modelo de Datos Gestion de usuarios RetroWeb


Figura 9.10: Modelo de Datos logica de negocio RetroWeb


9.5. Arquitectura de la Aplicacion

El diseno arquitectonico de la aplicacion web esta basado en el patronde diseno MVC, apoyado con el estilo de programacion por capas, que tienecomo objetivo separar la logica de diseno de la logica de negocios. En re-lacion a la capa de logica de negocios que incluye la logica que realiza lasfunciones principales de la aplicacion, es decir procesamiento de datos, imple-mentacion de funciones de negocios, procesamiento y persistencia de datos,se utilizo ademas de usar la plataforma de programacion Java EE el frame-work Sprint Boot el cual se trata de un proyecto creado a partir de Spring,el cual nos permite desarrollar y arrancar de forma muy rapida aplicacionesbasadas en Sprin. En cuanto a la persistencia de datos se utilizo de la herra-mienta denominada ”myBatis”que se encarga de mapear sentencias SQL yprocedimientos almacenados con objetos Java.


9.5.1. Diseno de Aplicacion

Se describen los componentes y diagramas que soportan el funcionamientode nuestro prototipo de aplicacion web:

Figura 9.11: Arquitectura de la aplicacion


9.5.2. Diseno capa de presentacion

Definicion de los elementos visuales de interaccion para el usuario, asıcomo la distribucion e interrelacion de estos mismos. Este diseno esta sopor-tado bajo conceptos importantes para la calidad de la experiencia de usuario,tal como lo es ”la usabilidad”.

Figura 9.12: Maquetado home en RetroWeb


Figura 9.13: Maquetado gestion de tareas en RetroWeb


Figura 9.14: Maquetado gestion de usuarios en RetroWeb

Capıtulo 10

IMPLEMENTACION

10.1. Prototipo funcional

En la fase de analisis se determino una interfaz muy sencilla de acceso unavez el usuario ha sido autenticado exitosamenre,pero que facilite el acceso atodos los componentes de una forma usable. Acorde al rol de cada usuarioautenticado se le permite visualizar las opciones de menu necesarias acorde alas funciones operativas que requiera realizar cada tipo de usuario. La paginaprincipal se muestra en la imagen a continuacion, donde se puede apreciar elhome de acceso del prototipo web.

Figura 10.1: Pagina principal del prototipo RetroWeb

98

CAPITULO 10. IMPLEMENTACION 99

El modulo de registro de requerimientos es la entrada del proceso, puestoque conforme a los procesos de gestion de la demanda los requerimientos acu-den a las necesidades de los clientes y de allı se inicia el analisis, adquisiciony puesta en marcha para el desarrollo de las soluciones de software.

Figura 10.2: Modulo de registro de requerimientos

El modulo de registro de equipos de desarrollo permite ademas de registrarlos equipos de desarrollo agiles tambien asociar a estos los requerimientospreviamente registrados que se desean solucionar y solventar para los clientes.


Figura 10.3: Modulo de registro de equipos de desarrollo

Una vez que se tienen definidos requerimientos y equipos de desarrollog seprocede a definir los Sprint en los cuales se distribuyen las tareas de desarrollorequeridas para solventar las funcionalidades o historias de usuarios definidas,cada Sprint es entendido como una iteracion de avance, desarrollo, mejora yoptimizacion de las soluciones de software.

Figura 10.4: Modulo de registro Sprints de desarrollo


En cada Sprint de desarrollo se definen y acuerdan tareas a ejecutar li-gadas a un equipo determinado, requeridas llevar a cabo para poder cumplircon el objetivo del Sprint definido y las historias de usuario asociadas a dichoSprint.Las tareas que se promueven son actividades relacionadas directamen-te con la construccion de software.

Figura 10.5: Modulo de registro tareas de desarrollo

En el mismo modulo de registro de tareas de desarrollo se dispone conla funcionalidad dedicada a asociar los impedimentos que se le presentan auno o varios colaboradores que conforman un equipo de desarrollo y que nopermiten ejecutar satisfactoriamente las tareas asignadas y acordadas. Cadaimpedimento que se registre para una tarea determinada estara asociado aun tipo de categoria padre de impedimento al cual realmente pertenece.


Figura 10.6: Consultar tarea de desarrollo para asociar impedimentos

Figura 10.7: Asociar impedimentos a tareas de desarrollo

En la siguiente imagen se puede apreciar la funcionalidad que tiene mayorrelevancia dentro de la cadena logica de negocio que fundamenta este proto-tipo web, la cual es la referente a la generacion de retrospectivas, una vez setienen asociados impedimentos a las tareas de desarrollo dentro de un SprintRetroWeb”permite ofrecer modelos de retrospectivas agiles que se pueden


llevar a cabo con los equipos de desarrollos, con la finalidad de incentivarla mejora contınua, resolver dichos impedimentos o dificultades y propiciaracciones de mejora.

Figura 10.8: Generacion de retrospectiva

Figura 10.9: Generacion de retrospectiva

Parte III

CIERRE DE LAINVESTIGACION

104

Capıtulo 11

RESULTADOS Y DISCUSION

El prototipo web RetroWebcomo producto principal de este proyecto deinvestigacion contempla en sus funcionalidades una estrategia para contrares-tar los 2 principios motivacionales(ver figura 8.4) que inspiran y fundamentanla situacion problemica inicialmente descrita, los cuales son el incumplimien-to en las entregas de soluciones de software y fiabilidad de dichas soluciones,cuyos resultados estan enmarcados en reducir los altos indicadores de incum-plimiento en las entregas de soluciones de software y reducir la cantidad deincidencias o errores obtenidos en las pruebas y testing de los soluciones desoftware implementadas por los equipos que conforman el area de portalestransaccionales, todo esto dirigido a la meta principal que es incrementar laconfianza y fidelidad de los clientes actualmente exstentes. Conforme a loanterior podemos en primera instancia concluir que la estructura y diseno deRetroWeb”tiene una inspiracion alineada con las preocupaciones y objetivosorganizacionales de la compania SHA. En segunda instancia se puede mani-festar que durante el experimento llevado a cabo con el equipo de desarrollode la unidad de portales corporativos se pudo constatar que:

Se logro evidenciar un mejoramiento considerable en la falta de comu-nicacion efectiva entre esta unidad y otra unidad alterna(integracion)pero impactante en el avance de 2 requerimientos de software de prio-ridad alta.

La cantidad de incidencias obtenidas durante las pruebas de certifica-cion no fue mayor a 5, siendo estas 5 incidencias no bloqueantes nialtamente impactantes en las operaciones transaccionales que efectuanambos requerimientos.

Se puede interpretar entonces que si tiene un impacto positivo la pro-puesta incentivada con este proyecto de invetigacion, en donde claramente

105

CAPITULO 11. RESULTADOS Y DISCUSION 106

se plantea una forma diferente y estructurada para mejorar el cumplimientoy fiabilidad de las soluciones de software desarrolladas en la compania SHA,quien ha venido buscando alternativas para solventar esta preocupacion, porlo cual es preciso manifestar que la realizacion efectiva y estrategica de lasretrospectivas agiles apalancada en las Tics, es un camino viable para mejo-rar nuestra problematica de estudio.Cabe resaltar que muchas de las expectativas tenidas al inicio de la inves-tigacion se conoceran realmente al momento de que la plataforma lleve untiempo considerable en produccion.

Capıtulo 12

CONCLUSIONES

12.1. Verificacion,contraste y evaluacion de

los objetivos

La razon por la cual se decide construir e implementar un protototipo deaplicacion web como RetroWeb.es para proponer una forma estrategica quepermite mejorar en la compania SHA los indicadores de incumplimiento enlas entregas de las soluciones de software implementadas para los requeri-mientos solicitados por los clientes, incumplimiento en terminos de tiempospreviamente acordados con los clientes, ası mismo como propuesta estraegicapara contribuir al mejoramiento en la fiabilidad de dichas soluciones de soft-ware, fiabilidad en terminos de reduccion de errores e incidencias obtenidasen la fases de pruebas de certificacion.En contraste con el objetivo general de nuestro proyecto de investigacion po-demos precisar que con la ayuda y ventajas de aplicabilidad que ofrecen lasTics como en nuestro caso un prototipo de aplicacion web concatenado con lapropuesta de realizar y controlar de forma efectiva la realizacion de las cere-monias de retrospectivas si permite mejorar los indicadores de cumplimientoy fiabilidad de las soluciones de software implementadas, traducido esto enel mejoramiento de los servicios de negocio de la compania SHA y el fortale-cimiento de la fase de implementacion de software comprendida actualmenteen el ciclo de vida de desarrollo que gestiona y administra la gerencia dedesarrollo de esta compania.En apoyo a lo anterior tambien se puede manifestar que con haber podidoidentificar los factores proclives del incumplimiento y regular fiabilidad enlas soluciones de software desarrolladas se pudo plantear una estrategia desolucion para contrarestar estos factores, estructurando un modelo basadoen actividades ludico-estrategicas para la realizacion de retrospectivas agiles

107

CAPITULO 12. CONCLUSIONES 108

en base a los impedimentos que se les presentan a los equipos de desarrollodurante la fase de implementacion de software orientada a solucionar los dis-tintos requerimientos de los cliente, entendiendose incumplimiento como lano entrega de los desarrollos de software en los tiempos pactados y fiabilidadcon la cantidad de incidencias o errores encontrados en dichos desarrollos des-de la fase de pruebas de certificacion hasta la puesta en marcha en ambientesproductivos.

12.2. Sıntesis del modelo propuesto

El modelo propuesto esta basado en metodologıa agile, la cual es la meto-dologıa que ha venido adoptando la compania para la gestion del desarrollode software, cuyo modelo propuesto esta constituido de la siguiente forma:

1. Actividad 1:Gestion de requerimientos

2. Asociar equipos o celulas de desarrollo disponibles para abordar reque-rimientos de software previmente definidos.

3. Actividad 2:Definir Sprints de desarrollo(iteraciones) para la solucionde requerimientos

4. Actividad 3:Definir y ejecutar tareas por parte de los equipos previa-mente definidos, orientadas a la construccion y desarrollo de las solu-ciones de software requeridas realizar para dar solucion a los requeri-mientos solicitados, adquiridos y registrados.

5. Actividad 4:Asociar los impedimentos evidenciados que bloquean y di-ficultan la ejecucion eficaz de las tareas de desarrollo.

6. Actividad 5:Asociar los distintos impedimentos evidenciados durante laejecucion de tares en cada Sprint a categorias padres de impedimentos.

7. Actividad 6:Definir y generar modelos de retrospectivas basados en lascategorias padres a las cuales se asocian los disntitos impedimentos quese presentan durante la ejecucion de tareas por parte de los equipos ocelulas de desarrollo.Las anteriores descripciones en el orden descrito conforman la logica delmodelo propuesto, tendiendo en cuenta que cada retrospectiva generadadescribe una serie de actividades ludicas y cognitivas cuyo objetivoprincipal es atacar los impedimemtos que se le presenten a los equiposde desarrollo, atacar esos impedimentos impactan directamente en la


mejora continua de cada equipo y avance efectivo en los desarrollos desoftware con lo cual se logra reducir la perdida de tiempos que a lalarga terminan influyendo en el incumplimiento para la entrega de lassoluciones de software con las areas de pruebas de certificacion comoprimer alcance y de igual forma disminuir la cantidad de incidencias oerrores detectados en esas soluciones implementadas.

12.3. Aportes originales

El principal aporte realizado es el concerniente a establecer una estrategiapara ofrecer modelos de retrospectivas agiles fundamentados en actividadesludicas y cognitivas, en base a categorias de impedimentos previamente de-finidas a las cuales le son asociadas los distintos impedimentos que se lepresentan a los equipos o celulas de desarrollo durante la realizacion de lastareas relacionadas con la construccion e implementacion de software, cadatipo de modelo de retrospectiva que se ofrece esta orientado a atacar impedi-mentos especıficos, con esta estrategia pasamos de concebir las retrospectivascomo una reunion mas en la que no se evidencian acciones realmente correc-tivas que brinden un valor agregado a la mejora continua de los equipos dedesarrollo durante la implementacion de soluciones y en su defecto de reque-rimientos de software.

12.4. Trabajos o Publicaciones derivadas

En base a los resultados descritos se mantendra la motivacion para am-pliar el alcance de esta propuesta ampliando el alcance de implementacion deeste prototipo web en otras areas de desarrollo de la compania, enriqueciendola base de datos y conocimientos conforme a las demas situaciones o even-tos que se presentan en el resto de areas funcionales, se pretende identificarimpedimentos no identificados aun propios de los procesos internos bajo loscuales operan esas demas areas de desarrollo.De igual forma optimizar la aplicacion web con la adicion de funcionalida-des sin afectar su funcionamiento base, que permitan hacerla mas atractivay usable ante los usuarios, pero bajo la consigna que esas funcionalidadespermitan aportar en el mejoramiento de los 2 principios que fundamentan lasituacion problemica de este proyecto como lo son el incumplimiento y fiabi-lidad de las soluciones de software. Sin embargo se deja abierta la posibilidadde afrontar con esta propuesta otros tipos de preocupaciones que inquietena los equipos de desarrollo y a todas las partes interesadas, por ahora una


de las principales inquietudes que puede ser aboradada como trabajo de in-vestigacion bajo el soporte de esta misma propuesta es lo referente a comollevar a cabo de forma efectiva un plan de mejoramiento de las aplicacionespara disminuir los riesgos y costos de mantenibilidad.

Bibliografıa

[1] Gabardini Juan, Tecnicas para realizacion de retrospectivas, Kleer,Argentina,2013.

[2] Alaimo Martin, Proyectos Agiles con Scrum, Kleer, Argentina,2013.Disponible en: http://www.kleer.la/es/libros

[3] Derby Esthery Larsen Diana, Agile Retrospectives Ma-king Good Teams Great, Dallas, Texas,2010. Disponible en:https://media.pragprog.com/titles/dlret/Leading.pdf

[4] Buhler Erich , Psicologıa profunda de las retrospectivas Agile, 2013.Disponible en: https://innova1st.com/2013/03/12/psicologia-profunda-de-las-retrospectivas-agile/

[5] The CHAOS Report,Standish Group, 1994. Disponible en:https://www.pmiwdc.org/sites/default/files/presentations/20170/

111

ANEXOS

112

BIBLIOGRAFIA 113

Figura 12.1: Modelo de Datos logica de negocio RetroWeb

BIBLIOGRAFIA 114

Figura 12.2: Arquitectura de aplicacion RetroWeb

BIBLIOGRAFIA 115

Figura 12.3: EDT Proyecto de Investigacion

prototipo de herramienta web para la realizacion y...

Documents