Especializacin de MoProSoft basada en el Mtodo gil Scrum (MPS-Scrum)Magdalena Dvila Muoz Posgrado en Ciencia e Ingeniera en Computacin, UNAM, Mxico magda_davilam@yahoo.com Dra. Hanna Oktaba Facultad de Ciencias, UNAM, Mxico ho@fciencias.unam.mx

ResumenEste artculo describe el proceso llamado MPSScrum resultado de la combinacin de MoProSoft [1] y Scrum[2]. El propsito de MPS-Scrum es acelerar el desarrollo de software incorporando prcticas giles de Scrum en procesos de desarrollo de software establecidos bajo MoProSoft. MPS-Scrum describe una serie de prcticas tomadas de Scrum con roles y productos de trabajo de MoProSoft. MoProSoft es un modelo mexicano que rene una serie de prcticas de gestin y de ingeniera para el desarrollo de software para guiar a las organizaciones en la mejora de sus procesos[1]. Por otra parte, Scrum es un marco de trabajo para el desarrollo de software enfocado a entregar un producto con el mximo valor posible para el rea de negocio[2].

1. Introduccin.El desarrollo de software actual demanda poner en funcionamiento procesos completos y flexibles que deriven como resultado productos de software que cumplan con la funcionalidad y calidad necesarias [3]. Adems, las diferentes reas de negocio requieren software que atienda sus necesidades inmediatas. Por lo tanto tambin se solicita rapidez en la entrega. Como una respuesta a todas estas exigencias existen una serie de modelos de procesos que conjuntan una serie de practicas que sirven como referencia para lograr calidad. MoProSoft es uno de estos modelos y surge de la iniciativa del gobierno mexicano para incrementar la capacidad de la industria de software, compuesta en su gran mayora de pequeas y medianas empresas.

El enfoque de MoProSoft como el de otros modelos es predictivo, tambin llamado dirigido por planes o tradicional. Esto consiste en intentar determinar los elementos del proceso como actividades, productos de trabajo, mecanismos de aseguramiento de la calidad y dems, para cada proyecto, con la finalidad de saber qu hacer en cada circunstancia. Por otro lado, en los ltimos aos ha surgido un movimiento llamado Alianza gil que propone otro tipo de prcticas para desarrollar software. Sus integrantes han declarado su enfoque en un Manifiesto gil [4] y en una serie de principios. Su atencin se centra en lograr la satisfaccin del cliente por medio de entregas continuas y frecuentes de productos valiosos para su rea de negocio. Ejemplos de modelos giles son Adpative Software Development[5], Crystal[6], eXtreme Programming[7] y Scrum[2]. Scrum es un proceso simple con pocas prcticas y productos, adems con reglas claras fciles de aprender. Este proceso no es prescriptivo, no describe qu hacer en cada circunstancia. En cambio, ofrece un grupo de prcticas para conocer lo que est sucediendo en el proyecto para implementar ajustes y as siga trabajando hacia las metas deseadas[2]. MPS-Scrum [8] es una propuesta que tiene el propsito de acelerar la produccin del software cumpliendo con las necesidades inmediatas de las diferentes reas de negocio. Esto se logra incorporando prcticas giles a procesos ya establecidos. Especficamente MPS-Scrum combina prcticas de Scrum con roles y productos de MoProSoft. Esto permite aprovechar el potencial de Scrum utilizando la experiencia en el uso de MoProSoft. Scrum ha sido utilizado en la industria del software en varios lugares del mundo [9], reconociendo su potencial para mantener un control continuo de los proyectos entregando un producto valioso para el cliente.

Por su parte MoProSoft es un modelo probado y utilizado en la industria mexicana de software. Constituye el ncleo de la Norma Mexicana Tecnologa de la informacin-Software-Modelos de Procesos y evaluacin para desarrollo y mantenimiento de software[10]. Esto permite que los procesos del modelo sean conocidos como parte de la adopcin de la norma. El propsito de este artculo es describir las prcticas de MPS-Scrum, las cuales tienen la finalidad de acelerar la entrega del software combinando Scrum y MoProSoft. En la seccin 2 y 3 se presentan MoProSoft y Scrum respectivamente. En la seccin 4 se describe MPS-Scrum y en la 5 los resultados del anlisis comparativo entre MoProSoft y MPS-Scrum. Finalmente, en la seccin 6 se presentan las conclusiones y el trabajo futuro.

