Tatiana Alejandra Oquendo Garzón

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

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 Ingeniero Efrain Ortiz Pabon Ingeniero Rafael Andrés González Rivera, Msc. Página web del Trabajo de Grado http://pegasus.javeriana.edu.co/~cis0930is06 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C. Diciembre, 2011 Página 2

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

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

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación AGRADECIMIENTOS Agradezco inmensamente a mis padres que con profundo amor y esfuerzo me dieron la oportunidad de formarme profesionalmente. A mis hermanos, por ser mi soporte y fuente alegría en los mejores y peores momentos de mi vida. A John Vásquez por ser mi polo a tierra, por su ayuda, tolerancia y apoyo absoluto. A mis amigas, Nataly Guerrero y Marcela Castro, que siempre estuvieron dispuestas a ayudarme y darme la mejor de las energías para seguir. A mis ángeles que están en el cielo, por cuidarme y ayudarme cada día a tener la fortaleza que necesito para seguir adelante y a quienes dedico este logro porque sé que se sienten orgullosos. Un agradecimiento grande a mi directora de trabajo de grado, Angela Ramírez, por su dedicación, esfuerzo y el bagaje de conocimientos que aportó en mi vida, tanto a nivel académico como profesional. Finalmente, agradezco a los expertos por su tiempo, aportes y disposición, y a todas las demás personas que contribuyeron directa o indirectamente para que este trabajo pudiera llegar a su exitosa culminación. Página 5

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...37 II.2.1 Agilidad...37 II.2.2 Desarrollo ágil de software...39 Página 6

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II.2.3 Metodología...40 II.2.4 Producto...40 II.2.5 Proyecto...40 II.2.6 Calidad...41 II.2.7 Calidad ágil...41 II.2.8 Productividad...43 II.2.9 Productividad ágil...43 III DESARROLLO DEL TRABAJO...45 IV POST-MORTEM...53 IV.1 Metodología propuesta vs. Metodología realmente utilizada...53 IV.2 Actividades propuestas vs. Actividades realizadas...54 V RESULTADOS Y REFLEXIÓN SOBRE LOS RESULTADOS...55 VI CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS...58 VI.1 Conclusiones...58 VI.2 Recomendaciones...59 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 VIII.5 Anexo 5. SWAPyME para pymes del sector de servicios...66 Página 7

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> LISTA DE IMÁGENES Imagen 1. Resultados del informe "Chaos Report 2009"...16 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...26 Imagen 5. Metodologías ágiles más usadas...27 Imagen 6 Qué es ágil...39 Imagen 7. Ciclo de la metodología SWAPyME...46 Imagen 8. Prácticas de la metodología SWAPyME...48 Imagen 9. Resultados perspectiva contenido...56 Imagen 10. Resultados perspectiva calidad...57 Imagen 11. Resultados perspectiva productividad...57 Página 8

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...34 Tabla 7. Comparación de metodologías...36 Tabla 8. Análisis comparativo de las metodologías...36 Página 9

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 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 madurez en la gestión 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

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 son una diferencia entre consolidar el negocio o desaparecer, nace la visión de gestión de proyectos, particularmente informáticos, como una alternativa para fortalecer el portafolio de la empresa y/o la capacidad operativa para mantenerse en el mercado. Por lo general, el fracaso en los proyectos ocasiona 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, siempre velando por el cumplimiento de aspectos de calidad, costo y tiempo, y habilitando en lo posible saltos tecnológicos para atender necesidades actuales y futuras del negocio o el mercado; siendo así, la gestión adecuada de un proyecto, requiere una formulación adecuada de las necesidades y herramientas disponibles y controlar los aspectos del entorno que determine el éxito en la ejecución del mismo. En otras palabras, 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. Para responder a éste tipo de proyectos las Pymes cuyo enfoque de negocio no está relacionado con el desarrollo de software requieren de outsourcing, para atender proyectos informáticos, dado que aún tienen en su gestión actividades que no son esenciales para su negocio y que, adicionalmente exigen un alto nivel de involucramiento por parte de TI en la atención en el detalle del ciclo de vida del software, lo que correspondería a recursos especializados en el tema, por lo tanto 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 asumir retrasos que no están bajo su responsabilidad. 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 de un aumento de la carga operativa, dada la lentitud con la cual se atienen los requerimientos gestionados en las áreas de TI. En conclusió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. Página 11

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Por lo antes expuesto, se identificó la necesidad de plantear una alternativa para abordar las metodologías usadas y así dar valor a las cosas más importantes atenuando lo menos importante, desde la perspectiva de las áreas de TI, debido a que esto estaba absorbiendo gran cantidad de tiempo valioso y produciendo pocos beneficios. Como complemento, las empresas desarrolladoras de software han efectuado cambio en: la percepción del tiempo, alcance y calidad de los productos que van a ser entregados, en la búsqueda de nuevas y mejores estrategias para lograr mayor eficiencia y efectividad en todo el ciclo de vida del proyecto; en la ejecución de procesos más eficientes apuntando al objetivo de la entrega en períodos de tiempo específicos mejorando incluso la calidad del producto entregado. Todas estas iniciativas de las empresas desarrolladoras de software y área de TI se han consolidado en el uso de alternativas metodológicas basadas en prácticas ágiles, 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. Estas metodologías de enfoque ágil prestan su atención, por un lado en la gestión de proyectos promoviendo el aumento en la productividad de la gestión del ciclo de vida del mismo, y por otro lado en el producto, apuntando al aumento de calidad de los productos finales entregados al cliente. La Guía metodológica SWAPyME (resultado de éste trabajo de grado), es una propuesta ágil que busca tomar los mejores elementos de las metodologías de gestión ágil de proyectos y de desarrollo, proporcionando a los gestores de proyectos los elementos conceptuales que les permita simultáneamente aumentar la productividad contribuyendo de forma activa en el ciclo de vida del proyecto y asegurar la calidad del producto entregado. Página 12

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación INTRODUCCIÓN 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, el cual que tiene como finalidad proporcionar a las Pymes, del sector de servicios una herramienta para que enfoquen sus esfuerzos en la gestión ágil y desarrollo ágil de proyectos informáticos, esto a partir de la investigación realizada sobre las metodologías ágiles. 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 se requiere para hacer uso de éstas, y adicionalmente se entrega una breve comparación entre las metodologías ágiles que fueron elegidas para la investigación realizada, con el fin de sustentar la razón por la cual se incluyen cada una de las prácticas referenciadas en la guía metodológica propuesta. 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. 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. Página 13

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> 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

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, 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, desvirtuando el paradigma de relación entre tiempo y calidad en los proyectos informáticos. 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, que además de las implicaciones antes expuestas, no usar una metodología implica un alto costo al implementar un cambio en el proyecto o proceso de construcción de software, lo cual compromete la calidad esperada por el usuario. En general lo que se evidencia como una de las principales causas del fracaso de los proyectos de software. La Imagen 1, presenta 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, 44% deficientes por presentar retrasos, presupuesto excedido, y/o menos de la funcionalidad prometida y el 24% de los proyectos fracasaron siendo cancelados o nunca usados [1]. Página 15

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Éxitoso Deficiente Fracasó Imagen 1. Resultados del informe "Chaos Report 2009" 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 la curva de aprendizaje es baja en comparación con las metodologías tradicionales, estas metodologías, conocidas como metodologías ágiles, 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. Al referirnos a metodologías ágiles, es necesario tener claro el término desarrollo ágil, el cual fue creado en el año 2001 y se introdujo en el Manifiesto Ágil [2], partiendo del hecho 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, las prácticas á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 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, necesarios para la gestión de su ciclo vida. Página 16

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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. Como ingrediente adicional al reto de responder al usuario con calidad y oportunidad óptima, 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 principales economías, en consecuencia se requieren nuevos procesos de desarrollo para que la colaboración global sea exitosa. Por otra parte, 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, entre otros. Es por esto que se han desarrollado herramientas, metodologías y prácticas que han surgido como respuesta al reto de satisfacer las nuevas metas de las empresas y alinear el desarrollo de proyectos informáticos con los objetivos del cliente. La mayor parte de estos aportes se han enfocado en brindar soluciones a las empresas que no son fábricas de software para cumplir con los objetivos estratégicos, para lo cual necesitan mantener 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 [3]. 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 Página 17

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> 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 SWAPyME, consiste en hacer más productiva y con mejor calidad la gestión de proyectos informáticos 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 fortalecer los procesos metodológicos que acompañan 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 empresa, que serán entregados por medio del servicio de outsorcing prestado por una fábrica de software. I.1.3 Justificación En los proyectos de desarrollo de software, generalmente, 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, generando diferentes problemas de productividad a la empresa. La causa principal de estos problemas se da, en la mayoría de los casos, por 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. 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 se debería 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

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Imagen 2. Razones para la adopción de prácticas ágiles 1 En la Imagen 2, se pueden observar 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%. En lo general, 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 entregar a las empresas Pymes del sector de servicios una guía metodológica que les ayude a gestionar proyectos informáticos y entregar a estudiantes de ingeniería de sistemas de la Pontificia Universidad Javeriana la base del trabajo de grado que puede y debe ser madurada para así fortalecer la propuesta. A mediano plazo, se espera que la guía sea adoptada como referente para la gestión de proyectos en las empresas Pymes del sector de servicios de Bogotá. 1 Imagen obtenida de: [28] Página 19

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> A largo plazo, consolidar la guía metodológica SWAPyME como una metodología ágil para la gestión de proyectos de software en las empresas que no son fábricas de software. 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 (ver Imagen 3). Estas fases permiten el desarrollo constante e iterativo sobre cada uno de los entregables del trabajo de grado. Página 20

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

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 presente 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, 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 [4]. El autor y conferencista Martin Fowler [5] plantea que la clave del desarrollo iterativo es entregar frecuentemente versiones que funcionen del sistema final que tengan un subconjunto de las funcionalidades requeridas. 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 [6]. 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

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Network 2 y el Manifiesto de Desarrollo de software ágil, escrito por muchos de los miembros fundadores de la Alianza Ágil 3 [7]. 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." [8] 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 [2]: 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. 2 www.apln.org 3 www.agilealliance.org Página 23

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.1.3.1 Principios del manifiesto ágil En esta reunión del 2001 se determinaron los siguientes principios en los que se fundamenta el manifiesto ágil [2]: 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

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. [2] 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ó [9], 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

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 [7], 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. Imagen 4. Proceso de metodologías ágiles 4 4 Imagen tomada de [7] Página 26

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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 en el mercado internacional, según se muestra en los resultados de la encuesta (ver Imagen 5) realizada por la compañía VersionOne en el año 2010 [10]. Imagen 5. Metodologías ágiles más usadas 5 Estas metodologías son: SCRUM [11], [12], extreme Programming (XP) [13], Dynamic System Development Method (DSDM) [14], Feature Driven Development (FDD) [15], Lean Software Development (LSD) [16], Adaptive Software Development (ASD) [17], Agile Unified Process (AUP) [18] y Crystal [19]. A continuación, de acuerdo a la sugerencia propuesta por Alistair Cockburn, en su libro Surviving Object-Oriented Projects: A Managers Guide, con respecto a las características fundamentales de una metodología, 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. 5 Imagen tomada de [10] Página 27

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II.1.5.1 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

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> II.1.5.2 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 confiable de software que trabajan de manera oportuna con información muy precisa y significativa para todas las funciones clave dentro y fuera 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 (RUP) 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

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II.1.5.3 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.1.5.4 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

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> II.1.5.5 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 sostenible Investigación Refinamiento Consolidación Modelado de objetos de dominio Desarrollo por funciones Propiedad de clase (Código) individual Equipos de característica s Inspecciones Construccion es 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 6 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 el proyecto sin temor a represalias. La otra forma de seguridad es que el 6 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. [61] Página 32

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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 II.1.5.6 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 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 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 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 Página 33

