PROPUESTA PARA TRABAJO DE GRADO

Transcripción

1 Ingeniería de Sistemas TÍTULO PROPUESTA PARA TRABAJO DE GRADO Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil MODALIDAD Ayuda Didáctica OBJETIVO GENERAL Elaborar una guía que permita ayudar a organizaciones de desarrollo ágil, en la selección de técnicas propias de Ingeniería de Requerimientos formales, las cuales de acuerdo al contexto del proyecto y la organización apoyen los procesos ya existentes al interior de las mismas, teniendo como referente el uso de buenas prácticas en la Ingeniería de Software. ESTUDIANTE(S) Juan Darío Murcia Torres Documento Celular Teléfono fijo Correo Javeriano CC murcia.juan@javeriana.edu.co DIRECTOR Ing. Miguel Eduardo Torres Moreno Documento Celular Teléfono fijo Correo Javeriano Empresa donde trabaja y cargo cc ext metorres@javeriana.edu.co Pontificia Universidad Javeriana; Profesor 5316 Departamento de Sistemas 5/27/2014

2 Contenido 1 OPORTUNIDAD O PROBLEMÁTICA DESCRIPCIÓN DE LA OPORTUNIDAD O PROBLEMÁTICA FORMULACIÓN JUSTIFICACIÓN IMPACTO ESPERADO DEL PROYECTO DESCRIPCIÓN DEL PROYECTO OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS ENTREGABLES O RESULTADOS ESPERADOS PROCESO FASE DE ANÁLISIS Y ESPECIFICACIÓN Metodología (Investigación exploratoria) Actividades Hitos FASE DE INTEGRACIÓN DE COMPONENTES Metodología (integración basada en workflows) Actividades Hitos FASE DE VALIDACIÓN Metodología (Validación por experto) Actividades Hitos GESTIÓN DEL PROYECTO CALENDARIZACIÓN PRESUPUESTO ANÁLISIS DE RIESGOS COMPROMISO DE APOYO DE LA INSTITUCIÓN DERECHOS PATRIMONIALES MARCO TEÓRICO / ESTADO DEL ARTE FUNDAMENTOS Y CONCEPTOS RELEVANTES PARA EL PROYECTO Ingeniería de Requerimientos (IR) Métodos ágiles SEMAT (Software Engineering Method and Theory) (Jacobson, Ng, McMahon, Spence, & Lidman, 2012) TRABAJOS IMPORTANTES EN EL ÁREA...26 Página 1

3 5.3 GLOSARIO REFERENCIAS Y BIBLIOGRAFÍA REFERENCIAS BIBLIOGRAFÍA PROPUESTA PARA EL DESARROLLO DEL TRABAJO DE GRADO...30 Página 2

4 1 Oportunidad o Problemática 1.1 Descripción de la Oportunidad o Problemática Según los principios de las metodologías ágiles, la simplicidad en las tareas es un factor fundamental a la hora de desarrollar software (Beck, y otros, 2002). Parte de esta simplicidad consiste en la reducción de la documentación generada durante el proceso de desarrollo, dedicando más esfuerzos a la creación de software funcional por medio de una fuerte comunicación con el cliente. A pesar de hacer uso de la Ingeniería de Requerimientos, al no ser este tipo de metodologías lo suficientemente formal, algunos elementos no se encuentran claramente separados e identificados, provocando dificultades en el futuro cuando se necesite algún producto propio de estos procesos (Paetsch, Eberlein, & Maurer, 2003). Actualmente en muchas metodologías ágiles se es consciente de lo anterior, y se está proponiendo más formalismo a pesar de su naturaleza, como es el caso de XP (en su segunda edición) el cual propone algunas nuevas prácticas en las que a diferencia de su primer versión, se sugiere documentar aspectos como el contrato de negociación y algunas decisiones que se tomen durante el desarrollo del proyecto (Kent & Cynthia, 2004). De una manera mucho más formal, las metodologías tradicionales enfocan sus esfuerzos principalmente en el descubrimiento, desarrollo, trazabilidad, y análisis de requerimientos, de tal forma que sean definidos de manera estricta por medio de técnicas bastante bien estructuradas del área de conocimiento conocida como Ingeniería de Requerimientos (Hull, Jackson, & Dick, 2011). Todos los proyectos de software son diferentes, ya que poseen características que varían de acuerdo al tipo de software a desarrollar, al ciclo de vida establecido y definido por la organización, y a las mismas necesidades del cliente, de este modo las compañías pueden seleccionar metodologías ágiles o tradicionales para realizarlos. Sin embargo, muchas veces para abordar nuevos proyectos dentro de la organización o soportar los ya realizados ante la gerencia, es necesario contar con documentación detallada y políticas de trazabilidad definidas (Sommerville, 2010), lo cual usando metodologías tradicionales en teoría- estaría asegurado, pero en los proyectos ágiles esto desafortunadamente no siempre es así, por lo que se sugiere una metodología que ayude a soportar los procesos ágiles ya existentes dentro de la organización, con una Ingeniería de Requerimientos lo suficientemente formal. Para una organización es muy importante desde sus inicios establecer un tipo de metodología para desarrollar sus proyectos, esto con el fin de que valla madurando con el tiempo, y cada vez genere mejores resultados. De igual forma siempre es necesario tener en cuenta los estándares y modelos que apliquen según el caso, de manera que para que las compañías desarrolladoras de software realicen sus procesos de desarrollo con calidad, deberían seguir dichos modelos, como lo son por ejemplo CMMI y MoProSoft, entre otros. La correcta implementación de estos modelos es vigilada y certificada por distintas organizaciones en cada país, las cuales garantizan que estos procesos de desarrollo se estén realizando no solo con calidad, sino también siguiendo la correspondiente normativa (CMMI, 2013), (Nyce, 2013). Además de lo anterior, existen iniciativas como SEMAT (Jacobson, Meyer, & Soley, SEMAT, 2009-a), que buscan por medio de una teoría lo suficientemente formal, la implementación de la Ingeniería de Software utilizando las mejores prácticas de los más de Página 3

