trabajo de asia

1. REPÚBLICA BOLIVARIANA DE VENEZUELA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN PORLAMAR
Metodología para el análisis y diseño
de sistemas
C.I :23770856
nombre: Jesús aular
prof, lcdo: Jonatán Fernández
Porlamar, octubre 2015

2. Introducción
En la actualidad y el mercado de la informática del análisis y diseño de sistemas existen una
gran rama de metodologías ,herramienta que utilizan las empresas del Software , empresas en
general o personas asociadas al mundo informatico que llevan a cabo o implementa esta
metodologías para optimizar sus objetivo de una forma mas efectiva.

3. Definiciones:
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.
Metodología: es un vocablo generado a partir de tres palabras de origen griego: meta (“más
allá”), odòs (“camino”) y logos (“estudio”). El concepto hace referencia al plan de
investigación que permite cumplir ciertos objetivos en el marco de una ciencia. La
Metodología es muy importante en el mundo de la ciencia y los conocimientos,
refiriéndonos en este caso bajo el concepto de Método Científico, aunque también es
aplicable por ejemplo al ámbito laboral, donde tenemos una Metodología de Trabajo que
nos lleva a lograr un mayor rendimiento y productividad, como también una Metodología
de Estudio que nos permite alcanzar una mayor eficiencia a la hora de estudiar y realizar
alguna labor educativa o didáctica.
Metodología para el análisis y diseño de sistemas:
1. Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling
Language) 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, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar 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 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, 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.

4. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.
Diagrama de caso de uso UML:
2. 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
Fases o Etapas de Metodología RAD de James Martin.
Esta metodología consta de 4 etapas a saber:

5. 1) 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.
2) 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.
3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca
con los usuarios finalizan 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.
4) 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.
3. Metodología de Jeffrey Whitten: Teniendo entonces una idea clara de los conceptos,
relaciones y diferencias entre datos, información y conocimiento, se hace entonces
importante, mencionar algunos conceptos tales como “sistema”, “sistema de información” y
“sistema de información informático” ya que aunque sus definiciones puedan parecerse e
incluso superponerse, poseen mínimos detalles que marcan la diferencia. 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. Los Sistemas de Información han sido
conceptualizados por distintos investigadores y expertos del área, los definen como “un
conjunto de componentes interrelacionados que recolectan o recuperan, procesan,
almacenan y distribuyen información para apoyar la toma de decisiones y el control de una
organización”. Una definición mucho más concreta se podría dilucidar como “un conjunto
de personas, datos, procesos y tecnología de la información que interactúan para recoger,
procesar, almacenar y proveer la información necesaria para el correcto funcionamiento de
la organización.
4. Metodología del Proceso Unificado de Desarrollo de Software RUP: es el resultado de
varios años de desarrollo y uso práctico en el que se han unificado técnicas de desarrollo, a
través del UML, y trabajo de muchas metodologías utilizadas por los clientes. La versión
que se ha estandarizado vió la luz en 1998 y se conoció en sus inicios como Proceso

6. Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este proceso de
desarrollo.
 Como RUP es un proceso, en su modelación define como sus principales elementos:
 Trabajadores (“quién”)
 Define el comportamiento y responsabilidades (rol) de un individuo, grupo de
individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo.
Ellos realizan las actividades y son propietarios de elementos.
 Actividades (“cómo”)
 Es una tarea que tiene un propósito claro, es realizada por un trabajador y manipula
elementos.
 Artefactos (”qué”)
 Productos tangibles del proyecto que son producidos, modificados y usados por las
actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y
ejecutables.
 Flujo de actividades (“Cuándo”)
 Secuencia de actividades realizadas por trabajadores y que produce un resultado de
valor observable.
 En RUP se han agrupado las actividades en grupos lógicos definiéndose 9 flujos de
trabajo principales. Los 6 primeros son conocidos como flujos de ingeniería y los tres
últimos como de apoyo. En la figura 2.1 se representa el proceso en el que se grafican
los flujos de trabajo y las fases y muestra la dinámica expresada en iteraciones y puntos
de control.
 Flujos de trabajo:
 Modelamiento del negocio: Describe los procesos de negocio, identificando quiénes
participan y las actividades que requieren automatización.
 Requerimientos: Define qué es lo que el sistema debe hacer, para lo cual se identifican
