Pgina 1 Implementacin de CMMI utilizando una combinacin de mtodos giles Julio Ariel Hurtado Alegra 1 y Mara Cecilia Bastarrica

2 1 Departamento de Sistemas, Universidad del Cauca Calle 5 # 4-70, Popayn, Colombia ahurtado@unicauca.edu.co 2 Departamento de Ciencias de la Computacin, Universidad de Chile Blanco Encalada 2120 Santiago, Chile cecilia@dcc.uchile.cl Abstracto En este trabajo se explora la posibilidad de que las compaas de software de obtener una certificacin CMMI de sus procesos mediante la aplicacin de prcticas giles. Para este propsito, empezando por el nivel de madurez CMMI 2 metas genricas y las prcticas, se analiza la aplicabilidad de una serie de mtodos giles, identificando su contribucin individual o combinada en el cumplimiento de cada rea de proceso. El principal resultado de esta investigacin es la definicin de un "cumplimiento delta" requerida para una pequea o mediana tamao de la empresa para alcanzar el nivel 2 de CMMI utilizando mtodos giles. Se presenta un caso de aplicacin en la una pequea empresa aplica una combinacin de Scrum y XP para cumplir el requisito gestin de las reas. Comparamos el delta cumplimiento terico con los resultados de esta empresa. 1 Introduccin En la actualidad, la industria del software representa una importante actividad econmica para cada pas, sino que ofrece mltiples posibilidades para las empresas y que promete ser una gran oportunidad para el desarrollo de pases. En los pases latinoamericanos, la industria del software es generalmente inmaduros, y las empresas cara baja productividad que amenaza el crecimiento y aumenta la dependencia existente con respecto a los pases desarrollados. A pesar de las desventajas comparativas, el Latin American Software industria ha crecido ltimamente, por lo que la generacin de estrategias para el desarrollo de la zona permiten que el a los pases a aprovechar la oportunidad. Aseguramiento de calidad del software a travs de la mejora de procesos de software y la certificacin es uno de los

empresas de software estrategias podran participar con un gol dos veces: la primera es mejorar su imagen internacional, de modo que puedan participar en el mercado global, la segunda, la necesidad de hacer que sus proyectos sean ms eficientes y eficaces de las unidades administrativas. Una de las caractersticas de la industria latinoamericano de software es que est formada principalmente por las pequeas y medianas empresas. Varias de estas empresas han optado por aplicar los mtodos giles en su desarrollo software procesa bsicamente por la pequea inversin inicial requerida, y aprovechando su competitividad personal. No obstante, siempre que la mayora del software normas y modelos de desarrollo se han creado en base a rigurosos procesos tradicionales y metodologas, es necesario definir qu nuevas prcticas de estas empresas necesitan para llevar a cabo en 1 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 2 Para poder obtener una certificacin de uso de prcticas giles. Llamamos a este conjunto de nuevas prcticas de la "Cumplimiento delta". El proyecto SIMEP-SW est construyendo Agile SPI (Mejora de Procesos de Software gil), un marco trabajar por objeto apoyar la mejora de procesos para la industria del software en Colombia. Su objetivo principal es motivar a las pequeas y medianas empresas a mejorar y certificar su desaMent procesos. El marco incluye recomendaciones prcticas para la implementacin del proceso, en para facilitar su certificacin, as como una herramienta para la definicin del proceso. En este trabajo se han establece los requisitos para que una empresa alcance una certificacin CMMI utilizando prcticas giles. En el contexto del proyecto SIMEP-SW, una experiencia piloto se llev a cabo con el fin de validar los resultados tericos de esta investigacin. La gestin necesaria para la transformacin de una pequea rea Colombiano de desarrollo de software empresa Unisoft-se llev a cabo de acuerdo con las directrices sugerido por una combinacin de XP y Scrum. Los resultados se compararon con el terico "Cumplimiento delta". En la seccin 2 una lista de trabajos correspondientes se presentan. La seccin 3 describe los principales elementos de fondo, incluyendo una descripcin del proyecto SIMEP-SW, CMMI y algunos mtodos giles. En la seccin 4,

la posibilidad de implementar CMMI utilizando mtodos giles se indica. Los resultados tericos principales de este estudio se describen en la seccin 5. Un caso de aplicacin se presentan en la seccin 6. Finalmente, seccin 7 presenta las principales conclusiones y describe nuestro trabajo futuro. 2 Trabajos relacionados Ha habido otras iniciativas relacionadas con los mtodos giles con modelos de certificacin. Uno de los relacionada con el trabajo ms relevante es el de la migracin de los mtodos giles con las prcticas estandarizadas [18]. En este trabajo, tanto la perspectiva de la ingeniera y la del mundo gil tienen la misma importancia en el desarrollo de software. Para este fin, un marco destinado a aplicar valores giles y principios dentro de una organizacin en particular se ha desarrollado. En este contexto, es necesario utilizar consistentemente RUP como un proceso de desarrollo y CMM como modelo de referencia para la certificacin. En este trabajo, la creacin de instancias enfoque sugiere que la capacidad del proceso puede ser certificado en una definida nivel, incluyendo instancias de proceso explcito y configuracin. En [30] se presenta una experiencia en que una empresa se somete a un CMM nivel 2 y ISO9001 certificacin usando XP y Scrum. En esta experiencia, las contribuciones mtodos giles son comcombinada: XP fue utilizado para los procesos tcnicos y despus de un ao, Scrum se introdujo para apoyar aspectos organizativos y de gestin. Se obtuvo xito en un caso particular: la empresa alcanzado una certificacin en ambos modelos de calidad estndar. Este mtodo se llama Xp @ Scrum. Lo Tambin se aplic para hacer ms gil el proceso de desarrollo de "software Global", de MoTorola Argentina, una empresa ya est certificada como CMM nivel 5, despus de las dificultades en la adaptacin sealando su complejo proceso a proyectos que eran pequeos o cuyos requisitos eran inestables o vagamente definida. Con este trabajo se estableci que Xp @ Scrum no es incompatible con una mayor niveles de CMM bien [19]. Marcos Paulk evala XP desde una perspectiva CMM [23], y concluye que XP incluye muy buenas prcticas de ingeniera, aunque se debe tener cuidado porque algunos de ellos pueden ser polmica o incluso contradictorias. Mediante la evaluacin de XP desde una perspectiva CMM, expresa cmo ambas ideas se pueden combinar de forma adecuada y sinrgica con otras ideas y de gestin 2 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006

