Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Merinde

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 6

¿Qué es Merinde?

Es una metodología de la Red Nacional de Integración y Desarrollo de Software Libre.

MeRinde 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 para el 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 SL en sus proyectos, suministrando las herramientas necesarias para que estos cumplan con un
proceso de desarrollo y documentación de sus sistemas.

Nace por:

 Falta de una metodología estándar.


 Redundancia o ausencia de datos en artefactos.
 Limitación de paquete de Software dado el costo y el diseño de tercero.

Fue creado por:

 Ministerio del Poder Popular para las Telecomunicaciones y la Informática (MPPTI) de la República Bolivariana
de Venezuela.
 Centro Nacional de Tecnología de Informática (CNTI).

Mejores practica de implementación

 Adapta el proceso de desarrollo.


 Código estándar.
 Dirigido por caso de uso.
 Mostrar resultados interactivamente e incrementalmente.
 Diseño simple.
 Enfoque continuo en la calidad.
 Colaboraciones entres equipos.
 Enfoque en los Riesgos.
 Interacción continua con el cliente
 Centrarse en la arquitectura.

Fundamentos de Merinde

 Requerimiento del Centro Nacional de Tecnología de Informática (CNTI).


 Influencia de metodología como Proceso Unificado (UP), Open UP.
 Las fases de Hitos de los aspectos dinámicos son UP y las diciplinas que corresponde a los aspectos estáticos se
fundamentar de UP, Open UP y RUP.
 Los flujos de trabajo de cada disciplina están inspirados en RUP.
 Los procesos de desarrollo corresponden a CNTI.
 Los roles están inspirados en MSF, las actividades en RUP, UP, Open UP y los artefactos están basados en los de
readyset, UP y Artefactos existente en la organización.
Estructura de proceso Merinde

EJE HORIZONTAL

 Representación de tiempo.
 Eje dinámico.
 Indica las características del ciclo d vida del proceso expresado en términos de fases, iteraciones e hitos.

EJE VERTICAL

 Eje estático
 Describe el proceso y términos de componentes de procesos, actividades, artefactos y roles.

EJE DINAMICO

Esta compuesto por 4 fases:

INICIO

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.
 Establecer los objetivos para el ciclo de vida del proyecto.
 Establecer el ámbito del proyecto y su límite.
 Encontrar los casos de usos crítico del sistema.
 Estimar tiempo, recurso y tiempo.
 El hito esta fase finalizar con el establecimiento de ámbito del producto e identificación de los principales riesgos
y la viabilidad del proyecto.

ELABORACION

En esta 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.
 Plantear la arquitectura para el ciclo de vida del proyecto.
 Definir, validar y establecer la arquitectura.
 Demostrar que la arquitectura propuesta soporta la versión con un costo y tiempo factible.
 El hito finalizar con la obtención de una línea base de la arquitectura, captura de la mayoría de los requisitos,
reducción de riesgos y escalabilidad.

CONTRUCCION

Esta fase debe 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.
 Alcanzar la capacidad operacional del proyecto.
 Evitar rehacer o deshacer de trabajos ya hechos.
 Conseguir una calidad adecuada tan rápido como sea practico.
 Conseguir versiones funcionales lo más rápido posible.
 El hito culminar con el desarrollo del sistema con calidad.

TRANSICION

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.
 Entregar el proyecto funcional en menos de los usuarios finales, una vez realizada las pruebas.
 Caracterizar que el usuario aprenda a operar y mantener el sistema.
 Conseguir un producto final que cumpla con los esperados.
 El hito termina al decir si los objetivos se cumplieron y comenzar de otros ciclos de desarrollos. El cliente debe
haber revisado y aceptado los artefactos que se entregaron.

EJE ESTATICO

ROLES

Se define responsabilidades de un individuo o de un grupo de individuos trabajando en equipos.

Los roles serán agregados por participación en actividades relacionadas.

ROLES BASICOS

 Analista de calidad.
 revisar toda la documentación de avance
 comité de dirección.
 Comité de seguimiento.
 Analista de paquetes.
 Dirigir, definir y estructurar.
 Especificador de requerimientos.

 Arquitecto de software.
 Definir de la arquitectura que guiara el desarrollo.
 Diseñador.
 Diseñador de base de datos.
 Diseñador de interfaz de usuario.
 Diseñador de paquete.

ROLES

 Desarrollador.
 Codificar los componentes en código fuente en algunos lenguajes de alto nivel.
 Implementador.
 Integrador.

 Involucrados.
 Personas o grupos de personas afectados por el resultado del proyecto.
 Cliente.
 Usuario.
 Otro rol.

 Líder del proyecto.


 Establecer las condiciones de trabajo.
 Jefe de diciplina.
 Ingeniero de proceso.

 Motor.
 Ligado con el proceso de desarrollo de software. Conocer todas las practicas.
 Revisor.

 Probador.
 Realizar las pruebas identificadas y definidas previamente.
 Analista de pruebas.
 Diseñador de pruebas.
 Especialista de pruebas.

Actividades

Conjunto de acciones que se llevan acabo para cumplir los objetivos de desarrollo.

Tarea

Trabajo que debe hacerse en tiempo limitado; parte de una actividad.

¿Quien? (Roles)

¿Como? (Tarea)

¿Que? (Artefacto)

¿Cuándo?

(Flujo de trabajo) (Actividades) (Sub Actividades)


Artefactos

Artefactos Compuestos
Artefacto Contenedor Artefactos Contenidos
Lista de materiales
El Sistema Artefactos de instalación
Unidad de implementación
Modelo de caso de uso
Especificación de requerimientos del Especificaciones implementarías
Software (ERS)
Infraestructura de Desarrollo Herramientas
Marco de Desarrollo Lineamiento de Proyecto
Entidad de negocio
Modelo de Analista del Negocio Trabajador de negocio
Reglas del negocio
Capsula
Modelo de diseño Realización de caso de uso
Entidad del negocio
Realización de los casos de uso del negocio
Modelo de diseño del negocio
Trabajador de negocio
Elemento de implementación
Modelo de implementación Subsistema de implementación
Elemento de soporte de prueba
Casos de pruebas
Criterio de aceptación
Datos de pruebas
Plan de prueba Escenario por caso de uso
Lista de ideas de las pruebas
Resumen del ciclo de prueba

Disciplinas fundamentales

 Modelado del negocio


 Mejorar entendimiento de la organización.
 Requisitos.
 Analizar los especificadores para describir como implementar el sistema.
 Analista de diseño.
 Convertir los elementos del diseño en elementos de implementación como código fuente, ejecutable,
binario entre otros.
 Implementación
 Evaluar la calidad del proyecto que se esté desarrollando a través de diferentes fases por las cuales este
pasa.
 Prueba
 Distribuir e instalar con éxito el sistema elaborado por el equipo de desarrollo y asegurar la
disponibilidad del producto para los usuarios finales.
 Implementación.
 Mantener la integridad de todos los objetos que se crean el proceso y controlar los cambios.

Disciplina de soporte

 Gestión de configuración y cambio.


 Mantener la integridad de todos los objetos que crean e el proceso y controlar los cambios.
 Gestión de proyecto.
 Conseguir alcanzar los objetivos propuesto, administrar el riesgo y superar las restricciones.
 Gestión de Ambiente
 Dar soporte al proyecto con los procesos, método y herramientas correctas.

También podría gustarte