Complejo Educativo Brigadier Lpez

MeRinde
Metodologa de la Red Nacional de Integracin y Desarrollo de Software
Libre

Carrera: Analista De Sistemas.

Asignatura: Anlisis De Sistemas.

Profesor: Emanuel Salinas.

Alumnos: Lucas Zoela, Christian Thompson.

03/05/2016

Merinde

Brigadier Lpez

INDICE
1-MERINDE ............................................................................................................................................ 3
1.1- CARACTERSTICAS ................................................................................................................................... 3
1.2-VENTAJAS.............................................................................................................................................. 3
1.3-DESVENTAJAS......................................................................................................................................... 4
2-FASES .................................................................................................................................................. 4
2.1-FASE DE INICIO ....................................................................................................................................... 4
2.2-FASE DE ELABORACIN ............................................................................................................................ 4
2.3-FASE DE CONSTRUCCIN .......................................................................................................................... 5
2.4-FASE DE TRANSICIN ............................................................................................................................... 5
3-ESTRUCTURA DEL PROCESO DE MERINDE ........................................................................................... 6
3.1-VISIN DINMICA DE MERINDE ................................................................................................................. 6
3.2-VISIN ESTTICA DE MERINDE .................................................................................................................. 7
4-DISCIPLINAS ........................................................................................................................................ 7
4.1-MOLDEADO DEL NEGOCIO ........................................................................................................................ 8
4.2-REQUERIMIENTOS ................................................................................................................................... 8
4.3-ANLISIS Y DISEO .................................................................................................................................. 9
4.4-IMPLEMENTACIN................................................................................................................................... 9
4.5-PRUEBAS ............................................................................................................................................. 10
4.6-IMPLANTACIN..................................................................................................................................... 10
4.7-GESTIN DE CONFIGURACIN Y CAMBIOS................................................................................................... 11
4.8-GESTIN DEL PROYECTO ......................................................................................................................... 11
4.9-GESTIN DEL AMBIENTE ......................................................................................................................... 12
5-ARTEFACTOS ..................................................................................................................................... 12
6-ROLES ............................................................................................................................................... 14
7-EL MODELO DE EQUIPO PARA PROYECTOS ....................................................................................... 16
8-HABILITADOR WEB ........................................................................................................................... 17
9-CONCLUSIN .................................................................................................................................... 18
10-BIBLIOGRAFA: ................................................................................................................................ 19

Pgina 2 de 19

Merinde

Brigadier Lpez

1-MeRinde
Metodologa de la Red Nacional de Integracin y Desarrollo de Software Libre
(MeRinde) Una Propuesta Metodolgica para Elaborar Software Libre con el Uso de
Estndares Abiertos y con un Enfoque de Calidad.
Es un proyecto de Software Libre (SL) que propone un estndar para el
proceso de desarrollo de software que puede ser empleado y adaptado segn los
requerimientos de cualquier comunidad u organizacin, con la finalidad del desarrollo
de sistemas y adems para producir y mantener una librera de plantillas reutilizables
para la ingeniera de software. Estas plantillas proveen un punto partida para los
documentos utilizados en proyectos de desarrollo de software, con lo que pueden
ayudar a los desarrolladores a trabajar ms rpido y evitar pasar por alto aspectos
importantes del proceso de desarrollo.
Este proyecto pretende entre sus principales objetivos apoyar a las
comunidades de desarrollo de Software Libre en sus proyectos, suministrando las
herramientas necesarias para que estos cumplan con un proceso de desarrollo y
documentacin de sus sistemas.
La Metodologa MeRinde surge de la combinacin y adaptacin de modelos y
metodologas ampliamente utilizadas para el desarrollo de software y la reingeniera
de procesos del negocio. Esta metodologa est fuertemente fundamentada en los
requerimientos del Centro Nacional de Tecnologa de Informacin (CNTI) y en varias
metodologas como el Proceso Unificado (UP) especialmente. Pretende entre sus
principales objetivos apoyar a las comunidades de desarrollo de software libre en sus
proyectos, suministrando las herramientas necesarias para que estos cumplan con un
proceso de desarrollo y documentacin de sus sistemas.
1.1- Caractersticas
Estandarizacin

Flujos de trabajo

Proceso de desarrollo

Modelo de equipo

Propicia calidad

Plantillas de los artefactos