Pgina 3 prcticas. Mientras que XP ofrece una perspectiva de la programacin del sistema, CMM ofrece una organizacin perspectiva de mejora de procesos. La idea es que las empresas pueden tomar ventaja de cada uno de ellos mediante la adaptacin y adopcin de sus prcticas. En [20], un modelo de madurez para XP se propone para que una organizacin podra adoptar en las sucesivas etapas. Todas las prcticas propuestas por XP son difciles de implementar en un solo paso y es necesario que ser bien implementado con el fin de lograr todos los beneficios de XP reales. A pesar de todos estos trabajos son una valiosa evidencia emprica del proceso de certificacin, todos ellos son experiencias particulares, ya sea porque se presenta el caso de una organizacin en particular o que utilizan un mtodo especfico. En nuestro trabajo, antes de implementar procesos de mejora a travs de los mtodos giles, tomamos el enfoque de la evaluacin de cmo un conjunto de mtodos giles puede hacer que sea posible para lograr una certificacin CMMI utilizando sus prcticas. Adems, no hay mucha experiencia tratando de alcanzar CMMI con mtodos giles, slo CMM. 3 Antecedentes El objetivo del proyecto SIMEP-SW es proporcionar las herramientas necesarias para motivar software colombiano a las empresas a mejorar sus procesos de desarrollo con el fin de facilitar el posicionamiento y la comcompetitividad en los mercados nacionales, regionales e internacionales. El proyecto tiene la intencin de crear, aplicar y poner a prueba un sistema de mejora que integra elementos de calidad internacionalmente reconocida, modelos de evaluacin y mejora, junto con las caractersticas de la industria colombiana, y que con el tiempo podra ser replicado en otras industrias con caractersticas similares. Como parte de la estrategia, el proyecto tiene la intencin de establecer la aplicabilidad de las prcticas del mundo gil para implementar los requisitos de CMMI. 3,1 CMMI Actualmente hay varias calidad internacionalmente reconocidos y modelos de mejora y cumplen con los estndares dards. Entre ellos, CMMI e ISO puede ser comentado. El SEI ha desarrollado el pro-CMMI ceso modelo [27], su mtodo de evaluacin SCAMPI [28], y el mtodo de mejora asociado IDEAL [9]. La Organizacin Internacional de Normalizacin (ISO) ha desarrollado la ISO 15504 [11] promodelo de proceso que se basa en la norma ISO / IEC 12207 norma [14] y la modificacin de los [16], su

Evaluacin mtodo ISO 15504 (cuarta parte) [12], y su mtodo de mejora asociado ISO 15504 (Sptima parte) [13]. Tambin es importante tener en cuenta la familia de normas ISO 9001:2000 [15]. La modelos de mejora y calidad que son ms ampliamente aceptados por la industria a nivel mundial son la ISO 9001:2000 y CMMI. Este ltimo integra los modelos de calidad CMM e ISO / IEC 15504, tambin conocido como SPICE. CMMI modelos [27] se refieren al concepto de CMM, establecido por el Modelo de Madurez de la Capacidad para el software (SW-CMM) [24] en un nuevo nivel que promete el continuo crecimiento y expansin de el concepto CMM para mltiples disciplinas o cuerpos de conocimiento tales como SWCMM, IPD-CMM [26], y SA-CMM [5], entre otros. Modelos CMMI son herramientas para ayudar a las organizaciones a mejorar su desarrollo, adquisicin y mantenimiento de procesos y servicios. Las empresas pueden utilizar una CMMI modelo para ayudar a establecer sus objetivos de mejora, para mejorar los procesos de s mismos, y para proporcionar directrices para garantizar un proceso estable, capaz y maduro. Siempre que hay mltiples Modelos CMMI disponibles, una decisin debe ser tomada acerca de cul es el ms apropiado para 3 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 4 las necesidades particulares de la organizacin. Ya sea por etapas o representacin continua debe ser seleccionado, as como el cuerpo de conocimientos para ser incluido como parte del modelo. Cada modelo CMMI ha sido diseado para ser usado junto con otros modelos de CMMI, haciendo ms fcil para las organizaciones para mejorar las diferentes reas de una manera consistente. El conjunto de modelos CMMI contiene y se produce a partir de un marco que tiene la capacidad de generar mltiples modelos y la formacin asociada y material de evaluacin. Estos modelos muestran los rganos de contenidos de conocimiento, como la ingeniera de sistemas o ingeniera de software, en el combinaciones requeridas (CMMI-SE/SW/IPDDS/SS o CMMI-SE/SW). Las representaciones son formas de la presentacin de los componentes de CMMI, es decir, las mejores prcticas que promueve. Estas representaciones pueden ser

ya sea por etapas o continua. El CMMI representacin por etapas organiza reas de proceso en cinco niveles de madurez con el fin de apoyar y orientar la mejora de procesos. La agrupacin de las reas de proceso indica qu reas necesitan para ser implementado a fin de alcanzar el nivel de madurez determinado. Los niveles de madurez representar una trayectoria que ilustra la evolucin de la organizacin completa a lo largo de una obra de mejora de procesos. Para cada proceso rea, una lista de objetivos y prcticas especficas se define a partir de los objetivos generales y prcticas. La representacin por etapas utiliza cuatro caractersticas comunes para la organizacin de prcticas genricas: alto mancompromiso de gestin, las habilidades a desarrollar, orientacin implementacin y ejecucin verificacin. El nivel de madurez de una cierta organizacin nos permite predecir su comportamiento en dado algunos disciplinas. Cada nivel de madurez establece una parte importante de la organizacin proceso, y prepara a la organizacin para alcanzar el nivel de madurez siguiente. La representacin continua utiliza los niveles de capacidad para medir la mejora de los procesos alcanzados. Niveles de capacidad se aplica al proceso de organizacin de cada rea de proceso. Hay seis niveles de capacidad numeradas de 0 a 5. La representacin continua de CMMI tambin incluye la capacidad perfiles, nivel de objetivo y nivel equivalente como elementos de organizacin de los componentes del modelo. Agrupa a procesar reas de acuerdo a las categoras y niveles similares de capacidad diseados para el proceso de mejora dentro de cada rea de proceso. Perfiles de Capacidad representan trayectorias de mejora de procesos para ilustrar la evolucin de cada rea de proceso de mejora. El nivel equivalente se utiliza para relacionar reas de proceso de nivel de capacidad con los niveles de madurez en la representacin por etapas. 3.2 Los Mtodos giles Aparentemente opuesta a los procesos estandarizados, no hay actualmente otra tendencia formado por la llamada metodologas giles [6], que est motivado por una conciencia profunda de la crnica crisis del software, por la responsabilidad asignada a las metodologas tradicionales como la causa de esta crisis, y por el deseo de proponer soluciones. El trmino "gil" aplicado a la industria del software se creado en febrero de 2001, despus de una reunin en Utah, EE.UU., fueron la "Alianza gil" fue creado,

