UN-COGNI CÓMO HACER INGENIERIA DE CONOCIMIENTOS

Presentación del tema: "UN-COGNI CÓMO HACER INGENIERIA DE CONOCIMIENTOS"— Transcripción de la presentación:

1 UN-COGNI CÓMO HACER INGENIERIA DE CONOCIMIENTOS
Ing. ALFONSO PEREZ GAMA - IEEE Senior Member Profesor Titular Maestro Universitario

2 CONCLUSIONES Y REFLEXIONES
CONTENIDO UN-COGNI Versión 2.0 CONCLUSIONES Y REFLEXIONES

3 SOLUCION IMPLEMENTACION INSTITUCIONAL Nivel Organizacional NECESIDAD
CONCEPCIÓN ENTREGA Desarrollo Arquitectónico Construcción (Integración-Pruebas) DESARROLLO (Implementation) SOLUCION

4 UN-COGNI Versión 2.0 Planificacion Cognitiva DEFINICIÓN Aprendizaje
Ontología Diseño Solución de Problemas Construcción del Prototipo Validacion- Legitimación Obtención del Sistema y Evolución DEFINICIÓN DESARROLLO CONSTRUCCION

5 FASES UN-COGNI Planificación Cognitiva
Adquisición de Conocimientos o proceso de aprendizaje maquinal: Ontología, Representación y Organización de Conocimientos: Diseño de alternativas y selección de la Solución Construcción del Prototipo Verificación, Validación, Contrastación Legitimación Obtención del Sistema final

6 GESTION DE CONOCIMIENTOS
PLANEACION SIGUIENTE FASE GESTION DE CONOCIMIENTOS 1- Planificación Cognitiva: Generalidades Cómo hacer un Plan cognitivo Talleres ConExpertos Talleres respecto a la incorporación de conocimientos PRODUCTOS DE LA FASE

7 Determinación del sistema (estructura y componentes),
PLANEACION 1- Generalidades Planificación Cognitiva: Determinación del sistema (estructura y componentes), el modelo (comportamiento), especificación detallada del problema selección de los métodos y técnicas, los requerimientos de usuario y de interfaz identificación de los tipos de datos y objetos y calidad de la solución.

8 PLANEACION

9 PLANEACION compromiso de los altos directivos y el involucramiento del grupo de expertos del dominio. Se hacen reuniones preliminares: se analizan los aspectos a considerar que estén relacionados con las capas de conocimientos a adicionar. Se determinan mecanismos para adquirir dichos conocimientos. Determinación del sistema (estructura y componentes), el modelo (comportamiento), especificación detallada del problema con su dominio, requerimientos computacionales, escenarios, construcción de un ejemplo de la sesión de un usuario, decisión de los métodos y técnicas, los requerimientos de usuario y de interfaz, identificación de objetos y calidad de la solución. Análisis de costo/beneficio. Identificación y definición de diccionarios y conceptos para representar en la BC con el fin de seleccionar los conocimientos relevantes.

10 PLANEACION Determinación del subsistema para incorporar conocimientos: se analizan los resultados de la ingeniería de requerimientos y se escoge un subsistema con el fin de delimitar el conocimiento a involucrar. Determinación del módulo específico: una vez elegido el subsistema, se analiza funcionalmente y según la prioridad de los módulos y los requerimientos de los usuarios, se elige uno para la adición de capas de conocimiento.

11 COMO PUEDO HACER PLANEACIÓN COGNITIVA
PLANEACION COMO PUEDO HACER PLANEACIÓN COGNITIVA ES UNA FORMA DE CONSTRUIR FUTURO. ES UN SISTEMA QUE DEBE DESCRIBIR LA MISION Y LA VISION A LARGO PLAZO DE LA INSTITUCION DEFINIR COMO AGREGAR VALOR MEDIANTE CONOCIMIENTO E INTELIGENCIACION DE SUS NEGOCIOS

12 PLANEACION

13 UN PLAN QUE FUNCIONA: 1. PRIMERO, UN PLAN COGNITIVO DEBE SERVIR:
PLANEACION UN PLAN QUE FUNCIONA: 1. PRIMERO, UN PLAN COGNITIVO DEBE SERVIR: COMO HERRAMIENTA PARA EVALUAR LA VERDADERA POSICION Y CAPACIDAD DE LA COMPAÑÍA EN EL III MILENIO  PARA IDENTIFICAR POSIBILIDADES POTENCIALES Y EN DESARROLLO,  PARA DISEÑAR UNA POSICION VENTAJOSA Y COMPETITIVA, Y  ESPECIALMENTE PARA DETERMINAR LO QUE DEBE HACERSE PARA EJECUTAR UNA ESTRATEGIA EN PARTICULAR.

14 PLANEACION

