modelo de proceso de gestión para proyectos de ingeniería

Modelo de Proceso de Gestión para Proyectos de Ingeniería del Conocimiento

Hernán Amatriain, Hernán Merlino, Sebastián Martins y Santiago Bianco

Laboratorio de Investigación y Desarrollo en Ingeniería de Software Grupo de Investigación en Sistemas de Información.

Departamento de Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús http://www.unla.edu.ar/sistemas/gisi/

[email protected], [email protected], [email protected], [email protected]

Resumen. Las reformulaciones de paradigmas metodológicos en Ingeniería de Software de los últimos 25 años relacionadas con los conceptos de: proceso, actividades, técnicas y metodologías; plantean la necesidad de una revisión sobre el uso de ellos en algunos de sus subcampos. En este contexto, se propone un Modelo de Proceso de Gestión para Proyectos de Ingeniería del Conocimiento que pone foco en la gestión de este tipo de proyectos.

Palabras clave. Ingeniería del Conocimiento, Sistemas Basados en Conocimientos, Sistemas Expertos, Modelo de Procesos, Control y Gestión de Proyectos, Metodología IDEAL, Metodología GROVER, Método BGM, Estándar IEEE 1074-1997, ISO/IEC 12.207, PMBOK.

1. Introducción

La Ingeniería de Conocimiento (INCO) tiene por misión adquirir, formalizar, representar y utilizar grandes cantidades de conocimiento de la más alta calidad y específicos de una tarea [; García-Martínez y Britos; 2004; García-Martínez et al, 2003; Gómez et al, 2001; Bermejo et al, 2002; Diez E, 2013] para el desarrollo de los sistemas Basados en Conocimiento (SSBBCC) o Sistemas Expertos (SSEE). Para este propósito, se han desarrollado varias metodologías, técnicas y herramientas para desarrollar SSBBCC [Grover, 1983; Brulé y Blount, 1989; Schreiber, 2000; Staab et al., 2001]. La INCO ha desarrollado una variedad de soluciones a problemas que requieren un abordaje distinto que el ofrecido por la Ingeniería de Software [Britos, 2001; Britos et al, 2004]. En los últimos años ha cobrado auge los Sistemas Basados en Gestión de Reglas de Negocios [Ibarra y Bazán, 2013; Kliegr et al, 2014; Parra et al, 2014], que son un tipo específico de SBC, con varias aplicaciones prácticas, por ejemplo en medicina [Martínez del Busto et al, 2012; Pacheco Cárdenas et al, 2015]; existiendo, incluso, una comunidad dedicada a ello [Club-BPM] que ha celebrado sus últimos congresos en Perú (2014) y España (2015).

XXIII Congreso Argentino de Ciencias de la Computación La Plata - 9 al 13 de octubre de 2017

762

