Metodología MeRindeEs un proyecto que propone un estándar abierto para el proceso de desarrollo de software orientado a pl...
Pretende entre sus principales objetivos apoyar a las comunidades de desarrollo de software libre en sus proyectos,suminis...
versión beta. Se hace énfasis en controlar las operaciones realizadas, administrando los recursos eficientemente, de tal f...
Metodologia RUP o Rational Unified Process (RUP)La metodología RUP, llamada así por sus siglas en inglés Rational Unified ...
Actividades: Son los procesos que se llegan a determinar en cada iteración.Trabajadores: Vienen hacer las personas o entes...
Próxima SlideShare
Cargando en…5
×

Metodologia merinde y rup

5.572 visualizaciones

Publicado el

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Metodologia merinde y rup

  1. 1. Metodología MeRindeEs un proyecto que propone un estándar abierto para el proceso de desarrollo de software orientado a planes que seestructura 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 lareingeniería de procesos del negocio. Esta metodología está fuertemente fundamentada en los requerimientos del CentroNacional de Tecnología de Información (CNTI) y en varias metodologías como el Proceso Unificado (UP) especialmente.Fase de inicioEn 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ósitoso fines principales para el ciclo de vida del producto. Durante la fase de inicio se establece el mecanismo por el cual elproducto le proveerá beneficios al usuario final o bien sea al cliente. Se describen todos los actores y casos de usos delproducto 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 eincertidumbres que pueda generar, además de su viabilidad.Fase de ElaboraciónEl propósito específico que tiene la fase de elaboración es proyectar la manera en que se va a realizar la arquitectura para elciclo 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 detodos 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 losfines 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 alproducto, de manera de saber cuáles son los requerimientos en cuanto a la realización de este, además de la evolución queeste tendrá.Fase de ConstrucciónUna vez que el equipo este en esta fase deben tener como meta o finalidad lograr la disposición o capacidad operativa delproducto, considerando que en dicho producto deben de estar incluidas todas las propiedades, elementos, requisitos y/oexigencias, las cuales previamente deben haber sido evaluadasy probadas totalmente, obteniendo de esta manera una versión del producto que sea aprobada o admisible para quien vaya ahacer 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 habersido probada toda su funcionalidad y aplicación de manera de evitar que sea pospuesta la fase de transición porincumplimiento de los criterios de esta fase.Fase de TransiciónYa en esta fase, el producto debe de estar en manos de los usuarios finales en su forma funcional, luego de que haya sidoprobado y aceptado en su totalidad por dichos usuarios, además se deberá doctrinar a los usuarios en cuanto al empleo omanipulación del sistema, y principalmente en lo que se refiere a la configuración usabilidad e instalación del producto. Esdecir, se debe avalar o confirmar que el usuario aprenda a operar el producto final, el cual debe cumplir con todos losrequerimientos 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 debeconfirmar 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 seestructura en dos dimensiones o ejes:Esfuerzo en actividades según la fase del proyectoHaz clic sobre la imagen para ver más detallesEje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las característicasdel 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 eldesarrollo de software y la reingeniería de procesos del negocio. Esta metodología está fuertemente fundamentada en losrequerimientos del Centro Nacional de Tecnología de Información (CNTI) y en varias metodologías como el ProcesoUnificado (UP) especialmente.
  2. 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 sussistemas.MeRinde es concebida para abarcar el desarrollo completo de sistemas desoftware de diversa complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse ydimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. Dada la adaptabilidad quepuede 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á basadaen componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes softwareinterconectados 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 delconocimiento entre las comunidades desarrolladoras de software libre, con lo cual no solo se pretende que sea compartidolos códigos de los sistemas sino que también se compartan la documentación como guía de referencia para mejoras porterceros 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 porel cual se descompone en el tiempo en cuatro fases secuenciales como se muestra abajo en la figura, que son: 1. Inicio2. Elaboración 3. Construcción 4. Transición Al final de cada fase el equipo gestor del proyecto realiza una evaluaciónpara 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 sedefine el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla, unplan 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 escenariosbá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 enesta fase finaliza con el establecimiento del ámbito del producto, e identificación de los principales riesgos y la viabilidaddel proyecto. Fase de Inicio e Hito en MeRindeSe recomienda utilizar dos iteraciones en esta fase. Sin embargo, algunos delos proyectos podrían requerir más o menositeraciones 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 unmodelo de la arquitectura, que se desarrolla en iteraciones sucesivas hasta obtener el producto final, este prototipo debecontener los casos de uso críticos que fueron identificados en la fase de inicio. En esta fase se realiza la captura de la mayorparte de los requerimientos funcionales, manejando los riesgos que interfieran con los objetivos del sistema, acumulando lainformación necesaria para el plan de construcción y obteniendo suficiente información para hacer realizable el caso delnegocio. Los objetivos específicos de esta fase son: 1. Definir, validar y establecer la arquitectura. 2. Completar lavisión. 3. Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debeincluir los costos si procede. 4. Demostrar que la arquitectura propuesta soportará la visión con un costo razonable y enun tiempo razonable. El hito en la fase de elaboración finaliza con la obtención de una línea base de la arquitectura delsistema, la captura de la mayoría de los requerimientos y la reducción de los riesgos importantes así como permitir laescalabilidad del equipo del proyecto durante la fase de construcción. Fase de Elaboración e Hito en MerindeSe recomiendautilizardos iteraciones en la fase de elaboración. Aunque algunos de los proyectos en esta fase podrían requerir más iteraciones paraalcanzar 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 incrementala través de las sucesivas iteraciones. En esta fase todas las características, componentes, y requerimientos deben serintegrados, implementados, y probados en su totalidad, obteniendo una versión aceptable del producto comúnmente llamada
  3. 3. versión beta. Se hace énfasis en controlar las operaciones realizadas, administrando los recursos eficientemente, de tal formaque se optimicen los costos, los calendarios y la calidad. Los objetivos específicos de esta fase son: 1. Minimizar loscostos 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 otrasversiones de prueba) tan rápido como sea práctico. El hito en esta fase culmina con el desarrollo del sistema con calidad deproducción y la preparación para la entrega al equipo de transición. Toda la funcionalidad debe haber sido implementada ylas pruebas para el estado beta de la aplicación completadas. Si el proyecto no cumple con estos criterios de cierre, entoncesla 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 vezrealizadas las pruebas de aceptación por un grupo especial de usuarios, para lo que se requerirá desarrollar nuevas versionesactualizadas del producto, entrenar a los usuarios en el manejo del sistema, completar la documentación, y en general tareasrelacionadas 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 losrequerimientos esperados. El hito en la fase de transición corresponde a haber decidido si los objetivos se cumplieron y elcomienzo 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 nuevaversión. La complejidad de esta fase depende totalmente de la naturaleza del proyecto, de su alcance y de la organización enla que deba implantarse. En esta fase se recomienda utilizar dos iteraciones para los proyectos.
  4. 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 softwarey 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 ynecesidades de cada organización.El RUP está basado en 6 principios clave que son los siguientes:Adaptar el procesoEl proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las característicaspropias del proyecto u organización.Equilibrar prioridadesLos requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debeencontrarse un equilibrio que satisfaga los deseos de todos.Demostrar valor iterativamenteLos proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de losinversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgosinvolucradosColaboración entre equiposEl desarrollo de software no lo hace una única persona sino múltiples equipos.Elevar el nivel de abstracciónEste principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcosde referencia (frameworks) por nombrar algunos.Enfocarse en la calidadEl 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 softwareVale 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 proyectoEs recomendable que a cada unade estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable alcliente. 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. 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 elanálisis como el diseño del sistema. Algunos de esos artefactos son los siguientes:Inicio: * Documento Visión * Especificación de RequisitosElaboración: * Diagramas de caso de usoConstrucció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ónVista Conceptual * Modelo de dominioVista 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 deartefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en eldesarrollo del software.La Metodología RUP es mas adaptable para proyectos de largo plazo

×