Gestin de Proyectos de Desarrollo de Software Libre con un Enfoque de Calidad

Laboratorio de Investigacin en Sistemas de Informacin (LISI), Departamento de Procesos y Sistemas, Universidad Simn Bolvar, Apartado 89000, Baruta, Caracas 1080-A, Venezuela. {kdoming, movalles, lmendoza}@usb.ve Carrera Ingeniera de Sistemas, Universidad Nacional Experimental de las Fuerzas Armadas, Chacao, Caracas 1064, Venezuela. {cdmarrero2040, kiberleys }@hotmail.com

Kenyer Domnguez, Mara Prez, Luis E. Mendoza

Kiberley Santos , Carlos D. Marrero

Oficina de Apoyo Tcnico al Estado (OATE) Centro Nacional de Tecnologas de Informacin Ministerio de del Poder Popular para las Telecomunicaciones y la Informatca Av. Universidad, esquina El Chorro, torre Ministerial, piso 11, Caracas, Venezuela hrivero@cnti.gob.ve

Henry Rivero ,

Resumen
Desarrollar software es una tarea riesgosa y difcil de controlar, sobre todo cuando se trabaja con grandes equipos de personas; por ello es necesario tener una metodologa con el fin de gestionar bajo un enfoque disciplinado y sistemtico este tipo de proyectos para poder obtener resultados satisfactorios tanto en tiempo como en costos. El Gobierno venezolano promulg a finales de 2004 el decreto presidencial 3.390. Este decreto establece el uso prioritario de Software Libre (SL), basado en estndares abiertos en los servicios y sistemas informticos de los organismos pertenecientes a la Administracin Pblica Nacional (APN). Por otro lado, el Ministerio del Poder Popular para las Telecomunicaciones y la Informtica (MPPTI), debe definir los lineamientos y polticas para llevar a cabo los procesos institucionales de migracin gradual y progresiva a SL, as como programas y proyectos que fortalezcan la industria nacional de software, promoviendo el desarrollo tecnolgico de la nacin. Dado que el SL se caracteriza porque su proceso de desarrollo es llevado a cabo por comunidades de diversas tendencias, contar con un marco de procesos que sirva de apoyo a esta tarea es un reto complejo. En este trabajo se describe una propuesta metodolgica basada en Unified Process (UP) para gestionar proyectos de desarrollo de SL para el estado venezolano, siguiendo los lineamientos del MPPTI y cumpliendo con los estndares internacionales que propician software de calidad. Esta propuesta de gestin de proyectos de SL busca fortalecer la cooperacin y colaboracin entre las distintas comunidades desarrolladoras de SL, adems de garantizarle al Estado venezolano el cumplimiento con calidad del decreto 3.390.