2. MoProSoft.MoProSoft es un modelo de referencia para guiar a las compaas para establecer y mejorar sus procesos. Este modelo es considerado como base para los trabajos del grupo WG24 de la organizacin internacional para la estandarizacin: ISO/IEC consistentes en desarrollar una serie de perfiles que proporcionen una gua para cumplir con los estndares de esta organizacin [11]. Tambin MoProSoft es un componente importante del proyecto de Competisoft, en el cual participan universidades y empresas de Espaa y Latino Amrica. Uno de los objetivos de este proyecto es proporcionar un marco de trabajo metodolgico para mejorar y evaluar a pequeas organizaciones dedicadas al software[12]. MoProSoft considera nueve procesos distribuidos en tres categoras: Categora de Alta Direccin. Esta categora aborda las prcticas relacionadas con la gestin del negocio. Proporciona los lineamientos a los procesos de la Categora de Gerencia y se retroalimenta con la informacin generada por ellos[1]. Incluye un solo proceso: Gestin de Negocio. Categora de Gerencia. Esta categora aborda las prcticas de gestin de procesos, proyectos y recursos en funcin de los lineamientos establecidos en la Categora de Alta Direccin. Proporciona los elementos para el funcionamiento de los procesos de la Categora de Operacin, recibe y evala la informacin por stos y comunica los resultados a la Categora de Alta Direccin[1]. Incluye los siguientes procesos: Gestin de Procesos. Gestin de Proyectos.

Gestin de Recursos. Categora de Operacin. Categora de procesos que aborda las prcticas de los proyectos de desarrollo y mantenimiento de software. Esta categora realiza las actividades de acuerdo a los elementos proporcionados por la Categora de Gerencia y entrega a sta la informacin y productos generados [1]. Incluye dos procesos: Administracin de Proyectos Especficos. Desarrollo y Mantenimiento de Software. En el modelo se especifica el propsito, descripcin, roles, metas, artefactos, verificaciones, validaciones y secuencia de actividades de cada uno de los nueve procesos. En este artculo se hace referencia a los procesos de la Categora de Operacin: Administracin de Proyectos Especficos (APE) y Desarrollo y Mantenimiento de Software (DMS). En la Tabla 1 y Tabla 2 se muestra el propsito y una breve descripcin de sus actividades. Tabla1. Proceso APE de MoProSoft. APE El propsito de este proceso es realizar las actividades que conduzcan al cumplimiento de los objetivos del proyecto en tiempo y costo esperados. Actividades A1. Planificacin. Comprende una serie de subactividades que indican la planificacin de todos los aspectos de un proyecto y la preparacin del siguiente ciclo. A2. Realizacin. Consiste en un conjunto de subactividades para distribuir la informacin, para asignar responsabilidades y para registrar el avance del proyecto. A3. Evaluacin y Control. Abarca las sub-actividades para evaluar la ejecucin del proyecto de acuerdo a lo planeado, para dar seguimiento a los riesgos y para generar los reportes del proyecto. A4.Cierre. Incluye sub-actividades para formalizar el ciclo o cerrar el proyecto, para entregar los productos y para registrar las lecciones aprendidas. Tabla 2. Proceso DMS de MoProSoft. DMS El propsito de este proceso es la ejecucin de las actividades de anlisis, diseo, construccin, integracin y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. Actividades A1. Realizacin de la fase de Inicio. Contempla la revisin del Plan de Desarrollo con el Equipo de Trabajo para lograr un entendimiento comn y obtener su compromiso con el proyecto.

Tabla 2. Proceso DMS de MoProSoft (cont). Actividades A2. Realizacin de la fase de Requerimientos. Comprende todas las sub-actividades para especificar los requerimientos del producto de software, para planear las pruebas de sistema y la documentacin de usuario. A3. Realizacin de la fase de Anlisis y Diseo. Se compone de las sub-actividades para disear los componentes del producto de software y para planear las pruebas de integracin. A4. Realizacin de la fase de Construccin. Consiste en la serie de sub-actividades para la construccin de los componentes del producto de software y para la realizacin de las pruebas unitarias de los componentes. A5. Realizacin de la fase de Integracin y Pruebas. Contempla las sub-actividades para integrar los componentes del producto de software, para realizar las pruebas y para completar la documentacin de usuario. A6. Realizacin de la fase de Cierre. Comprende la elaboracin de la documentacin para el mantenimiento, para liberar el producto de software y para registrar las lecciones aprendidas.