5 métodos existentes (Jacobson, Meyer, & Soley, SEMAT, 2009-b) dentro de los cuales se encuentran RUP, CMMI, Scrum y XP entre otros. Finalmente, en un contexto nacional las organizaciones Fedesoft (FEDESOFT, 2013) y Min- TIC (MinTIC, 2013) son las encargadas de agrupar a las empresas desarrolladoras de Software en Colombia, proveyendo además de normativas, regulación y estándares, talleres, certificaciones, seminarios y demás actividades para garantizar que dichas empresas realicen este proceso con calidad. Para el desarrollo de este proyecto, se hará énfasis únicamente en organizaciones que implementen procesos ágiles, y en un contexto que agrupe las necesidades más generales de dichos procesos. De acuerdo a lo anterior, se observa que aunque existen iniciativas como SEMAT, aún no se ha propuesto una guía metodológica que teniendo en cuenta procesos de desarrollo al interior de las organizaciones permita a quien la aplique, unificar metodologías ágiles e ingeniería formal de requerimientos para generar procesos más acordes a la organización. 1.2 Formulación Cómo por medio de la aplicación de una Guía Metodológica puede la Ingeniería de Requerimientos formal, apoyar y fortalecer procesos propios de las metodologías ágiles, a través de la selección de métodos adecuados al entorno del proyecto y la organización? 1.3 Justificación Según el último Informe CHAOS del proyecto CHAOS de The Standish Group, en 2012 el 39% de los proyectos de software culminaron con éxito, sin embargo y aunque esta cifra ha disminuido en comparación a años anteriores el 18% de los proyectos terminó de manera fallida, y en un 43% de las oportunidades, hubo problemas durante la etapa de desarrollo (The Standish Group, 2013). Las anteriores cifras dan una idea acerca de la actualidad de los proyectos de desarrollo de software, y muestran que solo algunos consiguen ser exitosos. De esta manera se logra ver que en un 61% de los proyectos se tienen inconvenientes que hacen que estos no funcionen de manera apropiada, generando en determinado caso que el proyecto no se logre si quiera culminar. Según el artículo What Software Fails publicado en una edición digital de IEEE Spectrum, los proyectos pueden fallar por los siguientes factores comunes (Charette, 2005): Objetivos de proyecto no realizables, Inexactitud en la estimación de recursos, Requerimientos del sistema definidos de manera errónea, Presentación pobre de los informes del proyecto, Riesgos no gestionados, Comunicación pobre entre clientes, desarrolladores y usuarios, Uso de tecnología poco madura e inestable, Incapacidad para manejar la complejidad del proyecto, Malas prácticas de desarrollo, Gestión pobre del proyecto, Políticas de los Stakeholders y finalmente Presiones comerciales. Es de notar que los factores enunciados anteriormente son genéricos y no aplican siempre en todos los proyectos, eso depende del tipo de metodología usada por la organización. Por ejemplo, cuando se usan metodologías ágiles, es casi incomprensible hablar de una pobre comunicación con el cliente, debido a que por el contrario esta es una de sus fortalezas. De acuerdo a esto, y teniendo en cuenta que la Guía se desarrollará enfocada a organizaciones que hagan uso de métodos y procesos ágiles, se observa que sería posible reducir muchos de Página 4

6 estos factores de riesgo, y más aún, ayudar a abordar los elementos que no se están teniendo en cuenta durante la ejecución del proyecto, y que podrían ser claves en un futuro, apoyando dichos procesos sobre Ingeniería de Requerimientos un poco más formal a la usada en la actualidad por la organización. Actualmente se encuentran diferentes trabajos relacionados con temas como trazabilidad e implementación de métodos formales en proyectos ágiles como por ejemplo Implementing Traceability In Agile Software Development (Jacobsson, 2009) o An Agile Approach to Capturing Requeriments and Traceability (Lee, Guadagno, & Jia, 2003), sin embargo, según el leal saber y entender del autor, aún no se ha desarrollado una metodología basada en SEMAT, que guíe a compañías desarrolladoras de software (basadas en procesos ágiles), en la implementación de sus proyectos, fundamentándose en un conjunto de buenas prácticas y apoyadas por mecanismos, técnicas y/o métodos más (o menos) formales a los ya existentes en la organización, de tal modo que estos procesos se adapten de una mejor forma a las necesidades de los stakeholders (todos aquellos a quienes interesa o afecta el sistema a desarrollar) (Sommerville, 2010) y del proyecto en sí mismo. Para garantizar que lo anterior se haga de una manera apropiada, y permitiendo hacer uso de las mejores prácticas (de los métodos más apropiados según el contexto de la organización), se pretende utilizar SEMAT (Jacobson, Meyer, & Soley, SEMAT, 2009-a) como base fundamental de la guía. De esta forma, SEMAT proporcionará un factor clave para la especificación de los métodos y prácticas, ya que el permitirá especificar e integrar estos de una forma sencilla. Para concluir, este proyecto pretende generar un documento (Guía Metodológica) que sirva como pauta a organizaciones desarrolladoras de software que usen principios ágiles, para facilitar la selección de elementos que se adapten a sus políticas, metodologías y procesos. Para esto se intenta proporcionar un conjunto de elementos clave de la Ingeniería formal de Requerimientos, que basados en SEMAT, y en combinación con la experticia del lector, permita a las organizaciones apoyar los procesos ya establecidos al interior de la compañía, por medio de las mejores prácticas de la Ingeniería de Software aplicables al proyecto. 1.4 Impacto Esperado del Proyecto En caso de que la Guía Metodológica propuesta sea exitosa, se espera que realmente ayude a las organizaciones a continuar desarrollando software de calidad y con facilidad a la hora de seleccionar los procesos que se acoplen a los propios con el fin de soportar procesos de la Ingeniería de Requerimientos formal. En un corto plazo, se esperan pruebas en algunas organizaciones (con el fin de la validación de la guía) e implementaciones en un ámbito meramente académico, de tal forma que los estudiantes y/o docentes que puedan desarrollar proyectos para sus clases basados en esta guía, observen una facilidad a la hora de implementarla logrando los objetivos esperados. En un mediano plazo, se pretende que la guía sea usada por organizaciones desarrolladoras en Colombia que se basen en procesos ágiles, permitiendo a la industria del software nacional, ser más competitiva, y desarrollar software de la misma o mejor calidad a la actual. (Lo cual no se podría determinar en un comienzo, ya que la guía se desarrolla únicamente con el fin de Página 5

7 proporcionar facilidades a las organizaciones que la apliquen, no asegura que se mejoren procesos durante la implementación) A largo plazo, lo ideal es que la guía sea reconocida nacional e internacionalmente (si es posible) por grandes organizaciones de desarrollo ágil. Página 6