15 3. UN PLAN COGNITIVO DEBE ESTAR ALINEADO CON EL PLAN ESTRATEGICO
PLANEACION 3. UN PLAN COGNITIVO DEBE ESTAR ALINEADO CON EL PLAN ESTRATEGICO QUE DEBE SER UN MARCO O PUNTO DE ENFOQUE PARA TODAS LAS ACTIVIDADES DE LA ORGANIZACION. UNIENDO CENTENARES DE EMPLEADOS, DOCENAS DE DEPARTAMENTOS Y CUALQUIER NUMERO DE GERENTES CON UN CARACTER FUERTE PARA QUE TODOS SE MUEVAN EN LA MISMA DIRECCION AL MISMO TIEMPO Y LOGREN LAS METAS ACORDADAS A PESAR DE LOS PROBLEMAS Y OBSTACULOS QUE SURJAN POR EL CAMINO.

16 PLANEACION

17 Talleres con los Expertos
PLANEACION Talleres con los Expertos Antes de iniciar los talleres, el líder del proyecto y el ingeniero de conocimientos deben desarrollar una estrategia de acción respecto a los siguientes interrogantes: ·   ¿Cómo se va a incentivar a los expertos? ·  ¿Cómo pueden los expertos estar seguros de que no vayan a perder su empleo o que a su trabajo no se le va a restar importancia una vez el sistema esté operando? ·   ¿Los expertos son conscientes de la existencia de otras personas en la organización cuyos trabajos sí pueden tener dificultades cuando llegue el SI? ¿Cómo manejar esta situación?

18 PLANEACION ·          ¿Cómo puede la empresa determinar si los expertos están acertando sobre la resolución de problemas? En el taller inicial es importante motivar a los expertos y asegurar la completa cooperación y el grupo de trabajo para la Ingeniería de Conocimientos debe determinar los recursos necesarios para desarrollar la base de conocimientos, con base al análisis costo/beneficio  Las sesiones de entrevistas con los expertos deben cubrir el rango suficiente de ejemplos (casos) para solución de problemas diferentes, con el fin de que la mayor parte de las posibles reglas estén definidas. Es indispensable documentar cada uno de los posibles resultados para implementar una adecuada justificación

19 El sistema requiere o no el uso de variables probabilísticas.
PLANEACION  Talleres respecto de las necesidades de la incorporación de conocimientos La solución del problema no requiere únicamente el simple sentido común. Se requieren especialmente habilidades cognitivas (no físicas): e.g. aprender, razonar simbólicamente. Existe por lo menos un experto que quiere cooperar conociendo de antemano su responsabilidad (se recomienda que el ingeniero de conocimientos evalúe este aspecto y, si es posible, haga un análisis con los expertos). El sistema requiere o no el uso de variables probabilísticas. El sistema requiere de contextos lingüísticos o razonamientos ambiguos (uso de lógica fuzzy).

20 · Las tareas no son muy difíciles.
PLANEACION  · Los expertos involucrados pueden articular sus métodos de solución de problemas. · Los expertos involucrados están de acuerdo con el conoci­miento y el enfoque de solución del problema. ·  Las tareas no son muy difíciles. · Las tareas son relativamente fáciles de entender, definir y descomponer claramente. · La definición de la tarea debe ser estable, es decir, no debe ser muy cambiante, en el corto plazo. · Las técnicas convencionales de solución por computador (e.g. algoritmos) no son satisfactorias para resolver el problema. ·  Se pueden tolerar resultados incorrectos o no óptimos. Existen pruebas de datos y hay disponibilidad de casos concre­tos

21 Identificacion de las clases de Conocimientos
PLANEACION PRODUCTOS DE LA FASE I Identificacion de las clases de Conocimientos Identificación de las capas de Conocimientos de la empresa Identificación de Activos Inteligentes Metodología, Herramientas y Técnicas Portafolio de Subsistemas Inteligentes Recursos de Capital Intelectual Cronograma Plan de Aseguramiento de Calidad

22 Adquisición de Conocimientos
2- Adquisición de Conocimientos o proceso de aprendizaje maquinal: OBJETIVOS CONOCIMIENTO EN INGENIERÍA DE SISTEMAS CAPAS DE CONOCIMIENTOS PRODUCTOS DE LA FASE FASE ANTERIOR SIGUIENTE FASE

23 Adquisición de Conocimientos
OBJETIVOS fase II Obtención del conocimiento que requiere el sistema, en forma sistematizada o automática o con la ayuda de los expertos. Este conocimiento puede ser específico cuando el dominio del problema y los procedimientos son la solución del mismo; o puede ser conocimiento general, por ejemplo conocimiento sobre toda una empresa.