completar la tarea. Esto ltimo se actualiza diariamente[2]. Increment of potentially shippable product functionality. Es el producto de software completo que cumple con todas las funcionalidades acordadas en todos los Sprints del proyecto. Este producto en cada Sprint debe contar con las caractersticas necesarias para funcionar en el ambiente operativo del cliente. [2] Burndown Chart. Es una grfica que muestra la tendencia del trabajo restante a lo largo del tiempo del Sprint [2].

3.2. Roles de Scrum.Product Owner. Es la persona responsable de la administracin del Product Backlog , permitiendo as maximizar el valor del proyecto. Prodcut Owner representa a los involucrados en el proyecto [2]. ScrumMaster. Es la persona responsable del proceso de Scrum, de su correcta implementacin y de aprovechar sus beneficios [2]. Team. Es un grupo interdisciplinario de personas responsables de auto-adminstrarse para desarrollar el producto de software en cada Sprint [2].

3.3. Flujo de Scrum.Un proyecto de Scrum comienza desarrollando la visin del sistema. Product Owner es responsable de encontrar el financiamiento del proyecto para hacer que se obtenga lo que indica la visin del sistema, de tal manera que se maximice el retorno de inversin (ROI). Product Owner formula un plan para hacerlo, as que incorpora un Product Backlog. El Product Backlog es una lista de requerimientos funcionales y no funcionales que cumplirn dicha visin, cuando se conviertan en un producto de software. Se prioriza el Product Backlog para que los requerimientos que generen ms valor sean los primeros en implementarse. Todo el trabajo se realiza en Sprints. Cada Sprint es una iteracin de 30 das del calendario consecutivos. Cada Sprint se inicia con la reunin de planificacin del Sprint: Sprint Planning Meeting. Product Owner presenta los requerimientos de ms alta prioridad. Team realiza preguntas acerca del contenido, propsito y significado del Product Backlog, adems selecciona los elementos del Product Backlog que se pueden convertir en funcionalidad para el prximo Sprint. Tambin Team elabora, actualiza o revisa los estimados para los requerimientos y confirma su exactitud tanto como sea posible. Durante la segunda parte Team planifica el Sprint. Debido a que Team es responsable de administrar su propio trabajo necesita un plan tentativo para comenzar el Sprint. Las tareas

3. Scrum.Scrum estructura el trabajo en ciclos llamados Sprints. Durante cada Sprint, el equipo selecciona requerimientos del cliente de una lista priorizada, as que los requerimientos que se desarrollan primero, son los de ms alto valor para el cliente. Al final de cada Sprint se entrega un producto con todas las caractersticas para funcionar en el ambiente operativo del cliente[9]. Existen casos documentados sobre la experiencia de las organizaciones que adoptan Scrum, por mencionar algunas: 3M [13] y Yahoo! Inc.[14]. Las siguientes secciones describen brevemente los productos, roles y flujo de las actividades de Scrum.

3.1. Productos de Scrum.Product Backlog. Es una lista priorizada de los requerimientos del proyecto junto con el tiempo estimado para convertirlos en un producto de software completo y funcional. La lista evoluciona y va cambiando de acuerdo a las condiciones del rea de negocio o de acuerdo a cambios tecnolgicos[2]. Sprint Backlog. Comprende una lista de tareas que Team define para el Sprint. Se agrega el responsable y la cantidad de trabajo restante para

que componen este plan se registran en el Sprint Backlog; conforme se desenvuelve el Sprint pueden surgir ms tareas que deben agregarse. Sprint Planning Meeting no puede durar ms de 8 horas. Cada da el equipo se rene durante 15 minutos, a esta reunin se le llama Daily Scrum Meeting. En sta cada miembro de Team responde tres preguntas: Qu has hecho desde la ltima reunin?, Qu planeas hacer hasta la prxima reunin? y Qu obstculos te estorban para cumplir tus compromisos?. El propsito de la reunin es sincronizar el trabajo diariamente, de todos los miembros de Team y agendar cualquier actividad de ayuda para continuar con el proyecto. Al final de cada Sprint, se lleva a cabo la reunin de revisin del Sprint: Sprint Review Meeting. En el primer segmento de mximo 4 horas Team presenta lo que se desarroll durante el Sprint al Product Owner y a cualquier involucrado. Es una reunin informal en la que se presenta la funcionalidad y se pretende que la gente aporte y ayude a determinar lo que Team realizar para el prximo Sprint. En el segundo segmento, ScrumMaster y Team sostienen una reunin de retrospectiva con respecto a la estructura del proceso Scrum. Esta parte de la reunin, que debe durar 3 horas como mximo [2]. La Figura 1 muestra el flujo de estas actividades.cada 24 horas

