Aná lisis y disen o de sistemás Metodologías

Realizado por: Andoni Vasquez

Porlamar, Noviembre de 2014

Lenguaje Unificado de Modelado (UML)

El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas

estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de

lo que estos diagramas y símbolos significan.

Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a

objetos, ahora los modeladores sólo tienen que aprender una única notación. UML se

puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de

hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales

modelar sistemas.

Metodología del Ciclo de Vida de un Sistema de James Martín

Metodología para el desarrollo de sistemas creada para disminuir radicalmente el tiempo

necesario para diseñar e implementar Sistemas de Información. El RAD cuenta con una

participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas

y generadores de código

Metodología de Jeffrey Whitten

A continuación se detallan las fases de esta metodología para el desarrollo de los sistemas

de información.

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

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.

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.

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

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.

Fase VIII Depuración. La depuración es el proceso metodológico para encontrar y reducir

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

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

Existen aplicaciones que permiten ayudar a analistas, programadores y diseñadores en

estas tareas, pero es la habilidad del mismo el factor más determinante para la efectividad

y eficiencia del proceso de depuración.

Metodología del Proceso Unificado de Desarrollo de Software.

El proceso unificado conocido como RUP, es un modelo de software que permite el

desarrollo de software a gran escala, mediante un proceso continuo de pruebas y

retroalimentación, garantizando el cumplimiento de ciertos estándares de calidad.

Aunque con el inconveniente de generar mayor complejidad en los controles de

administración del mismo. Sin embargo, los beneficios obtenidos recompensan el esfuerzo

invertido en este aspecto.

Metodología de Kendall y 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.

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

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 (trozo) con el fin de modelizar los aspectos unidos a

la presentación de las entidades. Un slice corresponde a un subconjunto de atributos de

una misma entidad destinados a ser presentados de forma agrupada. La navegación se

modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y

bidireccional) que permiten especificar la navegación entre slices, y visita guiada

condicional, índice condicional y agrupación, que permiten especificar la navegación entre

entidades. El esquema completo del dominio y de la navegación de la aplicación se

denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del

método.

Metodología Orientada a Objetos.

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.

Metodología de Ingeniería de Software Educativo (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 de Sistemas Blandos (SSM) de Peter Checkland

La naturaleza de una metodología siempre deriva de la concepción de los métodos que

emplea una ciencia, ya desde muy antes se fueron acumulando conceptos de designar

"método", describiéndolo como la forma de hacer algo (el modo de obrar) o

posteriormente el comportamiento experto en la formulación de los pensamientos de uno

mismo, pero siempre como base de una metodología.

El desarrollo de MSB para Checkland(1993), "No tiene como resultado el establecimiento

de un método que en cualquier situación particular se tiene que reducir a un método

adecuado únicamente aesa situación particular", este aspecto de suma importancia porque

considera la complejidad del mundo real en continuo cambio, no pudiendo establecerse

dos casos problemáticos iguales a los cuales se podría abordar de igual modo. Además,

asume que la Metodología de Sistemas Blandos es un intermedio en estatus, entre una

Filosofía y una Técnica o un método.

Considerándola como filosofía porque es una pauta no especifica (amplia) para la acción,

dejando la suficiente libertad en su accionar y por otra parte tiene de técnica porque es un

programa de acción específico y preciso, en donde la Filosofía le indica el "Que" y una

técnica le indica el "como", determinándose tanto el "Que" y el "Como" de la Metodología

de Sistemas Blandos.

Metodología MERINDE.

La Metodología MeRinde surge de la combinación y adaptación de modelos y

metodologías ampliamente utilizadas para el desarrollo de software y la reingeniería de

procesos del negocio. Esta metodología está fuertemente fundamentada en los

requerimientos del Centro Nacional de Tecnología de Información (CNTI) y en varias

metodologías como el Proceso Unificado (UP) especialmente.

Pretende entre sus principales objetivos apoyar a las comunidades de desarrollo de

software libre en sus proyectos, suministrando las herramientas necesarias para que estos

cumplan con un proceso de desarrollo y documentación de sus sistemas.

MeRinde es concebida para abarcar el desarrollo completo de sistemas de software de

diversa complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos

y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características

particulares de cada proyecto. Dada la adaptabilidad que puede sufrir la metodología,

esta puede llegarse a aplicar bajo un enfoque ágil, lo cual no se detalla en la presente

versión, pero no se descarta su empleo.

Metodología SCRUM

Es un modelo de referencia que define un conjunto de prácticas y roles, y que puede

tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará

durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los

procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que

representa a los stakeholders (interesados externos o internos), y el Team que incluye a los

desarrolladores.