Tatiana Alejandra Oquendo Garzón

Transcripción

1 CIS0930IS06 SWAPyME: Guía metodológica para la gestión de proyectos de software, en Pymes que no son fábricas de software, por medio de metodologías ágiles Tatiana Alejandra Oquendo Garzón PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2011

2 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> CIS0930IS06 SWAPyME: Guía metodológica para la gestión de proyectos de software, en Pymes que no son fábricas de software, por medio de metodologías ágiles Autor: Tatiana Alejandra Oquendo Garzón MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS Director Ingeniera Angela Paola Ramírez Pinilla, Msc. Jurados del Trabajo de Grado <Nombres y Apellidos Completos del Jurado > <Nombres y Apellidos Completos del Jurado > Página web del Trabajo de Grado PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. Diciembre, 2011 Página 2

3 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS Rector Magnífico Joaquín Emilio Sánchez García S.J. Decano Académico Facultad de Ingeniería Ingeniero Luis David Prieto Martínez Decano del Medio Universitario Facultad de Ingeniería Padre Sergio Bernal Restrepo S.J. Director (E) de la Carrera de Ingeniería de Sistemas Ingeniero César Julio Bustacara Medina Director Departamento de Ingeniería de Sistemas Ingeniero César Julio Bustacara Medina Página 3

4 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Artículo 23 de la Resolución No. 1 de Junio de 1946 La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia Página 4

5 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación AGRADECIMIENTOS Página 5

6 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> CONTENIDO LISTA DE IMÁGENES...8 LISTA DE TABLAS...9 I DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO...15 I.1 Oportunidad, Problemática y Antecedentes...15 I.1.1 Descripción del contexto...15 I.1.2 Formulación del problema que se resolvió...17 I.1.3 Justificación...18 I.1.4 Impacto esperado...19 I.2 Descripción del Proyecto...20 I.2.1 Visión global...20 I.2.2 Objetivo general...20 I.2.3 Objetivos específicos...20 I.2.4 Método que se propuso para satisfacer cada fase metodológica...20 II MARCO TEÓRICO...22 II.1 Marco Contextual...22 II.1.1 Metodologías ágiles...22 II.1.2 Declaración de interdependencia...23 II.1.3 Manifiesto ágil...23 II.1.4 Proceso de las metodologías ágiles...25 II.1.5 Descripción de las metodologías ágiles...27 II.1.6 Comparación de metodologías...35 II.2 Marco Conceptual...38 II.2.1 Agilidad...38 II.2.2 Desarrollo ágil de software...40 Página 6

7 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II.2.3 Metodología...41 II.2.4 Producto...41 II.2.5 Proyecto...41 II.2.6 Calidad...42 II.2.7 Calidad ágil...42 II.2.8 Productividad...44 II.2.9 Productividad ágil...44 III DESARROLLO DEL TRABAJO...46 IV POST-MORTEM...54 IV.1 Metodología propuesta vs. Metodología realmente utilizada...54 IV.2 Actividades propuestas vs. Actividades realizadas...55 V RESULTADOS Y REFLEXIÓN SOBRE LOS RESULTADOS...56 VI CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS...59 VI.1 Conclusiones...59 VI.2 Recomendaciones...60 VI.3 Trabajos Futuros...60 VII REFERENCIAS BIBLIOGRÁFICAS...62 VIII ANEXOS...66 VIII.1 Anexo 1. Guía metodológica SWAPyME...66 VIII.2 Anexo 2. Formato de evaluación...66 VIII.3 Anexo 3. Perfiles de los expertos...66 VIII.4 Anexo 4. Método de captura y análisis de resultados...66 Página 7

8 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> LISTA DE IMÁGENES Imagen 1. Resultados del informe "Chaos Report 2009"...15 Imagen 2. Razones para la adopción de prácticas ágiles...19 Imagen 3. Método propuesto...21 Imagen 4. Proceso de metodologías ágiles...27 Imagen 5. Metodologías ágiles más usadas...27 Imagen 6 Qué es ágil...40 Imagen 7. Ciclo de la metodología...47 Imagen 8. Resultados perspectiva contenido...57 Imagen 9. Resultados perspectiva calidad...58 Imagen 10. Resultados perspectiva productividad...58 Página 8

9 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación LISTA DE TABLAS Tabla 1. Definición de las metodologías...29 Tabla 2. Enfoque de las metodologías...30 Tabla 3. Roles de las metodologías...31 Tabla 4.Valores de las metodologías...31 Tabla 5. Prácticas de las metodologías...33 Tabla 6. Principios de las metodologías...35 Tabla 7. Comparación de metodologías...37 Tabla 8. Análisis comparativo de las metodologías...37 Página 9

10 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> ABSTRACT Nowadays, SMC's (Small and Midsize Companies) on the service sector manage software development projects which commonly cannot achieve enough quality, nor meet the scheduled delivery times for the final product they develop, mainly because they lack of a structured management for this kind of projects, outsource software factories which use complex and heavy methodologies, or IT resources involves deeply into implementation details, augmenting their own responsibility over tasks that should be accomplished by the outsourcing. This thesis work proposes a methodology guide to provide concepts and practical elements about agile methodologies, to achieve greater productivity on the project's development and ensure overall quality over the delivered product. RESUMEN Actualmente las Pymes del sector de servicios, gestionan proyectos de desarrollo de software que típicamente no consiguen calidad y/o no cumplen con los tiempos de entrega en el producto final, debido a que no tienen una gestión estructurada de este tipo de proyectos, contratan fábricas de software que tienen metodologías complejas y/o el recurso TI se involucra en detalles de la implementación, incrementando su responsabilidad en tareas propias de la empresa contratada. Este trabajo de grado propone una guía metodológica, para proporcionar elementos conceptuales, permitiendo aumentar la productividad en el desarrollo del proyecto y asegurar la calidad del producto entregado. Página 10

11 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación RESUMEN EJECUTIVO Hoy en día, en el entorno competitivo en que se desenvuelven las empresas, donde los servicios que ofrecen al cliente puede ser una diferencia entre consolidar el negocio o desaparecer los proyectos, nace la visión del proyecto, particularmente informático, como una respuesta para fortalecer el portafolio de la empresa y/o la capacidad operativa para mantenerse en el mercado. El fracaso en los proyectos genera pérdidas relacionadas principalmente con los factores tiempo y dinero, por lo que los proyecto deben planearse y ejecutarse teniendo en cuenta que se desarrollan para obtener mejoras significativas en la empresa, manteniendo el cumplimiento de aspectos de calidad, costo y tiempo, y/o habilitando en lo posible, futuros saltos tecnológicos para atender necesidades inminentes del negocio o el mercado; siendo ésta la gestión adecuada de un proyecto, requiere habilitar los aspectos relacionados con la formulación adecuada de las necesidades y herramientas disponibles y controlar los aspectos del entorno que determine los resultados obtenidos en la ejecución del mismo. Es decir, los proyectos fracasan a causa del uso de procesos que prestan más importancia a la cantidad de artefactos que a los resultados y, particularmente para las Pymes, el costo de proyectos no exitosos que pueden comprometer la estabilidad del negocio. De esta forma, se vio la necesidad de plantear una mejor forma de abordar las metodologías usadas y que debía tomarse un camino para dar valor a las cosas más importantes atenuando lo menos importante, debido a que esto estaba absorbiendo gran cantidad de tiempo valioso y produciendo pocos beneficios. Sin embargo, actualmente las Pymes cuyo enfoque de negocio no está relacionado con el desarrollo de software y que por tanto requieren de outsourcing, para proyectos informáticos, aún tienen en su gestión de proyectos informáticos, actividades que no son esenciales para su negocio y que, adicionalmente, exigen un alto nivel de involucramiento por parte de TI en la implementación de los proyectos. La atención de detalle en el ciclo de implementación le corresponde a recursos especializados en el tema, que además de tener el conocimiento suficiente en cuanto a la gestión de proyectos, al presentarse problemas de tiempo y/o alcance del proyecto, deben llevar a cabo funciones que Página 11

12 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> deberían ser ejecutadas por las fábricas de software. Como consecuencia de esto, al interior de las empresas se generan retrasos en los procesos críticos, ocasionando el desenfoque parcial en la atención del negocio, además del aumento de la carga operativa, dada la lentitud con la cual se atienen los requerimientos gestionados en las áreas de TI. Por esta razón, no se ha logrado el equilibrio entre las necesidades presentadas por el cliente, la gestión esperada de TI y el servicio de implementación de soluciones de software. Debido a esto, las empresas desarrolladoras de software, actualmente, ya se han involucrado en la realización del cambio en la percepción del tiempo, alcance y calidad de los productos que van a ser entregados, de la búsqueda de nuevas y mejores estrategias, y de lograr mayor eficiencia y efectividad en todo el ciclo de vida del proyecto, lo que le permitió tomar fuerza a la ideología enfocada en solucionar los problemas y suplir las necesidades de los clientes en el menor tiempo posible, lo que lleva a pensar en que en la evolución del desarrollo del software, no sólo se ha tenido la preocupación de mejorar la calidad de los productos entregados, sino también que el tiempo en que se lleve a cabo el desarrollo sea menor, disminuyendo costos y así mismo llevando a cabo un proceso más eficiente, apuntando al objetivo de la entrega en períodos de tiempo específicos, establecidos de antemano. Como respuesta, surge una amplia gama de alternativas metodológicas de prácticas ágiles, que nacen como alternativa a las metodologías formales, desarrolladas con el fin de contrarrestar el carácter normativo y la fuerte dependencia de planificaciones detalladas que tienen las metodologías formales, consideradas excesivamente pesadas y rígidas. Lo cual fundamenta la propuesta de la Guía metodológica SWAPyME, que busca tomar los mejores elementos en la gestión ágil de proyectos y desarrollo, proporcionando a los gestores de proyectos los elementos conceptuales que les permita aumentar la productividad en el desarrollo de proyectos y asegurar la calidad del producto entregado, contribuyendo de forma activa en el ciclo de vida del proyecto y del producto desarrollado. Página 12

