You are on page 1of 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

You might also like