República bolivariana de Venezuela

Ministerio del poder popular para la educación

Instituto universitario politécnico “Santiago Mariño”

Extensión – Porlamar.

Prof. Fernandez Jhonatan

Bachiller:

Alberto Marín

C.I:17.898.703

Metodologías para el Análisis y Diseño de Sistemas

Introducción.

El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una

empresa con el propósito de mejorar con métodos y procedimientos más adecuados. El

desarrollo de sistemas tiene dos componentes. Sistema de información Conjunto u

ordenación de elementos organizados para llevar a cabo algún método, procedimiento o

control mediante el proceso de información. Análisis: Es el proceso de clasificación e

interpretación de hechos, diagnóstico de problemas y empleo de la información para

recomendar mejoras al sistemas. Diseño: Especifica las características del producto terminado.

En la actualidad para muchas organizaciones, los sistemas de información basados en

computadoras son el corazón de las actividades cotidianas y objeto de gran consideración

en la toma de decisiones, las empresas consideran con mucho cuidado las capacidades

de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o

cuando planean la respuesta que darán a la competencia. Al establecer los sistemas de

información basados en computadoras deben tener la certeza de que se logren dos

objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún

sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización.

Puede ocurrir que, una vez contratado como miembro de una organización, se convierta

en usuario de su sistema de información, entonces el conocimiento del análisis y diseño

de sistemas, le permitirá aumentar su productividad personal, sirviéndole para resolver los

problemas que surjan en su área de trabajo, determinando nuevos requerimientos de

información y permitiéndole colaborar con los profesionales en informática en la resolución de tales situaciones.

El análisis y diseño de sistemas es un procedimiento para la resolución de problemas.

Cuando se trata del diseño de sistemas de información, busca analizar sistemáticamente

la entrada o flujo de datos, la transformación de los datos, el almacenamiento de datos y

la salida de información en el contexto de una organización particular. También es usado

para analizar, diseñar e implementar mejoras que puedan incorporarse a la organización y puedan ser alcanzadas al usar un sistema de información computarizado.

El método.

Un método es una serie de pasos sucesivos, conducen a una meta. El objetivo del

profesionista es llegar a tomar las decisiones y una teoría que permita generalizar

y resolver de la misma forma problemas semejantes en el futuro. Por ende es

necesario que siga el método más apropiado a su problema, lo que equivale a

decir que debe seguir el camino que lo conduzca a su objetivo.

Algunos métodos son comunes a muchas ciencias, pero cada ciencia tiene sus

propios problemas y por ende sus propias necesidades en donde será preciso

emplear aquellas modalidades de los métodos generales más adecuados a la

solución de los problemas específicos.

El método es un orden que debe imponer a los diferentes procesos necesarios

para lograr un fin dado o resultados.

Definición de Metodología.

Se denomina metodología al estudio de los métodos de investigación que luego se

aplican en el ámbito científico.

La metodología de la investigación supone la sistematización, es decir, la

organización de los pasos a través de los cuales se ejecutará una investigación

científica. No es posible concebir la idea de “investigación” sin pensar de manera

casi automática en la serie de pasos que debemos cumplir para otorgar seriedad,

veracidad y cientificidad a dicha investigación.

Lenguaje Unificado de Modelado (UML) (Diagramas).

Es el lenguaje de modelado de sistemas de software más conocido y

utilizado en la actualidad; está respaldado por el OMG (Object

Management Group). Es un lenguaje gráfico para visualizar, especificar,

construir y documentar un sistema. UML ofrece un estándar para

describir un "plano" del sistema (modelo), incluyendo aspectos

conceptuales tales como procesos de negocio y funciones del sistema, y

aspectos concretos como expresiones de lenguajes de programación,

esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para

especificar o para describir métodos o procesos. Se utiliza para definir un sistema,

para detallar los artefactos en el sistema y para documentar y construir. En otras

palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el

desarrollo de software entregando gran variedad de formas para dar soporte a una