1. Introduccin
Actualmente el Software Libre (SL) ha ganado seguidores a nivel mundial debido a las ventajas, tanto filosficas como prcticas, que ofrece a sus usuarios y desarrolladores. Las ventajas de este movimiento se derivan de las cuatro libertades (uso, estudio, modificacin y

distribucin) que fomentan en sus sistemas, dando de esta forma la posibilidad de adaptar rpidamente el software a las preferencias y necesidades, tanto de usuarios como de organizaciones. Existen dos movimientos vinculados a este tipo de desarrollo Free Software y Open Source. El tiempo ha demostrado que ambos ofrecen sistemas de bajos costos, con alta seguridad, basados en estndares abiertos, que favorecen el trabajo colaborativo, aumentan la capacidad tecnolgica, reducen la dependencia de proveedores y fomentan el desarrollo de la empresa local (Sourcepyme, 2006). Incluso han ofrecido soluciones Web que demuestran ser ms robustas que sus anlogas en el software propietario (Netcraf, 2006; Wheeler, 2005). Sin embargo, el desarrollo de SL, por su carcter colaborativo, tiende a ser catico, sin metodologas documentadas y enfocadas ms en el producto de software que en su proceso de desarrollo. Olvidando, de esta forma, los atributos de calidad que se han identificado en el mbito de la Ingeniera del Software. En este artculo se presenta una propuesta metodolgica basada en Unified Process (UP) para gestionar proyectos de desarrollo de SL con un enfoque de Calidad. Esta propuesta fue desarrollada en el Centro Nacional de Tecnologas de Informacin (CNTI) con el objetivo de fomentar la coordinacin, comunicacin y cooperacin dentro de los equipos de proyecto, adems de ofrecer una forma de garantizar al Estado venezolano el cumplimiento con calidad del Decreto Presidencial N 3.390, basado en el artculo 110 de la Constitucin de la Repblica Bolivariana de Venezuela de 1999 que plantea el uso prioritario del SL en toda la Administracin Pblica Nacional (APN). Adems de la Introduccin y las Conclusiones, este artculo consta de cinco secciones. En la primera se resumen las necesidades de la Oficina de Apoyo Tcnico al Estado (OATE) del CNTI luego de analizar su situacin actual; en la segunda se analizan las metodologas ms frecuentes en la literatura revisada; en la cuarta se hace la propuesta metodolgica, y en la quinta de describe el habilitador que la soporta. 2. Diagnstico Despus de un anlisis de la situacin actual mediante la recoleccin de informacin, observaciones e interacciones con los equipos de proyectos de software de la OATE, incluyendo las cooperativas y pequeas empresas desarrolladoras de software contratadas, se pudieron determinar las siguientes necesidades: Estandarizar la documentacin, lneas base y procesos de desarrollo de sistemas. Gestionar bajo un enfoque disciplinado y sistemtico los proyectos para poder obtener resultados en tiempo y costos satisfactorios. Desarrollar sistemas con documentacin adecuada y que provea trazabilidad, a fin de permitir y facilitar la reutilizacin y gestin de componentes para otros proyectos tanto internos como externos a la organizacin. Facilitar el desarrollo de aplicaciones basadas en SL para atender requerimientos de organismos de la APN. Tener un marco de trabajo extensible que permita ser adaptado conforme a los lineamientos del desarrollo de software de cada proyecto dentro la organizacin, el cual involucre al personal desarrollador interno de la organizacin, el cliente,

cooperativas, pequeas compaas y dems entes jurdicos con los que trabaja el organismo. Fortalecer el perfil las empresas, cooperativas y el de los desarrolladores de software en Venezuela, a travs de capacitacin sobre el proceso de desarrollo de software con calidad. Capacitar con mtodos y herramientas estandarizadas a las cooperativas, pequeas empresas, desarrolladores internos de la organizacin y dems entes jurdicos de base tecnolgica, encargadas del diseo y desarrollo de las soluciones de software para la APN. Propiciar las mejores prcticas en el proceso de desarrollo de software a fin de aprovechar al mximo las capacidades que se tienen para desarrollar software con eficacia y eficiencia. Adoptar y adaptar modelos de desarrollo de software que garanticen ptimos niveles de calidad en los procesos de produccin y los productos finales. Consolidar la industria nacional de SL, y permitir la apropiacin y reutilizacin del conocimiento implcito en esta actividad. Promover el desarrollo del SL Nacional en las organizaciones pblicas y privadas del pas.

Como respuesta a estas necesidades se analizaron las metodologas de desarrollo de software existentes hasta el momento con el objetivo de identificar las mejores prcticas y adaptarlas al entorno venezolano.
3.

Anlisis de las Metodologas

Para responder a las necesidades de la OATE se analizaron un conjunto de metodologas siguiendo la clasificacin propuesta por Boehm (2002); es decir, algunas metodologas pertenecientes al grupo de orientadas al plan y otras al grupo de metodologas giles. Las metodologas analizadas fueron: Dynamic Systems Development Method (DSDM) (DSDM Consortium, 2007); Feature Driven Development (FDD) (Palmer y Felsing, 2002); Microsoft Solution Framework (MSF) (Microsoft Corporation, 2006); Proceso Unificado (UP) (Jacobson y otros, 2000); Proceso Unificado Abierto (OpenUP) (Eclipse Foundation, 2007); Proceso Unificado de Rational (RUP) (IBM Corporation, 2006); Programacin Extrema (XP) (Beck, 2000), y Scrum (Schwaber, 2004). El anlisis consisti en compararlas, con el fin de identificar las similitudes y diferencias entre ellas con base a las mejores prcticas que propicia cada una, los roles que definen, sus flujos de trabajo, las fases que contemplan y las actividades necesarias para completar el ciclo de vida de un sistema de software.

3.1 Mejores Prcticas Sobre las mejores prcticas de la ingeniera de software recabada de toda la investigacin bibliogrfica, en la Tabla 1 se muestra la comparacin entre las metodologas seleccionadas con base a la evidencia de cules son las mejores prcticas que ella promueven, tamao de los grupos de trabajo y complejidad del proyecto.
Tabla 1. Mejores Prcticas empleadas por las Metodologas
1