DMS que guardan cierta similitud con los sealados por Scrum. La especializacin MPS-Scrum considera la simplificacin del contenido de dichos productos de trabajo y la redefinicin de roles.

4.1. Contexto de aplicacin.El uso de esta especializacin es para organizaciones o equipos de trabajo que tienen establecido un proceso de administracin de proyecto dirigidos por planes en un marco de trabajo MoProSoft y desean evolucionar a procesos con prcticas giles, para obtener sus beneficios. Adems se requieren otras condiciones como que la colaboracin entre desarrolladores, gente del negocio y dems involucrados, el equipo de desarrolladores debe estar formado y debe contar con la capacitacin necesaria y la habilidad de autoorganizarse.

4.2. Roles de MPS-Scrum.MPS-Scrum toma los roles de APE y DMS similares con los de Scrum. El rol que se agreg es el de Involucrados. Los roles de MPS-Scrum se presentan a continuacin: RESPONSABLE DE ADMINISTRACIN DEL PROYECTO ESPECFICO (RAPE). Corresponde con el rol del mismo nombre de APE y con ScrumMaster de Scrum. Es responsable del proceso y de la ejecucin del proyecto. Debe conocer todas las prcticas de MPS-Scrum y contar con la habilidad de adaptarlas de acuerdo a las necesidades del proyecto.

Daily Scrum

SprintSprint Backlog

La nueva funcionalidad se demuestra al final del Sprint

Product Backlog seleccionado

Product Backlog: Requerimientos nuevos, priorizados Vision: ROI anticipada, liberaciones, milestones

CLIENTE O REPRESENTANTE DEL CLIENTE (REC). Corresponde con el rol Cliente de APE y con Product Owner de Scrum. Este rol representa los intereses del Cliente o del rea del negocio, debido a que conoce sus necesidades y oportunidades.EQUIPO DE TRABAJO (EQT). Corresponde al rol con el mismo nombre de APE y con Team de Scrum. Es un grupo pequeo, de hasta 10 personas, con personal capacitado y auto-organizado. INVOLUCRADOS (stakeholders) (IN). Es el grupo de personas que tienen algn inters en el producto de software que se desarrolla

Figura 1. Perspectiva general del proceso de Scrum [1].

4. MPS-Scrum.MPS-Scrum [8] consiste en una serie de prcticas desprendidas de Scrum que guan el trabajo que se lleva a cabo en un proyecto de desarrollo de un producto de software, sin necesidad de predecir todos los aspectos de la administracin de un proyecto y las circunstancias que puedan presentarse o no. MoProSoft es la base para su implantacin, por lo que hace uso de algunos roles y productos establecidos por APE y

4.3. Productos de MPS-Scrum.MPS-Scrum toma algunos productos de APE y DMS. Para ajustarlos a Scrum se redujo su contenido. Se presenta a continuacin una breve descripcin de cada uno de ellos: DESCRIPCIN DEL PROYECTO- VISIN DEL SISTEMA (DP-VISIN DEL SISTEMA). Corresponde a

