Gestión de Proyectos de Desarrollo de Software Libre con un Enfoque de Calidad

Kenyer Domínguez, María Pérez, Luis E. MendozaLaboratorio de Investigación en Sistemas de Información (LISI),

Departamento de Procesos y Sistemas, Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas 1080-A, Venezuela.

{kdoming, movalles, lmendoza}@usb.ve

Kiberley Santos , Carlos D. Marrero Carrera Ingeniería de Sistemas, Universidad Nacional Experimental de las Fuerzas Armadas,

Chacao, Caracas 1064, Venezuela.{cdmarrero2040, kiberleys }@hotmail.com

Henry Rivero ,Oficina de Apoyo Técnico al Estado (OATE)

Centro Nacional de Tecnologías de InformaciónMinisterio de del Poder Popular para las Telecomunicaciones y la Informatíca

Av. Universidad, esquina El Chorro, torre Ministerial, piso 11, Caracas, Venezuelahrivero@cnti.gob.ve

Resumen

Desarrollar software es una tarea riesgosa y difícil de controlar, sobre todo cuando se trabaja con grandes equipos de personas; por ello es necesario tener una metodología con el fin de gestionar bajo un enfoque disciplinado y sistemático 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 estándares abiertos en los servicios y sistemas informáticos de los organismos pertenecientes a la Administración Pública Nacional (APN). Por otro lado, el Ministerio del Poder Popular para las Telecomunicaciones y la Informática (MPPTI), debe definir los lineamientos y políticas para llevar a cabo los procesos institucionales de migración gradual y progresiva a SL, así como programas y proyectos que fortalezcan la industria nacional de software, promoviendo el desarrollo tecnológico de la nación.

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 metodológica 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 estándares internacionales que propician software de calidad. Esta propuesta de gestión de proyectos de SL busca fortalecer la cooperación y colaboración entre las distintas comunidades desarrolladoras de SL, además de garantizarle al Estado venezolano el cumplimiento con calidad del decreto 3.390.

1. Introducción

Actualmente el Software Libre (SL) ha ganado seguidores a nivel mundial debido a las ventajas, tanto filosóficas como prácticas, que ofrece a sus usuarios y desarrolladores. Las ventajas de este movimiento se derivan de las cuatro libertades (uso, estudio, modificación y

distribución) que fomentan en sus sistemas, dando de esta forma la posibilidad de adaptar rápidamente 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 estándares abiertos, que favorecen el trabajo colaborativo, aumentan la capacidad tecnológica, reducen la dependencia de proveedores y fomentan el desarrollo de la empresa local (Sourcepyme, 2006). Incluso han ofrecido soluciones Web que demuestran ser más robustas que sus análogas en el software propietario (Netcraf, 2006; Wheeler, 2005).

Sin embargo, el desarrollo de SL, por su carácter colaborativo, tiende a ser caótico, sin metodologías documentadas y enfocadas más 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 Ingeniería del Software.

En este artículo se presenta una propuesta metodológica 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 Tecnologías de Información (CNTI) con el objetivo de fomentar la coordinación, comunicación y cooperación dentro de los equipos de proyecto, además de ofrecer una forma de garantizar al Estado venezolano el cumplimiento con calidad del Decreto Presidencial Nº 3.390, basado en el artículo 110 de la Constitución de la República Bolivariana de Venezuela de 1999 que plantea el uso prioritario del SL en toda la Administración Pública Nacional (APN).

Además de la Introducción y las Conclusiones, este artículo consta de cinco secciones. En la primera se resumen las necesidades de la Oficina de Apoyo Técnico al Estado (OATE) del CNTI luego de analizar su situación actual; en la segunda se analizan las metodologías más frecuentes en la literatura revisada; en la cuarta se hace la propuesta metodológica, y en la quinta de describe el habilitador que la soporta.

2. Diagnóstico

Después de un análisis de la situación actual mediante la recolección de información, observaciones e interacciones con los equipos de proyectos de software de la OATE, incluyendo las cooperativas y pequeñas empresas desarrolladoras de software contratadas, se pudieron determinar las siguientes necesidades:

• Estandarizar la documentación, líneas base y procesos de desarrollo de sistemas. • Gestionar bajo un enfoque disciplinado y sistemático los proyectos para poder obtener

resultados en tiempo y costos satisfactorios.• Desarrollar sistemas con documentación adecuada y que provea trazabilidad, a fin de

