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/

Modelos_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+KENDALL+%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