Descripcin del Proyecto de APE y a la visin del sistema. Su contenido es una descripcin del enfoque o perspectiva del producto a desarrollar, debe sealar el por qu se est emprendiendo el proyecto. Puede estar en trminos del rea de negocio o en trminos del sistema. ESPECIFICACIN DE REQUERIMIENTOS. Corresponde con el producto con el mismo nombre de DMS y con Product Backlog de Scrum. Contiene una lista priorizada de los requerimientos funcionales y no funcionales que el producto de software a desarrollar debe cumplir, junto con los estimados de tiempo realizados por el EQT para convertir cada requerimiento en una funcionalidad del producto. PLAN DE DESARROLLO- LISTA DE TAREAS (PDLISTA DE TAREAS). Corresponde con el Plan de Desarrollo de APE y con Sprint Backlog de Scrum. Contiene una lista para convertir los requerimientos seleccionados en un producto de software funcional al final del presente ciclo. Tambin contiene los nombres de los responsables y el tiempo estimado restante para terminar cada una de las tareas. SOFTWARE (SW). Corresponde con el producto con el mismo nombre de DMS y con Increment of potentially shippable product functionality de Scrum. Es una versin incremental del producto de software que implementa los requerimientos comprometidos al inicio del ciclo. Este producto debe contar con las caractersticas necesarias para ejecutarse en el ambiente operativo requerido por el cliente o bien, con aquellas caractersticas que el cliente considere para ser entregable. GRFICA DE TRABAJO RESTANTE. Corresponde con Burndown Chart de Scrum. Es una grfica que muestra la correlacin entre la cantidad del trabajo pendiente (en tiempo) y cada uno de los das del ciclo. As se puede percibir la tendencia de la velocidad del EQT hacia el final del ciclo.

4.4. Prcticas de MPS-Scrum.La preparacin del proyecto y las reuniones alrededor de ciclos de desarrollo son las actividades que se indican en las prcticas de MPS-Scrum. stas son las que permiten la visibilidad del proyecto, la inspeccin y adaptacin. En la Figura 2 se muestra el flujo de las prcticas con los roles y productos involucrados. En la Tabla 3 se muestra una breve descripcin de cada una de ellas.

Tabla 3. Descripcin de prcticas de MPSScrum. PREPARACIN DEL PROYECTO El REC elabora la DP VISIN DEL SISTEMA de acuerdo al rea de negocio y elabora la primera versin de la ESPECIFICACIN DE REQUERIMIENTOS. Corresponde con el comienzo de in proyecto d eScrum. REUNIN DE PLANEACIN Se realiza al principio de cada ciclo. Su propsito es entender los requerimientos, estimar el tiempo para implementarlos, seleccionar los que se implementarn en el ciclo y planear las tareas necesarias. Se divide en dos partes: 1. El REC y el EQT revisan la DP-VISIN DEL SISTEMA. El REC explica los requerimientos con mayor prioridad de la ESPECIFICACIN DE REQUERIMIENTOS. El EQT estima el tiempo que se llevar en implementar cada uno de los requerimientos. Adems selecciona los que se pueden implementar en el ciclo, a estos requerimientos se les llama meta del ciclo. 2. El EQT genera PD-LISTA DE TAREAS para el presente ciclo. Si es necesario ajustar el tiempo estimado en la 1. Parte de la reunin el REC debe autorizar la modificacin de la ESPECIFICACIN DE REQUERIMIENTOS. El RAPE facilita el trabajo de EQT para generar las tareas del ciclo. Corresponde con Sprint Planning Meeting de Scrum. CICLO DE DESARROLLO Es el tiempo que transcurre entre la REUNIN DE PLANEACIN y la REUNIN DE REVISIN. En cada REUNIN DE REVISIN se acuerda la fecha de la siguiente, por lo que al final del ciclo todos conocen cuando se terminar el siguiente ciclo. El EQT ejecuta las tareas establecidas en el PD-LISTA DE TAREAS para el presente ciclo. La finalidad es implementar los requerimientos de la meta del ciclo en una nueva versin incremental del SOFTWARE. RAPE se encarga de proporcionar el apoyo para que el EQT cumpla con la meta del ciclo. Debe mantener la informacin del proyecto visible y disponible para todos los involucrados. Corresponde al Sprint de Scrum. Durante el CICLO DE DESARROLLO se deben ejecutar las siguientes actividades: REUNIN DIARIA El propsito de esta reunin es mantener la visibilidad del proyecto, a travs de la revisin del progreso de las actividades y de la exposicin de los obstculos encontrados por los integrantes del EQT. El RAPE dirige esta reunin y debe ser corta para no interferir con el esfuerzo del EQT. Corresponde a Daily Scrum Meeting de Scrum.