24 de la Ingeniería De Sistemas
Adquisición de Conocimientos Areas Técnicas de la Ingeniería de Sistemas al medio Definir y desarrollar los Procesos de ingeniería de Sistemas. 2. Gestionar Competencias 3. Gerstionar Tecnología 4.Gestionar Ingeniería de Sistemas como soporte al medio ambiente COMPETENCIAS en de la Ingeniería De Sistemas Areas de Gestión Ingeniería de Sistemas 13. Definir los implicados y niveles de Requerimientos. 14. Definir Problemas Técnicos 15. Definir Solución 16. Evaluar y seleccionar 17. Integrar el Sistema 18. Verificar el Sistema 19. Validar el Sistema Areas Técnicas de atención de la Ingeniería de Sistemas 5. Planificar y organizar 6. Monitorear y controlar 7. Integrar Disciplinas 8.Coordinar con proveedores Gestión del Riesgo Gestionar Configuración Aseguramiento de Calidad

25 Información y Conocimiento
Adquisición de Conocimientos Gestión de Tecnología Ciencia Medio Ambiente Organización Información y Conocimiento Figura 1. Sistema Socio-Técnico

26 INVESTIGACION Y EXPERIMENTACION ADQUISICION
Adquisición de Conocimientos Definir y desarrollar los Procesos de ingeniería deSistemas. 2. Gestionar Competencias 3. Gestionar Tecnología 4.Gestionar Ingeniería de Sistemas como soporte al medio ambiente GESTION DE SISTEMAS PROCESO PRODUCTO E M P R S A 13. Definir los implicados y niveles de Requerimientos. 14. Definir Problemas Técn. 15. Definir Solución 16. Evaluar y seleccionar 17. Integrar el Sistema 18. Verificar el Sistema 19. Validar el Sistema 5. Planificar y organizar 6. Monitorear y controlar 7. Integrar Disciplinas 8.Coordinar con proveedores Gestión del Riesgo Gestionar Configuración Aseguramiento de Calidad PLANEACION INVESTIGACION Y EXPERIMENTACION ADQUISICION

27 Producto Conocimientos Prospectivos Conocimientos Vivenciales
Adquisición de Conocimientos Producto Esfuerzos Gerenciales e Ingeniería de Sistemas Sistema Socio-Técnico Capas de Conocimientos de Ingeniería de Sistemas Conocimientos Prospectivos Conocimientos para Resolución de Problemas Conocimientos Vivenciales Aprendizaje Dual: Hombre Máquina: Memoria Institucional

28 y= ƒ[Estrategia, Objetivo, PlanSolucion, ....]
Conocimiento Prospectivo MODELO T0 SISTEMA SO MODELO TK SISTEMA Sk y= ƒ[Estrategia, Objetivo, PlanSolucion, ....] Vision Mision Escenarios BRECHA Y = ƒ(x) Visión Misión

29

30 Cuál es la brecha? Prospectiva Negocios Electrónicos
Donde estamos hoy: Aplicación de negocios. Mercados Pequeños. Red Donde deseamos estar: Prospectiva Negocios Electrónicos Requerimientos Economía Global, TLC, ALCA Necesidad de inteligenciación. Arquitectura computacional Arquitectura de servicios.

31 Desarrollo Efectivo y Metáfora de la Brecha
Rancho Ardiendo Estado Futuro Definición Visión Estado Presente Programas de infraestructura Transición General Programas de exploradores

32 Productos de la fase II CONOCIMIENTO RECUPERADO BASES DE CONOCIMIENTOS
Adquisición de Conocimientos Productos de la fase II CONOCIMIENTO RECUPERADO BASES DE CONOCIMIENTOS REPOSITORIOS MAPA CONCEPTUAL DE CONOCIMIENTOS ESTRUCTURAS DE CONOCIMIENTOS

33 METODOS SEMIAUTOMATICOS APRENDIZAJE MAQUINAL MÉTODOS FORMALES
Ontología Ontología, Representación y Organización de Conocimientos: OBJETIVOS METODOS MANUALES METODOS SEMIAUTOMATICOS APRENDIZAJE MAQUINAL MÉTODOS FORMALES PRODUCTOS DE LA FASE FASE ANTERIOR SIGUIENTE FASE

34 Ontología OBJETIVOS Fase III: Se distribuye, jerarquiza, organiza, se desarrolla el mapa de conocimientos y se representa por medio de algún formalismo o estructura de información u objetos en la base de conocimientos, para posibilitar su uso computacional.

35 Ontología Métodos Manuales ü        La entrevista no estructurada: el proceso es de manera informal, lo que ahorra tiempo y ayuda a obtener rápidamente la estructura del dominio. ü        La entrevista estructurada: es un proceso sistemático orientado por objetivos, que conduce a la comunicación entre el ingeniero de conocimientos y el experto, de una manera organizada. Reduce la complejidad de los problemas inherentes de las entrevistas no estructuradas. ü        Análisis de casos: En solución de problemas que Incluye un análisis documental sobre situaciones ocurridas en el pasado (casos hipotéticos o reales) a personas tales como expertos, usuarios o administradores se pueden interrogar a este respecto. ü       

