Вы находитесь на странице: 1из 21

Repblica Bolivariana de Venezuela

Ministerio del Poder Popular para la Educacin Superior


Universidad Centro-Occidental Lisandro Alvarado
Decanato de Ciencias y Tecnologa

Metodologa MeRinde

Integrantes:
Castaeda, Efren C.I. 21.506.005
Colmenarez, Carlos C.I. 23.903.914
Riera, Ana C.I. 24.399.004
Rodrguez, Isaac C.I.25.688054
Sistemas III
Seccin 1
Prof. Ana Mercedes Daz

Barquisimeto, 15 de Diciembre del 2016.


ndice
Introduccin...................................................................................................................3

Qu es Merinde?..........................................................................................................4
Catorce mejores prcticas de la Metodologa................................................................5
Estructura del Proceso Merinde.....................................................................................7
Disciplinas de la Metodologa.....................................................................................15
Conclusin...................................................................................................................21

Introduccin
La tecnologa desde sus inicios se fundament como una herramienta capaz de
agilizar actividades en la vida cotidiana. Pese a que en sus comienzos sta avanz con
pasos tmidos, durante un perodo comprendido por las dcadas de 1960 a 1970 hubo
un impulso particularmente exponencial en los avances tecnolgicos a nivel de
hardware.
Durante estas dos dcadas, los sistemas sufrieron considerables catstrofes al
momento de satisfacer las necesidades cada vez ms exigentes del mercado, trayendo
como consecuencia (gracias a las arquitecturas artesanales) retrasos en las entregas de
los proyectos, como tambin costos estimados inexactos y mantenimiento de software
difcil, casi nulo.
Debido a todo lo anterior, surge la Ingeniera del Software y consigo las
metodologas de desarrollo, las cuales se dividen actualmente en tradicionales
(caracterizndose por estar fundamentadas bajo una fuerte documentacin), giles
(siendo todo lo opuesto a las tradicionales y destacando la programacin dentro de su
esquema) y las hbridas (resultando sta el punto intermedio entre las dos anteriores,
tomando las mejores prcticas de cada una).
Entre las metodologas tradicionales se puede destacar particularmente la
metodologa MeRinde, la cual fue propuesta por el Centro Nacional de Tecnologas
de Informacin en el ao 2007 como una metodologa enfocada al desarrollo de
sistemas en Software Libre.

Qu es Merinde?
Metodologa de la red nacional de integracin y Desarrollo de Software Libre
(Merinde) 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 para el 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.
Merinde surge debido la necesidad de involucrar para el desarrollo de sus
proyectos de software equipos que hicieran uso de una metodologa y documentacin
estandarizada, buscando alcanzar una trazabilidad entre documentos y siguiendo un
mismo estndar para el proceso de desarrollo y tener varias medidas para el
aseguramiento de calidad de los sistemas; aunado a eso, tras percibir la no existencia
de un consenso en cuanto a los artefactos a desarrollar ni al contenido que cada uno
de estos debera llevar, se busc crear una metodologa capaz de subsanar la falta de
datos o redundancia de stos dentro de los artefactos con los que ya se contaban.
Merinde es una 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,
particularmente UP , OpenUP y RUP.
Es un proyecto que propone un estndar abierto para el proceso de desarrollo
de software orientado a planes que se estructuran en dos dimensiones o ejes.

Catorce mejores prcticas de la Metodologa


Esta metodologa se inspira en las catorce mejores prcticas, dirigidas a
facilitar el desarrollo colaborativo de software entre equipos de trabajo de diversa
magnitud e ndole, con el fin de que se desarrollen productos de software de alta
calidad aprovechando al mximo todos los recursos disponibles. Estas son:
-

Adaptar el proceso de desarrollo: el objetivo es mantener la agilidad durante


el proceso de desarrollo, establecer planes con representacin realista, y
estimaciones conforme a las condiciones del proyecto y durante todo el ciclo

de vida de ste.
Alto nivel de abstraccin: esta metodologa favorece los niveles altos de
abstraccin debido a que ayuda a reducir la complejidad del proyecto entre los

involucrados.
Centrarse en la arquitectura: adems de basarse en la utilizacin de los Casos
de Uso para guiar el proceso de desarrollo, presta gran parte de su atencin
hacia el establecimiento temprano de una arquitectura capaz de soportar los

cambios de futuras revisiones en la construccin y mantenimiento.


Cdigo estndar: mediante la estandarizacin del cdigo se busca lograr la

