Crucigrama de Sistemas Expertos

Sistemas Expertos

  

Complete the crossword, then click on "Check" to check your answer. If you are stuck, you can click on "Hint" to get a free letter. Click on a number in the grid to see the clue or clues for that number.

								1
2		3
		4
5
					6														7
8
9	10																11
														12
			13
							14
				15
												16

Across: 3. ¿Quién es denominado como Sistema de Consulta? 4. Es el núcleo de los Sistemas Expertos? 5. Cuales son las Siglas de la rama de los Sistemas Expertos? 6. Usa un conjunto de reglas que relacionan varios objetos? 8. Como están definidos los Sistemas Expertos? 9. Es una memoria auxiliar que contiene a la vez los datos? 12. Los Sistemas basados en reglas son de razonamiento? 13. Qué utilizan los Sistemas Expertos de los usuarios? 14. Un Sistema Experto que tipo de carácter tiene? 15. Una de las principales desventajas de un Sistema Experto? 16. Qué herramientas ayudan al desarrollo de los Sistemas Expertos?

Down: 1. Contiene gran cantidad de información en la arquitectura de los Sistemas Expertos? 2. Permite crear un nuevo Experto? 7. Cuál es la Función Principal de un Sistema Experto? 10. Quién publico en 1.950 el trabajo titulado "Inteligencia y Funcionamiento de las Máquinas"? 11. De que naturaleza es el conocimiento que manipula un Sistema Experto?

Sistemas Expertos

Make your own mind maps with Mindomo.

Diagrama de Colaboración

Diagrama de Secuencia

Diagrama de Caso de Uso

Diagrama Caso de Uso

Índice 1. Introducción 2. Definición 3. Propósito 4. Características 5. Ventajas 6. Desventajas 7. Elementos 7.1 Actores 7.1.1 Tipos de Actores 7.1.1.1 Actores Principales 7.1.1.2 Actores Secundarios 7.1.1.3 Materiales Externos 7.2 Caso de Uso 7.3 Relaciones 7.3.1 Asociación 7.3.2 Dependencia o Instanciación 7.3.3 Generalización 8. Ejercicio Práctico 8.1 Diagrama de Caso de Uso 9. Bibliografía Introducción. El diagrama de caso de uso representa las principales interacciones entre los usuarios y el sistema, mostrando las distintas operaciones y cómo se relacionan con su entorno, así este diagrama se encarga de mostrar la funcionalidad futura de una aplicación de software además de documentar el comportamiento, determinar los requisitos funcionales del sistema y representar las funciones que un sistema puede ejecutar. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa. Definición. Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se producen en el mismo. Propósito Decidir y describir los requerimientos funcionales del sistema, dando lugar a un acuerdo entre el cliente (y/o usuario final) y los programadores que desarrollan el sistema. Dar una descripción clara y consistente de lo que debería hacer el sistema, de modo que el modelo se use a lo largo del proceso de desarrollo. Proporcionar una base para realizar verificaciones (tests) del sistema que comprueben su funcionamiento. Proporcionar la capacidad para rastrear requerimientos funcionales en clases y operaciones reales del sistema, verificando los casos de uso afectados por cambios y extensiones al sistema.  Características Describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario. Se documentan con un lenguaje informal(fácil de entender para todos). Un caso de uso siempre es iniciado por un actor: se realiza en interés de un actor que, directa o indirectamente, debe ordenar al sistema que inicie el caso de uso. Un caso de uso proporciona un valor a un actor: debe entregar alguna clase de valor tangible para el usuario. Se los utiliza para la obtención y modelamiento de requerimientos. Permiten definir los límites del sistema y las relaciones entre el sistema y su entorno. Pueden ser utilizados en proyectos que sigan cualquier metodología de desarrollo. En UML, un diagrama de casos de uso muestra la relación entre actores y los casos de uso del sistema.  Ventajas Lenguaje de comunicación entre usuarios y desarrolladores. Comprensión detallada de la funcionalidad del sistema. Facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente. Mayor control para mantener las sucesivas previsiones de los programas.  Desventajas En sistemas grandes toman mucho tiempo para definir todos los casos de uso. El análisis de calidad depende de como se haya realizado la descripción inicial del caso de uso. No establecen los requisitos funcionales. Tampoco permiten establecer los requisitos no funcionales. Cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.  Elementos Los elementos que pueden aparecer en un diagrama de casos de uso son: ACTORES Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Un actor representa un rol que es desempeñado con respecto al sistema(es importante destacar el uso de la palabra ³ROL´, ya que esto especifica que un actor no necesariamente representa a una persona en particular, sino la labor que realiza frente al sistema, pero no forman parte del sistema. Un actor puede intervenir en varios casos de uso. Un actor necesita el caso de uso y/o participa en el. En la elaboración de un caso de uso pueden intervenir diferentes actores. Se representa mediante una figura humana. TIPOS DE ACTORES ACTORES PRINCIPALES: Son las personas que utilizan las funciones principales del sistema. ACTORES SECUNDARIOS: Personas que efectúan tareas administrativas o de mantenimiento. MATERIALES EXTERNOS: Son los materiales imprescindibles que forman parte de la aplicación y que deben de ser utilizados. CASO DE USO Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. RELACIONES Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<>) o de Herencia (<>). Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores). Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). Uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. Ejercicio Práctico Sistema de Atención a Clientes para una Casa de Equipos Deportivos  Diagrama de Caso de Uso  Bibliografía Ingeniería-de-Software-Un-Enfoque-Práctico-6th-edicion-Roger-pressman-2 www.ctr.unican.es/asignaturas/MC.../Casos_de_uso.pdf http://es.scribd.com/doc/58128216/Diagrama-de-Caso-de-Uso http://redalyc.uaemex.mx/pdf/496/49615315.pdf http://www.codecompiling.net/files/slides/UML_clase_02_UML_casos_de_uso.pdf