Metodologas Conceptos Adaptar el proceso de desarrollo Alto nivel de abstraccin Fomento del aprendizaje de experiencias Centrarse en la arquitectura Interaccin continua con cliente Cdigo estndar Colaboracin entre equipo Demostrar resultados Iterativamente e Incrementalmente Diseo simple Modelar el software Enfoque continuo en la calidad Enfoque en los riesgos Permanecer gil y esperar los cambios Dirigido por Casos de Uso Para pequeos grupos de trabajo Para grandes grupos de trabajo Para proyectos complejos

UP

RUP

OpenUP

XP

MSF

FDD

Scrum

DSDM

En la Tabla 1 se puede constatar fundamentalmente que todas las metodologas analizadas tienen un enfoque continuo en la calidad, son iterativas e incrementales, tienen un enfoque en los riesgos y son unos marcos de trabajo adaptable. Por otro lado, como detalles significativos se tiene que para grandes proyectos slo RUP y Scrum son las ms adecuadas, y que slo UP est totalmente dirigido por casos de uso.

3.2 Nivel de los Procesos de Desarrollo Segn Eclipse Foundation (2007), cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones crticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores, los cuales podran ser los criterios aplicables a cada iteracin. Cada metodologa que est siendo analizada es representada en la Figura 1 con tres barras, la primera barra representa si la metodologa provee soporte para la gestin de proyectos; la segunda barra representa si la metodologa provee el proceso de desarrollo; y la tercera barra indica si la metodologa describe las actividades y artefactos que pueden ser seguidos y empleados para cubrir el proceso de desarrollo de dicha metodologa. La Figura 1 muestra que las diferentes metodologas estudiadas estn enfocadas en diferentes aspectos de ciclo de vida del proceso de desarrollo de software. Adems, algunas estn ms enfocadas en las prcticas y el proceso de desarrollo (XP), mientras que otras se enfocan ms en la gestin del proyecto (Scrum). As mismo, se observa la existencia de metodologas que proveen cobertura completa sobre el ciclo de vida del desarrollo de software (DSDM y RUP).

Figura 1. Ciclo de Vida Provisto por las Metodologas de Desarrollo de Software. Adaptado Abrahamsson, P. et al. (2002).

A continuacin se compararan los roles empleados por las metodologas para llevar a cabo las actividades anteriormente sealadas.

3.3 Roles El conjunto de actividades presentes en una metodologa son realizadas por diferentes roles que producen unos resultados observables. En la Tabla 2 se presentarn los grupos de roles presentes en las metodologas que estn siendo analizadas, para dicha comparacin se establecer conforme a una serie de roles predefinidos que servirn como medio de tipificacin para la comparacin.
Tabla 2. Roles empleados por las Metodologas2 Metodologas Roles Analista de Calidad Analista del Producto Arquitecto Desarrollador Involucrados Lder de Proyecto Probador Otros Roles UP RUP OpenU P XP MSF FDD Scrum DSDM

La Tabla 2 seala que las diferentes metodologas para el desarrollo de software que estn siendo analizadas en no todas las metodologas se observa que correspondan los mismos roles. Otro aspecto importante de destacar es que cada metodologa propone un conjunto de roles adicionales que complementan su proceso de desarrollo acorde a lo propuesto por estas. 3.4 Artefactos Un producto o artefacto es un fragmento de informacin que es producido, modificado o usado durante el proceso de desarrollo de software (Kruchten, 2003). Los artefactos son producto de las actividades necesarias para completar el ciclo de vida de desarrollo del sistema, mientras que los roles son los responsables de crear y actualizar artefactos. Para establecer las comparaciones a nivel de los artefactos se emple la tabla 3, la cual contiene como metalenguaje el conjunto de artefactos definidos por Kruchten (2003) como los ms importantes para un proceso de desarrollo de software, adicionalmente a los artefactos se presenta una fila donde se seala si la metodologa descrita por sus autores provee dichos artefactos y mantienen un estndar si por el contrario son artefactos que se adquieren mediante terceros. Por otro lado, la tabla 3 incluye dos productos desarrollados por terceros que facilitan artefactos para la gestin de proyectos, las cuales tienen la caracterstica de que pueden ser empleadas por cualquier metodologa para el desarrollo de software, es decir que las mismas son universales y pueden sustituir a los artefactos de cualquiera de las metodologas aqu comparadas. En la tabla 3 se observa que las diferentes metodologas para el desarrollo de software que estn siendo analizadas no detallan los mismos artefactos para sus procesos de desarrollo, a su vez cabe destacar que cada metodologa no define estos artefactos en igual profundidad y detalle. Todas las metodologas presentadas abarcan ms artefactos de los presentados en la tabla 3 y muchos de ellos son especficos para su proceso de desarrollo. Otro aspecto

importante a destacar de la tabla 3 es que cada metodologa para el desarrollo de software presenta en sus artefactos uno o varios tipos de licencia para su uso. As mismo, los artefactos en muchos casos son provistos por terceros, con lo cual se denota que no todas las metodologas incluyen sus artefactos provenientes de sus autores originales, sino en muchos casos de fuentes externas. Por su parte ReadySET segn Robbin, J. (2003) y Method123 segn Method123 (2003), ofrecen artefactos independientes de la metodologa que se est empleando y que pueden cubrir algunos de los artefactos que se estn tipificando. Ninguna de las metodologas analizadas contempla todas las prcticas, artefactos, roles y ciclo de vida considerados para el desarrollo de software contemplados, pero el UP por ser libre y ofrecer un marco de desarrollo flexible, permite que pueda ser ajustado a los requerimientos de la organizacin. Basndose en este anlisis, a continuacin se presenta la propuesta metodolgica para la Gestin de Proyectos de SL.

Tabla 3. Artefactos empleados por las Metodologas Metodologas Artefactos Caso del Negocio Documento de Arquitectura del Software Especificaciones Suplementarias Glosario Modelo de Anlisis Modelo de Casos de Uso Modelo de Diseo Modelo de Implementacin Plan de Gestin de Riesgos Plan de Implantacin Plan de Iteracin Plan de Pruebas Planificacin del Proyecto Producto Visin del Sistema Otros Artefactos Fuente de los Artefactos Propio Por Terceros Tipo de Licencia Propietaria Libre UP RUP Open UP XP MSF FDD Scrum DSD M Productos Method1 ReadySET 23

4. MeRinde
La Red Nacional de Integracin y Desarrollo de Software Libre (RINDE) esta integrada por un conjunto de herramientas destinadas a apoyar los procesos de desarrollo y migracin a SL en el Estado Venezolano (Rinde, 2007). En este caso, MeRinde (Metodologa de RINDE), es la propuesta metodolgica que se pone a disposicin de los usuarios de la red. Para describir la metodologa aqu propuesta, primero se presentan sus fundamentos, y luego describimos su estructura.

4.1 Fundamentos MeRinde establece una estructura que cubre todo el ciclo de vida de desarrollo de software, por ello incluye fases, roles, actividades, artefactos, disciplinas, flujos de trabajo, mitigacin de riesgos, control de calidad, gestin del proyecto y control de configuracin. En general, esta metodologa est fuertemente fundamentada en los requerimientos del CNTI y en las mejores prcticas para el desarrollo de software congregadas en UP, RUP, XP, MSF y OpenUP. MeRinde propone una estructura como UP basada en aspectos dinmicos y estticos. Las fases e hitos que corresponde los aspectos dinmicos considerados son las de UP y las disciplinas que corresponde a los aspectos estticos de la metodologa se fundamentan en las de UP, OpenUP y RUP. Dada las necesidades del CNTI expuestas anteriormente, MeRinde fue formulada y desarrollada bajo el enfoque orientado a planes, para satisfacer los requerimientos de planificacin, detalle de documentacin y que pueda ser un proceso flexible aplicable tanto por un nmero variado de personas expertas o con poca experiencia en el rea de desarrollo. A su vez, cabe destacar que esta metodologa se busca adaptar al desarrollo de SL de proyectos vinculados a organizaciones. MeRinde es concebida para abarcar el desarrollo completo de sistemas de software de diversa complejidad y magnitud, por lo cual su estructura responde a desarrollos mximos y deber adaptarse y dimensionarse en cada momento de acuerdo a las caractersticas particulares de cada proyecto. Dada la adaptabilidad que puede sufrir la metodologa, esta puede llegarse a aplicar bajo un enfoque gil, lo cual no se detalla en la presente investigacin, pero no se descarta su empleo. Los flujos de trabajos que envuelve cada disciplina estn inspirados en RUP, as como tambin en los procesos de desarrollo del CNTI y en la realidad y el deber ser del desarrollo de software. En cuanto a los roles, tareas y artefactos contenidos en una actividad se puede decir que la metodologa est fuertemente inspirada en los roles de MSF, las actividades en RUP, OpenUP, UP y las observadas del ambiente de desarrollo en el CNTI, y los artefactos estn basados en los de Readyset, UP, RUP, XP y artefactos existentes en la organizacin. Tambin se ven reflejadas las ideas y recomendaciones de los autores en muchos aspectos que envuelve MeRinde. 4.2 Estructura del Proceso de MeRinde MeRinde es un proyecto que propone un estndar abierto para el proceso de desarrollo de software orientado a planes que se estructura en tres dimensiones o ejes como se muestra en la Figura 2: Eje Horizontal: Representa el tiempo y es considerado el eje de los aspectos dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso expresado en trminos de fases, hitos e iteraciones. Eje Vertical: Representa los aspectos estticos del proceso. Describe el proceso en trminos de componentes de proceso, disciplinas, actividades, artefactos y roles. En el modelo cada barra representa una iteracin por fase para un proyecto. Adicionalmente el modelo enfatiza que durante cada iteracin se recorren casi todas las disciplinas pero con

diferente esfuerzo, es por ello que en la Fase de Inicio, por ejemplo, la barra correspondiente a la Disciplina de Requerimientos tiene mayor altura que la barra de la Disciplina de Pruebas.

Figura 2. Esfuerzo en Actividades segn la Fase del Proyecto en MeRinde.

4.2.1 Visin dinmica de MeRinde MeRinde se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generacin del producto y consta de cuatro fases. Cada fase se subdivide a la vez en iteraciones, el nmero de iteraciones en cada fase es variable. El ciclo de vida de un proyecto de software en MeRinde se inspira en UP, motivo por el cual se descompone en el tiempo en cuatro fases secuenciales (ver Figura 3) que son: Inicio, Elaboracin, Construccin y Transicin. Al final de cada fase el equipo gestor del proyecto realiza una evaluacin para determinar si los objetivos se cumplieron y as pasar a la fase siguiente.

Figura 3. Fases e Hitos encontrados en MeRinde. Tomado de Jacobson, et al . (2000).

4.2.2 Visin esttica de MeRinde Un proceso de desarrollo de software segn (Letelier, 2003), define quin hace qu, cmo y cundo. El proceso de MeRinde define cuatro elementos: los roles, que responden a la pregunta Quin?, las actividades que responden a la pregunta Cmo?, los artefactos, que responden a la pregunta Qu? y los flujos de trabajo de las disciplinas que responde a la pregunta Cundo?, as como se muestra en la Figura 4.

Figura 4. Visin Esttica de MeRinde. Elaborado por los Autores, con imgenes de Farouz, (2006).

A continuacin se describen cada uno de los elementos antes mencionados. Disciplinas MeRinde se organiza en disciplinas. Las disciplinas poseen flujos de trabajos en donde cada uno conlleva a actividades (ver Figura 4) que a su vez estn compuestos por un conjunto de tareas (ver Figura 4) realizadas en un rea determinada, las cuales tienen como objetivo producir artefactos. A su vez, en MeRinde existen actividades que se dividen en subactividades con el fin de facilitar la agrupacin de tareas relacionadas. Roles Una de las razones principales de la adopcin de esta metodologa para el desarrollo de software consiste en la definicin de las tareas que sern llevadas a cabo por los individuos que participan en un proyecto. En MeRinde un rol (ver Figura 4) define las responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Este se encarga de la realizacin de tareas, las cuales generan artefactos. Cada uno de los roles propuestos en MeRinde poseen mtodos especficos para la ingeniera del software en su rea en particular. La metodologa del CNTI propone ocho (8) roles bsicos que deben tomarse en cuenta para la elaboracin de software, los cuales se describen en la Tabla 4. Cabe destacar que un rol puede ser desempeado por varias personas y una persona puede representar varios roles, es por ello que esta metodologa brinda la oportunidad de incorporar un nmero variante de personas a los proyectos de desarrollo. Por otro lado, para proyectos que por su magnitud requieran ms roles que los ocho recomendados, se puede ajustar MeRinde conforme a las necesidades.

Tabla 4. Descripcin de roles propuestos por MeRinde Rol Analista calidad. Analista producto. de de Descripcin Se encarga de revisar todos los documentos que reflejan el avance del proyecto, y de verificar que los objetivos del marco de desarrollo se cumplan. En estas actividades tambin participan los miembros del proyecto que estn involucrados en su elaboracin. Se encarga de dirigir el proceso de captura de requerimientos, definir los actores y casos de uso y estructurar el modelo de casos de uso, estableciendo la forma en que funcionar el sistema y cules son las restricciones del mismo. Se encarga de la definicin de la arquitectura que guiar el desarrollo, y de la continua refinacin de la misma en cada iteracin; debe construir cualquier prototipo necesario para probar aspectos riesgosos desde el punto de vista tcnico del proyecto; definir los lineamientos generales del diseo y la implementacin. Tiene a su cargo la codificacin de los componentes en cdigo fuente en algn lenguaje de programacin durante cada iteracin; debe elaborar y ejecutar las pruebas unitarias realizadas sobre el cdigo desarrollado; es responsable de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante cambios y mantenerlas bajo el control de configuracin de las mismas mediante la herramienta utilizada. Cualquier persona que se vea afectada por el resultado del proyecto es considerada como un involucrado. Comprende un grupo de personas interesadas en que sus necesidades sean satisfechas por el proyecto. Este rol se encarga de establecer las condiciones de trabajo. Por tal motivo tiene la funcin de dirigir y asignar recursos, coordina las interacciones con los clientes y usuarios finales, planifica las iteraciones, asigna el trabajo, define la organizacin del proyecto, establece las prcticas que aseguran la integridad y calidad de los artefactos del proyecto, entre otras responsabilidades. El Mentor es un rol incorporado por MeRinde, el cual est ntimamente ligado con el proceso de desarrollo de software, que conoce todas las prcticas involucradas y entiende el porqu de la misma. Acompaa y apoya a los equipos de trabajo mediante revisiones de los artefactos y haciendo recomendaciones de cmo mejorar los mismos durante todo el ciclo de vida del sistema. Este rol est en capacidad de aclarar cualquier duda que puede surgir del proceso, as como tambin contribuye a que la calidad se mantenga durante el desarrollo del sistema y adems es considerado necesario para guiar los procesos de desarrollo sobre todo cuando: Los equipos de proyecto cuentan con poca experiencia en el desarrollo de los sistemas. La complejidad y la criticidad del proyecto juegan un papel fundamental. El equipo de proyecto es numeroso y distribuido. La organizacin cuenta con una cultura organizacional dirigida al orden. El Mentor se encarga de hacer con base en observaciones y revisiones constantes al proyecto una serie recomendaciones formales sobre las mejores prcticas para el proceso de desarrollo que han funcionado en contextos similares y es este quien aporta cmo se pueden emplear dada las particularidades del proyecto a desarrollar. Quien desempee este rol debe contar con una amplia experiencia en el desarrollo de sistemas y debe conocer las herramientas que se estn empleando para la documentacin del mismo. La funcin del probador es realizar las pruebas identificadas y definidas previamente, utilizando las instrucciones, mtodos y herramientas necesarias para este rol. Debido a la realizacin de las pruebas debe obtener los resultados de las mismas.

Arquitecto de software. Desarrollador.

Involucrados. Lder del proyecto.

Mentor.

Probador.

El trabajo en equipo entre todos los involucrados es un principio fundamental para alcanzar el xito en cualquier proyecto. MeRinde reconoce esto y asigna roles y responsabilidades a cada persona involucrada en un proyecto, tanto del lado del cliente como del de los desarrolladores, y permite que estos trabajen continuamente en equipo.

El Modelo de Equipo para Proyectos El desarrollo de SL para el CNTI est conformado por equipos de personas que trabajan en conjunto en reas geogrficas que pueden ser distantes; es decir distribuidos o por el contrario que pueden coincidir en un punto. Adicionalmente a esto, se tiene que el desarrollo de un proyecto puede estar a cargo de personal tanto interno como externo a una organizacin, en donde a su vez el personal externo a una organizacin puede ser de diversa ndole jurdica como cooperativas, fundaciones, entes gubernamentales, compaas, personas naturales, entre otras. Todo lo anteriormente sealado impacta la configuracin de un equipo ideal, para la cual es importante considerar todos los roles propuestos por MeRinde y que las responsabilidades individuales sean asignadas apropiadamente para alcanzar el xito. MeRinde para solucionar las restricciones anteriormente expuestas propone como modelo para equipos de trabajo una estructura que puede ser observada en la Figura 5 o, muchos individuos pueden asumir un rol.