permitir y facilitar la reutilización y gestión de componentes para otros proyectos tanto internos como externos a la organización.

• 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 organización, el cual involucre al personal desarrollador interno de la organización, el cliente,

cooperativas, pequeñas compañías y demás entes jurídicos con los que trabaja el organismo.

• Fortalecer el perfil las empresas, cooperativas y el de los desarrolladores de software en Venezuela, a través de capacitación sobre el proceso de desarrollo de software con calidad.

• Capacitar con métodos y herramientas estandarizadas a las cooperativas, pequeñas empresas, desarrolladores internos de la organización y demás entes jurídicos de base tecnológica, encargadas del diseño y desarrollo de las soluciones de software para la APN.

• Propiciar las mejores prácticas en el proceso de desarrollo de software a fin de aprovechar al máximo 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 producción y los productos finales.

• Consolidar la industria nacional de SL, y permitir la apropiación y reutilización del conocimiento implícito en esta actividad.

• Promover el desarrollo del SL Nacional en las organizaciones públicas y privadas del país.

Como respuesta a estas necesidades se analizaron las metodologías de desarrollo de software existentes hasta el momento con el objetivo de identificar las mejores prácticas y adaptarlas al entorno venezolano.

3. Análisis de las Metodologías

Para responder a las necesidades de la OATE se analizaron un conjunto de metodologías siguiendo la clasificación propuesta por Boehm (2002); es decir, algunas metodologías pertenecientes al grupo de orientadas al plan y otras al grupo de metodologías ágiles. Las metodologías 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); Programación Extrema (XP) (Beck, 2000), y Scrum (Schwaber, 2004).

El análisis consistió en compararlas, con el fin de identificar las similitudes y diferencias entre ellas con base a las mejores prácticas 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 Prácticas

Sobre las mejores prácticas de la ingeniería de software recabada de toda la investigación bibliográfica, en la Tabla 1 se muestra la comparación entre las metodologías seleccionadas con base a la evidencia de cuáles son las mejores prácticas que ella promueven, tamaño de los grupos de trabajo y complejidad del proyecto.

Tabla 1. Mejores Prácticas empleadas por las Metodologías1

MetodologíasConceptos

UP RUP OpenUP XP MSF FDD Scrum DSDM

Adaptar el proceso de desarrollo √ √ √ √ √ √ √ √Alto nivel de abstracción √ √ √Fomento del aprendizaje de experiencias

√ √ √

Centrarse en la arquitectura √ √ √ √Interacción continua con cliente √ √ √ √Código estándar √Colaboración entre equipo √ √ √ √ √ √Demostrar resultados Iterativamente e Incrementalmente

√ √ √ √ √ √ √ √

Diseño 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 pequeños grupos de trabajo √ √ √ √ √ √ √Para grandes grupos de trabajo √ √Para proyectos complejos √ √

En la Tabla 1 se puede constatar fundamentalmente que todas las metodologías 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 sólo RUP y Scrum son las más adecuadas, y que sólo UP está totalmente dirigido por casos de uso.

3.2 Nivel de los Procesos de Desarrollo

Según 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 críticas 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 podrían ser los criterios aplicables a cada iteración. Cada metodología que está siendo analizada es representada en la Figura 1 con tres barras, la primera barra representa si la metodología provee soporte para la gestión de proyectos; la segunda barra representa si la metodología provee el proceso de desarrollo; y la tercera barra indica si la metodología describe las actividades y artefactos que pueden ser seguidos y empleados para cubrir el proceso de desarrollo de dicha metodología.

La Figura 1 muestra que las diferentes metodologías estudiadas están enfocadas en diferentes aspectos de ciclo de vida del proceso de desarrollo de software. Además, algunas están más enfocadas en las prácticas y el proceso de desarrollo (XP), mientras que otras se enfocan más en la gestión del proyecto (Scrum). Así mismo, se observa la existencia de metodologías que proveen cobertura completa sobre el ciclo de vida del desarrollo de software (DSDM y RUP).

1

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

A continuación se compararan los roles empleados por las metodologías para llevar a cabo las actividades anteriormente señaladas.

3.3 Roles

El conjunto de actividades presentes en una metodología son realizadas por diferentes roles que producen unos resultados observables. En la Tabla 2 se presentarán los grupos de roles presentes en las metodologías que están siendo analizadas, para dicha comparación se establecerá conforme a una serie de roles predefinidos que servirán como medio de tipificación para la comparación.