Ventajas y desventajas de los modelos sw

Modelo Lineal Secuencial

VENTAJAS

     Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno.

     Facilita la gestión del desarrollo.

     La calidad del producto resultante es alta.

     Sus fases son conocidas por los desarrolladores.

     Se tiene todo muy bien organizado y no se mezclan las fases.

     La planificación es sencilla.

     Los usuarios lo pueden comprender fácilmente.

DESVENTAJAS

     En general, establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable: Los usuarios no pueden imaginárselo que quieren hasta que no ven un sistema funcionando.

     Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia, todo cambia.

     El usuario debe esperar mucho tiempo hasta ver los resultados.

     Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases siguientes con un efecto conocido como bola de nieve.

     Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y éste recae, en su mayor parte.

Modelo de Construcción de prototipos

VENTAJAS

Permite al desarrollador darse  en cuenta de lo que quiere el cliente

     Se crea con rapidez

     Son Fácilmente modificable

     Reduce costo.

     Aumenta la probabilidad de Éxito

DESVENTAJAS

     Administración difícil.

     Adaptarlo como el sistema final.

     El Desarrollador y el  Cliente tienen poca comunicación.

     Surge Cambios imprevistos que retrasan el progreso de prototipo.

Modelo DRA

VENTAJAS

     Permite trabajar en el a varias personas a la vez.

     El desarrollo se realiza a un nivel de abstracción mayor.

     Los entregables pueden ser trasladados a otra plataforma.

     Interfaz gráfica estándar.

     Ciclo de desarrollo más pequeño.

DESVENTAJAS

     El enfoque DRA tiene inconvenientes para proyectos grandes, necesita suficientes recursos de humanos para crear el numero correcto de equipos.

     Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema los proyectos fallaran.

     El DRA sería inapropiado cuando los riesgos técnicos son altos.

     Indeficientes.

Modelos Evolutivos de proceso del software

Modelo Incremental

VENTAJAS

     Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

     También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.

     El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

     Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

     Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

     Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

DESVENTAJAS

     El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

     Requiere de mucha planeación, tanto administrativa como técnica.

     Requiere de metas claras para conocer el estado del proyecto.

     Se necesitan pruebas de regresión y su coste puede aumentar.

Modelo Espiral

VENTAJAS

     El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.

     Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.

     El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.

     El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.

     En la utilización de grandes sistemas a doblado la productividad.

DESVENTAJAS

     Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

     Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

     Genera demasiado tiempo en el desarrollo de sistemas.

     Si no existen grupos de trabajo no se puede trabajar en éste método.

Modelo Espiral WINWIN

VENTAJAS

     Reduce riesgos del proyecto

     Incorpora objetivos de calidad

     Integra el desarrollo con el mantenimiento, etc.

     El software evoluciona a medida que progresa el proceso, el desarrollador y el cliente y reaccionan mejor ante de riesgos.

DESVENTAJAS

     Genera mucho tiempo en el desarrollo del sistema

     Modelo costoso

     Requiere experiencia en la identificación de riesgos.

     Debido a su elevada complejidad no es aconsejable utilizarlo en sistemas pequeños.

Modelo de Desarrollo concurrente

VENTAJAS

     Excelente para proyectos en los que se conforman grupos de trabajo independientes.

     Proporciona una imagen exacta del estado actual de un proyecto.

DESVENTAJAS

     Si no se dan las condiciones señaladas no es aplicable.      

     Si no existen grupos de trabajo no se puede trabajar en este método

Modelo de desarrollo de software basado en componentes

VENTAJAS:

     Reutilización del Software.

     Mayor calidad. (Aunque esta depende de si somos o no buenos           compradores).

     Ciclos de desarrollo se hacen más cortos.

     El dinero invertido regresa en menos tiempo.

DESVENTAJAS:

     Genera mucho tiempo en el desarrollo del sistema.

     Modelo costoso.

     Cuando un sistema falla se pierde tiempo y coste dentro de la empresa.

     Exige una cierta habilidad en los analistas (es bastante difícil).

Modelo de Métodos Formales

VENTAJAS

     Se comprende mejor el sistema.

     La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.

     El sistema se describe de manera más precisa.

     Mayor calidad software respecto al cumplimiento de las especificaciones.

DESVENTAJAS

     El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.

     Los investigadores por lo general no conocen la realidad industrial.

     Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.

     Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

GRUPO 1

INTEGRANTES:

Jennifer Arriaga Aguilera

Janio Robelli Guerrero

Katherine Zambrano Delgado

Luis Espinoza Campusano

Sara Chica Mora