Dentro de las metodologías establecidas para el desarrollo de SSBBCC y SSEE, la que se destaca desde su aparición en 1987 es la Metodología IDEAL, que se ha convertido en un estándar de facto [Britos P., 2001; Rossi, 2001; Rizzi, 2001; Bermejo, 2002; Ierache, 2001; Cao, 2003; Diez E., 2003; Gómez, 2003; Hossian, 2003]. La metodología IDEAL [Carrillo Verdum, 1987; Gómez et al., 1997; García-Martínez y Britos; 2004] consta de cinco fases: (i) identificación de la tarea, (ii) desarrollo de los prototipos, (iii) ejecución de la construcción del sistema integrado. (iv) actuación para conseguir el mantenimiento perfectivo, y (v) lograr una adecuada transferencia tecnológica. Cada una de éstas fases se “subdivide” en distintas etapas. La Metodología IDEAL se centra en: adquisición, conceptualización y formalización de conocimientos. Si bien esta metodología tiene etapas para el estudio de viabilidad, integración con otros sistemas y etapas de validación, carece de las etapas de gestión a nivel proyecto, y no prevé actividades especificas para la gestión de proyectos. Las actividades propias de gestión, en ésta metodología están embebidas en las mismas actividades de desarrollo, dejando su responsabilidad al mismo Ingeniero de Conocimiento que realiza el desarrollo. El Modelo de Ciclo de Vida que se utiliza conjuntamente con esta metodología es el modelo en espiral tronco-cónico [Alonso et al., 1996]. Otras metodologías tienen el mismo inconveniente: carecen de actividades propias de gestión y deja el control de las actividades de desarrollo al mismo Ingeniero de Conocimiento. La metodología de Grover [Grover; 1983] se concentra en el la definición del dominio (conocimiento, referencias, situaciones y procedimientos) en la formulación del conocimiento fundamental (reglas elementales, creencias y expectativas) y en la consolidación del conocimiento de base (revisión y ciclos de corrección). Otra metodología para el desarrollo de Sistemas Expertos o Sistemas Basados en conocimientos es el Método BGM [García-Martínez y Britos; 2004]. El mismo tiene las etapas de Adquisición de Conocimientos, Enunciación de Conceptos, Parametrización de Conceptos, Planteo de Causalidades, y Verificación. Por otro lado, los modelos de proceso de software, o metodologías, que tienen en cuentas todas las actividades de control y gestión, como ser el Estándar IEEE 1074 [IEEE; 1998], la ISO/IEC 12.207 [ISO; 2008] o el PMBOK [PMBOK; 2013], carecen de aquellas actividades de gestión específicas para los Proyectos INCO. En este trabajo presenta: el problema abordado (sección 2), la solución propuesta (sección 3), descripción de etapas y formalismos de salida (sección 4) y se plantean algunas conclusiones y futuras investigaciones (sección 5).

2. Descripción del Problema

Desde la Crisis del Software [Sommerville, 2005], se ha aprendido que la planificación de proyectos y su gestión y control son esenciales para el éxito de cualquier proyecto software. Es decir que la construcción de software requiere una visión ingenieril [Sommerville, 2005; Pressman, 2010], siendo muy factible un fracaso cuando así no se hace.


763

Los Proyectos INCO tienen un énfasis en las actividades de Adquisición de Conocimientos y Conceptualización, considerablemente mayor al resto de las actividades de desarrollo, ya que la construcción de reglas que van a constituir la Base de Conocimiento (pieza fundamental en la arquitectura de un SBC o SE, y ausente en cualquier otro tipo de sistema basado en software) es clave en el éxito del sistema. Por ello, las actividades de Adquisición de Conocimientos, Conceptualización de Conocimientos, y la verificación de Coherencia (de las reglas en la Base de Conocimientos), deben ser planificadas y monitoreadas de manera rigurosa. Las actividades que deberían desarrollarse para llevar a cabo esta gestión son específicas de estos sistemas (así como lo son las mismas actividades de desarrollo a gestionar) y siguen reglas propias. Los procesos de y metodologías para gestión y control en Proyectos de Software existentes (IEEE 1074, ISO/IEC 12.207, PMBOK), carecen de estas actividades. Por otro lado, las metodologías para el desarrollo de SBC y SE, tienen en cuenta las actividades de desarrollo específicas, pero no la gestión y control de la misma, dejándolas, en el mejor de los casos, embebidas (solo algunas de ellas) en las mismas actividades de desarrollo sin una figura de gestor para la planificación y monitoreo, recayendo la responsabilidad en el mismo Ingeniero de Conocimiento que realiza el desarrollo. La importancia de la Gestión y Control de los Proyectos de Software es indiscutible, y la inexistencia de actividades de gestión y control específicos en los procesos y metodologías actuales es un área que debe ser cubierta.

3. Solución Propuesta

Para afrontar el problema identificado, se propone un modelo de proceso para control y gestión de proyectos de Ingeniería del Conocimiento. Se establece para el proceso las fases, etapas, actividades, insumos y el producto obtenido que surge del desarrollo de cada actividad. También se desarrollan heurísticas para la realización de las mismas. El proceso propuesto está compuesto por tres fases que se muestran en la Figura 1 y detallan en la Tabla 1. En la Figura 1 se muestran las fases, etapas (en recuadros redondeados) y productos de cada etapa (rectángulos con esquina inferior derecha cortada), del proceso de control y gestión. La Tabla 1 nuestra, además, l detalle de actividades a desarrollar por cada etapa del proceso de control y gestión.


