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.

Upload: alexander-pino

Post on 09-Aug-2015

66 views

Category:

Documents


2 download

TRANSCRIPT

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  23. 23. Bibliografa 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