Source: https://www.slideshare.net/JavierGarzas/mariano-minoli-tesis-doctoral-2011-marco-de-soluciones-basado-en-ontologas-para-desarrollo-global-gil
Timestamp: 2020-04-08 00:19:11+00:00

Document:
Mariano Minoli Tesis Doctoral (2011) Marco de Soluciones basado en On…
Mariano Minoli Tesis Doctoral (2011) Marco de Soluciones basado en Ontologías para Desarrollo Global Ágil
Global Healthcare Report Q2 2019 by CB Insights 644401 views
Be A Great Product Leader (Amplify,... by Adam Nash 186345 views
Trillion Dollar Coach Book (Bill Ca... by Eric Schmidt 225515 views
APIdays Paris 2019 - Innovation @ s... by apidays 217970 views
A few thoughts on work life-balance by Wim Vanderbauwhede 147158 views
Is vc still a thing final by Mark Suster 197859 views
La propuesta que se realiza en esta Tesis Doctoral es la definición de un
marco de soluciones que permita sugerir a los profesionales de proyectos A- GSD, soluciones que se ajusten exactamente a las configuraciones de sus proyectos. Con ello, se pretende resolver las tres cuestiones mencionadas anteriormente. El marco de soluciones basado en ontologías que se propone tiene los objetivos de clasificar, organizar y unificar todo el conocimiento existente sobre la problemática de equipos A-GSD e incluye:
• Una ontología que representa todo el conocimiento encontrado en términos de características de proyectos ágiles y distribuidos y;
• Una herramienta que explota la información de dicha ontología, lo que permitirá poner a disposición de la comunidad (científica y no científica) todo el conocimiento existente en A-GSD.
Visit Here to Download eBook === http://pdfuhuijuiuiuo.ygto.com/B009IFQUN4-un-cadaver-en-el-desierto-las-tres-edades-serie-negra-no-5.html
Marco Antonio González Restrepo , Alineación de la tecnología y la información para el logro de los objetivos estratégicos empresariales at Director Diseño y Gestión Servicios Digitales
ValeriaBelmonte
Jose Luis Rodriguez Gonzalez , Product Manager. Software Engineer at ROSEN
Juan Martínez Neira , Director del Área de Desarrollo en Plexus S.L. at Plexus S.L.
1. Universidad Rey Juan Carlos Escuela Técnica Superior de Ingeniería Informática Departamento de Lenguajes y Sistemas Informáticos II Marco de Soluciones basado en Ontologías para Desarrollo Global Ágil Autor: Mariano Minoli Directores: María Valeria de Castro Javier Garzás Parra Móstoles, Diciembre 2011
2. III Cada uno de nosotros es un modelo totalmente nuevo, parecido a otros modelos pero totalmente diferente. A
3. IV nónimo
4. V Resumen En los últimos años se ha puesto de manifiesto una creciente tendencia hacia la deslocalización de las tareas de construcción de software. Esta disciplina ha recibido el nombre de Desarrollo Global de Software (GSD por sus siglas en inglés, Global Software Development). Esta tendencia ha sido motivada por cuestiones de negocio, más que por cuestiones relacionadas con la ingeniería del software. Como consecuencia de ello muchas de las metodologías de desarrollo de software están siendo adaptadas a estos entornos. Este tipo de proyectos pueden implicar sitios remotos cercanos, como dos empresas dentro de la misma ciudad, o algo que implique más distancia como la coordinación de equipos pertenecientes a diferentes empresas en diferentes continentes, con diferente zona horaria, cultura, etc. Frecuentemente se asocia GSD a equipos de desarrollo de software geográficamente distribuidos con un modelo de negocio outsourcing. Aunque en muchos de los casos esto es cierto, en realidad existen otros tipos de proyectos, con características completamente distintas dentro de GSD. Comprender estas características y sus implicaciones resulta fundamental para poder solventar los desafíos a los cuales se enfrentan los profesionales en este tipo de proyectos. Ante este escenario (de equipos distribuidos), la comunidad científica ha propuesto una gran cantidad de herramientas y estrategias. La mayor parte de ellas son adaptaciones de técnicas y metodologías tradicionales, de existencia previa. Por lo general, estas soluciones tienden a recomendar mayor documentación, procesos más lineales y mejor planificación. Sin embargo, ninguna de estas soluciones han contemplado, en su concepción, una nueva forma de desarrollo de software que se ha consolidado fuertemente en los últimos años en equipos de desarrollo de todo el mundo: las metodologías ágiles. Las metodologías o métodos de desarrollo ágil han ganado protagonismo en los últimos años como una alternativa al estilo marcado por las metodologías tradicionales de la ingeniería del software. El origen de esta corriente puede encontrarse en el Manifiesto Ágil, propuesto por un grupo de profesionales en 2001. Este manifiesto favorece algunos valores (como la colaboración del cliente o la aceptación del cambio) en detrimento de otros (como la documentación exhaustiva o el seguimiento de un plan rígido) aceptados hasta ese momento en la ingeniería del software. Este cambio de enfoque fue recibido con aceptación por una parte importante de la comunidad de desarrolladores. Puede enmarcarse dentro de esta corriente de la ingeniería del software a un conjunto de iniciativas que llevan a la práctica los valores y principios expresados en el manifiesto ágil.
5. VI Dentro de las más populares se puede citar: eXtreme Programming (XP), la familia de metodologías Crystal Family, o Scrum. Los buenos resultados evidenciados por los equipos de desarrollo que adoptaron metodologías ágiles han llevado a plantear la posibilidad de utilizar este enfoque en equipos de trabajo distribuido. Así, a primera vista, parece natural que se utilicen métodos ágiles en entornos GSD. Esta combinación recibe el nombre de Desarrollo Global de Software Ágil (A-GSD por sus siglas en inglés: Agile Global Software Development). Sin embargo, esta visión contiene un problema esencial: los valores sobre los cuales se construyen las metodologías ágiles (es decir los valores del Manifiesto Ágil) presentan aspectos que son difíciles de mantener en un entorno distribuido. Esta contradicción fundamental que aparece al mezclar distancia y agilidad ha despertado últimamente tanto el interés de la comunidad científica, como así también de la comunidad de usuarios de metodologías ágiles. Así, el análisis de los trabajos realizados sobre A-GSD, muestra un aumento en los últimos años en la actividad académica en este tema. Sin embargo, se ha detectado que, aunque muchos autores justifican la necesidad de disponer de herramientas como una forma de solucionar los desafíos planteados por la distribución en combinación con la agilidad, no existen en la actualidad trabajos que analicen la relación entre las herramientas disponibles y desafíos existentes. Esta situación es también evidente en la comunidad no académica de usuarios de métodos ágiles. El estado de la práctica de esta comunidad no se ve reflejado en trabajos de tipo académico, sin embargo representa una fuente valiosa de herramientas que están siendo utilizadas. Esta dispersión de la información, distribuida en distintas fuentes, algunas provenientes del entorno académico y otras de comunidades de desarrolladores, deja a la vista el estado de la cuestión en esta área: • Por una parte, no existen trabajos que analicen de manera unificada y completa los desafíos de equipos A-GSD. • Además, ninguna de las soluciones que se proponen para estos tipos de equipos han sido analizadas desde el punto de vista de cuáles desafíos intenta solucionar. • Por último, las soluciones propuestas por la comunidad científica no tienen un alcance efectivo a la comunidad de desarrolladores. Todas estas cuestiones dificultan a los profesionales la utilización de de todos los avances que se han producido en el ámbito de A-GSD en los últimos años. Por todo ello, se considera conveniente buscar un marco conceptual y
6. VII tecnológico que permita determinar cuáles son las mejores soluciones de acuerdo a los diferentes tipos de equipos en proyectos A-GSD. La propuesta que se realiza en esta Tesis Doctoral es la definición de un marco de soluciones que permita sugerir a los profesionales de proyectos A- GSD, soluciones que se ajusten exactamente a las configuraciones de sus proyectos. Con ello, se pretende resolver las tres cuestiones mencionadas anteriormente. El marco de soluciones basado en ontologías que se propone tiene los objetivos de clasificar, organizar y unificar todo el conocimiento existente sobre la problemática de equipos A-GSD e incluye: • Una ontología que representa todo el conocimiento encontrado en términos de características de proyectos ágiles y distribuidos y; • Una herramienta que explota la información de dicha ontología, lo que permitirá poner a disposición de la comunidad (científica y no científica) todo el conocimiento existente en A-GSD.
7. IX Abstract Over the last years the software industry has shown an increasing trend towards the offshoring of software construction tasks. This discipline has been named Global Software Development (GSD). This trend has been driven by business issues, rather than issues related to software engineering. As a result, many software development methodologies are being adapted to these distributed projects. Such projects may involve remote sites nearby, such as two companies within the same city, or something that involves more distance such as the coordination of teams from different companies in different continents with different time zone, culture, etc. GSD is frequently associated with software development teams geographically distributed using outsourcing business model. Although in many cases this is true, there are actually other types of projects, with completely different characteristics, within GSD. Understanding these characteristics and their implications is essential to solve the challenges they face. Given this scenario, distributed teams, the scientific community has proposed a large number of tools and strategies. Most of them are adjustments of traditional techniques and methodologies of previous existence. Generally, these solutions recommend more documentation, more linear processes and better planning. However, none of these solutions have been created considering a new style of software development that has been consolidated in recent years on development teams around the world: the agile methodologies. Agile methodologies have gained popularity in recent years as an alternative to traditional style of methodologies of software engineering. The origin of this stream can be found in the Agile Manifesto, proposed by a group of professionals in 2001. This manifesto presents values and principles radically different from those accepted so far in software engineering. These principles and values were adopted by a significant part of the developer community. Using the basis of this manifesto various initiatives have been proposed. Among the most popular can be cited: eXtreme Programming (XP), the family of Crystal Methodologies, or Scrum. The good results evidenced by the development teams that have adopted agile methodologies led to consider the possibility of using this approach in distributed teams. At first glance, it seems natural to use agile methods in GSD environments. This combination is called the Global Development Agile Software (A-GSD for its acronym in English: Global Agile Software Development). However, this point of view contains a fundamental problem: the agile values,
8. X which are the foundations of agile methodologies, have aspects that are difficult to maintain in a distributed environment. This fundamental contradiction, which appears when mixing distance and agility, has recently raised much interest from the scientific community, as well as the community of users of agile methodologies. The analysis of works on A-GSD shows an increase of academic activity in this area in recent years. However, it was found that, although many authors justify the need for tools as a way to solve the challenges of distribution in combination with the agility, currently there are no studies that analyze the relationship between the available tools and existing challenges. This situation is more evident in non-academic community of users. The state of the practice of this community is not reflected in academic works; however, it constitutes a valuable source of tools that are being used. This dispersion of information represents a problem in this area: • First, there are no studies that analyze in a unified and complete team challenges A-GSD. • Moreover, none of the proposed solutions for these types of teams have been analyzed from the challenges point of view. • Finally, solutions proposed by the scientific community do not actually reach the developer community. The issues described difficult for practitioners to use all the advances that have occurred in the area of A-GSD in recent years. Therefore it is considered appropriate to develop a technological framework that helps to determine the best solutions according to different types of A-GSD projects. The proposal that is made in this PhD Thesis is the definition of a solution framework that enables A-GSD professionals to suggest solutions tailored exactly to the configurations of their projects. This is intended to resolve the three issues mentioned above. The ontology-based solution framework proposed has the objective to classify, organize and unify all the existing knowledge on A-GSD and includes: • An ontology that represents the knowledge found in terms of agile and distributed projects features and; • A tool that uses the information of this ontology, which will make available existing knowledge in A-GSD to the community (scientific and nonscientific). .
9. XI Agradecimientos En primer lugar quiero agradecer a mis directores Valeria y Javier. Gracias por acompañarme en todo este proceso, por guiarme con su experiencia y motivarme día a día. Y por sobre todas las cosas, gracias por la infinita paciencia demostrada. A Esperanza, por haberme dado la oportunidad de realizar estudios de posgrado. De donde provengo pocos profesionales tienen la posibilidad de llegar tan lejos en sus estudios y claro nada de esto podría haber sido posible sin tu apoyo y confianza. Gracias a mi familia, Verónica, sin vos todavía estaría estudiando análisis matemático☺. A mis padres y a mi hermano Justi por enseñarme a hacer bien las cosas. Muchas gracias a todos mis compañeros de trabajo, en especial a los Javieres (Broggi y Lopez) y a Jorge, es un honor trabajar con profesionales tan profesionales. Gracias por el apoyo demostrado en esta aventura. Finalmente, agradezco a mis amigos, los nuevos, los viejos, los que están cerca a pesar de la distancia, los que están lejos…a todos. Gracias Agustín por interrumpirme todos los días a través del messenger para contarme como van las cosas de aquel lado del charco. Gracias!
10. XIII Índice 1. INTRODUCCIÓN .....................................................................................23 1.1 Planteamiento del Problema y Enfoque...........................................23 1.2 Hipótesis y Objetivos .....................................................................29 1.3 Método de Investigación ................................................................30 1.3.1 Método de Resolución y Validación .........................................31 1.3.1.1 Caso de estudios para la validación de la ontología ....................33 1.3.1.2 Casos de estudio para la validación de la herramienta.................34 1.4 Estructura de la Tesis .....................................................................34 2. ESTADO DEL ARTE ................................................................................39 2.1 Introducción...................................................................................39 2.2 Distribución y Agilidad: Desafíos y Soluciones ..............................40 2.2.1 Características de proyectos distribuidos.................................41 2.2.2 Características de proyectos Ágiles .........................................41 2.2.3 Desafíos..................................................................................41 2.2.4 Soluciones...............................................................................41 2.3 Revisión Sistemática ......................................................................42 2.3.1 Preguntas de investigación......................................................42 2.3.2 Términos de búsqueda.............................................................43 2.3.3 Fuentes de información ...........................................................44 2.3.4 Ejecución de la revisión...........................................................45 2.3.5 Resultados...............................................................................45 2.3.5.1 Resultados numéricos generales ................................................45 2.3.5.2 Cronología de los trabajos encontrados......................................46 2.3.5.3 Conceptos, instancias y relaciones entre instancias.....................47 2.3.6 Respuestas a las Preguntas de Investigación............................48 2.3.6.1 RQ1: ¿Cuáles son los conceptos clave relacionados a características de proyectos ágiles y distribuidos?..................................................................48 2.3.6.2 RQ2: ¿Cuáles son los conceptos clave relacionados a desafíos en proyectos A-GSD?.........................................................................................56
11. XIV 2.3.6.3 RQ3: ¿Cuáles son los conceptos clave relacionados a las soluciones para equipos A-GSD? ....................................................................................61 2.3.6.4 RQ4: ¿Existen trabajos que mapeen características de proyectos a desafíos y a soluciones? .................................................................................65 2.4 Propuestas de Marcos de Soluciones en el ámbito de A-GSD..........66 2.4.1 Agility Across Time and Space: Implementing Agile Methods in Global Software Projects (Šmite, Darja; Moe, Nils Brede; Ågerfalk, Pär J.) [107] 66 2.4.2 A Practical Guide to Distributed Scrum (Elizabeth Woodward, Steffan Surdek, Matthew Ganis) [125].....................................................66 2.4.3 Practices for Scaling Lean and Agile Development (Craig Larman) [75]..........................................................................................66 2.4.4 Síntesis de Propuestas.............................................................67 2.5 Conclusiones..................................................................................69 3. MARCO DE SOLUCIONES BASADO EN ONTOLOGÍAS PARA A-GSD .........73 3.1 Ontología.......................................................................................74 3.1.1 Presentación y Objetivo...........................................................74 3.1.2 Planificación de la Construcción de la Ontología ....................76 3.1.3 Especificación de la Ontología ................................................79 3.1.3.1 Información General.................................................................79 3.1.3.2 Situación y Contexto.................................................................81 3.1.4 Conceptualización de la Ontología ..........................................82 3.1.4.1 Ontología A-GSD.....................................................................82 3.1.4.2 Sub-Ontología Características de Proyectos Ágiles ....................83 3.1.4.3 Sub-Ontología Características de Proyectos Distribuidos ...........87 3.1.4.4 Sub-Ontología Desafíos............................................................97 3.1.4.5 Sub-Ontología Soluciones....................................................... 109 3.1.5 Implementación de la Ontología ............................................115 3.1.5.1 Selección del lenguaje de ontología y la herramienta................ 115 3.1.5.2 Implementación de la ontología A-GSD en OWL usando Protègè 117 3.2 Herramienta de explotación de la ontología A-GSD: AG-Advisor..121
12. XV 3.2.1 Presentación y Objetivo.........................................................122 3.2.2 Proceso de desarrollo de la herramienta AG-Advisor ............122 3.2.2.1 Historias de usuario ................................................................ 122 3.2.2.2 Modelo de Arquitectura .......................................................... 123 3.2.3 Herramienta..........................................................................124 4. VALIDACIÓN........................................................................................131 4.1 Método de Validación ..................................................................131 4.2 Presentación de los Casos de estudio para validar la ontología.......133 4.3 Descripción de los Casos de Estudio desarrollados........................134 4.3.1 Caso 1 - Tipificación de proyectos A-GSD.............................134 4.3.2 Caso 2 - Descubrimiento de desafíos .....................................136 4.3.3 Caso 3 - Encuestas sobre tipos de proyectos A-GSD y sus desafíos 137 4.3.4 Caso 4 y Caso 5 - Utilización de la herramienta AG-Advisor en proyectos reales....................................................................................138 5. CONCLUSIONES ...................................................................................145 5.1 Análisis de la Consecución de Objetivos.......................................145 5.2 Principales Contribuciones...........................................................149 5.3 Trabajos Futuros ..........................................................................151 5.3.1 Enriquecimiento de la Ontología A-GSD con nuevas soluciones 151 5.3.2 Perfeccionamiento del mecanismo de recomendaciones de soluciones.............................................................................................151 5.3.3 Perfeccionamiento de la herramienta AG-Advisor..................152 5.3.4 Publicación de resultados científicos .....................................153 REFERENCIAS...............................................................................................155 ACRÓNIMOS .................................................................................................161 A INFORMACIÓN DETALLADA DE LA REVISIÓN SISTEMÁTICA.................165 A.1 Relación completa de trabajos analizados .....................................165 B LISTA COMPLETA DE INSTANCIAS SISTEMÁTICA .................................217 B.1 Lista de instancias de conceptos y sus relaciones...........................217
14. XVII Lista de Figuras Figura 1-1. Método de Investigación..................................................................31 Figura 1-2. Etapa de Resolución y Validación....................................................32 Figura 2-1. Esquema de conocimiento básico de la revisión sistemática..............40 Figura 2-2. Distribución cronológica de los trabajos encontrados en la revisión. .46 Figura 2-3. Ejemplo de concepto e instancia con sus relaciones..........................47 Figura 2-4. Página principal del manifiesto ágil..................................................50 Figura 2-5. Modelos Estructura de modelos de negocio de Damian [34].............55 Figura 2-6. Modelos Resumen de desafíos A-GSD [99] .....................................58 Figura 2-7. Resultados de encuesta de Scott Ambler sobre distribución geográfica en equipos ágiles [6] .................................................................................63 Figura 2-8. Resultados de encuesta de Scott Ambler sobre distribución de personas en equipos ágiles [6] .................................................................................63 Figura 3-1. Planificación de la construcción de la Ontología A-GSD ..................78 Figura 3-2. Ciclo de conceptualización de la Ontología A-GSD..........................80 Figura 3-3. Ontología de A-GSD y sus sub-ontologías .......................................81 Figura 3-4. Modelo UML de la sub-ontología Características de Proyectos Ágiles. .................................................................................................................83 Figura 3-5. Modelo UML de la sub-ontología Características de Proyectos Distribuidos..............................................................................................88 Figura 3-6. Modelo UML de la sub-ontología Desafíos. .....................................98 Figura 3-7. Modelo UML de la sub-ontología Soluciones.................................110 Figura 3-8. Modelo UML de la sub-ontología Soluciones para la taxonomía de soluciones...............................................................................................114 Figura 3-9. Tabla comparativa de lenguajes de ontologías presentada en [59] ...116 Figura 3-10. Tabla comparativa de herramientas de ontologías presentada en [59] ...............................................................................................................116 Figura 3-11. Pantalla de bienvenida de la herramienta Protègè..........................118 Figura 3-12. Marco de trabajo de la herramienta Protègè..................................118 Figura 3-13. Jerarquía de clases.......................................................................119 Figura 3-14. Definición de la propiedad implementa ........................................119
15. XVIII Figura 3-15. Definición de las subclases de distancia.......................................120 Figura 3-16. Definición de los individuos de la clase de distancia-temporal ......120 Figura 3-17. Ejemplo de codificación de la ontología. ......................................121 Figura 3-18. Arquitectura de la herramienta AG-Advisor. ................................123 Figura 3-19. Pantalla de bienvenida de la aplicación AG-Advisor.....................124 Figura 3-20. Paso 1: Configuración de características ágiles del proyecto. ........125 Figura 3-21. Paso 2: Configuración de características distribuidas del proyecto.126 Figura 3-22. Paso 3: Configuración de Desafíos...............................................127 Figura 3-23. Paso 4: Visualización de Soluciones.............................................127
16. XIX Lista de Tablas Tabla 1-1. Clasificación de los casos de estudio .................................................33 Tabla 2-1. Orígenes de información utilizados durante la revisión sistemática ....43 Tabla 2-2. Orígenes de información utilizados durante la revisión sistemática ....44 Tabla 2-3. Orígenes de información utilizados durante la revisión sistemática ....46 Tabla 2-4. Relación de conceptos sobre características de proyectos ágiles.........49 Tabla 2-5. Relación de conceptos sobre características de proyectos distribuidos 51 Tabla 2-6. Relación de conceptos sobre Desafíos ...............................................57 Tabla 2-7. Relación de conceptos sobre Soluciones............................................61 Tabla 2-8. Ejemplos de prácticas A-GSD encontradas en la bibliografía.............64 Tabla 2-9. Ejemplos de herramientas A-GSD encontradas en la bibliografía.......65 Tabla 2-10. Síntesis de Propuestas.....................................................................68 Tabla 3-1. Especificación de la Ontología sobre A-GSD. ...................................79 Tabla 3-2. Mapeo de las sub-ontologías de la Ontología sobre A-GSD a las áreas de conocimientos del SWEBOK 2004. ......................................................81 Tabla 3-3. Sub-ontología de Características de Proyectos Ágiles: glosario de conceptos..................................................................................................84 Tabla 3-4. Sub-ontología de Características de Proyectos Ágiles: instancias más representativas..........................................................................................85 Tabla 3-5. Sub-ontología de Características de Proyectos Distribuidos: glosario de conceptos..................................................................................................89 Tabla 3-6. Sub-ontología de Características de Proyectos Ágiles: instancias más representativas..........................................................................................93 Tabla 3-7. Sub-ontología de Desafíos: glosario de conceptos..............................99 Tabla 3-8. Sub-ontología de Desafíos: principales instancias. ...........................103 Tabla 3-9. Sub-ontología de Desafíos: glosario de conceptos............................111 Tabla 3-10. Sub-ontología de Soluciones: principales instancias.......................113 Tabla 3-11. Historias de usuario del proyecto de desarrollo de la herramienta AG- Advisor...................................................................................................123 Tabla 4-1. Relación de trabajos analizados en el caso de estudio 1....................134 Tabla 4-2. Características de los proyectos Alfa y Beta. ...................................139
17. XX Tabla 4-3. Lista de desafíos encontrados para los proyectos Alfa y Beta con la herramienta AG-Advisor.........................................................................140 Tabla 4-4. Lista parcial de soluciones propuestas para los proyectos Alfa y Beta con la herramienta AG-Advisor...............................................................141 Tabla A-1. Relación completa de trabajos analizados .......................................166 Tabla B-1. Instancias de la Sub-ontología Características de Proyectos Ágiles..216 Tabla B-2. Instancias de la Sub-ontología Características de Proyectos Distribuidos..........................................................................................................218 Tabla B-3. Instancias de la Sub-ontología de Desafíos........................................228 Tabla B-4. Instancias de la Sub-ontología de Soluciones....................................240
19. 1. Introducción La presente Tesis Doctoral aborda la definición de un marco de soluciones para en el ámbito del Desarrollo de Software Global (GSD, Global Software Development) y las Metodologías Ágiles, que asista a los profesionales en la selección de las mejores soluciones acorde a las características específicas de sus proyectos. En este capítulo, en la sección 1.1 se presenta la motivación que ha llevado a realizar este trabajo. En la sección 1.2 se establece la hipótesis principal y los objetivos directamente derivados de la misma. En la sección 1.3 se resume el método de investigación utilizado. Y finalmente, en la sección 1.4 se proporciona una visión general del resto del documento. 1.1 Planteamiento del Problema y Enfoque La ingeniería del software es una de las ingenierías que más ha evolucionado en los últimos 50 años [90]. Desde su concepción, la ingeniería del software ha resuelto múltiples desafíos inherentes al proceso de construcción de un producto (el software) con características totalmente distintas a las existentes en otras ingenierías. Por este motivo la construcción de software no es comparable a la construcción de otros tipos de productos, como por ejemplo, edificios, caminos o aviones [90]. En consecuencia los procesos de ingeniería de software que se han obtenido a través de los años han tenido que evolucionar a base de errores y lecciones aprendidas; pudiendo utilizar pocas estrategias de otras ingenierías [81]. En su evolución, la ingeniería del software ha logrado enormes avances en los modelos de ciclo de vida, técnicas de planificación y control, arquitecturas, técnicas de modelado y herramientas de todo tipo. Sin embargo aun restan por resolver múltiples desafíos derivados de la aplicación de estos avances en ambientes interdisciplinarios y distribuidos. La distribución de las tareas asociadas a la construcción de software se ha vuelto una práctica común en empresas de todo mundo en los últimos años [52, 24]. Desde la expansión de Internet, a mediados de los años 90, esta tendencia se ha acentuado aún más. En este momento las empresas están cooperando en todo el mundo y la deslocalización de tareas (como la programación o las pruebas) hacia sitios remotos, normalmente más rentables, es una de las ideas más populares en la gestión de proyectos de ingeniería de software. Estos sitios remotos pueden ser
20. 24 Mariano Minoli algo tan cercano como otra empresa dentro de la misma ciudad o país, o algo tan lejano como empresas en otro continente, incluso con diferente zona horaria, cultura, etc. Esta tendencia ha sido motivada por cuestiones de negocio, más que por cuestiones relacionadas con la ingeniería de software [34]. Es por ello que muchas de las metodologías de desarrollo de software están siendo adaptadas a estos entornos. La disciplina de la ingeniería de software que intenta solventar estos desafíos se denomina Desarrollo Global de Software (GSD, Global Software Development) [52]. Según el Outsourcing Management Body of Knowledge (OMBOK) ™ se define GSD de la siguiente manera [86]: Desarrollo de software (nuevo, de mantenimiento, total o parcial) llevado a cabo fuera del contexto de una iniciativa de software interna. Generalmente se asocia GSD a equipos de desarrollo de software geográficamente distribuidos (distancia geográfica) con un modelo de negocio outsourcing. Aunque en la mayor parte de los casos esto es cierto, en realidad existen otros tipos de distancia (por ejemplo la organizacional) y condiciones para las cuales GSD es aplicable. Desde el punto de vista de la industria del software, lo verdaderamente relevante es que la distancia (geográfica, temporal, cultural u organizacional) derivada de la distribución plantea una serie de desafíos que no pueden ser resueltos con las soluciones existentes para equipos co-localizados [23]. Algunos de los desafíos más comúnmente citados son [32]: • Comunicación efectiva • Diferencias culturales • Dificultades para la coordinación del equipo y para lograr cooperación • Diferencias de huso horario • Falta de confianza • Asimetría en los procesos, políticas y normas • Distancia física • Infraestructura de TI • Diferentes niveles de conocimiento • Seguimiento y Control • Barreras idiomática • Gestión del Conocimiento
21. Introducción 25 • Ámbito de aplicación y gestión del cambio • Visibilidad general del proyecto • Diferencias en las tecnologías utilizadas • Dificultades para la creación de espíritu de equipo En mayor o menor medida, todos estos desafíos están presentes en proyectos co-localizados, el problema es que al entrar en juego la distancia, muchos de ellos se ven acentuados. Cualquier estrategia que se proponga para equipos GSD debería contemplar estos desafíos. Desde que el término GSD fue propuesto hacia finales del los años 90 [25, 49], la comunidad se ha volcado en analizar las múltiples características, desafíos y tipologías de este tipo de proyectos de software. Una gran cantidad de herramientas y estrategias se propusieron desde entonces [23, 94, 88, 127, 34, 104, 36, 92, 87]. La mayor parte de ellas son adaptaciones de técnicas y metodologías tradicionales, de existencia previa. Por lo general, estas soluciones tienden a recomendar mayor documentación, procesos más lineales y mejor planificación. Por ejemplo, existen técnicas que favorecen la utilización de ingeniería de requisitos para solventar la brecha de comunicación [62], o el uso de arquitecturas en el mismo sentido [28]. Estas soluciones fueron adoptadas por los equipos distribuidos reportando ciertas mejoras en la calidad de los procesos de desarrollo deslocalizado [51]. Sin embargo, ninguna de estas soluciones han contemplado, en su concepción, una nueva forma de desarrollo de software que se ha consolidado fuertemente en los últimos años en equipos de desarrollo de todo el mundo: las metodologías ágiles. Los métodos de desarrollo ágil, surgidos inicialmente como reacción de la comunidad a las metodologías “pesadas” que tradicionalmente han dominado el mundo de la ingeniería de software, han ganado protagonismo en los últimos años. El origen de esta corriente puede encontrarse hacia mediados de los años ’90 con los métodos de desarrollo de software ligeros (lightweight software development methods). En 2001, un grupo de desarrolladores que estaban proponiendo iniciativas en este ámbito se reunieron para unificar criterios. Así nació el denominado Manifiesto Ágil, con un conjunto de valores y principios [79]. Estos principios y valores, a primera vista radicales, fueron recibidos con aceptación por parte de la comunidad de desarrolladores y con cierto escepticismo por parte de la comunidad científica. En el marco de este manifiesto se propusieron distintas iniciativas. Dentro de las más populares se puede citar: eXtreme Programming [41] propuesta originalmente por Kent Beck, la familia de metodologías Crystal
22. 26 Mariano Minoli Family [9,29] propuesta por Alistair Cockburn, o Scrum [116] propuesto por Ken Schwaber y Jeff Sutherland. Más allá de las discusiones suscitadas originalmente por este cambio de enfoque en el modo de llevar proyectos de desarrollo de software, existen estudios de la industria que demuestran una creciente adopción de estas prácticas y metodologías en equipos de diverso tamaño y características [2]. Desde este punto de vista, parece natural que también se utilicen métodos ágiles en entornos GSD, o al menos, que todos los equipos que utilizan metodologías ágiles para sus proyectos co-localizados también lo hagan para sus proyectos distribuidos. Esta tendencia recibe el nombre de Desarrollo Global de Software Ágil (en adelante esta combinación será llamada A-GSD por sus siglas en inglés: Agile Global Software development [119]). Sin embargo, esta visión contiene un problema esencial: los valores sobre los cuales se construyen las metodologías ágiles (los valores del manifiesto ágil) presentan aspectos que son difíciles de mantener en un entorno distribuido. Si se analiza el manifiesto ágil, puede encontrarse que éste insta a valorar [79]: • A los individuos y su interacción, por encima de los procesos y las herramientas, • El software que funciona, por encima de la documentación exhaustiva. • La colaboración con el cliente, por encima de la negociación contractual. • La respuesta al cambio, por encima del seguimiento de un plan. Es fácil concluir que la interacción y la colaboración, habiendo distancia de por medio, es muy difícil de mantener. Incluso la eliminación de documentación exhaustiva o el no seguimiento de plan pre-establecido van en contra de la mayor parte de soluciones que se habían propuesto para GSD tradicionalmente. Puede verse que las primeras evidencias sobre la utilización de metodologías ágiles en GSD demuestran discusiones contrapuestas sobre, si aplicar esta combinación, contribuye o resta valor a los equipos de desarrollo [5,4,39,82,99]. Por ejemplo, en [4] David Parnas describe a la utilización de métodos ágiles en GSD como: “La solución equivocada para un problema real y antiguo”. En su exposición, Parnas explica que los problemas (o desafíos) relacionados a GSD son los mismos a los cuales se enfrentan profesionales de desarrollo que trabajan en un mismo sitio (co-ubicados), con un incremento en los
23. Introducción 27 problemas asociados con la comunicación. En este sentido el autor explica que los métodos ágiles, lejos de mejorar este aspecto, lo complican aún más. Sin embargo, son varios los trabajos que destacan los beneficios de la combinación de métodos ágiles y GSD. En [5] los autores concluyen que: “la incorporación cuidadosa de agilidad en entornos distribuidos de desarrollo de software es esencial para hacer frente a varios de los desafíos relacionados a equipos distribuidos, como la comunicación, el control y la confianza”. En [39], los autores hacen especial referencia a: “la necesidad de disponer de herramientas tecnológicas que permitan a los equipos de desarrollo enfrentarse a los desafíos de A-GSD”. Este creciente interés en el tema de A-GSD se hace evidente también en la reciente encuesta publicada por Scott Ambler en su página, en la cual indaga sobre la utilización de métodos ágiles en entornos distribuidos [6], o el hecho de que “Agile Globalization” haya sido el tema central en la XP Conference 2011 [1]. El análisis de los trabajos realizados en la problemática de esta Tesis Doctoral, A-GSD, muestra un aumento en los últimos años en la actividad académica en este tema. En concreto a partir del año 2006, cuando se ha detectado un marcado incremento en las publicaciones científicas sobre el tema y la disponibilidad de herramientas para este tipo de equipos. Sin embargo, un problema detectado en el análisis de tales trabajos es que, aunque muchos autores justifican la necesidad de disponer de herramientas como una forma de solucionar los desafíos planteados por la distribución en combinación con la agilidad, no existen en la actualidad trabajos que analicen la relación entre las herramientas disponibles y desafíos presentes. Así, por ejemplo, las revisiones sistemática de Da Silva et. al [32] y Jalali y Wolhin [59] realizan un análisis de los desafíos a los que se enfrentan los equipos de GSD y A-GSD respectivamente. Sin embargo, dichos trabajos dejan de lado el análisis de las prácticas y herramientas que están siendo propuestas y usadas en estos tipos de desarrollo. Dos ejemplos claros de estas herramientas son: [3] y [110] en donde los autores proponen la utilización de técnicas avanzadas de Wikis y redes sociales para mejorar la comunicación en equipos A-GSD. Esta situación es también evidente en la comunidad no académica de usuarios de métodos ágiles. El estado de la práctica de esta comunidad muchas veces no se ve reflejado en trabajos de tipo académico, sin embargo representa una
24. 28 Mariano Minoli fuente valiosa de herramientas que están siendo utilizadas. En este sentido, se han encontrado trabajos que analizan el estado de la práctica de herramientas para equipos distribuidos, pero no ágiles [90]. Esta dispersión de la información, distribuida en distintas fuentes, algunas provenientes del entorno académico y otras de comunidades de desarrolladores más prácticas, deja a la vista el estado de la cuestión en esta área: • Por una parte, no existen trabajos que analicen de manera unificada y completa los desafíos de equipos A-GSD teniendo en cuenta tanto características ágiles como distribuidas. Los esfuerzos que existen en este sentido no analizan las principales características de este tipo de proyectos, ni realizan un mapeo desde las características a los desafíos. • Además, ninguna de las soluciones que se proponen para estos tipos de equipos han sido analizadas desde el punto de vista de cuáles desafíos intenta solucionar. Es importante discernir entre las diferentes características que puede tener un proyecto A-GSD y que en base a esas características pueden ser más o menos aconsejables determinadas soluciones. • Por último, las soluciones propuestas por la comunidad científica no tienen un alcance efectivo a la comunidad de desarrolladores. En resumen, todas estas cuestiones dificultan a los profesionales la utilización de de todos los avances que se han producido en el ámbito de A-GSD en los últimos años. Así, aunque en la actualidad exista una gran cantidad de soluciones propuestas (herramientas, prácticas, etc.) que pueden servir de ayuda en problemas concretos presentes en A-GSD, la decisión de cuál utilizar en cada proyecto, puede ser en muchos casos una decisión al azar o por simple gusto. Por todo ello, se considera conveniente buscar un marco, conceptual y tecnológico, que permita a los profesionales determinar cuáles son las mejores soluciones de acuerdo a los diferentes tipos de equipos en proyectos A-GSD. Desde este punto de vista, la propuesta que se realiza en esta Tesis Doctoral es la definición de un marco, que se ha llamado marco de soluciones, que permitirá sugerir a los profesionales de proyectos A-GSD, soluciones que se ajusten exactamente a las configuraciones de sus proyectos. Con ello, se pretende resolver las tres cuestiones mencionadas anteriormente. El marco de soluciones que se propone estará basado en una ontología, y tiene los objetivos de clasificar,
25. Introducción 29 organizar y unificar todo el conocimiento existente sobre la problemática de equipos A-GSD. En concreto, en el marco de esta Tesis Doctoral se propone proporcionar una ontología que organice todo el conocimiento encontrado en términos de características de proyectos ágiles y distribuidos; los desafíos que éstas implican; y las soluciones que pueden solventar estos desafíos. La ontología a construir establecerá relaciones entre los desafíos y las soluciones que mejor se ajustan a éstos. A través de la implementación de la ontología mediante un lenguaje y plataforma que permita realizar consultas, dichas relaciones permitirán sugerir a los profesionales A-GSD las mejores soluciones acordes a las características de sus proyectos. Además, se propone la construcción de una herramienta que explote dicha ontología, lo que permitirá poner a disposición de la comunidad (científica y no científica) todo el conocimiento existente en A-GSD para que pueda ser utilizado por profesionales. La implementación de dicha herramienta deberá permitir: a) la exploración gráfica de ontología implementada; b) la creación de proyectos de A- GSD teniendo en cuenta sus características; c) el análisis de los desafíos potenciales y reales acordes a las características indicadas; y d) la sugerencia de soluciones que permitan solventar los desafíos de cada proyecto. 1.2 Hipótesis y Objetivos La hipótesis planteada en esta Tesis Doctoral es que “es factible la definición de un marco conceptual y tecnológico que pueda asistir a los profesionales en la selección de las mejores soluciones a aplicar acordes a las características de sus proyectos A-GSD”. El objetivo principal de este trabajo de investigación, derivado directamente de la hipótesis, es: “la especificación de una ontología que agrupe todo el conocimiento encontrado en A-GSD, y la construcción de una herramienta para la explotación de dicha ontología, de forma que proporcione un marco que asista a los profesionales en la selección de las mejores soluciones acordes a las características de sus proyectos A-GSD”. Para la consecución de este objetivo se han planteado los siguientes objetivos parciales: O1. Análisis y evaluación de trabajos relacionados con A-GSD. O2. Especificación de una ontología que concentre el conocimiento relevado:
26. 30 Mariano Minoli O2.1. Especificación de una ontología semi-formal haciendo uso de modelos UML. O2.2. Recopilación de todas las instancias de los conceptos de la ontología y registro de sus relaciones. O2.3. Implantación de una ontología formal haciendo uso de un lenguaje que disponga de una herramienta estable. O3. Construcción de una herramienta que permita explotar la información registrada en la ontología: O3.1. Especificación de la arquitectura de la herramienta de soporte. O3.2. Implementación de la herramienta. O4. Validación del marco de soluciones propuesto. O4.1. La utilidad de la ontología y la herramienta propuesta se validarán mediante su aplicación en casos de proyectos A-GSD que se utilizarán como casos de estudio. 1.3 Método de Investigación La diferente naturaleza de las Ingenierías, respecto al resto de las disciplinas empíricas y formales, dificulta la aplicación directa de los métodos de investigación clásicos [65] y en particular, a la investigación en Ingeniería de Software. El método de investigación que se sigue en esta tesis es la adaptación del propuesto por Marcos y Marcos en [80] para la investigación en Ingeniería del Software. Dicho método se basa en el hipotético-deductivo propuesto por Bunge [18] y se compone de una serie de pasos (ver Figura 1-1) lo suficientemente generales como para ser aplicado a cualquier tipo de investigación. Como puede apreciarse en la Figura 1-1, en el método de investigación se incluye una etapa de definición del propio método. Los autores [80] recomiendan definirlo de esta manera, puesto que cada investigación posee sus propias características, lo que implica que no exista un método genérico y universal que pueda aplicarse de forma directa y sin modificaciones a cualquier trabajo de investigación. Según sea la naturaleza del problema a resolver, se utilizará un método deductivo, experimental, etc. A continuación, se resume el método específico usado en esta tesis para las etapas de resolución y validación.
27. Introducción 31 Figura 1-1. Método de Investigación 1.3.1 Método de Resolución y Validación El método de resolución y validación seguido en esta Tesis Doctoral es la adaptación, propuesta en [120], de dos métodos conocidos en el campo de la Ingeniería del Software: el método en cascada tradicional [101] y el Proceso Unificado de Rational [16], tomando como base la definición de etapas consecutivas del primero y el proceso iterativo del segundo. La elección de estos métodos se basa en la similitud que existe entre la naturaleza del problema a resolver y los problemas que surgen en el desarrollo de software. Existen ciertos problemas de investigación en Ingeniería del Software que tienen en sí mismo una naturaleza ingenieril, ya que se trata de la construcción de nuevos objetos [81]. Un método de desarrollo de software da las pautas para la construcción de nuevos objetos (de software); por ello, los métodos de desarrollo
28. 32 Mariano Minoli de software nos pueden servir de base para la resolución de los problemas de investigación en Ingeniería del Software con carácter ingenieril. En el caso de esta Tesis Doctoral, el nuevo objeto a construir se trata de un marco de soluciones que permita asistir a los profesionales en la selección de las mejores soluciones acordes a las características de sus proyectos A-GSD. Dicho marco incluye la creación de una ontología que agrupe todo el conocimiento de A- GSD y una herramienta que permita la explotación de dicha ontología. La Figura 1-2 muestra el proceso de resolución y validación seguido en este trabajo. Figura 1-2. Etapa de Resolución y Validación Como puede verse en la Figura 1-2, en la resolución y validación de esta Tesis Doctoral se han realizado dos grandes ciclos de iteración: uno para la resolución y validación de la ontología y otro para la resolución y validación de la herramienta construida. Cada iteración se ha llevado a cabo a través de la aplicación de la propuesta a diferentes casos de estudios. Desde el punto de vista de las ciencias sociales, los casos de estudio se utilizan para investigar una situación o fenómeno que ocurre en un contexto real [126]. Sin embargo, cuando se habla de investigación en sistemas software, los casos de estudios pueden abordar casos como el desarrollo o la implantación de un sistema de información en una organización particular [31]. Entre los casos de estudios realizados, los cuales se recogen en la Tabla 1-1, se pueden destacar el Caso 3, Caso 4 y Caso 5 que se han llevado a cabo en un entorno real. Tales casos de estudio se han llevado a cabo en el marco de la empresa Assertum Tecnologías S.L., cuyo co-director es el doctorando de esta Tesis Doctoral.
29. Introducción 33 La empresa Assertum Tecnologías tiene como objeto la creación, desarrollo, comercialización y asesoramiento de sistemas y equipos informáticos, así como la prestación de servicios relacionados con las nuevas tecnologías. Desde hace 5 años la empresa se encuentra llevando adelante un proceso de deslocalización de su producción de software. En este sentido ha instalado una factoría en Argentina. A pesar de que la experiencia ha sido satisfactoria, la empresa aún detecta la necesidad de mejorar los procesos de producción de software. El objetivo de la empresa al colaborar en la resolución y validación de esta Tesis Doctoral es el de mejorar sus procesos de desarrollo A-GSD. Por otro lado, para los objetivos de esta Tesis Doctoral resulta valioso disponer de una fuente de experiencia real del personal de Assertum en proyectos A-GSD. Además de poder utilizar sus entornos de producción como entorno de pruebas de las soluciones propuestas en el ámbito de este trabajo. Tabla 1-1. Clasificación de los casos de estudio Objeto a validar Caso de estudio desarrollado Ontología Caso 1 - Tipificación de proyectos A-GSD Caso 2 - Descubrimiento de desafíos Caso 3 (Real) - Encuestas sobre tipos de proyectos A-GSD y sus desafíos Herramienta Caso 4 (Real) - Uso de AG-Advisor en el proyecto Alfa Caso 5 (Real)- Uso de AG-Advisor en el proyecto Beta A continuación se describen brevemente los casos de estudio realizados. El detalle de tales casos, incluyendo tanto los resultados obtenidos como las nuevas mejoras que fueron surgiendo a partir de cada uno de ellos, se describen detalladamente en el capítulo 4 de esta memoria de Tesis Doctoral. 1.3.1.1 Caso de estudios para la validación de la ontología Estos casos de estudio han sido diseñados específicamente para investigar si la ontología creada era correcta antes de ser usada en entornos reales. En este ámbito se han desarrollado dos casos de estudio de laboratorio (Casos 1 y 2) y uno real (Caso 3). La definición de casos de estudio como “de laboratorio” se fundamenta en que se han llevado a cabo en condiciones similares a las que se desarrolla un “experimento de laboratorio”, es decir bajo condiciones controladas
30. 34 Mariano Minoli y no reales. Los casos de estudio de laboratorio (Casos 1 y 2) se desarrollaron con los siguientes objetivos: verificar que la ontología definida en el ámbito de estas Tesis Doctoral estaba completa y detectar posibles inconsistencias, fallos, o carencias en la misma. Además se ha desarrollado un caso de estudio basado en entrevistas a jefes de proyecto de Assertum Tecnologías con el objetivo de validar el estado de la ontología en un entorno real (Caso 3). El aporte de la experiencia de los jefes de proyecto de Assertum Tecnologías ha sido valioso para validar la ontología propuesta desde el punto de vista de la gestión de este tipo de proyectos. 1.3.1.2 Casos de estudio para la validación de la herramienta Estos casos de estudio (Casos 4 y 5) han consistido en la utilización en un entorno real de la herramienta de explotación de la ontología definida en el ámbito de esta Tesis Doctoral, llamada AG-Advisor. Estos casos de estudio han sido desarrollados con la colaboración de los jefes de proyecto de Assertum Tecnologías en entornos A-GSD. La utilización de la herramienta AG-Advisor en entornos empresariales ha permitido medir el valor que aporta en proyectos A- GSD. 1.4 Estructura de la Tesis El resto de los capítulos de esta tesis, se organizan de la siguiente manera: • El Capítulo 2 proporciona un completo estado de la cuestión en la temática de esta Tesis Doctoral. En concreto, se presenta una revisión sistemática llevada a cabo cuyo objetivo principal ha sido la búsqueda del material existente sobre A-GSD así como la búsqueda de propuestas similares en esta área. • El Capítulo 3 presenta la solución propuesta en esta tesis: un marco de soluciones para A-GSD por medio de la creación e implementación de una ontología, que permita asistir a los profesionales en la selección de las mejores soluciones acordes a las características de sus proyectos. En la sección 3.1 se presenta la ontología, que agrupa las definiciones de cada uno de los conceptos. En la sección 3.2 se presenta la herramienta que permite la explotación del conocimiento de la ontología. • En el Capítulo 4 en este capítulo se presenta la validación del marco propuesto en esta Tesis Doctoral, mediante su aplicación a casos de estudio.
31. Introducción 35 • Por último, en el Capítulo 5 se concluye con un resumen de las principales contribuciones de esta tesis. Para ello, se proporciona un análisis de los resultados obtenidos y las publicaciones realizadas. Además, se plantean una serie de cuestiones que sirven para futuras investigaciones. • Además, en el apéndice A se presenta información detallada de la Revisión Sistemática por medio de una tabla que contiene todos los trabajos que han servido de base para la ontología. En el apéndice B se detalla la totalidad de las instancias de la ontología.
32. Estado del Arte
33. 2. Estado del Arte En este capítulo se presenta la revisión sistemática llevada a cabo en el ámbito de esta Tesis Doctoral y los resultados encontrados en la misma. La revisión realizada se centra en la búsqueda del material existente sobre A- GSD. Teniendo en cuenta la hipótesis planteada en esta Tesis Doctoral, ésta búsqueda ha sido conducida a través de un esquema Desafíos - Soluciones, es decir, buscando en diversas fuentes tanto soluciones y desafíos presentes en A- GSD, como relaciones existentes entre ellas. La misma búsqueda ha abarcado la existencia de propuestas similares en esta área, encontrando que las propuestas existentes abordan parcialmente este problema. Como se verá en las conclusiones de esta sección, no existe ninguna propuesta que permita sugerir soluciones específicas para A-GSD partiendo de las características de los proyectos. 2.1 Introducción A partir de la expansión de Internet, a mediados de los años 90, ha habido una creciente tendencia a la distribución geográfica de tareas relacionadas al desarrollo de software. Aunque existen referencias anteriores sobre este fenómeno [10] [73], no es sino hasta finales de los años 90, cuando esta nueva realidad se manifiesta en la comunidad científica. Dos de los autores pioneros en este campo son Erran Carmel [24] [23] y James Herbsleb [49] [52]. En ambos casos, sus primeros trabajos representan el reflejo de una tendencia en la industria, originada por cuestiones de negocio, y no por cuestiones metodológicas o de ingeniería del software. Herbsleb resume esta situación de manera muy precisa en su trabajo “Global Software Development” de 2001 [52]: “Durante las últimas décadas se ha puesto de manifiesto una tendencia constante e irreversible hacia la globalización de los negocios en general y del desarrollo de software en particular. Las fuerzas económicas están convirtiendo implacablemente a los mercados nacionales en mercados globales y la producción de nuevas formas de competencia y cooperación que traspasan las fronteras nacionales. Este cambio está teniendo un profundo impacto no sólo en la comercialización y distribución, sino también en la manera cómo se conciben los productos, y de cómo el software es diseñado, construido, probado y entregado a los clientes.”
34. 40 Mariano Minoli A partir de ese momento (2001) existen múltiples evidencias que demuestran un marcado incremento en los estudios de campo, análisis de desafíos y problemas, y soluciones de todo tipo para equipos GSD [93,23]. Esta lista crece aún más cuando, alrededor del año 2006, se comienza a contemplar el uso de metodologías ágiles en este tipo de entornos [119]. Con el objetivo de ordenar todo el conocimiento existente en relación con esta Tesis Doctoral, se llevó a cabo una revisión sistemática. En las siguientes secciones se presentan: el esquema de conocimiento Desafíos - Soluciones que se ha utilizado en esta revisión (sección 2.2); la revisión sistemática llevada a cabo (sección 2.3); y un resumen de los trabajos similares a nuestra propuesta obtenidos también del proceso de revisión (sección 2.4). 2.2 Distribución y Agilidad: Desafíos y Soluciones Como se ha descrito previamente en la introducción de este trabajo, uno de los problemas presentes en relación con la temática de esta Tesis Doctoral es la cantidad y diversidad de trabajos existentes, así como la poca relación entre ellos. Tal diversidad nos ha llevado a la necesidad de plantear, como paso previo a la revisión, un esquema que permita organizar todo el conocimiento encontrado. Teniendo en cuenta el objetivo de esta Tesis Doctoral, se ha decidido partir de un esquema conceptual que permita realizar un análisis que abarque desde el origen de los desafíos a los que se enfrentan los equipos A-GSD, ya sea por cuestiones de agilidad o de distribución, hasta sus soluciones. Esta decisión ha sido basada en trabajos anteriores en esta área [32,59,75]. De este modo se ha planteado un esquema de conocimiento dividido en tres grupos que se muestra en la Figura 2-1: Características de Proyectos (ágiles y distribuidos), Desafíos y Soluciones. Figura 2-1. Esquema de conocimiento básico de la revisión sistemática.
35. Estado del Arte 41 Obtener, clasificar, y modelar, todo el conocimiento de A-GSD acorde a este esquema, será la base para poder realizar un análisis sobre cuáles son las principales soluciones que pueden ser aplicadas según las características de agilidad y/o distribución existentes en cada equipo y proyecto. En las siguientes secciones se explica el significado de cada uno de los grupos de conocimientos identificados. 2.2.1 Características de proyectos distribuidos Este grupo conceptual contendrá las principales características de proyectos GSD. Las búsquedas en este sentido abarcan material que no solo esté relacionado con A-GSD, sino también con GSD (no ágil). La idea detrás de ello es identificar claramente aquellas características que impactan directa o indirectamente en los desafíos (o problemas) existentes en A-GSD. 2.2.2 Características de proyectos Ágiles Este grupo conceptual contendrá las principales características de proyectos Ágiles. Como se ha expresado en el capítulo 1, en su concepción el manifiesto ágil contiene conceptos a los cuales habría que prestar especial atención en entornos distribuidos [79]. 2.2.3 Desafíos Dentro de este grupo entran los trabajos que tratan sobre la problemática de equipos ágiles y distribuidos. En el esquema de conocimientos que se ha propuesto en la Figura 2-1 decimos que las características de proyectos ágiles y distribuidos originan desafíos. Estos desafíos representan todos los posibles problemas que pueden ocurrir en este tipo de proyectos. El objetivo durante la revisión es encontrar todos los trabajos que cataloguen estos problemas, sus categorías y variables. 2.2.4 Soluciones Usamos el término solución para englobar prácticas, herramientas o metodologías existentes. Dentro de este grupo se agruparán la mayor cantidad de soluciones propuestas en la actualidad; relacionándolas (siempre que sea posible) con los desafíos que intentan solucionar. En este sentido, la búsqueda se ampliará
36. 42 Mariano Minoli no solo a las bases de datos científicas, sino también a los repositorios de código libre. 2.3 Revisión Sistemática En esta sección se presenta la revisión sistemática que se ha llevado a cabo siguiendo el esquema definido anteriormente. Se incluye la descripción del proceso de la revisión sistemática así como los resultados de la revisión. El listado completo de los trabajos de referencia se puede encontrar en el anexo A de esta memoria. Para la revisión se ha utilizado el método de revisión de literatura sistemática propuesto por B. Kitchenham [65]. Las etapas seguidas pueden resumirse de la siguiente manera: • Planificación de la revisión • Ejecución de la revisión • Generación de informes sobre los resultados Durante la etapa de la planificación de la revisión se han llevado a cabo las siguientes actividades: formulación de las preguntas de investigación, determinación de los términos de búsqueda y determinación de las fuentes de información. A continuación se describen cada uno de estas actividades, seguido de la ejecución de la revisión y los resultados de la misma. 2.3.1 Preguntas de investigación La preparación de las preguntas de investigación ha sido guiada por el esquema de conocimiento presentado en la sección anterior. De este modo, las preguntas de investigación planteadas son las siguientes: • RQ1: ¿Cuáles son los conceptos clave relacionados a características de proyectos ágiles y distribuidos? • RQ2: ¿Cuáles son los conceptos clave relacionados a desafíos en proyectos A-GSD? • RQ3: ¿Cuáles son las soluciones y los conceptos clave relacionados a las soluciones para equipos A-GSD? • RQ4: ¿Existen trabajos que mapeen características de proyectos a desafíos y a soluciones?
37. Estado del Arte 43 2.3.2 Términos de búsqueda En la Tabla 2-1 se presenta la lista de términos que se han empleado para las búsquedas en los orígenes de datos. Se ha considerado además la utilización de sinónimos con el objetivo de abarcar la mayor cantidad de trabajos posible. Tabla 2-1. Orígenes de información utilizados durante la revisión sistemática Términos Sinónimos GSD Global Software Development Global Software Engineering Distributed software development Distributed teams Dispersed teams Multisite software development GSD GSE Agile Agile Scrum Extreme Programming Lean Crystal Family Agile Modeling Challenges Challenges Problems Difficulty Solutions Practice Methodology Framework Strategy Tool Software Program Technique
38. 44 Mariano Minoli De acuerdo con las palabras de búsqueda y sus sinónimos, se ha formado la siguiente consulta: ("Global Software Development" or "Global Software Engineering" or "Distributed software development" or "Distributed teams" or "Dispersed teams" or "Multisite software development" or "GSD" or "GSE") and ("Agile" or "Scrum" or "Extreme Programming" or "Lean" or "Crystal Family" or "Agile Modeling") and ("Challenges" or "Problems" or "Difficulty") and ("Practice" or "Methodology" or "Framework" or "Strategy" or "Tool" or "Software" or "Program" or "Technique"). Esta consulta ha sido ejecutada en todas las fuentes de información que serán presentadas en la siguiente sección. 2.3.3 Fuentes de información Para los efectos de este estudio, se ha decidido utilizar tres tipos de fuentes de información: (1) Bases de Datos Científicas (SpringerLink, IEEEXplore, Biblioteca Digital de la ACM y Google Scholars). (2) Congresos de referencia, se han utilizado las actas de la conferencia ICGSE y el XP Conference. Por último, con el objetivo de abarcar las herramientas propuestas por la comunidad no científica se han realizado búsquedas en los (3) Repositorios de Código (SourceForge.net, CodePlex.com y Google Code). En la Tabla 2-2 se presenta la lista de los orígenes utilizados. Tabla 2-2. Orígenes de información utilizados durante la revisión sistemática Tipo de origen de datos Definición (1) Bases de Datos Científicas SpringerLink IEEEXplore Biblioteca Digital de la ACM Google Scholars (2) Congresos de referencia ICGSE 2006 a 2011 XP Conference 2011 (3) Repositorios de Código Libre SourceForge.net CodePlex.com Google Code
39. Estado del Arte 45 Con el fin de estandarizar los resultados recuperados de las diferentes fuentes se han seguido las siguientes convenciones: • El año de la publicación de los trabajos de investigación, se ha equiparado con el año de registro del proyecto en los casos de repositorios de código libre. • Con el fin de hacer comparaciones estadísticas de las cantidades de publicaciones, teniendo en cuenta los diversos orígenes de datos, se ha decido equiparar los años correspondientes a las publicaciones con los años correspondientes a los proyectos que se encuentran en los repositorios de código. 2.3.4 Ejecución de la revisión En el momento de la ejecución de la revisión sistemática, se han ido obteniendo una serie de documentos sobre los que se han aplicado criterios de inclusión y exclusión, para determinar cuáles deberían ser incluidos en el proceso de análisis. El criterio de inclusión que se ha utilizado es realizar un análisis del título, el resumen y las palabras clave de los documentos obtenidos en la búsqueda. De esta manera, se ha determina si los documentos pertenecen al tema de la revisión sistemática y se los incluye como estudios primarios y relevantes de la misma. Todas las publicaciones potencialmente relevantes se analizaron de forma completa con el objetivo de catalogarlos según el esquema definido. 2.3.5 Resultados En esta sección se presentan los resultados generales de la ejecución de la revisión. Mayores detalles, así como discusiones sobre los mismos serán presentados en las secciones posteriores cuando se detalle las respuestas a cada una de las preguntas de investigación. 2.3.5.1 Resultados numéricos generales De los 243 trabajos identificados, el 7% trata sobre Características de Proyectos Ágiles, el 19% trata sobre Características de Proyectos Distribuidos, un 21% trata sobre desafíos A-GSD y un 53% propone Soluciones. La Tabla 2-3 resume los resultados totales de la revisión.
40. 46 Mariano Minoli Tabla 2-3. Orígenes de información utilizados durante la revisión sistemática Concepto Porcentaje de trabajos Total de trabajos Características de Proyectos Ágiles 7% 20 Características de Proyectos Distribuidos 19% 54 Desafíos 21% 62 Soluciones 53% 154 Es importante tener en cuenta que la mayor parte de los trabajos analizados incluían al menos dos conceptos. Es por ello que la suma de los porcentajes supera 100%. 2.3.5.2 Cronología de los trabajos encontrados Un análisis cronológico de la información encontrada se presenta en la Figura 2-2. En la misma puede verse que hay poca actividad relacionada a A-GSD antes de 2006. También se ha decidido hacer una distinción entre diferentes tipos de trabajo a fin de analizar la evolución. Figura 2-2. Distribución cronológica de los trabajos encontrados en la revisión. Esta distinción nos ha permitido concluir que, si bien entre 2006 y 2008 ha habido más actividad relacionada con los desafíos y prácticas, entre 2008 y 2010 la cantidad de propuestas relacionadas a herramientas ha crecido por sobre las demás.
41. Estado del Arte 47 2.3.5.3 Conceptos, instancias y relaciones entre instancias Con el fin de poder responder a las preguntas de investigación planteadas, el análisis de los trabajos se ha realizado tenido como objetivo la identificación de los principales conceptos en cada una de los grupos identificados en el esquema inicial. Sin entrar en las formalidades que implican la construcción de una ontología (que serán explicadas en el capítulo 3), en este punto ya ha sido necesario realizar una clara distinción entre qué es “concepto” y qué es “instancia de un concepto”, para cada uno de los conceptos identificados en los grupos. Esta distinción se ha llevado a cabo con vistas a la posterior construcción de la ontología. Las ontologías creadas serán discutidas a fondo en el capítulo 3. Sin embargo, con el objetivo de esclarecer el modo en que ha sido catalogada la información en esta revisión sistemática se propone el siguiente ejemplo. Figura 2-3. Ejemplo de concepto e instancia con sus relaciones En la Figura 2-3 puede se puede ver el concepto “Regla”. Los trabajos en los cuales ha sido encontrado dicho concepto, en este caso los trabajos [W031] y [W090] y una instancia. La instancia tiene un código, que la identifica y permite relacionarla con otras instancias; y una descripción. En este caso, se puede decir que el concepto “Regla”, tiene una instancia que es: “si un proyecto GSD utiliza prácticas ágiles, entonces deberían usarse otros mecanismos de coordinación distintos a ajuste mutuo, supervisión directa o estandarización”. La última columna presenta una lista de instancias (de otros conceptos) con las cuales ésta está relacionada. Por ejemplo esta instancia, la instancia número [I0385] está relacionada con otras instancias, las [I0007], [I0028], [I0058], [I0059], [I0060] e [I0061]. Las cinco primeras relaciones están referenciadas en el trabajo [W037] y la última en el trabajo [W090]. De esta manera se logró registrar, para cada instancia, los trabajos en los cuales se hacía referencia a ella, sus relaciones con otras instancias y los trabajos en los cuales estaban estas relaciones. De esta manera se puede ver como a través del análisis en profundidad de cada trabajo encontrado, se ha logrado construir una red de relaciones entre los conceptos y sus instancias. Esta red de relaciones ha sido registrada
42. 48 Mariano Minoli sistemáticamente en una base de datos con el objetivo de llevar esta estructura a la ontología a definir. Tablas de trabajos e instancias y las referencias a trabajos e instancias En este trabajo de Tesis Doctoral se han incluido dos apéndices conteniendo la lista completa de trabajos (Anexo A) y la lista completa de instancias (Anexo B). Los trabajos están numerados con un identificador incremental y una letra “W” de prefijo. En adelante, cada vez que se haga referencia a un trabajo obtenido durante la revisión sistemática, se hará de la forma: [W + código]. Por ejemplo, para hacer referencia al trabajo “Coordinating mechanisms for Agile Global Software Development” de código 031 se referenciará [W031]. Se empleará el mismo mecanismo con las instancias, en este caso usando la letra I. Así. Una referencia a la instancia [I0385] denota una referencia a la instancia que se ha explicado en la sección anterior. En la siguiente sección se explicarán los resultados a las preguntas de investigación. En estos resultados se incluirán referencias como las que se ha explicado a los trabajos e instancias. 2.3.6 Respuestas a las Preguntas de Investigación En esta sección se presentan las respuestas a las preguntas planteadas al inicio de la revisión sistemática. Para cada una de las preguntas se exponen las respuestas y discusiones sobre éstas. 2.3.6.1 RQ1: ¿Cuáles son los conceptos clave relacionados a características de proyectos ágiles y distribuidos? El análisis de los trabajos que de alguna manera tratan las características de proyectos ágiles, distribuidos o ágiles y distribuidos a la vez, nos he llevado a la conclusión de que existen múltiples conceptos que pueden combinarse en una gran diversidad de configuraciones. Para mayor claridad se ha decidido presentar y discutir por separado las características de proyectos ágiles de las de distribuidos. 2.3.6.1.1 Conceptos claves relacionados a características de proyectos ágiles Los principales conceptos identificados en lo referente a las características de proyectos ágiles se presentan en la Tabla 2-4.
43. Estado del Arte 49 Tabla 2-4. Relación de conceptos sobre características de proyectos ágiles Concepto Definición Valor Los valores ágiles definen de manera genérica el espíritu del manifiesto ágil, sin entrar en detalle de cómo llevarlo a la práctica. Kent Beck los define de la siguiente manera [14]: “Los valores ágiles son los criterios a gran escala que usamos para juzgar lo que vemos, pensamos y hacemos.” Principio Los doce principios ágiles llevan a un plano más concreto los valores expresados. En ellos ya se encuentran directivas concretas de cómo actual ante el cliente, los cambios y el equipo entre otras cosas. Con el objetivo de lograr una mejor contextualización de los resultados, a continuación se exponen algunas consideraciones sobre los conceptos definidos. Los valores y principios ágiles Los conceptos valores y principios ágiles han sido extraídos directamente del manifiesto ágil [79]. Éstos resumen las características comunes a todos los marcos, metodologías y prácticas ágiles. Los cuatro valores del desarrollo ágil constituyen los cuatro pilares del mismo. Estos valores encuentran citados en la página principal del manifiesto ágil, como se ve en la Figura 2-5. Estos valores favorecen ciertos aspectos de la gestión de proyectos de desarrollo de software en detrimento de otros.
44. 50 Mariano Minoli Figura 2-4. Página principal del manifiesto ágil Por su parte, los doce principios ágiles, disponibles en la misma Web del manifiesto [79], presentan acciones concretas para llevar a la realidad los cuatro valores ágiles. A continuación se presentan los doce principios ágiles, se ha decidido incluir todos los principios porque todos ellos tienen un alto impacto en entornos distribuidos y serán usados de referencia más adelante en este trabajo: • Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. • Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. • Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. • Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. • Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. • El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. • El software funcionando es la medida principal de progreso. • Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. • La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. • La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. • Las mejores arquitecturas, requisitos y diseños emergen de equipos auto- organizados. • A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
45. Estado del Arte 51 En 2005, el grupo encabezado por Alistair Cockburn y Jim Highsmith escribió un apéndice de los principios de gestión de proyectos, la Declaración de Interdependencia, para orientar la gestión de proyectos de software de acuerdo a los métodos de desarrollo ágil [8]. A continuación se presentan estos principios: • Aumentar la rentabilidad de la inversión por lo que el flujo continuo del valor de nuestro enfoque. • Obtener resultados fiables mediante la participación de clientes en las interacciones frecuentes y la propiedad compartida. • Esperar la incertidumbre y la gestión para ella a través de iteraciones, la anticipación y la adaptación. • Dar rienda suelta a la creatividad y la innovación mediante el reconocimiento de que las personas son la fuente última de valor, y crear un ambiente donde puedan hacer la diferencia. • Aumentar el rendimiento a través de la responsabilidad del grupo por los resultados y la responsabilidad compartida para la efectividad del equipo. • Mejorar la eficacia y fiabilidad a través de estrategias específicas a ciertas situaciones, procesos y prácticas. 2.3.6.1.2 Conceptos clave relacionados a características de proyectos distribuidos Por otra parte, los principales conceptos identificados en lo referente a las características de proyectos distribuidos se presentan en la Tabla 2-5. Tabla 2-5. Relación de conceptos sobre características de proyectos distribuidos Concepto Definición Distancia Temporal Es una medida del desplazamiento en el tiempo experimentado por dos actores que deseen interactuar [5]. Distancia Geográfica La distancia geográfica es una medida del esfuerzo requerido por un actor para visitar a otro y puede ser visto como la reducción de la intensidad de la comunicación [5], especialmente cuando la gente experimenta problemas con los medios de comunicación y tienen dificultades para encontrar un sustituto lo suficientemente buena a la interacción cara a cara [108].
46. 52 Mariano Minoli Concepto Definición Distancia Cultural Es una medida de la comprensión de un actor de los valores y las prácticas normativas del otro actor [5]. Distancia Idiomática Es un subconjunto de la distancia cultural [55]. Distancia Organizacional También llamada distancia institucional, se refiere a tener un equipo distribuido en diferentes empresas o departamentos de una empresa. Motivaciones para usar equipos distribuidos Se refiere a las causas por las cuales las empresas trabajan en configuraciones distribuidas. Modelo de negocio offshore outsoursing Cuando una organización contrata determinadas tareas a otra, pero en el mismo ámbito geográfico. Modelo de negocio offshore insourcing Cuando una organización contrata determinadas tareas a otra y además las tareas se no se realizan en la empresa contratada. Modelo de negocio onshore outsoursing Se corresponde con el típico departamento interno de IT. Sinónimos: Internal. Modelo de negocio onshore insoursing Cuando la misma organización decide llevar a cabo determinadas tareas en ubicaciones distintas. Elementos de Distribución Diferentes elementos intervinientes en los proyectos de software pueden ser distribuidos. Personas Se refiere a la distribución de personas Tareas Se refiere a la distribución de tareas Con el objetivo de lograr una mejor comprensión de los resultados, a continuación se exponen algunas consideraciones sobre los conceptos definidos. La distancia La distancia es el principal concepto a considerar dentro de las características de proyectos distribuidos [55]. En líneas generales, la bibliografía analizada trata de manera muy completa estos aspectos [55, 5]. En este sentido, los autores citan interesantes cuestiones que servirán para entender el origen de los desafíos que se analizarán más adelante. A continuación se mencionan algunas de estas consideraciones. Según lo expresado por Sarker, en su trabajo “Implications of space and time for distributed work”, [105]:
47. Estado del Arte 53 “La distancia temporal puede ser vista como la reducción de las oportunidades de colaboración en tiempo real, y de como el tiempo de respuesta se incrementa cuando las horas de trabajo en lugares remotos que no se superponen”. Tan importante es el impacto de la distancia temporal en la organización de equipos de desarrollo de distribuidos, que los autores del libro “Practical Guide to Distributed Scrum” han decidido dedicarle un espacio importante citando ejemplos y categorizaciones [125]. De este trabajo se cita la siguiente categorización: “Distribuido con superposición de horas de trabajo: Con este modelo, los miembros del equipo tienen al menos algunas horas durante cada día de trabajo normal en el que interactúan unos con otros. Distribuido sin superposición de horas de trabajo: equipos que no tienen oportunidad de interactuar entre ellos en horas normales de trabajo y viven en el nivel más exigente de desafíos de comunicación.” Por otro lado, en lo referente a la distancia geográfica, resulta especialmente útil la distinción realizada por Holmstrom en [55]: “La distancia geográfica se mide mejor en facilidad de traslado que en kilómetros. Dos ubicaciones con una conexión aérea directa y vuelos regulares pueden ser consideradas cercanas, aunque separadas por grandes distancias, pero lo mismo no se puede decir de las dos localidades que están geográficamente cerca, pero con mala infraestructura de transporte”. Como se verá más adelante, esta consideración cobra especial importancia con una de las prácticas más recomendadas para equipos A-GSD, el uso de “Embajadores culturales” que consiste en el intercambio de miembros de todos los niveles del equipo entre las distintas ubicaciones geográficas. En [W048] Alistair Cockburn presenta una interesante analogía entre el efecto de la distancia en la comunicación relacionándola con la dispersión del gas o el calor. Esta analogía sirve para visualizar la pérdida de calidad de la comunicación cuando dos personas se encuentran en la misma sala, en salas separadas, en edificios separados o en ciudades distantes. O lo que es lo mismo decir, como afecta la distancia (geográfica) a la comunicación. Cockburn se apoya en esta metáfora para presentar el concepto de “Comunicación Osmótica”, según el cual la proximidad física de las personas facilita el intercambio de información, incluso sin quererlo. En palabras del autor: “En algunos casos, se registra lo suficiente acerca de una conversación para poder desarrollar lo que se necesita en memoria [...] Esta recepción de
48. 54 Mariano Minoli información sin prestar atención es como el proceso de ósmosis, en la que se filtra la sustancia de un sistema.” Para finalizar, se citan dos reflexiones que se utilizarán más adelante, cuando se combinen distancia con agilidad: “La distancia cultural puede tener un gran efecto en cómo las personas interpretan una determinada situación, y cómo reaccionan ante ella. Es una dimensión compleja, que involucra la cultura organizacional, la cultura nacional y el lenguaje, la política y las motivaciones individuales y la ética del trabajo. Es posible tener un bajo nivel de distancia socio-cultural entre dos actores de diferentes orígenes nacionales y culturales que comparten una cultura común de organización, pero a una distancia elevada entre dos individuos de la misma nacionalidad pero con antecedentes de compañías muy diferentes [71].” “La distancia geográfica puede implicar una mayor distancia cultural. Sin embargo, la distancia cultural puede ser grande, incluso con la distribución geográfica de baja [55].” Como se puede apreciar, el análisis de estas variables describe la diversidad de configuraciones de proyectos A-GSD y los desafíos que se presentarán en posteriores secciones de este trabajo. Elementos de Distribución Otra importante característica de la distribución consiste en los elementos a distribuir. Como elementos se pueden entender sobre todo a las personas, pero no solo a éstas. También es importante definir cómo serán distribuidas las tareas a realizar. Estas definiciones afectarán a la estructura del equipo. Por ejemplo, es muy diferente dividir a los equipos por tareas de desarrollo (programación, testeo, etc.) que por funcionalidades a construir. Estas decisiones afectarán sobre todo a la coordinación del equipo [49]. Más adelante se verá que la coordinación es el segundo aspecto más importante a tratar en equipos A-GSD. En lo referente a la distribución de tareas, se destaca la opinión de Larman [75], quién expresa la siguiente recomendación: “Utilizar grupos de trabajo co-localizados. Evitar la dispersión de características. Evitar la organización de equipos por tipo de tarea. Evitar "las disciplinas offshore".” En el capítulo 3 se analizará como impacta esta dispersión de elementos (personas y tareas) en entornos ágiles. Modelo de negocio
49. Estado del Arte 55 Como se ha mencionado en la introducción, la deslocalización de tareas en GSD ha sido conducida por motivaciones económicas [52] y no metodológicas. En este sentido resulta importante analizar las diferentes variaciones existentes para los modelos de negocio. Robinson y Ravi proporcionan un marco para clasificar los proyectos GSD en dos dimensiones de acuerdo al modelo de negocio: la estructura de la relación (on/off) y ubicación geográfica de trabajo (source/shore) [100]. En la Figura 2-6 se presenta una versión simplificada de esta estructura de modelos de negocio presentada por Damian [34]. Figura 2-5. Modelos Estructura de modelos de negocio de Damian [34] La estructura presentada por los autores contempla dos dimensiones: • El control • La ubicación geográfica En referencia a la primera dimensión (control), la categorización divide a los proyectos de software desarrollados en el marco de un acuerdo de externalización, outsourcing, es decir por personal externo a la empresa. El caso contrario es insourcing, donde el equipo de desarrollo de software es personal de software perteneciente a la empresa. Por otro lado, con respecto a la dimensión de ubicación geográfica, los proyectos pueden llevarse a cabo en una modalidad offshore (normalmente en un país diferente de la contratación organización) u onshore (que se encuentra en el mismo país o en un país vecino). Otros autores relacionan esta dimensión con la distancia temporal y no geográfica. Es importante considerar que la distancia temporal (distintos husos horarios) siempre implica distancia geográfica. En este sentido, incluso se podría generalizar el concepto on/off-shore relacionándolo a la “distancia”, sea cual sea el tipo. Como en este trabajo se trata a la distancia de
50. 56 Mariano Minoli manera completa, como un concepto independiente, para el caso de la clasificación on/off-shore del modelo de negocio se limitará a relacionarlo a la distancia geográfica. Motivaciones para la distribución En general, las mayores motivaciones detrás de la deslocalización de tareas en GSD son económicas [52] y no metodológicas. El análisis de las motivaciones para la distribución resulta importante para poder plantear soluciones que las respeten. Los autores del trabajo “Insights into an Agile Adventure with Offshore Partners” [113] citan estas motivaciones como las que los han llevado a buscar socios de negocio offshore en la India: • “Flexibilidad en los Recursos, fue visto como deseable tener la capacidad de expandir y contraer con facilidad el número de recursos. • Habilidades disponibles, hemos tenido gente buena a nivel local, pero siempre fue difícil reclutar a las personas adecuadas con las habilidades necesarias para complementar los que ya teníamos. Sin embargo, la India, con su abundancia de profesionales capacitados de TI apareció para resolver este problema. • Ahorro en el Coste, el coste de tener los recursos en modalidad offshore era más rentable que los recursos locales. • Profesionalidad, un socio con Nivel 5 CMM, como el que elegimos parecía ofrecer el ambiente que nos permita producir software a un nivel predecible.” La importancia de conocer las motivaciones para llevar adelante proyectos distribuidos radica permitirá construir una ontología que recomiende soluciones respetando estas motivaciones. Ahora que ya se ha analizado las principales características de proyectos ágiles y distribuidos por separado, en la próxima sección se analizan los principales desafíos que conlleva su combinación. 2.3.6.2 RQ2: ¿Cuáles son los conceptos clave relacionados a desafíos en proyectos A-GSD? Para el caso de los desafíos, se han identificado conceptos que permiten relacionar cada desafío bien al tipo de interacción, o bien, a aspectos del proceso de desarrollo de software empleado.
51. Estado del Arte 57 Los principales conceptos identificados en lo referente a los desafíos se presentan en la Tabla 2-6. Tabla 2-6. Relación de conceptos sobre Desafíos Concepto Definición Desafío Representan los problemas o inconvenientes a los que se enfrentan los integrantes de un equipo A-GSD Comunicación Representa todos los aspectos relacionados a la inter- conexión de las personas. Coordinación Representa todos los aspectos relacionados a la organización de las tareas y las personas en equipos A- GSD. Colaboración Es el acto de integración de cada tarea en cada unidad organizativa, lo que la unidad contribuye al objetivo general Control Es el proceso de adhesión a los objetivos, políticas, normas, o los niveles de calidad. Con el objetivo de lograr una mejor comprensión de los resultados, a continuación se exponen algunas consideraciones sobre los conceptos definidos. 2.3.6.2.1 Desafíos a los que se enfrentan los equipos de Desarrollo Global Ágil. Para comprender el origen y la magnitud de estos desafíos se puede analizar en el ChAOS Report de 1999 [111]: “La mayoría de las técnicas de gestión de proyectos fueron diseñadas para equipos co-ubicados. Estas técnicas pueden resultar ineficaces en desarrollo global, multi-sitio. Los CIOs entienden que la gestión de una fuerza de trabajo de un proyecto distribuido no depende de la tecnología. Desde el correo electrónico hasta los teléfonos móviles, las herramientas de comunicación abundan. Una vez más, las personas y los procesos están en el centro de gestión de los proyectos, no las herramientas y la tecnología. ... Las principales prioridades de gestión son la construcción de equipos distribuidos con un mínimo de tiempo cara a cara, definiendo claramente el trabajo, la medición de la productividad del trabajador
52. 58 Mariano Minoli remoto y la gestión de comunicaciones de los empleados a través de zonas horarias.” La gestión de proyectos de desarrollo A-GSD cuenta con más retos y dificultades que los tradicionales (co-ubicados). La principal razón citada por investigadores y profesionales es que en un desarrollo distribuido ágil existen nuevas variables y los problemas relacionados se agregan al problema de por sí complejo de proyecto de software de gestión: la distancia [32]. En la bibliografía se han encontrado múltiples trabajos que tratan de manera exhaustiva los desafíos en equipos A-GSD [54,99,88,36,32,55,70]. De todos ellos, se ha decido incluir un resumen presentado por el trabajo titulado “Can Distributed Software Development be Agile?” [99]. En este trabajo, los autores presentan el cuadro que se muestra en la Figura 2-7. Figura 2-6. Modelos Resumen de desafíos A-GSD [99] Como se puede apreciar en la Figura 2-7, los autores presentan una lista de contradicciones que requieren especial atención en A-GSD: • Necesidad de comunicación frente a la calidad de comunicación. • Requisitos de calidad fijos frente a requisitos evolutivos. • Procesos orientados a las personas frente orientados al control. • Acuerdos formales frente informales. • La falta de cohesión del equipo. En las próximas secciones se analizarán los aspectos que más relevancia cobran en relación a los desafíos de proyectos A-GSD: la comunicación, la coordinación, la colaboración y el control de los equipos. El análisis de estos
53. Estado del Arte 59 aspectos permitirá comprender en profundidad los desafíos de este tipo de equipos. 2.3.6.2.2 La comunicación en equipos de Desarrollo Global Ágil. Directa o indirectamente la mayoría de los trabajos encontrados tratan a la comunicación como el aspecto más importante a tener en cuenta en A-GSD. El tema es tratado de manera recurrente en la bibliografía analizada [87,99,67,69,12]. El análisis de estos trabajos nos ha llevado a la construcción de una taxonomía que será presentada en el próximo capítulo. El problema de la comunicación en equipos A-GSD es bien resumido en [99]: “El desarrollo distribuido de software se basa en mecanismos formales, tales como el diseño detallado de arquitectura y los planes para abordar los riesgos de la comunicación del equipo que se derivan de distancia geográfica. Como el desarrollo ágil se basa más en las interacciones informales que la documentación explícita, esto plantea un verdadero desafío en un entorno distribuido. ¿Cómo podemos lograr un equilibrio en la formalidad de la comunicación en entornos distribuidos ágil?” El estudio en profundidad del problema de la comunicación permitirá resolver estos desafíos a través del empleo de las mejores soluciones que se ajusten a las distintas situaciones. 2.3.6.2.3 La coordinación en equipos de Desarrollo Global Ágil. La coordinación, después de la comunicación, es el segundo aspecto que más trabajos presenta en la bibliografía [49,26,16]. Los autores del trabajo [16] resumen estos desafíos de la siguiente manera: “La creciente externalización de desarrollo de software en equipos ágiles conduce a varias preguntas: • ¿Qué efectos tiene el cambio de equipos co-localizados a distribuidos en relación a la coordinación de las tareas? • ¿Cuáles son las estrategias de coordinación desplegadas por los equipos con el fin de garantizar la agilidad en el desarrollo de software en entornos distribuidos? ” Por su parte, en el trabajo titulado “On Coordination Mechanisms in Global Software Development” [26], los autores presentan y discuten estos mecanismos de coordinación:
54. 60 Mariano Minoli • Estructura centralizada • Identificación temprana de las dependencias • Documentación • Gestión del cambio, configuración y procesos de integración • Compromiso periódico • Compilaciones diarias • Herramientas de comunicación • Reuniones periódicas Como se verá en la siguiente sección, todos estos desafíos pueden ser tratados utilizando soluciones que se adecuen a las características de los mismos. 2.3.6.2.4 Colaboración en equipos de Desarrollo Global Ágil. A pesar de que la mayor parte de los autores que hacen referencia a este aspecto, lo relacionan con la comunicación, éste es en sí un aspecto que merece un tratamiento por separado. Existe una importante área de investigación relacionada a la colaboración en equipos de desarrollo de software en general y también hay varios trabajos que tratan el tema particularmente en equipos distribuidos. Aunque hay menos trabajos que traten el tema en equipos A-GSD, los que hay aportan valiosas conclusiones y soluciones. Dentro de los trabajos más destacados en esta área, se pueden citar a [W002], [W082], [W190], [W202] y [W206]. Por ejemplo en [W002] se proponen las siguientes prácticas: • Sincronización de los principales hitos. • Entregas frecuentes. • Establecimiento de enlaces peer-to-peer (de pares). • Prácticas de resolución de conflictos. • Prácticas de informar y seguimiento. • Prácticas de construcción de relaciones. Estas prácticas tienen el objetivo de mejorar la colaboración en el equipo, a pesar de la distancia. Otro de los trabajos que realiza significativos aportes al área de la colaboración (en este caso solo para GSD) es “Global Software Development and Collaboration: Barriers and Solutions” [W082]. En este trabajo los autores presentan un mapeo entre los principales problemas relacionados a la colaboración y algunas soluciones.
55. Estado del Arte 61 2.3.6.2.5 Control en equipos de Desarrollo Global Ágil. A diferencia de lo que ocurre con los aspectos de comunicación, coordinación y colaboración en equipos A-GSD, sobre el aspecto de control se ha encontrado menos información. Los trabajos [W012] [W018] tratan este tema. De acuerdo a lo expuesto en [W018]: “El proceso de control se refiere a los mecanismos de gestión e información puestos en marcha para asegurarse de que una actividad de desarrollo está avanzando. Está relacionado con la gestión de proyectos y por lo tanto el desarrollo de las estructuras formales necesarias garantía de software en tiempo, presupuesto y de la calidad deseada.” Por lo encontrado, se concluye que un mayor desarrollo en este tema sería un aporte necesario a los equipos A-GSD. Si bien es cierto que algunas de las prácticas A-GSD existentes aportan a este aspecto (como por ejemplo las Distributed Scrum Retrospectives), no existen estudios profundos del impacto de la agilidad y la distancia en este aspecto. 2.3.6.3 RQ3: ¿Cuáles son los conceptos clave relacionados a las soluciones para equipos A-GSD? Las soluciones que propone la bibliografía se presentan de diferentes maneras, pueden ir desde simples prácticas hasta completas metodologías. En la Tabla 2-7 se presentan estos conceptos. Tabla 2-7. Relación de conceptos sobre Soluciones Concepto Definición Solución Una solución describe de manera genérica a una práctica, una metodología, una regla o una herramienta. Práctica Representan prácticas individuales. Metodología Representan una agrupación de prácticas y su aplicación en determinadas circunstancias. Ejemplo: Scrum distribuido. Herramienta Representan las herramientas tecnológicas que pueden utilizar los integrantes de equipos A-GSD. Las herramientas pueden ser Hardware o Software o una combinación de ambos. Estrategia Representa la estrategia de soluciones. Puede ser centralizada o distribuida.
Self managing an empirical study of the practice in agile teams
UML jgarzas componentes despliegue
Diagramas de Secuencia y colaboración en UML
Tesis Doctoral (Ph.D.). 2004. CONOCIMIENTO EN DISEÑO DE MICRO ARQUITECTURAS ...
A case study of software process improvement with CMMI‐DEV and Scrum in Spani...
An ontology for microarchitectural design knowledge (published in IEEE Softwa...

References: Resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución