Introducción
La Creciente complejidad del mundo actual y por ende de las situaciones de diseño que enfrentan los diseñadores requieren de la aplicación de herramientas y/o instrumentos flexibles que, a modo de guías simplifiquen o allanen el camino a seguir en búsqueda de la solución de los problemas de diseño. A continuación le hablaremos de una herramienta llamada Metodología MeRinde, la cual se especifica para la creación de Sistema.
En el mundo actual la creación de páginas web o multimedia es algo que ha llegado a convertirse de mucha ayuda no solo para los estudiantes sino para la comunidad en general. Para la creación de estas páginas al igual que un proyecto en particular, se necesitan una serie de pasos o normas para lograr la realización absoluta. A continuación le hablaremos de la Metodología Moomh, instrumento para la creación de multimedias.
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 pantea 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 Moomh
MOOMH está subdividida en cuatro (4) modelos: requerimientos, análisis, diseño e implementación, pretendiéndose desarrollar una metodología multimedial/hipermedial, que permita las herramientas necesarias para el desarrollo de aplicaciones educativas de escritorio y para la Web. Es importante destacar que cada uno de estos modelos están interrelacionados, permitiendo que el mismo sea iterativo entre cada una de sus fases, por lo tanto existe interacción entre ellos.
Modelo de Requerimientos
La base central de MOOMH radica en el modelo de requerimientos, ya que debe diferenciarse, estrictamente, hacia quién va dirigido el software que se pretende desarrollar; en estos momentos hablamos de autoría del software: Educativo o Informativo.
Cuando el software es netamente educativo, refiriéndonos particularmente a un(os) objetivo(s) específico(s) del contenido programático de un curso en particular, se debe cumplir con una serie de especificaciones involucradas en el proceso de enseñanza y aprendizaje. Es en este momento cuando nos involucramos con la enseñanza asistida por el computador (E.A.C) o por el ordenador (E.A.O).
En el caso de la enseñanza asistida por computador, el actor principal puede ser el aprendiz o el docente (dependiendo de la aplicación).
En lo que respecta al informativo, el actor principal puede ser cualquier usuario interesado en el tema.
La E.A.C comprende todas las aplicaciones que utilizan al computador en el ámbito educativo, a saber: enseñanza, gestión y administración escolar, evaluación y corrección de pruebas, orientación escolar e investigación pedagógica, entre otras.
En el caso de un software multimedia informativo, podríamos hacer referencia a un libro electrónico, un atlas, diccionarios, folletos, revistas, entre otros. Con un software de este tipo, el usuario podría educarse obteniendo información particular del contenido del software que utilice, con la salvedad de que éste no cumple con el contenido programático de un curso específico.
Modelo de Análisis
Una vez determinado el problema y analizada las tareas de los diferentes usuarios, se procede a modelar el análisis. El modelo de análisis está compuesto de las fases siguientes:
Identificación de los objetos.
Elaboración del mapa de navegación del sistema.
Diseño de los objetos.
Identificación de los objetivos
Esta etapa define los objetos y la relación existente entre ellos, Dichas relaciones representan los links, hipervínculos o ramificaciones hacia otras lecciones, unidades de información o bloques administrativos es imprescindible definir los objetos claramente. Estos objetos, no son más que las posibles ventanas o metáforas que en un primer momento de diseño tendrá la aplicación.
Elaboración del mapa de navegación del sistema
Un grafo de navegación, es donde estarán representadas todas las lecciones, unidades de información o bloques administrativos, según sea el caso. Este grafo representará el prototipo del sistema a desarrollar, representado a través de nodos (objetos) y las asociaciones o enlaces
Diseño de los objetos
En esta fase se representa de una manera sencilla las lecciones, unidades de información o bloques administrativos, especificando un lenguaje de diseño para el mismo.
El lenguaje de diseño que se desprende para cada uno de los prototipos (inicialmente recomendado en papel) es representado bajo un lenguaje formal.
Modelo de Diseño
El modelo de diseño permite refinar el primer intento de prototipaje (prototipo de baja fidelidad), logrado en las primeras etapas de desarrollo. Además es el modelo que permite internarse lógicamente en los aspectos computacionales, que tienen que ver con el almacenamiento de los objetos generados en el modelo de análisis
Este modelo queda comprendido en tres 3 pasos:
Prototipo de la Interfaz
Diseño de la Base de Datos
Modelado en la Web
Prototipo de la interfaz
Muestra a los posibles usuarios finales del sistema un prototipo de las potenciales pantallas del mismo o simplemente un prototipaje en papel, a través de las respectivas metáforas (globales, visuales, entre otros), icono, botones. Permitiendo minimizar considerablemente la carga cognitiva de los mismos.
Diseño de la base de datos
Para el diseño de la base de datos se emplea el Diagrama de Clases. En el diagrama de clases se define las características de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalización. Estos diagramas también se pueden utilizar para mostrar subsistemas e interfaces.
Modelado en la web
Si la aplicación a desarrollar es en ambiente Web (aula virtual, sitio web de asignatura, entre otras), se podrá hacer uso de la extensión de la notación de Lenguaje de Modelado Unificado (Unified Modeling Lenguaje – UML), Los componentes que integran una aplicación web, como páginas, hipervínculos, y el contenido dinámico de la aplicación (scripts por ejemplo), pueden ser modelados por medio de extensiones de UML para este tipo de sistemas.
Modelo de Implementación
En este modelo se procede a seleccionar los recursos computacionales necesarios para programar el sistema, se debe hacer una evaluación exhaustiva con el personal que colaboró en los modelos anteriores y se debe elaborar el manual del programador o manual del sistema respectivo. Este modelo consta de las siguientes fases:
Arquitectura o Capas OSI
Pruebas del sistema
Arquitectura o Capas OSI
Permitirá mayor versatilidad e independencia en el proceso de las operaciones del sistema. En el caso de una arquitectura de tres (3) capas, el nivel de almacenamiento (conformado por Manejador de Base de Datos), nivel lógico (conformado por el servidor de aplicaciones o reglas del negocio) y el nivel de presentación (conformado por la Interfaz del usuario). Debe verificarse bajo que arquitectura o capas OSI será implementada la aplicación que se está desarrollando
Pruebas del sistema
Finalmente en este modelo, deben efectuarse las pruebas respectivas (generalmente pruebas beta) para asegurar que la aplicación cumple con el propósito planteado desde su primer modelo. Estas pruebas deberían aplicarse en cada modelo del método, para garantizar el éxito en la primera versión del prototipo desarrollado.
Bibliografía
http://ri.biblioteca.udo.edu.ve/bitstream/123456789/1041/1/04-MULTIMEDIA.pdf
http://www.scielo.org.ve/scielo.php?pid=S0798 40652008000400010&script=sci_arttext
http://merinde.net/index.php?option=com_content&task=view&id=39&Itemid=157
http://merinde.net/index.php?option=com_content&task=view&id=40&Itemid=157
http://merinde.net/index.php?option=com_content&task=view&id=41&Itemid=157
http://merinde.net/index.php?option=com_content&task=view&id=42&Itemid=157
Autor:
Jesús Bravo
Jesús Fernández
María Blanco
Alberto Salcedo
Roseddy Gutiérrez
Sección º28
Carúpano, Enero del 2012
República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Universitaria
I.U.T "Jacinto Navarro Vallenilla"
Carúpano- Estado Sucre
Carúpano, Enero del 2012