13 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación INTRODUCCIÓN El presente trabajo de grado tiene como finalidad proporcionar a las Pymes, del sector de servicios, una guía metodológica con elementos conceptuales estructurados, que les permita a los gestores de proyectos informáticos, obtener el aumento en la productividad de estos proyectos, mejorando, a su vez, la calidad del producto esperado. Debido a que el planteamiento del uso de metodologías ágiles, en gestión de proyectos y desarrollo de software, es una tendencia reciente y creciente en la industria del software, se entrega un marco teórico que permite adquirir el conocimiento base, necesario que requiere para hacer uso de éstas y adicionalmente se presenta una breve comparación entre las metodologías ágiles que fueron elegidas para la investigación realizada, con el fin de justificar la razón por la cual se incluye cada una de las prácticas referenciadas en la guía metodológica propuesta. En el presente documento encontrará, de forma detallada, el desarrollo del trabajo de grado titulado: SWAPyME: Guía metodológica para la gestión de proyectos de software, en Pymes que no son fábricas de software, por medio de Metodologías Ágiles, cuyo propósito consiste en proporcionar a los gestores de proyectos informáticos los elementos conceptuales que les permita tomar la decisión de adoptar prácticas ágiles, cambiando la cultura de la empresa y, a través de un consolidado de los mejores elementos de las prácticas ágiles de proyectos de software, aumentar la productividad en el desarrollo de proyectos y asegurar la calidad del producto entregado, contribuyendo de forma activa en el ciclo de vida del proyecto y del producto. En el capítulo I. Descripción general del trabajo de grado, se encuentra la definición de la problemática que se identificó, describiendo el estado actual en que se encuentra la gestión de proyectos y el desarrollo de software y el contexto en que se presenta el problema de baja calidad y productividad. Se expone el por qué se eligió este tema y la forma en que se aporta a las Pymes, por medio del cumplimiento de los objetivos propuestos en el trabajo de grado. Finalmente para entender el propósito del trabajo, se exponen en este capítulo los objetivos y el método que se llevó a cabo para formalizar el cumplimiento de cada uno de éstos. Página 13

14 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> En el capítulo II. Marco teórico, con el objetivo de establecer la base teórica del trabajo realizado, se encuentra una serie de definiciones, principalmente correspondientes a los conceptos de agilidad, calidad, productividad y gestión de proyectos de software. El capítulo III. Desarrollo del trabajo, contempla el proceso que se llevó a cabo para lograr el cumplimiento de cada uno delos objetivos planeados y los resultado obtenidos. En el capítulo IV. Post-Mortem, se realiza una comparación entre lo que se tenía planeado, con respecto a la metodología empleada, las actividades, los tiempos y los riesgos del trabajo de grado, desde el planteamiento de la propuesta y lo que realmente ocurrió en el desarrollo y la finalización del mismo. En el capítulo V. Resultados y reflexión sobre los resultados, se muestra el producto final del trabajo de grado, definido en la etapa de validación de la metodología planteada y a partir de los resultados, las observaciones que se lograron discernir a partir de lo que se encontró. Finalmente, en el capítulo VI. Conclusiones, recomendaciones y trabajos futuros, se presenta el discernimiento obtenido del proceso que se llevó a cabo en el desarrollo del trabajo de grado y una visión de las opciones que pueden ser consideradas para su desarrollo en otros trabajos de grado, como continuidad del presente. Página 14

15 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación I DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO I.1 Oportunidad, Problemática y Antecedentes I.1.1 Descripción del contexto Actualmente las empresas que manejan proyectos en los que está involucrada la entrega de software se ven afectadas por factores que hasta hace unos años eran inversamente proporcionales, tiempo y calidad. Entre más rápido el cliente solicitaba la entrega del producto, mayor era el riesgo que corría de no recibir lo que buscaba o recibir un producto en mal estado. Sin embargo, dada la necesidad de poner un orden y pensando en la satisfacción del cliente se han creado diferentes metodologías que permiten, a partir de prácticas, aportar productividad y calidad en el desarrollo de los productos. No obstante, implementar una metodología y hacer que ésta se cumpla cabalmente dentro de la organización, implica un alto costo, debido al tiempo que se debe invertir en el aprendizaje, el manejo de herramientas y principalmente el que se invierte en generar una cultura organizacional que lleve a todas las personas hacía un mismo objetivo. Es importante tener en cuenta, en este punto, que además de esto, no usar una metodología implica un alto costo al implementar un cambio en la etapa de desarrollo, lo que se evidencia como una de las principales causas del fracaso de los proyectos de software, como se puede ver en la Imagen 1que muestra los resultados del informe el Chaos Report 2009, donde se mostró que sólo el 32% de los proyectos de software cumplían con el Tiempo, Costo y Alcance (requerimientos de usuario) planeados. Imagen 1. Resultados del informe "Chaos Report 2009" Página 15

16 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Debido a que no se ofrece una óptima solución para proyectos donde el entorno es volátil, en los últimos diez años, se han desarrollado otro tipo de metodologías que presentan un paradigma mucho más asequible para los desarrolladores y gestores de proyectos, debido a que el nivel de la curva de aprendizaje es bajo en comparación con las metodologías tradicionales. Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan, ya que para muchos clientes esta flexibilidad será una ventaja competitiva y porque estar preparados para el cambio significaría reducir su coste. El término desarrollo ágil fue fijado en el año 2001 y se introdujo en el Manifiesto Ágil [1], basado en que las metodologías ágiles de gestión van tras la defensa del desarrollo de proyectos rigurosos y el proceso iterativo que fomentan el análisis y modificación a lo largo de la vida de un proyecto. Lo cual, usando las metodologías ágiles puede ser manejado sin dificultad, dado que éste es un proceso fluido que a menudo promueve un ambiente donde las metas de los clientes están en línea con el enfoque de desarrollo. A pesar de ser el Manifiesto Ágil, la base de muchas de las metodologías que se han creado, los métodos ágiles en realidad surgen de las experiencias con la gestión de proyectos en la vida real, es decir, de los profesionales de software que experimentan los desafíos y las limitaciones de desarrollo en cascada tradicional proyecto tras proyecto. Es por esta razón que el enfoque que promueve el desarrollo ágil es una respuesta directa y de manera efectiva a la temática relacionada con el desarrollo de software tradicional, en términos de filosofía del enfoque y de los procesos específicos. De igual forma, las metodologías ágiles se presentan como un marco de trabajo liviano que brinda un beneficio a los equipos de trabajo, sin dejar de lado la evolución técnica y funcional que demanda la industria, manteniendo el enfoque de entregas iterativas que se refieran, principalmente, a las funciones que brinden valor para el negocio, por medio de un proceso de planificación continua y retroalimentación constante. Debido al avance tecnológico que se está presentando a nivel mundial, las necesidades de las empresas han cambiado y las exigencias son aún mayores. La conectividad global que proporcionan el internet y las comunicaciones virtuales ha causado la evolución de las Página 16

17 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación principales economías, en consecuencia se requieren nuevos procesos de desarrollo para que la colaboración global sea exitosa. Las empresas cuyo enfoque de negocio no está relacionado con el desarrollo de software y que usan como alternativa el outsourcing, deben manejar junto con el proyecto técnicas de colaboración multicultural, visión compartida y confianza, definir mecanismos de contratación, incentivos, entregas y adaptación al cambio. Es por esto que se han desarrollado herramientas, metodologías y prácticas que se han hecho frente al reto de satisfacer las nuevas metas de las empresas y alinear el desarrollo del proyecto con los objetivos del cliente. La mayor parte de estos desarrollos se han enfocado en brindar soluciones a las empresas que no son fábricas de software y que para cumplir con los objetivos estratégicos, que les permitan llevar el ritmo de su entorno tecnológico, necesitan adaptarse a sistemas que automaticen los procesos de negocio. I.1.2 Formulación del problema que se resolvió Desde la década de los 90s, el sector del software ha jugado un papel importante en el desarrollo industrial colombiano, al contribuir a la eficiencia de los procesos de diseño, producción, distribución y comercialización. Así mismo, ha servido como catalizador del cambio tecnológico, reduciendo costos y simplificado el almacenamiento y el procesamiento de información (Departamento Nacional de Planeación, 2007). Sin embargo, dados los avances tecnológicos, el alto nivel de competitividad empresarial y el paradigma actual en la industria de hacer más en menos tiempo, estas empresas han perdido el control en el manejo de tiempo, calidad y productividad. La solución que se aporta por medio de la guía metodológica consiste en hacer más productiva y con mejor calidad la gestión de proyectos que involucran el desarrollo de software en empresas que no son fábricas de software, que pertenecen a las Pymes del sector de servicios, por medio del uso de prácticas de gestión de proyectos y desarrollo de software basadas en metodologías ágiles. El enfoque principal es el desarrollo de nuevos productos de software, que buscan satisfacer una necesidad informática y/o tecnológica que se tiene en uno o más procesos de la Página 17