764

Figura 1. Proceso de Control y Gestión de Proyecto

Tabla 2. Proceso de Control y Gestión de Proyecto

PROCESO DE CONTROL Y GESTION PARA PROYECTOS INCO FASEI: INICIACION DEL PROYECTO INCO

ETAPAS ACTIVIDADES INSUMOS PRODUCTOS

EXPLORACION DEL DOMINIO

1) REALIZAR ENTREVISTA INICIAL

2) PLANIFICAR ENTREVISTAS CON USUARIOS Y EXPERTOS

3) PLANIFICAR OBSERVACION DE TAREAS

4) ANALIZAR ENTREVISTAS

5) PLANIFICAR NUEVO CICLO

DOCUMENTACION ORGANIZACION

INFORME DE DOMINIO

INFORME DE EXERTOS

TESTEO DE VIABILIDAD

6) ESTIMACION TEMPRANA

7) TESTEAR PLAUSIBILIDAD

8) TESTEAR ADECUACION

9) TESTEAR JUSTIFICACION

10) TESTEAR ÉXITO

11) GENERAR INFORME GENERAL

INFORME DE DOMINIO

INFORME DE EXPERTOS INFORME DE VIABILIDAD

ELABORACION DE LA PROPUESTA DE PROYECTO

12) DELIMITAR ALCANCE DEL PROYECTO

13) ESPECIFICAR CARACTERISITICAS DEL SE

14) GENERAR CALENDARIO GENERAL

15) ELABORAR PROPUESTA

INFORME DE DOMINIO

INFORMEDE EXPERTOS

INFORME DE VIABILIDAD

PROPUESTA PROYECTO

PRODUCTO FINALDE LA FASE: PROPUESTA DEL PROYECTO INCO


765

FASE II: PLANIFICACION DEL PROYECTO INCO ETAPAS ACTIVIDADES INSUMOS PRODUCTOS

CALENDARIZACION DEL PROYECTO INCO

16) SLECCIONAR DE METRICAS (HAUGE)

17) SELECCIONAR EL MCV (PROPONER ESPIRAL)

18) ESTIMAR EL ESFUERZO (OBEJERO)

19) DESARROLLAR MAPA DE ACTIVIDADES

20) DEFINIR HITOS

21) ESTABLECER CALENDARIO

PROPUESTA DEL PROYECTO NCO

MCV

INFORME DE ESTIMACION

MAPA DE ACTIVIDADES

CALENDARIO GENERAL

PLANEAMIENTO DE LA ADQUISICION Y COHERENCIA

22) FACTORIZAR EDUCCION

23) CALENDARIZAR CADA EDUCCION CON EXPERTO

24) SUGERIR TECNICAS DE EDUCCION

25) ESTABLECER PROPOSITO Y CRITERIO DE ÉXITO POR SESION

26) SELECCIONAR TECNICAS DE CONTROL DE COHERENCIA

27) ESTABLECER HITOS DE CONTROL

28) ESTABECER ROPOSITO Y CRITERIO DE ÉXITO DE CADA CONTROL DE COHERENCIA

CALENDARIO GENERAL

PLAN DE ADQUISICION Y COHERENCIA

CALENDARIO ACTUALIZADO

PLANEAMIENTO DE LA VERIFICACION Y VALIDACION

29) PLANIFICAR REVISIONES ESTATICAS

30) DEFINIR CASOS DE PRUEBA

31) ESTABLECER PROPOSITO Y CRITERIO DE ÉXITO

32) ESTABLECER FORMATOS INFORMES



PLAN DE REVISIONES

PLAN DE VERIFICACION Y VALIDACION


PLANEAMIENTO DE CONTINGENCIAS

33) IDENTIFICAR RIESGOS

34) CLASIFICAR RIESGOS

35) ESTABLECER CRITICIDAD