8 2.1 Objetivo general 2 Descripción del Proyecto Elaborar una guía que permita ayudar a organizaciones de desarrollo ágil, en la selección de técnicas propias de Ingeniería de Requerimientos formales, las cuales de acuerdo al contexto del proyecto y la organización apoyen los procesos ya existentes al interior de las mismas, teniendo como referente el uso de buenas prácticas en la Ingeniería de Software. 2.2 Objetivos Específicos Sintetizar los aspectos más importantes de los métodos más usados de las metodologías ágiles, y crear un documento que muestre dicho resultado. Establecer los métodos y prácticas de la Ingeniería de Requerimientos (por medio de SEMAT y la síntesis generada con el cumplimiento del objetivo anterior) que más se acomodan a las metodologías usadas actualmente. Generar un documento que integre los diferentes módulos generados en el objetivo anterior, el cual, si es aplicado de manera apropiada (y de acuerdo a las características de cada proyecto), sea capaz de optimizar los procesos de desarrollo y negocio que actualmente usa. Validar la guía con la ayuda de un experto en Ingeniería de Software e Ingeniería de Procesos. 2.3 Entregables o Resultados Esperados A continuación se enuncian los entregables durante el desarrollo del Trabajo de Grado. En general, corresponden a un conjunto de elementos que cada vez se irán adhiriendo al documento principal, que es la Guía Metodológica. Documento de análisis sobre las principales metodologías ágiles y de Ingeniería de Requerimientos usadas en la actualidad. Documento que proponga los métodos y prácticas basadas en SEMAT que más se acomoden a las metodologías analizadas en el entregable anterior. Guía Metodológica que proponga el uso de SEMAT para la selección de herramientas y técnicas apropiadas según el proyecto de desarrollo de software. Informe de validación de la guía, proporcionado por uno o más expertos en Ingeniería de Software (pueden ser también organizaciones líderes en el tema de desarrollo de software). Memorias del Trabajo de grado. Página 7

9 3 Proceso Teniendo en cuenta el tiempo como principal limitante del desarrollo de esta Guía Metodológica, durante cada fase del proceso de realización del Trabajo de Grado, se adoptará el uso de Scrum como metodología de gestión (Schwaber, 2001) con el fin de realizar iteraciones (sprints) de dos semanas, y reuniones semanales enfocadas hacia el control y verificación de pequeñas tareas. Durante cada sprint serán asignadas distintas actividades referentes a la culminación de pequeñas secciones de los entregables de determinada fase. El estado de culminación/cumplimiento de dichas actividades será controlado y administrado en una lista de tareas o Sprint Backlog por el autor del TG. De manera similar, el Product Backlog es el documento en el cual (en proyectos de desarrollo de software) por lo general se hace la especificación de requerimientos, sin embargo en el caso de este Trabajo de Grado será usado para especificar los principales entregables, los cuales deberán ser presentados al final de todo el desarrollo como elementos fundamentales para la Guía Metodológica. Durante el proceso de desarrollo del TG, el Product Backlog, será controlado por el autor del TG, quien verificará en la reunión semanal (junto al director de Trabajo de Grado) el avance logrado e irá actualizando el estado (o porcentaje de culminación) de cada documento referente a la creación de la Guía Metodológica. 3.1 Fase de Análisis y Especificación Durante esta fase se usará una metodología de investigación exploratoria (Grajales G., 2000), ya que será la fase en la cual se realizará una aproximación y profundización en temáticas como SEMAT, Ingeniería de Requerimientos, Metodologías Ágiles. La idea principal de esta fase es proporcionar un contexto inicial que sirva como base para la elaboración de la Guía Metodológica Metodología (Investigación exploratoria) Por medio del análisis de las metodologías ágiles más usadas en organizaciones de desarrollo de software, definir un contexto sobre el cual profundizar en temas como Ingeniería formal de Requerimientos y procesos ágiles de desarrollo de software. De igual forma, se pretende llevar el control de avance general del proyecto por medio del Product Backlog, y de cada iteración requerida, mediante el Sprint Backlog correspondiente Actividades Levantamiento de información correspondiente a la actualidad (problemas más comunes, y forma de gestionar procesos de desarrollo) de las organizaciones desarrolladoras de software, enfocando esta búsqueda principalmente en las que soporten procesos ágiles. Análisis de las principales tendencias en el uso e implementación de métodos ágiles e Ingeniería de Requerimientos. Usando SEMAT, especificar un conjunto de prácticas de la Ingeniería de Requerimientos formal que mejor se acomode a los métodos más usados actualmente. Página 8