Tabla 3. Descripcin de prcticas de MPSScrum (cont.). ACTUALIZACIN DIARIA DE ESTIMADOS DEL TRABAJO RESTANTE Cada integrante del EQT debe actualizar el tiempo que hace falta para terminar cada tarea asignada (tiempo restante) en la PD-LISTA DE TAREAS. ACTUALIZACIN DE TAREAS El EQT puede agregar o quitar tareas de PD-LISTA DE TAREAS de acuerdo a las necesidades del proyecto. CONTROL DIARIO DE TAREAS El RAPE revisa las tareas terminadas, las que han comenzado, las que se han agregado y el estimado de tiempo restante para terminar cada una de ellas. Esto con la finalidad de conocer el avance de las tareas. Puede utilizar la GRFICA DE TRABAJO RESTANTE como herramienta para esta actividad. CONTENCIN DE FACTORES EXTERNOS El RAPE puede detectar factores externos que interfieran con el esfuerzo de desarrollo, por lo que puede emprender acciones que resuelvan estas situaciones con la finalidad de que el EQT no pierda la concentracin. REUNIN DE REVISIN Se realiza al final del ciclo y su propsito es presentar el SOFTWARE y revisar el proceso que se est llevando a cabo. Se divide en dos partes:

Tabla 3. Descripcin de prcticas de MPSScrum (cont.). REUNIN DE REVISIN 1. El EQT presenta los requerimientos dela meta del ciclo y el SOFTWARE desarrollado ejecutando sus funcionalidades. REC e IN expresan sus impresiones y observaciones, as como los cambios a las funcionalidades y nuevos requerimientos, todo de acuerdo a su experiencia y conocimiento. El REC actualiza la ESPECIFICACIN DE REQUERIMIENTOS para incluir todo lo mencionado en la reunin. El RAPE solo apoya en esta parte de la reunin. 2. El RAPE dirige esta parte de la reunin y gira en torno a dos preguntas qu estuvo bien en el anterior ciclo? Y qu se podra mejorar?. El EQT discute las mejoras, las prioriza y determina las acciones a realizar para el siguiente ciclo. Corresponde a Sprint Review Meeting en Scrum. Adems de estas prcticas existen actividades continuas que son responsabilidad de RAPE: SEGUIMIENTO A OBSTCULOS. El RAPE debe priorizar y hacer lo necesario para resolver todos los obstculos que el EQT reporte en la REUNIN DIARIA. ATENCIN A PROBLEMAS PERSONALES. El RAPE tambin, debe atender los posibles problemas personales o conflictos que puedan afectar el trabajo en equipo y por lo tanto, el producto de software a desarrollar.

PD-LISTA DE TAREAS

CICLO DE DESARROLLO EQT, RAPE

Sw

REUNIN DIARIA EQT, RAPE CONTROL DIARIO DE TAREAS CONTENCIN DE FACTORES EXTERNOSRAPE

PD-LISTA DE TAREAS

ACTUALIZACIN DIARIA DE ESTIMADOS DEL TRABAJO RESTANTE PD-LISTA DE ACTUALIZACIN DE TAREAS TAREAS E QT

PREPARACIN DEL PROYECTOREC

DP-VISIN DEL SISTEMA

DP-VISIN DEL SISTEMA

REUNIN DE PLANIFICACIN EQT, RAPE

ESPECIFICACIN DE REQUERIMIENTOS

ESPECIFICACIN DE REQUERIMIENTOS REC, EQT, RAPE

DP-VISIN DEL SISTEMA ESPECIFICACIN DE REQUERIMIENTOS PD-LISTA DE TAREASSEGUIMIENTO A OBSTCULOS

ESPECIFICACIN DE REQUERIMIENTOS Sw

REUNIN DE ESPECIFICACIN REVISIN DE REC, EQT, EQT, RAPE REQUERIMIENTOS RAPE, IN

ATENCIN A PROBLEMAS PERSONALES RAPE

NOMBRE DE PRCTICA (S) ENTRADA(S)ROL (ES) QUE EJECUTA (N) LA PRACTICA(S)

SALIDA(S)

Actividad Continua

Figura 2. Flujo de prcticas de MPS-Scrum[8]

5. Relacin de MoProSoft con MPS-ScrumLa relacin de MoProSoft con MPS-Scrum se especific considerando los productos, roles y actividades de APE y DMS[8]. Sin embargo, los

resultados ms representativos los tienen las actividades, por lo que en las siguientes secciones se presenta cmo se detall esta relacin.