reutilizacin de componentes, permitiendo el claro entendimiento de ste.


Colaboracin entre equipo: el marco de trabajo da a la comunicacin y la
colaboracin entre los miembros del equipo de trabajo un papel fundamental,

pues propicia un ambiente de trabajo altamente productivo.


Demostrar resultados iterativamente e incrementalmente: Merinde se
encuentra compuesto por fases que estn divididas en iteraciones (repeticin
de procesos para alcanzar una meta deseada), cuyo resultado es una versin
ejecutable (hito secundario), con el cual se busca mitigar los riesgos desde los
ms altos hasta los ms bajos (donde el concepto de riesgo se refiere a ciertos

casos de uso crticos para el proyecto).


Dirigido por Casos de Uso: se utilizan debido a que son la herramienta
estndar empleada para especificar los requerimientos funcionales del sistema,

adems que guan el diseo, implementacin y pruebas de todo el sistema,


-

permitiendo una mayor trazabilidad.


Diseo simple: esta metodologa apoya que los equipos de trabajo eliminen
las complejidades innecesarias y cdigo extra, prestando un mayor nfasis en
diseo de la solucin ms simple susceptible de implementarse en el

momento.
Enfoque continuo en la calidad: contiene mecanismos para que la calidad de
todos los artefactos se evale en varios puntos durante todo el proceso de

desarrollo, especialmente al final de cada iteracin.


Enfoque en los riesgos: los riesgos son contemplados desde el inicio del
proyecto hasta el final del mismo a travs de diferentes artefactos,
permitiendo programar las actividades que deben ejecutarse durante las

iteraciones.
Fomento del aprendizaje de experiencias: a travs de retroalimentaciones se
busca el fomento del aprendizaje de las experiencias obtenidas en cada uno de

los proyectos realizados.


Interaccin continua con cliente: el cliente cumple un rol fundamental dentro
de la metodologa, llegando a ser considerado como uno de los principales
involucrados para llevar a cabo muchas de las actividades fundamentales del

proceso de desarrollo de software a lo largo de todo el ciclo de vida propuesto.


Modelar el software: el modelo es el tipo de artefacto ms primario utilizado
en la metodologa, pues cada rol necesita una perspectiva diferente del
sistema. El diseo de MeRinde permite identificar todos los roles y cada una
de las perspectivas que posiblemente podran necesitar. Las perspectivas
recogidas de todos los roles se estructuran en unidades ms grandes, es decir,
modelos, de modo que un rol pueda tomar una perspectiva concreta del

conjunto de modelos.
Permanecer gil y esperar los cambios: el cambio es un factor de riesgo crtico
en los proyectos de software, siendo tomado por la metodologa desde un
enfoque gil, buscando crear las condiciones necesarias a travs de sus

actividades para Gestinarlos lo mas tempranamente posible con su proceso


iterativo e incremental.
Estructura del Proceso Merinde
MeRinde absorbe parte de la estructura de UP, llegando a poseer dos dimensiones, las
cuales son:

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, iteraciones e hitos.


Eje vertical: representa los aspectos estticos del proceso. Describe el
proceso en trminos de componentes de proceso, disciplinas, actividades,
artefactos y roles.

Estructura Dinmica de la Metodologa


Fase de inicio: en esta se plantea la visin que tiene el equipo o desarrollador
en cuanto a lo que ser el sistema, fijndose 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.
Fase de Elaboracin: El propsito especfico que tiene 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 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.
Dicha fase 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.
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.
Fase de Transicin: el producto en esta fase 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 que 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.

Estructura Esttica de la Metodologa


El eje esttico la metodologa corresponde a los roles, las tareas, los artefactos
y a los flujos de trabajo.
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.
La cantidad de roles a utilizar para el desarrollo de un proyecto de software a
realizar con esta metodologa depende de la magnitud del proyecto y del tiempo que
se le fue asignado a ste. Mientras ms grande y complejo sea el proyecto ms
requerir de una mayor cantidad de participantes para su elaboracin y ms roles
especializados.
La metodologa del CNTI propone ocho roles bsicos que deben tomarse en
cuenta para la elaboracin de software como son:
-

Analista de Calidad: es el encargado de la revisin de todos los documentos


que reflejan el avance del proyecto (diagrama Gantt, reporte de estado, actas
de reunin, reporte de pendientes, y otras afines al control y seguimiento del
proyecto), y de verificar que los objetivos del marco de desarrollo se cumplan.
Este rol se pueden descomponer en dos sub roles: comit de direccin y