Adaptacin de varias practicas

1.2-Ventajas
Trazabilidad

Pgina 3 de 19

Merinde

Brigadier Lpez

Adaptacin y extensin

Habilitador metodolgico

Habilitador Web con Foro

Fortalecimiento

Integracin

Reutilizacin

Planificacin

Utiliza un procedimiento de desarrollo incremental e iterativo en el que se van

agregando ms funcionalidades al sistema

1.3-Desventajas
Falta de plantillas

La metodologa puede muy pesada

No contempla una herramienta para instanciar el desarrollo

Poco factible en un desarrollo real con todas las caractersticas de este mtodo

2-Fases
El ciclo de vida de un proyecto de software desarrollado por el CNTI se inspira
en UP, motivo por el cual se descompone en el tiempo en cuatro fases secuenciales
como se muestra abajo en la figura, que son:
2.1-Fase de inicio
En esta fase se plantea la visin que tiene el equipo o desarrollador en cuanto
a lo que ser el sistema, se fijan los propsitos o fines principales para el ciclo de vida
del producto. Durante la fase de inicio se establece el mecanismo por el cual el
producto le proveer beneficios al usuario final o bien sea al cliente. Se describen
todos los actores y casos de usos del producto y adems se debe crear o implementar
un plan de negocio para definir los recursos que se asignaran al proyecto. Para
finalizar esta fase se deben haber tomado en cuenta los costos en recursos,
el tiempo total del proyecto, los riesgos e incertidumbres que pueda generar, adems
de su viabilidad.

2.2-Fase de Elaboracin
El propsito especfico que tiene la fase de elaboracin es proyectar la manera
en que se va a realizar la arquitectura para el ciclo de vida del producto, es decir, para
su evolucin durante su uso o bien sea su permanencia en cuanto a funcionamiento,
se elabora una arquitectura en diversas interacciones hasta lograr el producto

Pgina 4 de 19

Merinde

Brigadier Lpez

deseado. Esta fase debe seguir el patrn de todos los casos de uso planteados en la
fase de inicio.
Adems se deben considerar la mayora de las exigencias funcionales,
tomando en cuenta los riesgos que puedan afectar los fines del sistema para que de
esta manera pueda hacerse realizable el producto en cuestin.
La fase de elaboracin concluye cuando el equipo del proyecto tiene en claro
los riesgos principales que puedan afectar al producto, de manera de saber cules son
los requerimientos en cuanto a la realizacin de este, adems de la evolucin que este
tendr.

2.3-Fase de Construccin
Una vez que el equipo este en esta fase deben tener como meta o finalidad
lograr la disposicin o capacidad operativa del producto, considerando que en dicho
producto deben de estar incluidas todas las propiedades, elementos, requisitos y/o
exigencias, las cuales previamente deben haber sido evaluadas y probadas
totalmente, obteniendo de esta manera una versin del producto que sea aprobada o
admisible para quien vaya a hacer uso de esta.
En conclusin, el objetivo de esta fase es el desarrollo total del sistema ya
preparado para la fase de transicin, debe haber sido probada toda su funcionalidad y
aplicacin de manera de evitar que sea pospuesta la fase de transicin por
incumplimiento de los criterios de esta fase.

2.4-Fase de Transicin
Ya en esta fase, el producto debe de estar en manos de los usuarios finales en
su forma funcional, luego de que haya sido probado y aceptado en su totalidad por
dichos usuarios, adems se deber doctrinar a los usuarios en cuanto al empleo o
manipulacin del sistema, y principalmente en lo que se refiere a la configuracin
usabilidad e instalacin del producto. Es decir, se debe avalar o confirmar que el
usuario aprenda a operar el producto final, el cual debe cumplir con todos los
requerimientos establecidos en el proceso de realizacin del mismo.
En resumen, en esta fase se debe determinar si todos los propsitos en cuanto
al proyecto fueron logrados, adems se debe confirmar que el cliente haya aceptado,
observado y verificado el producto final que le fue proporcionado.

Pgina 5 de 19

Merinde

Brigadier Lpez

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

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

Pgina 6 de 19

Merinde

Brigadier Lpez

inspira en UP, motivo por el cual se descompone en el tiempo en cuatro fases

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

3.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
siguiente figura:

4-Disciplinas

Modelado del Negocio

Requerimientos