las funcionalidades requeridas y las restricciones que se imponen.
 Análisis y diseño: Describe cómo el sistema será realizado a partir de la funcionalidad
prevista y las restricciones impuestas (requerimientos), por lo que indica con precisión
lo que se debe programar.
 Implementación: Define cómo se organizan las clases y objetos en componentes, cuáles
nodos se utilizarán y la ubicación en ellos de los componentes y la estructura de capas
de la aplicación.
 Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.
 Instalación: Produce reléase del producto y realiza actividades (empaque, instalación,
asistencia a usuarios, etc.) para entregar el software a los usuarios finales.
 Administración del proyecto: Involucra actividades con las que se busca producir un
producto que satisfaga las necesidades de los clientes.
 Administración de configuración y cambios: Describe cómo controlar los elementos
producidos por todos los integrantes del equipo de proyecto en cuanto a:
utilización/actualización concurrente de elementos, control de versiones, etc.
 Ambiente: Contiene actividades que describen los procesos y herramientas que
soportarán el equipo de trabajo del proyecto; así como el procedimiento para
implementar el proceso en una organización.
 Fases:
 Conceptualización (Concepción o Inicio): Se describe el negocio y se delimita el
proyecto describiendo sus alcances con la identificación de los casos de uso del sistema.

7.  Elaboración: Se define la arquitectura del sistema y se obtiene una aplicación ejecutable
que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a
profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la
base de la comprensión del sistema completo y los requerimientos (funcionales y no
funcionales) identificados de acuerdo al alcance definido.
 Construcción: Se obtiene un producto listo para su utilización que está documentado y
tiene un manual de usuario. Se obtiene 1 o varios reléase del producto que han pasado
las pruebas. Se ponen estos reléase a consideración de un subconjunto de usuarios.
 Transición: El reléase ya está listo para su instalación en las condiciones reales. Puede
implicar reparación de errores.
El ciclo de vida de RUP se caracteriza por:
1) Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros
necesitan y desean, lo cual se capta cuando se modela el negocio y se representa a
través de los requerimientos. A partir de aquí los casos de uso guían el proceso de
desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos
de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo).
2) Centrado en la arquitectura: La arquitectura muestra la visión común del sistema
completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo
que describe los elementos del modelo que son más importantes para su construcción,
los cimientos del sistema que son necesarios como base para comprenderlo,
desarrollarlo y producirlo económicamente. RUP se desarrolla mediante iteraciones,
comenzando por los CU relevantes desde el punto de vista de la arquitectura. Tal como
se aprecia en la figura 2.2, el modelo de arquitectura se representa a través de los
diagramas de UML.
Vista del modelo de arquitectura.
3) Iterativo e Incremental: Aunque la figura 2.1 puede sugerir que los flujos de trabajo se
desarrollan en cascada, la “lectura” de este grafico tiene que ser vertical y horizontal.
RUP propone que cada fase se desarrolle en iteraciones. Una iteración involucra
actividades de todos los flujos de trabajo, aunque desarrolla fundamentalmente algunos
más que otros. Por ejemplo, una iteración de elaboración centra su atención en el
análisis y diseño, aunque refina los requerimientos y obtiene un producto con un
determinado nivel, pero que irá creciendo incrementalmente en cada iteración.
4) Aunque cada iteración tiene que proponerse un incremento en el proceso de desarrollo,
todas deben aportar al principal resultado de la fase en la que se desarrolla, por lo que
los puntos de control evalúan:
• Conceptualización Objetivos
• Elaboración Arquitectura
• Construcción Funcionalidad operativa
• Transición Reléase del sistema
Para lograr estos cuatro hitos, hay que construir determinados artefactos definidos dentro de los
flujos de trabajo involucrados.
5. Metodología Kendall & Kendall.

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

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

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

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

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

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

17. Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de
sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a
cabo durante cada una de las fases.
El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de
sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar
a la fase previa y modificar el trabajo realizado.
6. Metodología de Administración de Relaciones (RMM)
Es un proceso de análisis , diseño y desarrollo de aplicaciones hipermedia. Los elementos
principales de esta metodología son:
Modelo E-R (Entidad-Relación)
Modelo RMDM (Relationship Management Data Model).
La metodología fue creada por Isakowitz, Stohr y Balasubramanian.
Esta metodología es apropiada para dominios con estructuras regulares, es decir, con clases
de objetos bien definidos, y con claras relaciones entre esas clases.
El modelo propone un lenguaje que permite describir los objetos del dominio, sus
interrelaciones y los mecanismos de navegación hipermedia de la aplicación. Los objetos del
dominio se definen con la ayuda de entidades, atributos y relaciones asociativas. El modelo
introduce el concepto de slice con el fin de modelizar los aspectos unidos a la presentación de
las entidades.
Ante las limitaciones que ofrecía RMM, sus creadores analizaron la estructura de navegación de
RMM y propusieron añadir dos nuevos y tipos de Slices:
Slice Híbridos: permiten combinar atributos de diferentes entidades y estructuras de acceso.
Slice Mínimos: es la mínima parte de una entidad que es necesaria para identificar uno de sus
elementos y que se utilizara como ancla.
M-Slice: permiten combinar primitivas de acceso con otros slices de otras entidades para crear
un m-slice.

18. 7. METODOLOGIA ORIENTADA A OBJETO
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:
1. 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 elsistema 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.
2. 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

19. en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para
afrontar el problema.
3. 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.).
4. 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:
1.
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.
2. 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.
3. 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
8. Metodología de Sistemas Expertos por David Rolston. Un Sistema Experto (SE), es
básicamente unprogramade computadorabasadoen conocimientosyraciocinioque lleva
a cabo tareas que generalmente sólorealizaunexpertohumano;es decir, es un programa
que imitael comportamientohumanoenel sentidode que utilizalainformación que le es
proporcionadaparapoderdar una opiniónsobre untemaenespecial. Se puede decir que
losSistemasExpertossonel primerresultadooperacional de laInteligencia artificial, pues
logran resolver problemas a través del conocimiento y raciocinio de igual forma que lo
hace el experto humano. Metodología del Software Educativo por Álvaro Galvis (ISE). Es
una metodologíade desarrollode software que contempla una serie de fases o etapas de

20. un proceso sistemático atendiendo a: análisis, diseño, desarrollo, prueba y ajuste, y por
último implementación.
Etapa 1: Análisis Características de la población objetivo: edad (física y mental), sexo,
características físicas y mentales (si son relevantes), experiencias previas, expectativas,
actitudes, aptitudes, intereses o motivadores por aprender. Conducta de entrada y campo
vital: nivel escolar, desarrollo mental, físico o psicológico, entorno familiar y escolar, etc.
Etapa 2: Diseño Educativo (este debe resolver las interrogantes que se refieren al alcance,
contenido y tratamiento que debe ser capaz de apoyar el Sistema Educativo). Etapa
3: Desarrollo En esta fase se implementa la aplicación usando la información obtenida
anteriormente. Tomando en cuenta las restricciones que se tengan.
9. 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 último
implementación.
Etapas:
Etapa 1: Análisis
Características de la población objetivo: edad (física y mental), sexo, características físicas y
mentales (si son relevantes), experiencias previas, expectativas, actitudes, aptitudes, intereses o
motivadores por aprender.
Conducta de entrada y campo vital: nivel escolar, desarrollo mental, físico o psicológico,
entorno familiar y escolar, etc.
Problema o necesidad a atender: Para establecer la necesidad se puede recurrir a los
mecanismos de análisis de necesidades educativas en. Estos mecanismos usan
entrevistas, análisis de resultados académicos, etc. para detectar los problemas o
posibles necesidades que deben ser atendidas. El problema o necesidad no tiene que
estar necesariamente relacionado con el sistema educativo formal, pueden ser
necesidades sentidas, económicas, sociales, normativas, etc.
Principios pedagógicos y didácticos aplicables: se debe analizar cómo se ha llevado a
cabo el proceso de enseñanza-aprendizaje para establecer cómo debe enfocarse el
ambiente, qué factores tomar en cuenta, qué objetivos debe cumplir.

