1. Metodología MeRinde
Es un proyecto que propone un estándar abierto para el proceso de desarrollo de software orientado a planes que se
estructura en dos dimensiones o ejes.
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.
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.
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 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á.
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.
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.
Metodología de la Red Nacional de Integración y Desarrollo de Software Libre
(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 dos dimensiones o ejes:
Esfuerzo en actividades según la fase del proyecto
Haz clic sobre la imagen para ver más detalles
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, iteraciones e hitos.
Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso,
disciplinas, actividades, artefactos y roles.
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.

2. 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.
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 versión,
pero no se descarta su empleo.
Así mismo, esta permite producir y mantener una librería de plantillas reutilizables para ingeniería de software. Está basada
en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software
interconectados a través de interfaces bien definidas. Además, la metodología utiliza el Lenguaje Unificado de Modelado
(Unified Modeling Language, UML) para preparar todos los diagramas de un sistema software.
Con el proceso de desarrollo y con las plantillas de esta metodología se busca a su vez estimular con la transferencia del
conocimiento entre las comunidades desarrolladoras de software libre, con lo cual no solo se pretende que sea compartido
los códigos de los sistemas sino que también se compartan la documentación como guía de referencia para mejoras por
terceros al sistema o para que sirva como modelo a otras comunidades para el desarrollo de sus propios sistemas.
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: 1. Inicio
2. Elaboración 3. Construcción 4. 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. Fases e Hitos Encontrados en MeRinde |
Fase de Inicio | | |
Su propósito general es establecer los objetivos para el ciclo de vida del producto (ver figura de abajo). Durante esta fase se
define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla, un
plan de negocio para determinar qué recursos deben ser asignados al proyecto. Los objetivos específicos de esta fase son:
1. Establecer el ámbito del proyecto y sus límites. 2. Encontrar los casos de uso críticos del sistema, los escenarios
básicos que definen la funcionalidad. 3. Mostrar al menos una arquitectura candidata para los escenarios principales. 4.
Estimar el costo en recursos y tiempo de todo el proyecto. 5. Estimar los riesgos, las fuentes de incertidumbre. El hito en
esta fase finaliza con el establecimiento del ámbito del producto, e identificación de los principales riesgos y la viabilidad
del proyecto. Fase de Inicio e Hito en MeRindeSe recomienda utilizar dos iteraciones en esta fase. Sin embargo, algunos de
los proyectos podrían requerir más o menos
iteraciones para alcanzar su objetivo. |
Fase de Elaboración | | |
Su objetivo general es plantear la arquitectura para el ciclo de vida del producto (ver figura de abajo). Se construye un
modelo de la arquitectura, que se desarrolla en iteraciones sucesivas hasta obtener el producto final, este prototipo debe
contener los casos de uso críticos que fueron identificados en la fase de inicio. En esta fase se realiza la captura de la mayor
parte de los requerimientos funcionales, manejando los riesgos que interfieran con los objetivos del sistema, acumulando la
información necesaria para el plan de construcción y obteniendo suficiente información para hacer realizable el caso del
negocio. Los objetivos específicos de esta fase son: 1. Definir, validar y establecer la arquitectura. 2. Completar la
visión. 3. Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe
incluir los costos si procede. 4. Demostrar que la arquitectura propuesta soportará la visión con un costo razonable y en
un tiempo razonable. El hito en la fase de elaboración finaliza con la obtención de una línea base de la arquitectura del
sistema, la captura de la mayoría de los requerimientos y la reducción de los riesgos importantes así como permitir la
escalabilidad del equipo del proyecto durante la fase de construcción. Fase de Elaboración e Hito en MerindeSe recomienda
utilizar
dos iteraciones en la fase de elaboración. Aunque algunos de los proyectos en esta fase podrían requerir más iteraciones para
alcanzar su objetivo. |
Fase de Construcción | | |
El objetivo general de esta fase es alcanzar la capacidad operacional del producto (ver figura de abajo) de forma incremental
a través de las sucesivas iteraciones. En esta fase todas las características, componentes, y requerimientos deben ser
integrados, implementados, y probados en su totalidad, obteniendo una versión aceptable del producto comúnmente llamada

3. versión beta. Se hace énfasis en controlar las operaciones realizadas, administrando los recursos eficientemente, de tal forma
que se optimicen los costos, los calendarios y la calidad. Los objetivos específicos de esta fase son: 1. Minimizar los
costos de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.
2. Conseguir una calidad adecuada tan rápido como sea práctico. 3. Conseguir versiones funcionales (alfa, beta, y otras
versiones de prueba) tan rápido como sea práctico. El hito en esta fase culmina con el desarrollo del sistema con calidad de
producción y la preparación para la entrega al equipo de transición. Toda la funcionalidad debe haber sido implementada y
las pruebas para el estado beta de la aplicación completadas. Si el proyecto no cumple con estos criterios de cierre, entonces
la transición deberá
posponerse una iteración. Fase de Construcción e Hito en MeRindePara esta fase se recomienda realizar tres iteraciones.
Tomando en cuenta las dimensiones de algunos proyectos el número de iteraciones puede variar. |
Fase de Transición | | |
Tiene como objetivo general entregar el producto funcional (ver figura de abajo) en manos de los usuarios finales una vez
realizadas las pruebas de aceptación por un grupo especial de usuarios, para lo que se requerirá desarrollar nuevas versiones
actualizadas del producto, entrenar a los usuarios en el manejo del sistema, completar la documentación, y en general tareas
relacionadas con la configuración, instalación y usabilidad del producto. Los objetivos específicos de esta fase son: 1.
Garantizar que el usuario aprenda a operar y mantener el sistema. 2. Conseguir un producto final que cumpla los
requerimientos esperados. El hito en la fase de transición corresponde a haber decidido si los objetivos se cumplieron y el
comienzo de otro ciclo de desarrollo. El cliente debe haber revisado y aceptado los artefactos que le han sido entregado.
Fase de Transición e Hito en MeRindeLas iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva
versión. La complejidad de esta fase depende totalmente de la naturaleza del proyecto, de su alcance y de la organización en
la que deba implantarse. En esta fase se recomienda utilizar dos iteraciones para los proyectos.

4. Metodologia RUP o Rational Unified Process (RUP)
La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, es un proceso de desarrollo de software
y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y
necesidades de cada organización.
El RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características
propias del proyecto u organización.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe
encontrarse un equilibrio que satisfaga los deseos de todos.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los
inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos
involucrados
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos
de referencia (frameworks) por nombrar algunos.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción.
PRINCIPALES CARACTERISTICAS
* Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
* Pretende implementar las mejores prácticas en Ingeniería de Software
* Desarrollo iterativo
* Administración de requisitos
* Uso de arquitectura basada en componentes
* Control de cambios
* Modelado visual del software
* Verificación de la calidad del software
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas:
Disciplina de Desarrollo Y Disciplina de de Soporte.
Disciplina de Desarrollo.
- Ingeniería de Negocios: Entendiendo las necesidades del negocio.
- Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
- Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.
- Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.
- Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado esta presente.
Disciplina de Soporte:
- Configuración y administración del cambio: Guardando todas las versiones del proyecto.
- Administrando el proyecto: Administrando horarios y recursos.
- Ambiente: Administrando el ambiente de desarrollo.
- Distribución: Hacer todo lo necesario para la salida del proyecto
Es recomendable que a cada una
de estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable al
cliente. Esto trae como beneficio la retroalimentación que se tendría en cada entregable o en cada iteración.
Los elementos del RUP son:

5. Actividades: Son los procesos que se llegan a determinar en cada iteración.
Trabajadores: Vienen hacer las personas o entes involucrados en cada proceso.
Artefactos: Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
ARTEFACTOS: RUP en cada una de sus fases realiza una serie de artefactos que sirven para comprender mejor tanto el
análisis como el diseño del sistema. Algunos de esos artefactos son los siguientes:
Inicio:
* Documento Visión
* Especificación de Requisitos
Elaboración:
* Diagramas de caso de uso
Construcción:
* Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica
* Diagrama de clases
* Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación
* Diagrama de Secuencia
* Diagrama de estados
* Diagrama de Colaboración
Vista Conceptual
* Modelo de dominio
Vista física
* Mapa de comportamiento a nivel de hardware.
CONCLUSION:
Al estudiar y analizar esta metodología me he dado cuenta que en cada ciclo de iteración se hace exigente el uso de
artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el
desarrollo del software.
La Metodología RUP es mas adaptable para proyectos de largo plazo