36 Ontología Métodos Manuales ü        El análisis de incidentes críticos: se seleccionan los casos a investigar, usualmente aquellos que son relevantes, difíciles o de un interés especial. ü        La lluvia de preguntas e ideas: Permite conocer la opinión de diferentes expertos con el fin de generar ideas de apoyo para la adquisición de conocimientos. ü        El desarrollo de prototipos: es un método para inducir a los expertos a contribuir en el conocimiento; consta de la realización de un prototipo del sistema, el cual es útil para mejorarlo por medio de cambios con lo que es posible analizar los resultados. Análisis de tareas particulares con el experto: permite realizar la adquisición de conocimientos orientado por objetivos y metas. Es el proceso de razonamiento asociado a una tarea particular, a través del cual se clasifica las labores y se analiza completamente el sistema.

37 Métodos Semiautomáticos Computacionales
Ontología Métodos Semiautomáticos Computacionales Apoyar al experto en la construcción de la BC, guiándolo en las tareas necesarias con ninguna o muy poca ayuda del ingeniero de conocimientos, y El computador ayuda al experto a reducir o eliminar los problemas que se hayan discutido con anterioridad, especialmente aquellos que implican ambigüedad. Para este fin se emplea el SHELL que permite al experto representar sus conocimientos de manera muy sencilla y refinar su BC. Modelo inicial del dominio se emplean la simulación o el modelamiento UML. El objetivo de este enfoque es brindar al usuario la capacidad de visualizar los problemas del mundo real y manejar sus elementos a través de las gráficas.

38 La Comunidad de UML está creciendo, AUGE
Ontología METODOS FORMALES Notación Z, VDM.... UML La Comunidad de UML está creciendo, AUGE Hay problemas que se pueden representar con UML. Ciertos formalismos de KR La Solución de problemas asociada con generar un plan para ser ejecutado No hay coincidencia 1:1 entre KR y el UML: Hay diferencias conceptuales Muchas limitaciones para implementar Ontologías Se puede aprovechar las convergencias

39 Ontología Métodos Automáticos y Aprendizaje Maquinal En esta clase de métodos los roles del experto y del ingeniero de conocimientos se minimizan o prácticamente se eliminan. Un ejemplo es el caso en que el desarrollador de la BC puede ser un analista de sistemas. El experto participa como fuente de conocimientos y como evaluador de resultados, y el ingeniero de conocimientos sería el mismo analista. Un problema de investigación es la automatización de un proceso de Minería de Datos

40 PRODUCTOS DE LA FASE III
Ontología PRODUCTOS DE LA FASE III Bases de Conocimientos Plenamente Reorganizables Redes Internas y Externas Portafolio de Capacidades: de Asimilación, Estratégicas; Tecnológicas, de Innovación

41 4-Diseño de alternativas y selección de la Solución
Definición de las soluciones potenciales Determinación del conocimiento relacionado con el aspecto aplicativo del módulo Determinación del conocimiento relacionado con la resolución de problemas Descomposición de tareas Identificación de las reglas de producción Identificación de las metareglas y los marcos FASE ANTERIOR SIGUIENTE FASE PRODUCTOS DE LA FASE

42 Se debe conocer cada respuesta posible a través del tiempo
Diseño Objetivo: que la BC brinde consejos en el momento en que se requiera y no de repente, basada en una conclusión momentánea. Se debe organizar el dominio del conocimiento relacionado con el módulo seleccionado: todas las posibles soluciones, entradas, salidas, respuestas, alternativas o recomendaciones. Se debe identificar las salidas exactas que se deben presentar al usuario en la pantalla. Se debe conocer cada respuesta posible a través del tiempo

43 Las capas de conocimientos se plantea a todo nivel de la organización
Las capas de conocimientos se plantea a todo nivel de la organización. En este momento se determina el conocimiento operativo, es decir, lo que está relacionado con la aplicación (operación) del sistema.  Conocimiento del dominio del módulo: Se determina el conocimiento que requiere el usuario para desempeñarse apropiadamente en la empresa.  Conocimiento deducido: Se precisa el conocimiento que se puede inferir por medio de la utilización de la IA y que apoya al usuario.  Conocimiento sobre los proceso y tareas del módulo: Se identifi­ca el cono­cimiento que se requiere para el de­sarro­llo de las tareas del sistema, y se relaciona con la base de planes. Estas capas también sirven de soporte para la planea­ción a nivel estratégico y táctico, y se emplean en la genera­ción y reconocimiento de planes Diseño