21. Justificación de uso de los medios interactivos: Para cada problema o necesidad
encontrada se debe establecer una estrategia de solución contemplando diferentes
posibilidades. El apoyo informático debe ser tomado en cuenta siempre y cuando no
exista un mecanismo mejor para resolver el problema: soluciones administrativas, ver
si el problema se soluciona al tomar decisiones de tipo administrativo; soluciones
académicas, cambios en metodologías de clase; mejoras a los medios y materiales de
enseñanza contemplando el uso de medios informáticos. Una vez que se han
analizado todas las alternativas se puede decir por qué el uso de medios informáticos
es una buena solución. La justificación se puede basar en la no existencia de otro
medio mejor y en la relación costo-beneficio para la institución pues puede ser que
exista una mejor solución pero que demande mayor tiempo y esfuerzo o un mayor
costo económico, etc.
Diagramas de interacción: Permiten ver secuencias de interacción entre el usuario y la
aplicación, representando lo que se espera del diálogo y dando más detalle a la
descripción textual de la descripción de la aplicación. Los diagramas de interacción
son un formalismo que permite ver la secuencia de acciones entre diferentes partes de
la aplicación involucrada en llevar a cabo determinada actividad. Es importante ver la
secuencia de acciones para cada escenario de interacción. Con base en estos
diagramas se pueden ver cuáles pueden ser las necesidades de información en cada
escenario de interacción y se puede ir pensando en cuáles pueden ser los algoritmos
que serán usados.
Etapa 2: Diseño
Educativo (este debe resolver las interrogantes que se refieren al alcance, contenido y
tratamiento que debe ser capaz de apoyar el Sistema Educativo).
Comunicacional (es donde se maneja la interacción entre usuario y máquina, se
denomina interfaz).
Computacional (con base a las necesidades se establece qué funciones es deseable
que cumpla el Sistemas Educativo en apoyo de sus usuarios, el docente y los
estudiantes).
Etapa 3: Desarrollo
En esta fase se implementa la aplicación usando la información obtenida
anteriormente. Tomando en cuenta las restricciones que se tengan.

22. Etapa 4: Prueba Piloto
En esta etapa se pretende ayudar a la depuración del Sistema Educativo 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 Sistema Educativo 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 la funcionalidad requerida.
10. La Metodología de Sistemas Blandos (SSM por sus siglas en inglés) de Peter Checkland
es una técnica cualitativa que se puede utilizar para aplicar los sistemas estructurados a las
situaciones asistémicas. Es una manera de ocuparse de problemas situacionales en los cuales
hay una actividad con un alto componente social, político y humano. Esto distingue el SSM
de otras metodologías que se ocupan de los problemas DUROS que están a menudo más
orientados a la tecnología.
El SSM aplica los sistemas estructurados al mundo actual de las organizaciones humanas.
Pero crucialmente sin asumir que el tema de la investigación es en sí mismo es un sistema
simple. El SSM por lo tanto es una manera útil de acercarse a situaciones complejas y a las
preguntas desordenadas correspondientes.
PASOS DE LA METODOLOGÍA DE SISTEMAS BLANDOS. PROCESO
Se deben tomar las siguientes medidas (a menudo se requieren varias repeticiones):
Investigue el problema no estructurado.
Exprese la situación del problema a través de “gráficas enriquecidas”. Las gráficas
enriquecidas son los medios para capturar tanta información como sea posible referente a la
situación problemática. Una gráfica enriquecida puede mostrar límites, la estructura, flujos de
información, y los canales de comunicación. Pero particularmente muestra el sistema humano
detrás de la actividad. Éste es el elemento que no está incluido en modelos como: diagramas de
flujo o modelos de clase.