10 3.1.3 Hitos Documento de análisis sobre las principales metodologías, tendencias y herramientas ágiles y de Ingeniería de Requerimientos usadas actualmente en el desarrollo de software. Documento que proponga métodos y prácticas de Ingeniería de Requerimientos basadas en SEMAT, que soporten los procesos ágiles de las organizaciones. Product Backlog actualizado. Sprint Backlog por cada iteración realizada. 3.2 Fase de Integración de componentes Esta fase se enfoca principalmente en la integración de los hitos de la fase anterior con el fin de elaborar la Guía. Para esto, se pretende usar una metodología integración basada en flujos de trabajo (N. Aydin, 2005). La idea de estos workflows es que permitan no solo enlazar y unificar técnicas de desarrollo ágil con Ingeniería formal de Requerimientos por medio del framework de SEMAT, sino también intentar mejorar los procesos de desarrollo de software al interior de las organizaciones, de manera que la integración sea realizada y ajustada teniendo en cuenta dichos procesos. De igual forma, se pretende llevar el control de avance general del proyecto por medio del Product Backlog, y de cada iteración requerida, mediante el Sprint Backlog correspondiente Metodología (integración basada en workflows) Teniendo en cuenta posibles entradas y salidas de workflows referentes a procesos de Ingeniería de Software al interior de las organizaciones, proponer mejoras que se acomoden y se integren a dichos procesos y al contexto generado durante la fase de análisis y especificación, por medio de un conjunto de prácticas apropiadas Actividades Hitos Desarrollo de una Guía Metodológica que integre los hitos de la fase de análisis y especificación, teniendo en cuenta los workflows de los procesos de desarrollo de software. Guía Metodológica. Product Backlog actualizado. Sprint Backlog por cada iteración realizada. 3.3 Fase de Validación Finalizada la integración, y generada la Guía Metodológica, se procederá a la validación de esta, por lo que se utilizará una metodología de validación/juicio por expertos (Morales Nápoles & Cooke, 2009). En esta última fase se pretende seleccionar uno o dos expertos en Ingeniería de Requerimientos y/o procesos de desarrollo ágil, quien sea el que verifique la relevancia, coherencia, suficiencia y claridad de la Guía Metodológica y determine si lo reali- Página 9

11 zado durante las fases anteriores cumplió realmente con las expectativas del proyecto. De igual forma, se pretende llevar el control de avance general del proyecto por medio del Product Backlog, y de cada iteración requerida, mediante el Sprint Backlog correspondiente Metodología (Validación por experto) De acuerdo al conocimiento de terceros, determinar si la Guía Metodológica desarrollada durante las fases anteriores, se realizó de manera que se cumpla el objetivo general del proyecto Actividades Hitos Validar con un tercero (experto en el tema de Ingeniería de software u organización con experiencia en el desarrollo de software con métodos ágiles) la calidad y validez de la guía propuesta. Validación por parte de uno o más expertos. Product Backlog con ítems completamente terminados. Sprint Backlog por cada iteración realizada. Página 10

12 4.1 Calendarización 4 Gestión del Proyecto Para el desarrollo del proyecto, se tiene estipulado un total de 17 semanas para culminar todo el trabajo. Este tiempo será distribuido de la siguiente manera, de tal forma que se logren cumplir todos los objetivos: Fase de Análisis y Especificación 9 semanas. Fase de Integración de componentes 6 semanas. Fase de Validación 2 semanas. Para mayor detalle, ver Anexo 1 (Calendario de trabajo.png). 4.2 Presupuesto A continuación se muestra un estimado de los costos que pudiera haber durante el desarrollo del Trabajo de Grado. Ítem Cantidad Costo por Unidad Costo total Fotocopias 1000 $50 $50000 Libros 2 $60000 $ Portátil Dell XPS 15 1 $ $ Director de TG 50 horas $50000 $ Extras - - $ $ Los anteriores costos presupuestados para este proyecto, corresponden (por la naturaleza del mismo) a costos meramente de carácter investigativo. Por lo que el costo de los libros, y la cantidad de libros presupuestados para compra por parte del estudiante es mínima, en cuanto a que la mayoría de información relevante para el proyecto se obtendrá de recursos electrónicos de las bases de datos de la Biblioteca General de la Pontificia Universidad Javeriana, o de recursos físicos encontrados en otras bibliotecas de la ciudad. El ítem Extras corresponde a costos por licenciamientos o por ítems no tenidos en cuenta durante esta estimación de presupuesto. 4.3 Análisis de Riesgos Ver Anexo 2 (Análisis de Riesgos.xlsx). 4.4 Compromiso de apoyo de la Institución Al ser un trabajo meramente académico, no se recibe apoyo de instituciones externas durante el desarrollo de las dos fases iniciales. Será hasta la fase de validación que se haga necesaria Página 11

13 la intervención de terceros, por lo que el compromiso no será total, y únicamente corresponderá a las actividades referentes a dicha fase. 4.5 Derechos Patrimoniales Los derechos patrimoniales del Trabajo de Grado a desarrollar, serán de la Pontificia Universidad Javeriana, quien se compromete a hacer un adecuado uso de los documentos generados como entregables finales, y a respetar los derechos morales del estudiante como autor intelectual de dicho Trabajo de Grado (junto a los entregables desarrollados). Página 12