una organizacin dedicada a promover los conceptos de desarrollo gil de software y ayudar a las organizaciones en la adopcin de tales conceptos. El punto de partida fue un documento que resume la gil filosofa: el manifiesto gil [3], que incluye un conjunto de principios y valores que sustentan la la filosofa. Se describen algunas de estas metodologas. La programacin extrema (XP) es el mtodo creado por Kent Beck, Ron Jeffries y Ward Cunningham [2]. XP fue creado para los equipos de pequeas y medianas empresas de desarrollo de software que requierenmentos son vagos, cambiar rpidamente o son muy crticos. XP fue diseado teniendo en cuenta los problemas con las metodologas tradicionales de desarrollo con respecto a los plazos y la satisfaccin del cliente. La 4 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 5 objetivo principal de XP es lograr la satisfaccin de los clientes tratando de mantener su / su confianza en el producto. Recomendaciones XP estn orientados hacia la obtencin de software de alta calidad. Scrum ha sido aplicada por Jeff Sutherland y elaborada de manera ms formal por Ken Schwaber [25]. Poco despus, Sutherland y Schwaber unieron esfuerzos para perfeccionar y ampliar Scrum por aplicarIng. Industrial mtodos de control, junto con experiencias metodolgicas en Microsoft, Borland y Hewlett-Packard. Scrum no se concibe como un mtodo independiente, sino un complemento de otras mtodos como el XP o el Proceso Unificado (UP) [17]. Como mtodo, Scrum subraya gestin valores y prcticas, y que no incluye prcticas para las partes tcnicas (requisitos, diseo, ejecucin), por eso es aconsejable utilizarlo en combinacin con otro mtodo gil. Scrum es un proceso de gestin y control que implementa tcnicas de control de procesos. Agile modelado (AM) es un complemento a las metodologas giles para facilitar el modelado y eficaz documentacin de los sistemas basados en software. AM es un conjunto de prcticas guiado por principios y valores que deben aplicar los ingenieros de software. AM no define un procedimiento de modelado especfico en detalle, slo proporciona consejos para hacer que el modelado sea ms eficaz. AM se puede aplicar en los requisitos, arquitectura y modelado de diseo [1]. AM es una estrategia de modelado destinado a hacerse cargo de el hecho

que los mtodos giles no se preocupan por el modelado o la documentacin como productos de trabajo. El mtodo de Evo, creado por Tom Gilb, es el mtodo ms antiguo gil [8]. En 1976, trat Gilb con temas como el desarrollo iterativo y evolutivo de gestin, y ms tarde trat estos temas ms profundamente y public "El desarrollo evolutivo" en 1981 [7]. En los aos 90, continu Gilb desarrollo de Evo, que influy en otros mtodos, como XP, Scrum e incluso UP [17]. Este modelo est hecho de cinco elementos principales: objetivos, valores y costos, soluciones, estimacin de impacto, el plan evolutivo y funciones. Crystal es una familia de metodologas creadas por Alistair Cockburn [4]. Estas metodologas son basa en el hecho de que, la comparacin de la construccin de software con otro proceso de ingeniera hace nosotros pensamos acerca de software "especificaciones" y "modelos", de su integridad, exactitud y operacin. Cockburn piensa que esta pregunta no contributiva, porque despus de un tiempo se convierten en obsoleto e irrelevante. Existen cuatro variantes de las metodologas Crystal: Crystal Clear para hasta 8 personas, equipos Amarillas para equipos de 8 a 20 personas, Orange el 20 y el 50, y rojo para equipos de 50 a 100 personas. Se comprometi a continuar con marrn, azul y violeta. El ms exhaustivamente documentada es Crystal Clear (CC). CC se puede utilizar en proyectos pequeos con el medio crtica, aunque tambin se puede aplicar a proyectos crticos con algunas extensiones. Feature Driven Development (FDD) es un gil e iterativo y el mtodo adaptativo. Diferente de otros mtodos giles, no cubren todo el ciclo de vida del software completo, pero slo el diseo y fases de ejecucin. Se considera adecuada para los proyectos importantes de la misin crticos [22]. FDD Aplica un desarrollo iterativo con las mejores prcticas de probada eficacia en la industria parmetros. Hace hincapi en los aspectos de calidad e incluye pequeas entregables tangibles, junto con el control preciso del avance del proyecto. Adaptativa de desarrollo de software (ASD) se centra en el problema de desarrollar grandes y complejas sistemas. El mtodo utiliza un enfoque incremental e iterativo, con prototipos continua. Lo tiene la intencin de lograr "el rigor estrictamente necesario", y para ello se propone ejecutar el al menos control requerido [10]. Mtodo Dinmico Desarrollo de Sistemas (DSDM) es un marco para la aplicacin de desarrollo rpido

