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

1. 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

2. 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.

3. 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.
LenguajeUnificado 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

4. 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.

5. 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.

6. Metodología delCiclo de Vida de un SistemadeJames Martín.
Esta metodologíade desarrollo de Software es mejor conocidacomo
MetodologíaRAD (Rapid ApplicationDevelopment)o Desarrollo rápido
de Aplicaciones, y fue creada por el gurú de computaciónJames
Martin en 1991.Está orientada a disminuir radicalmente el tiempo
necesario para diseñare 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.

7. 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.

8. 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

9. Determinante para la efectividad y eficiencia del proceso de depuración.
Metodología de Kendally 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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íade Administraciónde 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

18. 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:

19. 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

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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

28. 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.

29. 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íaMERINDE.
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.

30. 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

31. 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

32. 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.

33. 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