18 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> empresa, que serán entregados por medio del servicio de outsorcing prestado por una empresa fábrica de software. I.1.3 Justificación En ciertos proyectos de software las actividades que involucran las prácticas de estimación, planificación, recolección de requerimientos, entre otras, se conciben en muchos casos como actividades que no aportan a la productividad en la entrega de un producto, dado que el tiempo invertido en reunir los resultados que arrojan estas actividades se toman y se llevan a cabo en el desarrollo del proyecto, generando diferentes problemas de productividad a la empresa. La causa principal de estos problemas se da, en la mayoría de los casos, por una falta de conocimiento acerca de la aplicación de las prácticas y en otros casos por la aplicación de prácticas inapropiadas o falta de conocimiento de herramientas que le permitirán obtener resultados mucho más eficientes, sin perder la calidad necesaria para obtener un resultado exitoso de los proyectos. En algunas oportunidades se podrían generar errores al exigir a los clientes criterios de adquisición, y aplicar a los proyectos procesos de gestión predictivos, cuando se trata de proyectos que no necesitan tanto garantías de previsibilidad en la ejecución, como valor y flexibilidad para trabajar en un entorno cambiante, por lo que es indispensable contar con otro tipo de alternativas que modifiquen su visión con respecto a cambios y aplicación de elementos diferentes a los que comúnmente se llevan a cabo. Es por esto que la guía metodológica SWAPyME brinda a las empresas el conocimiento necesario y más relevante de forma puntual de lo que deberían hacer y las principales prácticas y herramientas que deben utilizar en el momento de llevar a cabo la gestión de un proyecto que involucre el desarrollo de software. Página 18

19 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Imagen 2. Razones para la adopción de prácticas ágiles Según las estadísticas, que muestran las principales razones por las cuales se deben usar las prácticas ágiles, se puede ver que la más importante es acelerar el tiempo de entrega con el 37%. Con lo cual, se puede deducir, a partir de la experiencia de diferentes compañías que han hecho uso de las metodologías ágiles, que se logra contrarrestar el principal conflicto que tienen los proyectos de desarrollo de software, que consiste en el incumplimiento de un cronograma predefinido y la necesidad de involucrar al cliente en fases del proyecto que le corresponde realizar a su proveedor. I.1.4 Impacto esperado El impacto del trabajo de grado a corto plazo, consiste en permitir que se otorgue al autor el título de Ingeniera de Sistemas en la Pontificia Universidad Javeriana y entregar a las empresas Pymes del sector de servicios una guía que les ayude a gestionar proyectos informáticos. A mediano plazo, se espera que la guía sea adoptada como estándar para la gestión de proyectos en las empresas Pymes del sector de servicios de Bogotá. Página 19

20 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> A largo plazo, la guía se podría convertir en una metodología ágil para la gestión de proyectos de software en las empresas que no son fábricas de software y ser acogida como un estándar por las empresas colombianas de este tipo. I.2 Descripción del Proyecto I.2.1 I.2.2 I.2.3 I.2.4 Visión global El trabajo de grado se llevó a cabo con el propósito de aportar, a las empresas que no son fábricas de software, prácticas para la gestión de proyectos de software basadas en metodologías ágiles. Esta gestión está dirigida hacia el aumento de la productividad en el desarrollo del proyecto y la calidad del producto entregado. Se elaboró una guía metodológica, que permite definir una serie de prácticas a seguir en el ciclo de vida del proyecto y del producto, haciendo énfasis en la diferencia existente. De manera adicional, se muestra conceptualmente y con el análisis requerido, cómo se eligieron estas mejores prácticas con el fin de promover la productividad y calidad. Objetivo general Definir una guía metodológica que permita reforzar la productividad y calidad de los proyectos que involucran desarrollo de software en Pymes del sector de servicios que no son fábricas de software. Objetivos específicos Identificar los elementos de las prácticas ágiles de desarrollo y de gerencia de proyectos de software. Consolidar el conjunto de artefactos (herramientas) que acompañan la aplicación de la guía metodológica, basada en las mejores propuestas de las prácticas ágiles. Validar la viabilidad y la calidad de la aplicación de la guía metodológica. Método que se propuso para satisfacer cada fase metodológica El método propuesto consiste en un ciclo de trabajo que se divide en cuatro fases. Estas fases permiten el desarrollo constante e iterativo sobre cada uno de los entregables del trabajo de grado. Página 20

21 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Imagen 3. Método propuesto A continuación se explica cada una de las fases: Exploración: Consiste en la búsqueda de bibliografía, autores y fuentes de información relevantes para la elaboración de la guía. Elaboración: Cada uno de los entregables se redacta de forma tal, que su lectura pueda ser rápida y fácilmente entendida. Validación: Consiste en efectuar pruebas de la guía metodológica. Estas pruebas se realizaron a partir de un juicio de expertos que permitió, en su retroalimentación, determinar la viabilidad y calidad necesaria para la óptima ejecución de la guía metodológica. Cierre: Revisión y corrección de los entregables del trabajo de grado, además de los resultados aportados por la validación de la guía metodológica. Página 21

22 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> II MARCO TEÓRICO II.1 Marco Contextual A continuación se encuentra la base teórica sobre la cual se fundamentó la investigación y la propuesta metodológica realizadas en el trabajo de grado. Dado que la propuesta metodológica se fundamenta en los principios de metodologías ágiles, se contextualiza en principio dicho tema, donde se explica su concepto y las dos características principales que le definen: Iterativo e incremental. Posteriormente y con base en diferentes metodologías ágiles seleccionadas a esto, se presenta el compendio de valores y principios sobre los cuales están fundadas estas metodologías. Se explican cada una de las fases del proceso sobre el cual típicamente se desarrolla un proyecto ágil, junto con una breve descripción de las metodologías que fueron desglosadas y comparadas. II.1.1 Metodologías ágiles Las metodologías ágiles están definidas como un subconjunto de las metodologías iterativas e incrementales, en el cual el ciclo de vida de un proyecto de software está compuesto de varias iteraciones de forma secuencial [2]. El autor y conferencista Martin Fowler [3] plantea que la clave del desarrollo iterativo es producir frecuentemente versiones que funcionen del sistema final que tengan un subconjunto de los rasgos requeridos. Estos entregables, cortos en funcionalidad, deben ser coherentes con la demanda del sistema final, deben ser totalmente integrados y cuidadosamente probados como una entrega final. Por otra parte, el desarrollo incremental significa que un producto se construye bloque a bloque durante todo el ciclo de vida de desarrollo del producto. Para que un proceso sea considerado <<ágil>>, las iteraciones individuales deben producir alguna característica completamente funcional o mejorada. De esta manera, el producto final se desarrolla bloque por bloque, iteración por iteración [4]. Actualmente existen dos pilares primarios de valores ágiles, la Declaración de interdependencia, escrita por los miembros fundadores de la Agile Project Leadership Página 22

23 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Network 1 y el Manifiesto de Desarrollo de software ágil, escrito por muchos de los miembros fundadores de la Alianza Ágil 2 [5]. II.1.2 Declaración de interdependencia La declaración de interdependencia proporciona una serie de valores modernos, relacionados e imprescindibles para que un proyecto de desarrollo de software construido bajo principios ágiles sea exitoso. Los principios de esta declaración, que todo equipo de desarrollo ágil debería asumir sin problemas, son: "Nosotros... Incrementamos el retorno de la inversión enfocándonos en lograr un continuo flujo de valor. Proporcionamos resultados fiables involucrando frecuentemente al cliente y compartiendo con él la propiedad del proyecto. Esperamos incertidumbre y la manejamos mediante iteraciones, anticipación y adaptación. Liberamos creatividad y motivación reconociendo a los individuos como la fuente última de valor y creando un entorno donde ellos puedan marcar la diferencia. Impulsamos el rendimiento mediante la responsabilidad compartida en los resultados y efectividad del equipo. Mejoramos la efectividad y la confianza mediante procesos, prácticas y estrategias específicas para cada situación." [6] II.1.3 Manifiesto ágil En febrero de 2001 se creó el manifiesto ágil aplicado al desarrollo de software. Su objetivo es definir los valores y principios para el desarrollo ágil de software, teniendo en cuenta los cambios que se puedan presentar a lo largo del desarrollo del proyecto. A continuación se presenta el manifiesto ágil en detalle [1]: Estamos descubriendo mejores métodos de desarrollo de software al hacerlo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar: Los individuos e interacciones SOBRE los procesos y herramientas Página 23

24 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> El trabajo en software SOBRE la documentación completa. La colaboración de los clientes SOBRE la negociación en los contratos. La respuesta al cambio SOBRE el seguimiento de un plan. Es decir, mientras hay valor en los elementos de la derecha, nosotros valoramos más los elementos de la izquierda. II Principios del manifiesto ágil En esta reunión del 2001 se determinaron los siguientes principios en los que se fundamenta el manifiesto ágil [1]: La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Un proceso es ágil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender más, a la vez que logran una mayor satisfacción del cliente. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. El paradigma orientado a objetos puede ayudar a conseguir esta flexibilidad. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. Las entregas al cliente se insiste en que sean software, no planificaciones, ni documentación de análisis o de diseño. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interacción con el equipo es muy frecuente. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado. Página 24

25 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, éste es el principal modo de comunicación. Se pueden crear documentos pero no todo estará en ellos, no es lo que el equipo espera. El software que funciona es la medida principal de progreso. El estado de un proyecto no viene dado por la documentación generada o la fase en la que se encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo momento que la calidad de lo producido es máxima. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto. La simplicidad es esencial. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. Todo el equipo es informado de las responsabilidades y éstas recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se persigan. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está cambiando continuamente, el equipo también debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo ágil. [1] II.1.4 Proceso de las metodologías ágiles Todos los métodos de desarrollo de software, incluidos los ágiles, tienen algún tipo de ciclo de vida del proyecto. Steven Thomas, basándose en la investigación que realizó [7], determina que estos métodos tienen mucho en común, en particular alrededor de la gestión ágil de proyectos. Este ciclo de vida ágil toma los elementos comunes de las metodologías: Página 25