cin (RAD), que es muy popular en el Reino Unido [29], y que ha sido promovido como un estndar de facto para la 5 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Pgina 6 el desarrollo de soluciones de negocio con plazos estrictos. DSDM puede complementar otras metodologas tales como XP, UP, o una combinacin de ellos. 4 de CMMI reas de Prctica y Mtodos giles El proyecto SIMEP-SW tiene la intencin de establecer la posibilidad de alcanzar una certificacin CMMI por utilizando los mtodos giles, y la forma en que esto podra lograrse. Con este fin, tomamos el conceptual acercamiento entre ambos dominios: CMMI y los mtodos giles. Los esquemas conceptuales en las figuras 1 y 2 muestran los requisitos de un proceso debe cumplir para para lograr una certificacin. CMMI estructura est determinada por sus componentes, tanto para la escena y las representaciones continuas. Estos componentes son: reas de proceso, metas concretas y especficas prcticas, las prcticas genricas, productos tpicos de trabajo, Subprcticas, notas, ampliaciones disciplina, elaboraciones prcticas genricas y referencias. Figura 1: Tipos y relaciones de los componentes de CMMI (abstraccin del modelo CMMI) El componente principal del modelo es el rea de proceso, que consiste en un grupo de prcticas relacionadas que cuando se implementa junto cumplen una serie de objetivos relevantes para la mejora significativa de la zona. La Figura 2 muestra los tipos de componentes utilizando los elementos definidos en la Figura 1 como estereotipos, y describe grficamente las relaciones entre estos componentes dentro del modelo. CMMI comcomponentes definidos en un rea de proceso son: el componente deseado, componente esperado, e informativo componente. Figura 2: componentes CMMI 6 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 7 Requerido componente. Describe los requisitos, la organizacin debe alcanzar para satisfacer el rea de proceso. Este logro se debe visiblemente implementado en la organizacin proceso. Los componentes requeridos en CMMI son generales y objetivos especficos. La satisfaccin de estos objetivos

se utiliza durante las evaluaciones para comprobar si el rea de proceso ha alcanzado. Espera componente. Un conjunto de componentes esperados describe lo que una organizacin debe aplicar con el fin de lograr un componente requerido. Estas personas Gua de componentes encargados de evaluar o mejorar un proceso. Estos incluyen prcticas generales y especficos. Antes objetivos son considerar que se cumple estas prcticas o prcticas de implementacin alternativa debe ser descrito en el plan de trabajo y las aplicaciones. Componente informativo. Proporciona detalles que ayudan a las organizaciones a pensar en la forma de alcanzando requerido y esperado componentes. Algunos ejemplos de componentes informativos son: subprcticas, productos tpicos de trabajo, ampliaciones de disciplina, elaboraciones prcticas genricas, objetivo y ttulos y notas prcticas y referencias. Fue necesario desarrollar un modelo conceptual con el fin de especificar los elementos giles procesos basados en los elementos comunes en todos los mtodos. La Figura 3 muestra el modelo conceptual preliminar de la catlogo de elementos del proceso que estamos desarrollando, utilizando SPEM para la creacin de estereotipos [21]. Hemos utilizado SPEM porque es el idioma utilizado para el modelado de procesos en Agile SPI. Figura 3: Modelo conceptual preliminar para activos de los procesos giles Los diferentes mtodos de definir los valores, principios, procesos y otras caractersticas. AgileValue refiere a los valores y principios que definen la orientacin prctica del mtodo (por ejemplo, comu-continuas cacin), AgilePractice es una prctica gil recomendado por algn mtodo (por ejemplo, programacin par), AgileProcess es el proceso gil seguida de un mtodo gil (por ejemplo iterativo o incremental proceso en XP), AgileFeature es cualquier otra caracterstica que no puede ser expresado en trminos de la otra elementos (por ejemplo, el Plan Evolutivo elemento principal de Evo). Con el fin de establecer hasta qu punto los mtodos giles pueden contribuir a implementar CMMI, tomamos dos diferentes enfoques, en general una y un enfoque especfico sobre cmo gil activos de los procesos puede cumplir individualmente de forma conjunta los requisitos de CMMI. La Figura 4 muestra la relacin entre estos dos modelos y los dos enfoques. El enfoque general, representado por el crculo en la derecha, comenz a partir de la descripcin general de las reas de proceso, sus objetivos generales y su genrico prcticas en el contexto del rea de proceso respectivo. De esta manera, se obtuvo una idea inicial

acerca de cmo gil activos podran permitir a una organizacin alcanzar una certificacin CMMI, qu nivel de capacidad o madurez, y que los requisitos de estos activos giles no cubren. El segundo enfoque, 7 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 8 Figura 4: Implementacin relacin entre los requisitos de CMMI y activos de procesos giles representado por el crculo en el lado izquierdo, se consider el fin de obtener informacin ms detallada acerca el cumplimiento de las metas y prcticas especficas. De esta manera se limita ms precisamente, el trabajo que era necesario en cada rea para finalmente llegar el conjunto de los activos de los procesos que en su conjunto, y bajo la filosofa mundo gil, permitira para una empresa de tamao pequeo o medio para implementar CMMI aplicacin de un proceso gil. Este segundo enfoque fue aplicado en las reas en las que se encuentran ms necesidades en el primer enfoque. En este trabajo se muestran los resultados generales correspondientes a las reas de proceso en el perfil de 2 de la representacin continua, con el fin de evaluar la distancia en el rea especfica de CMMI Requisito de Gestin. Se parte de los objetivos generales de la medicin del nivel de capacidad de cada rea alcanzado o se alcance con un porcentaje entre 0% y 100%. De la misma manera que aparece los requisitos necesarios para alcanzar los niveles de capacidad 2 y 3 en las reas de proceso correspondiente a la madurez el nivel 2, y lo llamamos "cumplimiento delta". Niveles de capacidad de 4 y 5 no son relevantes porque no son relevantes para lograr una certificacin CMMI en cualquier representacin. Se consider el nivel 2 para esta primera aproximacin, y esperamos que para desarrollar el "cumplimiento delta" para el nivel 3 pronto, a condicin de que nuestro objetivo general es definir un conjunto de activos de proceso y los hacen disponible como una infraestructura para implementar las reas de proceso relacionadas con la gestin de procesos. Para cada rea de proceso relacionada con el nivel de madurez 2 se complet una tabla como la que se muestra en la Tabla 1. Se utiliz para medir la capacidad de cada rea de proceso mediante la asignacin de la contribucin de cada mtodo gil para la zona, y dedujimos un nivel de capacidad que podra ser alcanzado, el

