SlideShare ist ein Scribd-Unternehmen logo
1 von 37
Instituto Universitario Politécnico “Santiago Mariño”
Semestre: V . Asignatura: Análisis y Diseño de Sistemas
Porlamar, Nueva Esparta.
Metodologías para el
Diseño de Sistemas
Realizado por:
Isidro González C.I. 25.547.661
Porlamar, Mayo de 2015.
Introducción
En la actualidad la mayoría de los usuarios de microcomputadoras tienen acceso a
un sistema de información o forman parte del mismo. Todas las organizaciones
cuentan con un sistema de información de algún tipo, que sus empleados deben
utilizar.
La creación o establecimiento de un nuevo sistema de información en la
organización, puede ser una tarea compleja. Para encarar este tipo de situaciones
existe un proceso de análisis y diseño de sistemas que auxilia en la resolución de
tales problemas. El análisis y diseño de sistemas proporciona una guía útil que
busca disminuir las situaciones de fracaso o errores al acometer estos procesos.
Este procedimiento se lleva a cabo, en el llamado ciclo de vida de desarrollo de
sistemas. Este ciclo puede repetirse indefinidamente, porque las organizaciones
siempre se ven sometidas a cambios, y sus sistemas deben renovarse
periódicamente.
La finalidad de este informe es la de concienciar al lector acerca de una variedad
de metodologías utilizadas para el análisis y diseño de sistemas de información.
Contenido
Método y Metodología
Un método es el procedimiento utilizado para llegar a un fin. Su significado original
señala el camino que conduce a un lugar.
La palabra método puede referirse a diversos conceptos. Por ejemplo, a
los métodos de clasificación científica. Esta es la disciplina que permite a los
biólogos agrupar y separar en categorías a los diversos organismos y conjuntos.
El método científico, por su parte, es la serie de pasos que sigue una ciencia para
obtener saberes válidos (es decir, que pueden verificarse a través de un
instrumento fiable). Gracias al respeto por un método científico, un investigador
logra apartar su subjetividad y obtiene resultados más cercanos a la objetividad o
a lo empírico.
Metodología es un vocablo generado a partir de tres palabras de origen
griego:metà (“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ías para el Análisis y Diseño de Sistemas
Lenguaje Unificado de Modelado
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.
Se trata de un estándar que se ha adoptado a nivel internacional por numerosos
organismos y empresas para crear esquemas, diagramas y documentación
relativa a los desarrollos de software (programas informáticos).
Las etapas y actividades en el desarrollo basado en UML son:
Análisis de Requerimientos
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual
se le va a presentar la solución que está buscando
Actividades técnicas de esta etapa:
1. Identificar Casos de Uso del sistema
2. Dar detalle a los casos de uso descritos
3. Definir una interfaz inicial del sistema (si es aplicable)
4. Desarrollar el modelo del mundo
5. Validar los modelos
Diseño del Sistema
En esta etapa se define una subdivisión en aplicaciones del sistema (si es lo
suficientemente grande) y la forma de comunicación con los sistemas ya
existentes con los cuales debe interactuar
La única actividad técnica que se realiza durante esta fase es Identificar la
arquitectura del sistema, lo cual consiste en:
Definir componentes del sistema, las aplicaciones y su ubicación. Representarlos
por medio de nodos, componentes y objetos activos (representando las
aplicaciones) dentro de los nodos.
Definir mecanismos de comunicación. Expresarlos por medio de asociaciones de
dependencia entre los nodos, componentes o aplicaciones y, si es conocido,
agregar un estereotipo para definir el protocolo de comunicación requerido.
Agregar notas con restricciones, rendimiento esperado y demás detalles de las
conexiones.
Particularizar los casos de uso a la arquitectura planteada. Refinar los casos de
uso ya existentes de la etapa anterior para adecuarse a la arquitectura planteada.
Validar arquitectura. Comprobar la validez técnica, económica y organizacional de
la propuesta.
Diseño Detallado
En esta etapa se adecúa el análisis a las características específicas del ambiente
de implementación y se completan las distintas aplicaciones del sistema con los
modelos de control, interfaz o comunicaciones, según sea el caso.
Durante esta etapa ocurren las siguientes actividades:
1. Agregar detalles de implementación al modelo del mundo
2. Desarrollar el modelo de interfaz
3. Desarrollar los modelos de control, persistencia y comunicaciones
Implementación y Pruebas
Se desarrolla el código de una manera certificada. Sus actividades son:
1. Definir estándares de programación
 Asimilar los idioms aplicables al lenguaje
 Conocer y adecuar estándares de programación al lenguaje
 Definir estructura de directorios
 Diseñar makefiles
2. Codificación y pruebas unitarias
 Revisiones de código
 Tratamiento de Trace y Log
3. Pruebas de módulos y de sistema
 Casos de prueba
 Procedimiento de instalación
Metodología del Ciclo de Vida de un Sistema de James Martín.
Esta metodología de desarrollo de Software es mejor conocida como Metodología
RAD (Rapid Application Development) o Desarrollo rápido de Aplicaciones, y fue
creada por el gurú de computación James Martin en 1991. Está orientada a
disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas
de Información, el RAD cuenta con una participación intensa del usuario, sesiones
JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad
requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y
herramientas.
Más que un modelo, se puede considerar una secuencia de eventos en el
desarrollo de un sistema de información, ya que “... un modelo describe la
estructura de cómo se desarrollará el proyecto”. (Raccoon, 1995)
Esta metodología consta de 4 etapas a seguir:
Etapa I. 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 II. 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.
Etapa III. 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.
Etapa IV. Implementación
Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio
del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los
usuarios.
Metodología de Jeffrey Whitten
Una metodología es una versión amplia y detallada de un ciclo de vida completo
del desarrollo de un sistema que incluye: 1.- Tareas paso a paso para cada fase;
2.- funciones individuales y en grupo desempeñadas en cada tarea; 3.- productos
resultantes y normas de calidad para cada tarea, y 4.- técnicas de desarrollo que
se utilizarán en cada tarea.
A continuación se detallan las fases de esta metodología para el desarrollo de los
sistemas de información.
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
“No intentes arreglarlo a menos que lo hayas comprendido”. Esta frase consiste en
estudiar y analizar el sistema actual. Se identificarán sus problemas, como 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
proporcionará información con relación a la factibilidad del concepto. Se tomará
como un plan piloto o prueba del sistema. El prototipo diseñado podrá ser
modificado con facilidad y en el momento que así lo requiera según sea el caso.
Fase IV. Diseño de la topología y de los servicios
A partir de los usuarios involucrados con el sistema, y utilizando diversos
instrumentos y técnicas de recolección de datos, el estudio de datos y formas
usadas por la organización se ubicarán los requierimientos 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 colocará 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 de 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. Dirante estas
pruebas, además de hacer observaciones necesarias durante algunas consultas
reales se usará del sistema de información, también se llenará 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. E general, las
tareas de depuración suelen ser engorrosas y agotadoras. Existen aplicaciones
que permiten ayudar a analistas, programadores y diseñadores en estas tareas,
pero la habilidad del mismo es el factor más determinante para la efectividad y
eficiencia del proceso de depuración.
Metodología del Proceso Unificado de Desarrollo de Software (RUP).
Es un marco de desarrollo de software que se caracteriza por estar dirigido
por casos de uso, centrado en la arquitectura y por ser iterativo e incremental.
El nombre Proceso Unificado se usa para describir el proceso genérico que
incluye aquellos elementos que son comunes a la mayoría de los refinamientos
existentes.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
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 vio la
luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0;
de ahí las siglas con las que se identifica a este proceso de desarrollo.
Fases del Proceso Unificado de Desarrollo de Software:
La fase de concepción o inicio tiene por finalidad definir la visión, los objetivos y el
alcance del proyecto, tanto desde el punto de vista funcional como del técnico,
obteniéndose como uno de los principales resultados una lista de los casos de uso
y una lista de los factores de riesgo del proyecto. El principal esfuerzo está
radicado en el Modelamiento del Negocio y el Análisis de Requerimientos. Es la
única fase que no necesariamente culmina con una versión ejecutable.
La fase de elaboración tiene como principal finalidad completar el análisis de los
casos de uso y definir la arquitectura del sistema, además 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.
La fase de construcción está compuesta por un ciclo de varias iteraciones, en las
cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los
factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma
temprana con versiones el sistema que satisfacen los principales casos de uso.
Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima
iteración.
La fase de transición se inicia con una versión “beta” del sistema y culmina con el
sistema en fase de producción.
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.
Fase I: Identificación de problemas, oportunidades y objetivos
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
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
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
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
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 de los 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
En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera
conjunta con los programadores para desarrollar cualquier software original
necesario. Entre las técnicas estructuradas para diseñar y documentar software se
encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y
el pseudocódigo.
Durante esta fase el analista trabaja con los usuarios para desarrollar
documentación efectiva para el software, como manuales de procedimientos,
ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en
archivos “léame” que se integrarán al nuevo software.
La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en
caso de que surjan problemas derivados de este uso. Los programadores
desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores
sintácticos de los programas de cómputo.
Fase VI: Prueba y mantenimiento del sistema
Antes de poner en funcionamiento el sistema es necesario probarlo es mucho
menos costoso encontrar los problemas antes que el sistema se entregue a los
usuarios.
Una parte de la pruebas la realizan los programadores solos, y otra la llevan a
cabo de manera conjunta con los analistas de sistemas. Primero se realizan las
pruebas con datos de muestra para determinar con precisión cuáles son los
problemas y posteriormente se realiza otra con datos reales del sistema actual.
El mantenimiento del sistema de información y su documentación empiezan en
esta fase y se llevan de manera rutinaria durante toda su vida útil.
Fase VII: Implementación y evaluación del sistema
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.
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.
Metodología de Administración de Relaciones (RMM)
se define como un proceso de análisis, diseño y desarrollo de
aplicaciones hipermedia. Los elementos principales de este método son el modelo
E-R (Entidad-Relación) y el modelo RMDM (Relationship Management Data
Model) basado en el modelo HDM. 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 definidas, y con claras relaciones
entre esas clases). Por ejemplo, catálogos o "frentes" de bases de
datos tradicionales. Según sus autores, está orientada a problemas con datos
dinámicos que cambian con mucha frecuencia, más que a entornos estáticos.
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. Las etapas son:
Primera etapa: representar los objetos del dominio con la ayuda del modelo
Entidad-Relación ampliado con relaciones asociativas (aquéllas que permiten
representar caminos navegacionales entre entidades puestos en evidencia en la
fase de análisis).
Segunda etapa: determinar la presentación del contenido de las entidades de la
aplicación así como su modo de acceso. El esquema obtenido como resultado de
esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relación
en el que cada entidad ha sido reemplazada por su esquema de entidad. Un
esquema de entidad está constituido por nodos (los trozos o slides) unidos por
relaciones estructurales.
Tercera etapa: definir los caminos de navegación inducidos por las relaciones
asociativas del esquema E-R+. A continuación, es posible definir estructuras de
acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicación de
accesos jerárquicos a niveles diferentes de los trozos de información. El esquema
RMDM resultante se obtiene añadiendo al esquema E-R+ las agrupaciones y
caminos navegacionales definidos en esta etapa.
Las cuatro etapas restantes consisten en:
 Definición del protocolo de conversión de elementos del diagrama RMDM en