26 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Extreme Programming, Scrumy Dynamic System Development Method, y racionaliza la terminología. Los elementos clave son la iniciación del proyecto seguido por uno o más lanzamientos compuestos, por una o más iteraciones (aunque por lo general son tres), finalizando con un cierre del proyecto. Desde otra perspectiva, Jim Highsmith en su libro Agile Project Management: Creating Innovative Products [5], divide el proyecto ágil en cinco fases (ver Imagen 4), que se explican a continuación: Imaginación: Esta fase consiste en determinar la visión del producto y los objetivos del proyecto y las limitaciones, la comunidad del proyecto, y cómo el equipo va a trabajar. Especulación: El objetivo de esta fase es desarrollar la capacidad y el plan de lanzamiento basado en funciones para cumplir con la visión. Exploración: En esta fase se define el plan de ejecución y se entregan las historias a prueba en una iteración corta, buscando constantemente reducir el riesgo y la incertidumbre del proyecto Lanzamiento de producto: La fase de lanzamiento consiste en la revisión de los resultados entregados, la situación actual, y el rendimiento del equipo, y modificar según las necesidades. Cierre: Conclusión del proyecto, retomar las enseñanzas destacadas y celebrar. [5] Página 26

27 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Imagen 4. Proceso de metodologías ágiles 3 II.1.5 Descripción de las metodologías ágiles Las metodologías sobre las cuales se realizó la investigación, se tuvieron en cuenta debido a que actualmente tienen mayor reconocimiento en el sector de desarrollo de software y algunas de éstas son las más usadas, según se muestra en los resultados de la encuesta (ver Imagen 5) realizada por la compañía VersionOne [8]. Imagen 5. Metodologías ágiles más usadas 4 3 Imagen tomada de [5] Página 27

28 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Estas metodologías son: SCRUM, extreme Programming (XP), Dynamic System Development Method (DSDM), Feature Driven Development (FDD), Lean Software Development (LSD), Adaptive Software Development (ASD), Agile Unified Process (AUP) y Crystal. A continuación se muestran los aspectos más importantes que permiten describirlas: Definición Enfoque Roles Valores Prácticas Proceso Enfoque de aplicación dirigido al ciclo de vida del proyecto o la realización del producto. 4 Imagen tomada de [8] Página 28

29 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II Definición En la siguiente tabla se muestra la definición conceptual de cada una de las prácticas ágiles elegidas: Scrum XP DSDM FDD LSD ASD AUP Crystal Scrum es un framework de gestión liviano con amplia aplicabilidad para la gestión y control de los proyectos iterativos e incrementales de todo tipo. La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. XP es un enfoque disciplinado para la distribución de software de alta calidad con rapidez y continuidad. Se promueve la participación alta de los clientes, bucles de retroalimentació n rápida, prueba continua, planeación continua y trabajo en equipo cerca de ofrecer software de trabajo a intervalos muy frecuentes, por lo general cada 1-3 semanas. La metodología DSDM proporciona una base general para la planeación, gestión, ejecución, y la ampliación ágil e iterativa de proyectos de desarrollo de software. DSDM se basa en nueve principios fundamentales que principalmente giran en torno a las necesidades del negocio / valor, los usuarios participen activamente, los equipos facultados, entregas frecuentes, las pruebas integradas y colaboración de los interesados. FDD es un LSD centra el equipo ASD encarna el modelo impulsado en la entrega de valor principio de que la por procesos de al cliente, en la adaptación continua corta iteración. Se eficiencia de la del proceso de la obra inicia con el "Cadena de Valor" y es el estado normal de establecimiento los mecanismos que cosas. El modelo de de un modelo de proporcionan ese adaptación se basa en forma global. valor. Se hace una visión del mundo Luego continúa hincapié en la diferente: Cíclico con una serie de velocidad y la como el modelo dos semanas eficiencia de flujo de evolutivo, los iteraciones trabajo de desarrollo nombres de las fases "diseñar por y se basa en una reflejan el ámbito función, construir respuesta rápida y cada vez más por función". Las fiable entre los impredecible de los funciones son programadores y sistemas complejos. pequeños clientes. La esencia ASD va más allá de su resultados "útiles de Lean es que a cada herencia evolutiva de a los ojos del empleado se le da la dos maneras cliente. Para oportunidad de principales: En primer habilitar la encontrar problemas lugar, explícitamente entrega confiable en su manera de reemplaza el de software que trabajar, para determinismo con la trabajan de resolverlos y hacer emergencia. En manera oportuna mejoras. El objetivo segundo lugar, va más con información es desarrollar allá de un cambio en muy precisa y software utilizando el el ciclo de vida para significativa para conjunto mínimo de un cambio más todas las actividades necesarias profundo en el estilo funciones clave y adaptar el proceso a de gestión. dentro y fuera de las necesidades del un proyecto. producto. Tabla 1. Definición de las metodologías Describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (Test Driven Development - TDD), Modelado ágil, Gestión de Cambios ágil y Refactorización de Base de Datos para mejorar la productividad. Se considera una versión simplificada del Rational Unified Process (RUP). La metodología Crystal es una de las más ligeras y adaptable a los enfoques de desarrollo de software. Crystal, se compone de una familia de metodologías (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) cuyas características únicas son impulsadas por varios factores, como el tamaño del equipo, la criticidad del sistema y las Prioridades del proyecto. Página 29

30 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> II Enfoque En la siguiente tabla se muestra el objetivo que tiene cada una de las metodologías: Scrum XP DSDM FDD LSD ASD AUP Crystal La intención de Scrum es la de maximizar la realimentación sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Para habilitar la entrega co nfiable de software que trabajan de manera oportuna con información muy precisa y significativa para todas las funciones clave dentro y fu era de un proyecto La esencia de Lean es que cada empleado se le da la oportunidad de encontrar problemas en su manera de trabajar, para resolverlos y hacer mejoras. El objetivo es desarrollar software utilizando el conjunto mínimo de actividades necesarias y adaptar el proceso a las necesidades del producto. El modelo de adaptación se basa en una visión del mundo diferente. Cíclico como el modelo evolutivo, los nombres de las fases reflejan el ámbito cada vez más impredecible de los sistemas complejos. Va más allá de su herencia evolutiva de dos maneras principales. En primer lugar, explícitamente reemplaza el determinismo con la emergencia. En segundo lugar, va más allá de un cambio en el ciclo de vida para un cambio más profundo en el estilo de gestión. Versión simplificada del Proceso Unificado de Rational (RU P) La metodología Crystal es una de las más ligeras, adaptable a los enfoques de desarrollo de software. Crystal, en realidad se compone de una familia de metodologías cuyas características únicas son impulsadas por factores, como el tamaño del equipo, la criticidad del sistema y las Prioridades del proyecto. Tabla 2. Enfoque de las metodologías Página 30

31 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II Roles En la siguiente tabla se muestran los principales roles que se deben definir durante el proceso de gestión de proyectos ágiles y desarrollo de productos: Scrum XP DSDM FDD LSD ASD AUP Crystal Equipo Scrum Master Dueño de Producto Usuario Administrador Cliente Cliente Desarrollador Tester Tracker Entrenador Líder de equipo Usuario embajador Usuario asesor Desarrollador Senior Desarrollador Documentador Gerente de proyecto Arquitecto en jefe Gerente de desarrollo Jefe de los programadores Propietarios de clase Expertos en dominio Tabla 3. Roles de las metodologías Líder Desarrollo Planeación Calidad Soporte Gerente de proyecto Ingeniero de procesos Agile DBA: Administrador de base de datos (DBA) Modelador ágil Administrador de configuración Stakeholder Gerente de pruebas Tester Analista- Diseñador de negocios Diseñador - Programador Diseñador de interfaz de usuario Tester II Valores En la siguiente tabla se muestran los principales valores que resalta cada una de las metodologías para el equipo de trabajo: Scrum XP DSDM FDD LSD ASD AUP Crystal Compromiso Enfoque Transparencia Honestidad Respeto Coraje Simplicidad Comunicación Retroalimentación Respeto Esfuerzo Mejora continua Respeto por las personas Tabla 4.Valores de las metodologías Página 31

32 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> II Prácticas En la siguiente tabla se muestran las prácticas que se llevan a cabo para la gestión de proyectos ágiles y el desarrollo ágil de productos: Scrum XP DSDM FDD LSD ASD AUP Crystal Planeación de la iteración (Sprint Planning) Ejecución de la iteración (Sprint) Reunión diaria de sincronización del equipo (Scrum Daily Meeting) Demostración de los requerimientos completados (Sprint Review) Retrospectiva (Sprint Retrospective) Replaneación del proyecto Planeación de Juego Pequeños releases Pruebas de aceptación del cliente Diseño simple Programación en parejas Desarrollo basado en pruebas Refactoring Integración Continua Propiedad colectiva del Código Estándares de codificación Metáfora Paso Investigación Refinamiento Consolidación Modelado de objetos de dominio Desarrollo por funciones Propiedad de clase (Código) individual Equipos de características Inspecciones Construcciones regulares Visibilidad de resultados Gestión de la configuración Informes Eliminar los residuos Calidad de construcción óptima Crear conocimiento Diferir Compromiso Entrega Rápida Respeta a las personas Optimizar el todo Ciclo de vida evolutivo Cliente grupos de discusión Sesiones de JAD 5 Revisiones técnicas Duración fija de la gestión de proyectos Ingeniería de software continua Equipos dedicados Modelo Aplicación Prueba Implementación Gestión de la Configuración Gestión de Proyectos Medio Ambiente El equipo del proyecto se reúne regularmente para discutir las actividades del proyecto. El equipo también se reúne periódicamente con las partes interesadas para asegurar que el proyecto va en la dirección esperada y comunicar cualquier descubrimiento nuevo que pueda afectar el proyecto. Todos los proyectos esperan tener acceso frecuente a la persona (s) en la definición de los requerimientos. Zona de seguridad que los miembros del equipo deben tener para ser eficaces y para comunicar la verdad en 5 JAD (Joint Application Development) es una técnica de definición de requisitos y de diseño de la interfaz de usuario, basada en reuniones participativas entre clientes, directiva y desarrolladores. [50] Página 32