porcentaje de cumplimiento que podra ser alcanzado, y el trabajo que se debe hacer para complementar 8 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Pgina 9 lo que falta. Si la combinacin de los elementos en los mtodos giles completamente puede implementar la zona, se supone que un proceso administrado se puede establecer dentro de la organizacin como base para esta zona. rea Requisitos de gestin del rea de proceso. ML-2 Propsito Administrar los requerimientos del producto y componentes de productos, e identificar inconsistencias entre los requisitos, planes de proyectos y productos de trabajo Los valores (V), principios (Pr), prcticas (P), artefactos (Arte), funciones (R) que favorecen la rea de aplicacin Mtodo Contribucin mtodo gil para el rea de proceso V1. La comunicacin continua, V2. Feedback, Pr2. La participacin del cliente, art. Usuario historios, R2. Cliente, R4. Tracker, R5. Trainer, P5. Pruebas, P9. La integracin continua XP Proporciona los elementos bsicos para la gestin de requisitos, pero no proporciona elementos de gestin en s. El cusTomer es un actor principal en la gestin de proyectos. Se considers la existencia de un entrenador de procesos. V3. Las reuniones diarias, art. Backlog, R2. Producto propietario, P1. Requisitos del producto, P5. Sprint requisito, P5 Daily scrum reunin Mel Proporciona dos elementos esenciales para alcanzar el requisito por el hombre tin: Backlog, que permite trazar un requisito, y un papel responsable para el seguimiento de ella, el dueo del producto. La reunin diaria promueve la mejora continua. Pr3. Pasos Evo proporcionar los requisitos especificados de manera evolutiva Evo Considera evolucin requisitos Art4. Secuencia Entrega, art10. Requisito archivo, R2. Usuario experto, R5. Informacin de la radiacin tor, P6. Prototipo proceso, P10. Revisin, P15.

Punto de vista del usuario. CC Proporciona dos artefactos importantes de gestin: los recin de archivos y los radiadores de la informacin. Puntos de vista del usuario son tambin relevantes. Proporciona capacitacin sobre el proceso general. F2.Construction de la lista de caractersticas, R6. Dominio experto, R7. Delivery Manager, P8. Progreso reportar FDD Proporciona una lista de caractersticas y un informe de avance del proyecto, tanto relacionado con los requisitos. Hay dos papeles que pueden desempear una parte importante en la gestin del requisito: el dominio experto y el gerente de la entrega. PR5. Tolerancia Cambio, R5. Cliente representante ASD Un representante de atencin al cliente est disponible para jugar el papel de requisito gerente y promover la tolerancia cambio F2. Estudio de negocios, R3. Usuario representante, R4. Visionario, P1. Compromiso del usuario, P6. Todos P7 cambios son reversibles,. Alto nivel de requisitos cin basal, P4. Entrega sujeta aceptacin a la adecuacin a los propsitos de negocio DSDM Se ve favorecida por teniendo al usuario como parte del equipo y con un compromiso de alto. Se promueve el cambio reversibilidad y recomienda un nivel basal de alta exigencia para facilitar evolucin. Conclusin El rea de Gestin de Requisitos es viable. Aunque ninguno de los mtodos giles define un proceso completo de requisitos cin de gestin, es posible la construccin de uno de los elementos presentes en la integracin de diferentes mtodos. El uso de un artefacto de base (Requisito lista, requisito, el historial del usuario, feature) es posible que una organizacin pequea puede definir un modelo para la rerequisito de gestin El nivel de capacidad accesible es CL-2 en el 75% y el CL 3-en un 50% Cumplimiento delta: GP 2.8 Proyecto de monitoreo y control. No hay elementos explcitos de seguimiento y control requisito gestin ambiente. GP 3.1 Establecer un proceso definido. Slo es posible definir, dentro de la organizacin que se aplica. GP 3.2 Recopilar informacin mejora. Aunque varios mtodos promover estrategias de comunicacin con el fin de imdemostrar el trabajo del proyecto, ninguno de ellos promueve elementos de hormign a utilizar esta informacin para mejorar la gestin de requisitos.

Tabla 1: contribucin general de los mtodos giles en el cumplimiento de la gestin de requisitos rea de proceso 5 Resultados Al aplicar el mismo enfoque a otras reas, que nos dieron la informacin de la Tabla 2. Aqu summamemorice los resultados de la primera aproximacin para cada rea de proceso en el nivel de madurez 2, exceptuando subcontrato 9 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 10 la gestin, ya que normalmente no es aplicable a las organizaciones pequeas. Por lo tanto, si asignamos un equiprest importancia a todas las reas de proceso, se puede calcular el porcentaje general requerida para alcanzar la madurez el nivel 2. Tambin se calcul el porcentaje general para alcanzar el nivel de madurez 3 y lo incluy en el final de la Tabla 2. rea Los mtodos con mayor Cumplimiento porcentaje contribucin (Nivel de capacidad Porcentaje +) Requisitos de gestin XP CL-2 en el 75%, CL-3 en 50% Medicin y anlisis XP, ASD, Scrum CL-2 en el 75%, CL-3 en 50% Planificacin del proyecto XP, Scrum CL-3 en 100% Seguimiento y control XP, Scrum CL-3 en 100% Subcontratar la gestin No aplicable Producto y el proceso de aseguramiento de la calidad FDD, Crystal, Evo CL-2 en el 75%, CL-3 en 50% Gestin de la configuracin ninguno CL-1 en 10% Cumplimiento porcentaje para el nivel de madurez 2

