Sunteți pe pagina 1din 22

MERINDE

METODOLOGIA DE LA RED NACIONAL DE


INTEGRACION Y DESARROLLO DE SOTFWARE LIBRE

INTEGRANTES:
1 CRISTIAN VIZCARDO RAMOS
2 ANTHONY APARICIO MENESES
3 LUIS JOVE ROMAN
MERINDE
• PROPUESTA METODOLÓGICA PARA ELABORAR SOFTWARE LIBRE CON EL USO
DEESTÁNDARES ABIERTOS Y CON UN ENFOQUE DE CALIDAD
• ES UN PROYECTO DE SOFTWARE LIBRE (SL) QUE PROPONE UN ESTÁNDAR PARA
ELPROCESO 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
REUTILIZABLESPARA LA INGENIERÍA DE SOFTWARE.
• ESTAS PLANTILLAS PROVEEN UN PUNTO PARTIDA PARA LOSDOCUMENTOS
UTILIZADOS EN PROYECTOS DE DESARROLLO DE SOFTWARE, CON LO QUE
PUEDENAYUDAR A LOS DESARROLLADORES A TRABAJAR MÁS RÁPIDO Y
EVITAR PASAR POR ALTO ASPECTOSIMPORTANTES DEL PROCESO
DE DESARROLLO.
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
LOSREQUERIMIENTOS DEL CENTRO NACIONAL DE TECNOLOGÍA DE
INFORMACIÓN (CNTI) Y EN VARIAS METODOLOGÍAS COMO EL PROCESO
UNIFICADO (UP) ESPECIALMENTE.
MERINDE
CARACTERISTICAS:

• ESTANDARIZACION
• FLUJOS DE TRABAJO
• PROCESOS DE DESARROLLO
• MODELO DE EQUIPO
• PROPICIA CALIDAD
• PLANTILLAS
• ADAPTACION DE VARIAS PRACTICAS
MERINDE
VENTAJAS:

• TRAZABILIDAD • PLANIFICACION
• ADAPTACION Y EXTENSION • UTILIZA UN PROCESO DE
• HABILITADOR METODOLOGICO DESARROLLO INCREMENTAL E
ITERATIVO EN EL QUE SE VAN
• HABILITADOR WEB CON FORO AGREGANDO MAS
• FORTALECIMIENTO FUNCIONALIDADES AL SISTEMA
• INTEGRACION
• REUTILIZACION
MERINDE
DESVENTAJAS

• FALTA DE PLANTILLAS
• LA METODOLOGIA PUEDE SER MUY PESADA
• NO CONTEMPLA UNA HERRAMIENTA PARA INSTANCIAR EL DESARROLLO
• POCO FACTIBLE EN UN DESARROLLO REAL CON TODAS LAS
CARACTERISTICAS DE ESTE METODO
MERINDE
FASES:

• FASE DE INICIO
• FASE DE ELABORACION
• FASE DE CONSTRUCCION
• FASE DE TRANSICION
MERINDE
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
• 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, ADEMAS DE SU VIABILIDAD
MERINDE
FASE DE ELABORACION
• PROYECTAR LA MANERA EN QUE SE VA A REALIZAR LA ARQUITECTURA PARA
EL CICLO DE VIDA DEL PRODUCTO
• SE ELABORA UNA ARQUITECTURA EN DIVERSAS INTERACCIONES HASTA
LOGRAR EL PRODUCTO DESEADO
• SEGUIR EL PATRÓN DE TODOS LOS CASOS DE USO PLANTEADOS EN LA FASE
DE INICIO
• FINALIZA ESTA FASE 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Á.
MERINDE
FASE DE CONSTRUCCION
• 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.
MERINDE
FASE DE TRANSICION
• 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, 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.
• ESTA FASE 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
MERINDE
MERINDE
VISION DINAMICA
• 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 ENCADA
FASE ES VARIABLE. EL CICLO DE VIDA DE UN PROYECTO DE SOFTWARE EN
MERINDE SE 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
MERINDE
VISION ESTATICA
• 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:
MERINDE
DISCIPLINAS:
• MODELADO DEL NEGOCIO
• REQUERIMIENTOS
• ANALISIS Y DISEÑO
• IMPLEMENTACION
• PRUEBAS
• IMPLANTACION
• DISCIPLINAS LLAMADAS DE SOPORTE O GESTION
• GESTION DE CONFIGURACION Y CAMBIOS
• GESTION DEL PROYECTO
• GESTION DEL AMBIENTE
MERINDE
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.
MERINDE
REQUERIMIENTOS
• OBJETIVOS ESPECIFICOS DE ESTA DISCIPLINA
1. DEFINIR EL AMBITO DEL SISTEMA
2. DEFINIR UNA INTERFAZ DE USUARIOS PARA EL SISTEMA, ENFOCADA A LAS
NECESIDADES Y METAS DEL USUARIO
3. ESTABLECER Y MANTENER UN ACUERDO ENTRE CLIENTES Y OTROS INVOLUCRADOS
SOBRE LO QUE EL SISTEMA DEBERIA HACER
4. PROVEER A LOS DESARROLLADORES UN MEJOR ENTENDIMIENTO DE LOS
REQUERMIENTOS DEL SISTEMA
5. PROVEER UNA BASE PARA ESTIMAR RECURSOS Y TIEMPO DE DESARROLLO DEL
SISTEMA
6. PROVEER UNA BASE PARA LA PLANEACION DE LOS CONTENIDOS TECNICOS DE LAS
ITERACIONES.
MERINDE
ANALISIS 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
MERINDE
ANALISIS Y DISEÑO
• OBJETIVOS ESPECIFICOS DE ESTA DISCIPLINA
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
IMPLEMENTACION
MERINDE
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 (77) ARTEFACTOS QUE PUEDEN SER CREADOS DURANTE
EL PROCESO DE DESARROLLO DE SOFTWARE.
MERINDE
GRACIAS

S-ar putea să vă placă și