33 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación sostenible el proyecto sin temor a represalias. La otra forma de seguridad es que el propósito de cada proyecto de software no es el mismo y que en algunos proyectos de software lo que está en peligro es la seguridad de sus usuarios finales. Crystal tiene diversas capacidades para la verificación de la funcionalidad del proyecto: Los controles deben ponerse en marcha para apoyar versiones, pruebas automatizadas, y la integración frecuente de los componentes del sistema. Tabla 5. Prácticas de las metodologías Página 33

34 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> II Principios En la siguiente tabla se muestran los principios que se deben tener en cuenta en el equipo de trabajo en la gestión ágil de proyectos y el desarrollo de productos: Scrum XP DSDM FDD LSD ASD AUP Crystal Tan pronto como hay un problema, identificarlo. Los analistas saben cómo analizar y los desarrolladores saben cómo desarrollar. Hacer iteraciones que no sean demasiado cortas ni demasiado largas. El equipo debe autoorganizarse. Trabajar en un tema cada sprint Debe haber una sala para el equipo. La participación activa del usuario es imprescindible. El equipo debe estar facultado para entregar. La entrega frecuente es la clave. El principal criterio para la aceptación es la entrega de la funcionalidad que satisface las necesidades de negocio actuales. Entregas iterativas e incrementales son esenciales. Todos los cambios durante el ciclo de vida del proyecto son reversibles. Los requerimientos son la línea base en un nivel alto. Pruebas integradas en el ciclo de vida del proyecto completo. La colaboración y la cooperación entre todas las partes interesadas son esenciales. El abandono del determinismo Colaboración Aprendizaje Su personal sabe lo que están haciendo. Simplicidad: Todo se describe de manera concisa con pocas páginas no, con miles. Agilidad: AUP se ajusta a los valores y principios del desarrollo ágil de software y la Alianza Ágil. Centrarse en actividades de alto valor: La atención se centra en las actividades que en realidad aportan al negocio, no todas las cosas que podrían suceder en el proyecto. Independencia del uso de herramientas: Se puede utilizar cualquier conjunto de herramientas. Trabajo en equipo, comunicación y sencillez Reflexión para ajustar con frecuencia y mejorar el proceso. Entregas frecuentes Retroalimentación continua Constante comunicación Seguridad Enfoque Acceso a Usuarios Pruebas automatizadas e integración. Algunos conceptos clave de crystal son el tamaño del proyecto y la criticidad: o El tamaño es definido como el número de personas involucradas en un proyecto (a medida que crece el tamaño del equipo los cambios de crystal se enfocan en agregar más formalidad a la estructura, los artefactos y la gestión del proyecto). o Criticidad se define como el potencial del sistema para Página 34

35 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Tabla 6. Principios de las metodologías causar daño. En cuanto a la criticidad del proyecto aumenta las necesidades del proyecto aumentan para garantizar que la demanda esperada pueda ser entregada. II Producto/Proyecto En la siguiente tabla se define si la metodología ágil está dirigida a la gestión de proyectos o al desarrollo de productos: Scrum XP DSDM FDD LSD ASD AUP Crystal Proyecto x x x X x Producto x x x II.1.6 Comparación de metodologías En la siguiente tabla se muestran las fortalezas y debilidades encontradas en cada una de las metodologías definidas en el capítulo anterior: Scrum Fortalezas Complementa las prácticas existentes. Auto-organización de los equipos y retroalimentación. La participación del cliente y la dirección. Prioridades basadas en el valor del negocio. Sólo el enfoque en esta materia que tiene un proceso de certificación. Debilidades Sólo proporciona apoyo a los proyectos de gestión, otras disciplinas están fuera de alcance. No especifica las prácticas técnicas. Puede tomar algún tiempo para obtener el negocio de proporcionar prioridades únicas para cada requisito. Página 35

36 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> XP DSDM FDD LSD AUP Fuerte prácticas técnicas. Cliente propietario de la prioridad característica, los desarrolladores propietarios de la estimación. Oportunidades frecuentes de retroalimentación. Enfoque más conocido y adoptado, al menos en los EE.UU. El énfasis en las pruebas es tan fuerte que existe por lo menos un probador en cada equipo del proyecto. Diseñado desde el principio por la gente de negocios, por lo que el valor del negocio se identifica y se espera que sea la prioridad más alta a entregar. Tiene enfoque específico para determinar la importancia de cada requisito tiene en una iteración. Establece expectativas de los stakeholder desde el inicio del proyecto que no todos los requisitos se harán en la entrega final. Soporta varios equipos trabajando en paralelo. Todos los aspectos de un proyecto seguidos por característica. Diseño por característica y construcción por característica son aspectos fáciles de entender y adoptar. Bueno en escalas de equipos grandes o proyectos. Complementa las prácticas. Se centra en el ROI del proyecto. Elimina todos los residuos del proyecto. Equipos interfuncionales. Metodología robusta con muchos artefactos y disciplinas para elegir. Documentación de ayuda a comunicarse en entornos distribuidos. Establecer prioridades sobre la base de más alto riesgo. El riesgo puede ser un negocio o riesgo técnico. Requiere de los clientes en el sitio (onsite). Documentación principalmente a través de la comunicación verbal y el código. Para algunos de estos equipos los artefactos creados son únicos, otros crean diseño minimalista y documentación del usuario. Difícil para los nuevos adoptantes determinar cómo responder a las preocupaciones de arquitectura y diseño. Probablemente, el proyecto más pesado en comparación con otras metodologías. Espera que la participación continua del usuario. Define varios artefactos y productos de trabajo para cada fase del proyecto. Documentación más pesada. El acceso al material es controlado por un consorcio, y las tasas puede ser cobrado sólo para tener acceso al material de referencia. Promueve la propiedad individual del código frente a la propiedad compartida del equipo. Las iteraciones no están tan bien definidas por el proceso como otras metodologías ágiles. Los aspectos centrados en modelos pueden tener un impacto enorme cuando se trabaja en los sistemas que no tienen modelos. No especifica las prácticas técnicas. Requiere constante recolección de métricas que puede ser difícil de acomodar para algunos ambientes. Teoría de las Restricciones puede ser un aspecto complejo y difícil de adoptar. Los niveles más altos de la ceremonia puede ser un obstáculo en proyectos más pequeños. Mínima atención a la dinámica del equipo. La documentación es mucho más formal que la mayoría de los enfoques. Página 36

37 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Crystal Familia de metodologías diseñada para escala por el tamaño del proyecto y la criticidad. Única metodología que tiene en cuenta los proyectos críticos de la vida. Como crece el tamaño del proyecto, los equipos multifuncionales se utilizan para garantizar la coherencia. El componente "humano" ha sido considerado para todos los aspectos de la estructura de soporte del proyecto. Un énfasis en las pruebas es tan fuerte que por lo menos un probador se espera que esté en cada equipo del proyecto. Prevé todos los miembros del equipo, para ser ubicados. No puede funcionar bien para los equipos distribuidos. Se requieren ajustes de tamaño/ estructura de un proyecto a otra para seguir el tipo prescrito de crystal para el tamaño del proyecto o la criticidad. Pasar de un tipo de crystal a otro en la mitad del proyecto no funciona. Crystal no fue diseñado para ser compatible hacia arriba o hacia abajo. Tabla 7. Comparación de metodologías Como resultado de la investigación realizada de cada una de las metodologías, se efectuó un análisis comparativo de algunas características que éstas tienen en común. Las condiciones que se tuvieron en cuenta fueron: Tamaño del equipo, requerimientos, si es apta para múltiples clientes, cultura del equipo e importancia de la criticidad de los sistemas. Los resultados se muestran en la siguiente tabla: Equipos pequeños Recolección de requerimientos Múltiples clientes Cultura ceremonial Equipos distribuidos Criticidad del sistema Scrum Si Si Si No Si N/A XP Si Si No No No No DSDM Si No No Si No No FDD No Si N/A N/A Si N/A LSD Si Si Si N/A Si N/A AUP No N/A N/A Si Si N/A Crystal N/A N/A N/A N/A No Si No Aplica N/A Tabla 8. Análisis comparativo de las metodologías Página 37

38 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II.2 Marco Conceptual A continuación se mencionarán los conceptos y elementos fundamentales para el desarrollo de la guía metodológica propuesta como resultado de este trabajo de grado. II.2.1 Agilidad Son varias las definiciones encontradas para el concepto de agilidad, sin embargo para este trabajo de grado se han elegido las siguientes: Capacidad de crear y responder al cambio con el fin de obtener ganancias en un ambiente de negocios turbulento. La agilidad es la capacidad de equilibrar la flexibilidad y la estabilidad [9]. Capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno [10]. Mejora continua y regular, basada en el aprendizaje continuo [11], de acuerdo a lo que muestra la Imagen 6. Esto se da gracias a que el desarrollo se ejecuta en ciclos cortos de retroalimentación, por medio del desarrollo iterativo e incremental con demostraciones regulares del producto final. De esta manera se generan resultados regulares visibles para el cliente, dando como principal beneficio la confianza en el producto. A continuación, para ampliar la perspectiva de la agilidad como concepto fundamental del desarrollo ágil de software, se realiza la explicación general de la Imagen 6: En el desarrollo de proyectos ágiles se cuenta con tres pilares principales que son: el proceso, el equipo y el producto. Con respecto al proceso se tiene en cuenta como elemento facilitador la excelencia técnica, que consiste en el manejo de la simplicidad, refactorización, arquitectura emergente y automatización, lo que da paso a la flexibilidad frente a cambios que se presenten durante la ejecución del proyecto. Los beneficios que tiene este elemento son la mantenibilidad del producto, el paso sostenido y que brinda calidad y productividad. Página 38