Figura 5. Representacin Grfica del Modelo de Equipo de Proyecto.

En la Figura 5 los rectngulos contienen los diversos roles contemplados por la metodologa, las lneas que conectan el diagrama representan lneas de comunicacin, las elipses representan los equipos y los fuertes enlaces comunicacionales que existen entre estos, y la elipse central es ncleo del modelo donde se ve el equipo como un todo en donde existe una constante comunicacin, coordinacin y cooperacin. El modelo de equipo para proyectos est conformado por: Un equipo de gestin de proyecto el cual es interno a la organizacin que conlleva el proyecto, cuya misin es mantener y establecer los lineamientos del proyecto y mantener la calidad durante todo el ciclo de vida del proyecto. Uno o ms equipos de desarrollo que conllevan el anlisis, diseo e implementacin del proyecto. Estos pueden representar desde una organizacin como una cooperativa hasta individuos que participan en el proyecto, los cuales a su vez se pueden ser interno, externo ambas inclusive a la organizacin. El caso en que una organizacin cuenta con personal interno y externo a la vez puede ser el ms difcil de comprender, para el caso de MeRinde ambos son equipos distintos y con tareas especificas pero que

entran en la elipse central donde hay una alta comunicacin, coordinacin y cooperacin para desarrollar el proyecto en conjunto. Uno o ms probadores ajenos a los equipos de gestin y de desarrollo. Uno o ms involucrados en el proyecto que colaboren. Un equipo de proyecto, conformado por todos los elementos anteriormente listados, el cual est integrado por una cantidad de individuos que pueden variar durante las diversas etapas del desarrollo.

El modelo en general no pretende ser una estructura jerrquica, sino por el contrario representa un modelo de trabajo flexible basado en la comunicacin, cooperacin y la coordinacin para aplicar las prcticas y flujos de trabajos especificados en MeRinde. El Modelo se ajusta a los cambios que puedan ocurrir por la salida o entrada de individuos a un proyecto, as como a desarrollos tanto internos como externos al CNTI y a las restricciones geogrficas de los equipos de trabajo que pueda emplear la organizacin como cooperativas u otras organizaciones de ndole jurdica que se encuentran geogrficamente distribuidas en todo el territorio nacional. A continuacin se describen los artefactos que representan otro de los aspectos estticos en esta metodologa. Artefactos Propuestos en MeRinde MeRinde propone setenta y siete (77) artefactos que pueden ser creados durante el proceso de desarrollo de software. Estos artefactos van desde el propio cdigo fuente hasta la documentacin aportada por el cliente y la entregada por el equipo de desarrollo al culminar cada hito dentro del proyecto. Partiendo de estos artefactos se pueden crear slo los artefactos que se consideren necesarios para el proyecto, adicionalmente segn los lineamientos establecidos se les puede hacer modificaciones a los mismos y tambin se pueden establecer artefactos adicionales a los aqu propuestos siempre que estos faciliten y cumplan con los requerimientos. Se recomienda al emplear MeRinde usar pocos artefactos, eligiendo los de mayor valor prctico para cada proyecto, siguiendo los lineamientos de la disciplina de gestin del ambiente. Mientras mayor documentacin exista que detalle en profundidad los aspectos de un sistema, mejor ser el entendimiento de los grupos de trabajo sobre el proyecto, as mismo esta documentacin flexibiliza el proceso posterior de mantenimiento que el sistema puede llegar a tener, adicionalmente es una buena prctica para la elaboracin de proyectos que involucran un gran nmero de personas y roles. MeRinde propone un total de 77 artefactos, donde 14 son necesarios y 21 poseen plantillas especficas para su detalle, pero por razones de espacio no se listan en este artculo. Existen artefactos en MeRinde que se encuentran contenidos dentro de otro artefactos, a los artefactos contenedores de otros artefactos tambin se les denomina artefactos compuestos. 5. Habilitador Web El Habilitador Web cuyo objetivo es brindar el proceso de aprendizaje y de distribucin del material de la metodologa MeRinde de forma fcil e integrada a los usuarios, permitiendo