Ingeniería de Sistemas 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 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. <ISTAR> - < CIS0930IS06> Tabla 6. Principios de las metodologías 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. 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 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.1.5.7 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 soluciones de software: Scrum XP DSDM FDD LSD ASD AUP Crystal Proyecto x x x X x Producto x x x Página 34

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación II.1.6 Comparación de metodologías En la siguiente tabla se muestran las fortalezas y debilidades de cada una de las metodologías definidas en los capítulos anteriores: Scrum XP DSDM FDD LSD 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. 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. 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. 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. Página 35

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> AUP Crystal 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. 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. Tabla 7. Comparación de metodologías 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. 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. 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 y que aportan de manera sustancial en el objetivo del aumento de la productividad en la gestión de un proyecto y la calidad en el desarrollo de un producto de software. Las condiciones que se tuvieron en cuenta fueron: Tamaño del equipo, recolección de requerimientos, si es apta para múltiples clientes, la cultura ceremonial de la metodología, la capacidad de adaptabilidad en un equipo distribuido 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 36

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 SWAPyME 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 contextualiza a partir de 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 [20]. Capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno [21]. Mejora continua y regular, basada en el aprendizaje continuo [22], que como se observa en la Imagen 6, la agilidad 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 Página 37

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> son la mantenibilidad del producto, el paso sostenido y que brinda calidad y productividad. 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 autoorganizarse, 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 38

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación Imagen 6 Qué es ágil 7 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 7 Imagen tomada de [22] Página 39

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> 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 [23]. 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 [24]. 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 [25]. 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 el enfoque del PMBOK, 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 y 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 [25]. 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 40

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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 [26]. 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 [27]. 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é produciendo. Esto implica una fuerte dependencia entre los desarrolladores y testers 8 en la medida que trabajen en estrecha colaboración para lograr este objetivo común [28]. 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. Sin embargo se ha encontrado que las prácticas ágiles aseguran costo-efectividad de una solución si se incluyen herramientas de control del entorno del proyecto y se utilizan herramientas de iteración que permitan hacer cambios en los requerimientos de los clientes. 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 [29]. En este entorno, una innovadora técnica es propuesta para la evaluación de metodologías con el fin de determinar los factores de calidad de software existentes. Ésta consiste en un conjunto de factores de calidad del software adaptado según lo definido por Bertrand Meyer y McCall [29]. 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: 8 Nombre con el que se llama a las personas encargadas de realizar las pruebas de software. Página 41

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> 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. 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. Página 42

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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. [29]. En conclusión, consecuente con los principios ágiles, se debe tener presente que la calidad de un proyecto depende directamente de las personas que trabajan en él. La productividad y la calidad dependen de la capacidad de reflexión y de aprendizaje de un equipo, de las herramientas que se utilicen y de su capacidad de automatización [22]. 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 [30]. Una investigación realizada por la International Data Corporation (IDC por sus siglas en inglés) [31], 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 [32] se 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 Página 43

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> diferencia. Permitiendo así tener evidencia 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. Además, si se estructuran grandes requerimientos en entregas incrementales que mejoran el time-tomarket, permite a las empresas ser más sensibles a la dinámica del mercado. Adicional, para reducir la curva de aprendizaje en el tiempo, se evidencia que el 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, y consecuentemente, el éxito de un equipo con el desarrollo ágil puede ser un ejemplo para llevar a la adopción por parte de la organización de estos nuevos paradigmas de gestión. 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 [33]. Por otro lado, Jeff Sutherland [34] 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 44

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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, por lo tanto en el Anexo 5. SWAPyME para pymes del sector de servicios, se puede conocer la descripción en cuanto a la aplicación de la metodología SWAPyME en una pyme del sector de servicios. 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 describen las siguientes características que estructuran el planteamiento y la gestión del ciclo propuesto para 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. Página 45

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> 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. Imagen 7. Ciclo de la metodología SWAPyME 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, Página 46

Pontificia Universidad Javeriana Memoria de Trabajo de Grado Proyecto de Investigación 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 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 8), 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. Página 47

Ingeniería de Sistemas <ISTAR> - < CIS0930IS06> Imagen 8. Prácticas de la metodología SWAPyME 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 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. Página 48