44 Diseño Las capas de conocimientos que se introduzcan también deben apoyar la administración a nivel táctico y operativo, por lo cual se debe determinar el conocimiento que apoya la resolución de problemas.  Conocimiento sobre habilidades gerenciales: Comprende el razonamiento decisional y el SSD (sistema de soporte a las decisiones) teniendo en cuenta el estilo gerencial del usuario, con el fin de identificar el subespacio datos-información que demanda el ejecutivo para la toma de sus decisiones en cada una de las aplicaciones que contiene el módulo específico.  Conocimiento sobre la interfaz con el usuario: En don­de se debe hacer la re­presentación del conocimiento del usuario y se debe considerar el estilo cognitivo y el gerencial. En este aspecto se persigue una interfaz en lenguaje natural para trabajar con bases de datos del sistema.

45 Se evalúan las tareas independientemente del modelo del usuario.
¿se pueden descomponer las tareas? ¿hay diferencia entre la perspectiva del usuario y la del experto? Este cuestionamiento es útil para determinar si es necesario realizar un análisis y elaborar un plan para obtener conclusiones completas. 3. Las tareas que se analizan están relacionadas con las labores que desempeñan los expertos para resolver sus problemas y realizar su trabajo: se deben descomponer en subtareas o subfunciones de acuerdo con el orden natural en que se desarrollan. Diseño

46  Analizar el orden de las tareas: diagrama de estados de las tareas, considerando su orden. Se debe hacer un análisis para determinar si el orden es el correcto, si sobran tareas o si se pueden reordenar para optimizar el desempeño.  Construcción del modelo: El modelo de una BC es útil en la medida en que es fácilmente interpretable: permite determinar cómo se va a resolver el problema en la BC. Este modelo se debe diseñar determinando las islas de conocimiento y las regiones. Diseñar la arquitectura de la BC: La arquitectura física de la BC Representen diferentes componentes y sus relaciones, con el fin de tener un "mapa" (e.g. mapa cognitivo o red semántica) de la BC y facilitar su construcción. El mapa brinda la idea principal o estructura de metaconocimientos sobre la BC y la manera en que va a resolver problemas. Debe mostrar capacidades y las interfaces con otros Sistemas de Información. Diseño

47 Diseño Para determinar las reglas de las tareas y subtareas: considerar soluciones, entradas, salidas, respuestas, alternativas o recomendaciones que se determinaron anteriormente, considerando:   Es necesario identificar preguntas para recoger los datos necesarios de las instrucciones IF que dispararán reglas conduciéndolo a la conclusión. Se deben listar todos los datos que se requerirá el sistema, denominados "hechos" (o síntomas), que el usuario entrará al sistema. Cada conclusión debe estar en la porción THEN de la regla. Un árbol de decisión es una buena ayuda si los elementos del conocimiento se pueden organizar rápidamente en un formato de árbol. Construir un árbol de búsqueda o decisión. Algunas BC son tan grandes que pueden necesitar de un árbol de decisión para el dominio completo, sin embargo, y para simplificar el trabajo, se pueden crear árboles de decisión para subconjuntos del dominio. Definir reglas para cada salida.

48 Diseño Una vez se hayan determinado las reglas concernientes al dominio del problema se definen aquellas que ejercerán control sobre las otras y sobre el proceso de inferencia. Identificación de los marcos. Seleccionar los objetos sobre los cuales se requiere modelar conocimientos. Determinación de METACONOCIMIENTOS. El control sobre los conocimientos, o "conocimiento sobre el conocimiento", se debe determinar con el fin de tener información y dominio en el proceso de inferencia.

49 Métodos de Solución de problemas Dominios de Soluciones de Problemas
Diseño PRODUCTOS DE LA FASE IV Métodos de Solución de problemas Dominios de Soluciones de Problemas Metaconocimiento Especificaciones Satisfechas

50 5- Construcción del Prototipo
CONSTRUCCION FASE ANTERIOR SIGUIENTE FASE 5- Construcción del Prototipo OBJETIVO: CONTENIDO PRODUCTOS DE LA FASE

51 CONSTRUCCION OBJETIVO Fase V: verificar la implementación, probar y verificar las ideas. CONTENIDO Si usa una la herramienta (Shell), identificar deficiencias y fortalezas sobre el modelo desarrollado para afinar los resultados hasta llegar a la calidad. Para probar los conceptos antes de invertir en un programa mayor. Se puede ensamblar rápidamente un prototipo pequeño que permite determinar si se está en el camino correcto. Permite realizar demostraciones ya que su evaluación también será importante en la determinación de la calidad del resultado.