39 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación En cuanto al equipo de trabajo, se debe considerar, primordialmente, la satisfacción, por medio de la motivación e implicación, manteniendo una comunicación regular cara a cara y permitiendo además el uso de la creatividad, brindando mayor autonomía, formando equipos que sean capaces de auto-organizarse, con una responsabilidad compartida, tomando decisiones consensuadas, manteniendo un compromiso conjunto y guiados por estándares de desarrollo, que da como beneficio la innovación. Para este fin se debe crear cultura corporativa dentro de la organización, llevándola a cabo en un ambiente de colaboración, probando las cosas y mejorando, con el objetivo de obtener un equipo transparente y con actitudes de humildad, respeto, confianza y disciplina. Finalmente con relación al producto, la gestión está encaminada a que éste tenga mayor valor en un menor tiempo, dando así como resultado la priorización por valor de negocio y como principal beneficio, lo más importante es la satisfacción del cliente, contando con su colaboración regular dentro del proyecto y mostrando resultados visibles que generen confianza en el producto que se está desarrollando. Página 39

40 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Imagen 6 Qué es ágil 6 II.2.2 Desarrollo ágil de software El desarrollo ágil de software es usualmente definido como un proceso iterativo e incremental (evolutivo) para el desarrollo de software que se realiza de una manera muy colaborativa por auto-organización de los equipos dentro de un marco de gobernabilidad 6 Imagen tomada de [11] Página 40

41 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación eficaz con <<la suficiente>> ceremonia que produce soluciones de alta calidad de una manera rentable y oportuna que responda a las necesidades cambiantes de sus stakeholders [12]. II.2.3 Metodología Metodología se define como un conjunto de procedimientos basados en principios lógicos, utilizados para alcanzar objetivos que rigen en una investigación científica o en una exposición doctrinal [13]. (Mora, 2006) II.2.4 Producto Un producto se define como un artículo producido, que es cuantificable y que puede ser un elemento terminado o un componente. Otras palabras para hacer referencia a los productos son materiales y bienes. Éste tiene, al igual que un proyecto, un conjunto de fases, secuenciales y sin superposición. Cada una de estas fases tiene un nombre y orden que, por lo general, son determinados por las necesidades de fabricación y control de la organización, sin embargo, comúnmente, la última fase del ciclo de vida del producto, consiste en su retiro. Es normal que el ciclo de vida del proyecto esté contenido dentro de uno o más ciclos de vida del producto, por esta razón, debe tenerse cuidado en diferenciar el ciclo de vida del proyecto del ciclo de vida del producto [14]. II.2.5 Proyecto Los proyectos surgen en la década del 50 como una manera de organizar los desarrollos contratados por el Departamento de Defensa (DoD) y otros organismos de gobierno de EEUU. Las definiciones de proyecto han sido varias a través de los años, sin embargo desde un enfoque de desarrollo proyecto se define como un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un principio y un final definidos. El final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto [14]. En general un proyecto se plantea a partir de una solicitud de propuesta (en inglés Request for Proposal o RFP) que define con precisión lo que desea el cliente y donde los Página 41

42 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> proveedores proponen el costo y tiempo necesario para realizar el proyecto. Ambos participantes (cliente y proveedor) intentan protegerse de la incertidumbre por medio de extensos análisis iníciales de la situación y definición de contratos [15]. II.2.6 Calidad Calidad según la ISO 9000 está definida como el grado en el que un conjunto de características inherentes cumple con las necesidades o expectativas establecidas [16]. II.2.7 Calidad ágil Las metodologías ágiles ofrecen beneficios similares a las técnicas de aseguramiento de la calidad (QA), entre ellas se encuentra que en los proyectos ágiles, los escenarios de pruebas se concretan al mismo tiempo o incluso antes de que el software se esté escribiendo. Esto implica una fuerte dependencia entre los desarrolladores y testers 7 en la medida que trabajen en estrecha colaboración para lograr este objetivo común [17]. Sin embargo, en la literatura existente no se ha dado una definición clara de cuáles características de calidad de software son mejoradas por el uso de los procesos agiles en el desarrollo de éste. Se ha encontrado que las prácticas ágiles que aseguran costo-efectividad de un sistema incluyendo control de los ámbitos de influencia y utilizando sistemas de iteración que permitan hacer cambios en los requerimientos de los clientes. Si se aborda la calidad de los procesos y su agilidad al momento de gestarlo, se encuentra con que no hay independencia entre estos, debido a que el objetivo es definir la eficacia y eficiencia, y cómo estos pueden responder a las necesidades que los clientes tienen, al igual que el tiempo. Adicional a esto, al evaluar la calidad de los procesos de desarrollo de software, se pretende determinar su rendimiento para corregir problemas o para mejorarlos, teniendo como propósito principal la disminución de los costos de desarrollo y el aumento de la productividad [18]. En este entorno, una innovadora técnica es introducida para la evaluación de metodologías con el fin de determinar los factores de calidad de software existentes para mejorar. 7 Nombre con el que se llama a las personas encargadas de realizar las pruebas de software. Página 42

43 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación La técnica utiliza un conjunto de factores de calidad del software adaptado según lo definido por Bertrand Meyer y McCall. Al evaluar estos factores de calidad en diferentes etapas, se puede determinar la calidad del producto de software [18]. A continuación se exponen la definición y asociación con el desarrollo ágil de los factores de aseguramiento de la calidad del software, que determinan el control constante de estos durante la ejecución de cada proyecto: Compatibilidad: Una característica general de todos los objetos orientados al desarrollo de aplicaciones. Posibles mejoras en el enfoque de la agilidad incluyen consideraciones de diseño y arquitectura que apuntan a la independencia de la plataforma. Costo Efectividad: Control de los ámbitos de trabajo. Esta técnica es usada para prevenir la introducción de cambios en los requerimientos hasta el fin de la iteración. La ventaja de esto es que teniendo en cuenta que las iteraciones se generan por periodos de tiempo cortos, el costo del proyecto también obtendrá frecuentes comentarios que sustentaran los costos de inversión. Correcciones: Inscripción codificada de requerimientos mínimos; especificaciones, las cuales son obtenidas por la comunicación constante y directa con el cliente, permitiendo al cliente hacer cambios en los requerimientos, historial de usuarios y pruebas de desarrollo. Desde que todo el desarrollo en prácticas agiles esté hecho iterativamente, estas técnicas aseguraran las correcciones en los niveles de iteración antes tomar decisiones a cerca de continuar o cancelar el proyecto. Facilidad de uso: Hacer al cliente parte del equipo de trabajo y clientes que proporcionen comentarios frecuentemente, ya que ellos probablemente recomendarán un sistema de fácil utilización. Eficiencia: La aplicación de buenos códigos normativos y fomentación de los diseños basados en los algoritmos más eficientes. Página 43

44 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Integridad: Esta característica está basada en el nivel del sistema operativo y también el nivel de la plataforma de desarrollo. Mejorando la integridad de las técnicas que definen el producto mejora la integridad del sistema. Mantenimiento: La aplicación de los principios de Objetos Orientados al diseño conduce al mantenimiento informático. Desarrollos que mejoren las interfaces entre los diferentes módulos de objetos pueden tener un impacto positivo en el mantenimiento. Portabilidad: Es generalmente implementado a través del concepto de los Objetos Orientados al diseño. Puntualidad: Desarrollo iterativo, rápida distribución y ciclos cortos. Esto puede mejorar la reducción del tiempo para el despliegue de procesos. Verificación y Validación. Las técnicas agiles que manejen esta característica deben incluir: Desarrollo Basado en Pruebas, unidades de prueba y frecuente integración. Para mejorar en estas técnicas, más herramientas podrían ser desarrolladas para vincular las pruebas existentes acerca de los conceptos basados en el Desarrollo Basado en Pruebas. [18]. II.2.8 Productividad La productividad se define como la relación entre los resultados y el tiempo utilizado para obtenerlos: cuanto menor sea el tiempo que lleve obtener el resultado deseado, más productivo es el sistema [19]. Una investigación realizada por la International Data Corporation (IDC por sus siglas en inglés) [20], indica que entre el 70 y 80% de los fracasos de desarrollos de software son resultado de la recopilación de requisitos, análisis y gestión pobres. II.2.9 Productividad ágil En concepto de productividad ha sido uno de los aspectos estudiado con mayor interés en los últimos años. En un estudio de la evolución del desarrollo ágil realizado [21] se Página 44

45 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación comparó la productividad de dos proyectos similares. Un equipo utilizó una metodología tradicional y el otro XP. Encontraron que, en general, el equipo XP obtuvo una productividad 42% mayor que la del equipo tradicional. No obstante, en la primera iteración, la productividad del equipo XP fue mucho mayor y en la última no hubo apenas diferencia. Demostrando de esta forma que los enfoques ágiles, adecuadamente gestionados, ofrecen una respuesta a la problemática de baja productividad, habilitando una rápida y frecuente retroalimentación entre el negocio y el equipo de TI. Se estructuran grandes requerimientos en entregas incrementales que mejoran el time-to-market, lo cual permite a las empresas ser más sensibles a la dinámica del mercado, dado que para el establecimiento de métodos ágiles es clave el potencial de ganancias de productividad. Además del entrenamiento de nuevos equipos por equipos ágiles maduros puede ayudar a establecer una mayor adopción de prácticas ágiles y un enfoque de desarrollo de software más dinámico, como apoyo a las empresas y consecuentemente, el éxito de un equipo con el desarrollo ágil puede ser un ejemplo para llevar a la adopción de organización y nuevas mejoras de la productividad por otros equipos, en todos los ámbitos. También es útil establecer un enfoque ágil como parte de un alcance de ciclo de vida del proyecto, comprender la colaboración de la comunidad y que el desarrollo ágil puede ayudar a las organizaciones a evolucionar en el negocio [22]. Por otro lado, Jeff Sutherland [23] defiende que si las metodologías ágiles están bien integradas se debe producir un gran aumento de la productividad, cualquier dato que indique lo contrario debería llevar a los responsables a estudiar el por qué y en qué están fallando. El aumento de la productividad viene dado básicamente por la mejora de gestión de la producción, mejora que se refleja por la autogestión de los equipos, que les permite ser más eficientes, sobre todo, por eliminar procesos repetitivos y de escaso valor para la producción. Página 45