Anlisis y Diseo

Pgina 7 de 19

Merinde

Implementacin

Pruebas

Implantacin

Disciplinas llamadas de soporte o gestin:

Gestin de Configuracin y Cambios

Gestin del Proyecto

Gestin del Ambiente

Brigadier Lpez

4.1-Moldeado del negocio

Con esta disciplina se pretende llegar a un mejor entendimiento de la
organizacin donde se va a implantar el sistema de software.
Los objetivos especficos del modelado de negocio son:
1. Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento comn de la organizacin objetivo.
2. Derivar los requerimientos del sistema necesarios para apoyar a la
organizacin objetivo en su mejora.
3. Entender el problema actual en la organizacin objetivo e identificar potenciales
mejoras.
4. Entender la estructura y la dinmica de la organizacin para la cual el sistema
va a ser desarrollado (organizacin objetivo).

4.2-Requerimientos
El objetivo principal de esta disciplina es establecer las funciones que se quiere
que satisfaga el sistema a construir. En esta lnea los requerimientos son el contrato
que se debe cumplir, de modo que los usuarios finales tienen que comprender y
aceptar los requerimientos que se especifiquen. Para obtener los requerimientos se
deben aplicar prcticas de licitacin a los involucrados en el proyecto, anotar y validar
todas sus solicitudes.
Los objetivos especficos de la disciplina requerimientos son:
1. Definir el mbito del sistema.
2. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y
metas del usuario.

Pgina 8 de 19

Merinde

Brigadier Lpez

3. Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo

que el sistema debera hacer.
4. Proveer a los desarrolladores un mejor entendimiento de los requerimientos del
sistema.
5. Proveer una base para estimar recursos y tiempo de desarrollo del sistema.
6. Proveer una base para la planeacin de los contenidos tcnicos de las
iteraciones.
4.3-Anlisis y diseo
El objetivo principal de esta disciplina es transformar los requerimientos a una
especificacin

que

describa

cmo

implementar

el

sistema.

El

anlisis

fundamentalmente consiste en obtener una visin que se preocupa de ver que hace el
sistema de software a desarrollar, por tal motivo este se interesa en los requerimientos
funcionales. Por otro lado, el diseo es un refinamiento que toma en cuenta los
requerimientos no funcionales, por lo cual se centra en como el sistema cumple sus
objetivos.
Los objetivos especficos del anlisis y diseo son:
1. Transformar los requerimientos al diseo del futuro sistema.
2. Desarrollar una arquitectura para el sistema.
3. Adaptar el diseo para que sea consistente con el entorno de implementacin.

4.4-Implementacin
El objetivo principal de esta disciplina es convertir los elementos del diseo en
elementos de implementacin, dichos elementos son cdigos fuentes, ejecutables,
binarios, entre otros. Otra parte de esta disciplina son las pruebas de unidad, las
cuales se limitan a los componentes de software implementados. De esta disciplina se
obtiene un sistema ejecutable estable, constituido de los resultados producidos por los
programadores individuales.
Los objetivos especficos de la implementacin son:
1. Planificar qu subsistemas deben ser implementados y en qu orden deben ser
integrados, formando el Plan de Integracin.
2. Cada desarrollador decide en qu orden implementa los elementos del
subsistema.
3. Notificar los errores de diseo, si se encuentran.
4. Probar los subsistemas individualmente.

Pgina 9 de 19

Merinde

Brigadier Lpez

5. Integrar el sistema siguiendo el plan.

4.5-Pruebas
El principal objetivo de esta disciplina es de evaluar la calidad del producto que
se est desarrollando a travs de las diferentes fases por las cuales este pasa,
mediante la aplicacin de pruebas concretas para validar que las suposiciones hechas
en el diseo y los requerimientos se estn cumpliendo satisfactoriamente, esto quiere
decir que se verifica que el producto funcione como se dise y que los requerimientos
son satisfechos cabalmente. Esta disciplina brinda soporte para encontrar y
documentar (y solucionar) defectos en la calidad del sistema a las otras disciplinas.
Esta disciplina debe estar presente en todo el ciclo de vida del desarrollo del sistema
para ir refinndolo y no al final del mismo.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos especficos
son:
1. Encontrar y documentar defectos en la calidad del software.
2. Notificar la calidad percibida del software.
3. Proveer un medio de validacin para las suposiciones hechas en el diseo y
especificaciones de requerimientos por medio de demostraciones concretas.
4. Validar las funciones del producto de software segn lo diseado.
5. Validar que los requerimientos fueron implementados apropiadamente.
4.6-Implantacin
El objetivo principal de esta disciplina es transformar los requerimientos a una
especificacin