comit de seguimiento.
Analista de Producto: dirige el proceso de captura de requerimientos, define
los actores y casos de uso y estructura el modelo de casos de uso,
estableciendo la forma en que funcionar el sistema y cules son las

restricciones del mismo. Este rol se descompone en el sub rol de especificador


-

de requisitos.
Arquitecto de Software: Se encarga de la definicin de la arquitectura que
guiara el desarrollo, y de la continua refinacin de la misma en cada iteracin.
Este rol se puede descomponer en los siguientes sub roles: diseador,
diseador de base de datos, diseador de interfaz de usuario y diseador de

paquetes.
Desarrollador: tiene a su cargo la codificacin de los componentes en cdigo
fuente en algn lenguaje de alto nivel a desarrollar en la iteracin; debe
elaborar y ejecutar las pruebas unitarias realizadas sobre el cdigo
desarrollado y adems de encargarse de la solidez de la documentacin. Se

descompone en los siguientes sub roles: implementador e integrador.


Involucrado: es cualquier persona que se vea afectada por el resultado del
proyecto. Entre los sub roles que posee se encuentran: cliente, cualquier rol,

diseador grfico, documentador tcnico, usuario, entre otros.


Lder del Proyecto: es el encargado de establecer las condiciones de trabajo.
Por tal motivo tiene la funcin de dirigir y asignar recursos, coordinar las
interacciones con los clientes y usuarios finales, planificar las iteraciones y el
trabajo. Sus sub roles son: ingeniero de procesos, jefe de configuracin, jefe

de control de cambios y jefe de implantacin.


Mentor: est ntimamente ligada con el proceso de desarrollo de software, que
conoce todas las practicas involucradas y entiende el porqu de la misma. Sus
dos sub roles son: revisor y revisor tcnico.

Probador: realiza las pruebas identificadas y definidas previamente, utilizando


las instrucciones, mtodos y herramientas necesarias para este rol. Su
descomposicin en sub roles es: analista de pruebas, diseador de pruebas y
especialista en Pruebas.

10

Artefactos: son todos aquellos productos resultantes del proceso de desarrollo.


MeRinde propone setenta y seis 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.
Hay artefactos que se convierten en documentos, as mismo cuando se
desarrolla un sistema para un tercero hay artefactos que pueden ser entregados al
cliente y otros que no, esto depende fundamentalmente por el acuerdo que se realice
entre las partes.
A continuacin se presenta una tabla con los artefactos propuestos con
indicacin de necesidad:

11

12

13

Artefactos Compuestos: Los artefactos mencionados anteriormente que sern


generados y utilizados por el proyecto constituyen los entregables. Algunos artefactos
estn contenidos dentro de otros artefactos, dichos artefactos constituidos por terceros
se encuentran en la siguiente tabla:

14

Disciplinas de la Metodologa
La metodologa propuesta MeRinde se organiza en disciplinas. Las disciplinas poseen
flujos de trabajos en donde cada uno conlleva a actividades que a su vez estn
compuestos por un conjunto de tareas realizadas en un rea determinada, las cuales
tienen como objetivo producir artefactos.
Las disciplinas que conforman esta metodologa se dividirn en dos grupos. El
primero comprende las disciplinas fundamentales asociadas con las reas de
ingeniera:
-

Modelado del Negocio: con sta se pretende llegar a un mejor entendimiento


de la organizacin donde se va a implantar el sistema de software. Los
principales motivos para ejecutar esta disciplina son los siguientes: asegurarse
de que el producto ser algo til y no un obstculo y conseguir que se ajuste
de la mejor forma posible en la organizacin donde se va a implantar.

Los objetivos especficos de la disciplina modelado de negocio son:

Asegurar que clientes, usuarios finales y desarrolladores tengan un

entendimiento comn de la organizacin objetivo.


Derivar los requerimientos del sistema necesarios para apoyar a la

organizacin objetivo en su mejora.


Entender el problema actual en la organizacin objetivo e identificar

potenciales mejoras.
Entender la estructura y la dinmica de la organizacin para la cual el

sistema va a ser desarrollado (organizacin objetivo).


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 practicas de

15

licitacin a los involucrados en el proyecto, anotar y validar todas sus


solicitudes.
Los objetivos especficos de la disciplina requerimientos son:
Definir el mbito del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las

necesidades y metas del usuario.


Establecer y mantener un acuerdo entre clientes y otros involucrados

sobre lo que el sistema debera hacer.