adicionalmente el acceso a una serie de recursos y de servicios. Al igual que un sitio Web, el mismo puede ser accedido desde cualquier ubicacin geogrfica con un navegador Web y con una conexin a internet activa. Cabe destacar que el Habilitador Web se encuentra publicado en la direccin http://MeRinde.rinde.gob.ve/. Una de sus interfaces se presenta en la Figura 6.

Figura 6. Interfaz del flujo de trabajo de la disciplina Gestin de Configuracin y Cambios

6. Conclusiones En este artculo se hace la propuesta metodolgica MeRinde que responde a las necesidades de las OATE del CNTI, de Venezuela, las cuales estn fuertemente influenciadas por el decreto 3390. La formulacin de la propuesta metodolgica se bas en los principios de investigacin accin, y de reingeniera de procesos. Por ello se analizaron las metodologas encontradas ms frecuentemente en la literatura en base a las mejores prcticas que propician, los roles que definen, sus flujos de trabajo, las fases que contemplan y las actividades necesarias para completar el ciclo de vida de un sistema de software. Entre sus principales beneficios esta su adecuacin a la realidad del desarrollo de software libre y al contexto venezolano. En el cual se presentan actores de diferentes sectores pudiendo o no estar en la misma ubicacin geogrfica. MeRinde pasa a ser una herramienta ms de apoyo a las comunidades de desarrollo de software libre de Venezuela. En los prximos pasos se aspira a evaluar esta propuesta metodolgica aplicando mtricas de calidad tanto de producto como de proceso a fin de hacer mejoras en la misma y medir su efectividad.

Referencias
Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. Agile software development method, review and analysis, Finlandia, VTT Publications (478), 2002. Beck K. Extreme Programming Explained, Addison-Wesley, 2000. Boehm, B. Get Ready for Agile Methods, with Care, IEEE Computer 35(1), 2002, pp. 64-69. DSDM Consortium. DSDM Public Version 4.2. http://www.dsdm.org/products/dsdm_version_4_2.asp. Acceso el 26 Ene. 2007. Disponible en:

Eclipse Foundation. OpenUP/Basic Published. Material descargable desde: http://www.eclipse.org/epf/ downloads/openup/openup_downloads.php. Disponible en: OpenUP_Basic_published-0.9-20061002. Acceso el 26 Ene. 2007. Farouz, J. Kopete Vista Icono Theme. Disponible en: http://www.kde-look.org/content/show.php? content=48635 como 48635-Kopete_Vista.tar. Acceso el 16 Dic. 2006. IBM Corporation. Rational Unified Process [Material disponible en disco Compacto (CD)]. Disponible: Rational Unified Process Version 7.0.1., 2006. Jacobson, I., Booch, G. y Rumbaugh, J. El Proceso Unificado de Desarrollo de Software, Madrid, Pearson Educacin S.A., 2000. Kruchten, P. The Rational Unified Process: An Introduction (3ra Ed.), Addison Wesley, 2003. Letelier, P. Proyecto Docente e Investigador, DSIC, 2003. Method123. Project Management Templates. Disponible en: http://www.method123.com. Acceso el 02 Feb. 2007. Microsoft Corporation. MSF for Agile Software Development [Material descargable desde http://msdn2.microsoft.com/en-usa/teamsystem/aa718795.aspx]. Disponible: MSF for Agile Software Development Version 4.1.0., 2006. Netcraft. December 2006 Web Server Survey. Disponible en: http://news.netcraft.com/. Acceso el 09 Dic. 2006. Palmer, S. y Felsing, J. A Practical Guide to Feature-Driven Development, The Coad Series, 2002. Rinde. Descripcin de Rinde. Disponible en: https://rinde.gob.ve. Acceso el 10 Abr. 2007. Robbin, J. Readyset. Disponible en: http://readyset.tigris.org. Acceso el 02 Feb. 2007. Schwaber, K. Agile Project Management with Scrum, Microsoft-Press, 2004. Sourcepyme. Los institutos tecnolgicos AIMME, AIMPLAS e ITI renen a ms de 200 expertos en la Jornada Sourcepyme. Disponible en: http://www.sourcepyme.org/?q=node/97. Acceso el 10 Dic. 2006. Wheeler, D. Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! 2005. Disponible en: http://www.dwheeler.com/oss_fs_why.html. Acceso el 10 Dic. 2006.