1. Instituto Universitario Politécnico
“Santiago Mariño”
Extensión Porlamar
Escuela de Ingeniería de Sistemas
Metodologías para el Análisis y el Diseño de Sistemas.
Profesor: Autor:
Jonathan Fernández Alexander Pino
C.I.: 25.156.375
Porlamar, Mayo de 2015.

2. Introducción
El análisis y diseño de sistemas de información es el proceso de estudiar su
situación con la finalidad de observar cómo trabaja y decir si es necesario realizar una
mejora; el encargado de realizar estas tareas es el analista de sistemas. Antes de
comenzar el desarrollo de cualquier proyecto, se conoce un estudio de sistema s para
detectar todos los detalles de la situación actual en la empresa. La información reunida
con este estudio sirve como base para crear varias estrategias de diseño. Los
administradores deciden qué estrategia seguir. Los gerentes, empleados y otros usuarios
finales que se familiarizan cada vez más con el empleo de computadoras están teniendo
un papel muy importante en el desarrollo de sistemas.
Todas las organizaciones son sistemas que actúan recíprocamente con su medio
ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar
formados por otros sistemas más pequeños denominados subsistemas, funcionan para
alcanzar fines específicos. Sin embargo, los propósitos o metas se alcanzan sólo cuando
se mantienen el control.
Un sistema de información es un conjunto de elementos que interactúan entre sí
con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional:
el hardware necesario para que el sistema de información pueda operar.
El recurso humano que interactúa con el Sistema de Información, el cual está
formado por las personas que utilizan el sistema.

3. Método
Es un modo, manera o forma de realizar algo de forma sistemática, organizada y/o
estructurada. Hace referencia a una técnica o conjunto de tareas para desarrollar una
tarea.
En algunos casos se entiende también como la forma habitual de realizar algo por
una persona basada en la experiencia, costumbre y preferencias personales.
Procede del latín methŏdus, que a su vez deriva del griego μέθοδος.
Metodología
Una metodología es el conjunto de métodos por los cuales se regirá una
investigación científica por ejemplo, en tanto, para aclarar mejor el concepto, vale aclarar
que un método es el procedimiento que se llevará a cabo en orden a la consecución de
determinados objetivos.
Entonces, lo que preeminentemente hace la metodología es estudiar los métodos
para luego determinar cuál es el más adecuado a aplicar o sistematizar en una
investigación o trabajo.
Por otro lado, no existe una única metodología a la hora de investigar, esto
dependerá en gran medida de los postulados que sostiene la ciencia de la cual partirá el
investigador.
Lenguaje Unificado de Modelado (UML) (Diagramas)
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado
en la actualidad; está respaldado por el OMG (Object Management Group).
El uml es un sistema de notación que se ha convertido en estándar en el mundo
de desarrollo de sistemas. Es el resultado del trabajo hecho por grady booch, james
rumbaugh e ivar jacobson. El uml está constituido por un conjunto de diagramas, y
proporciona un estándar que permite el analista de sistemas generar un anteproyecto de
varias facetas que sean comprensibles para los clientes, desarrolladores y todos aquellos

4. que estén involucrados en el proceso de desarrollo. Es necesario contar con todos esos
diagramas dado que cada uno se dirige a cada tipo de persona implicada en el sistema.
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 puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso Unificado
Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de
una utilización en un requerimiento. Mientras que, programación estructurada, es una
forma de programar como lo es la orientación a objetos, la programación orientada a
objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML
sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.
Diagramas Utilizados en UML:
En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera
concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura
de la derecha.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el
sistema modelado:
* Diagrama de clases
* Diagrama de componentes
* Diagrama de objetos
* Diagrama de estructura compuesta (UML 2.0)
* Diagrama de despliegue
* Diagrama de paquetes

5. Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema
modelado:
* Diagrama de actividades
* Diagrama de casos de uso
* Diagrama de estados
Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que
enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
* Diagrama de secuencia
* Diagrama de comunicación, que es una versión simplificada del Diagrama de
colaboración (UML 1.x)
* Diagrama de tiempos (UML 2.0)
* Diagrama global de interacciones o Diagrama de vista de interacción (UML 2.0)
Fases: las fases del desarrollo de sistemas que soporta uml son: análisis de
requerimientos, análisis, diseño, programación y pruebas.
Análisis de requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente.
A través del modelado de casos de uso, los actores externos que tienen interés en el
sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos
de uso). Los actores y los casos de uso son modelados con relaciones y tienen
asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso
son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica
los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la
funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado
también para procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que están presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las

6. colaboraciones entre las clases para ejecutar los casos de uso también se consideran
en esta fase a través de los modelos dinámicos en uml. Es importante notar que sólo se
consideran clases que están en el dominio del problema (conceptos del mundo real) y
todavía no se consideran clases que definen detalles y soluciones en el sistema de
software, tales como clases para interfaces de usuario, bases de datos, comunicaciones,
concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica.
Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de
usuario, manejo de bases de datos para almacenar objetos en una base de datos,
comunicaciones con otros sistemas, etc. las clases de dominio del problema del análisis
son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase
de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de
programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en
UML, lo más aconsejable es trasladar mentalmente esos modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integración, pruebas de sistema, pruebas de aceptación, etc. las pruebas de unidades
se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas
por el programador. Las pruebas de integración integran componentes y clases en orden
para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema
como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario
final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema
satisface los requerimientos y son similares a las pruebas de sistema.

7. 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.
Fases:
Esta metodología consta de 4 etapas a saber:
1) Etapa de 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.
2) Etapa de 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

8. 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.
3) 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.
4) 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
Teniendo entonces una idea clara de los conceptos, relaciones y diferencias entre
datos, información y conocimiento, se hace entonces importante, mencionar algunos
conceptos tales como “sistema”, “sistema de información” y “sistema de información
informático” ya que aunque sus definiciones puedan parecerse e incluso superponerse
poseen mínimos detalles que marcan la diferencia.
Según el Diccionario de la Real Academia de la Lengua Española en su ediciónvigésimo
segunda la palabra sistema significa “Conjunto de cosas que relacionadas entre sí
ordenadamente contribuyen a determinado objeto”.
Es importante enfocarnos en una palabra determinante en este
concepto: ordenadamente, los autores Stair y Reynolds (1999) nos dan un panorama de
la importancia de este vocablo dentro de la definición: “la forma en que están organizados
o dispuestos los distintos elementos de un sistema se llama configuración” y más tarde
“conocer el propósito o resultado que se desea obtener de un sistema es el primer paso
en la definición de la manera en que se configurarán sus elementos” por lo tanto la salida
de nuestro sistema estará intrínsecamente relacionada con la configuración del mismo.
Tomando como base este simple pero general concepto de lo que es un sistema

9. podemos centrarnos en dialogar sobre que es un sistema de información, y aunque su
definición quizás no diste mucho de la anterior es más acorde con los objetivos de este
trabajo y nos ofrece una idea más específica de lo que en realidad estamos buscando.
Los SI han sido conceptualizados por distintos investigadores y expertos del área,
Laudon y Laudon (2004) los definen como “un conjunto de componentes
interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen
información para apoyar la toma de decisiones y el control de una organización”.
Elementos fundamentales de un sistema de información:
 Información: La información es la base, la materia prima sobre la cual se mueve
todo el engranaje de un sistema de información, es todo lo almacenado,
procesado y distribuido en la organización por el sistema.
 Las personas: Son los encargados de interactuar con la información, quienes la
introducen, utilizan y valoran su importancia en las distintas tareas relacionadas
con esta.
 Medios para la interacción con la información: Activos tangibles e intangibles
de interacción con los usuarios para el tratamiento de la información, pueden ser
archivos, documentos, hardware, software, redes de comunicación, intranets,
etcétera.
 Normas y/o técnicas de trabajo: Métodos utilizados por las personas y las