14 5 Marco Teórico / Estado del Arte 5.1 Fundamentos y conceptos relevantes para el proyecto. En esta sección se pretende explicar de manera un poco detallada la idea central de algunos autores respecto a determinadas temáticas (conceptos) Ingeniería de Requerimientos (IR) Los requerimientos para un sistema son descripciones qué es lo que el sistema debería hacer. Estos requerimientos reflejan las necesidades de los stakeholders en un sistema que sirve para cierto propósito como controlar un dispositivo, colocar una orden o buscar información. Este proceso de descubrimiento, análisis, documentación y chequeo de dichos servicios y/o restricciones se conoce como Ingeniería de Requerimientos (Sommerville, 2010). Existen muchos tipos de requerimientos, y de igual forma existen muchas clasificaciones, sin embargo se suelen agrupar en 3 tipos de requerimientos Los requerimientos del negocio, los requerimientos de usuario, y los requerimientos del sistema (Young, 2004). Los primeros representan a gran nivel los objetivos de la organización y/o las solicitudes del cliente con respecto al sistema o producto. Los segundos describen tareas que los usuarios deben poder realizar con el producto. Y los terceros son descripciones más detalladas de funciones, servicios y restricciones operacionales del sistema de software. Todo el proceso de IR debe estar reflejado en el Documento de Requerimientos del Sistema y debería ser parte del contrato entre el dueño del sistema y el grupo desarrollador. (Sommerville, 2010) En cuanto a los requerimientos del sistema, se encuentran divididos a su vez en dos grandes grupos, los requerimientos de hardware, y los requerimientos de software, quienes a su vez se dividen en requerimientos funcionales y no funcionales. Los requerimientos funcionales (también conocidos como requerimientos de comportamiento u operacionales debido a que especifican las entradas y salidas del sistema, desde y hacia otros sistemas, y las relaciones de comportamiento entre ellas) describen qué es lo que el sistema o software debería hacer, y qué servicios debería ofrecer. En el proceso de desarrollo se debe generar un documento de especificación de requerimientos, el cual es usado para comunicar los requerimientos a los clientes, sistemas e ingenieros de software, el cual se refiere a características y capacidades que deberían estar disponibles a los usuarios del sistema. De igual forma, podría incluir definiciones detalladas de las interfaces a usar en el sistema. (Young, 2004). Los requerimientos no funcionales como es de esperar no entran en detalles de qué se debería hacer, ni cómo debería ser el comportamiento, sino que describen propiedades específicas del sistema que se encuentran asociadas a atributos de calidad como rendimiento, seguridad, disponibilidad, usabilidad, portabilidad e integrabilidad entre otros (Eeles & Cripps, 2009). Adicionalmente pueden referirse a restricciones de implementación del sistema tales como capacidades de interacción con dispositivos o representaciones de datos usadas en interfaces con otros sistemas (Young, 2004). A continuación se muestran los principales tipos de requerimientos no funcionales: Página 13

15 Ilustración 1. Requerimientos no funcionales. (Sommerville, 2010) El proceso de Ingeniería de Requerimientos propone una serie de actividades realizadas de manera iterativa con el fin de generar el Documento de Requerimientos del Sistema, de tal modo que al finalizar todo el proceso de IR, se asegure que los requerimientos allí documentados, realmente cumplan con las necesidades de los stakeholders y del sistema. Ilustración 2. Vista en espiral del proceso de Ingeniería de Requerimientos Página 14

16 A continuación se detallan las actividades del proceso de Ingeniería de Requerimientos. Especificación de Requerimientos Es el proceso de anotar los requerimientos de usuario y del sistema en el Documento de Requerimientos, el cual debería especificar el comportamiento externo de dicho sistema, y tratar de no incluir detalles de arquitectura o diseño. Los requerimientos de usuario deben ser escritos en lenguaje natural, de tal forma que sean claros, no ambiguos, de fácil entendimiento, completos, y consistentes. Los requerimientos del sistema deben describir requerimientos funcionales y no funcionales de manera que sean comprensibles por usuarios del sistema que no poseen conocimiento técnico. Obtención y Análisis de Requerimientos En este proceso hacen parte activa los stakeholders, quienes deberían estar directamente influenciados por los requerimientos del sistema, o quienes se vean afectados por el sistema en sí mismo. Este proceso consta de 4 actividades más pequeñas, y que son parte fundamental en la obtención y análisis de Requerimientos: Descubrimiento de Requerimientos: Este es el proceso en que se interactúa con los stakeholders del sistema para descubrir sus requerimientos. Organización y clasificación de Requerimientos: Esta actividad toma colecciones de requerimientos sin estructura, grupos de requerimientos relacionados y los organiza en clusters coherentes. Priorización de Requerimientos: Es inevitable que algunos requerimientos entren en conflicto con otros, por lo que se hace necesario priorizarlos para encontrar y resolver dichos conflictos Especificación de Requerimientos: Estos requerimientos finalmente son documentados y preparados para la siguiente iteración. Validación de Requerimientos Es el proceso de chequear que los requerimientos actualmente definen el sistema como el usuario realmente quiere. La validación de requerimientos es importante debido a que los errores en el Documento de Requerimientos pueden resultar bastante costosos una vez se ha comenzado el desarrollo o peor aún, cuando el sistema ya esté en servicio. Página 15

17 Durante el proceso de validación de requerimientos, se podrían utilizar varios tipos de chequeo, con el fin de validar los requerimientos encontrados en el Documento de Requerimientos: Chequeo de validez: El sistema tiene diversos Stakeholders, los cuales consideran qué funcionalidades debería tener el sistema. Chequeo de consistencia: En el Documento de Requerimientos, estos no deberían ser contradictorios con diferentes descripciones de las mismas funcionalidades del sistema. Chequeo de completitud: El Documento de Requerimientos debe incluir requerimientos que definan todas las funcionalidades Chequeo de realismo: Usando el conocimiento de tecnología existente, los requerimientos deben ser comprobados para asegurar que actualmente pueden ser implementados. Verificabilidad: Se deberían escribir un conjunto de pruebas para demostrar que el sistema reúne cada requerimiento específico. Gestión de Requerimientos Antes de comenzar, es necesario saber qué es lo que se debe hacer. Tenemos que saber el tipo de actividades que deben llevarse a cabo. Necesitamos saber si existen dependencias entre las actividades, por ejemplo, si una actividad puede comenzar sólo cuando otro se ha completado. Tenemos que saber lo que tipos de habilidades se requieren para llevar a cabo las actividades. Métodos ágiles Scrum Considerado como el método ágil más popular, Scrum es un framework iterativo e incremental para proyectos y productos o desarrollo de aplicaciones (Scrum, Inc., 2012) que se desarrolla en ciclos de trabajo llamados Sprints. Scrum no es un proceso o técnica para construir productos; en lugar de eso es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos (Schwaber & Sutherland, The Scrum guide, 2013). El marco de trabajo de Scrum consiste en el equipo Scrum, roles, eventos, artefactos y reglas asociadas, los cuales son mostrados como interacción en la Ilustración 3. Página 16