72% Cumplimiento porcentaje para el nivel de madurez 3 60% Tabla 2: Resumen del valor de la contribucin de los mtodos giles en el desempeo de las reas de proceso en la madurez nivel 2 Requisito CMMI rea de Gestin se puede implementar utilizando prcticas giles. Aunque ninguno de los mtodos analizados giles define un proceso completo de gestin requisito, todava es posible para construir uno usando una combinacin de elementos que se encuentran en diversos mtodos. El uso de un artefacto de base (por ejemplo, lista de requisitos, la historia del usuario, o la funcin), la organizacin puede definir una gestin de requisitos modelo basado en las prcticas de gestin en Scrum, o cualquier otro mtodo que podra considerar adecuada. El rea de proceso de Medicin y anlisis no est limitada por ningn mtodo particular, sin embargo, es posible ponerla en prctica como una combinacin de elementos de los diferentes mtodos. Dos interesantes estrategias a tener en cuenta son las cajas de ASD tiempo y la medicin de velocidad se define en el proyecto XP. Cualquiera de estas estrategias pueden apoyar la calidad y la medicin de la productividad. Prcticas de Scrum puede ser tambin de gran valor. El rea de planificacin del proyecto est cubierto por casi todos los mtodos giles, la diferencia es que la planificacin se aplica a iteraciones cortas y no es un documento requerido. La planificacin es la base para el trabajo, pero planes pueden cambiar, el objetivo es desarrollar un producto que satisface al cliente. Los planes se ajustan a lo largo del proyecto, el riesgo es tomado en cuenta por priorizar actividades y los participantes estn involucrados en estas actividades. Monitoreo y control se ejerce en el marco de los mtodos giles, pero no de una manera muy organizada As, con la excepcin de algunos como XP donde hay algo ms formal y Scrum donde gestin es la fuerza ms relevante. Por tanto, es posible implementar esta rea con la contribucin de estos mtodos. Garanta de Producto y Proceso de Calidad es un rea dbil en todos los mtodos giles porque no es muy claramente presentado. FDD incluye una estructura bsica que va ms all de las pruebas. Crystal Clear ofertas una alternativa para sincronizar el proceso en el tiempo, y Evo tiene un enfoque en el producto y el proceso se mejoran como parte inherente del proyecto de desarrollo. A condicin de que Scrum es

el ms fuerte en la gestin, sus prcticas se puede aplicar en un proceso de aseguramiento de la calidad. Gestin de la Configuracin es el rea ms dbil, ya que no llega ni al nivel de capacidad 1 utilizando tcnicas de los mtodos giles. Algunos mtodos, como XP o Crystal, proponer un tcnico medio ambiente se centraron principalmente en la gestin de cdigo de configuracin. Es posible extender estos 10 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 11 tcnicas para manejar otros elementos de configuracin y el uso de herramientas para apoyar algunas de la rutina tareas. AM favorece el uso de artefactos intermedios que pueden ser considerados como elementos de configuracin para el proceso. El delta del cumplimiento necesario para alcanzar la madurez CMMI nivel 2 est dada por las prcticas y otros elementos giles para apoyar la gestin de la configuracin de elementos que no sean de cdigo, y-en el existencia de prcticas u otros elementos giles para apoyar la vigilancia y control, aseguramiento de calidad, gestin de requisitos, y la medicin y el anlisis. El delta del cumplimiento necesario para alcanzar la madurez CMMI nivel 3 se debe completar con los otras reas de proceso de nivel 3. Estas reas son el establecimiento de un proceso definido, y el recopilacin de informacin mejora en las reas de gestin de requisitos, la medicin y anlisis, control de calidad y gestin de la configuracin. Un resumen de los niveles alcanzables de capacidad se muestra en la Figura 5. Figura 5: Capacidad nivel alcanzado en cada rea de prctica 6 Estudio de caso: Gestin de Requisitos con XP + Scrum Utilizando los conocimientos obtenidos en esta investigacin, se procedi a aplicarlo en un caso del mundo real con el fin de corroborar la consistencia del delta cumplimiento encontrados. Unisoft Ltda. es una pequea empresa formada por 9 personas. Sus procesos no responde a ninguno de CMMI reas de proceso. Su primer proyecto de mejora de procesos es elegido para estar en el rea de requisito de manejo ya que se considera que es uno de los ms crticos para la organizacin, lo tiene de la ms alta prioridad de su gestin, y fue inicialmente slo se cumpli en un 32%. El proceso aplicado es el siguiente: 1. el proceso de gestin requisito fue diseado en Unisoft como una disciplina que permita que alcancen los requisitos de CMMI utilizando mtodos giles basadas en las conclusiones tericas

