El documento presenta una propuesta metodológica basada en Unified Process (UP) para gestionar proyectos de desarrollo de Software Libre (SL) con un enfoque de calidad en Venezuela. La propuesta busca estandarizar procesos, gestionar proyectos de forma sistemática, y fortalecer la industria nacional de SL siguiendo lineamientos gubernamentales. Se analizaron varias metodologías para identificar mejores prácticas y adaptarlas al contexto venezolano. La propuesta sigue un marco de trabajo

1. Gestión de Proyectos de Desarrollo de Software Libre con un
Enfoque de Calidad
Kenyer Domínguez, María Pérez, Luis E. Mendoza
Laboratorio 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ón
Ministerio de del Poder Popular para las Telecomunicaciones y la Informatíca
Av. Universidad, esquina El Chorro, torre Ministerial, piso 11, Caracas, Venezuela
hrivero@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

2. 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,

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

4. 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ías
1
Metodologías
UP RUP OpenUP XP MSF FDD Scrum DSDM
Conceptos
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.

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

6. 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
Metodologías OpenU
UP RUP XP MSF FDD Scrum DSDM
Roles P
Analista de Calidad √ √
Analista del Producto √ √ √
Arquitecto √ √ √ √ √ √
Desarrollador √ √ √ √ √ √
Involucrados √ √ √ √
Líder de Proyecto √ √ √ √ √ √ √ √
Probador √ √ √ √ √ √ √
Otros Roles √ √ √ √ √ √ √ √
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

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

8. Tabla 3. Artefactos empleados por las Metodologías
Metodologías Productos
Artefactos Open DSD Method1
UP RUP XP MSF FDD Scrum ReadySET
UP M 23
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
Artefactos
Propio √ √ √ √ √ √
Por Terceros √ √ √ √
Tipo de Licencia
Propietaria √ √ √ √ √
Libre √ √ √ √ √ √ √
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.

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

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

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

12. Tabla 4. Descripción de roles propuestos por MeRinde
Rol Descripción
Analista de Se encarga de revisar todos los documentos que reflejan el avance del proyecto, y de verificar
calidad. 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 Se encarga de dirigir el proceso de captura de requerimientos, definir los actores y casos de
producto. 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 Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la continua
software. 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 Este rol se encarga de establecer las condiciones de trabajo. Por tal motivo tiene la función de
proyecto. 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.

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

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

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

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