que

describa

cmo

implementar

el

sistema.

El

anlisis

fundamentalmente consiste en obtener una visin que se preocupa de ver que hace el
sistema de software a desarrollar, por tal motivo este se interesa en los requerimientos
funcionales. Por otro lado, el diseo es un refinamiento que toma en cuenta los
requerimientos no funcionales, por lo cual se centra en como el sistema cumple sus
objetivos.
Los objetivos especficos del anlisis y diseo son:
1. Transformar los requerimientos al diseo del futuro sistema.
2. Desarrollar una arquitectura para el sistema.
3. Adaptar el diseo para que sea consistente con el entorno de implementacin.

Pgina 10 de 19

Merinde

Brigadier Lpez

4.7-Gestin de configuracin y cambios

El objetivo de esta disciplina es mantener la integridad de todos los objetos que
se crean en el proceso y controlar los cambios. Se debe identificar elementos de
configuracin, restringir y auditar los cambios a esos elementos, y definir y dirigir la
distribucin de los mismos.
Sus objetivos especficos son:
1. Dar soporte a los mtodos de desarrollo.
2. Mantener la integridad del producto.
3. Asegurar que los productos desarrollados sean completados y corregidos
debidamente.
4. Proveer un ambiente estable durante el desarrollo del producto.
5. Restringir los cambios a los productos segn las polticas del proyecto.
6. Proveer una brecha para auditoras que permita identificar el por qu, cundo y
por quin ha sido modificado un proyecto.
7. Mantener la consistencia de los productos durante la evolucin de los mismos.
8. Proveer datos para medir el progreso.
9. Proveer los medios eficientes para adaptarse apropiadamente a los cambios y
a los replanteamientos de planes de trabajo.

4.8-Gestin del proyecto

El objetivo de la gestin del proyecto es conseguir alcanzar las metas
propuestas con el desarrollo del sistema, administrar el riesgo y superar las
restricciones para desarrollar un producto que sea acorde a los requerimientos de los
clientes y usuarios.
Los objetivos especficos de este flujo de trabajo son:
1. Proveer un marco de trabajo para la gestin de proyectos de software
intensivos.
2. Proveer guas prcticas para realizar planeacin, contratar personal, ejecutar y
monitorear el proyecto.
3. Proveer un marco de trabajo para gestionar riesgos.

Pgina 11 de 19

Merinde

Brigadier Lpez

4.9-Gestin del ambiente

La finalidad de esta disciplina es dar soporte al proyecto con los procesos,
mtodos y herramientas correctas. Ofrece una descripcin de las herramientas que se
van a necesitar para el apropiado desarrollo del software, que contendr las
herramientas de desarrollo y del proceso, plantillas, documentos, convenciones a
seguir, y cualquier otro elemento necesario para llevar adelante con xito el desarrollo
del proyecto.
En concreto los objetivos especficos de esta disciplina de trabajo incluyen:
1. Seleccionar y adquirir herramientas.
2. Establecer y configurar las herramientas para que se ajusten a la organizacin.
3. Configurar el proceso.
4. Mejorar el proceso de desarrollo.
5. Proveer los servicios tcnicos necesarios.

5-Artefactos
Es un trozo de informacin que es producido, modificado o usado durante el
proceso de desarrollo de software. Los artefactos son los resultados tangibles del
proyecto.
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

Pgina 12 de 19

Merinde

Brigadier Lpez

poseen plantillas especficas para su detalle. 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.
En la siguiente tabla se muestran los 77 artefactos:
Artefactos de Instalacin

Lista de Materiales

Calificacin de los Aspectos Tcnicos

Manual de Instalacin

de los Servicios de Desarrollo de

Manual de Usuario

Sistemas

Mapa de Navegacin

Capsula

Marco de Desarrollo

Casos de Pruebas

Material de Adiestramiento

Componente Operacional del Sistema

Matriz de Trazabilidad de Pruebas

Criterios de Aceptacin

Mecanismo de Retroalimentacin