tecnologías para desarrollar sus actividades.
 Hardware: Todas las piezas físicas de la computadora y sus periféricos, dígase
teclado, monitor, tarjeta madre, y los demás elementos que conforman el equipo.
Este equipamiento es utilizado para llevar a cabo las tareas de entrada,
procesamiento y salida.
 Software: Son los programas de computación mediante los cuales se dirige las
operaciones de una computadora.
 Bases de Datos: Una Base de Datos es una colección de datos organizados en
celdas. Este elemento se encuentra entre los más importantes de un sistema de
información informático.

10.  Redes: Se denomina así a la interconexión entre computadoras u otros equipos
informáticos para hacer posible la comunicación electrónica, este elemento es
muy importante ya que puede ser determinante en la efectividad del sistema de
información informático.
Metodología del Proceso Unificado de Desarrollo de Software
Un proceso de software detallado y completo suele denominarse “Metodología”.
Las metodologías se basan en una combinación de los modelos de proceso genéricos
(cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir
con precisión los artefactos, roles y actividades involucrados, junto con prácticas y
técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para
uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para
referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas)
actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de
análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido
a la diversidad de propuestas y diferencias en el grado de detalle, información disponible
y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las
notaciones utilizadas para especificar artefactos producidos en actividades de análisis y
diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas
y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de
desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del
proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de
Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o
Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más
orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a
equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos
asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