23. Definiciones de fondo de los sistemas relevantes. ¿De qué diversas perspectivas podemos
observar esta situación problemática?
Las definiciones de fondo se escriben como oraciones que elaboren una transformación. Hay
seis elementos que definen como bien formulada a una definición de fondo. Se resumen en las
siglas CAPWORA:
Cliente. Todos los que pueden ganar algún beneficio del sistema son considerados clientes del
sistema. Si el sistema implica sacrificios tales como despidos, entonces esas víctimas deben
también ser contadas como clientes.
Actores. Los agentes transforman las entradas en salidas y realizan las actividades definidas en
el sistema.
Proceso de transformación. Este se muestra como la conversión de las entradas en salidas.
Weltanschauung. La expresión alemana para la visión del mundo. Esta visión del mundo hace el
proceso de transformación significativo en el contexto.
Dueño. Cada sistema tiene algún propietario, que tiene el poder de comenzar y de cerrar el
sistema (poder de veto).
Restricciones ambientales. Éstos son los elementos externos que deben ser considerados. Estas
restricciones incluyen políticas organizacionales así como temas legales y éticos.
Modelos conceptuales.
Concepto formal del sistema.
El otro sistema estructurado.
Comparación de 4 con 2.
Cambios factibles, deseables.
Acción para mejorar la situación problemática.
11. MetodologíaMeRinde surge de lacombinaciónyadaptaciónde modelosy
metodologíasampliamente utilizadasparael desarrollode software ylareingenieríade
procesosdel negocio.Estametodologíaestáfuertemente fundamentadaenlos
requerimientosdel CentroNacionalde Tecnologíade Información(CNTI) yenvarias
metodologíascomoel ProcesoUnificado(UP) especialmente.
Pretende entre susprincipalesobjetivosapoyaralas comunidadesde desarrollode
software libre ensusproyectos,suministrandolasherramientasnecesariasparaque estos
cumplancon unprocesode desarrolloydocumentaciónde sussistemas.
MeRinde esconcebidaparaabarcar el desarrollocompletode sistemasde software de
diversacomplejidadymagnitud,porlocual su estructuraresponde adesarrollosmáximosy
deberáadaptarse ydimensionarseencadamomentode acuerdoa lascaracterísticas
particularesde cada proyecto.Dadala adaptabilidadque puede sufrirlametodología,esta

24. puede llegarseaaplicarbajoun enfoque ágil,locual nose detallaenlapresente versión,
perono se descarta suempleo.
Así mismo,estapermite producirymantenerunalibreríade plantillasreutilizables para
ingenieríade software.Estábasadaencomponentes,locual quiere decirque el sistema
software enconstrucciónestáformadoporcomponentessoftwareinterconectadosatravés
de interfacesbiendefinidas.Además,lametodologíautilizael Lenguaje Unificadode
Modelado(UnifiedModelingLanguage,UML) para preparar todoslosdiagramasde un
sistemasoftware.
Con el procesode desarrolloyconlas plantillasde estametodologíase buscaa su vez
estimularconlatransferenciadel conocimientoentre las comunidadesdesarrolladorasde
software libre,conlocual no solose pretende que seacompartidoloscódigosde los
sistemassinoque tambiénse compartanladocumentacióncomoguíade referenciapara
mejorasportercerosal sistemaopara que sirvacomo modeloaotras comunidadesparael
desarrollode suspropiossistemas.
12. Metodología Scrum
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software,cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa
en construir primero la funcionalidad de mayor valor para el cliente y en los principios de
inspección continua, adaptación, auto-gestión e innovación.
¿Cuándo se utiliza?
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado
que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el
software con los objetivos de negocio de su empresa,ya que puede introducir cambios
funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que
forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para

25. desarrollar sus capacidades.
Beneficios
Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le
aporta cada requisito /historia del proyecto, el equipo los estima y con esta información
el Product Owner establece su prioridad. De manera regular, en las demos de Sprint
el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se
feedback al equipo.
Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología está
diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.
Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por completo.
Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión
funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.
Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos
para organizarse.
Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de
inversión.
Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente,es posible estimar
fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el
Backlog.
Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer
lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.

26. Conclusión
Ya manejandoestasmetodologíasysusdistintasetapasse puede afirmaque manejandoun
buenconceptode estasmetodologíasse puede hacerunusomas organizadooefectivode la
informáticaode los Software engeneral ahorrándonostiempode trabajoyotorgándonosuna
mejorcapacidadpara detectarerrores.

27. Referencias bibliográficas y electronicas
http://mundoinformatico321.blogspot.com/2012/12/metodologia-de-james-martin-y-uml.html
https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado
http://es.slideshare.net/andoniv2/repblica-bolivariana-de-venezuela-41293595
http://www.eumed.net/libros-
gratis/2009c/587/Proceso%20Unificado%20de%20Desarrollo%20de%20Software.htm
http://mundoinformatico321.blogspot.com/2012/11/metodologia-kendall-kendall.html
http://lametodologiarmm.blogspot.com/
http://franklinmorillouba.blogspot.com/2010/11/metodologia-orientada-objetos-fases-y.html
http://es.slideshare.net/andoniv2/repblica-bolivariana-de-venezuela-41293595
http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-software-educativo-
por.html
http://www.12manage.com/methods_checkland_soft_systems_methodology_es.html
http://www.merinde.net/
https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html