Proveer a los desarrolladores un mejor entendimiento de los

requerimientos del sistema.


Proveer una base para estimar recursos y tiempo de desarrollo del

sistema.
Proveer una base para la planeacin de los contenidos tcnicos de las
iteraciones.

Anlisis y Diseo: El objetivo principal de esta disciplina es transformar los


requerimientos a una especificacin que describa como 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 de la disciplina anlisis y diseo son:
Adaptar el diseo para que sea consistente con el entorno de

implementacin.
Desarrollar una arquitectura para el sistema.
Transformar los requerimientos al diseo del futuro sistema.
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

16

implementados. De esta disciplina se obtiene un sistema ejecutable estable,


constituido de los resultados producidos por los programadores individuales.
Los objetivos especficos de la disciplina implementacin son:
Cada desarrollador decide en queque orden implementa los elementos

del subsistema.
Integrar el sistema siguiendo el plan.
Notificar los errores de diseo, si se encuentran.
Planificar que subsistemas deben ser implementados y en queque

orden deben ser integrados, formando el Plan de Integracin.


Probar los subsistemas individualmente.

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 diseo 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.
Los objetivos especficos de la disciplina pruebas son:
Encontrar y documentar defectos en la calidad del software.
Notificar la calidad percibida del software.
Proveer un medio de validacin para las suposiciones hechas en el
diseo

especificaciones

de

requerimientos

por

medio

de

demostraciones concretas.
Validar las funciones del producto de software segn lo diseado.
Validar que los requerimientos fueron implementados apropiadamente.
Implantacin: Esta disciplina tiene como objetivo distribuir e instalar con
xito el sistema elaborado por el equipo de desarrollo y asegurar la
disponibilidad del producto para los usuarios finales.
Sus objetivos especficos son:
17

Formar a los usuarios y al cuerpo encargado de distribuir el sistema.


Instalar el software.
Migrar el software existente.
Probar el producto en su entorno de ejecucin final.
Proveer asistencia y ayuda a los usuarios.

El segundo grupo lo integran las disciplinas llamadas de soporte o Gestin:


-

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:
Asegurar que los productos desarrollados sean completados y

corregidos debidamente.
Dar soporte a los mtodos de desarrollo.
Mantener la consistencia de los productos durante la evolucin de los

mismos.
Mantener la integridad del producto.
Proveer datos para medir el progreso.
Proveer los medios eficientes para adaptarse apropiadamente a los

cambios y a los replanteamientos de planes de trabajo.


Proveer un ambiente estable durante el desarrollo del producto.
Proveer una brecha para auditorias que permita identificar el por qu,

cundo y por quien ha sido modificado un proyecto.


Restringir los cambios a los productos segn las polticas del proyecto.
Gestin del Proyecto: El objetivo de la gestin del proyecto es conseguir
alcanzar los objetivos propuestos, 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 la disciplina Gestin del Proyecto son:
Proveer guas practicas para realizar planeacin, contratar personal,
ejecutar y monitorear el proyecto.
18

Proveer un marco de trabajo para gestionar riesgos.


Proveer un marco de trabajo para la gestin de proyectos de software

intensivos.
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, lineamientos a seguir, y cualquier otro
elemento necesario para llevar adelante con xito el desarrollo del proyecto.
En concreto los objetivos especficos de esta disciplina son:
Configurar el proceso.
Establecer y configurar las herramientas para que se ajusten a la

organizacin.
Mejorar el proceso de desarrollo.
Proveer los servicios tcnicos necesarios.
Seleccionar y adquirir herramientas.

19

Conclusin
El proceso de desarrollo MeRinde comprende una metodologa altamente sustentada,
en la cual se logran reflejar los procesos medulares de un proceso de desarrollo,
manteniendo una cualidad de esperarse por su condicin de metodologa tradicional,
la cual es la alta mantenibilidad del software gracias a la rica documentacin, adems
de ser un mtodo altamente confiable debido al resguardo que su estructura brinda
para el anlisis de riesgos. Es de apreciar las similitudes de MeRinde con la
metodologa RUP en cuanto a sus fases, sin embargo es de percatarse tambin, que
aunque MeRinde es tradicional, posee aspectos parecidos a la metodologa gil XP en
cuanto a la definicin de roles, sin dudas, MeRinde es una metodologa bastante
completa a considerar al momento del desarrollo de software, siempre y cuando luego
de un estudio pertinente se concluya que la va ms conveniente es la metodologa
tradicional.

20

21

Вам также может понравиться