11. Fases de desarrollo
En la ingeniería del software el término fases de desarrollo expresa cómo ha
progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión
importante de un producto pasa generalmente a través de una etapa en la que se
agregan las nuevas características (etapa alfa), después una etapa donde se eliminan
errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos
los bugs importantes (etapa estable). Las etapas intermedias pueden también ser
reconocidas. Las etapas se pueden anunciar y regular formalmente por los
desarrolladores del producto, pero los términos se utilizan a veces de manera informal
para describir el estado de un producto. Normalmente muchas compañías usan nombres
en clave para las versiones antes del lanzamiento de un producto, aunque el producto y
las características reales son raramente secretas
Metodología de Kendall y Kendall
“El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para
el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan
mejor utilizando un ciclo especifico de actividades del analista y el usuario.” (Kendall &
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.
Observación directa del entorno.

12. Aplicación de entrevista para recolectar información.
Sintetizar la información recolectada para construir objetivos.
Estimar el alcance del proyecto.
Identificar si existe una necesidad, problema u oportunidad argumentada.
Documentar resultados.
Estudiar los riesgos del proyecto.
Presentar un informe de vialidad.
FASE II: Determinación de los requerimientos de información.
Revisión de los objetivos.
Identificar el dominio.
Investigar la razón por la cual se implementa el sistema actual.
Recolectar información sobre los procedimientos y operaciones que se desempeñan
actualmente.
FASE III: Análisis de las necesidades.
Evaluar las dos fases anteriores.
Modelar las entradas, los procesos y las salidas de las funciones ya identificadas.
Elaborar diccionario de datos y sus especificaciones.
Elaborar diagramas de procesos de cada función.
Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos.
Realizar el análisis del riesgo sobre el realizado en las fases anteriores, tomando en
cuenta el aspecto económico, técnico y operacional (estudio de factibilidad)
Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el sistema.
FASE IV: Diseño del sistema recomendado.
Evaluar las tres fases anteriores.

13. Realizar el diseño lógico de todo el sistema.
Elaborar procedimientos precisos para la captura de los datos que van a ingresar al
sistema de información.
Elaborar el diseño de la base de datos.
Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o
función.
Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos.
Producir los paquetes específicos de programas para los programadores.
Elaborar una lista de las funciones genéricas y de las que será obligatorio crear.
FASE V: Desarrollo y documentación del software.
Evaluar los procedimientos que va a ser desarrollados por el programador.
Mostrar y explicar cada procedimiento, función y operación al programador.
Elaborar manuales de procedimientos internos del sistema.
Elaborar manuales externos de ayuda a los usuarios del sistema.
Elaborar demostraciones para los usuarios y la interacción con distintas interfaces.
Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe con el
tiempo que se llevó construir cada procedimiento.
FASE VI: Prueba y mantenimiento del sistema.
Realizar la programación de las pruebas del sistema.
Realizar un instrumento para evaluar el sistema de información.
El programador deberá elaborar un resumen de las pruebas del sistema.
El analista deberá realizar un informe de sus pruebas y discutirlo con el programador.
Elaborar la planificación de las horas del mantenimiento del sistema. Elaborar la lista de
las operaciones que pudieran sufrir modificaciones de códigos.

14. FASE VII: Implementación y evaluación del sistema.
Planificar gradualmente la conversión del sistema anterior.
Instalar los equipos de hardware necesarios para el funcionamiento del software creado.
Capacitar por medio de talleres a los usuarios en el manejo de equipos y software
creados.
Evaluar la adaptabilidad de los usuarios al 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.
Metodología de Administración de Relaciones (RMM)
La RMM o Relationship Management Methodology 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

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

16. Metodología Orientada a Objetos
La metodología OMT (Object Modeling Technique) fue creada por James
Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de investigación
de los laboratorios General Electric.
OMT es una de las metodologías de análisis y diseño orientada a objetos, más
madura y eficiente que existe en la actualidad. La gran virtud que aporta esta metodología
es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en
consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse
a todas las necesidades actuales y futuras de la ingeniería de software.
Las fases que conforman a la metodología OMT son:
1. Análisis. El analista construye un modelo del dominio del problema, mostrando sus
propiedades más importantes. El modelo de análisis es una abstracción resumida y
precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará.
Los elementos del modelo deben ser conceptos del dominio de aplicacióny no conceptos
informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido
y criticado por expertos en el dominio del problema que no tengan conocimientos
informáticos.
2. Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la
arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas
basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se
selecciona una estrategia para afrontar el problema.
3. Diseño de objetos. El diseñadorde objetos construye un modelo de diseño basándose
en el modelo de análisis, pero incorporando detalles de implementación. El diseño de
objetos se centra en las estructuras de datos y algoritmos que son necesarios para
implementar cada clase. OMT describe la forma en que el diseño puede ser
implementado en distintos lenguajes (orientados y no orientados a objetos, bases de
datos, etc.).

17. 4. Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis
de objetos se traducen finalmente a una implementación concreta. Durante la fase de
implementación es importante tener en cuenta los principios de la ingeniería del software
de forma que la correspondencia con el diseño sea directa y el sistema implementado
sea flexible y extensible.
No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización
de código y la correspondencia entre el dominio del problema y el sistema informático, si
luego perdemos todas estas ventajas con una implementación de mala calidad.
Metodología de Sistemas Expertos por David Rolston
Es una aplicación informática capaz de solucionar un conjunto de problemas que
exigen un gran conocimiento sobre un determinado tema. Un sistema experto es un
conjunto de programas que, sobre una base de conocimientos, posee información de
uno o más expertos en un área específica. Se puede entender como una rama de
la inteligencia artificial, donde el poder de resolución de un problema en un programa de
computadora viene del conocimiento de un dominio específico. Estos sistemas imitan las
actividades de un humano para resolver problemas de distinta índole (no necesariamente
tiene que ser de inteligencia artificial). También se dice que un SE se basa en el
conocimiento declarativo (hechos sobre objetos, situaciones) y el conocimiento de control
(información sobre el seguimiento de una acción).
Para que un sistema experto sea herramienta efectiva, los usuarios deben interactuar de
una forma fácil, reuniendo dos capacidades para poder cumplirlo:
1. Explicar sus razonamientos o base del conocimiento: los sistemas expertos se
deben realizar siguiendo ciertas reglas o pasos comprensibles de manera que se
pueda generar la explicación para cada una de estas reglas, que a la vez se basan
en hechos.
2. Adquisición de nuevos conocimientos o integrador del sistema: son mecanismos
de razonamiento que sirven para modificar los conocimientos anteriores. Sobre
la base de lo anterior se puede decir que los sistemas expertos son el producto
de investigaciones en el campo de la inteligencia artificial ya que ésta no intenta

18. sustituir a los expertos humanos, sino que se desea ayudarlos a realizar con más
rapidez y eficacia todas las tareas que realiza.
Debido a esto en la actualidad se están mezclando diferentes técnicas o aplicaciones
aprovechando las ventajas que cada una de estas ofrece para poder tener empresas
más seguras. Un ejemplo de estas técnicas sería los agentes que tienen la capacidadde
negociar y navegar a través de recursos en línea; y es por eso que en la actualidad juega
un papel preponderante en los sistemas expertos.
Metodología del Software Educativo por Álvaro Galvis (ISE)
Es una metodología de desarrollo de software que contempla una serie de fases o etapas
de un proceso sistemático atendiendo a: análisis, diseño, desarrollo, prueba y ajuste, y
por ú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.
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).