Tabla 2. Roles empleados por las Metodologías2

La Tabla 2 señala que las diferentes metodologías para el desarrollo de software que están siendo analizadas en no todas las metodologías se observa que correspondan los mismos roles. Otro aspecto importante de destacar es que cada metodología 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 información 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 más importantes para un proceso de desarrollo de software, adicionalmente a los artefactos se presenta una fila donde se señala si la metodología descrita por sus autores provee dichos artefactos y mantienen un estándar ó 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 gestión de proyectos, las cuales tienen la característica de que pueden ser empleadas por cualquier metodología para el desarrollo de software, es decir que las mismas son universales y pueden sustituir a los artefactos de cualquiera de las metodologías aquí comparadas.

En la tabla 3 se observa que las diferentes metodologías para el desarrollo de software que están siendo analizadas no detallan los mismos artefactos para sus procesos de desarrollo, a su vez cabe destacar que cada metodología no define estos artefactos en igual profundidad y detalle. Todas las metodologías presentadas abarcan más artefactos de los presentados en la tabla 3 y muchos de ellos son específicos para su proceso de desarrollo. Otro aspecto

MetodologíasRoles

UP RUPOpenUP

XP MSF FDD Scrum DSDM

Analista de Calidad √ √Analista del Producto √ √ √Arquitecto √ √ √ √ √ √Desarrollador √ √ √ √ √ √Involucrados √ √ √ √Líder de Proyecto √ √ √ √ √ √ √ √Probador √ √ √ √ √ √ √Otros Roles √ √ √ √ √ √ √ √

importante a destacar de la tabla 3 es que cada metodología 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 metodologías incluyen sus artefactos provenientes de sus autores originales, sino en muchos casos de fuentes externas.

Por su parte ReadySET según Robbin, J. (2003) y Method123 según Method123 (2003), ofrecen artefactos independientes de la metodología que se esté empleando y que pueden cubrir algunos de los artefactos que se están tipificando. Ninguna de las metodologías analizadas contempla todas las prácticas, 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 organización. Basándose en este análisis, a continuación se presenta la propuesta metodológica para la Gestión de Proyectos de SL.

Tabla 3. Artefactos empleados por las Metodologías

4. MeRinde

La Red Nacional de Integración y Desarrollo de Software Libre (RINDE) esta integrada por un conjunto de herramientas destinadas a apoyar los procesos de desarrollo y migración a SL en el Estado Venezolano (Rinde, 2007). En este caso, MeRinde (Metodología de RINDE), es la propuesta metodológica que se pone a disposición de los usuarios de la red.

Para describir la metodología aquí propuesta, primero se presentan sus fundamentos, y luego describimos su estructura.

Metodologías ProductosArtefactos

UP RUPOpenUP

XP MSF FDD ScrumDSDM

ReadySETMethod123

Caso del Negocio √ √ √ √ √

Documento de Arquitectura del Software

√ √ √ √ √ √

Especificaciones Suplementarias

√ √ √ √ √ √ √ √

Glosario √ √ √ √ √Modelo de Análisis

√ √

Modelo de Casos de Uso

√ √ √ √ √ √ √

Modelo de Diseño

√ √ √

Modelo de Implementación

√ √ √ √

Plan de Gestión de Riesgos

√ √ √ √ √ √

Plan de Implantación

√ √ √

Plan de Iteración √ √ √ √ √ √ √

Plan de Pruebas √ √ √ √ √ √Planificación del Proyecto

√ √ √ √ √ √ √ √ √ √

Producto √ √ √ √ √ √ √ √Visión del Sistema

√ √ √ √

Otros Artefactos √ √ √ √ √ √ √ √ √ √Fuente de los ArtefactosPropio √ √ √ √ √ √Por Terceros √ √ √ √Tipo de LicenciaPropietaria √ √ √ √ √Libre √ √ √ √ √ √ √

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, mitigación de riesgos, control de calidad, gestión del proyecto y control de configuración. En general, esta metodología está fuertemente fundamentada en los requerimientos del CNTI y en las mejores prácticas para el desarrollo de software congregadas en UP, RUP, XP, MSF y OpenUP. MeRinde propone una estructura como UP basada en aspectos dinámicos y estáticos. Las fases e hitos que corresponde los aspectos dinámicos considerados son las de UP y las disciplinas que corresponde a los aspectos estáticos de la metodología 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 planificación, detalle de documentación y que pueda ser un proceso flexible aplicable tanto por un número variado de personas expertas o con poca experiencia en el área de desarrollo. A su vez, cabe destacar que esta metodología 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 máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. Dada la adaptabilidad que puede sufrir la metodología, esta puede llegarse a aplicar bajo un enfoque ágil, lo cual no se detalla en la presente investigación, pero no se descarta su empleo.