36) ESTABLECER PROBABILIDAD DE OCURRENCIA

37) RANQUEAR RIESGOS

38) ESTABLECER ACCIONES PREVENTIVAS

39) ESTABLECER MEDICIONES DETECTIVAS

40) ESTABLECER PUNTOS DE CONTROL

41) ESTABLECER ACCIONES CORRECTIVAS


PLAN DE V & V


PLAN DE CONTINGENCIAS


PLANEAMIENTO DE LA CONFIGURACION

42) ESTABLECER LINEA BASE

43) INFORMACION DE CADA ELEMENTO

44) ESTABLECER FORMATO DE PEDIDOS,ANALISIS Y APROBACION

45) PLANEAR REVISIONES


PLAN DE V & V


PLAN DE CONTINGENCIAS

PLAN DE CONFIGURACION

PLAN GNERAL DEL PROYECTO

PRODUCTO FINALDE LA FASE: PLAN GENERAL DEL PROYECTO INCO FASE III: MONITOREO Y CONTROL DEL PROYECTO INCO

ETAPAS ACTIVIDADES INSUMOS PRODUCTOS

CONTROLES DE AVANCE Y GESTION DE LA CONFIGURACION

46) CONTROLAR ELEMENTO DE CONFIGURACION EN CADA ITO (MEDIR Y COMPARAR CON CRITERIO DE EXITO)

47) ACTUALIZAR INFORMACION DE TRAZABILIDAD

48) EJECUTAR PROTOCOLO DE CAMBIO

49) EJECUTAR REVISIONES

PLAN GENERAL DEL PROYECTO

LINEA BASE ACTUALIZADA

PLAN DE CAMBIOS APROBADOS

INFORME DE REVISIONES

CONTROLES DE ADQUISICION Y COHERENCIA

50) MEDIR EN CADA HITO EL ESTADO DE ADQUSICION Y COHERENCIA

51) COMPARAR EN CADA HITO EL RESULADO DE LA MEDICION CON CRITERIO DE ÉXITO

52) ANALIZAR RESULTADO Y ESTABLECERSIGUIENTE CICLO

53) ESTABLECER REGLAS INCONSISTENTES

54) DETERMINAR SUGERENCI


INFORME DE APROBACION DE ADQUISICION

INFORME DE APROBACION DE CONCEPTUALIZACION

INFORME DE CONSISTENCIAS Y SUGERENCIAS DE CAMBIO

VERIFICACION Y VALIDACION

55) EJECUTAR PRUEBAS DE VALIDACION

56) COMPARAR CON CRITERIOS DE ÉXITOPREVIAMENTE DEFINIDOS

57) DETERMINAR SUGERENCIAS

58) EJECUTAR VALIDACION

59) REALIZAR ANALISIS Y SUGERENCIAS


INFORME DE VERIFICACION Y VALIDACION


766

MONITOREO DE RIESGOS

60) REALIZAR MEDICIONES EN HITOS

61) ESTABLECER OCURRENCIA DE INCIDENTE

62) DETRMINAR GRADO DE CRITICIDAD

63) SUGERIR ACCIONES A TOMAR


INFORME DE CONTROLES

INFORME DE INCIDENTES

ACCIONES A TOMAR

PRODUCTO FINALDE LA FASE: INFORMEGENERAL DE CONTROLES, INCIDENTES Y MODIFICACIONES

4. Descripción de Etapas y Formatos de Salida