19. 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) de Peter Checkland
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)

20. 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.
Metodología MERINDE
MeRinde es un proyecto que propone un estándar abierto para el proceso de
desarrollo de software orientado a planes que se estructura en dos dimensiones o ejes.
La metodología propuesta MeRinde se organiza en disciplinas. Las disciplinas
poseen flujos de trabajos en donde cada uno conlleva a actividades (ver primera figura)
que a su vez están compuestos por un conjunto de tareas (ver segunda figura) realizadas
en un área determinada, las cuales tienen como objetivo producir artefactos. A su vez,
en MeRinde existen actividades que se dividen en subactividades (ver tercera figura) con
el fin de facilitar la agrupación de tareas relacionadas.
Las disciplinas que conforman esta metodología se fundamentan en las
propuestas por RUP, las cuales se dividirán en dos grupos. El primero comprende las
disciplinas fundamentales asociadas con las áreas de ingeniería:
 Modelado del Negocio
 Requerimientos
 Análisis y Diseño
 Implementación
 Pruebas
 Implantación
El segundo grupo lo integran aquellas disciplinas llamadas de soporte o gestión:
 Gestión de Configuración y Cambios
 Gestión del Proyecto
 Gestión del Ambiente

21. Fases:
 Fase de Inicio
 Fase de Elaboracion
 Fase de Construccion
 Fase de Transicion
Metodología SCRUM
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software,
cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se
basa en construir primero la funcionalidad de mayor valor para el cliente y en los
principios de inspección continua, adaptación, auto-gestión e innovación.
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto
dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento
realinear el software con los objetivos de negocio de su empresa, ya que puede introducir
cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún
problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del
equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito
propicio para desarrollar sus capacidades.

22. Conclusión
Un proyecto de desarrollo de un Sistema de Información comprende varios
componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a
traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de los
componentes: Software, hardware, personas, base de datos, documentación y
procedimientos.
En una organización o Empresa, el análisis y Diseño de Sistemas, es el proceso
de estudiar su Situación con la finalidad de observar cómo trabaja y decidir si es
necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el

23. Bibliografía
http://www.significados.com/metodo/
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html
http://articulacion.simonrodriguez.org.ve/lval/index.php/Metodologia_MeRinde.#Metodol
og.C3.ADa_de_la_Red_Nacional_de_Integraci.C3.B3n_y_Desarrollo_de_Software_Libr
e_.28MeRinde.29
http://articulacion.simonrodriguez.org.ve/lval/index.php/Metodologia_MeRinde.#Metodol
og.C3.ADa_de_la_Red_Nacional_de_Integraci.C3.B3n_y_Desarrollo_de_Software_Libr
e_.28MeRinde.29
http://utnsimocametodologia.blogspot.mx/2011/08/aprendiendo-uml-hora-1-
introduccion-al.html
http://mmc.geofisica.unam.mx/LuCAS/Tutoriales/doc-modelado-sistemas-UML/multiple-
html/c12.html
http://www.definicionabc.com/ciencia/metodologia.php