Datos de Pruebas

Modelo de Anlisis

Documento de Arquitectura del

Modelo de Anlisis del Negocio

Negocio (DAN)

Modelo de Casos de Uso

Documento de Arquitectura del

Software (DAS) *

Modelo de Casos de Uso del Negocio

Elemento de Implementacin
Elemento de Soporte de Prueba
El Sistema *

Modelo de Datos

Entidad del Negocio

Modelo de Diseo *

Escenarios por Casos de Uso

Modelo de Diseo del Negocio

Especificacin de Migracin de Datos

Modelo de Implantacin

Especificacin de Requerimientos del

Modelo de Implantacin del Negocio

Software

Modelo de Implementacin

(ERS) *

Modelo de Servicio

Especificaciones Suplementarias

Notas de Lanzamiento

Evaluacin de la Organizacin Objetivo

Oferta de Servicio del Personal

(EOO)

Orden de Trabajo

Glosario del Sistema *

Plan de Adiestramiento

Herramientas

Plan de Gestin de Configuracin

Infraestructura de Desarrollo

Plan de Gestin de Riesgos *

Licitacin de Personal

Plan de Implantacin *

Lineamientos del Proyecto

Plan de Integracin

Lista de Ideas de las Pruebas

Plan de Iteracin

Pgina 13 de 19

Merinde

Brigadier Lpez

Plan de Pruebas *

en MeRinde existen actividades que

Planificacin del Proyecto *

se dividen en sub-actividades con el fin

Plantillas para el Proyecto

de facilitar la agrupacin de tareas

Prototipo de la Interfaz de Usuario

relacionadas.

Prueba de Concepto Arquitectnico del

Negocio
La metodologa MeRinde se organiza
en disciplinas. Las disciplinas a su vez
poseen flujos de trabajos en donde
cada uno conlleva a actividades, estas
estn compuestas por un conjunto de
tareas realizadas en un rea
determinada, las cuales tienen como
objetivo producir artefactos. A su vez,
6-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 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.

Pgina 14 de 19

Merinde

Brigadier Lpez

Pgina 15 de 19

Merinde

Brigadier Lpez

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

En la Figura los rectngulos contienen los diversos roles contemplados por la

metodologa,
comunicacin,

las
las

lneas

que

elipses

conectan

representan

el

diagrama

los

equipos

representan
y

los

lneas

fuertes

de

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.

Pgina 16 de 19

Merinde

Brigadier Lpez

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

8-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://www.merinde.net/

Pgina 17 de 19

Merinde

Brigadier Lpez

9-Conclusin
Es un proyecto que para el desarrollo de sistemas de diversas complejidades y
magnitudes facilita los flujos de trabajo, los procesos de desarrollo, modelos de
equipo, adaptacin de varias prcticas y propicia calidad al momento de desarrollar
sistemas. Busca lograr una unificacin en los modelos de todo el mundo para el
desarrollo, por lo que cuenta con un acceso gratuito ya que es de software libre.
Tambin permite ser modificado, editado y mejorado por cualquier usuario. No
exige tener mucha inversin ni en software ni en hardware, ya que con el navegador
se podr utilizar y con un equipo con recursos fsicos mnimos alcanzarn para
utilizarlo. Ayuda en la planificacin definiendo tareas y procesos, dejando en claro las
funciones de cada uno y evitando lugar a errores u omisiones. Utiliza un procedimiento
de desarrollo incremental, es decir que se van agregando ms funcionalidades al
sistema a medida que est avanza y crece.

Pgina 18 de 19

Merinde

Brigadier Lpez

10-Bibliografa:

https://es.scribd.com/doc/57861721/MeRinde-Guia
https://prezi.com/vhzwon8z3vg1/merinde/
https://prezi.com/rtdrv5sv7qp-/copy-of-merinde/
https://prezi.com/yn0waokncxag/metodologia-merinde/
http://www.monografias.com/trabajos91/fases-metodologia-merinde-ymetodologia-moomh/fases-metodologia-merinde-y-metodologia-moomh.shtml
http://articulacion.simonrodriguez.org.ve/lval/index.php/Metodologia_MeRinde.
http://es.slideshare.net/reinaldobetancourtgarcia/metodologia-merinde-y-rup
http://artmerinde.blogspot.com.ar/

Pgina 19 de 19