El modelo de proceso propuesto como solución para la gestión de Proyectos INCO se encuentra dividido en tres fases: Fase de Iniciación del Proyecto, Fase de Planificación y Fase de Control, como queda detallado en la Figura 1 y la Tabla 1. La Fase de Iniciación, comprende todas aquellas actividades que deben desarrollarse al principio de cualquier Proyecto, incluyendo el Test de Viabilidad [García-Martínez y Britos; 2004], finalizando con la Propuesta de Proyecto. Esta fase se compone de tres etapas: Exploración del Dominio (se realiza la primera aproximación al SBC a construir introduciendo el léxico del dominio y sus características), Test de Viabilidad (fundamental para seguir adelante con el Proyecto), y Elaboración de la Propuesta (donde se realiza una primera calendarización de las actividades a desarrollar). Durante la Fase de Planificación se realizan todos los planes que deberán ejecutarse durante el proyecto, y que están relacionados con la gestión del mismo. Las etapas de esta fase son cinco: Calendarización del Proyecto (debe realizarse una estimación del proyecto utilizando [Obejero; 2006], seleccionar un MCV para lo que será necesario escoger las métricas adecuadas [Hauge et al; 2006], y elaboración del calendario), Planeamiento de la Adquisición, Conceptualización y Coherencia (estas actividades son específicas del desarrollo de SE y no figuran en ningún modelo de proceso de gestión de Ingeniería de Software y en las metodologías de construcción de SBC están, a lo sumo, embebidas en las mismas actividades de desarrollo y a cargo del mismo Ingeniero de Conocimiento; las actividades de gestión incluyen la factorización de los conocimientos a través de una categorización del glosario del dominio, programar las sesiones estableciendo los objetivos de cada una y criterios de éxito; otra actividad específica de los SBC y SE es el control de consistencias de las reglas, ya que la Base de Conocimiento es una pieza fundamental de la arquitectura de estos sistemas, por lo que es necesario mantener la consistencias de las nuevas reglas agregadas), Planeamiento de Verificación y Validación (incluye las actividades de seleccionar cuidadosamente con los expertos los casos de prueba y criterios de éxito; también deben definirse los formatos de los informes), Planeamiento de Contingencias (este plan es común a todos los proyectos de Ingeniería de Software, aquí se agregan heurísticas a tener en cuenta para la categorización de riesgos específicos de los sistemas INCO), y Planeamiento de la Configuración (otro plan común en los proyectos de Ingeniería de Software, pero no expresado en las metodologías de construcción de SE y SBC, agregando heurísticas de revisiones y versionados). Esta fase tiene como producto final el Plan General del Proyecto INCO. La Fase final es la de Monitoreo y Control, donde se realizan los controles de las actividades de desarrollo según lo establecido en la fase de planificación (hitos de control), realizando las mediciones correspondientes según las métricas definidas (también en la fase previa), llevando a cabo las acciones correctivas necesarias y


767

preestablecidas. Los formatos de los informes están definidos en el Plan General del Proyecto, y los productos de cada una de las etapas que conforman esta fase serán los informes correspondientes. Al final de esta fase de realiza un Informe General de Controles, Incidentes y Modificaciones conformado por un resumen de cada uno de los informes producidos durante cada etapa. Las actividades de cada etapa se encuentran detalladas en la Tabla 1, y los productos de cada una de ellas son los que se detallan a continuación. Informe de Dominio: (a) Carátula (Título, fecha realización, última revisión, responsable y revisor), (b) Índice, (c) Objetivo del Informe, (d) Objetivos del SBC/SE, (e) Glosario del dominio (léxico del dominio, con una categorización prematura identificando conceptos, atributos, valores y reglas), (f) Características del dominio (habilidades necesarias para manejarlo, tipo de tareas desarrolladas, sensibilidad de la información manejada, necesidad de procesamiento de información por expertos, profundidad y variabilidad de los conocimientos), (g) Fuentes de conocimientos (toda fuente que provea información del dominio, explicitando disponibilidad y accesibilidad a la misma), (h) Listado de expertos (nombres, contacto y disponibilidad), (i) Características de los expertos (sub área específica de expertica y facilidades de articular su experiencia). Informe de Viabilidad: (a) Introducción (Carátula: título, fecha realización, última revisión, responsable y revisor; Índice; Objetivo del Informe), (b) Estimación temprana (basada en el informe de dominio y aplicación prematura de [Hauge et al; 2006]), (g) Resultado de la viabilidad (informe corto), (h) Informe detallado de Plausibilidad (según Test de Viabilidad en [García-Martínez y Britos; 2004]), (i) Informe detallado de Adecuación (según Test de Viabilidad), (j) Informe detallado de Justificación (según Test de Viabilidad), (k) Informe detallado de Éxito (según Test de Viabilidad), (l) Informe General. Propuesta de Proyecto: (a) Introducción, (b) Objetivos del SE, (c) Características del SE (necesidades de disponibilidad, características del dominio, tipo de problemas que resuelve), (d) Informe de estimación temprana, (e) Informe de viabilidad corto, (f) Cronograma de actividades principales, (g) Anexos (Informe de Dominio; Informe de Viabilidad). Calendario General: (a) Introducción, (b) Informe de estimación (según [Obejero; 2006]), (c) Mapa de Actividades a desarrollar, (d) Dependencia de tareas (técnicas sugeridas: Grafo PER y Matriz de Dependencias), (e) Calendario del Proyecto (técnica sugerida: Diagrama de Gantt). Plan de Adquisición y Coherencia: (a) Introducción, (b) Glosario Clasificado y factorizado (agrupar por conceptos), (c) Identificación de fuentes por agrupación de conceptos, (d) Asignación de expertos por agrupación, (e) Calendario de sesiones por experto, (f) Propósito de cada sesión, (g) Técnicas de control sugeridas para coherencia (de acuerdo a cada inconsistencia posible de la Base de Conocimiento), (h) Listado de acciones a tomar según cada tipo de inconsistencia, (i) Hitos de control y criterios de éxito, (j) Formato de los informes de control. Plan de Verificación y Validación: (a) Introducción, (b) Plan de revisiones estáticas (gerenciales, técnicas e inspecciones), (c) Casos de pruebas, (d) Criterios de éxito, (e) Formato de los informes de control, (f) Criterios de validación, (g) Formato de los informes de validación.