46 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> III DESARROLLO DEL TRABAJO A partir de los resultados encontrados en la investigación realizada, se generó una propuesta metodológica que cimenta su enfoque en el aumento de la productividad del proyecto y el aseguramiento de la calidad del producto entregado. Adicionalmente, se integraron mejores prácticas, establecidas a partir de un criterio basado en la información que se recolectó y analizó con el enfoque antes mencionado. Con el fin de lograr la efectividad en el uso de las prácticas, esta metodología se debe alinear a la cultura de la empresa, es decir, del conjunto de ideologías, valores, metas, que perciben los individuos que conforman la misma, ya que ésta es una de las primeras cuestiones con las que debe relacionarse rápidamente un individuo al comenzar a formar parte de una empresa. Se estableció el nombre de SWAPyME para la metodología, como reducción de la frase software ágil para Pymes (para conocer más detalles de la guía metodológica vaya al Anexo 1. Guía metodológica SWAPyME ). En el desarrollo de la guía metodológica se describieron las siguientes características que permiten el planteamiento y secuencia que debe seguir el usuario para llevar a cabo la implementación de la metodología: Definición: La metodología SWAPyME se define como un framework liviano que tiene como principal objetivo la gestión ágil de proyectos productivos de software y el desarrollo de alta calidad, en torno a las necesidades de valor del negocio. Se fundamenta esencialmente en la responsabilidad de entrega, en cada una de las iteraciones, de artefactos completos, no ambiguos, en los que se cumpla con estándares definidos para el desarrollo del producto y la gestión del proyecto. La Imagen 7 representa la descripción general de las características de la metodología, basada en el ciclo que enmarca las pautas que se deben llevar a cabo, junto con las herramientas, a través del tiempo del proyecto. Página 46

47 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Imagen 7. Ciclo de la metodología Enfoque: Es una metodología iterativa, debido a la flexibilidad que provee ante los cambios que se puedan generar en los requerimientos a través del tiempo, genera más valor para el usuario, contribuye con la corrección temprana de errores, generando un menor costo en el proyecto, y finalmente, permite tener más control sobre ciertas características del proyecto disminuyendo posibles riesgos. Principios: Los principios establecidos para la gestión y el desarrollo del proyecto de software son: Participación activa del usuario Página 47

48 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Entregas incrementales Requerimientos tomados como línea base Centrarse en actividades de alto valor Comunicación y retroalimentación constante Gestión del cambio Mantener independencia de herramientas y lenguajes de programación (Para ver la definición de los principios ver Anexo 1. Guía metodológica SWAPyME) Prácticas: Las prácticas son las técnicas recomendadas, asociadas a los principios del proceso de gestión y desarrollo del proyecto de software. Éstas, se basan en los valores de las metodologías ágiles, por lo tanto se ajustan a los principios del enfoque acá propuesto, mitigando la complejidad en diferentes procesos de gestión y de desarrollo que suelen tener las metodologías convencionales. Se muestran desde dos perspectivas (ver Imagen ), la primera respecto a la gestión de proyectos y la segunda en relación con cada una de las iteraciones que se dan en el desarrollo del producto. El logro principal de esta propuesta metodológica se basa en la integración de las prácticas que contribuyen con el aumento de la productividad, como la planeación, los ambientes colaborativos, el seguimiento y control del proyecto, e integración continua y las que hacen que haya una mejora en la calidad del producto, entre las cuales están la definición de requerimientos, el diseño del sistema, desarrollo basado en pruebas y la refactorización. Roles: Los roles se deben definir con el fin de cumplir con actividades y responsabilidades que se precisan en la metodología. Para este fin una persona puede ejercer más de un rol, sin embargo se deben tener en cuenta algunas excepciones, mencionadas en la descripción de cada rol (ver Anexo 1. Guía metodológica SWAPyME). Estos roles son sugeridos para la organización, por lo que en caso de necesitar alguno adicional, puede ser integrado a la metodología: Gerente de proyecto Página 48

49 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Líder técnico de proyecto Rol de desarrollador Rol de pruebas Rol de entrega del sistema Usuario multiplicador Usuario de negocio Ciclo SWAPyME: Dado que la metodología tiene un enfoque iterativo, cada una de las unidades principales de trabajo se entiende como una iteración dentro del proyecto, la cual se lleva a cabo en un corto y determinado tiempo, concibiendo esto como un ciclo. A continuación se describe el contenido de cada una de estas iteraciones, el tiempo sugerido que debe tardar y las actividades que se deben llevar a cabo. Preparación Se compone de las primeras actividades en el inicio del proyecto, donde se determinan las bases que guiarán su progreso, sin embargo ésta se debe ejecutar cada vez que se inicie una iteración, realizando modificaciones pertinentes en la planeación que se realice del proyecto (para conocer la descripción de estas actividades ver Anexo 1. Guía metodológica SWAPyME). Construcción En la iteración de construcción se desarrolla software de alta calidad que cumpla con las necesidades planteadas por el usuario. Se pueden llevar a cabo una o más iteraciones de construcción antes de realizar la entrega al cliente, basados en las historias de usuario, asignadas para la iteración que marcan el alcance de ésta, junto con las modificaciones pertinentes en el diseño de la arquitectura del sistema. Entrega al cliente En esta iteración se realiza una entrega formal al cliente de las historias de usuario que hayan sido construidas y que cuenten con la verificación pertinente. Se deben realizar pruebas de aceptación del cliente, a partir de las cuales se determinan los cambios que se deben realizar o controles de cambio que se deben ejecutar para la siguiente iteración. Se realiza un documento, con el fin de dejar definido lo que se entrega. Página 49

50 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Producción En esta iteración se debe controlar que el sistema es útil, cumple con las expectativas del cliente y es productivo al ser desplegado en el ambiente. Para cada organización puede ser diferente, sin embargo se debe prestar el servicio de soporte necesario, con el fin de solucionar dudas o problemas que se presenten y en caso de ser necesario, una capacitación que ayude al usuario a comprender el funcionamiento del sistema. Se sugiere realizar la entrega a un usuario multiplicador, que se encargue de instruir a las demás personas que hagan uso del sistema que se entrega al cliente. Cierre Consiste en analizar todas las actividades que se lograron realizar después de la última iteración de producción, donde se contemplan las debilidades del equipo y las habilidades por mejorar, además de las lecciones aprendidas para los próximos proyectos. Se realiza el cierre del proyecto por cada iteración del ciclo, dado que si en algún momento, por problemas que se presenten, se cancela el proyecto, se logre realizar el cierre adecuado del trabajo que se ha realizado hasta ese momento. Herramientas: Estudio de factibilidad técnica En este documento, se relacionan los principales aspectos que deben ser considerados para no desviar el alcance del proyecto y sus objetivos del estudio de pre factibilidad realizado y para llevar una trazabilidad con el mismo. Historias de usuario Las historias de usuario tienen como propósito detallar lo que el usuario de negocio quiere lograr por medio del sistema, en un lenguaje de negocio que éste logre comprender fácilmente. Son una manera rápida de gestionar los requerimientos del cliente sin elaborar una gran cantidad de documentos y sin llevar a cabo las tareas administrativas. Por medio de estas historias, el equipo de desarrollo responderá rápidamente y con menos esfuerzos a las cambiantes necesidades del mercado. Éstas se deben descomponer en funcionalidades que posteriormente se deben implementar para cumplir con la funcionalidad que se solicita. Con el fin de elaborar buenas historias de usuario se deben considerar seis características con las Página 50

51 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación que deben cumplir: Independientes, negociables, valorables, estimables, pequeñas y comprobables. Arquitectura de la solución El modelado tiene como principales beneficios organizar y facilitar la comunicación de ideas de manera eficiente y encontrar defectos temprano. Para tener una visión total del diseño del sistema se recomienda elaborar un modelo de comportamiento, un modelo de arquitectura y un modelo físico. Notas de entrega Este documento resume los cambios recientes, mejoras y errores corregidos, que se entrega con el producto final de cada iteración del proyecto. Grafo de trazabilidad Este documento modela la relación de los requerimientos iniciales del proyecto con el desarrollo de estos en cada una de las iteraciones. Cada historia de usuario está representada como un nodo y cada vínculo o dependencia entre ellos es denotado por un arco. Dadas las relaciones que existen entre las diferentes historias de usuario, planteadas en la preparación, el resultado de estos grafos se asemeja a una red compleja en la que se pueden visualizar los diferentes caminos o trazas requeridas para llegar a otros nodos. Son estas trazas las que indican la dependencia o no entre ellos. Evidencia de aceptación del producto La evidencia de aceptación del producto describe la evaluación por parte del cliente de los entregables del proyecto, describe y determina si cumplen con los criterios de aceptación establecidos en la preparación. Así mismo, identifica las tareas de aceptación, recursos y responsabilidades durante la ejecución de las iteraciones de desarrollo del proyecto. Lecciones aprendidas Este es un corto documento, que se debe realizar en la iteración de entrega al cliente, donde el líder técnico, junto con el equipo de desarrollo y pruebas, relata las causas de las dificultades presentadas, razones de las acciones correctivas elegidas para la solución temporal y la propuesta de solución definitiva que debe ser incorporada también en la base de conocimiento de la empresa. Adicionalmente, consolida los errores que no pudieron ser solucionados para tener en cuenta en la siguiente iteración o proyecto a realizar, Página 51