18 Ilustración 3. Scrum (Scrum, Inc., 2012) Scrum se encuentra basado en controles de procesos empíricos, de modo que se asegura que el conocimiento precede de la experiencia y se puedan tomar decisiones más acertadas. Existen tres pilares que soportan la implementación del proceso empírico, estos son (Schwaber & Sutherland, The Scrum guide, 2013): Transparencia, que implica que los aspectos significativos deben ser visibles para los responsables del resultado, lo que se logra por medio de la estandarización de dichos aspectos. Inspección constante y moderada de los artefactos de Scrum, de manera que sin interferir en el trabajo, se logren identificar variaciones en estos. Adaptación de procesos o artefactos de manera oportuna, de tal forma que no se presenten mayores desviaciones en el rumbo del proyecto. Scrum Team El equipo Scrum consta de 3 roles: Dueño del Producto (Product Owner): Es el único responsable (persona) de gestionar el Product Backlog, y sus decisiones deben ser respetadas por la organización. Esta gestión incluye (Schwaber & Sutherland, The Scrum guide, 2013): o Expresar claramente los elementos del Product Backlog. o Ordenar los elementos del Product Backlog para alcanzar los objetivos y misiones de la mejor manera posible. o o Optimizar el valor del trabajo desempeñado por El Equipo. Asegurar que el Product Backlog sea visible, transparente y claro para todos, y que muestre en lo que El Equipo trabajará a continuación. Página 17

19 o Asegurar que el equipo de desarrollo entiende los elementos del Product Backlog al nivel necesario. El Equipo (The Team): Los equipos son auto-gestionados, auto-organizados y multifuncionales, y son los responsables de encontrar la manera de convertir el Product Backlog en un incremento de funcionalidad al interior de cada iteración gestionando su propio trabajo a ser realizado. Los miembros del equipo son responsables del éxito de cada iteración y del proyecto en conjunto (Schwaber, Agile project management with Scrum, 2001). El tamaño óptimo de El Equipo debe estar entre 3 y 9 personas, que es un grupo lo suficientemente pequeño como para permanecer ágil, y lo suficientemente grande como para completar una cantidad de trabajo significativa. Scrum Master: No es el administrador del equipo ni del proyecto. El Scrum Master es el responsable de asegurar que Scrum se aplique y sea entendido de la manera adecuada y está al servicio del Scrum Team para garantizar que éste trabaje ajustado a la teoría, prácticas y reglas de Scrum. De igual forma ayuda a externos al Scrum Team a entender qué interacciones con el equipo pueden ser de ayuda y cuáles no, además de maximizar el valor creado por el Scrum Team por medio de modificaciones de dichas interacciones. (Schwaber & Sutherland, The Scrum guide, 2013). Eventos de Scrum En Scrum, todo el trabajo se realiza en Sprints (son el corazón de Scrum), los cuales contienen a todos los eventos de Scrum. Dichos eventos son bloques de tiempo, de manera que tienen una duración máxima. Una vez comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminarse una vez alcancen el objetivo del evento, asegurando que se emplee la cantidad de tiempo apropiada y sin desperdicio en el proceso. (Schwaber & Sutherland, The Scrum guide, 2013). Cada Sprint debe tener una duración de 2 a 4 semanas (no más, no menos); tiempo en el cual se crean incrementos en el producto. Estos incrementos implican un producto utilizable y potencialmente desplegable. No puede haber miembros de un mismo Equipo Scrum en Sprints simultáneos, por lo que cada iteración inicia con la finalización de la anterior. En un Sprint no se realizan cambios que afecten al Sprint Goal u Objetivo del Sprint, de manera que los objetivos de calidad no se disminuyen. El alcance puede ser clarificado y renegociado entre el Product Owner y El Equipo a medida que se obtiene nuevo conocimiento (Schwaber & Sutherland, The Scrum guide, 2013). Un Sprint podría ser cancelado únicamente por el Product Owner, y sólo si el Sprint Goal quedara obsoleto por cambios en el negocio, mercado o tecnología. Debido a la corta duración de las iteraciones, es raro cancelar Sprints, sin embargo si esto llegase a suceder, se entra a una etapa de evaluación por parte del Product Owner para determinar si hay trabajo potencialmente entregable, y se vuelven a estimar los elementos no terminados del Product Backlog. Una cancelación genera costos y traumas para el proyecto. (Schwaber & Sutherland, The Scrum guide, 2013). A continuación se enuncian y se da una breve explicación de los eventos en Scrum: Página 18

20 Objetivo del Sprint (Sprint Goal): Es propuesto durante el Sprint Planning Meeting, y corresponde a la meta establecida para el Sprint. Proporciona una guía al Equipo acerca del por qué se está realizando dicho incremento. Los eventos al interior de los Sprints que Scrum proporciona para la inspección y adaptación tanto de los procesos usados, como de los artefactos producidos, son los siguientes cuatro (Schwaber & Sutherland, The Scrum guide, 2013): Reunión de planificación del Sprint (Sprint Planning Meeting): Es la reunión inicial de cada Sprint, en la que se planifica el trabajo a realizar durante la iteración. Esta reunión es vigilada por el Scrum Master para asegurar que se haga de la manera adecuada y no debería durar más de 8 horas. Durante esta reunión se responden principalmente las siguientes preguntas: o Qué puede entregarse en el incremento resultante del Sprint que comienza? o Cómo se conseguirá hacer el trabajo necesario para entregar el incremento? Scrum diario (Daily Scrum): Reunión diaria de 15 minutos de duración en la que todos los miembros del Equipo deben estar presentes, con el fin de crear un plan para las siguientes 24 horas. Durante esta reunión se pretende que cada miembro del Equipo responda las siguientes preguntas: o Qué hice ayer que ayudó al Equipo a cumplir con el Sprint Goal? o Qué haré hoy para ayudar al Equipo a cumplir con el Sprint Goal? o Veo algún impedimento que evite que El Equipo o yo logremos el Sprint Goal? Revisión del Sprint (Sprint Review): Al terminar el Sprint, El Equipo dedica 4 horas o menos (dependiendo la duración del Sprint) para presentar al Product Owner lo realizado durante la iteración (Schwaber, Agile project management with Scrum, 2001), con el fin de actualizar el Product Backlog y definir los elementos para el siguiente Sprint. El Sprint Review corresponde a una reunión informal y no de seguimiento, en la que pueden además participar los interesados que colaboraron al Equipo. Adicional a la presentación ante el Product Owner, se busca fomentar la colaboración entre El Equipo. Al igual que en el Sprint Planning Meeting, es deber del Scrum Master asegurarse que la reunión se haga de la manera adecuada. Retrospectiva del Sprint (Sprint Retrospective): Reunión de duración no mayor a 3 horas (dependiendo la duración del Sprint), en la que se tiene como propósito: o Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas. o Identificar y ordenar los elementos más importantes que salieron bien, y las o posibles mejoras. Crear un plan para implementar las mejoras a la forma en que el equipo Scrum desempeña su trabajo. Las mejoras propuestas deben ser validadas junto al Scrum Master, garantizando que se implementen dentro del framework de Scrum. Artefactos Scrum (Schwaber & Sutherland, The Scrum guide, 2013) Página 19