metodología de desarrollo de software (tal como el Proceso Unificado Racional o

RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no

puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la

realidad de una utilización en un requerimiento. Mientras que, programación

estructurada, es una forma de programar como lo es la orientación a objetos, sin

embargo, la programación orientada a objetos viene siendo un complemento

perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a

objetos.

TIPOS DE DIAGRAMAS EN UML.

Usando UML se pueden construir numerosos tipos de diagramas. Vamos a citar

algunos:

Diagramas de casos de uso: representan a los actores y casos de uso (procesos

principales) que intervienen en un desarrollo de software.

Diagramas de clases: para UML una clase es una entidad, no una clase

software. Un diagrama de clases UML puede ser un diagrama del dominio o

representación de conceptos que intervienen en un problema, o también un

diagrama de clases software. El sentido de un diagrama UML se lo da la persona

que lo construye.

Diagramas de secuencia: suelen usarse para representar objetos software y el

intercambio de mensajes entre ellos, representando la aparición de nuevos objetos

de izquierda a derecha.

Diagramas de colaboración: suelen usarse para representar objetos o clases y

la forma en que se transmiten mensajes y colaboran entre ellos para cumplir un

objetivo.

Diagramas de estados: suelen usarse para representar cómo evoluciona un

sistema (cómo va cambiando de estado) a medida que se producen determinados

eventos.

Otros diagramas: diagramas de actividad, diagramas de paquetes, diagramas de

arquitectura software, etc.

CRÍTICAS A UML.

UML recibe numerosas críticas por parte de los miembros de la comunidad de

desarrolladores software, entre ellas el ser demasiado extenso, carecer de

significados precisos para los elementos representados, dificultad para representar

algunos tipos de sistemas software o elementos, etc.

A pesar de ello y de no ser “perfecto”, es un estándar de amplio uso hoy día y una

herramienta fundamental en desarrollos software de gran envergadura.

FASES.

Análisis de Requerimientos: UML tiene casos de uso (use-cases) para capturar

los requerimientos del cliente. A través del modelado de casos de uso, los actores

externos que tienen interés en el sistema son modelados con la funcionalidad que

ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son

modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas

en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case.

Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo

que él (o ella) espera del sistema sin considerar la funcionalidad que se

implementará. Un análisis de requerimientos puede ser realizado también para

procesos de negocios, no solamente para sistemas de software.

Análisis: La fase de análisis abarca las abstracciones primarias (clases y objetos)

y mecanismos que están presentes en el dominio del problema. Las clases que se

modelan son identificadas, con sus relaciones y descritas en un diagrama de

clases. Las colaboraciones entre las clases para ejecutar los casos de uso

también se consideran en esta fase a través de los modelos dinámicos en UML.

Es importante notar que sólo se consideran clases que están en el dominio del

problema (conceptos del mundo real) y todavía no se consideran clases que

definen detalles y soluciones en el sistema de software, tales como clases para

interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

Diseño: En la fase de diseño, el resultado del análisis es expandido a una

solución técnica. Se agregan nuevas clases que proveen de la infraestructura

técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos

en una base de datos, comunicaciones con otros sistemas, etc. Las clases de

dominio del problema del análisis son agregadas en esta fase. El diseño resulta en

especificaciones detalladas para la fase de programación.

Programación: En esta fase las clases del diseño son convertidas a código en un

lenguaje de programación orientado a objetos. Cuando se crean los modelos de

análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos

modelos a código.

Pruebas: Normalmente, un sistema es tratado en pruebas de unidades, pruebas

de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de

unidades se realizan a clases individuales o a un grupo de clases y son

típicamente ejecutadas por el programador. Las pruebas de integración integran

componentes y clases en orden para verificar que se ejecutan como se especificó.

Las pruebas de sistema ven al sistema como una "caja negra" y validan que el

sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de

aceptación conducidas por el cliente verifican que el sistema satisface los

requerimientos y son similares a las pruebas de sistema.

Metodología del Ciclo de Vida de un SistemadeJames Martín.

Esta metodología de desarrollo de Software es mejor conocida como

Metodología RAD (Rapid Application Development) o Desarrollo rápido

de Aplicaciones, y fue creada por el gurú de computación James

Martin en 1991. Está orientada a disminuir radicalmente el tiempo

necesario para diseñar e implementar Sistemas de Información, el

RAD cuenta con una participación intensa del usuario, sesiones JAD,

prototipaje, herramientas CSE integradas y generadores de código. El

Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.

Fases o Etapas.

Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con

un vasto conocimiento de los procesos de la compañía determinen cuáles serán

las funciones del sistema. Debe darse una discusión estructurada sobre los

problemas de la compañía que necesitan solución.

Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la

compañía en relación al sistema propuesto. Los usuarios participan activamente

en talleres bajo la tutela de los profesionales de la informática. En ellos

descomponen funciones y definen entidades asociadas con el sistema. Una vez se

completa el análisis se crean los diagramas que definen las alteraciones entre los

procesos y la data.

Construcción: En la etapa de construcción el equipo de desarrolladores

trabajando de cerca con los usuarios finaliza el diseño y la construcción del

sistema. La construcción de la aplicación consiste de una serie de pasos donde

los usuarios tienen la oportunidad de afirmar los requisitos y repasar los

resultados.

Implementación: Esta etapa envuelve la implementación del nuevo producto y el

manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y

se adiestran los usuarios.

Metodología de Jeffrey Whitten.

La palabra sistema significa “Conjunto de cosas que relacionadas entre sí

ordenadamente contribuyen a determinado objeto”. Es importante enfocarnos en

una palabra determinante en este concepto: ordenadamente, este vocablo se

define como “la forma en que están organizados o dispuestos los distintos

elementos de un sistema, a esto se le llama también configuración” y más tarde

“conocer el propósito o resultado que se desea obtener de un sistema es el primer

paso en la definición de la manera en que se configurarán sus elementos” por lo

tanto la salida de un sistema estará intrínsecamente relacionada con la

configuración del mismo. Tomando como base este simple pero general concepto

de lo que es un sistema podemos centrarnos en dialogar sobre que es un sistema

de información, y aunque su definición quizás no diste mucho de la anterior y nos

ofrece una idea más específica de lo que en realidad estamos buscando.

Fases:

Fase I: Identificación del Problema

El primer paso en toda investigación es saber identificar el problema, es decir,

saber con qué se va a trabajar, qué es lo que se va a resolver o mejorar. Pero este

problema debe ser factible y en realidad cubrir con las expectativas de relevancia,

para ser luego resuelto con ingenio mediante la utilización de personas expertas

en la materia.

Fase II. Análisis del sistema actual.

Bien se describe en el libro haciendo alusión a un viejo proverbio que dice “No

intentes arreglarlo a menos que lo hayas comprendido”. Esta fase consiste en

estudiar y analizar el sistema actual. Se identificaran sus problemas, cómo se

maneja, con quién se interrelaciona y cómo podría solventarse el mismo. Qué es

lo que se necesita para que el sistema trabaje de manera eficiente. Como parte

del análisis del sistema de información se encuentra el análisis de los

requerimientos, de viabilidad, el modelado de datos, procesos, redes y el

diccionario de datos.

Fase III. Diseño o Modelado.

El diseño del prototipo de los sistemas de información consta de dos etapas: un

diseño lógico y el desarrollo físico del mismo. El primero se refiere a la descripción

de salidas, entradas, archivos, bases de datos, procedimientos y el segundo

consta de la Programación del sistema y la creación de archivos. El prototipo

proporcionara información con relación a la factibilidad del concepto. Se tomara

como un plan piloto o prueba del sistema. El prototipo diseñado podrá ser

modificado con facilidad y en el momento que así lo requiera según sea el caso.

Fase IV. Diseño de la topología y de los servicios.

A partir de los usuarios involucrados con el sistema, y utilizando diversos

instrumentos y técnicas de recolección de datos, el estudio de datos y formas

usadas por la organización, se ubicaran los requerimientos del sistema a

proponer. Esto permite obtener opiniones y requerimientos sobre el sistema

necesario a implantar. Las causas posibles por las cuales suceden las cosas y

algunas ideas en relación con las posibles modificaciones. La versión modificada

se tomará, a su vez, como prueba para obtener información valiosa en el diseño

final.

Fase V. Desarrollo y Documentación.

Se elabora lo que realmente es la solución del problema basándose en el prototipo

anterior y del diseño del sistema propuesto a fin de solventarlo. Para poder lograr

esto, se necesitan una serie de pasos como lo son: revisión del prototipo,

desarrollo de la infraestructura del sistema, integración interna, verificación de las

salidas, y documentación paralela de todos estos pasos.

Fase VI. Implantación.

El término de implantación de sistemas se refiere a la entrega del mismo a los

usuarios finales que habrán de utilizarlo. Se colocara el sistema en funcionamiento

para que el problema pueda ser resuelto de una manera práctica y fácil. Se debe

instruir a los usuarios finales que estarán directamente relacionados con el mismo

a fin de que puedan entender el nuevo sistema y hacer modificaciones del

software y/o resolver problemas en caso que ocurrieran.

Fase VII. Pruebas.

Una fase muy importante en el desarrollo de todo sistema de información es la

fase de prueba, la cual permite obtener un indicador de que el esfuerzo

desempeñado no fue en vano. Su filosofía es la detección de errores. Aunque el

sistema es probado arduamente por los analistas, diseñadores y programadores

del sistema, es necesario realizar pruebas con los usuarios finales. Durante estas

pruebas, además de hacer las observaciones necesarias durante algunas

consultas reales se usara del sistema de información, también se llenara una

bitácora con errores, comentarios, sugerencias a fin de obtener retroalimentación

de la usabilidad, utilidad y fallas del mismo.

Fase VIII Depuración.

La depuración es el proceso metodológico para encontrar y reducir errores o

defectos en un sistema de información o en una pieza de hardware. Esta fase En

general, las tareas de la depuración de errores, suelen ser engorrosas y

agotadoras. Existen aplicaciones que permiten ayudar a analistas, programadores

y diseñadores en estas tareas, pero es la habilidad del mismo el factor más

Determinante para la efectividad y eficiencia del proceso de depuración.

Metodología de Kendall y Kendall.

El ciclo de vida del desarrollo de sistemas (SDLC, Systems Development life

cycle) es un enfoque por fases para el análisis y el diseño cuya premisa principal

consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de

actividades del analista y el usuario.” (Kendall & Kendall)

Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta

de siete partes: siendo la primera la identificación del problema, la segunda

identificación de requisitos de información, la tercera es el análisis de las

necesidades del sistema, la cuarta es el diseño del sistema recomendado, la

quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y

la última implementación y evaluación. Cada fase se explica por separado pero

nunca se realizan como pasos aislados, más bien es posible que algunas

actividades se realicen de manera simultánea, y algunas de ellas podrían

repetirse.

El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el

análisis y el diseño cuya premisa principal consiste en que los sistemas se

desarrollan mejor utilizando un ciclo especifico de actividades del analista y el

usuario.” (Kendall & Kendall) Según la metodología de Kendall & Kendall el ciclo

de vida de un sistema consta de siete partes: siendo la primera la identificación del

problema, la segunda identificación de requisitos de información, la tercera es el

análisis de las necesidades del sistema, la cuarta es el diseño del sistema

recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y

mantenimiento y la última implementación y evaluación. Cada fase se explica por

separado pero nunca se realizan como pasos aislados, más bien es posible que

algunas actividades se realicen de manera simultánea, y algunas de ellas podrían

repetirse.

FASES:

FASE I: Identificación de problemas, oportunidades y objetivos.

Observación directa del entorno.

Aplicación de entrevista para recolectar información.

Sintetizar la información recolectada para construir objetivos.

Estimar el alcance del proyecto.

Identificar si existe una necesidad, problema u oportunidad argumentada.

Documentar resultados.

Estudiar los riesgos del proyecto.

Presentar un informe de vialidad.

En la primera fase el analista es el encargado de identificar los problemas de la

organización, detallarlos, examinar, evaluar las oportunidades y objetivos.

El analista debe identificar y evaluar los problemas existentes en la organización

de manera crítica y precisa. Mayormente los problemas son detectados por

alguien más y es cuando el analista es solicitado a fin de precisarlos. Las

oportunidades son situaciones que el analista considera susceptibles de mejorar

utilizando sistemas de información computarizados, lo cual le da mayor seguridad

y eficacia a las organizaciones además de obtener una ventaja competitiva. El

analista debe identificar los objetivos, es decir, el analista debe averiguar lo que la

empresa trata de conseguir, se podrá determinar si algunas funciones de las

aplicaciones de los sistemas de información pueden contribuir a que el negocio

alcance sus objetivos aplicándolas a problemas u oportunidades específicos. Los

usuarios, los analistas y los administradores de sistemas que coordinan el

proyecto son los involucrados en la primera fase. Las actividades de esta fase son

las entrevistas a los encargados de coordinar a los usuarios, sintetizar el

conocimiento obtenido, estimar el alcance del proyecto y documentar los

resultados. El resultado de esta fase en un informe de viabilidad que incluye la

definición del problema y un resumen de los objetivos. La administración debe

decidir si se sigue adelante o si se cancela el proyecto propuesto

FASE II: Determinación de los requerimientos de información.

Revisión de los objetivos.

Identificar el dominio.

Investigar la razón por la cual se implementa el sistema actual.

Recolectar información sobre los procedimientos y operaciones que se

desempeñan actualmente.

Detallar específicamente: Quiénes son los involucrados, cuál es la actividad, regla

y restricciones del negocio, entorno de desarrollo de las actividades, momentos

oportunos de desarrollo de cada función, la manera en que se desempeñan los

procedimientos actuales.

Elaborar una lista detallada y organizada de todos los procedimientos.

Separar requerimientos funcionales y no funcionales. Adicionar al informe de la

primera fase, esta nueva información.

En esta fase el analista se esfuerza por comprender la información que necesitan

los usuarios para llevar a cabo sus actividades. Entre las herramientas que se

utilizan para determinar los requerimientos de información de un negocio se

encuentran métodos interactivos como las entrevistas, los muestreos, la

investigación de datos impresos y la aplicación de cuestionarios; métodos que no

interfieren con el usuario como la observación del comportamiento de los

encargados de tomar las decisiones y sus entornos e oficina, al igual que métodos

de amplio alcance como la elaboración de prototipos.

Esta fase es útil para que el analista confirme la idea que tiene de la organización

y sus objetivos.

Los implicados en esta fase son el analista y los usuarios, por lo general los

trabajadores y gerentes del área de operaciones.

El analista necesita conocer los detalles de las funciones del sistema actual:

El quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el

entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y

el cómo (la manera en que se realizan los procedimientos actuales) del negocio

que se estudia.

Al término de esta fase, el analista debe conocer el funcionamiento del negocio y

poseer información muy completa acerca de la gente, los objetivos, los datos y los

procedimientos implicados.

FASE III: Análisis de las necesidades.

Evaluar las dos fases anteriores.

Modelar las entradas, los procesos y las salidas de las funciones ya identificadas.

Elaborar diccionario de datos y sus especificaciones.

Elaborar diagramas de procesos de cada función.

Elaborar propuesta del sistema con todos los diagramas de operaciones y de

procesos.

Realizar el análisis del riesgo sobre el realizado en las fases anteriores, tomando

en cuenta el aspecto económico, técnico y operacional (estudio de factibilidad)

Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el sistema.

En esta fase el analista evalúa las dos fases anteriores, usa herramientas y

técnicas como el uso de diagramas de flujo de datos para graficar las entradas, los

procesos y las salidas de las funciones del negocio en una forma gráfica

estructurada.

A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos

que enlista todos los datos utilizados en el sistema así como sus respectivas

especificaciones.

El analista prepara en esta fase, una propuesta de sistemas que sintetiza sus

hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece,

en su caso, recomendaciones sobre lo que se debe hacer.

FASE IV: Diseño del sistema recomendado.

Evaluar las tres fases anteriores.

Realizar el diseño lógico de todo el sistema.

Elaborar procedimientos precisos para la captura de los datos que van a ingresar

al sistema de información.

Elaborar el diseño de la base de datos.

Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o

función.

Diseñar controles y procedimientos de respaldos que protejan al sistema y a los

datos.

Producir los paquetes específicos de programas para los programadores.

Elaborar una lista de las funciones genéricas y de las que será obligatorio crear.

En esta fase el analista utiliza la información recopilada en las primeras fases para

realizar el diseño lógico del sistema de información.

El analista diseña procedimientos precisos para la captura de datos que aseguran

que los datos que ingresen al sistema de información sean correctos.

Facilita la entrada eficiente de datos al sistema de información mediantes técnicas

adecuadas de diseño de formularios y pantallas.

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema

de información.

La interfaz conecta al usuario con el sistema y por tanto es sumamente

importante.

También incluye el diseño de archivos o bases de datos que almacenarán gran

parte delos datos indispensables para los encargados de tomar las decisiones en

la organización.

En esta fase el analista interactúa con los usuarios para diseñar la salida (en

pantalla o impresa) que satisfaga las necesidades de información de estos

últimos.

Finalmente el analista debe diseñar controles y procedimientos de respaldo que

protejan al sistema y a los datos y producir paquetes de especificaciones de

programa para los programadores.

Cada paquete debe contener esquemas para la entrada y la salida,

especificaciones de archivos y detalles del procesamiento.

FASE V: Desarrollo y documentación del software.

Evaluar los procedimientos que va a ser desarrollados por el programador.

Mostrar y explicar cada procedimiento, función y operación al programador.

Elaborar manuales de procedimientos internos del sistema.

Elaborar manuales externos de ayuda a los usuarios del sistema.

Elaborar demostraciones para los usuarios y la interacción con distintas

interfaces.

Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe

con el tiempo que se llevó construir cada procedimiento.

En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera

conjunta con los programadores para desarrollar cualquier software original

necesario. Entre las técnicas estructuradas para diseñar y documentar software se

encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y

el pseudocódigo.

Durante esta fase el analista trabaja con los usuarios para desarrollar

documentación efectiva para el software, como manuales de procedimientos,

ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en

archivos “léame” que se integrarán al nuevo software.

La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en

caso de que surjan problemas derivados de este uso. Los programadores

desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores

sintácticos de los programas de cómputo.

FASE VI: Prueba y mantenimiento del sistema.

Realizar la programación de las pruebas del sistema.

Realizar un instrumento para evaluar el sistema de información.

El programador deberá elaborar un resumen de las pruebas del sistema.

El analista deberá realizar un informe de sus pruebas y discutirlo con el

programador.

Elaborar la planificación de las horas del mantenimiento del sistema. Elaborar la

lista de las operaciones que pudieran sufrir modificaciones de códigos.

Antes de poner en funcionamiento el sistema es necesario probarlo es mucho

menos costoso encontrar los problemas antes que el sistema se entregue a los

usuarios.

Una parte de la pruebas la realizan los programadores solos, y otra la llevan a

cabo de manera conjunta con los analistas de sistemas. Primero se realizan las

pruebas con datos de muestra para determinar con precisión cuáles son los

problemas y posteriormente se realiza otra con datos reales del sistema actual.

El mantenimiento del sistema de información y su documentación empiezan en

esta fase y se llevan de manera rutinaria durante toda su vida útil.

FASE VII: Implementación y evaluación del sistema.

Planificar gradualmente la conversión del sistema anterior.

Instalar los equipos de hardware necesarios para el funcionamiento del software

creado.

Capacitar por medio de talleres a los usuarios en el manejo de equipos y software

creados.

Evaluar la adaptabilidad de los usuarios al sistema.

Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la

implementación del sistema de información. En esta fase se capacita a los

usuarios en el manejo del sistema. Parte de la capacitación la imparten los

fabricantes, pero la supervisión de ésta es responsabilidad del analista de

sistemas.

Metodología de Administración de Relaciones (RMM).

La metodología RMM permite hacer explícita la navegación al hacer el análisis, lo

que permite, teóricamente, obtener una navegación más estructurada e intuitiva, y

lo hace de una forma muy sencilla, como es añadir unas primitivas a un modelo

entidad-relación tradicional. El concepto de slice es muy útil, ya que permite

agrupar datos de una entidad en diferentes pantallas. Se utilizaría, por ejemplo,

para mostrar dos vídeos en dos pantallas diferentes sobre un mismo fenómeno.

También es interesante la primitiva de grupo, que permite mostrar la jerarquía de

menús.

RMM representa el primer caso en el que se crea una metodología completa

definiendo las distintas fases y no únicamente un modelo de datos. Además, se

basa en un modelo de datos relacional, ajustándose así a la gran mayoría de las

aplicaciones existentes. Sin embargo, los mecanismos de acceso a la información

son excesivamente simples y valen para un problema con pocas entidades, pero

el modelo se queda corto si hay gran número de ellas.

La característica más relevante de la RMM es el modelo de la cual hace las

abstracciones a los elementos de la aplicación de los híper medios, como la

navegación, esto se llama RMDM (Relationship Management Data Model), la cual

es un conjunto de objetos lógicos que proporcionan una abstracción de un

fragmento del mundo real, los modelos de datos son necesarios para expresar el

diseño de una aplicación.

Fases de la Metodología de Diseño RMM.

Fase I. Diseño del Diagrama entidad- relación

En esta primera fase del diseño se representa el dominio de la información

mediante un diagrama entidad-relación. Es el método más utilizado por los

analistas de sistemas, posee una buena documentación y puede modelar las

dependencias de información en numerosos dominios de aplicaciones. Esta etapa

de diseño representa una disertación de las actividades y relaciones relevantes al

dominio de la aplicación. Estas entidades y relaciones forman la base de la

aplicación hipermedia.

Fase II. Diseño de perfiles

Esta fase es única en aplicaciones híper mediales, determina como la información

en las entidades escogidas será expuesta al usuario y cómo podrá acceder a

estas. La misma conlleva a la división de entidades lógicas para organizarlas en

una red de hipertexto. De una manera más sencilla toda la información de una

entidad debe ser visualizada en una ventana con una barra de desplazamiento.

Fase III. Diseño Navegacional

En esta fase se proyectan las rutas que permiten la navegación por el hipertexto,

lo cual se crea estudiando cada paso del diagrama entidad-relación y una relación

asociativa debe ser viable para la navegación.

Fase IV. Protocolo de conversión de diseño

En esta fase se trata de transformar, mediante un conjunto de reglas de

conversión, que permiten transformar cada elemento del diagrama RMDM en un

objeto tangible de alguna herramienta de software.

Fase V. diseño de la interfaz de usuario

Esta fase involucra diagramar el diseño de pantallas para cada objeto que aparece

en el diagrama RMDM obtenido en la tercera fase. Esto incluye la distribución de

botones, la apariencia de los nodos e índice y la ubicación de la ayuda

navegación.

Fase VI. Diseño de comportamiento en tiempo de ejecución

Durante esta etapa los desarrolladores deben considerar la volatilidad y el tamaño

del dominio para decidir si los contenidos de los nodos y los índices finales serán

construidos durante el desarrollo de la aplicación o serán creados dinámicamente

en tiempo de ejecución a medida que se requieran.

Fase VII. Construcción y aplicación

Consiste en la construcción y validación de todas las trayectorias posibles de

navegación, para comprobar que los elementos de enlace están bien, que no

queden elementos desconectados de la aplicación.

Metodología Orientada a Objetos

La metodología OMT (Object Modeling Technique) fue creada por James

Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de

investigación de los laboratorios General Electric.

OMT es una de las metodologías de análisis y diseño orientada a objetos, más

madura y eficiente que existe en la actualidad. La gran virtud que aporta esta

metodología es su carácter de abierta (no propietaria), que le permite ser de

dominio público y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita

su evolución para acoplarse a todas las necesidades actuales y futuras de la

ingeniería de software.

Las fases que conforman a la metodología OMT son:

Análisis: El analista construye un modelo del dominio del problema, mostrando

sus propiedades más importantes. El modelo de análisis es una abstracción

resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma

en que se hará. Los elementos del modelo deben ser conceptos del dominio de

aplicación y no conceptos informáticos tales como estructuras de datos. Un buen

modelo debe poder ser entendido y criticado por expertos en el dominio del

problema que no tengan conocimientos informáticos.

Diseño del sistema: El diseñador del sistema toma decisiones de alto nivel sobre

la arquitectura del mismo. Durante esta fase el sistema se organiza en

subsistemas basándose tanto en la estructura del análisis como en la arquitectura

propuesta. Se selecciona una estrategia para afrontar el problema.

Diseño de objetos: El diseñador de objetos construye un modelo de diseño

basándose en el modelo de análisis, pero incorporando detalles de

implementación. El diseño de objetos se centra en las estructuras de datos y

algoritmos que son necesarios para implementar cada clase. OMT describe la

forma en que el diseño puede ser implementado en distintos lenguajes (orientados

y no orientados a objetos, bases de datos, etc.).

Implementación: Las clases de objetos y relaciones desarrolladas durante el

análisis de objetos se traducen finalmente a una implementación concreta.

Durante la fase de implementación es importante tener en cuenta los principios de

la ingeniería del software de forma que la correspondencia con el diseño sea

directa y el sistema implementado sea flexible y extensible.

No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la

reutilización de código y la correspondencia entre el dominio del problema y el

sistema informático, si luego perdemos todas estas ventajas con una

implementación de mala calidad.

La metodología OMT emplea tres clases de modelos para describir el

sistema:

Modelo de objetos: Describe la estructura estática de los objetos del sistema

(identidad, relaciones con otros objetos, atributos y operaciones). El modelo de

objetos proporciona el entorno esencial en el cual se pueden situar el modelo

dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del

mundo real que sean importantes para la aplicación. Se representa mediante

diagramas de objetos.

Modelo dinámico: Describe los aspectos de un sistema que tratan de la

temporización y secuencia de operaciones (sucesos que marcan los cambios,

secuencias de sucesos, estados que definen el contexto para los sucesos) y la

organización de sucesos y estados. Captura el control, aquel aspecto de un

sistema que describe las secuencias de operaciones que se producen sin tener en

cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que

están implementadas. Se representa gráficamente mediante diagramas de estado.

Modelo funcional: Describe las transformaciones de valores de datos (funciones,

correspondencias, restricciones y dependencias funcionales) que ocurren dentro

del sistema. Captura lo que hace el sistema, independientemente de cuando se

haga o de la forma en que se haga. Se representa mediante diagramas de flujo de

datos

Metodología del Software Educativo por Álvaro Galvis (ISE)

Es una metodología de desarrollo de software que contempla una serie de fases o

etapas de un proceso sistemático atendiendo a: Análisis, diseño, desarrollo,

prueba y ajuste, y por ultimo implementación. En la Figura siguiente se ilustra el

flujo de acción de la metodología, donde Gómez et al (s/f) señalan que el ciclo de

vida de una aplicación educativa puede tener dos maneras de ejecución, en

función de los resultados de la etapa de análisis (se diseña, desarrolla y prueba lo

que se requiere para atender la necesidad), y en el sentido contrario, se somete a

prueba aquello que puede satisfacer la necesidad.

Metodología ISE propuesta por Galvis

Etapa 1: Análisis

El propósito de esta etapa es determinar el contexto donde se creará la aplicación

y derivar de allí los requerimientos que deberá atender la solución interactiva,

como complemento a otras soluciones. Acorde con Galvis (citado en Gómez et al,

s/f) en esta fase se establece como mínimo la siguiente información:

1. Características de la población objetivo.

2. Conducta de entrada y campo vital.

3. Problema o necesidad a atender.

4. Principios pedagógicos y didácticos aplicables.

5. Justificación de uso de los medios interactivos.

6. Diagramas de Interacción

Etapa 2: Diseño

El diseño se construye en función directa de los resultados de la etapa de análisis,

es importante hacer explícitos los datos que caracterizan el entorno del SE a

diseñar: destinatarios, área del contenido, necesidad educativa, limitaciones y

recursos para los usuarios, equipo y soporte lógico.

En esta etapa acorde con Salcedo (2002) es necesario atender a tres tipos de

diseño: Educativo (este debe resolver las interrogantes que se refieren al alcance,

contenido y tratamiento que debe ser capaz de apoyar el SE), comunicacional (es

donde se maneja la interacción entre usuario y maquina se denomina interfaz), y

computacional (con base a las necesidades se estable qué funciones es deseable

cumpla el SE en apoyo de sus usuarios, el docente y los estudiantes).

Etapa 3: Desarrollo

En esta fase se implementa toda la aplicación usando la información recabada

hasta el momento. Se implementa el lenguaje escogido tomando en consideración

los diagramas de interacción mencionados anteriormente. Es preciso establecer la

herramienta de desarrollo sobre el cual se va a efectuar el programa, atendiendo a

recursos humanos necesarios, costo, disponibilidad en el mercado, portabilidad,

facilidades al desarrollar, cumpliendo las metas en términos de tiempo y calidad de

SE.

Etapa 4: Prueba Piloto

En esta se pretende ayudar a la depuración del SE a partir de su utilización por

una muestra representativa de los tipos de destinatarios para los que se hizo y la

consiguiente evaluación formativa. Es imprescindible realizar ciertas validaciones

(efectuadas por expertos) de los prototipos durante las etapas de diseño y prueba

en uno a uno de los módulos desarrollados, a medida que estos están funcionales.

Etapa 5: Prueba de Campo

La prueba de campo de un SE es mucho más que usarlo con toda la población

objeto. Si se exige, pero no se limita a esto. Es importante que dentro del ciclo de

desarrollo hay que buscar la oportunidad de comprobar, en la vida real, que

aquello que a nivel experimental parecía tener sentido, lo sigue teniendo, es decir,

si efectivamente la aplicación satisface las necesidades y cumple con la

funcionalidad requerida.

Metodología de Sistemas Blandos (SSM) de Peter Checkland.

Etapa 1: Situación problema no estructurada.

La etapa inicial consiste simplemente en que los encargados y/o los empleados

(propietarios del problema) deciden que son requeridos una revisión o un cambio

de tareas y la manera en que debe realizarse y llaman a un analista (facilitador del

problema). La gente de la organización acepta que puede haber un problema o

ven una posibilidad de mejorar y son de la idea de que se inicie el análisis o la

revisión. La metodología de sistemas suaves aporta en principio que el término 'el

problema ‘es inadecuado porque hace que se minimice la visión de la situación. La

metodología de los sistemas suaves cree que 'la situación problema' es un término

más apropiado puesto que puede haber muchos problemas que tienen la

necesidad percibida a ser solucionados.

Etapa 2: Situación problema expresada.

La etapa 1 incluyó básicamente las problemáticas, lo que la gente de la

organización sospecha que puede haber un problema y/o una posibilidad para la

mejora, y pide iniciar el análisis o la revisión. En la etapa 2, el analista recoge y

clasifica la información y prové una cierta descripción de la situación problema. Lo

siguiente es la información que estamos buscando:

La estructura de la organización: esos factores que no cambian fácilmente (las

construcciones, las localizaciones, el ambiente, etc); procesos o transformaciones

que se realizan dentro del sistema: muchos de éstos están cambiando

constantemente; hechos que son expresados o sentidos por los miembros de

organización (quejas, críticas, sugerencias, etc).

Hay muchas estrategias que los analistas pueden emplear cuando recogen los

hechos, más allá de enfoques muy informales, no estructurados a las

herramientas hasta las muy formales, estructuradas empleadas en análisis

tradicional de los sistemas. Algunas de las técnicas son:

Observación del trabajo:

Identificación de las tareas realizadas

Identificación de las herramientas empleadas

Establezca las interacciones entre personas/sistemas

Produzca registros, anote.

Descripciones de un"día en la vida”

Haga los gráficos de estructuras/layouts

Grabaciones video, si es posible.

Recoja las muestras de las herramientas usadas para manejar la información

Coleccione la observación de cada participante

Entrevistas: no estructurada, informal ("dígame lo que usted hace")

Semis estructurado (cuestionario con respuestas ampliables)

Altamente estructurada (cuestionario con rectángulos a hacer tictac)

Incidentes críticos

Grabación audio

Talleres y discusión:

Talleres futuros

Talleres de la revisión

Talleres de las resoluciones del conflicto

La mofa sube, las simulaciones, juegos de la mente

La etapa 1 y la etapa 2 son una fase de la 'expresión' durante a la cual una

tentativa se hace para construir la posible visión enriquecida, no 'el problema' sino

la situación que allí se percibe como problema. Es muy importante no reducir

nuestro alcance de la investigación demasiado rápido. Si seleccionamos un

enfoque muy estructurado tal como un cuestionario bien escogido múltiple al

principio de nuestro estudio, y construimos un modelo en base de esos resultados

solamente, excluimos probablemente mucha de la información que podría ser

relevante. Pues una estrategia general, por lo tanto, es mejor emplear una

selección no estructurada técnicamente desde el principio, y emplear más bien

técnicas estructuradas después de que una primera impresión del problema se

haya definido, con el fin de sacar la información detallada o de

controlar suposiciones. Las técnicas específicas se deben seleccionar siempre

para caber adentro con el trabajo de la organización, y cada una que está

proveyendo la información debe ser informada acerca de cuál es el propósito del

análisis.

Cuando un analista saca la información de los miembros de una organización,

éste se comunica con ellos usando el lenguaje natural (español). Esto plantea

numerosos problemas y potenciales trampas. El analista debe estar preparado

para aceptar que en esta etapa, la información obtenida es incompleta y contiene

contradicciones y ambigüedades. El sistema al cual estamos mirando es un

sistema suave y por lo tanto la información acerca del sistema es probable que

sea cualitativa más bien que cuantitativa.

Etapa 3: Nombramiento de los Sistemas Relevantes.

Definiciones raíz.

Es necesario prestar atención a la formulación del nombramiento de los sistemas

relevantes para escribirlos de manera que un modelo pueda ser construido basado

en cada nombramiento. Estos nombramientos se conocen como Definiciones

Raíz. El propósito de la definición raíz es expresar el propósito central de un cierto

sistema útil de actividad. Es importante que se ponga atención en el desarrollo de

las definiciones raíz. Las definiciones raíz correctamente escritas proveen una

directriz mucho más simple en la construcción del modelo de un sistema.

Una definición de raíz se expresa como un proceso de la transformación que toma

una entidad como entrada de información, cambia o transforma a esa entidad, y

produce una nueva forma de la entidad. Una prescripción para desarrollar estos

procesos la transformación se muestra en la siguiente tabla, que muestra ejemplos

de transformaciones típicas de la operación de un curso de golf. Como usted

puede notar, estas transformaciones variarán grandemente, dependiendo de la

opinión del mundo que se aplique.

ENTRADA DE

INFORMACIÓN PRODUCCIÓN

COMO ES VISTO A

LOS OJOS DE:

Pista inusitada Pista ocupada por

curso del golf. Arquitecto.

Necesidad por

tiempos de la te.

La necesidad por

tiempos de la te se

resuelve.

Gestión Del Club.

Bolas nuevas del

golf.

Utilizado, rascado

encima de bolas del

golf.

Industria del equipo.

Germen de la

hierba Hierba madura. Greenskeepers

Alimento crudo. Comidas de calidad. Cocinero de la

cocina.

Golfer registrado.

Golfer que terminó

alrededor en X frota

ligeramente.

Favorable personal

del departamento.

Programa de la

lección del golf.

Programa facilitado de

la lección.

Profesional del

Club.

Tabla 1. Transformaciones una a una que implican opiniones diferentes del

mundo.

Producir una definición de raíz es un proceso progresivo de dos pasos.

Un hecho o una tarea se eligen de una visión enriquecida

Se define un sistema para realizar la tarea o para dirigir los hechos.

Cada definición raíz implica dos cosas importantes. Lo primero es que debemos

implicar cierta visión del mundo. La definición de la opinión del mundo no es

siempre trivial. También, no es deseable definir todas las opiniones del mundo.

Recuerde que cada visión enriquecida implicará una variedad de opiniones del

mundo. Los ojos pueden venir de fuentes tales como oficiales del gobierno,

ejecutivo de compañías, encargados del proyecto, empleados, clientes,

competidores y medios de noticias. Cada una de estas opiniones del mundo será

conectada a unas o más definiciones raíz distinta.

Es importante prestar la atención a la cordialidad del proceso de la transformación.

Cada definición raíz implica una transformación de una entrada en una

producción. Suponga que definimos una transformación como el " equipamiento

de golf " más " curso del golf " más " mano de obra " (tres entradas de información)

para producir "necesidades de golf puestas" más "mercado de golf servido" (dos

producciones). Esta transformación " tres a dos " es ambigua, pero se puede

resolver con muchas transformaciones una a una que se correspondan más

claramente (el equipamiento de golf se transforma en equipamiento de golf

usado).

CATWOE

Las definiciones de la raíz se escriben como sentencias que efectúan una

transformación. Hay seis elementos que hacen a una definición raíz bien

formulada, que se resumen en la mnemónica CATWOE.

Cliente: considera a cada uno que está presto para obtener beneficios de un

sistema. Si el sistema implica sacrificios tales como despidos, son víctimas deben

también ser contadas como clientes.

Actor: Los actores realizan las actividades definidas en el sistema.

Proceso de la transformación: Esto se muestra como la conversión de la entrada

de información a la producción.

Weltanschauung: La expresión alemana para la opinión del mundo. Esta opinión

del mundo hace que el proceso de la transformación sea significativo en contexto.

Propietario:Cada sistema tiene algún propietario, quien tiene el poder para

comenzar y/o para cerrar el sistema.

Apremios ambientales: Los elementos externos que existen fuera del sistema que

se toman como dados. Estos apremios incluyen políticas de organización así

como materias legales y éticas.

CATWOE se utiliza principalmente con el fin de analizar las sentencias de la

definición raíz, pero se puede utilizar como bloque de construcción para derivar la

sentencia de la definición raíz si sabemos los elementos de CATWOE.

Utilizamos CATWOE como la espina dorsal para desarrollar definiciones raíz

debido a que el uso de la transformación en sí misma como definición raíz se hace

difícil de modelar. La transformación y la opinión del mundo son el centro del

CATWOE. Cada actividad se puede expresar en muchas maneras, usando

opiniones diferentes del mundo. Es una buena idea que diferentes puntos de vista

sean utilizados para desarrollar definiciones raíz diferente. CATWOE también

reconoce la necesidad de explicar lo relativo a propiedad, funcionamiento,

beneficiarios, víctimas y apremios externos, que son cosas importantes a explicar

en la documentación del sistema.

Etapa 4: Modelos Conceptuales.

Dado una definición raíz de un sistema, un modelo conceptual puede ser modelo

conceptual trazado de A es un modelo humano de la actividad que estrictamente

se conforma con la definición raíz usando el conjunto mínimo de actividades. Los

pensamientos de sistemas se aplican en este desarrollo.

Pensamiento de Sistemas.

Cuadro 3. La Ruta del Pensamiento de Sistemas.

El cuadro 3 muestra que el pensamiento de sistemas es un proceso iterativo que

combina tres conceptos

El mundo percibido: Cada uno de nosotros tenemos nuestras propias opiniones

del mundo.

Ideas: Percibimos el mundo a través del marco de ideas que están internas en

nosotros.

Metodología: Hay muchas de éstas para pensar acerca del mundo, la SSM es solo

una.

Modelación de Sistemas Formales

El Pensamiento de Sistemas Formal se aplica al desarrollo del modelo conceptual.

El Modelo Formal del Sistema sirve como una guía de consulta para controlar el

modelo conceptual que trazamos. Deje que S represente a un sistema de

actividad humana. Bajo el modelo de Sistema Formal, S es un sistema formal si y

solamente si cumple los criterios siguientes:

S debe tener una misión.

S debe tener una medida del funcionamiento.

S debe tener un proceso de toma de decisión

S debe tener componentes que interactuan con unos con otros tal que los efectos

y acciones son transmitidos a través del sistema.

S debe ser acotado por un sistema más amplio con el cual interactua.

S se debe limitar del sistema más ancho, basado en el área donde su proceso de

toma de decisión tiene poder para hacer cumplir una acción.

S debe tener recursos a disposición de su proceso de toma de decisión.

S debe tener estabilidad a largo plazo, o la capacidad de recuperarse en el caso

de un disturbio.

Componentes de S deben ser sistemas que tienen todas las características de S

(subsistemas).

El modelo conceptual se puede escribir como gráfico dirigido, similar a una gráfica

PERT. Los nodos en el gráfico son actividades que se harán. Estas actividades se

basan en los verbos de la definición raíz. La estructuración del sistema se basa en

la dependencia lógica. Las dependencias lógicas se muestran como arcos en el

gráfico. Un arco en el gráfico significa que la actividad de la fuente es un requisito

previo para la actividad de la destinación.

El modelo conceptual para un sistema consiste de un sistema operacional que se

cubra - pero limitado por - un proceso de monitoreo. Este sistema operacional

consiste en una actividad central y algunas actividades prerequisitos se requieren

tal que la actividad central pueda ser hecha. La psicología cognoscitiva sugiere

que el cerebro humano pueda hacer frente a 7 +/- 2 conceptos al mismo tiempo.

Por lo tanto, debemos apuntar tener 7 +/- 2 actividades dentro de cada sistema

operacional. Si esta guía de consulta conduce a actividades que están en un nivel

demasiado alto, esas actividades se pueden ampliar a otro nivel. Puesta

simplemente, cada actividad general se convierte en una fuente para que una

definición raíz sea ampliada al nivel siguiente.

Monitorear un sistema.

Monitorear un sistema operacional consiste en tres actividades:

Defina una medida del funcionamiento: Podemos utilizar cualesquiera o las tres

para la medida del sistema operacional

Eficacia - trabaja

Eficiencia - cuánto del trabajo terminó con los recursos consumidos dados

Eficacia - son las metas satisfechas.

Monitorear las actividades en el sistema operacional, de acuerdo con la métrica

definida en etapa 1.

Tomar la acción del control: Utilice los resultados de estas métricas para

determinar y para ejecutar la acción que controle al sistema operacional.

Sin embargo las tres e mostradas arriba no son las únicas métricas que pueden

ser utilizadas. Muchas firmas utilizarán métrica incluyendo las métricas

económicas, éticas, elegantes, y otras que pueden ser dependientes en el

contexto del trabajo que es hecho.

Etapa 5: Comparar modelos conceptuales con realidad

Ésta es la etapa de regreso al mundo verdadero, pasando sobre la línea punteada.

En esta etapa, los modelos conceptuales construidos en la etapa 4 serán

comparados con la expresión verdadera del mundo, de la etapa 2. El trabajo

puede conducir en esta etapa a la reiteración de la etapa 3 y la 4. Previa

experiencia anterior de usar SSM indicó que la comparación no es de hecho una

comparación propiamente dicha. Esto será discutido más adelante. Basado en el

análisis razonado de esta metodología, hay cuatro maneras de hacer la

comparación del número de experiencias.

Antes de que se realice la comparación, varios otros aspectos necesitan ser

mencionados. La primera pregunta es cuál es el fin de la etapa 4. Cuando deberá

ser tiempo de parar de construir el modelo conceptual y de moverse a la

comparación verdadera del mundo. La tentación siempre es complacer la

prolongación y elaboración de la construcción del modelo. Es divertido trabajar en

modelar y no es tan cómodo traer al modelo a la realidad y engancharse con las

dificultades de las situaciones del problema. De hecho, de la experiencia de

Checkland, es mejor moverse rápidamente a la etapa de la comparación. Se

permitirá refinar el modelo posteriormente cuando tenga que ir de nuevo a la etapa

de la conceptualización otra vez.

Antes de que resumamos la etapa 5 de SSM, necesitamos entender la definición

de comparación. Generalmente, comparación es una parte importante del

pensamiento racional y serio que contiene percibir, predecir y comparar. En SSM,

Checkland define la comparación como el punto que las opiniones intuitivas del

problema son reunidas con las construcciones de los sistemas por lo que los

pensadores de sistemas afirman proveer una profundidad epistemologica y más

generalidad de la realidad debajo de los aspectos superficiales; es la etapa de la

comparación la que incorpora las hipótesis básicas de los sistemas que los

conceptos de los sistemas proveen un medio de prueba de la complejidad de la

‘realidad’.

Metodología MERINDE.

La Metodología 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 los requerimientos del Centro Nacional de Tecnología de

Información (CNTI) y en varias metodologías como el Proceso Unificado (UP)

especialmente.

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 sus

sistemas.

MeRinde es concebida para abarcar el desarrollo completo de sistemas de

software de diversa complejidad y magnitud, por lo cual su estructura responde a

desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de

acuerdo a las características particulares de cada proyecto. Dada la adaptabilidad

que puede 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á basada en componentes, lo cual quiere decir que

el sistema software en construcción está formado por componentes software

interconectados 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 del conocimiento entre las comunidades

desarrolladoras de software libre, con lo cual no solo se pretende que sea

compartido los códigos de los sistemas sino que también se compartan la

documentación como guía de referencia para mejoras por terceros al sistema o

para que sirva como modelo a otras comunidades para el desarrollo de sus

propios sistemas.

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

Conclusión.

En este tema se presenta un proceso de desarrollo de sistemas, que aún con sus

variaciones e inconvenientes, sirve como base al planteamiento de metodologías

que intentan hacerlo más efectivo. Este enfoque sistémico permite estructurar los

proyectos y en especial llevar a cabo el desarrollo de sistemas computacionales.

Tener conocimiento sobre el mismo, es de gran utilidad y da una idea de cómo

abordar problemas que pueden tener un alto grado de complejidad.

La función del Análisis puede ser dar soporte a las actividades de un negocio, o

desarrollar un producto que pueda venderse para generar beneficios.

Para conseguir este objetivo, un Sistema basado en computadoras hace uso de

seis (6) elementos fundamentales: Software, que son Programas de computadora,

con estructuras de datos y su documentación que hacen efectiva la logística

metodología o controles de requerimientos del Programa. Hardware, dispositivos

electrónicos y electromecánicos, que proporcionan capacidad de cálculos y

funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias,

bombas, lectores, etc.), que proporcionan una función externa dentro de los