Los flujos de trabajos que envuelve cada disciplina están inspirados en RUP, así como también 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 metodología 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 están basados en los de Readyset, UP, RUP, XP y artefactos existentes en la organización. También 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 estándar 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 dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases, hitos e iteraciones.

Eje Vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, actividades, artefactos y roles.

En el modelo cada barra representa una iteración por fase para un proyecto. Adicionalmente el modelo enfatiza que durante cada iteración 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 según la Fase del Proyecto en MeRinde.

4.2.1 Visión dinámica 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 generación del producto y consta de cuatro fases. Cada fase se subdivide a la vez en iteraciones, el número 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, Elaboración, Construcción y Transición. Al final de cada fase el equipo gestor del proyecto realiza una evaluación 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 Visión estática de MeRinde

Un proceso de desarrollo de software según (Letelier, 2003), define quién hace qué, cómo y cuándo. El proceso de MeRinde define cuatro elementos: los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los artefactos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo?, así como se muestra en la Figura 4.

Figura 4. Visión Estática de MeRinde. Elaborado por los Autores, con imágenes de Farouz, (2006).

A continuación 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 están 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 agrupación de tareas relacionadas.

Roles

Una de las razones principales de la adopción de esta metodología para el desarrollo de software consiste en la definición de las tareas que serán 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 realización de tareas, las cuales generan artefactos.

Cada uno de los roles propuestos en MeRinde poseen métodos específicos para la ingeniería del software en su área en particular. La metodología del CNTI propone ocho (8) roles básicos que deben tomarse en cuenta para la elaboración de software, los cuales se describen en la Tabla 4.

Cabe destacar que un rol puede ser desempeñado por varias personas y una persona puede representar varios roles, es por ello que esta metodología brinda la oportunidad de incorporar un número variante de personas a los proyectos de desarrollo. Por otro lado, para proyectos que por su magnitud requieran más roles que los ocho recomendados, se puede ajustar MeRinde conforme a las necesidades.

Tabla 4. Descripción de roles propuestos por MeRinde

Rol DescripciónAnalista de calidad.

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 también participan los miembros del proyecto que están involucrados en su elaboración.

Analista de producto.

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 cuáles son las restricciones del mismo.

Arquitecto de software.

Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la continua refinación de la misma en cada iteración; debe construir cualquier prototipo necesario para probar aspectos riesgosos desde el punto de vista técnico del proyecto; definirá los lineamientos generales del diseño y la implementación.

Desarrollador. Tiene a su cargo la codificación de los componentes en código fuente en algún lenguaje de programación durante cada iteración; debe elaborar y ejecutar las pruebas unitarias realizadas sobre el código desarrollado; es responsable de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante cambios y mantenerlas bajo el control de configuración de las mismas mediante la herramienta utilizada.

Involucrados. 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.

Líder del proyecto.

Este rol se encarga de establecer las condiciones de trabajo. Por tal motivo tiene la función de dirigir y asignar recursos, coordina las interacciones con los clientes y usuarios finales, planifica las iteraciones, asigna el trabajo, define la organización del proyecto, establece las prácticas que aseguran la integridad y calidad de los artefactos del proyecto, entre otras responsabilidades.

Mentor. El Mentor es un rol incorporado por MeRinde, el cual está íntimamente ligado con el proceso de desarrollo de software, que conoce todas las prácticas involucradas y entiende el porqué de la misma. Acompaña y apoya a los equipos de trabajo mediante revisiones de los artefactos y haciendo recomendaciones de cómo 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 también contribuye a que la calidad se mantenga durante el desarrollo del sistema y además 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 organización 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 prácticas para el proceso de desarrollo que han funcionado en contextos similares y es este quien aporta cómo se pueden emplear dada las particularidades del proyecto a desarrollar. Quien desempeñe este rol debe contar con una amplia experiencia en el desarrollo de sistemas y debe conocer las herramientas que se estén empleando para la documentación del mismo.