52 CONSTRUCCION 1. Se deben graficar con el fin de evaluar la concatenación entre reglas, la relación y herencia entre marcos, es decir, para determinar si el modelo representado es el que realmente se desea. A. Elaboración del diagrama de la Red de reglas, para cada una de las capas de conocimientos, lo cual permitirá tener una amplia visión sobre la BC y hacer las correcciones necesarias para afinar el modelo. B. Elaboración del diagrama de los marcos. Se representan gráficamente todos los objetos, teniendo en cuenta la herencia y las relaciones entre ellos.  2 2. Prueba inferencial.  A partir de la BC se realiza el proceso de inferencia para evaluar los resultados basados en el proceso de razonamiento que se implementó

53 Prototipo Operacional Documentación de Pruebas de Software
CONSTRUCCION PRODUCTOS DE LA FASE V Prototipo Operacional Documentación de Pruebas de Software Resultados Efectivos y demostrados

54 6. Verificación, Validación, Contrastación Legitimación
VERIFICACION FASE ANTERIOR SIGUIENTE FASE 6. Verificación, Validación, Contrastación Legitimación OBJETIVOS INFERENCIA Y REFINAMIENTO EVALUACION OTROS REQUERIMIENTOS PRODUCTOS DE LA FASE

55 VERIFICACION OBJETIVOS Fase VI Verificar que la fuente de los conocimientos es la correcta. la metodología se emplea correctamente? Se comprueba que la solución y conclusiones son las esperadas. Refinar el Sistema Evaluar las Inferencias sobre casos REALES

56 VERIFICACION 6.1- La Inferencia. se basa en el diseño del software, que permite al computador inferir en el conocimiento representado en la BC. Se realiza un taller con los expertos con el fin de presentarles los resultados obtenidos con la BC, para que los analicen y den sus opiniones al respecto. El criterio principal que se debe emplear para las pruebas es el juicio de los expertos del dominio, ya que ellos pueden decir si los resultados son satisfactorios o no. Los usuarios potenciales también pueden servir como jueces, con criterios concernientes a la facilidad de uso, la interfaz y la claridad de las explicaciones. 6.2 Refinamiento Basados en las diferentes opiniones de los expertos, se hace un análisis de la BC, y en caso de que el ingeniero de conocimientos lo encuentre necesario, se realiza rediseño o reformulación

57 6.3.  Evaluación puede revelar casos no manejados por las reglas: se adicionan nuevas reglas o se modifican las antiguas; tales cambios pueden tener efectos negativos inesperados sobre algunas partes ·Verificación. comprobar si el sistema implementa bien sus especificaciones y hay consistencia lógica (el problema de comprobar que el método sea el correcto), para tal fin se evalúa el sistema obtenido, teniendo en cuenta niveles de desempeño efectivo. El prototipo y las versiones mejoradas del sistema se deben probar en cuanto a desempeño (performance) tanto en el laboratorio como en el campo. INICIAL: ambiente simulado, el sistema se expone a casos históricos o propuestos. También se analiza si el sistema se puede usar eficiente y es efectivo en costo. La evaluación debe considerar la calidad de los mensajes presentados, es decir, el diseño y programación de la capacidad de explicación de la BC para determinar hasta qué punto se cumplen los objetivos propuestos. ·         VERIFICACION

58 ·  Validación. Se debe probar el desempeño del sistema como aplicación, lo que se realiza comparándolo con el experto, para establecer que el sistema construido para resolver el problema sea el correcto y se desempeñe a un nivel aceptable de exactitud. La disminución del tiempo de respuesta y la calidad de las conclusiones pueden ser un buen criterio inicial para evaluar un SI.  Para este propósito se emplea la prueba de Turing modificada, con la cual se les presenta a los administradores, o usuarios potenciales, dos soluciones a un solo problema: la primera es el resultado del juicio experto y la otra el resultado del SIIG. Sin saber la fuente, se les solicita que comparen las soluciones. Con los resulta­dos de la comparación se determina que tan válidos son los resulta­dos del SIIG. Para emplear este enfoque se debe considerar los posibles desacuerdos entre los criterios de los evaluadores, ya que los problemas pueden ser tan complejos que se presenten desacuerdos sobre su interpretación y solución. VERIFICACION

59 · Solución de Problemas reales
VERIFICACION Otros requerimientos · Solución de Problemas reales · Aprendizaje dual, hombre-máquina: Herramienta de Doble Uso · La corrección de errores debe ser fácil · El sistema debe hacer preguntas para obtener información adicional. · El conocimiento debe ser fácilmente modificable · Hacer sentir al usuario con el control del sistema para motivar su uso. · Debe ser razonable el grado de esfuerzo tanto físico y mental de un usuario principiante. (Usability). Requerimientos de entrada (datos): simples de obtener. Explicación y justificación. la BC le explica al usuario cómo obtuvo cierta conclusión, es decir, cómo y porqué generó la respuesta