Sistemas. Personal, son los operadores o usuarios directos de las herramientas

del Sistema. Base de Datos, una gran colección de informaciones organizadas y

enlazadas al Sistema a las que se accede por medio del Software.

Documentación, Manuales, formularios, y otra información descriptiva que detalla

o da instrucciones sobre el empleo y operación del Programa. Procedimientos, o

pasos que definen el uso específico de cada uno de los elementos o componentes

del Sistema y las reglas de su manejo y mantenimiento.

Bibliografía.

http://www.monografias.com/trabajos91/fases-metodologia-merinde-y-

metodologia-moomh/fases-metodologia-merinde-y-metodologia-

moomh.shtml#ixzz3oUZxBuOK

http://www.monografias.com/trabajos6/elme/elme.shtml#ixzz3oSRqaBlK

Cataldi, Z. (2000). Metodología de diseño, desarrollo y evaluación de software

educativo. Consultado el día 19 de octubre de 2008 de la Word Wide Web:

http://laboratorios.fi.uba.ar/lsi/cataldi-tesisdemagistereninformatica.pdf

Galvis, A. (2004). Oportunidades educativas de las TIC. Consultado el día 15 de

octubre de 2008 de la Word Wide Web:

http://www.karisma.org.co/documentos/softwareredp/tic-galvis-articles-

73523_archivo.pdf

Gómez R., Galvis A. y Mariño O. (s/f). Ingeniería de Software Educativo con

Modelaje Orientado por Objetos: Un medio para desarrollar micromundos

interactivos. Consultado el día 14 de octubre de 2008 de la Word Wide Web:

http://www.ribiecol.org/index2.php?option=com_docman&task=doc_view&gid=94&I

temid=15