análisis y diseño de sistemas1
Post on 09-Aug-2015
102 Views
Preview:
TRANSCRIPT
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.
top related