Probador. La función del probador es realizar las pruebas identificadas y definidas previamente, utilizando las instrucciones, métodos y herramientas necesarias para este rol. Debido a la realización de las pruebas debe obtener los resultados de las mismas.

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 geográficas 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 organización, en donde a su vez el personal externo a una organización puede ser de diversa índole jurídica como cooperativas, fundaciones, entes gubernamentales, compañías, personas naturales, entre otras. Todo lo anteriormente señalado impacta la configuración 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. Representación Gráfica del Modelo de Equipo de Proyecto.

En la Figura 5 los rectángulos contienen los diversos roles contemplados por la metodología, las líneas que conectan el diagrama representan líneas de comunicación, las elipses representan los equipos y los fuertes enlaces comunicacionales que existen entre estos, y la elipse central es núcleo del modelo donde se ve el equipo como un todo en donde existe una constante comunicación, coordinación y cooperación.

El modelo de equipo para proyectos está conformado por:

• Un equipo de gestión de proyecto el cual es interno a la organización que conlleva el proyecto, cuya misión es mantener y establecer los lineamientos del proyecto y mantener la calidad durante todo el ciclo de vida del proyecto.

• Uno o más equipos de desarrollo que conllevan el análisis, diseño e implementación del proyecto. Estos pueden representar desde una organización como una cooperativa hasta individuos que participan en el proyecto, los cuales a su vez se pueden ser interno, externo ó ambas inclusive a la organización. El caso en que una organización cuenta con personal interno y externo a la vez puede ser el más difícil 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 comunicación, coordinación y cooperación para desarrollar el proyecto en conjunto.

• Uno o más probadores ajenos a los equipos de gestión y de desarrollo.• Uno o más 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 jerárquica, sino por el contrario representa un modelo de trabajo flexible basado en la comunicación, cooperación y la coordinación para aplicar las prácticas 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 geográficas de los equipos de trabajo que pueda emplear la organización como cooperativas u otras organizaciones de índole jurídica que se encuentran geográficamente distribuidas en todo el territorio nacional.

A continuación se describen los artefactos que representan otro de los aspectos estáticos en esta metodología.

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 código fuente hasta la documentación 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 sólo los artefactos que se consideren necesarios para el proyecto, adicionalmente según los lineamientos establecidos se les puede hacer modificaciones a los mismos y también 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 práctico para cada proyecto, siguiendo los lineamientos de la disciplina de gestión del ambiente. Mientras mayor documentación 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 documentación flexibiliza el proceso posterior de mantenimiento que el sistema puede llegar a tener, adicionalmente es una buena práctica para la elaboración de proyectos que involucran un gran número de personas y roles.

MeRinde propone un total de 77 artefactos, donde 14 son necesarios y 21 poseen plantillas específicas para su detalle, pero por razones de espacio no se listan en este artículo.

Existen artefactos en MeRinde que se encuentran contenidos dentro de otro artefactos, a los artefactos contenedores de otros artefactos también se les denomina artefactos compuestos.

5. Habilitador Web

El Habilitador Web cuyo objetivo es brindar el proceso de aprendizaje y de distribución del material de la metodología MeRinde de forma fácil 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 ubicación geográfica con un navegador Web y con una conexión a internet activa.

Cabe destacar que el Habilitador Web se encuentra publicado en la dirección 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 Gestión de Configuración y Cambios

6. Conclusiones

En este artículo se hace la propuesta metodológica MeRinde que responde a las necesidades de las OATE del CNTI, de Venezuela, las cuales están fuertemente influenciadas por el decreto 3390.

La formulación de la propuesta metodológica se basó en los principios de investigación acción, y de reingeniería de procesos. Por ello se analizaron las metodologías encontradas más frecuentemente en la literatura en base a las mejores prácticas 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 adecuación 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 ubicación geográfica.

MeRinde pasa a ser una herramienta más de apoyo a las comunidades de desarrollo de software libre de Venezuela.

En los próximos pasos se aspira a evaluar esta propuesta metodológica aplicando métricas 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. Disponible en: http://www.dsdm.org/products/dsdm_version_4_2.asp. Acceso el 26 Ene. 2007.

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 Educación 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. Descripción 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 tecnológicos AIMME, AIMPLAS e ITI reúnen a más 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.