21 Scrum define los siguientes artefactos con el fin de proporcionar transparencia y oportunidades para la inspección y adaptación: Product Backlog: Contiene una lista de los requerimientos (características) del sistema o producto a ser desarrollado por el proyecto, junto a una descripción, ordenación, estimación y valor para cada ítem. El Product Owner es el responsable del contenido y su priorización y disponibilidad. El Product Backlog es dinámico; la gestión cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil (Schwaber, Agile project management with Scrum, 2001). Un proceso continuo durante todo el proyecto, es el de refinamiento del Product Backlog, que consiste en añadir detalle, estimaciones y orden a los elementos de la lista en su interior. Durante este proceso son examinados y revisados los elementos de la lista. Este refinamiento es posible, gracias al avance logrado con el cumplimiento de los Sprint Goals. Sprint Backlog: Especifica el trabajo o lista de tareas que El Equipo define seleccionar del Product Backlog para un Sprint específico. En el Sprint Backlog se hace visible todo el trabajo que El Equipo considera como necesario para lograr el Sprint Goal. A medida que el trabajo se completa, se va actualizando la estimación del trabajo restante. XP (extreme Programming) (Kent & Cynthia, 2004) Metodología ágil de desarrollo propuesta formalmente por primera vez en (Beck, Extreme Programming Explained: Embrace Change, 2000), donde fue definida como un ligero, eficiente, de bajo riesgo, predecible, científico y divertido método para desarrollar software. Se diferencia según su autor Kent Beck por: Su anticipada, concreta, e inmediata reacción de ciclos internos. Su enfoque de planeación incremental, el cual rápidamente surge con un plan general que se espera, evolucione a través de la vida del proyecto. Su capacidad de programar con flexibilidad la implementación de la funcionalidad, en respuesta a las cambiantes necesidades del negocio. Su dependencia de pruebas automatizadas escritas por clientes y programadores para monitorear el progreso del desarrollo, permitiendo al sistema evolucionar y capturar los defectos tempranamente. Su dependencia de la comunicación oral, pruebas, y código fuente para comunicar la estructura y propósito del sistema. Su dependencia de un proceso de diseño evolutivo que dura lo que dura el sistema. Su dependencia de la estrecha colaboración de los programadores con conocimientos comunes. Su dependencia de las prácticas que funcionan tanto con los instintos de corto plazo de los programadores y los intereses a largo plazo del proyecto. Como se mencionó anteriormente, XP es considerado una metodología ágil para el desarrollo de software, por lo que suele ser complementario a Scrum (que es menos técnico y más enfocado hacia la gestión de proyectos) (Sommerville, 2010). Página 20