768

Plan de Contingencia: (a) Introducción, (b) Listado de riesgos clasificados (heurística sugerida: enumerar un riesgo por cada tipo de inconsistencia no detectada y asignar grado de seriedad dependiendo de la afectación a la BC; por ejemplo, las reglas conflictivas crean incoherencia y son críticas, las reglas incluidas en otras y las reglas redundantes aumentan innecesariamente el tamaño de la BC afectando la eficiencia por lo que son de criticidad moderada, y las reglas cíclicas pueden hacer entrar al SE en un bucle sin llegar a una solución si no se siguen otros criterios para evitarlo por lo que tienen criticidad entre alta y moderada), (c) Hitos de control y criterios de éxito, (d) Listado de acciones a tomar por cada incidente, (e) Formato de los informes de control. Plan de Configuración: (a) Introducción, (b) Línea base (heurística sugerida: tomar como elementos de configuración cada documento de gestión, cada informe de educción y los informes de coherencia; tomar como elemento de configuración especial la BC), (c) Estándares de versionados y anotaciones (heurística sugerida: identificar separadamente los elementos de configuración consistentes en los informes de educción separados por la clasificación y agrupación de conceptos identificados del dominio), (d) Formato de pedido de cambios, (f) Formato de análisis de cambios, (g) Formato de aprobación de cambios, (h) Hitos de control y revisiones, (i) Formatos de revisiones. Las etapas de la fase final (monitoreo y control) tienen como salida los informes de los controles realizados en los hitos establecidos en la fase anterior, al igual que los formatos de los mismos. Esta etapa tiene además un producto final que consiste en un resumen de todos los informes de control, que es el Informe General de Controles, Incidentes y Cambios, cuyo fin es documentar el proceso completo de desarrollo para posteriores análisis y mejoras eventuales del proceso aplicado.

5. Conclusiones y futuras líneas de investigación