objetos de la plataforma de desarrollo
 Concepción del interfaz usuario
 Concepción del comportamiento en ejecución
 Construcción del sistema y test
Metodología Orientada a Objetos
La metodología orientada a objetos ha derivado de las metodologías anteriores a
éste. Así como los métodos de diseño estructurado realizados guían a los
desarrolladores que tratan de construir sistemas complejos utilizando algoritmos
como sus bloques fundamentales de construcción, similarmente los métodos de
diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a
explotar el poder de los lenguajes de programación basados en objetos y
orientados a objetos, utilizando las clases y objetos como bloques de construcción
básicos.
Actualmente el modelo de objetos ha sido influenciado por un número de factores
no sólo de la Programación Orientada a Objetos, POO (Object Oriented
Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha
probado ser un concepto uniforme en las ciencias de la computación, aplicable no
sólo a los lenguajes de programación sino también al diseño de interfaces de
usuario, bases de datos y arquitectura de computadoras por completo. La razón
de ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a
la inherente complejidad de muchos tipos de sistemas.
Para definir el comportamiento de un objeto, se crean métodos, los cuales tienen
una apariencia y un comportamiento igual al de las funciones en otros lenguajes
de programación, los lenguajes estructurados, pero se definen dentro de una
clase. Los métodos no siempre afectan a un solo objeto; los objetos también se
comunican entre sí mediante el uso de métodos. Una clase u objeto puede llamar
métodos en otra clase u objeto para avisar sobre los cambios en el ambiente o
para solicitarle a ese objeto que cambie su estado.
Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto.
Además, como se puede observar de los diagramas, las variables del objeto se
localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el
núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las
variables de un objeto con la protección de sus métodos se le
llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para
esconder detalles de la puesta en práctica no importantes de otros objetos.
Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier
tiempo sin afectar otras partes del programa.
Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en
una membrana protectora de métodos— es una representación ideal de un objeto
y es el ideal por el que los diseñadores de sistemas orientados a objetos luchan.
Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en
práctica, un objeto puede querer exponer algunas de sus variables o esconder
algunos de sus métodos.
El encapsulamiento de variables y métodos en un componente de software
ordenado es, todavía, una simple idea poderosa que provee dos principales
beneficios a los desarrolladores de software:
Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como
darle mantenimiento, independientemente del código fuente de otros objetos. Así
mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado
y conducta.
Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que
otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede
mantener información y métodos privados que pueden ser cambiados en cualquier
tiempo sin afectar a los otros objetos que dependan de ello.
Los objetos proveen el beneficio de la modularidad y el ocultamiento de la
información. Las clases proveen el beneficio de la reutilización. Los
programadores de software utilizan la misma clase, y por lo tanto el mismo código,
una y otra vez para crear muchos objetos.
En las implantaciones orientadas a objetos se percibe un objeto como un paquete
de datos y procedimientos que se pueden llevar a cabo con estos datos. Esto
encapsula los datos y los procedimientos. La realidad es diferente: los atributos se
relacionan al objeto o instancia y los métodos a la clase. ¿Por qué se hace así?
Los atributos son variables comunes en cada objeto de una clase y cada uno de
ellos puede tener un valor asociado, para cada variable, diferente al que tienen
para esa misma variable los demás objetos. Los métodos, por su parte,
pertenecen a la clase y no se almacenan en cada objeto, puesto que sería un
desperdicio almacenar el mismo procedimiento varias veces y ello va contra el
principio de reutilización de código.
Otro concepto muy importante en la metodología orientada a objetos es el
de herencia. La herencia es un mecanismo poderoso con el cual se puede definir
una clase en términos de otra clase; lo que significa que cuando se escribe una
clase, sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual,
la herencia dará acceso automático a la información contenida en esa otra clase.
Con la herencia, todas las clases están arregladas dentro de una jerarquía
estricta. Cada clase tiene una superclase (la clase superior en la jerarquía) y
puede tener una o más subclases (las clases que se encuentran debajo de esa
clase en la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases
hijas, heredan de las clases más altas, las clases padres.
Las subclases heredan todos los métodos y variables de las superclases. Es decir,
en alguna clase, si la superclase define un comportamiento que la clase hija
necesita, no se tendrá que redefinir o copiar ese código de la clase padre
. Metodología de Sistemas Expertos
Esta metodología consta de 6 etapas:
Etapa I. Análisis y Descripción del Problema
Fase 1.1 Descripción general del problema:
1.1.1.- Familiarización con el proceso sobre el cual se desea realizar el sistema
experto.
1.1.2.- Familiarización con los ambientes computacionales donde se encuentran
los datos a ser utilizados.
1.1.3.- Definición detallada del problema que motiva el desarrollo del sistema
experto.
Fase 1.2.- Análisis de Factibilidad para el desarrollo del Sistema Experto:
1.2.1.- La tarea a desarrollar requiere del conocimiento manejado por un experto.
1.2.2.- Disponibilidad del experto o equipo de expertos.
1.2.3.- La experticia es requerida en varios lugares simultáneamente.
1.2.4.- El sistema requiere del manejo de incertidumbre y aplicación de juicios
personales.
1.2.5.- Existe un grupo potencial de usuarios.
1.2.6.- Se dispone del tiempo para desarrollar el Sistema Experto.
Fase 1.3.- Análisis de datos: Verificación de la ubicación y forma de
representación de los datos a ser manejados por el sistema experto, considerando
el tipo de base de datos y plataforma computacional.
Fase 1.4.- Elección de la fuente de conocimiento: Es necesario contar con un
experto o un grupo de ellos que estén dispuestos a colaborar con el proyecto. Los
expertos deben ser reconocidos como tal por el grupo de usuarios.
Etapa II. Especificación de requerimientos.
Fase 2.1.- Estimación del perfil de los usuarios finales del Sistema Experto.
Fase 2.2.- Verificación de los requerimientos con el usuario.
Fase 2.3.- Determinación de los requerimientos de información: Se especifica la
información que debe producir el Sistema Experto y sus atributos tales como el
formato de presentación, la frecuencia de salida, sus usuarios directos y su
interconexión con otros programas.
Fase 2.4.- Determinación de los requerimientos funcionales: Consiste en la
definición de las funciones generales que debe satisfacer el Sistema Experto.
Fase 2.5.- Determinación de los requerimientos de la entrada de datos:
2.5.1.- Selección de las posibles de entrada al Sistema Experto.
2.5.2.- Identificación de las fuentes de datos.
2.5.3.- Especificación de los procesos de adquisición de datos.
2.5.4.- Especificación de los procesos de generación de parámetros.
2.5.5.- Caracterización de la interoperatibilidad entre las bases de datos que se
requieren en la implantación.
Fase 2.6.- Definición de los requerimientos de hardware y software para la
implantación del Sistema Experto.
2.6.1.- Especificación de la plataforma de hardware que se utilizará para el
desarrollo y operación del Sistema Experto.
2.6.2.- Determinación, análisis y selección de las herramientas de software
disponibles en el mercado para el desarrollo de Sistemas Expertos.
Etapa III. Análisis de costos, tiempo y recursos.
Fase 3.1.- Elaboración del plan de actividades de desarrollo e implantación.
Fase 3.2.- Estimación del tiempo requerido para el desarrollo del Sistema Experto.
Fase 3.3.- Estimación de los recursos computacionales (hardware-software)
requeridos para el desarrollo del Sistema Experto.
Fase 3.4.- Estimación de los costos de desarrollo.
Etapa IV: Ingeniería del Conocimiento.
Fase 4.1.- Adquisición del Conocimiento: Es donde el Ingeniero del Conocimiento
interactúa con el experto para obtener la información sobre la solución de los
problemas, así como las estrategias utilizadas para la obtención de cada solución.
Fase 4.2.- Estructuración del Conocimiento: En esta fase, el Ingeniero del
Conocimiento debe llevar a una base de conocimiento la información
proporcionada por el experto. El conocimiento puede ser de carácter superficial o
profundo dependiendo de la estructura interna y de las interacciones entre sus
componentes.
Etapa V: Diseño preliminar del Sistema Experto.
Fase 5.1.- Diseño preliminar de la arquitectura del Sistema Experto.
Fase 5.2.- Selección de la herramienta computacional de acuerdo a los
requerimientos surgidos en la etapa de Ingeniería del Conocimiento.
Fase 5.3.- Diseño preliminar de procesos de adquisición y almacenamiento de
datos.
Fase 5.4.- Diseño preliminar de procesos de interconexión.
5.4.1.- Integración Interna.
5.4.2.- Integración Externa.
5.4.3.- Selección de software auxiliar.
Fase 5.5.- Verificación del diseño preliminar del Sistema Experto.
Etapa VI: Desarrollo e Implantación del Sistema Experto.
Fase 6.1.- Construcción del prototipo.
Fase 6.2.- Validación del prototipo.
Fase 6.3.- Construcción de modelo operacional
Fase 6.4.- Prueba y depuración.
Fase 6.5.- Mantenimiento y actualización.
Metodología del Software Educativo
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.
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.
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.
Metodología de Sistemas Blandos (SSM)
La SSM de Peter Checkland es una metodología sistémica fundamentada en el
concepto de perspectiva o en el lenguaje de la metodología “Weltanschauung”. Un
“weltanschauung” representa la visión propia de un observador, o grupo de ellos,
sobre un objeto de estudio, visión ésta que afecta las decisiones que el(los)
observador(es) pueda(n) tomar en un momento dado sobre su accionar con el
objeto. La SSM toma como punto de partida la idealización de estos
“weltanschauung” para proponer cambios sobre el sistema que en teoría deberían
tender a mejorar su funcionamiento.
En este punto es conveniente aclarar la noción de “weltanschauung”, para ello se
puede considerar como ejemplo, las diferencias que entre un observador y otro
presenta el propósito de las universidades:
- Para algunos estudiantes pueden ser centros de estudio donde asisten para
formarse con miras a ingresar a un mercado de trabajo profesional, para otros
pueden ser centros donde tomar experiencia en la diatriba política, para otro grupo
pueden ser centros donde converge el conocimiento universal y acuden a entrar
en contacto con él, etc.
- Para algunos profesores pueden ser centros de enseñaza donde acuden a
laborar impartiendo conocimientos entre sus estudiantes, para otros son centros
de docencia e investigación donde, a través del desarrollo de la investigación,
nutren su actividad de docencia, siempre con la intención de brindar lo mejor
posible de sus conocimientos a sus estudiantes, así mismo para otro grupo de
profesores la universidad puede ser un centro donde ellos y los estudiantes
acuden a intercambiar experiencias dentro de un proceso interactivo de
enseñanza aprendizaje, etc.
Como se puede ver, en ambos casos, estudiantes y profesores, la visión que se
tiene sobre las universidades es diferente, e incluso entre estudiantes y profesores
se pueden tener diferentes visiones. Estas visiones son los “weltanschauung”
sobre las universidades, es importante hacer notar que éstos no son correctos o
erróneos, ni unos son mejores que otros, todos son igualmente válidos e incluso
complementarios.
Otro concepto importante para la SSM es el de sistema blando, según Checkland,
un sistema blando es aquel que está conformado por actividades humanas, tiene
un fin perdurable en el tiempo y presenta problemáticas inestructuradas o blandas;
es decir aquellas problemáticas de difícil definición y carentes de estructura, en las
que los fines, metas, propósitos, son problemáticos en sí.
La SSM está conformada por siete (7) estadios cuyo orden puede variar de
acuerdo a las características del estudio, a continuación se describen brevemente
estos estadios.
Estadio 1: La Situación Problema no Estructurada: en este estadio se pretende
lograr una descripción de la situación donde se percibe la existencia de un
problema, sin hacer hincapié en el problema en sí, esto es sin dar ningún tipo de
estructura a la situación.
Estadio 2: La Situación Problema Expresada: se da forma a la situación
describiendo su estructura organizativa, actividades e interrelación de éstas, flujos
de entrada y salida, etc.
Estadio 3: Definiciones Raíz de Sistemas Pertinentes: se elaboran definiciones de
lo que, idealmente, según los diferentes “weltanschauung” involucrados, es el
sistema. La construcción de estas definiciones se fundamenta en seis factores que
deben aparecer explícitos en todas ellas, estos se agrupan bajo el nemónico de
sus siglas en ingles CATWOE (Bergvall-Kåreborn et. al. 2004), a saber:
consumidores, actores, proceso de transformación, weltanschauung, poseedor y
restricción del ambiente.
Estadio 4: Confección y Verificación de Modelos Conceptuales: partiendo de los
verbos de acción presentes en las definiciones raíz, se elaboran modelos
conceptuales que representen, idealmente, las actividades que, según la definición
raíz en cuestión, se deban realizar en el sistema (Ramírez 1983). Existirán tantos
modelos conceptuales como definiciones raíz.
Este estadio se asiste de los subestadios 4a y 4b.
Estadio 4a: Concepto de Sistema Formal: este consiste en el uso de un modelo
general de sistema de la actividad humana que se puede usar para verificar que
los modelos construidos no sean fundamentalmente deficientes.
Estadio 4b: Otros Pensamientos de Sistemas: consiste en transformar el modelo
obtenido en alguna otra forma de pensamiento sistémico que, dadas las
particularidades del problema, pueda ser conveniente.
Estadio 5: Comparación de los modelos conceptuales con la realidad: se
comparan los modelos conceptuales con la situación actual del sistema
expresada, dicha comparación pretende hacer emerger las diferencias existentes
entre lo descrito en los modelos conceptuales y lo que existe en la actualidad en el
sistema.
Estadio 6: Diseño de Cambios Deseables, Viables: de las diferencias emergidas
entre la situación actual y los modelos conceptuales, se proponen cambios
tendientes a superarlas, dichos cambios deben ser evaluados y aprobados por las
personas que conforman el sistema humano, para garantizar con esto que sean
deseables y viables.
Estadio 7: Acciones para Mejorar la Situación Problema: finalmente este estadio
comprende la puesta en marcha de los cambios diseñados, tendientes a
solucionar la situación problema, y el control de los mismos. Este estadio no
representa el fin de la aplicación de la metodología, pues en su aplicación se
transforma en un ciclo de continua conceptualización y habilitación de cambios,
siempre tendiendo a mejorar la situación.
. Metodología MERINDE
MeRinde es un proyecto de Software Libre (SL) que propone un estándar para el
proceso de desarrollo de software que puede ser empleado y adaptado según los
requerimientos de cualquier comunidad u organización para el desarrollo de
sistemas y además para producir y mantener una librería de plantillas reutilizables
para la ingeniería de software. Estas plantillas proveen un punto partida para los
documentos utilizados en proyectos de desarrollo de software, con lo que pueden
ayudar a los desarrolladores a trabajar más rápido y evitar pasar por alto aspectos
importantes del proceso de desarrollo.
Este proyecto pretende entre sus principales objetivos apoyar a las comunidades
de desarrollo de SL en sus proyectos, suministrando las herramientas necesarias
para que estos cumplan con un proceso de desarrollo y documentación de sus
sistemas. Se aclara que el proceso propuesto y las plantillas no son universales y
no intentan proveer guías prescriptivas en el proceso general de desarrollo de
sistemas
Metodología SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto
de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y
su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está
especialmente indicado para proyectos en entornos complejos, donde se
necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, laflexibilidad y
la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando
al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la rotación
alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o
cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de
producto.
Las actividades que se llevan a cabo en Scrum son las siguientes:
Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración.
Tiene dos partes:
Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de
requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las
dudas que surgen y selecciona los requisitos más prioritarios que se compromete
a completar en la iteración, de manera que puedan ser entregados si el cliente lo
solicita.
Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas
de la iteración necesarias para desarrollar los requisitos a que se ha
comprometido. La estimación de esfuerzo se hace de manera conjunta y los
miembros del equipo se autoasignan las tareas.
Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos máximo).
Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos
que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias
que permitan cumplir con el compromiso adquirido. En la reunión cada miembro
del equipo responde a tres preguntas:
¿Qué he hecho desde la última reunión de sincronización?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo
pueda cumplir con su compromiso y de que no se merme su productividad.
Elimina los obstáculos que el equipo no puede resolver por sí mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso o
su productividad.
Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene
dos partes:
Demostración (4 horas máximo). El equipo presenta al cliente los requisitos
completados en la iteración, en forma de incremento de producto preparado para
ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y
de los cambios que haya habido en el contexto del proyecto, el cliente realiza las
adaptaciones necesarias de manera objetiva, ya desde la primera iteración,
replanificando el proyecto.
Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El Facilitador se
encargará de ir eliminando los obstáculos identificados.
Conclusiones
 Un método es el procedimiento utilizado para llegar a un fin.
Su significado original señala el camino que conduce a un lugar. Metodología
referencia al plan de investigación que permite cumplir ciertos objetivos en el
marco de una ciencia.
 Aunque cada metodología se basa en la misma idea general, cada una posee
un enfoque distinto sobre la materia; se inicia con un planteamiento del
problema y se finaliza con la implantación/depuración-
Referencias bibliográficas
Martin Fowler, Kendall Sccott, "UML Gota a Gota", 1999.
Perdita Stevens, Rob Pooley. Addison Wesley. 2002.
UML 2 Perdita Stevens Pearson Education ISBN-10: 8478290869
UML Fermando Asteasuain ISBN-10: 9871347952
Jeffrey Whitten. Análisis y Diseño de Sistemas de Información. 2003
Balasubramanian, V; Bieber, M; Isakowitz, T. Systematic hypermedia design.CRIS
Working Paper series 5/10/96 1996.
Isakowitz, T.; Kamis, A.; Koufakis, M: Extending the capabilities of RMM: Russian
dolls and Hypertext. 1996
Isakowitz, T.; Stohr, E.A.; Balasubramanian, P. "Rmm: A methodology for the
design of structured hypermedia". Communications of the ACM, vol. 38, 1995.
Lopistéguy, Philippe Lopistéguy; Dagorret, Pantxila; Losada, Begoña. Hypermedia
Design Methodologies Versus Hypermedia Functionality Integration. ACM
HyperText'97 conference, Southampton, UK.
Losada, B. Lopistéguy, P. Dagorret, P. Metodologías de Concepción para
Aplicaciones Hipermedia: Análisis crítico. Ibermedia'97, Ciudad Real, España.
Wikipedia. Método [En línea] Disponible en http://es.wikipedia.org/wiki/Método
Definición.de. Método [En línea] Disponible en http://definicion.de/metodo/
Definición.de. Metodología [En línea] Disponible en
http://definicion.de/metodologia/
Importancia.org. Importancia de la Metodología [En línea]
http://www.importancia.org/metodologia.php
César Krall. ¿Qué es y para qué sirve UML? [En Línea] Disponible en:
http://bit.ly/1Gwacqm
Pablo Figueroa. Etapas y actividades en el desarrollo OO basado en UML [En
línea] Disponible en: http://webdocs.cs.ualberta.ca/~pfiguero/soo/metod/uml-
met.html
Luis Eduardo Mendoza M. Sistemas de Información II [En línea] Disponible en:
http://saia.psm.edu.ve/moodle/pluginfile.php/222814/mod_resource/content/1/Mod
elos_de_desarrollo_de_sistemas_de_informacion.pdf
Abdel Rívas. Metodología de James Martin y UML [En línea] Disponible en:
http://mundoinformatico321.blogspot.com/2012/12/metodologia-de-james-martin-y-
uml.html
Wikipedia. Proceso Unificado [En línea] Disponible en:
http://es.wikipedia.org/wiki/Proceso_unificado
EcuRed. Proceso Unificado de Desarrollo [En línea] Disponible en:
http://www.ecured.cu/index.php/Proceso_Unificado_de_Desarrollo
Adrian La Rosa, Rafael Silva, Juan Velázquez. Metodología Kendall & Kendall [En
línea] Disponible en:
http://sistemasdeinformacion2.wikispaces.com/METODOLOG%C3%8DA+KENDA
LL+%26+KENDALL
Carlos Alberto Román Zamitz. Conceptos de la Metodología Orientada a Objetos
[En Línea] Disponible en: http://profesores.fi-
b.unam.mx/carlos/aydoo/conceptos_oo.html
Franklin Rivas Echeverría. Sistemas Expertos [En línea] Disponible en:
http://webdelprofesor.ula.ve/economia/guillenr/inteligencia/sist_expert_3.pdf
Abdel Rívas. Metodología del Software Educativo por Álvaro Gálvis [En línea]
Disponible en: http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-
software-educativo-por.html
Carlos Marrero, Kiberley Santos. Metodología de la Red Nacional de Integración y
Desarrollo de Software Libre (MeRinde) [En línea] Disponible en:
http://www.fundacite-anz.gob.ve/cofinanciamientos/Metodologia_Desarrollo_SL.pdf
ProyectosÁgiles. SCRUM [En línea] Disponible en:
http://www.proyectosagiles.org/que-es-scrum

Weitere ähnliche Inhalte

Was ist angesagt?

Uml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoUml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoMarvin Zumbado
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosJuan Carlos Olivares Rojas
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareElvisAR
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionAbner Gerardo
 
Diseño de entradas para sistemas de información
Diseño de entradas para sistemas de informaciónDiseño de entradas para sistemas de información
Diseño de entradas para sistemas de informaciónYaskelly Yedra
 
Cuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientadoCuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientadoFreddySantiago32
 
Enfoque estructurado enfoque oo
Enfoque estructurado   enfoque ooEnfoque estructurado   enfoque oo
Enfoque estructurado enfoque ookarlanm07
 
54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-softwarecristina_devargas
 
Ensayo Analisis y Diseño de Sistemas
Ensayo Analisis y Diseño de Sistemas Ensayo Analisis y Diseño de Sistemas
Ensayo Analisis y Diseño de Sistemas malejandro08
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a ObjetosRafael Miranda
 
Ciclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacionCiclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacionYaskelly Yedra
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosJosé Antonio Sandoval Acosta
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónR.M. M.H.
 
tipos de requisitos
  tipos de requisitos   tipos de requisitos
tipos de requisitos Juan Henao
 
Diagramas de actividad
Diagramas de actividadDiagramas de actividad
Diagramas de actividadJulio Pari
 

Was ist angesagt? (20)

Uml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoUml lenguaje unificado de modelado
Uml lenguaje unificado de modelado
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de Requerimientos
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de software
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Casos De Uso
Casos De UsoCasos De Uso
Casos De Uso
 
Pruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacionPruebas de sistemas y aceptacion
Pruebas de sistemas y aceptacion
 
Diseño de entradas para sistemas de información
Diseño de entradas para sistemas de informaciónDiseño de entradas para sistemas de información
Diseño de entradas para sistemas de información
 
Cuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientadoCuadro comparativo de enfoque estructurado y enfoque orientado
Cuadro comparativo de enfoque estructurado y enfoque orientado
 
Enfoque estructurado enfoque oo
Enfoque estructurado   enfoque ooEnfoque estructurado   enfoque oo
Enfoque estructurado enfoque oo
 
54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software54714841 ejemplo-propuesta-de-desarrollo-de-software
54714841 ejemplo-propuesta-de-desarrollo-de-software
 
Ensayo Analisis y Diseño de Sistemas
Ensayo Analisis y Diseño de Sistemas Ensayo Analisis y Diseño de Sistemas
Ensayo Analisis y Diseño de Sistemas
 
Diagrama de clases - Ejemplo monográfico 02
Diagrama de clases - Ejemplo monográfico 02Diagrama de clases - Ejemplo monográfico 02
Diagrama de clases - Ejemplo monográfico 02
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
 
Ciclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacionCiclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacion
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De Información
 
tipos de requisitos
  tipos de requisitos   tipos de requisitos
tipos de requisitos
 
Diagramas de actividad
Diagramas de actividadDiagramas de actividad
Diagramas de actividad
 
Rational rose
Rational roseRational rose
Rational rose
 

Andere mochten auch

Metodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemasMetodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemasAndoni Vasquez
 
Presentacion grupo 1 metodologías de análisis y diseño de sistemas
Presentacion grupo 1   metodologías de análisis y diseño de sistemasPresentacion grupo 1   metodologías de análisis y diseño de sistemas
Presentacion grupo 1 metodologías de análisis y diseño de sistemaselias_estrada88
 
Metodologías para el Análisis y Diseño de Sistemas
Metodologías para el Análisis y Diseño de SistemasMetodologías para el Análisis y Diseño de Sistemas
Metodologías para el Análisis y Diseño de SistemasHernan Suarez
 
Metodologia para el desarrollo
Metodologia para el desarrollo Metodologia para el desarrollo
Metodologia para el desarrollo UTPL UTPL
 
Metodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistemaMetodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistemaFreddy Ramos
 
Metodologias para el desarrollo de sistemas
Metodologias para el desarrollo de sistemasMetodologias para el desarrollo de sistemas
Metodologias para el desarrollo de sistemasgmjuan
 
Presentacion Análisis y diseño de sistemas
Presentacion Análisis y diseño de sistemasPresentacion Análisis y diseño de sistemas
Presentacion Análisis y diseño de sistemasNoelvins Laya
 
Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...travesuras79
 
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A ObjetosMetodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A Objetoshector_h30
 
Metodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasMetodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasAlexander Pino
 
Metodologías para el análisis y diseño de sistemas
Metodologías para el análisis y diseño de sistemasMetodologías para el análisis y diseño de sistemas
Metodologías para el análisis y diseño de sistemasignaciogonzalez107
 
Adsi c02-iev1-uml(1)
Adsi c02-iev1-uml(1)Adsi c02-iev1-uml(1)
Adsi c02-iev1-uml(1)brayanfp
 

Andere mochten auch (17)

Metodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemasMetodologías del análisis y diseño de sistemas
Metodologías del análisis y diseño de sistemas
 
Taller: Scrum - Osvaldo Comelli
Taller: Scrum - Osvaldo ComelliTaller: Scrum - Osvaldo Comelli
Taller: Scrum - Osvaldo Comelli
 
Presentacion grupo 1 metodologías de análisis y diseño de sistemas
Presentacion grupo 1   metodologías de análisis y diseño de sistemasPresentacion grupo 1   metodologías de análisis y diseño de sistemas
Presentacion grupo 1 metodologías de análisis y diseño de sistemas
 
Metodologías para el Análisis y Diseño de Sistemas
Metodologías para el Análisis y Diseño de SistemasMetodologías para el Análisis y Diseño de Sistemas
Metodologías para el Análisis y Diseño de Sistemas
 
Metodologia para el desarrollo
Metodologia para el desarrollo Metodologia para el desarrollo
Metodologia para el desarrollo
 
Metodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistemaMetodología para el análisis de diseño del sistema
Metodología para el análisis de diseño del sistema
 
MeRinde
MeRindeMeRinde
MeRinde
 
Metodologias para el desarrollo de sistemas
Metodologias para el desarrollo de sistemasMetodologias para el desarrollo de sistemas
Metodologias para el desarrollo de sistemas
 
Analisis diseño sistemas
Analisis diseño sistemasAnalisis diseño sistemas
Analisis diseño sistemas
 
Adsi c02-iev1-uml(1) - diaz oscar david
Adsi c02-iev1-uml(1) - diaz oscar davidAdsi c02-iev1-uml(1) - diaz oscar david
Adsi c02-iev1-uml(1) - diaz oscar david
 
Metodologia merinde y rup
Metodologia merinde y rupMetodologia merinde y rup
Metodologia merinde y rup
 
Presentacion Análisis y diseño de sistemas
Presentacion Análisis y diseño de sistemasPresentacion Análisis y diseño de sistemas
Presentacion Análisis y diseño de sistemas
 
Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...
 
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A ObjetosMetodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
 
Metodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemasMetodologias para el analisis y diseño de sistemas
Metodologias para el analisis y diseño de sistemas
 
Metodologías para el análisis y diseño de sistemas
Metodologías para el análisis y diseño de sistemasMetodologías para el análisis y diseño de sistemas
Metodologías para el análisis y diseño de sistemas
 
Adsi c02-iev1-uml(1)
Adsi c02-iev1-uml(1)Adsi c02-iev1-uml(1)
Adsi c02-iev1-uml(1)
 

Ähnlich wie Metodologías para el Diseño de Sistemas

Metodologia
MetodologiaMetodologia
Metodologiasaintbat
 
Analisis y diseños de sistemas
Analisis y diseños de sistemasAnalisis y diseños de sistemas
Analisis y diseños de sistemasvictor rodriguez
 
Informe de Christian Oblitas
Informe de Christian OblitasInforme de Christian Oblitas
Informe de Christian OblitasChristian1705
 
Informe de christian oblitas
Informe de christian oblitasInforme de christian oblitas
Informe de christian oblitasChristian1705
 
Domingo García 4A
Domingo García 4ADomingo García 4A
Domingo García 4ADomingoG10
 
proceso analisis de diseño
proceso analisis de diseñoproceso analisis de diseño
proceso analisis de diseñodorimenlinda
 
Doris sotillo 1investigacion
Doris sotillo 1investigacionDoris sotillo 1investigacion
Doris sotillo 1investigaciondorimenlinda
 
República bolivariana de venezuela
República bolivariana de venezuelaRepública bolivariana de venezuela
República bolivariana de venezuelaaularjesus
 
Ciclo de vida de los sistemas
Ciclo de vida de los sistemasCiclo de vida de los sistemas
Ciclo de vida de los sistemasGustavo Oseche
 
Análisis y diseño de sistemas1
Análisis y diseño de sistemas1Análisis y diseño de sistemas1
Análisis y diseño de sistemas1Andoni Vasquez
 
Metodologia para el desarrollo de sistemas de informaciom
Metodologia para el desarrollo de sistemas de informaciomMetodologia para el desarrollo de sistemas de informaciom
Metodologia para el desarrollo de sistemas de informaciomMcgregory Shango
 
Ciclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de InformacionCiclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de InformacionJonathanCarrillo46
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónRaimonKoudsi
 
Ciclo de vida de un sistema de información
Ciclo de vida de un sistema de informaciónCiclo de vida de un sistema de información
Ciclo de vida de un sistema de informacióngiorginavillamizar
 
Analisis y Desarrollo de Sistemas de Información
Analisis y Desarrollo de Sistemas de Información Analisis y Desarrollo de Sistemas de Información
Analisis y Desarrollo de Sistemas de Información Roberto Soto
 
TP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
TP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓNTP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
TP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓNArnaldo Federico Ledesma
 
Análisis del sistema de información
Análisis del sistema de informaciónAnálisis del sistema de información
Análisis del sistema de informaciónalmayor
 
Klenni pino Analisis y diseño de sistemas..
Klenni pino Analisis y diseño de sistemas..Klenni pino Analisis y diseño de sistemas..
Klenni pino Analisis y diseño de sistemas..Klenni Pino
 

Ähnlich wie Metodologías para el Diseño de Sistemas (20)

Metodologia
MetodologiaMetodologia
Metodologia
 
Analisis y diseños de sistemas
Analisis y diseños de sistemasAnalisis y diseños de sistemas
Analisis y diseños de sistemas
 
Informe de Christian Oblitas
Informe de Christian OblitasInforme de Christian Oblitas
Informe de Christian Oblitas
 
Informe de christian oblitas
Informe de christian oblitasInforme de christian oblitas
Informe de christian oblitas
 
Domingo García 4A
Domingo García 4ADomingo García 4A
Domingo García 4A
 
proceso analisis de diseño
proceso analisis de diseñoproceso analisis de diseño
proceso analisis de diseño
 
Doris sotillo 1investigacion
Doris sotillo 1investigacionDoris sotillo 1investigacion
Doris sotillo 1investigacion
 
República bolivariana de venezuela
República bolivariana de venezuelaRepública bolivariana de venezuela
República bolivariana de venezuela
 
Ciclo de vida de los sistemas
Ciclo de vida de los sistemasCiclo de vida de los sistemas
Ciclo de vida de los sistemas
 
Análisis y diseño de sistemas1
Análisis y diseño de sistemas1Análisis y diseño de sistemas1
Análisis y diseño de sistemas1
 
Metodologia para el desarrollo de sistemas de informaciom
Metodologia para el desarrollo de sistemas de informaciomMetodologia para el desarrollo de sistemas de informaciom
Metodologia para el desarrollo de sistemas de informaciom
 
Alejandro13
Alejandro13Alejandro13
Alejandro13
 
Ciclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de InformacionCiclo de Vida y Diseño de Sistemas de Informacion
Ciclo de Vida y Diseño de Sistemas de Informacion
 
Metodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De InformaciónMetodologías De Diseño Y Desarrollo De Sistemas De Información
Metodologías De Diseño Y Desarrollo De Sistemas De Información
 
Ciclo de vida de un sistema de información
Ciclo de vida de un sistema de informaciónCiclo de vida de un sistema de información
Ciclo de vida de un sistema de información
 
Analisis y Desarrollo de Sistemas de Información
Analisis y Desarrollo de Sistemas de Información Analisis y Desarrollo de Sistemas de Información
Analisis y Desarrollo de Sistemas de Información
 
TP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
TP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓNTP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
TP04: ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
 
Análisis del sistema de información
Análisis del sistema de informaciónAnálisis del sistema de información
Análisis del sistema de información
 
Ciclo de vida-IJRCF
Ciclo de vida-IJRCFCiclo de vida-IJRCF
Ciclo de vida-IJRCF
 
Klenni pino Analisis y diseño de sistemas..
Klenni pino Analisis y diseño de sistemas..Klenni pino Analisis y diseño de sistemas..
Klenni pino Analisis y diseño de sistemas..
 

Kürzlich hochgeladen

PLAN DE REFUERZO ESCOLAR primaria (1).docx
PLAN DE REFUERZO ESCOLAR primaria (1).docxPLAN DE REFUERZO ESCOLAR primaria (1).docx
PLAN DE REFUERZO ESCOLAR primaria (1).docxlupitavic
 
Ejercicios de PROBLEMAS PAEV 6 GRADO 2024.pdf
Ejercicios de PROBLEMAS PAEV 6 GRADO 2024.pdfEjercicios de PROBLEMAS PAEV 6 GRADO 2024.pdf
Ejercicios de PROBLEMAS PAEV 6 GRADO 2024.pdfMaritzaRetamozoVera
 
Sesión de aprendizaje Planifica Textos argumentativo.docx
Sesión de aprendizaje Planifica Textos argumentativo.docxSesión de aprendizaje Planifica Textos argumentativo.docx
Sesión de aprendizaje Planifica Textos argumentativo.docxMaritzaRetamozoVera
 
La triple Naturaleza del Hombre estudio.
La triple Naturaleza del Hombre estudio.La triple Naturaleza del Hombre estudio.
La triple Naturaleza del Hombre estudio.amayarogel
 
Imperialismo informal en Europa y el imperio
Imperialismo informal en Europa y el imperioImperialismo informal en Europa y el imperio
Imperialismo informal en Europa y el imperiomiralbaipiales2016
 
ACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptx
ACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptxACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptx
ACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptxzulyvero07
 
MAYO 1 PROYECTO día de la madre el amor más grande
MAYO 1 PROYECTO día de la madre el amor más grandeMAYO 1 PROYECTO día de la madre el amor más grande
MAYO 1 PROYECTO día de la madre el amor más grandeMarjorie Burga
 
Valoración Crítica de EEEM Feco2023 FFUCV
Valoración Crítica de EEEM Feco2023 FFUCVValoración Crítica de EEEM Feco2023 FFUCV
Valoración Crítica de EEEM Feco2023 FFUCVGiustinoAdesso1
 
CALENDARIZACION DE MAYO / RESPONSABILIDAD
CALENDARIZACION DE MAYO / RESPONSABILIDADCALENDARIZACION DE MAYO / RESPONSABILIDAD
CALENDARIZACION DE MAYO / RESPONSABILIDADauxsoporte
 
Programacion Anual Matemática5 MPG 2024 Ccesa007.pdf
Programacion Anual Matemática5    MPG 2024  Ccesa007.pdfProgramacion Anual Matemática5    MPG 2024  Ccesa007.pdf
Programacion Anual Matemática5 MPG 2024 Ccesa007.pdfDemetrio Ccesa Rayme
 
ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...
ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...
ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...JAVIER SOLIS NOYOLA
 
Dinámica florecillas a María en el mes d
Dinámica florecillas a María en el mes dDinámica florecillas a María en el mes d
Dinámica florecillas a María en el mes dstEphaniiie
 
ORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptx
ORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptxORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptx
ORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptxnandoapperscabanilla
 
ACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLA
ACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLAACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLA
ACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
 
Caja de herramientas de inteligencia artificial para la academia y la investi...
Caja de herramientas de inteligencia artificial para la academia y la investi...Caja de herramientas de inteligencia artificial para la academia y la investi...
Caja de herramientas de inteligencia artificial para la academia y la investi...Lourdes Feria
 
BIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICA
BIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICABIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICA
BIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICAÁngel Encinas
 
Ley 21.545 - Circular Nº 586.pdf circular
Ley 21.545 - Circular Nº 586.pdf circularLey 21.545 - Circular Nº 586.pdf circular
Ley 21.545 - Circular Nº 586.pdf circularMooPandrea
 

Kürzlich hochgeladen (20)

PLAN DE REFUERZO ESCOLAR primaria (1).docx
PLAN DE REFUERZO ESCOLAR primaria (1).docxPLAN DE REFUERZO ESCOLAR primaria (1).docx
PLAN DE REFUERZO ESCOLAR primaria (1).docx
 
Power Point: Fe contra todo pronóstico.pptx
Power Point: Fe contra todo pronóstico.pptxPower Point: Fe contra todo pronóstico.pptx
Power Point: Fe contra todo pronóstico.pptx
 
Ejercicios de PROBLEMAS PAEV 6 GRADO 2024.pdf
Ejercicios de PROBLEMAS PAEV 6 GRADO 2024.pdfEjercicios de PROBLEMAS PAEV 6 GRADO 2024.pdf
Ejercicios de PROBLEMAS PAEV 6 GRADO 2024.pdf
 
Sesión de aprendizaje Planifica Textos argumentativo.docx
Sesión de aprendizaje Planifica Textos argumentativo.docxSesión de aprendizaje Planifica Textos argumentativo.docx
Sesión de aprendizaje Planifica Textos argumentativo.docx
 
Fe contra todo pronóstico. La fe es confianza.
Fe contra todo pronóstico. La fe es confianza.Fe contra todo pronóstico. La fe es confianza.
Fe contra todo pronóstico. La fe es confianza.
 
La triple Naturaleza del Hombre estudio.
La triple Naturaleza del Hombre estudio.La triple Naturaleza del Hombre estudio.
La triple Naturaleza del Hombre estudio.
 
Imperialismo informal en Europa y el imperio
Imperialismo informal en Europa y el imperioImperialismo informal en Europa y el imperio
Imperialismo informal en Europa y el imperio
 
ACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptx
ACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptxACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptx
ACUERDO MINISTERIAL 078-ORGANISMOS ESCOLARES..pptx
 
MAYO 1 PROYECTO día de la madre el amor más grande
MAYO 1 PROYECTO día de la madre el amor más grandeMAYO 1 PROYECTO día de la madre el amor más grande
MAYO 1 PROYECTO día de la madre el amor más grande
 
Valoración Crítica de EEEM Feco2023 FFUCV
Valoración Crítica de EEEM Feco2023 FFUCVValoración Crítica de EEEM Feco2023 FFUCV
Valoración Crítica de EEEM Feco2023 FFUCV
 
CALENDARIZACION DE MAYO / RESPONSABILIDAD
CALENDARIZACION DE MAYO / RESPONSABILIDADCALENDARIZACION DE MAYO / RESPONSABILIDAD
CALENDARIZACION DE MAYO / RESPONSABILIDAD
 
Programacion Anual Matemática5 MPG 2024 Ccesa007.pdf
Programacion Anual Matemática5    MPG 2024  Ccesa007.pdfProgramacion Anual Matemática5    MPG 2024  Ccesa007.pdf
Programacion Anual Matemática5 MPG 2024 Ccesa007.pdf
 
ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...
ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...
ACERTIJO DE LA BANDERA OLÍMPICA CON ECUACIONES DE LA CIRCUNFERENCIA. Por JAVI...
 
Medición del Movimiento Online 2024.pptx
Medición del Movimiento Online 2024.pptxMedición del Movimiento Online 2024.pptx
Medición del Movimiento Online 2024.pptx
 
Dinámica florecillas a María en el mes d
Dinámica florecillas a María en el mes dDinámica florecillas a María en el mes d
Dinámica florecillas a María en el mes d
 
ORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptx
ORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptxORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptx
ORGANIZACIÓN SOCIAL INCA EN EL TAHUANTINSUYO.pptx
 
ACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLA
ACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLAACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLA
ACERTIJO DE POSICIÓN DE CORREDORES EN LA OLIMPIADA. Por JAVIER SOLIS NOYOLA
 
Caja de herramientas de inteligencia artificial para la academia y la investi...
Caja de herramientas de inteligencia artificial para la academia y la investi...Caja de herramientas de inteligencia artificial para la academia y la investi...
Caja de herramientas de inteligencia artificial para la academia y la investi...
 
BIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICA
BIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICABIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICA
BIOMETANO SÍ, PERO NO ASÍ. LA NUEVA BURBUJA ENERGÉTICA
 
Ley 21.545 - Circular Nº 586.pdf circular
Ley 21.545 - Circular Nº 586.pdf circularLey 21.545 - Circular Nº 586.pdf circular
Ley 21.545 - Circular Nº 586.pdf circular
 

Metodologías para el Diseño de Sistemas

  • 1. Instituto Universitario Politécnico “Santiago Mariño” Semestre: V . Asignatura: Análisis y Diseño de Sistemas Porlamar, Nueva Esparta. Metodologías para el Diseño de Sistemas Realizado por: Isidro González C.I. 25.547.661 Porlamar, Mayo de 2015.
  • 2. Introducción En la actualidad la mayoría de los usuarios de microcomputadoras tienen acceso a un sistema de información o forman parte del mismo. Todas las organizaciones cuentan con un sistema de información de algún tipo, que sus empleados deben utilizar. La creación o establecimiento de un nuevo sistema de información en la organización, puede ser una tarea compleja. Para encarar este tipo de situaciones existe un proceso de análisis y diseño de sistemas que auxilia en la resolución de tales problemas. El análisis y diseño de sistemas proporciona una guía útil que busca disminuir las situaciones de fracaso o errores al acometer estos procesos. Este procedimiento se lleva a cabo, en el llamado ciclo de vida de desarrollo de sistemas. Este ciclo puede repetirse indefinidamente, porque las organizaciones siempre se ven sometidas a cambios, y sus sistemas deben renovarse periódicamente. La finalidad de este informe es la de concienciar al lector acerca de una variedad de metodologías utilizadas para el análisis y diseño de sistemas de información.
  • 3. Contenido Método y Metodología Un método es el procedimiento utilizado para llegar a un fin. Su significado original señala el camino que conduce a un lugar. La palabra método puede referirse a diversos conceptos. Por ejemplo, a los métodos de clasificación científica. Esta es la disciplina que permite a los biólogos agrupar y separar en categorías a los diversos organismos y conjuntos. El método científico, por su parte, es la serie de pasos que sigue una ciencia para obtener saberes válidos (es decir, que pueden verificarse a través de un instrumento fiable). Gracias al respeto por un método científico, un investigador logra apartar su subjetividad y obtiene resultados más cercanos a la objetividad o a lo empírico. Metodología es un vocablo generado a partir de tres palabras de origen griego:metà (“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.
  • 4. Metodologías para el Análisis y Diseño de Sistemas Lenguaje Unificado de Modelado 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. Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos). Las etapas y actividades en el desarrollo basado en UML son: Análisis de Requerimientos En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar la solución que está buscando Actividades técnicas de esta etapa: 1. Identificar Casos de Uso del sistema 2. Dar detalle a los casos de uso descritos 3. Definir una interfaz inicial del sistema (si es aplicable) 4. Desarrollar el modelo del mundo 5. Validar los modelos
  • 5. Diseño del Sistema En esta etapa se define una subdivisión en aplicaciones del sistema (si es lo suficientemente grande) y la forma de comunicación con los sistemas ya existentes con los cuales debe interactuar La única actividad técnica que se realiza durante esta fase es Identificar la arquitectura del sistema, lo cual consiste en: Definir componentes del sistema, las aplicaciones y su ubicación. Representarlos por medio de nodos, componentes y objetos activos (representando las aplicaciones) dentro de los nodos. Definir mecanismos de comunicación. Expresarlos por medio de asociaciones de dependencia entre los nodos, componentes o aplicaciones y, si es conocido, agregar un estereotipo para definir el protocolo de comunicación requerido. Agregar notas con restricciones, rendimiento esperado y demás detalles de las conexiones. Particularizar los casos de uso a la arquitectura planteada. Refinar los casos de uso ya existentes de la etapa anterior para adecuarse a la arquitectura planteada. Validar arquitectura. Comprobar la validez técnica, económica y organizacional de la propuesta. Diseño Detallado En esta etapa se adecúa el análisis a las características específicas del ambiente de implementación y se completan las distintas aplicaciones del sistema con los modelos de control, interfaz o comunicaciones, según sea el caso. Durante esta etapa ocurren las siguientes actividades: 1. Agregar detalles de implementación al modelo del mundo
  • 6. 2. Desarrollar el modelo de interfaz 3. Desarrollar los modelos de control, persistencia y comunicaciones Implementación y Pruebas Se desarrolla el código de una manera certificada. Sus actividades son: 1. Definir estándares de programación  Asimilar los idioms aplicables al lenguaje  Conocer y adecuar estándares de programación al lenguaje  Definir estructura de directorios  Diseñar makefiles 2. Codificación y pruebas unitarias  Revisiones de código  Tratamiento de Trace y Log 3. Pruebas de módulos y de sistema  Casos de prueba  Procedimiento de instalación Metodología del Ciclo de Vida de un Sistema de James Martín. Esta metodología de desarrollo de Software es mejor conocida como Metodología RAD (Rapid Application Development) o Desarrollo rápido de Aplicaciones, y fue creada por el gurú de computación James Martin en 1991. Está orientada a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.
  • 7. Más que un modelo, se puede considerar una secuencia de eventos en el desarrollo de un sistema de información, ya que “... un modelo describe la estructura de cómo se desarrollará el proyecto”. (Raccoon, 1995) Esta metodología consta de 4 etapas a seguir: Etapa I. 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 II. 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
  • 8. 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. Etapa III. 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. Etapa IV. Implementación Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios. Metodología de Jeffrey Whitten Una metodología es una versión amplia y detallada de un ciclo de vida completo del desarrollo de un sistema que incluye: 1.- Tareas paso a paso para cada fase; 2.- funciones individuales y en grupo desempeñadas en cada tarea; 3.- productos resultantes y normas de calidad para cada tarea, y 4.- técnicas de desarrollo que se utilizarán en cada tarea. A continuación se detallan las fases de esta metodología para el desarrollo de los sistemas de información. 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.
  • 9. Fase II. Análisis del Sistema Actual “No intentes arreglarlo a menos que lo hayas comprendido”. Esta frase consiste en estudiar y analizar el sistema actual. Se identificarán sus problemas, como 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 proporcionará información con relación a la factibilidad del concepto. Se tomará como un plan piloto o prueba del sistema. El prototipo diseñado podrá ser modificado con facilidad y en el momento que así lo requiera según sea el caso. Fase IV. Diseño de la topología y de los servicios A partir de los usuarios involucrados con el sistema, y utilizando diversos instrumentos y técnicas de recolección de datos, el estudio de datos y formas usadas por la organización se ubicarán los requierimientos 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
  • 10. 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 colocará 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 de 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. Dirante estas pruebas, además de hacer observaciones necesarias durante algunas consultas reales se usará del sistema de información, también se llenará 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. E general, las tareas de depuración suelen ser engorrosas y agotadoras. Existen aplicaciones que permiten ayudar a analistas, programadores y diseñadores en estas tareas, pero la habilidad del mismo es el factor más determinante para la efectividad y eficiencia del proceso de depuración.
  • 11. Metodología del Proceso Unificado de Desarrollo de Software (RUP). Es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. 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 vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este proceso de desarrollo. Fases del Proceso Unificado de Desarrollo de Software: La fase de concepción o inicio tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. El principal esfuerzo está radicado en el Modelamiento del Negocio y el Análisis de Requerimientos. Es la única fase que no necesariamente culmina con una versión ejecutable. La fase de elaboración tiene como principal finalidad completar el análisis de los casos de uso y definir la arquitectura del sistema, además 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
  • 12. completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido. La fase de construcción está compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones el sistema que satisfacen los principales casos de uso. Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración. La fase de transición se inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción. 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. Fase I: Identificación de problemas, oportunidades y objetivos 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
  • 13. 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 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 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
  • 14. 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 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 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 de los datos indispensables para los encargados de tomar las decisiones en la organización.
  • 15. 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 En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocódigo. Durante esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software. La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso. Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo. Fase VI: Prueba y mantenimiento del sistema 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
  • 16. cabo de manera conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual. El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan de manera rutinaria durante toda su vida útil. Fase VII: Implementación y evaluación del sistema 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. 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. Metodología de Administración de Relaciones (RMM) se define como un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia. Los elementos principales de este método son el modelo E-R (Entidad-Relación) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. 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 definidas, y con claras relaciones entre esas clases). Por ejemplo, catálogos o "frentes" de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos dinámicos que cambian con mucha frecuencia, más que a entornos estáticos.
  • 17. 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. Las etapas son: Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relación ampliado con relaciones asociativas (aquéllas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de análisis). Segunda etapa: determinar la presentación del contenido de las entidades de la aplicación así como su modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relación en el que cada entidad ha sido reemplazada por su esquema de entidad. Un esquema de entidad está constituido por nodos (los trozos o slides) unidos por relaciones estructurales. Tercera etapa: definir los caminos de navegación inducidos por las relaciones asociativas del esquema E-R+. A continuación, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicación de accesos jerárquicos a niveles diferentes de los trozos de información. El esquema
  • 18. RMDM resultante se obtiene añadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa. Las cuatro etapas restantes consisten en:  Definición del protocolo de conversión de elementos del diagrama RMDM en objetos de la plataforma de desarrollo  Concepción del interfaz usuario  Concepción del comportamiento en ejecución  Construcción del sistema y test Metodología Orientada a Objetos La metodología orientada a objetos ha derivado de las metodologías anteriores a éste. Así como los métodos de diseño estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos. Actualmente el modelo de objetos ha sido influenciado por un número de factores no sólo de la Programación Orientada a Objetos, POO (Object Oriented Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha probado ser un concepto uniforme en las ciencias de la computación, aplicable no sólo a los lenguajes de programación sino también al diseño de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razón de ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas. Para definir el comportamiento de un objeto, se crean métodos, los cuales tienen una apariencia y un comportamiento igual al de las funciones en otros lenguajes
  • 19. de programación, los lenguajes estructurados, pero se definen dentro de una clase. Los métodos no siempre afectan a un solo objeto; los objetos también se comunican entre sí mediante el uso de métodos. Una clase u objeto puede llamar métodos en otra clase u objeto para avisar sobre los cambios en el ambiente o para solicitarle a ese objeto que cambie su estado. Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Además, como se puede observar de los diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa. Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en una membrana protectora de métodos— es una representación ideal de un objeto y es el ideal por el que los diseñadores de sistemas orientados a objetos luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en práctica, un objeto puede querer exponer algunas de sus variables o esconder algunos de sus métodos. El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta.
  • 20. Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello. Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Las clases proveen el beneficio de la reutilización. Los programadores de software utilizan la misma clase, y por lo tanto el mismo código, una y otra vez para crear muchos objetos. En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos y procedimientos que se pueden llevar a cabo con estos datos. Esto encapsula los datos y los procedimientos. La realidad es diferente: los atributos se relacionan al objeto o instancia y los métodos a la clase. ¿Por qué se hace así? Los atributos son variables comunes en cada objeto de una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente al que tienen para esa misma variable los demás objetos. Los métodos, por su parte, pertenecen a la clase y no se almacenan en cada objeto, puesto que sería un desperdicio almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilización de código. Otro concepto muy importante en la metodología orientada a objetos es el de herencia. La herencia es un mecanismo poderoso con el cual se puede definir una clase en términos de otra clase; lo que significa que cuando se escribe una clase, sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la herencia dará acceso automático a la información contenida en esa otra clase. Con la herencia, todas las clases están arregladas dentro de una jerarquía estricta. Cada clase tiene una superclase (la clase superior en la jerarquía) y puede tener una o más subclases (las clases que se encuentran debajo de esa clase en la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases hijas, heredan de las clases más altas, las clases padres.
  • 21. Las subclases heredan todos los métodos y variables de las superclases. Es decir, en alguna clase, si la superclase define un comportamiento que la clase hija necesita, no se tendrá que redefinir o copiar ese código de la clase padre . Metodología de Sistemas Expertos Esta metodología consta de 6 etapas: Etapa I. Análisis y Descripción del Problema Fase 1.1 Descripción general del problema: 1.1.1.- Familiarización con el proceso sobre el cual se desea realizar el sistema experto. 1.1.2.- Familiarización con los ambientes computacionales donde se encuentran los datos a ser utilizados. 1.1.3.- Definición detallada del problema que motiva el desarrollo del sistema experto. Fase 1.2.- Análisis de Factibilidad para el desarrollo del Sistema Experto: 1.2.1.- La tarea a desarrollar requiere del conocimiento manejado por un experto. 1.2.2.- Disponibilidad del experto o equipo de expertos. 1.2.3.- La experticia es requerida en varios lugares simultáneamente. 1.2.4.- El sistema requiere del manejo de incertidumbre y aplicación de juicios personales. 1.2.5.- Existe un grupo potencial de usuarios. 1.2.6.- Se dispone del tiempo para desarrollar el Sistema Experto.
  • 22. Fase 1.3.- Análisis de datos: Verificación de la ubicación y forma de representación de los datos a ser manejados por el sistema experto, considerando el tipo de base de datos y plataforma computacional. Fase 1.4.- Elección de la fuente de conocimiento: Es necesario contar con un experto o un grupo de ellos que estén dispuestos a colaborar con el proyecto. Los expertos deben ser reconocidos como tal por el grupo de usuarios. Etapa II. Especificación de requerimientos. Fase 2.1.- Estimación del perfil de los usuarios finales del Sistema Experto. Fase 2.2.- Verificación de los requerimientos con el usuario. Fase 2.3.- Determinación de los requerimientos de información: Se especifica la información que debe producir el Sistema Experto y sus atributos tales como el formato de presentación, la frecuencia de salida, sus usuarios directos y su interconexión con otros programas. Fase 2.4.- Determinación de los requerimientos funcionales: Consiste en la definición de las funciones generales que debe satisfacer el Sistema Experto. Fase 2.5.- Determinación de los requerimientos de la entrada de datos: 2.5.1.- Selección de las posibles de entrada al Sistema Experto. 2.5.2.- Identificación de las fuentes de datos. 2.5.3.- Especificación de los procesos de adquisición de datos. 2.5.4.- Especificación de los procesos de generación de parámetros. 2.5.5.- Caracterización de la interoperatibilidad entre las bases de datos que se requieren en la implantación.
  • 23. Fase 2.6.- Definición de los requerimientos de hardware y software para la implantación del Sistema Experto. 2.6.1.- Especificación de la plataforma de hardware que se utilizará para el desarrollo y operación del Sistema Experto. 2.6.2.- Determinación, análisis y selección de las herramientas de software disponibles en el mercado para el desarrollo de Sistemas Expertos. Etapa III. Análisis de costos, tiempo y recursos. Fase 3.1.- Elaboración del plan de actividades de desarrollo e implantación. Fase 3.2.- Estimación del tiempo requerido para el desarrollo del Sistema Experto. Fase 3.3.- Estimación de los recursos computacionales (hardware-software) requeridos para el desarrollo del Sistema Experto. Fase 3.4.- Estimación de los costos de desarrollo. Etapa IV: Ingeniería del Conocimiento. Fase 4.1.- Adquisición del Conocimiento: Es donde el Ingeniero del Conocimiento interactúa con el experto para obtener la información sobre la solución de los problemas, así como las estrategias utilizadas para la obtención de cada solución. Fase 4.2.- Estructuración del Conocimiento: En esta fase, el Ingeniero del Conocimiento debe llevar a una base de conocimiento la información proporcionada por el experto. El conocimiento puede ser de carácter superficial o profundo dependiendo de la estructura interna y de las interacciones entre sus componentes. Etapa V: Diseño preliminar del Sistema Experto. Fase 5.1.- Diseño preliminar de la arquitectura del Sistema Experto.
  • 24. Fase 5.2.- Selección de la herramienta computacional de acuerdo a los requerimientos surgidos en la etapa de Ingeniería del Conocimiento. Fase 5.3.- Diseño preliminar de procesos de adquisición y almacenamiento de datos. Fase 5.4.- Diseño preliminar de procesos de interconexión. 5.4.1.- Integración Interna. 5.4.2.- Integración Externa. 5.4.3.- Selección de software auxiliar. Fase 5.5.- Verificación del diseño preliminar del Sistema Experto. Etapa VI: Desarrollo e Implantación del Sistema Experto. Fase 6.1.- Construcción del prototipo. Fase 6.2.- Validación del prototipo. Fase 6.3.- Construcción de modelo operacional Fase 6.4.- Prueba y depuración. Fase 6.5.- Mantenimiento y actualización. Metodología del Software Educativo 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.
  • 25. 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. 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-
  • 26. 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. 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
  • 27. 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. Metodología de Sistemas Blandos (SSM) La SSM de Peter Checkland es una metodología sistémica fundamentada en el concepto de perspectiva o en el lenguaje de la metodología “Weltanschauung”. Un “weltanschauung” representa la visión propia de un observador, o grupo de ellos, sobre un objeto de estudio, visión ésta que afecta las decisiones que el(los) observador(es) pueda(n) tomar en un momento dado sobre su accionar con el objeto. La SSM toma como punto de partida la idealización de estos “weltanschauung” para proponer cambios sobre el sistema que en teoría deberían tender a mejorar su funcionamiento. En este punto es conveniente aclarar la noción de “weltanschauung”, para ello se puede considerar como ejemplo, las diferencias que entre un observador y otro presenta el propósito de las universidades: - Para algunos estudiantes pueden ser centros de estudio donde asisten para formarse con miras a ingresar a un mercado de trabajo profesional, para otros
  • 28. pueden ser centros donde tomar experiencia en la diatriba política, para otro grupo pueden ser centros donde converge el conocimiento universal y acuden a entrar en contacto con él, etc. - Para algunos profesores pueden ser centros de enseñaza donde acuden a laborar impartiendo conocimientos entre sus estudiantes, para otros son centros de docencia e investigación donde, a través del desarrollo de la investigación, nutren su actividad de docencia, siempre con la intención de brindar lo mejor posible de sus conocimientos a sus estudiantes, así mismo para otro grupo de profesores la universidad puede ser un centro donde ellos y los estudiantes acuden a intercambiar experiencias dentro de un proceso interactivo de enseñanza aprendizaje, etc. Como se puede ver, en ambos casos, estudiantes y profesores, la visión que se tiene sobre las universidades es diferente, e incluso entre estudiantes y profesores se pueden tener diferentes visiones. Estas visiones son los “weltanschauung” sobre las universidades, es importante hacer notar que éstos no son correctos o erróneos, ni unos son mejores que otros, todos son igualmente válidos e incluso complementarios. Otro concepto importante para la SSM es el de sistema blando, según Checkland, un sistema blando es aquel que está conformado por actividades humanas, tiene un fin perdurable en el tiempo y presenta problemáticas inestructuradas o blandas; es decir aquellas problemáticas de difícil definición y carentes de estructura, en las que los fines, metas, propósitos, son problemáticos en sí. La SSM está conformada por siete (7) estadios cuyo orden puede variar de acuerdo a las características del estudio, a continuación se describen brevemente estos estadios. Estadio 1: La Situación Problema no Estructurada: en este estadio se pretende lograr una descripción de la situación donde se percibe la existencia de un
  • 29. problema, sin hacer hincapié en el problema en sí, esto es sin dar ningún tipo de estructura a la situación. Estadio 2: La Situación Problema Expresada: se da forma a la situación describiendo su estructura organizativa, actividades e interrelación de éstas, flujos de entrada y salida, etc. Estadio 3: Definiciones Raíz de Sistemas Pertinentes: se elaboran definiciones de lo que, idealmente, según los diferentes “weltanschauung” involucrados, es el sistema. La construcción de estas definiciones se fundamenta en seis factores que deben aparecer explícitos en todas ellas, estos se agrupan bajo el nemónico de sus siglas en ingles CATWOE (Bergvall-Kåreborn et. al. 2004), a saber: consumidores, actores, proceso de transformación, weltanschauung, poseedor y restricción del ambiente. Estadio 4: Confección y Verificación de Modelos Conceptuales: partiendo de los verbos de acción presentes en las definiciones raíz, se elaboran modelos conceptuales que representen, idealmente, las actividades que, según la definición raíz en cuestión, se deban realizar en el sistema (Ramírez 1983). Existirán tantos modelos conceptuales como definiciones raíz. Este estadio se asiste de los subestadios 4a y 4b. Estadio 4a: Concepto de Sistema Formal: este consiste en el uso de un modelo general de sistema de la actividad humana que se puede usar para verificar que los modelos construidos no sean fundamentalmente deficientes. Estadio 4b: Otros Pensamientos de Sistemas: consiste en transformar el modelo obtenido en alguna otra forma de pensamiento sistémico que, dadas las particularidades del problema, pueda ser conveniente. Estadio 5: Comparación de los modelos conceptuales con la realidad: se comparan los modelos conceptuales con la situación actual del sistema expresada, dicha comparación pretende hacer emerger las diferencias existentes
  • 30. entre lo descrito en los modelos conceptuales y lo que existe en la actualidad en el sistema. Estadio 6: Diseño de Cambios Deseables, Viables: de las diferencias emergidas entre la situación actual y los modelos conceptuales, se proponen cambios tendientes a superarlas, dichos cambios deben ser evaluados y aprobados por las personas que conforman el sistema humano, para garantizar con esto que sean deseables y viables. Estadio 7: Acciones para Mejorar la Situación Problema: finalmente este estadio comprende la puesta en marcha de los cambios diseñados, tendientes a solucionar la situación problema, y el control de los mismos. Este estadio no representa el fin de la aplicación de la metodología, pues en su aplicación se transforma en un ciclo de continua conceptualización y habilitación de cambios, siempre tendiendo a mejorar la situación. . Metodología MERINDE MeRinde es un proyecto de Software Libre (SL) que propone un estándar para el proceso de desarrollo de software que puede ser empleado y adaptado según los requerimientos de cualquier comunidad u organización para el desarrollo de sistemas y además para producir y mantener una librería de plantillas reutilizables para la ingeniería de software. Estas plantillas proveen un punto partida para los documentos utilizados en proyectos de desarrollo de software, con lo que pueden ayudar a los desarrolladores a trabajar más rápido y evitar pasar por alto aspectos importantes del proceso de desarrollo. Este proyecto pretende entre sus principales objetivos apoyar a las comunidades de desarrollo de SL en sus proyectos, suministrando las herramientas necesarias para que estos cumplan con un proceso de desarrollo y documentación de sus sistemas. Se aclara que el proceso propuesto y las plantillas no son universales y no intentan proveer guías prescriptivas en el proceso general de desarrollo de sistemas
  • 31. Metodología SCRUM Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, laflexibilidad y la productividad son fundamentales. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. Las actividades que se llevan a cabo en Scrum son las siguientes: Planificación de la iteración El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes: Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete
  • 32. a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas. Ejecución de la iteración Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas: ¿Qué he hecho desde la última reunión de sincronización? ¿Qué voy a hacer a partir de este momento? ¿Qué impedimentos tengo o voy a tener? Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. Elimina los obstáculos que el equipo no puede resolver por sí mismo. Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad. Inspección y adaptación El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:
  • 33. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.
  • 34. Conclusiones  Un método es el procedimiento utilizado para llegar a un fin. Su significado original señala el camino que conduce a un lugar. Metodología referencia al plan de investigación que permite cumplir ciertos objetivos en el marco de una ciencia.  Aunque cada metodología se basa en la misma idea general, cada una posee un enfoque distinto sobre la materia; se inicia con un planteamiento del problema y se finaliza con la implantación/depuración-
  • 35. Referencias bibliográficas Martin Fowler, Kendall Sccott, "UML Gota a Gota", 1999. Perdita Stevens, Rob Pooley. Addison Wesley. 2002. UML 2 Perdita Stevens Pearson Education ISBN-10: 8478290869 UML Fermando Asteasuain ISBN-10: 9871347952 Jeffrey Whitten. Análisis y Diseño de Sistemas de Información. 2003 Balasubramanian, V; Bieber, M; Isakowitz, T. Systematic hypermedia design.CRIS Working Paper series 5/10/96 1996. Isakowitz, T.; Kamis, A.; Koufakis, M: Extending the capabilities of RMM: Russian dolls and Hypertext. 1996 Isakowitz, T.; Stohr, E.A.; Balasubramanian, P. "Rmm: A methodology for the design of structured hypermedia". Communications of the ACM, vol. 38, 1995. Lopistéguy, Philippe Lopistéguy; Dagorret, Pantxila; Losada, Begoña. Hypermedia Design Methodologies Versus Hypermedia Functionality Integration. ACM HyperText'97 conference, Southampton, UK. Losada, B. Lopistéguy, P. Dagorret, P. Metodologías de Concepción para Aplicaciones Hipermedia: Análisis crítico. Ibermedia'97, Ciudad Real, España. Wikipedia. Método [En línea] Disponible en http://es.wikipedia.org/wiki/Método Definición.de. Método [En línea] Disponible en http://definicion.de/metodo/ Definición.de. Metodología [En línea] Disponible en http://definicion.de/metodologia/
  • 36. Importancia.org. Importancia de la Metodología [En línea] http://www.importancia.org/metodologia.php César Krall. ¿Qué es y para qué sirve UML? [En Línea] Disponible en: http://bit.ly/1Gwacqm Pablo Figueroa. Etapas y actividades en el desarrollo OO basado en UML [En línea] Disponible en: http://webdocs.cs.ualberta.ca/~pfiguero/soo/metod/uml- met.html Luis Eduardo Mendoza M. Sistemas de Información II [En línea] Disponible en: http://saia.psm.edu.ve/moodle/pluginfile.php/222814/mod_resource/content/1/Mod elos_de_desarrollo_de_sistemas_de_informacion.pdf Abdel Rívas. Metodología de James Martin y UML [En línea] Disponible en: http://mundoinformatico321.blogspot.com/2012/12/metodologia-de-james-martin-y- uml.html Wikipedia. Proceso Unificado [En línea] Disponible en: http://es.wikipedia.org/wiki/Proceso_unificado EcuRed. Proceso Unificado de Desarrollo [En línea] Disponible en: http://www.ecured.cu/index.php/Proceso_Unificado_de_Desarrollo Adrian La Rosa, Rafael Silva, Juan Velázquez. Metodología Kendall & Kendall [En línea] Disponible en: http://sistemasdeinformacion2.wikispaces.com/METODOLOG%C3%8DA+KENDA LL+%26+KENDALL Carlos Alberto Román Zamitz. Conceptos de la Metodología Orientada a Objetos [En Línea] Disponible en: http://profesores.fi- b.unam.mx/carlos/aydoo/conceptos_oo.html
  • 37. Franklin Rivas Echeverría. Sistemas Expertos [En línea] Disponible en: http://webdelprofesor.ula.ve/economia/guillenr/inteligencia/sist_expert_3.pdf Abdel Rívas. Metodología del Software Educativo por Álvaro Gálvis [En línea] Disponible en: http://mundoinformatico321.blogspot.com/2012/12/metodologia-del- software-educativo-por.html Carlos Marrero, Kiberley Santos. Metodología de la Red Nacional de Integración y Desarrollo de Software Libre (MeRinde) [En línea] Disponible en: http://www.fundacite-anz.gob.ve/cofinanciamientos/Metodologia_Desarrollo_SL.pdf ProyectosÁgiles. SCRUM [En línea] Disponible en: http://www.proyectosagiles.org/que-es-scrum