5.1. Criterio de Equivalencia.Para determinar una relacin especfica entre las actividades de de APE y DMS con las prcticas de MPS-Scrum se estableci un criterio de equivalencia que contiene los siguientes valores: Completa (C). Al ejecutar la prctica de esta especializacin se cumple con la sub-actividad de APE o DMS. Parcial (P). Al ejecutar la prctica de esta especializacin: Solo se ejecuta alguna parte de la sub-actividad correspondiente a un nivel de capacidad o bien, No se considera algn elemento del producto de trabajo citado o no se cuenta con alguna caracterstica citada en la sub-actividad de APE o DMS. Implcita (I). Al ejecutar esta especializacin se cumple la sub-actividad de APE o DMS porque se encuentra indicada en el enfoque o en el contexto, o bien, se realiz al mismo tiempo que alguna prctica. Inexistente (Ine). MPS-Scrum no incluye alguna prctica referente a la sub-actividad de APE o DMS. Posible (Po). Esta especializacin proporciona una prctica que pude servir como base para la subactividad, por lo que el EQT, REC y/o RAPE pueden decidir incluirla o no como tarea en el PD-LISTA DE TAREAS, solo hay que considerar que se sigan cumpliendo con el enfoque de esta especializacin

Tabla 4. Resultados del anlisis cuantitativo de la relacin entre APE y MPS-Scrum. APE y MPS-ScrumPosible 31% Completa 29% Parcial 6% Inexistente 14% Implcita 20%

Completa +Parcial+ Implcita+ Posible: 86%

Tabla 5. Resultados anlisis cuantitativo de la relacin entre DMS y MPS-Scrum. DMS y MPS-ScrumPosible 6% Completa Parcial 2% 14% Implcita 13%

Inexistente 65%

Completa +Parcial+ Implcita+ Posible: 35%

5.3. Anlisis Cualitativo. 5.2. Anlisis Cuantitativo.Durante el anlisis cuantitativo se asign un valor del criterio de equivalencia a cada sub-actividad de las actividades de APE y DMS. Los resultados de este anlisis se presentan en las Tablas 4 y 5. Algunas conclusiones de este anlisis son: La mayora de las prcticas de MPS-Scrum son de Administracin de Proyectos que de actividades de ingeniera referentes al desarrollo de software. Esto de acuerdo a los resultados de la suma de las subactividades asignadas con los valores Completa + Parcial +Implcita + Posible. Las actividades A2. Realizacin de la fase de Requerimientos y A4. Realizacin de la fase de Construccin de DMS son las que tienen mayor relacin con MPS-Scrum (sus porcentajes son mayores que los de las dems actividades). Por lo que estas actividades constituyen el punto de vinculacin entre APE y DMS dentro de MPSScrum. Durante el anlisis cualitativo se identificaron aspectos importantes a considerar al adoptar MPSScrum con respecto APE y DMS. Los resultados se clasificaron como Fortalezas, Riesgos, Posibilidades y Debilidades. A continuacin se mencionan algunos resultados: Fortalezas. Son los beneficios que se obtienen al ejecutar las prcticas de MPS-Scrum. Algunas son: Reduccin en las actividades necesarias para organizar el trabajo. Simplificacin del contenido de los productos de trabajo. Facilidad de la inclusin de solicitudes de cambios en requerimientos. Riesgos. Son las situaciones identificadas que si se presentan durante la ejecucin de MPS-Scrum puede ser que no se obtengan los beneficios esperados. Algunos son: Fallas en el trabajo en equipo. Falta de autoridad de conocimiento o disposicin por parte del REPRESENTANTE DEL CLIENTE. Identificacin incorrecta de los involucrados. Posibilidades. Son los aspectos de la Administracin de Proyectos que son considerados en APE pero no en

MPS-Scrum. Sin embargo, alguna prctica de MPSScrum puede servir como base para abordar dichos aspectos. Algunos son: Planificacin de adquisiciones y capacitacin. Administracin de riesgos. Estimacin y registro de costos. La debilidad encontrada en este anlisis es que en MPS-Scrum no se considera alguna prctica para la participacin de subcontratistas.

de Ciencia y Tecnologa (CONACYT) , por Becas de Estudio de Posgrado de Alta Calidad del Programa de Mejoramiento del Profesorado (PROMEP) y por la Universidad Tecnolgica Emiliano Zapata del Estado de Morelos (UTEZ).