La Metodología IDEAL, GROVER y BGM se centran en la construcción (análisis y desarrollo) de los SSBBCC y SSEE, pero carecen de las actividades necesarias para la gestión y control del proyecto, teniendo a lo sumo alguna planificación embebida en las mismas actividades de desarrollo y a cargo del mismo desarrollador. La solución propuesta, que pertenece a una investigación en desarrollo, se adecúa más a los proyectos INCO, sobre todo para aquellos de mayor tamaño donde la falta de gestión permite predecir un seguro fracaso. La metodología IDEAL, además de carecer de las actividades de planificación, control y gestión, establece un modelo de ciclo de vida prototipado, al cual queda atada, de manera innecesaria. La solución propuesta pone foco en la definición de procesos de control y gestión de Proyectos de Ingeniería de Conocimiento, partiendo de las Metodologías IDEAL y del Estándar IEEE 1074-1997, definiendo claramente cuáles son las actividades a realizar en cada fase, así como sus entradas (insumos) y salidas (productos). Como futuras líneas de trabajo se prevé: [a] definir las distintas técnicas, y los procedimientos asociados, necesarias para el desarrollo de las actividades propuestas en el modelo de proceso, [b] mejorar las heurísticas de clasificación e identificación de riesgos y configuración, [c] desarrollar un modelo de ciclo de vida que tenga en


769

cuenta la cuantificación de los conocimientos y la verificación de la base de conocimientos, [c] establecer una etapa de planificación y una de control de personal en las fases de planificación y control del proceso de gestión, [e] definir un modelo de desarrollo libre de actividades de gestión y que articule el modelo de proceso para Proyectos INCO, y [f] completar la validación de la propuesta a través de la aplicación práctica del modelo propuesto en el presente trabajo en más casos testigos.

6. Financiamiento

Las investigaciones que se reportan en este artículo han sido financiadas parcialmente por el Programa PROMINF-UNLa-2015-2017 del Ministerio de Educación Argentina y por el Proyecto 33B170 de la Secretaria de Ciencia y Tecnología de la Universidad Nacional de Lanús.

7. Bibliografía

Alonso, F., Juristo, N., Maté, J., Pazos, J. 1996. Software engineering and knowledge engineering: Towards a common life cycle. Journal of Systems and Software, 33(1): 65-79.

Bermejo F., Britos P., Rossi B, García-Martínez R. 2002 Sistemas de Asistencia para la Configuración de Ventiladores OAF en Neonatología. Revista del Instituto Tecnológico de Buenos Aires. Volumen 28, Pag. 24-68

Borrajo, D. 1993. Inteligencia artificial: Métodos y técnicas. Ed. Centro de Estudios Ramón Areces.

Britos, P., 2001. Sistema de ayuda sobre Legislación Argentina en Riesgos de Trabajo. Tesis Maestría. Universidad Politécnica de Madrid e Instituto Tecnológico de Buenos Aires.

Britos, P., Sierra, A., García-Martínez, R., 2004. Sistema de Asistencia Legal en Riesgos de Trabajo. Journal Informática y Sociedad. Vol. 1 N° 1 (2004), pág. 34-49. ISSN: 1668-3137.

Brulé, J., Blount, A. 1989. Knowledge acquisition. McGraw-Hill, Inc. Carrillo Verdun, J. 1987. Metodología para el Desarrollo de Sistemas Expertos. Tesis Doctoral.

Universidad Politécnica de Madrid. Club-BPM. Business Process Management. Centro Oficial del BPM. España y Latinoamérica.