se explica en la Seccin 5. Slo en las prcticas de Scrum y XP se aplicaron; 2. un mini-evaluacin se hizo, correspondiente a la zona necesaria para la transformacin y la gestin de acuerdo con el modelo CMMI. El delta del cumplimiento concreto se determin empricamente; 11 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 12 3. el delta del cumplimiento medido para la gestin de requisitos, se analiz y se compar con el definido tericamente. La compaa no tiene una forma definida de ingeniera ni tampoco los requisitos de gestin. Requisito proceso de gestin en Unisoft se defini bsicamente usando XP, con la contribucin de algunas prcticas de Scrum, que es ms fuerte en temas de gestin. Los activos de los procesos giles teoTericamente identificados se consideraron: el ciclo de vida definido por Scrum se utiliza para requisitos as como la lista de elicitacin requisito; tanto se describe en forma similar a como la empresa era acostumbrados. Historias de usuario son el camino XP requerimientos del cliente captura, guas de planificacin, el diseo, las pruebas, la integracin y el desarrollo general del proyecto. Las historias de usuario de XP se introdujeron en Unisoft como una forma de elicitacin requisito. Un conjunto de historias de usuario se desarrolla en una iteracin XP, y se puede verse afectada por el trabajo en iteraciones posteriores. Historias de usuario han sido adoptados por Unisoft como una base para la planificacin y diseo de la prueba, por lo que la verificacin y validacin del sistema tambin se consigue ms fcilmente. Para la gestin de esta informacin, XP hace que el usuario participa como parte del desarrollo equipo, sin embargo, es necesario controlar el proceso de gestin mediante la asignacin de una persona responsable y algunos recursos (la persona a cargo puede ser incluso el cliente, si l / ella tiene las habilidades). El lder del proyecto se defini como el dueo del producto (segn se prescribe en Scrum), tuvo a su cargo de las prcticas de ingeniera de gestin y administracin requisito (planes y ejecucin), de la gestin de cambios y de evaluar continuamente el estado de la ejecucin en comparacin con los planes y recursos. Defini las prcticas (basado en el requisito de Scrum Sprint), cambios gestionados (segn

gestin estrechamente relacionadas con los valores y principios en el Manifiesto Agile) las polticas, y l estaba en cargo de aceptar, rechazar y documentar la historia de estos cambios. Asociado con el proceso de requisito, un proceso de gestin de la luz requisito era demultado, incluyendo un proceso de seguimiento para el requisito de diferentes partes del ciclo de vida del software y un proceso de gestin para el proceso tcnico de ingeniera de requisitos (obtencin, anlisis, documentacin y validacin). Esta configuracin se ajustaba a la empresa. 6.1 Caso de Anlisis En el anlisis terico, las reas se dividieron de acuerdo con el modelo CMMI pero, en la caso de aplicacin, las reas no fueron abordados separadamente. En particular, la aplicacin de la rea de gestin requisito necesario otras reas a desarrollar, as: (1) Solucin tcnica: a condicin de que la gestin requisito est presente a lo largo del desarrollo de software y todo lo particularmente gestiona las actividades de ingeniera de requisitos, (2) la garanta de la calidad: la hora de definir y gestin de las actividades relacionadas con la validacin requisito, (3) gestin de la configuracin: se suministra que los requisitos son tambin elementos de configuracin. A pesar de que el anlisis aplicado no inclua la solucin tcnica, parte de ella tuvo que ser ejecutado de acuerdo con Scrum Recomendaciones de mantenimiento el escenario de la contribucin mtodos exclusivo gil. Las reas de la planificacin y el seguimiento y control tuvieron una mejor evaluacin inicial, alcanzando un 82% y 66%, respectivamente. As, cuando la administracin requisito fue incorporado en el experimento piloto, en la prctica estas reas mejorado la evaluacin final (84%), ya que haba un control de la totalidad proceso de gestin de requisitos. Estos resultados empricos son mejor que la que tericamente 12 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Pgina 13 encontrado (75%). Podemos entonces concluir que el logro de estas otras dos reas ayudado bajar el cumplimiento delta en la gestin de requisitos (y probablemente tambin en otras reas). En nuestro caso de estudio, esta diferencia podra haber sido mayor si estas reas no haban sido tan bien evaluado, y podra haber sido peor si el rea de solucin tcnica no haba trabajado tan duro. Esta sugiere que el anlisis original debe ser complementado por as incluir las correlaciones entre las reas

y de esta manera el cumplimiento delta podra ser inferior. As que el delta cumplimiento declarado que encontramos tericamente en este artculo puede ser considerado como el delta cumplimiento parcial mxima requerida para un conjunto de activos de los procesos giles para implementar CMMI. Teniendo en cuenta que la gestin de configuracin es fuerte a nivel de cdigo, que parte de ella se lleva a cabo con la gestin de requisitos (A condicin de que los requisitos son los elementos de configuracin), y que hay otro desarrollo pocos artefactos cuando se utilizan mtodos giles, gestin de configuracin no sera un problema ms, por lo que es posible alcanzar en la prctica un delta cumplimiento entre 5% y 10%. 7 Conclusiones Es importante darse cuenta de que es posible alcanzar el nivel de madurez 2, utilizando los mtodos giles si el resuelven los siguientes problemas: Cada rea de proceso debe ser explcitamente definido dentro de la organizacin. Los mtodos giles proporcionar casi todos los elementos necesarios para este fin. Las reas de proceso, tales como la gestin de requisitos, la medicin y el anlisis, control de calidad y gestin de la configuracin debe ser complementado con elementos obtenidos de otras fuentes, a fin de lograr un cumplimiento delta 0. En este trabajo se ha encontrado que es posible para las pequeas organizaciones de desarrollo de software a lograr una certificacin CMMI aplicacin de mtodos giles. Hemos definido el delta del cumplimiento y probado en la prctica en una pequea organizacin colombiana de desarrollo de software. Las reas ms dbiles del proceso en los mtodos giles se encontraron gestin de requisitos, medir surement y el anlisis, y la garanta de calidad del producto y de proceso. Con respecto a la configuracin la gestin, el esfuerzo debe ser an ms difcil porque los mtodos giles cubren slo una pequea parte de este rea. Asimismo, la conclusin de la necesidad de contar con un conjunto de activos de los procesos que permiten a las organizaciones definir y crear instancias de un proceso a travs de los elementos de los mtodos giles. Por lo tanto necesitamos un catlogo activo proceso que incluye tcnicas, prcticas, elementos de proceso (roles, disciplinas, fases, ciclos de vida, etc) que hacen posible la implementacin de los requisitos de una manera prctica. Todos los procesos deben tener los siguientes elementos bsicos: una poltica clara, que se obtiene a partir de los valores y principios de los mtodos giles;

 Flujos de trabajo de aplicacin en detalle cada parte del ciclo de vida: artefactos, actividades y roles, obtenido a partir artefactos, prcticas y roles definidos por los mtodos giles. Cada proceso es particular y nico, ya que depende de los objetivos y la estructura de la organizacin donde se aplica. Por lo tanto, es importante para definir un catlogo de activos de los procesos en 13 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Pgina 14 una manera estructurada y organizada, y proporcionar una serie de pautas de aplicacin, por lo que un pequeo organizacin puede adoptar y adaptar a ser capaces de llegar a una certificacin CMMI. En el corto futuro, planeamos construir esta estructura del catlogo y llenarla con algunos activos ejemplo de proceso. En un futuro no muy cercano, tenemos la intencin de llenar por completo el catlogo y lo utilizan en el mbito acadmico, as como entornos industriales. A continuacin, ser capaz de medir su eficacia para mejorar el software procesos de desarrollo en consonancia con SIMEP-SW objetivos. Agradecimientos Este trabajo ha sido desarrollado como parte del proyecto SIMEP-SW - Desarrollo de Software en Colombia Proceso de Mejoramiento del Sistema, financiado por la Universidad del Cauca, Colciencias, y Ltda SITIS. bajo contrato 421 de 2003 Colciencias-UniCauca. Referencias [1] Scott Ambler Agile Modeling:. Prcticas efectivas para eXtreme Programming y el Proceso Unificado. Wiley Computer Publishing, 2002. . [2] Kent Beck Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. [3] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Cunningham Ward, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Kern Jon, Marick Brian, Robert C. Martin, Steve Mellor, Schwaber Ken Sutherland Jeff y Dave Thomas. Manifiesto para Agile Software Desarrollo, febrero de 2001. http://agilemanifesto.org. [4] Alistair Cockburn. Agile Software Development. Adisson-Wesley, 2002. [5] J. Cooper y M. Fisher. Adquisicin de Software Capability Maturity Model. Informe Tcnico CMU/SEI2002-TR-010, Software Engineering Institute, 2002. [6] Martin Fowler. La nueva metodologa., Abril de 2003. http://www.martinfowler.com/articles/-