60 Prototipo verificado y con CALIDAD
VERIFICACION PRODUCTOS DE LA FASE VI Prototipo verificado y con CALIDAD Prototipo de Doble Uso: Herramienta Profesional y Tutoral para Capacitación Potenciada Documentación del Prototipo

61 7- Obtención del Sistema final OBJETIVOS PRODUCCION EVOLUTIVA
ENTREGA FASE ANTERIOR 7- Obtención del Sistema final OBJETIVOS PRODUCCION EVOLUTIVA PRODUCTOS DE LA FASE

62 ENTREGA OBJETIVOS Fase VII Un enfoque que se está empleando es el DESARROLLO EVOLUTIVO, en donde se perfecciona un prototipo hasta obtener el sistema final, que se puede construir gradualmente por medio de la adición de piezas, partes o componentes modulares. Este es un proceso cíclico, lo cual es una ventaja, que permite perfeccionar el resultado y obtener la mejor aproximación a los requerimientos de usuario y a las necesidades de conocimiento del SIIG. 

63 Desarrollo, verificar nivel nuevo
ENTREGA Costos acumulativos Determina Objetivos, Alternativas Contingencias Evalúa alternativas, identifica, resuelve Análisis de RIESGOS Prototipo Operacional Prototipo 1 Prototipo 2 Prototipo 3 Requisitos para un plan vital Simulación, modelos, mercadeo Conceptos de Operación Partición Requerimi- entos de Software Software diseñado Determina diseños Código Desarrollo del Plan Requisitos validación Unidad Pregunta s Diseño, Validación y verificación Integ .y preguntas Aceptación Preguntas Implementación Fases de un nuevo plan Desarrollo, verificar nivel nuevo producto

64 Se entrega el Sistema con Calidad Asegurada
Se realiza la integración de subsistemas, es decir, si se crearon BC diferentes o heterogéneas en cuanto a fuentes, se debe tener en cuenta las interfaces que permitan su óptimo funcionamiento y la comunicación entre el sistema y los usuarios. Se entrega el Sistema con Calidad Asegurada

65 PRODUCTOS DE LA FASE VII
ENTREGA PRODUCTOS DE LA FASE VII Sistema Integrado, ROBUSTO Bases Pobladas de Conocimientos Sistema de Aprendizaje Institucional Activos Intelectuales Memoria Institucional Tutoral Inteligente sobre Ingenieria de Conocimientos

66 CONCLUSIONES (1) La Planeación Estratégica sigue siendo la herramienta Gerencial preferida por ejecutivos de grandes multinacionales. El Modelo presentado incluyó una redefinición del ciclo del Ingeniería de Información de James Martin, la inclusión de la Prospectiva (Escenarios y Matriz DOFA dinámica), y la incorporación de capas de conocimientos al SIG (cognimatización) con nuestra herramienta UN-COGNI Vers 2.0. © El contenido del PESIC tiene 9 pasos metodológicos y se describió cada uno.

67 CONCLUSIONES (2) 6- Contribución al desarrollo y construcción de sistemas inteligentes, en especial para el Empresas del III Milenio y Comercio Electrónico 7- Promoción del Uso de la Moderna Planeación Estratégica apoyada por Conocimientos 8- Promoción de ACTIVOS INTELECTUALES comunes en empresas de la Sociedad del Conocimiento. 9- Contribución al Capital Intelectual 10- Fortalecimiento de la CAPACIDAD NACIONAL de GENERAR CONOCIMIENTO

68 HERRAMIENTA DE DOBLE USO
UN-COGNI © HERRAMIENTA DE DOBLE USO INTELIGENCIAR SISTEMAS DESARROLLAR HABILIDADES EN INGENIERIA DE CONOCIMIENTOS 3- Contribuir a Desmitificar la IAC-IC 4- Hacer ACCESIBLE el manejo de conocimientos a los expertos 5- Ofrecer una herramienta con estructura bidimensional: GESTION e INGENIERIA

69 Ante la turbulencia empresarial del III Milenio impulsada por los continuos y dramáticos cambios en la Tecnología, la única alternativa para que las empresas sobrevivan con éxito radica en: ADAPTACION AL CAMBIO APRENDIZAJE ORGANIZACIONAL Lo anterior es un imperativo

70