22 En la primera versión de XP, este era definido con 4 valores, 15 principios básicos y 20 prácticas, y se indicaba de manera muy estricta que para poder ser XP, se tenían que cumplir las 20 prácticas propuestas, sin embargo, desde su segunda edición, pasó a ser definido por medio de 5 valores, 14 principios, 13 prácticas primarias y 11 prácticas corolario. (Marchesi, 2013) Valores XP (Marchesi, 2013) Comunicación: Para evitar errores y problemas es necesario que los miembros del equipo se comuniquen de manera constante y adecuadamente. Simplicidad: Aunque requiere experiencia, y trabajo duro, es necesario hacer las cosas lo suficientemente simples como para no afectar la comunicación en el equipo y reducir la cantidad de código. Retroalimentación: Es un componente importante de comunicación, y fortalece a esta en cuanto se realice de manera apropiada. Esto contribuye a la simplicidad. Coraje: Valores como la comunicación, simplicidad y retroalimentación permitirán hacer frente con valentía, incluso a grandes cambios en requerimientos y refactorización sustancial del sistema. Respeto: Para lograr lo anterior, los miembros del equipo de desarrollo deben ser respetuosos con ellos y sus contribuciones. Ilustración 4. XP. (Contenido obtenido de Principios XP (Marchesi, 2013) Página 21

23 Humanidad: El software es desarrollado por personas, por lo que es necesario saber estimar los objetivos y necesidades de las personas, pero esto debe hacerse de manera que no se afecte la productividad. Económico: Si se produce software, este debería generar valor para el negocio. Dos aspectos económicos son claves para XP: el valor presente y el valor de las opciones. El primer aspecto sugiere que entre más temprano se desarrolle el software, va a ser más rentable para el negocio. El segundo indica que se pueden aplazar las inversiones en diseño hasta que sean obvias. Beneficio mutuo: Cualquier actividad debería beneficiar a todas las personas y a la organización, sin embargo esto es difícil de realizar debido a que por lo general las cosas que son beneficiosas para unos, no lo son para otros. Auto-semejanza: Se debe ser capaz de reutilizar soluciones similares en diferentes contextos. Mejora: La perfección no existe, sin embargo se debe luchar constantemente para alcanzarla, esto es por medio de iteraciones en el desarrollo que proporcionen funcionalidades y calidad por medio de la retroalimentación. Diversidad: Los equipos deberían incluir personas con diferentes conocimientos, cualidades y caracteres, ayudando proporcionar mayor cantidad de soluciones. Reflexión: Los equipos efectivos no deberían hacer el trabajo porque sí. Es necesario que se pregunten el cómo están trabajando, y el por qué lo están haciendo de esa manera. Flujo: Las prácticas de XP sugieren un continuo flujo de actividades y no una secuencia de diferentes fases que libere software hasta el final. Oportunidad: Los problemas deben ser vistos como oportunidades de mejora. Siempre se van a presentar inconvenientes y es allí donde se hace necesario aprender, y generar retroalimentación. Redundancia: Problemas críticos y dificultades deberían poder ser resueltos de diferentes maneras. Esto asegura que al tener muchas posibilidades, si alguna falla, otras podrían prevenir un desastre. Fracaso: No se debe relacionar con un aspecto negativo, siempre que se pueda aprender de ellos. Calidad: La calidad siempre debe ser máxima, y no se debe confundir con el perfeccionismo. Pequeños pasos: Es peligroso aplicar en un solo paso grandes cambios realizados en un largo periodo de tiempo. Por lo que se ve necesario proceder paso a paso y de manera iterativa, asegurando que no se produzcan daños por aplicar cambios en la dirección equivocada. Responsabilidad aceptada: La responsabilidad solo puede ser aceptada. Es fácil ordenar a los desarrolladores haga esto o haga aquello, pero esto no es trabajar. Prácticas XP (Marchesi, 2013) Existen dos grupos de prácticas, las primarias y las de corolario. Beck propone que estas prácticas deben aplicarse completamente para obtener los máximos beneficios de XP. Aun- Página 22

24 que no se proporciona una clasificación oficial por parte del autor, las prácticas se podrían clasificar de la siguiente manera (Marchesi, 2013): Prácticas primarias o Planeación y análisis de requerimientos Historias: Las funcionalidades del sistema son descritas usando historias, que son pequeñas descripciones visibles al cliente, de lo que puede hacer el sistema. Ciclo semanal: El desarrollo de software es realizado por semana. Al comienzo de cada semana se realiza una reunión donde las historias de desarrollo son seleccionadas por el cliente. Ciclo trimestral: En escalas de tiempo mayor, el desarrollo es planeado por trimestre. Esto incluye reflexiones del equipo, del proyecto y del progreso. Flojo: Evite hacer promesas que no pueda cumplir. Todo plan incluye tareas que podrán ser ignoradas. o Factores humanos y equipo Sentarse juntos: Para maximizar la comunicación, los equipos de desarrollo deberían trabajar en espacios abiertos, permitiendo alojar al equipo completo. Todo el equipo: El equipo debe estar compuesto por miembros que cumplan con todas las características y necesidades del proyecto. Espacio de trabajo informativo: El espacio de trabajo debería ser provisto con carteleras y otras cosas que proporcionen información del estado del proyecto y las tareas a ser realizadas. Trabajo energizado: Los desarrolladores deben ser productivos y estar atentos a su trabajo. Programación en pares: El código debe ser escrito por dos programadores en una misma máquina. o Diseño Diseño incremental: El diseño es indispensable para obtener buen código, y se sugiere que sea realizado de manera incremental durante la codificación. Programación de primero prueba : Antes de escribir el código, se hace necesario desarrollar las pruebas que lo verificarán. o Codificación de software y liberación Compilación de 10 minutos: El sistema debería ser compilado y todas las pruebas deberían ser finalizadas en 10 minutos, en orden de que se ejecute y se pueda obtener retroalimentación. Integración continua: Los desarrolladores deberían integrar cambios cada 2 horas. Prácticas de corolario o Planeación y análisis de requerimientos Participación real del cliente: Las personas que se vean afectadas por el sistema, deberían ser parte del equipo y pueden contribuir a la planificación semestral o trimestral. Página 23

25 o o o Despliegue incremental: Cuando se reemplacen los restos de un sistema, es necesario reemplazar primero algunas funcionalidades, y gradualmente todo el sistema. Contrato de alcance negociado: Los contratos para el desarrollo de software, deberían tener fijos tiempos, costos y calidad, pero el alcance del proyecto debería ser negociado durante su realización. Pago por uso: El cliente suele pagar por versión de software, esto crea un conflicto entre el proveedor y el cliente debido a que este último quiere grandes cambios en menos versiones, lo que está completamente por fuera de XP. Factores humanos y equipo Continuidad del equipo: Los equipos de desarrollo deberían ser los mismos para todos los proyectos. Contracción de equipos: Como el equipo se vuelve más capaz y productivo, es necesario mantener la carga, pero reducir gradualmente al equipo, enviando a los miembros libres a formar nuevos equipos. Diseño Análisis de origen de causa: Siempre que se encuentre un defecto, hay que eliminarlo junto a sus causas. Esto ayudará a que vuelva a aparecer Codificación de software y liberación Código y pruebas: Sólo el código y las pruebas son artefactos permanentes y deben ser preservados. Los otros documentos pueden ser generados con base a estos dos artefactos. Código compartido: Cualquiera en el equipo de desarrollo debe ser capaz de cambiar cualquier parte del sistema. Código base único: Esto es solo una versión oficial del sistema. Despliegue diario: Cada noche se debe poner software en producción. Es costoso tener brechas entre versiones de software lanzadas y las de producción personal de los desarrolladores SEMAT (Software Engineering Method and Theory) (Jacobson, Ng, McMahon, Spence, & Lidman, 2012) Es una iniciativa tomada por Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman que busca redefinir la Ingeniería de Software por medio de lo que los autores consideran como La esencia de la Ingeniería de Software: El núcleo de SEMAT. SEMAT apoya un proceso basado en una teoría sólida, principios probados y mejores prácticas que: Incluyan un núcleo (Kernel) de elementos ampliamente aceptados y que se puedan extender a usos específicos. Traten asuntos tecnológicos y humanos. Los apoyen la industria, la academia, los investigadores y los usuarios. Página 24