(http://www.club-bpm.com/, último acceso 30-05-2016). Diez, E.. 2013. Aseguramiento de la Calidad en la Construcción de Sistemas Basados en el

Conocimiento Un Enfoque Práctico. Revista Latinoamericana de Ingeniería de Software, 1(5) 167-206, ISSN 2314-2642.

Dramis, L., Britos, P., Rossi, B.., García-Martínez, R. 2000 Verificación de Base de Conocimiento basada en Algebra de Grafos. Proceedings del VI Congreso Internacional de Ingeniería Informática. Pag. 729-738. Editado

García-Martínez, R., Britos, P. 2004 Ingeniería de Sistemas Expertos. Editorial Nueva Librería. ISBN 987-1104-15-4.

García-Martínez, R., Servente, M. y Pasquini, D. 2003. Sistemas Inteligentes. Editorial Nueva Librería. ISBN 987-1104-05-7.

Grover, M. 1983. A Pragmatic Knowledge Acquisition Methodology. IJCAI Vol. 83: 436-438. Gómez, A., Juristo, N., Montes, C., Pazos, J. 1997. Ingeniería del conocimiento. Editorial

Centro de Estudios Ramón Areces.


770

Gómez, S. 2003. Sistema Informático Jurídico para la Individualización y Acuerdos sobre la Pena. Tesis de Magister en Ingeniería del Software. Centro de Ingeniería del Software e Ingeniería del Conocimiento. ITBA.

Hauge, O., Britos, P., García-Martínez, R. 2006. Conceptualization Maturity Metrics for Expert Systems. IFIPInternational Federation for Information Processing, Volume 217, ed. M. Bramer, (BostonSpringer), Pag. 435-444.

Hossian, A. 2003. Sistema de Asistencia para la Selección de Estrategias y Actividades Instruccionales. Tesis de Magister en Ingeniería del Software. ITBA.

Ibarra, G., Bazán, P. 2013. Análisis y comparación de plataformas BRMS a través de una prueba de concepto. XV Workshop de Investigadores en Ciencias de la Computación.

IEEE, 1998. IEEE Std 1074-1997. IEEE Standard 1074 for Developing Software Life Cycle Processes.

Ierache, J. 2002. Sistema Experto para la Asistencia a la Toma de Decisiones en Centro de Información y Control Aéreo. Tesis de Magister en Ingeniería del Software. Centro de Ingeniería del Software e Ingeniería del Conocimiento. ITBA.

ISO; 2008. ISO/IEC 12.207, Information Technology / Software Life Cycle Processes. International Organization for Standardization

Kliegr, T., Kuchar, J., Sottara, D., Y Vojr, S. 2014. Learning business rules with association rule classiers. In RuleML14 The 8th International Web Rule Symposium. Springer.

Martínez del Busto, M., Núñez Pérez, L., Caballero Martínez, A., Moreno Montes de Oca, I., Boggiano Castillo, M., González González, L., Hernández Hernández, P., 2012. Aplicación médica para trasplante renal usando reglas de negocio. Revista Habanera de Ciencias Médicas 2012:11(1)176-184

Nguyen, T., Perkins, W., Laffey, T., Pecora, D. 1987. Knowledge-base verification. AI Magazine, 8(2) 69-75.

Ovejero, J. 2006 Estimación de Proyectos para Sistemas Basados en Conocimientos, Tesis Magíster Ingeniería de Software, ITBA-Universidad Politécnica de Madrid.

Pacheco Cárdenas, Y., Estévez Abrahantes, S., Martínez del Busto, M., 2015. Integración de un Sistema de Gestión de Reglas de negocio al flujo de trabajo “control de historias clínicas para el trasplante renal”. Revista Cubana de Informática Médica, vol. 7, no. 1. ISBN 1684-1859.

Parra, J., Bazán, P., Garro, J., 2014. Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. XV Workshop de Investigadores en Ciencias de la Computación.

PMBOK, 2013. A Guide to the Project Management Body of Knowledge. Project Management Institute.

Pressman, R., 2010. Ingeniería del Software. Un Enfoque Práctico. Séptima edición. Capítulo 1. McGraw-Hill, Inc. ISBN: 978-607-15-0314-5.

Rizzi, M. 2001. Sistema Experto Asistente de Requerimientos. Tesis de Magister en Ingeniería del Software. Centro de Ingeniería del Software e Ingeniería del Conocimiento. ITBA.

Rossi, B. 2001. Sistema Experto de Ayuda para la Selección del Modelo de Ciclo de Vida. Tesis de Master en Ingeniería del Conocimiento. Universidad Politécnica de Madrid.

Schreiber, G. 2000. Knowledge engineering and management: the CommonKADS methodology. MIT press.

Sommerville, I., 2005. Ingeniería del Software. Séptima edición. Capítulo 1. Pearson Addison. ISBN: 84-7829-074-5.

Staab, S., Studer, R., Schnurr, H. P., Sure, Y. 2001. Knowledge processes and ontologies. IEEE Intelligent systems, (1): 26-34.


771

modelo de proceso de gestión para proyectos de ingeniería

Documents