Complejo Educativo Brigadier López
MeRinde Metodología de la Red Nacional de Integración y Desarrollo de Software Libre
Carrera: Analista De Sistemas.
Asignatura: Análisis De Sistemas.
Profesor: Emanuel Salinas.
Alumnos: Lucas Zoela, Christian Thompson.
03/05/2016
Merinde
Brigadier López
INDICE 1-MERINDE ............................................................................................................................................ 3 1.1- CARACTERÍSTICAS ................................................................................................................................... 3 1.2-VENTAJAS.............................................................................................................................................. 3 1.3-DESVENTAJAS......................................................................................................................................... 4 2-FASES .................................................................................................................................................. 4 2.1-FASE DE INICIO ....................................................................................................................................... 4 2.2-FASE DE ELABORACIÓN ............................................................................................................................ 4 2.3-FASE DE CONSTRUCCIÓN .......................................................................................................................... 5 2.4-FASE DE TRANSICIÓN ............................................................................................................................... 5 3-ESTRUCTURA DEL PROCESO DE MERINDE ........................................................................................... 6 3.1-VISIÓN DINÁMICA DE MERINDE ................................................................................................................. 6 3.2-VISIÓN ESTÁTICA DE MERINDE .................................................................................................................. 7 4-DISCIPLINAS ........................................................................................................................................ 7 4.1-MOLDEADO DEL NEGOCIO ........................................................................................................................ 8 4.2-REQUERIMIENTOS ................................................................................................................................... 8 4.3-ANÁLISIS Y DISEÑO .................................................................................................................................. 9 4.4-IMPLEMENTACIÓN................................................................................................................................... 9 4.5-PRUEBAS ............................................................................................................................................. 10 4.6-IMPLANTACIÓN..................................................................................................................................... 10 4.7-GESTIÓN DE CONFIGURACIÓN Y CAMBIOS................................................................................................... 11 4.8-GESTIÓN DEL PROYECTO ......................................................................................................................... 11 4.9-GESTIÓN DEL AMBIENTE ......................................................................................................................... 12 5-ARTEFACTOS ..................................................................................................................................... 12 6-ROLES ............................................................................................................................................... 14 7-EL MODELO DE EQUIPO PARA PROYECTOS ....................................................................................... 16 8-HABILITADOR WEB ........................................................................................................................... 17 9-CONCLUSIÓN .................................................................................................................................... 18 10-BIBLIOGRAFÍA: ................................................................................................................................ 19
Página 2 de 19
Merinde
Brigadier López
1-MeRinde Metodología de la Red Nacional de Integración y Desarrollo de Software Libre (MeRinde) Una Propuesta Metodológica para Elaborar Software Libre con el Uso de Estándares Abiertos y con un Enfoque de Calidad. Es un proyecto de Software Libre (SL) que propone un estándar para el proceso de desarrollo de software que puede ser empleado y adaptado según los requerimientos de cualquier comunidad u organización, con la finalidad del desarrollo de sistemas y además para producir y mantener una librería de plantillas reutilizables para la ingeniería 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 más rápido 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 documentación de sus sistemas. La Metodología MeRinde surge de la combinación y adaptación de modelos y metodologías ampliamente utilizadas para el desarrollo de software y la reingeniería de procesos del negocio. Esta metodología está fuertemente fundamentada en los requerimientos del Centro Nacional de Tecnología de Información (CNTI) y en varias metodologías 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 documentación de sus sistemas. 1.1- Características Estandarización
Flujos de trabajo
Proceso de desarrollo
Modelo de equipo
Propicia calidad
Plantillas de los artefactos
Adaptación de varias practicas
1.2-Ventajas Trazabilidad
Página 3 de 19
Merinde
Brigadier López
Adaptación y extensión
Habilitador metodológico
Habilitador Web con Foro
Fortalecimiento
Integración
Reutilización
Planificación
Utiliza un procedimiento de desarrollo incremental e iterativo en el que se van agregando más funcionalidades al sistema
1.3-Desventajas Falta de plantillas
La metodología puede muy pesada
No contempla una herramienta para instanciar el desarrollo
Poco factible en un desarrollo real con todas las características de este método
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 visión que tiene el equipo o desarrollador en cuanto a lo que será el sistema, se fijan los propósitos 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 además 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, además de su viabilidad.
2.2-Fase de Elaboración El propósito específico que tiene la fase de elaboración es proyectar la manera en que se va a realizar la arquitectura para el ciclo de vida del producto, es decir, para su evolución durante su uso o bien sea su permanencia en cuanto a funcionamiento, se elabora una arquitectura en diversas interacciones hasta lograr el producto
Página 4 de 19
Merinde
Brigadier López
deseado. Esta fase debe seguir el patrón de todos los casos de uso planteados en la fase de inicio. Además se deben considerar la mayoría 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 cuestión. La fase de elaboración concluye cuando el equipo del proyecto tiene en claro los riesgos principales que puedan afectar al producto, de manera de saber cuáles son los requerimientos en cuanto a la realización de este, además de la evolución que este tendrá.
2.3-Fase de Construcción Una vez que el equipo este en esta fase deben tener como meta o finalidad lograr la disposición 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 versión del producto que sea aprobada o admisible para quien vaya a hacer uso de esta. En conclusión, el objetivo de esta fase es el desarrollo total del sistema ya preparado para la fase de transición, debe haber sido probada toda su funcionalidad y aplicación de manera de evitar que sea pospuesta la fase de transición por incumplimiento de los criterios de esta fase.
2.4-Fase de Transición 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, además se deberá doctrinar a los usuarios en cuanto al empleo o manipulación del sistema, y principalmente en lo que se refiere a la configuración usabilidad e instalación 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 realización del mismo. En resumen, en esta fase se debe determinar si todos los propósitos en cuanto al proyecto fueron logrados, además se debe confirmar que el cliente haya aceptado, observado y verificado el producto final que le fue proporcionado.
Página 5 de 19
Merinde
Brigadier López
3-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. 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.
3.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
Página 6 de 19
Merinde
Brigadier López
inspira en UP, motivo por el cual se descompone en el tiempo en cuatro fases secuenciales 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.
3.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 siguiente figura:
4-Disciplinas
Modelado del Negocio
Requerimientos
Análisis y Diseño
Página 7 de 19
Merinde
Implementación
Pruebas
Implantación
Disciplinas llamadas de soporte o gestión:
Gestión de Configuración y Cambios
Gestión del Proyecto
Gestión del Ambiente
Brigadier López
4.1-Moldeado del negocio Con esta disciplina se pretende llegar a un mejor entendimiento de la organización donde se va a implantar el sistema de software. Los objetivos específicos del modelado de negocio son: 1. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo. 2. Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora. 3. Entender el problema actual en la organización objetivo e identificar potenciales mejoras. 4. Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización 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 línea 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 prácticas de licitación a los involucrados en el proyecto, anotar y validar todas sus solicitudes. Los objetivos específicos 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.
Página 8 de 19
Merinde
Brigadier López
3. Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo que el sistema debería 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 planeación de los contenidos técnicos de las iteraciones. 4.3-Análisis y diseño El objetivo principal de esta disciplina es transformar los requerimientos a una especificación
que
describa
cómo
implementar
el
sistema.
El
análisis
fundamentalmente consiste en obtener una visión 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 diseño 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 específicos del análisis y diseño son: 1. Transformar los requerimientos al diseño del futuro sistema. 2. Desarrollar una arquitectura para el sistema. 3. Adaptar el diseño para que sea consistente con el entorno de implementación.
4.4-Implementación El objetivo principal de esta disciplina es convertir los elementos del diseño en elementos de implementación, dichos elementos son códigos 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 específicos de la implementación son: 1. Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración. 2. Cada desarrollador decide en qué orden implementa los elementos del subsistema. 3. Notificar los errores de diseño, si se encuentran. 4. Probar los subsistemas individualmente.
Página 9 de 19
Merinde
Brigadier López
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 través de las diferentes fases por las cuales este pasa, mediante la aplicación de pruebas concretas para validar que las suposiciones hechas en el diseño y los requerimientos se estén 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 refinándolo y no al final del mismo. Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos específicos son: 1. Encontrar y documentar defectos en la calidad del software. 2. Notificar la calidad percibida del software. 3. Proveer un medio de validación para las suposiciones hechas en el diseño y especificaciones de requerimientos por medio de demostraciones concretas. 4. Validar las funciones del producto de software según lo diseñado. 5. Validar que los requerimientos fueron implementados apropiadamente. 4.6-Implantación El objetivo principal de esta disciplina es transformar los requerimientos a una especificación
que
describa
cómo
implementar
el
sistema.
El
análisis
fundamentalmente consiste en obtener una visión 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 diseño 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 específicos del análisis y diseño son: 1. Transformar los requerimientos al diseño del futuro sistema. 2. Desarrollar una arquitectura para el sistema. 3. Adaptar el diseño para que sea consistente con el entorno de implementación.
Página 10 de 19
Merinde
Brigadier López
4.7-Gestión de configuración 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 configuración, restringir y auditar los cambios a esos elementos, y definir y dirigir la distribución de los mismos. Sus objetivos específicos son: 1. Dar soporte a los métodos 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 según las políticas del proyecto. 6. Proveer una brecha para auditorías que permita identificar el por qué, cuándo y por quién ha sido modificado un proyecto. 7. Mantener la consistencia de los productos durante la evolución 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-Gestión del proyecto El objetivo de la gestión 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 específicos de este flujo de trabajo son: 1. Proveer un marco de trabajo para la gestión de proyectos de software intensivos. 2. Proveer guías prácticas para realizar planeación, contratar personal, ejecutar y monitorear el proyecto. 3. Proveer un marco de trabajo para gestionar riesgos.
Página 11 de 19
Merinde
Brigadier López
4.9-Gestión del ambiente La finalidad de esta disciplina es dar soporte al proyecto con los procesos, métodos y herramientas correctas. Ofrece una descripción 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 específicos de esta disciplina de trabajo incluyen: 1. Seleccionar y adquirir herramientas. 2. Establecer y configurar las herramientas para que se ajusten a la organización. 3. Configurar el proceso. 4. Mejorar el proceso de desarrollo. 5. Proveer los servicios técnicos necesarios.
5-Artefactos Es un trozo de información 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 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
Página 12 de 19
Merinde
Brigadier López
poseen plantillas específicas para su detalle. 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. En la siguiente tabla se muestran los 77 artefactos: Artefactos de Instalación
Lista de Materiales
Calificación de los Aspectos Técnicos
Manual de Instalación
de los Servicios de Desarrollo de
Manual de Usuario
Sistemas
Mapa de Navegación
Capsula
Marco de Desarrollo
Casos de Pruebas
Material de Adiestramiento
Componente Operacional del Sistema
Matriz de Trazabilidad de Pruebas
Criterios de Aceptación
Mecanismo de Retroalimentación
Datos de Pruebas
Modelo de Análisis
Documento de Arquitectura del
Modelo de Análisis del Negocio
Negocio (DAN)
Modelo de Casos de Uso
Documento de Arquitectura del Software (DAS) *
Modelo de Casos de Uso del Negocio
Elemento de Implementación Elemento de Soporte de Prueba El Sistema *
Modelo de Datos
Entidad del Negocio
Modelo de Diseño *
Escenarios por Casos de Uso
Modelo de Diseño del Negocio
Especificación de Migración de Datos
Modelo de Implantación
Especificación de Requerimientos del
Modelo de Implantación del Negocio
Software
Modelo de Implementación
(ERS) *
Modelo de Servicio
Especificaciones Suplementarias
Notas de Lanzamiento
Evaluación de la Organización Objetivo
Oferta de Servicio del Personal
(EOO)
Orden de Trabajo
Glosario del Sistema *
Plan de Adiestramiento
Herramientas
Plan de Gestión de Configuración
Infraestructura de Desarrollo
Plan de Gestión de Riesgos *
Licitación de Personal
Plan de Implantación *
Lineamientos del Proyecto
Plan de Integración
Lista de Ideas de las Pruebas
Plan de Iteración
Página 13 de 19
Merinde
Brigadier López
Plan de Pruebas *
en MeRinde existen actividades que
Planificación del Proyecto *
se dividen en sub-actividades con el fin
Plantillas para el Proyecto
de facilitar la agrupación de tareas
Prototipo de la Interfaz de Usuario
relacionadas.
Prueba de Concepto Arquitectónico del Negocio La metodología MeRinde se organiza en disciplinas. Las disciplinas a su vez poseen flujos de trabajos en donde cada uno conlleva a actividades, estas están 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 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 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.
Página 14 de 19
Merinde
Brigadier López
Página 15 de 19
Merinde
Brigadier López
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 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.
En la Figura los rectángulos contienen los diversos roles contemplados por la metodología, comunicación,
las las
líneas
que
elipses
conectan
representan
el
diagrama
los
equipos
representan y
los
líneas
fuertes
de
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.
Página 16 de 19
Merinde
Brigadier López
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 específicas 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.
8-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://www.merinde.net/
Página 17 de 19
Merinde
Brigadier López
9-Conclusión 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, adaptación de varias prácticas y propicia calidad al momento de desarrollar sistemas. Busca lograr una unificación en los modelos de todo el mundo para el desarrollo, por lo que cuenta con un acceso gratuito ya que es de software libre. También permite ser modificado, editado y mejorado por cualquier usuario. No exige tener mucha inversión ni en software ni en hardware, ya que con el navegador se podrá utilizar y con un equipo con recursos físicos mínimos alcanzarán para utilizarlo. Ayuda en la planificación 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 más funcionalidades al sistema a medida que esté avanza y crece.
Página 18 de 19
Merinde
Brigadier López
10-Bibliografía:
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/
Página 19 de 19