71 BIBLIOGRAFÍA FERNÁNDEZ ALCIRA “Un Estudio a la Planeación por Escenarios. Aplicación en una Empresa de Telecomunicaciones” Tesis de Maestría en Administración de Empresas UNIVERSIDAD NACIONAL DE COLOMBIA Bogotá 2001 Director Alfonso Pérez Gama HAUMER Peter, Klaus Pohl y Klaus Weidenhaupt. Requirements Elicitation and Validation with Real World Scenes. En: IEEE Transactions on Software Engineering. Vol. 24, No. 12, Diciembre 1998. JOYANES LUIS: Retos, Desafíos y Oportunidades de la Ingeniería de Software ante el Siglo XXI; Presidente Del Simposio SISOFT2001; Universidad Pontificia de Salamanca; MAKRIDAKIS, S. G. Forecasting, Planning and strategy for the 21st Century. New York; Free Press, 1990 MINTZBERG Henry The rise and fall of Strategy Planning Free Press 1994 PEREZ GAMA ALFONSO, GIOVANNI ROZO: ”Conocimiento para la Sociedad y la Industria del Conocimiento” ACCIO Bogota Junio 2006 ISBN PEREZ GAMA ALFONSO, Ing. VÍCTOR HUGO MEDINA García Diseño de Sistemas y Prototipos con el apoyo del Computador Universidad Nacional; Universidad Distrital 1995 Segunda Edición Bogotá PEREZ GAMA, Alfonso, Ing. Alcira Fernández F, Ing. Hada Jessica Pérez Gutiérrez Prospectiva y Escenarios en la Planeación Estratégica de Sistemas de Información para Empresas en La Web; ; U. Nacional SISOFT 2001. PEREZ GAMA, Alfonso, Ing. VÍCTOR HUGO MEDINA García, Ing. HADA JESSICA PÉREZ GUTIÉRREZ: “UN ASISTENTE PROFESIONAL EN METODOLOGÍAS PARA LA MODERNA INGENIERÍA DE SOFTWARE”; SEI2000 Madrid España. Publicado por la Revista de la EAN, No Noviembre de Bogotá ISSN PEREZ GAMA, Alfonso: "UN-SEEGSI: Un Sistema de Información Gerencial con aprendizaje dual hombre y máquina" Revista Ingeniería e Investigación # 30 ISSN UNIVERSIDAD NACIONAL de COLOMBIA Facultad de Ingeniería 1994. PEREZ GAMA, Alfonso: “UN SISTEMA INTELIGENTE DE INFORMACIÓN GERENCIAL PARA APRENDIZAJE DUAL HOMBRE Y MAQUINA EN LA SOCIEDAD DEL CONOCIMIENTO”; I CONGRESO INTERNACIONAL DE LA SOCIEDAD DE LA INFORMACIÓN.; Universidad de Las Palmas de Gran Canaria CANARIAS (España) 27, 28 de febrero y 1 de marzo de 2002. PEREZ GAMA, Alfonso: La predicción Tecnológica en Revista Ingeniería e Investigación. Universidad Nacional de Colombia, No

72 BIBLIOGRAFIA (CONT.) DAVIS, ALAN, Software Requirements: Objects, Functions, & States,  2nd Edition, Prentice Hall, Upper Saddle River, NJ, 1993 DE JOUVENEL, Hugues. La démarche prospective. En: Futuribles – Analyse et prospective. Noviembre Número 247. DZIDA, W. y R. Freitag. Making use of Scenarios for Validating Analysis and Design. En: IEEE Transactions on Software Engineering. Diciembre 1998. PRESSMAN ROGER; Ingeniería de Software: Un enfoque práctico Quinta Edición Editorial. Mc Graw Hill Adaptación Darrel Ince; Revisión Técnica Luis Joyanes Aguilar PRICE, Robert. Technology and Strategic Advantage. En: IEEE Engineering Management Review. Summer 1998. RAINER, Fuerer  y otros. Aligning Strategies, Processes and IT: AS case study. En: IEEE Engineering Management, Vol. 28. Número 3. Tercer trimestre 2000. SAGE ANDREW Handbook  of Systems Engineering and Management Ed. J.  Wiley  1999 New York. SCHWARTZ, Peter. Ha llegado el mañana. En: Revista Gestión. Vol. 2. Número 6. Diciembre Enero Bogotá STIEMERLING, O. y A. Cremers. The Use of cooperation scenarios in the design and evaluation of a CSCW System. En: IEEE Transactions on Software Engineering. December 1998 SUTCLIFFE Alistair, Neil Maiden y otros. Supporting Scenario-Based Requirements Engineering. En: IEEE Transactions on Software Engineering. Vol. 24, No. 12, Diciembre 1998. VALDERRAMA HUGO FERNANDO: Sabiduría Empresarial- Publicaciones NCR de Colombia 2001 VAN DER HEIJDEN, Kees. El arte de prevenir el futuro. Editorial Panorama VAUGHAN MERLYB & John Parkinson Development Of Effectiveness: Strategies for Information Systems Organizational Transition: ERNST AND YOUNG Information Management Series. John Wiley; 1994 New York WOODS, Eric y Madan Sheina. Knowledge Management. Applications, Markets and Technologies. Editorial Ovum Limitada

73