52 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Lista de chequeo calidad de software La lista de chequeo se emplea para revisiones y como recordatorio de las muchas tareas y aspectos que garantizan la coherencia e integridad del proyecto. Adicionalmente, puede servir para verificar cómo se ha llevado a cabo una actividad, identificar errores y corregirlos de forma rápida. Éste permitirá tener conocimiento acerca de la condición actual, de cada iteración, del desarrollo de software. Para la elaboración de este tipo de listas es necesario tener como base guías de los estándares necesarios que permitan cumplir con la calidad de producto que se desea. Estas guías están relacionadas con la codificación del producto, lo que permitirá evitar ambigüedades y confusiones que dificultan el entendimiento del código. Métricas ágiles La métrica más importante en un proyecto ágil es el valor que se está dando al cliente. Mediante esta métrica, el cliente puede conocer la velocidad con que retorna su inversión y saber cuándo ya no es necesario seguir con el proyecto, porque los beneficios pendientes de obtener ya no compensan sus costes. Sin embargo, para medir a una persona o a un equipo, es necesario utilizar un conjunto de métricas de diferentes aspectos relacionados, entre las cuales se deben tener en cuenta las siguientes (sugeridas más no limitadas): o Métricas de productividad y efectividad de la entrega o Métricas de resultados del proyecto o Métricas de situación financiera o Métricas de calidad de entregables y del proceso o Métricas de riesgos, impedimentos, proceso y mejora continua o Lecciones aprendidas. El criterio para definir una métrica de trabajo pueden ser las siguientes: o Útil para planeación o Relacionada con esfuerzo o Precisa: Es decir, que cuando dos personas midan lo mismo, deberán obtener los mismos resultados o Directamente contable y medible. Página 52

53 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Uso de herramientas de software Se presentan una serie de características y recomendaciones que se deben tener en cuenta en el momento de adquirir una herramienta, con el fin de automatizar y/o controlar algún proceso. Para apoyar adecuadamente el desarrollo ágil, las herramientas deben ser compatibles con la planeación actual y las prácticas de gestión promovidos por el enfoque ágil. Por medio de estas sugerencias, el gerente de proyecto podrá determinar si la herramienta que ya maneja cumple con las características y si no las cumple tomar una buena decisión al adquirirla (para conocer con mayor detalle estas recomendaciones ver Anexo 1. Guía metodológica SWAPyME). Página 53

54 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> IV POST-MORTEM A continuación se efectúa una comparación entre la planeación inicial del presente trabajo de grado, respecto a la metodología usada y las actividades, y la ejecución real del trabajo de grado, junto con los resultados obtenidos en lo referente a la efectividad de estimación del tiempo y riesgos del proyecto. IV.1 Metodología propuesta vs. Metodología realmente utilizada Teniendo en cuenta las fases establecidas dentro de la metodología propuesta inicialmente, con el fin de cumplir con los objetivos definidos, a continuación se presenta una relación entre lo que se formuló al iniciar el desarrollo del trabajo de grado y lo que en realidad sucedió: En la fase de exploración se llevó a cabo la búsqueda de las referencias bibliográficas, autores y fuentes de información relevantes para la elaboración de la base teórica de la memoria y la guía metodológica. En la fase de elaboración, se consolidó la información recolectada y se generó, a partir de ésta, cuadros conceptuales con el fin de organizar y estructurar la redacción de la guía metodológica y la memoria. La fase de validación de la guía metodológica se llevó a cabo con el fin de determinar si era viable y si tenía la calidad necesaria para su buena ejecución. Se realizó por medio de evaluación de juicio de expertos de la siguiente forma: La guía metodológica SWAPyme se entregó a expertos que tienen conocimiento académico y/o práctico de los elementos, de acuerdo a su perfil, gerentes de proyectos, que cuenten con experiencia en el tema de gestión de proyectos bajo metodologías de desarrollo ágil. En la fase final de cierre se presentan los documentos y guía metodológica que se generaron como entregables del trabajo de grado, debidamente revisados y corregidos, además de los resultados aportados en la etapa de validación de la guía metodológica. En general la metodología se cumplió, desarrollando efectivamente cada una de las actividades propuestas. Sin embargo, en la fase de validación, se realizó únicamente la Página 54

55 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación prueba de validación de expertos, porque se consideró que la puesta en marcha de la guía como caso de estudio, requería de esfuerzo y tiempo con el que no se contaba. IV.2 Actividades propuestas vs. Actividades realizadas Las actividades realizadas en cada una de las fases del proyecto fueron las siguientes: Exploración Se generó una plantilla con el fin de identificar los elementos característicos de cada una de las metodologías ágiles. Se definieron indicadores que permitieran identificar las mejores prácticas que aportan a la productividad en la gestión de proyectos de software y la calidad en la entrega de resultados de proyectos de construcción y evolución de software. Se seleccionaron las prácticas que generaran mayor eficiencia y productividad en los proyectos de desarrollo de software. Se estructuró la información obtenida durante la exploración en la plantilla Se identificaron herramientas basadas en metodologías ágiles que son útiles para las Pymes del sector de servicios, que no son fábricas de software. Elaboración Se consolidaron las herramientas que acompañan la propuesta metodológica. Se identificó el objeto de las diferentes herramientas y su nivel de aporte a la agilidad de atención de necesidades de TI y los usos que pueden darle las Pymes del sector de servicios, que no son fábricas de software. Se seleccionaron los conceptos claves para la guía metodológica (Calidad, productividad) Se realizó la redacción de la guía metodológica Validación La validación técnica de la guía metodológica se llevó a cabo por medio de la validación de juicio de expertos Se realizó el afinamiento pertinente de la guía metodológica a partir de los resultados y observaciones obtenidas en la ejecución de la validación Se realizó una revisión final de la guía metodológica. Cierre La elaboración de la memoria se llevó a cabo en paralelo con la guía metodológica. Página 55

56 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Se elaboró la página web en la que se presenta el trabajo de grado, junto con sus entregables. En relación con la ejecución real del trabajo de grado, se logró llevar a cabo todas las actividades que se habían planeado inicialmente. V RESULTADOS Y REFLEXIÓN SOBRE LOS RESULTADOS Con el fin de poner a prueba la guía metodológica, producto final de este trabajo de grado, se planeó una muestra de expertos en el tema de prácticas ágiles y gestión de proyectos informáticos (ver Anexo 3. Perfiles de los expertos), con experiencia, tanto en la academia como en la industria, a quienes dado su conocimiento se solicitó evaluar la guía metodológica junto con sus anexos. Con el fin de estandarizar los resultados de la evaluación y medir el nivel de aceptación se diseñó un formato de encuesta, con el fin de obtener retroalimentación del estado de madurez de la guía metodológica. La encuesta (ver Anexo 2. Formato de evaluación) consta de preguntas cerradas, manejando escalas Likert 8 y adicionalmente, con el ánimo de entender el criterio de evaluación que se eligió, tiene la opción de realizar comentarios adicionales, los cuales posteriormente fueron consignados en el formato de toma de decisiones (ver Anexo 4. Método de captura y análisis de resultado). La evaluación se estructuró con el ánimo de evaluar la guía desde tres perspectivas diferentes: contenido, calidad y productividad. De esta manera, adicionalmente, se logró correlacionar los resultados con el propósito de la metodología. La perspectiva contenido permitió evaluar, desde una visión más general, la forma en que está planteada la guía metodológica, con el objeto de validar el nivel de entendimiento del usuario de la guía. La perspectiva de calidad, permitió determinar la validez y el aporte de los aspectos propuestos respecto a los elementos que aseguran la calidad de producto, haciendo uso de la guía. 8 La escala de tipo Likert es una escala psicométrica comúnmente utilizada en cuestionarios, y es la escala de uso más amplio en encuestas para la investigación. Cuando se da respuesta a un elemento de un cuestionario elaborado con la técnica de Likert, se hace especificando el nivel de acuerdo o desacuerdo con una declaración (elemento, ítem o reactivo). Página 56

57 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación La perspectiva de productividad, permitió determinar la validez y el aporte de los aspectos propuestos respecto al aumento de la productividad en la gestión del proyecto, haciendo uso de la guía. Previo a la consolidación de los resultados, se diseñó un mecanismo de toma de decisión que permitiría una vez obtenidos los resultados y los comentarios entregados por los expertos, determinar entre realizar modificaciones sobre la guía o registrar como recomendaciones que pueden ser aplicadas posteriormente a la guía metodológica. Para conocer los resultados, se realizó la tabulación de las respuestas, en la que se determina el nivel de aceptación por cada ítem relacionado en cada uno de los conjuntos de preguntas. En las siguientes gráficas se pueden ver los resultados que fueron obtenidos en la validación. Las franjas de color verde se refieren a la aprobación total del ítem por parte de los expertos, las de color amarillo, se refieren a que hay una aprobación, pero que se deben realizar modificaciones al respecto para que sea total, de color naranja, representa que existe una contrariedad en lo que al ítem se refiere, pero que se puede solucionar realizando arreglos y finalmente, el color rojo representa la dificultad presentada, por divergencia o desacierto en lo que se quería transmitir, del ítem al que se refiere. 70% 60% 50% 40% 30% 20% 10% 0% Contenido Imagen 8. Resultados perspectiva contenido TDA DA ED TED Página 57

58 Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Calidad TDA DA ED TED Imagen 9. Resultados perspectiva calidad 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Productividad TDA DA ED TED Imagen 10. Resultados perspectiva productividad Página 58