newMethodology.html. [7] Tom Gilb. Desarrollo evolutivo. SIGSOFT ACM Software Engineering Notes, 6 (2) :1717, abril 1981. [8] Tom Gilb. Principios de la Gestin de Ingeniera de Software. Addison-Wesley, 1988. [9] Jennifer Gremba y Myers Chuck. El IDEAL SM Modelo: Una gua prctica para la mejora Bridge,. (3) :19-23, 1997. [10] Jim Highsmith desarrollo de software adaptable:. Un enfoque colaborativo para Gestin Complex Sistemas. Dorset House, 2000. [11] ISO. Software Proceso de Evaluacin - Parte 2: Un modelo de referencia para los procesos y la capacidad de proceso. Informe Tcnico ISO / IEC 15504 TR2: 1998, la Organizacin Internacional de Normalizacin, 1998. [12] ISO. Software Proceso de Evaluacin - Parte 4: Gua para la realizacin de la evaluacin. Informe Tcnico ISO / IEC TR2 15504: 1998, la Organizacin Internacional de Normalizacin, 1998. [13] ISO. Software de Evaluacin de Procesos - Parte 7: Gua para la mejora de procesos. Informe Tcnico ISO / IEC 15504 TR2: 1998, la Organizacin Internacional de Normalizacin, 1998. [14] ISO. Tecnologia de la Informacion Proceso de Ciclo de Vida del Software. Informe Tcnico ISO / IEC 12207 - UNE 71044, la Asociacin Espa ~ nola de Normalizacin y Certificacin, 1999. 14 CLEI Electronic Journal, volumen 9, nmero 1, PAPEL 7, JUNIO 2006 Page 15 [15] ISO. Sistemas de gestin de la calidad. Informe Tcnico ISO 9000:2000, Organizacin Internacional para las Normalizacin, 2000. [16] ISO. Tecnologa de la Informacin - Ciclo de vida del software Procesos Enmienda 1. Informe Tcnico ISO / IEC 12207 ENMIENDA 1, la Organizacin Internacional de Normalizacin, 2002. [17] Ivar Jacobson, Grady Booch, Rumbaugh y James. Proceso Unificado de Desarrollo de Software. Addison-Wesley, 1999. [18] Mark Lycett, Robert D. Macredie, Patel Chaitali, y Ray J. Paul. Migracin de mtodos giles para Desarrollo de la Prctica normalizada. IEEE Computer, 36 (6): 79-85, junio de 2003. [19] Patrcio Maller, Claudio Ochoa y Silva Josep. Agilizando el Proceso de Produccion de Software en sin Entorno de CMM Nivel 5. Revistas del IEEE Amrica Latina, 3 (1), marzo de 2005. Edicin Especial JISBD'2004. IX Jornadas de Ingeniera del Software y Bases de Datos.

[20] R. Jerzy Nawrocki, Bartosz Walter, y Wojciechowski Adn. Hacia el Modelo de Madurez de eXtreme Proprogramacin. En 27a Conferencia Euromicro 2001: Una odisea del Net, pginas 233-239, Varsovia, Polonia, Septiembre de 2001. IEEE Computer Society. [21] OMG. SPEM, Procesos de Ingeniera de Software Especificacin metamodelo. Versin 1.0. Informe Tcnico 02.11.14, Object Management Group, 2002. [22] Stephen R. Palmer y John M. Felsing. A Practical Guide to Feature-Driven Development. Aprendiz Hall, 2002. [23] Mark C. Paulk. Programacin Extrema perspectiva de un CMM Software. IEEE, 18 (6) :19-26, diciembre de 2001. [24] Mark C. Paulk, Bill Curtis, Mary Beth CHRISSIS y Weber Charles. Capability Maturity Model. Informe Tcnico CMU/SEI-93-TR-24, Nmero DTIC ADA263403, Software Engineering Institute, 2003. [25] Ken Schwaber. El proceso de desarrollo Scrum. En OOPSLA '95 Taller de Diseo Business Object e implementacin, Austin, Texas, EE.UU., octubre de 1995. ACM Press. [26] SEI. IPD-CMM - Desarrollo de Productos Integrada. Informe Tcnico CMU/SEI-MM97-001, Software Engineering Institute, 1997. [27] SEI. CMMI de Ingeniera de Sistemas, Ingeniera de Software, Productos Integrada y Proceso de Desarrollo, y el Proveedor Sourcing (CMMI-SE/SW/IPPD/SS, V1.1) representacin por etapas. Tcnico Informe CMU/SEI-2002-TR-012 ESC-TR-2002-012, Software Engineering Institute, 2002. [28] SEI. CMMISM mtodo estndar de evaluacin para la mejora de procesos (SCAMPISM), Versin 1.1: Mtodo de Definicin de documento. Informe Tcnico CMU/SEI-2001-HB-001, Ingeniera de Software en la Instituto, 2002. [29] Jennifer Stapleton mtodo dinmico de Desarrollo de Sistemas -. El mtodo en la prctica. Addison-Wesley, 1997. [30] Vriens Cristo. Certificacin CMM Nivel 2 para ISO9001 y con XP @ Scrum. En Actas del Agile Desarrollo de las Telecomunicaciones (ADC'03), pginas 120-124, Salt Lake City, Utah, EE.UU., 2003. IEEE Computer