Metodologias para el analisis y diseño de sistemas
33
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.
Metodologias para el analisis y diseño de sistemas
1. Instituto Universitario Politcnico Santiago Mario Extensin
Porlamar Escuela de Ingeniera de Sistemas Metodologas para el
Anlisis y el Diseo de Sistemas. Profesor: Autor: Jonathan Fernndez
Alexander Pino C.I.: 25.156.375 Porlamar, Mayo de 2015.
2. Introduccin El anlisis y diseo de sistemas de informacin es
el proceso de estudiar su situacin con la finalidad de observar cmo
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 situacin actual
en la empresa. La informacin reunida con este estudio sirve como
base para crear varias estrategias de diseo. Los administradores
deciden qu estrategia seguir. Los gerentes, empleados y otros
usuarios finales que se familiarizan cada vez ms con el empleo de
computadoras estn teniendo un papel muy importante en el desarrollo
de sistemas. Todas las organizaciones son sistemas que actan
recprocamente con su medio ambiente recibiendo entradas y
produciendo salidas. Los sistemas, que pueden estar formados por
otros sistemas ms pequeos denominados subsistemas, funcionan para
alcanzar fines especficos. Sin embargo, los propsitos o metas se
alcanzan slo cuando se mantienen el control. Un sistema de
informacin es un conjunto de elementos que interactan 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
informacin pueda operar. El recurso humano que interacta con el
Sistema de Informacin, el cual est formado por las personas que
utilizan el sistema.
3. Mtodo Es un modo, manera o forma de realizar algo de forma
sistemtica, organizada y/o estructurada. Hace referencia a una
tcnica o conjunto de tareas para desarrollar una tarea. En algunos
casos se entiende tambin como la forma habitual de realizar algo
por una persona basada en la experiencia, costumbre y preferencias
personales. Procede del latn methdus, que a su vez deriva del
griego . Metodologa Una metodologa es el conjunto de mtodos por los
cuales se regir una investigacin cientfica por ejemplo, en tanto,
para aclarar mejor el concepto, vale aclarar que un mtodo es el
procedimiento que se llevar a cabo en orden a la consecucin de
determinados objetivos. Entonces, lo que preeminentemente hace la
metodologa es estudiar los mtodos para luego determinar cul es el
ms adecuado a aplicar o sistematizar en una investigacin o trabajo.
Por otro lado, no existe una nica metodologa 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 ingls, Unified Modeling Language)
es el lenguaje de modelado de sistemas de software ms conocido y
utilizado en la actualidad; est respaldado por el OMG (Object
Management Group). El uml es un sistema de notacin que se ha
convertido en estndar 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 estndar que permite el analista de sistemas generar
un anteproyecto de varias facetas que sean comprensibles para los
clientes, desarrolladores y todos aquellos
4. que estn 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 grfico para visualizar, especificar, construir y
documentar un sistema. UML ofrece un estndar 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 programacin, 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 metodologa de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en s mismo qu
metodologa o proceso usar. UML no puede compararse con la
programacin estructurada, pues UML significa Lenguaje Unificado de
Modelado, no es programacin, solo se diagrama la realidad de una
utilizacin en un requerimiento. Mientras que, programacin
estructurada, es una forma de programar como lo es la orientacin a
objetos, la programacin orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML slo 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 jerrquicamente, 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
Interaccin 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
comunicacin, que es una versin simplificada del Diagrama de
colaboracin (UML 1.x) * Diagrama de tiempos (UML 2.0) * Diagrama
global de interacciones o Diagrama de vista de interaccin (UML 2.0)
Fases: las fases del desarrollo de sistemas que soporta uml son:
anlisis de requerimientos, anlisis, diseo, programacin y pruebas.
Anlisis de requerimientos UML tiene casos de uso (use-cases) para
capturar los requerimientos del cliente. A travs del modelado de
casos de uso, los actores externos que tienen inters 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 jerarquas. 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
anlisis de requerimientos puede ser realizado tambin para procesos
de negocios, no solamente para sistemas de software. Anlisis La
fase de anlisis abarca las abstracciones primarias (clases y
objetos) y mecanismos que estn 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 tambin se consideran en esta fase a travs de los modelos
dinmicos en uml. Es importante notar que slo se consideran clases
que estn en el dominio del problema (conceptos del mundo real) y
todava 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. Diseo
En la fase de diseo, el resultado del anlisis es expandido a una
solucin tcnica. Se agregan nuevas clases que proveen de la
infraestructura tcnica: 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
anlisis son agregadas en esta fase. El diseo resulta en
especificaciones detalladas para la fase de programacin.
Programacin En esta fase las clases del diseo son convertidas a
cdigo en un lenguaje de programacin orientado a objetos. Cuando se
crean los modelos de anlisis y diseo en UML, lo ms aconsejable es
trasladar mentalmente esos modelos a cdigo. Pruebas Normalmente, un
sistema es tratado en pruebas de unidades, pruebas de integracin,
pruebas de sistema, pruebas de aceptacin, etc. las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y
son tpicamente ejecutadas por el programador. Las pruebas de
integracin 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
aceptacin conducidas por el cliente verifican que el sistema
satisface los requerimientos y son similares a las pruebas de
sistema.
7. Metodologa del Ciclo de Vida de un Sistema de James Martn
Esta metodologa de desarrollo de Software es mejor conocida como
Metodologa RAD (Rapid Application Development) o Desarrollo rpido
de Aplicaciones, y fue creada por el gur de computacin James Martin
en 1991. Est orientada a disminuir radicalmente el tiempo necesario
para disear e implementar Sistemas de Informacin, el RAD cuenta con
una participacin intensa del usuario, sesiones JAD, prototipaje,
herramientas CSE integradas y generadores de cdigo. El Rad requiere
cuatro ingredientes esenciales: gerencia, gente, metodologas y
herramientas. Fases: Esta metodologa consta de 4 etapas a saber: 1)
Etapa de Planificacin de Requisitos: Esta etapa requiere que los
usuarios con un vasto conocimiento de los procesos de la compaa
determinen cules sern las funciones del sistema. Debe darse una
discusin estructurada sobre los problemas de la compaa que
necesitan solucin. 2) Etapa de Diseo: Esta consiste de un anlisis
detallado de las actividades de la compaa en relacin al sistema
propuesto. Los usuarios participan activamente en
8. talleres bajo la tutela de los profesionales de la
informtica. En ellos descomponen funciones y definen entidades
asociadas con el sistema. Una vez se completa el anlisis se crean
los diagramas que definen las alteraciones entre los procesos y la
data. 3) Construccin: En la etapa de construccin el equipo de
desarrolladores trabajando de cerca con los usuarios finalizan el
diseo y la construccin del sistema. La construccin de la aplicacin
consiste de una serie de pasos donde los usuarios tienen la
oportunidad de afirmar los requisitos y repasar los resultados. 4)
Implementacin: Esta etapa envuelve la implementacin del nuevo
producto y el manejo de cambio del viejo al nuevo sistema. Se hacen
pruebas comprensivas y se adiestran los usuarios. Metodologa de
Jeffrey Whitten Teniendo entonces una idea clara de los conceptos,
relaciones y diferencias entre datos, informacin y conocimiento, se
hace entonces importante, mencionar algunos conceptos tales como
sistema, sistema de informacin y sistema de informacin informtico
ya que aunque sus definiciones puedan parecerse e incluso
superponerse poseen mnimos detalles que marcan la diferencia. Segn
el Diccionario de la Real Academia de la Lengua Espaola en su
edicinvigsimo 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 definicin: la forma en que estn organizados o
dispuestos los distintos elementos de un sistema se llama
configuracin y ms tarde conocer el propsito o resultado que se
desea obtener de un sistema es el primer paso en la definicin de la
manera en que se configurarn sus elementos por lo tanto la salida
de nuestro sistema estar intrnsecamente relacionada con la
configuracin 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
informacin, y aunque su definicin quizs no diste mucho de la
anterior es ms acorde con los objetivos de este trabajo y nos
ofrece una idea ms especfica 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
informacin para apoyar la toma de decisiones y el control de una
organizacin. Elementos fundamentales de un sistema de informacin:
Informacin: La informacin es la base, la materia prima sobre la
cual se mueve todo el engranaje de un sistema de informacin, es
todo lo almacenado, procesado y distribuido en la organizacin por
el sistema. Las personas: Son los encargados de interactuar con la
informacin, quienes la introducen, utilizan y valoran su
importancia en las distintas tareas relacionadas con esta. Medios
para la interaccin con la informacin: Activos tangibles e
intangibles de interaccin con los usuarios para el tratamiento de
la informacin, pueden ser archivos, documentos, hardware, software,
redes de comunicacin, intranets, etctera. Normas y/o tcnicas de
trabajo: Mtodos utilizados por las personas y las tecnologas para
desarrollar sus actividades. Hardware: Todas las piezas fsicas de
la computadora y sus perifricos, dgase teclado, monitor, tarjeta
madre, y los dems 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 computacin
mediante los cuales se dirige las operaciones de una computadora.
Bases de Datos: Una Base de Datos es una coleccin de datos
organizados en celdas. Este elemento se encuentra entre los ms
importantes de un sistema de informacin informtico.
10. Redes: Se denomina as a la interconexin entre computadoras
u otros equipos informticos para hacer posible la comunicacin
electrnica, este elemento es muy importante ya que puede ser
determinante en la efectividad del sistema de informacin
informtico. Metodologa del Proceso Unificado de Desarrollo de
Software Un proceso de software detallado y completo suele
denominarse Metodologa. Las metodologas se basan en una combinacin
de los modelos de proceso genricos (cascada, evolutivo,
incremental, etc.). Adicionalmente una metodologa debera definir
con precisin los artefactos, roles y actividades involucrados,
junto con prcticas y tcnicas recomendadas, guas de adaptacin de la
metodologa al proyecto, guas para uso de herramientas de apoyo,
etc. Habitualmente se utiliza el trmino mtodo para referirse a
tcnicas, notaciones y guas asociadas, que son aplicables a una (o
algunas) actividades del proceso de desarrollo, por ejemplo, suele
hablarse de mtodos de anlisis y/o diseo. La comparacin y/o
clasificacin de metodologas no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle,
informacin 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 anlisis y
diseo, podemos clasificar las metodologas en dos grupos:
Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por
otra parte, considerando su filosofa de desarrollo, aquellas
metodologas con mayor nfasis en la planificacin y control del
proyecto, en especificacin precisa de requisitos y modelado,
reciben el apelativo de Metodologas Tradicionales (o
peyorativamente denominada Metodologas Pesadas, o Peso Pesado).
Otras metodologas, denominadas Metodologas giles, estn ms
orientadas a la generacin de cdigo con ciclos muy cortos de
desarrollo, se dirigen a equipos de desarrollo pequeos, 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 ingeniera del software el trmino
fases de desarrollo expresa cmo ha progresado el desarrollo de un
software y cunto desarrollo puede requerir. Cada versin importante
de un producto pasa generalmente a travs de una etapa en la que se
agregan las nuevas caractersticas (etapa alfa), despus 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 tambin ser reconocidas. Las
etapas se pueden anunciar y regular formalmente por los
desarrolladores del producto, pero los trminos se utilizan a veces
de manera informal para describir el estado de un producto.
Normalmente muchas compaas usan nombres en clave para las versiones
antes del lanzamiento de un producto, aunque el producto y las
caractersticas reales son raramente secretas Metodologa de Kendall
y Kendall El ciclo de vida de vida del desarrollo de sistemas es un
enfoque por fases para el anlisis y el diseo cuya premisa principal
consiste en que los sistemas se desarrollan mejor utilizando un
ciclo especifico de actividades del analista y el usuario. (Kendall
& Kendall) Segn la metodologa de Kendall & Kendall el ciclo
de vida de un sistema consta de siete partes: siendo la primera la
identificacin del problema, la segunda identificacin de requisitos
de informacin, la tercera es el anlisis de las necesidades del
sistema, la cuarta es el diseo del sistema recomendado, la quinta
desarrollo y documentacin del sistema, la sexta prueba y
mantenimiento y la ltima implementacin y evaluacin. Cada fase se
explica por separado pero nunca se realizan como pasos aislados, ms
bien es posible que algunas actividades se realicen de manera
simultnea, y algunas de ellas podran repetirse. FASE I:
Identificacin de problemas, oportunidades y objetivos. Observacin
directa del entorno.
12. Aplicacin de entrevista para recolectar informacin.
Sintetizar la informacin 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: Determinacin de los requerimientos de
informacin. Revisin de los objetivos. Identificar el dominio.
Investigar la razn por la cual se implementa el sistema actual.
Recolectar informacin sobre los procedimientos y operaciones que se
desempean actualmente. FASE III: Anlisis 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 funcin. Elaborar propuesta del sistema con todos
los diagramas de operaciones y de procesos. Realizar el anlisis del
riesgo sobre el realizado en las fases anteriores, tomando en
cuenta el aspecto econmico, tcnico y operacional (estudio de
factibilidad) Estimar en un diagrama de Gantt el tiempo que tomar
desarrollar el sistema. FASE IV: Diseo del sistema recomendado.
Evaluar las tres fases anteriores.
13. Realizar el diseo lgico de todo el sistema. Elaborar
procedimientos precisos para la captura de los datos que van a
ingresar al sistema de informacin. Elaborar el diseo de la base de
datos. Disear las diferentes interfaces de usuarios de cada
operacin, procedimiento y/o funcin. Disear controles y
procedimientos de respaldos que protejan al sistema y a los datos.
Producir los paquetes especficos de programas para los
programadores. Elaborar una lista de las funciones genricas y de
las que ser obligatorio crear. FASE V: Desarrollo y documentacin
del software. Evaluar los procedimientos que va a ser desarrollados
por el programador. Mostrar y explicar cada procedimiento, funcin y
operacin 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 interaccin 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 programacin de las pruebas
del sistema. Realizar un instrumento para evaluar el sistema de
informacin. 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 planificacin de las
horas del mantenimiento del sistema. Elaborar la lista de las
operaciones que pudieran sufrir modificaciones de cdigos.
14. FASE VII: Implementacin y evaluacin del sistema. Planificar
gradualmente la conversin 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 implementacin del
sistema de informacin. En esta fase se capacita a los usuarios en
el manejo del sistema. Parte de la capacitacin la imparten los
fabricantes, pero la supervisin de sta es responsabilidad del
analista de sistemas. Metodologa de Administracin de Relaciones
(RMM) La RMM o Relationship Management Methodology se define como
un proceso de anlisis, diseo y desarrollo de aplicaciones
hipermedia. Los elementos principales de este mtodo son el modelo
E-R (Entidad-Relacin) y el modelo RMDM (Relationship Management
Data Model) basado en el modelo HDM. La metodologa fue creada por
Isakowitz, Stohr y Balasubramanian. Esta metodologa es apropiada
para dominios con estructuras regulares (es decir, con clases de
objetos bien definidas, y con claras relaciones entre esas clases).
Por ejemplo, catlogos o "frentes" de bases de datos tradicionales.
Segn sus autores, est orientada a problemas con datos dinmicos que
cambian con mucha frecuencia, ms que a entornos estticos. El modelo
propone un lenguaje que permite describir los objetos del dominio,
sus interrelaciones y los mecanismos de navegacin hipermedia de la
aplicacin. 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 presentacin de las entidades. Un slice corresponde a un
subconjunto de atributos de una misma entidad destinados a ser
presentados de forma agrupada. La navegacin se modeliza con la
ayuda de primitivas de acceso, enlaces estructurales
(unidireccional
15. y bidireccional) que permiten especificar la navegacin
entre slices, y visita guiada condicional, ndice condicional y
agrupacin, que permiten especificar la navegacin entre entidades.
El esquema completo del dominio y de la navegacin de la aplicacin
se denomina esquema RMDM y se obtiene como resultado de las tres
primeras etapas del mtodo. Las etapas son: Primera etapa:
representar los objetos del dominio con la ayuda del modelo
Entidad-Relacin ampliado con relaciones asociativas (aqullas que
permiten representar caminos navegacionales entre entidades puestos
en evidencia en la fase de anlisis). Segunda etapa: determinar la
presentacin del contenido de las entidades de la aplicacin 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-Relacin 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 navegacin inducidos por las relaciones asociativas
del esquema E-R+. A continuacin, es posible definir estructuras de
acceso de alto nivel (agrupaciones), lo que permite dotar a la
aplicacin de accesos jerrquicos a niveles diferentes de los trozos
de informacin. El esquema RMDM resultante se obtiene aadiendo al
esquema E-R+ las agrupaciones y caminos navegacionales definidos en
esta etapa. Las cuatro etapas restantes consisten en: definicin del
protocolo de conversin de elementos del diagrama RMDM en objetos de
la plataforma de desarrollo concepcin del interfaz usuario
concepcin del comportamiento en ejecucin construccin del sistema y
test.
16. Metodologa Orientada a Objetos La metodologa OMT (Object
Modeling Technique) fue creada por James Rumbaugh y Michael Blaha
en 1991, mientras James diriga un equipo de investigacin de los
laboratorios General Electric. OMT es una de las metodologas de
anlisis y diseo orientada a objetos, ms madura y eficiente que
existe en la actualidad. La gran virtud que aporta esta metodologa
es su carcter de abierta (no propietaria), que le permite ser de
dominio pblico y , en consecuencia, sobrevivir con enorme
vitalidad. Esto facilita su evolucin para acoplarse a todas las
necesidades actuales y futuras de la ingeniera de software. Las
fases que conforman a la metodologa OMT son: 1. Anlisis. El
analista construye un modelo del dominio del problema, mostrando
sus propiedades ms importantes. El modelo de anlisis es una
abstraccin 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 aplicaciny no conceptos
informticos 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 informticos. 2. Diseo del
sistema. El diseador del sistema toma decisiones de alto nivel
sobre la arquitectura del mismo. Durante esta fase el sistema se
organiza en subsistemas basndose tanto en la estructura del anlisis
como en la arquitectura propuesta. Se selecciona una estrategia
para afrontar el problema. 3. Diseo de objetos. El diseadorde
objetos construye un modelo de diseo basndose en el modelo de
anlisis, pero incorporando detalles de implementacin. El diseo 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 diseo puede ser implementado en distintos lenguajes
(orientados y no orientados a objetos, bases de datos, etc.).
17. 4. Implementacin. Las clases de objetos y relaciones
desarrolladas durante el anlisis de objetos se traducen finalmente
a una implementacin concreta. Durante la fase de implementacin es
importante tener en cuenta los principios de la ingeniera del
software de forma que la correspondencia con el diseo sea directa y
el sistema implementado sea flexible y extensible. No tiene sentido
que utilicemos AOO y DOO de forma que potenciemos la reutilizacin
de cdigo y la correspondencia entre el dominio del problema y el
sistema informtico, si luego perdemos todas estas ventajas con una
implementacin de mala calidad. Metodologa de Sistemas Expertos por
David Rolston Es una aplicacin informtica 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 informacin de uno o ms
expertos en un rea especfica. Se puede entender como una rama de la
inteligencia artificial, donde el poder de resolucin de un problema
en un programa de computadora viene del conocimiento de un dominio
especfico. Estos sistemas imitan las actividades de un humano para
resolver problemas de distinta ndole (no necesariamente tiene que
ser de inteligencia artificial). Tambin se dice que un SE se basa
en el conocimiento declarativo (hechos sobre objetos, situaciones)
y el conocimiento de control (informacin sobre el seguimiento de
una accin). Para que un sistema experto sea herramienta efectiva,
los usuarios deben interactuar de una forma fcil, 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 explicacin para cada una de estas reglas, que a la
vez se basan en hechos. 2. Adquisicin 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 ms rapidez y eficacia todas las tareas que
realiza. Debido a esto en la actualidad se estn mezclando
diferentes tcnicas o aplicaciones aprovechando las ventajas que
cada una de estas ofrece para poder tener empresas ms seguras. Un
ejemplo de estas tcnicas sera los agentes que tienen la capacidadde
negociar y navegar a travs de recursos en lnea; y es por eso que en
la actualidad juega un papel preponderante en los sistemas
expertos. Metodologa del Software Educativo por lvaro Galvis (ISE)
Es una metodologa de desarrollo de software que contempla una serie
de fases o etapas de un proceso sistemtico atendiendo a: anlisis,
diseo, desarrollo, prueba y ajuste, y por ltimo implementacin.
Etapas: Etapa 1: Anlisis Caractersticas de la poblacin objetivo:
edad (fsica y mental), sexo, caractersticas fsicas 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, fsico o
psicolgico, entorno familiar y escolar, etc. Etapa 2: Diseo
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
interaccin entre usuario y mquina, 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 aplicacin usando la informacin obtenida
anteriormente. Tomando en cuenta las restricciones que se tengan.
Etapa 4: Prueba Piloto En esta etapa se pretende ayudar a la
depuracin del Sistema Educativo a partir de su utilizacin por una
muestra representativa de los tipos de destinatarios para los que
se hizo y la consiguiente evaluacin formativa. Es imprescindible
realizar ciertas validaciones (efectuadas por expertos) de los
prototipos durante las etapas de diseo y prueba en uno a uno de los
mdulos desarrollados, a medida que estos estn funcionales. Etapa 5:
Prueba de Campo La prueba de campo de un Sistema Educativo es mucho
ms que usarlo con toda la poblacin 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 pareca tener sentido, lo sigue
teniendo, es decir, si efectivamente la aplicacin satisface las
necesidades y cumple la funcionalidad requerida. Metodologa de
Sistemas Blandos (SSM) de Peter Checkland SSM de Peter Checkland es
una metodologa sistmica fundamentada en el concepto de perspectiva
o en el lenguaje de la metodologa Weltanschauung. Un weltanschauung
representa la visin propia de un observador, o grupo de ellos,
sobre un objeto de estudio, visin 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 idealizacin de estos
weltanschauung para proponer cambios sobre el sistema que en teora
deberan tender a mejorar su funcionamiento. Metodologa MERINDE
MeRinde es un proyecto que propone un estndar abierto para el
proceso de desarrollo de software orientado a planes que se
estructura en dos dimensiones o ejes. La metodologa 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 estn 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 agrupacin de tareas relacionadas. Las
disciplinas que conforman esta metodologa se fundamentan en las
propuestas por RUP, las cuales se dividirn en dos grupos. El
primero comprende las disciplinas fundamentales asociadas con las
reas de ingeniera: Modelado del Negocio Requerimientos Anlisis y
Diseo Implementacin Pruebas Implantacin El segundo grupo lo
integran aquellas disciplinas llamadas de soporte o gestin: Gestin
de Configuracin y Cambios Gestin del Proyecto Gestin del
Ambiente
21. Fases: Fase de Inicio Fase de Elaboracion Fase de
Construccion Fase de Transicion Metodologa SCRUM Scrum es una
metodologa gil y flexible para gestionar el desarrollo de software,
cuyo principal objetivo es maximizar el retorno de la inversin para
su empresa (ROI). Se basa en construir primero la funcionalidad de
mayor valor para el cliente y en los principios de inspeccin
continua, adaptacin, auto-gestin e innovacin. Con la metodologa
Scrum el cliente se entusiasma y se compromete con el proyecto dado
que lo ve crecer iteracin a iteracin. 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 iteracin sin ningn
problema. Esta metdica de trabajo promueve la innovacin, motivacin
y compromiso del equipo que forma parte del proyecto, por lo que
los profesionales encuentran un mbito propicio para desarrollar sus
capacidades.
22. Conclusin Un proyecto de desarrollo de un Sistema de
Informacin comprende varios componentes o pasos llevados a cabo
durante la etapa del anlisis, el cual ayuda a traducir las
necesidades del cliente en un modelo de Sistema que utiliza uno ms
de los componentes: Software, hardware, personas, base de datos,
documentacin y procedimientos. En una organizacin o Empresa, el
anlisis y Diseo de Sistemas, es el proceso de estudiar su Situacin
con la finalidad de observar cmo trabaja y decidir si es necesario
realizar una mejora; el encargado de llevar a cabo estas tareas es
el