8. Referencias.[1]Oktaba, Hanna, et al.,MoProSoft: Process Model to Industry Software, Ministry of Economy, Mexico 2005. [2]Schwaber, Ken. Agile Project Management with Scrum, Microsoft Press, Redmond, Whashington, 2004. [3] Banco Nacional de Comercio Exterior S.N.C. Centro de Informacin ProMxico. http://www.bancomext.com.mx/ Bancomext/portal/portal.jsp?parent=8&category=2239&docu ment=6142. [4] Kent, Beck, et al. Manifesto for Agile Software Development. http://agilemanifesto.org/, 2001 [5]. Beck K.,Andres C. Extreme Programming Explained: Embrace Change. New Jersey, United States : Addison Wesley Professional, 2004. [6]. Highsmith, Jim. Adaptive software development: A collaborative approach to managing complex systems. New York United States : Dorset House Publishing, 2000. [7]. Cockburn, Alistar. Crystal Clear A Human-Powered Methodology for Small Teams. New Jersey, United States : Pearson Education, 2004. [8] Dvila, Muoz Magdalena. Desarrollo de una Especializacin de MoProSoft basada en el Mtodo gil Scrum. (Maestra en Ingeniera (Computacin); Mxico D.F: Universidad Nacional Autnoma de Mxico. 2008). [9] Scrum Alliance, Inc. What is Scrum?, http://www.scrumalliance.org/pages/what_is_scrum, 20032008 [10] Tecnologa de la informacin-Software-Modelo de procesos y evaluacin para desarrollo y mantenimiento de software, 2005, Mxico: Normalizacin y Certificacin Electrnica A.C (NYCE), NMX-I-059 [11] Laporte, C. Y., Renault A., Alexander S., The Application of International Software Engineering Standards in Very Small Enterprises (EN: Software Process Improvement for Small and Medium Enterprises, Techniques and Case Studies. Editado por: Hanna Oktaba, and Mario Piattini. Hershey New York. Information Science Reference 2008), pp.42-70 [12] Oktaba, H., Garcia, F., Piattini, M., Ruiz, F., Pino, F.J., Alquicira, C. Software Process Improvement: The Competisoft Project, Computer, IEEE Computer Society, October 2007, pp. 21-28. [13]Moore, R., Graham J., Hackerson B., Scrum at a Fortune 500 Manufacturing Company. AGILE 2007, IEEE Computer Society, 2007. [14]Benefield, Gabriel. Rolling out Agile at a large Enterprise, Proceedings of the 41st Hawaii international Conference on System Science, IEEE, 2008 .

6. Conclusiones y trabajo futuro.La propuesta que realiza MPS-Scrum articula prcticas que permiten agilizar el desarrollo de software con base en Scrum tomando los roles y productos de APE y DMS de MoProSoft. Esto con la finalidad de obtener las ventajas de las prcticas giles en el trabajo de equipos u organizaciones que siguen procesos de administracin de proyectos y de desarrollo de software establecidos mediante APE y DMS. Por un lado, Scrum se concentra en la administracin de un proyecto que entregue un producto de software valioso para el cliente. Por otra parte, APE y DMS definen claramente prcticas probadas y aceptadas en la industria. MPS-Scrum tiene la intencin de ayudar a los equipos u organizaciones que adopten prcticas que causen un efecto positivo en su productividad tomando ventaja de su experiencia, habilidades y capacitacin. Esto sin descuidar los objetivos de realizar proyectos que entreguen productos de software que satisfagan las necesidades del cliente en el tiempo y costo acordados. MPS-Scrum fue sometida a la revisin de un experto en la implantacin de prcticas giles en la industria y enterado de MoProSoft. La opinin de ste fue que las prcticas contenidas en MPS-Scrum son realizables. Debido a su experiencia en la industria mexicana de desarrollo de software confirm que MPS-Scrum tiene los elementos necesarios para llevar a cabo su implantacin en las empresas. El trabajo futuro para MPS-Scrum es someter a experimentacin la implantacin de sus prcticas en un equipo de trabajo u organizacin de desarrollo de software. Para esto se debe considerar las condiciones descritas en el contexto. Los resultados del experimento permitirn ajustar las prcticas contenidas en MPS-Scrum para cumplir con las necesidades de la industria.

7. Agradecimientos.Este trabajo ha sido apoyado por Programa de Becas de Estudio de Posgrado del Consejo Nacional