UNIVERSIDAD MAYOR DE SAN ANDRES

Facultad de Ciencias Puras y Naturales

Postgrado en Informática

Ingeniería del Software

“Desarrollo de un Sistema Experto para la Elección de un Método Ágil”

Proyecto Final

Presentado a: Lic. Luís Gilberto Salinas

Presentado por: Roger Saravia Aramayo

Agosto de 2007

Resumen

En el presente documento se desarrolla cómo puede construirse un sistema experto basado en reglas de producción para elegir a través del mismo una metodología ágil de desarrollo de software. Primero, se elabora bien el planteamiento del problema. Luego, se hace una revisión de la literatura y se desglosa el marco teórico pero principalmente enfocado al manifiesto ágil. Posteriormente, se expone el desarrollo teórico-práctico que lleva a la concreción del mencionado sistema experto bautizado en esta parte como “Mentor Versión 1.0”. Con el software ya concluido, se soluciona un caso de estudio típico propuesto. Y finalmente, se hacen algunas conclusiones y recomendaciones para estudios futuros.

Palabras Clave

Metodologías de Desarrollo, Métodos Ágiles, Manifiesto Ágil, Programación Extrema (XP), Cristal de Cockburn, Desarrollo de Software Adaptable (ASD), Scrum, Desarrollo Manejado por Rasgos (FDD), Sistema Experto, Reglas de Producción.

1

Índice

1 INTRODUCCIÓN .........................................................................................................................................2 1.1 ESCENARIO..............................................................................................................................................2 1.2 PROBLEMA IDENTIFICADO ......................................................................................................................2 1.3 ABORDAJE DEL PROBLEMA.....................................................................................................................2

2 OBJETIVOS ..................................................................................................................................................2 2.1 OBJETIVO GENERAL................................................................................................................................2 2.2 OBJETIVOS ESPECÍFICOS .........................................................................................................................3

3 JUSTIFICACIÓN..........................................................................................................................................3

4 MARCO TEÓRICO......................................................................................................................................3 4.1 LAS METODOLOGÍAS...............................................................................................................................3 4.2 EL DESARROLLO DE SOFTWARE ADAPTABLE DE HIGHSMITH (ASD) ....................................................4 4.3 SCRUM.....................................................................................................................................................5 4.4 XP (PROGRAMACIÓN EXTREMA) ............................................................................................................6 4.5 LA FAMILIA DE CRISTAL DE COCKBURN ................................................................................................6 4.6 DESARROLLO MANEJADO POR RASGOS (FDD) ......................................................................................7

5 DESARROLLO TEÓRICO-PRÁCTICO...................................................................................................8 5.1 DISEÑO DEL SISTEMA EXPERTO..............................................................................................................8 5.2 IMPLEMENTACIÓN DEL SISTEMA EXPERTO EN VISUAL BASIC 5.............................................................9

6 CASOS DE ESTUDIO.................................................................................................................................12 6.1 CASO DE ESTUDIO 1 ..............................................................................................................................12

6.1.1 Problema...........................................................................................................................................12 6.1.2 Solución ............................................................................................................................................12

7 CONCLUSIONES Y RECOMENDACIONES.........................................................................................14

8 REFERENCIAS...........................................................................................................................................15

APÉNDICES.........................................................................................................................................................15 A SISTEMAS EXPERTOS .................................................................................................................................15

Sistemas Basados en Reglas (SBR)................................................................................................................15 Proceso de Razonamiento..............................................................................................................................16 Información incierta en los SBR....................................................................................................................16 Explicaciones .................................................................................................................................................17

2

1 Introducción

1.1 Escenario

El escenario de este proyecto se desarrolla principalmente en el área de la ingeniería del software específicamente en la rama de metodologías ágiles de desarrollo de software.

Las metodologías de desarrollo han estado presentes durante mucho tiempo pero sin ser muy exitosas. Estas metodologías son burocráticas. Al seguir la metodología, el ritmo entero del desarrollo se retarda. Como reacción a estas metodologías, un nuevo grupo de metodologías ha surgido últimamente. Se conocían como metodologías ligeras pero el término ahora es metodologías ágiles. El encanto de estas metodologías ágiles es su reacción a la burocracia. Estos nuevos métodos buscan un medio entre ningún proceso y demasiado proceso.

1.2 Problema Identificado

Uno de los principales problemas identificados con relación a las metodologías ágiles de desarrollo de software es el cómo elegir una de ellas a partir de ciertas condiciones iniciales dadas.

1.3 Abordaje del Problema

Se resolverá el problema mediante la propuesta y desarrollo de un sistema experto basado en reglas de producción pero capaz de sugerir una metodología ágil de desarrollo de software sobre la base de una serie de preguntas pertinentes.

2 Objetivos

2.1 Objetivo General

• Determinar el método ágil de desarrollo de software a seguir para un proyecto dado mediante la aplicación de un sistema experto basado en reglas de producción.

3

2.2 Objetivos Específicos

• Desarrollar la teoría y especificaciones de distintos métodos ágiles de desarrollo.

• Desarrollar las reglas condición-acción para la elección de los distintos métodos ágiles de desarrollo.

• Desarrollar un sistema experto basado en reglas de producción para la elección de un método ágil de desarrollo correspondiente a un proyecto dado.

3 Justificación

La elección de un método ágil de desarrollo adecuado es muy importante para el desarrollo exitoso de software. El desarrollo de software es una actividad caótica caracterizada por la frase "codifica y corrige". El software se escribe con un plan mínimo y el diseño se hace con decisiones a corto plazo. Se ha vivido con este estilo por tiempo pero se ha tenido una alternativa desde no hace mucho: la metodología ágil. Las metodologías ágiles imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más eficiente. Los métodos ágiles son adaptables en lugar de predictivos. Los métodos ágiles son orientados a la gente y no orientados al proceso. Están a favor de la naturaleza humana y enfatizan que el desarrollo de software debe ser una actividad agradable.

4 Marco Teórico

4.1 Las Metodologías

Varias metodologías encajan bajo el estandarte de ágil. Mientras todas ellas comparten muchas características, también hay diferencias significativas. No se puede resaltar todos los puntos en este proyecto. Tampoco se tiene experiencia significativa sobre la mayoría de ellas.

Metodologías Ágiles Metodologías Tradicionales

Basadas en heurísticas provenientes de producción de código

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo) Impuestas externamente

Proceso menos controlado, con pocos principios

Proceso mucho más controlado, con numerosas normas

4

Generalmente no existe un contrato tradicional, o al menos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones

Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio

Grupos grandes y posiblemente distribuidos

Menos énfasis en la arquitectura del software

La arquitectura del software es esencial y se expresa mediante modelos

4.2 El Desarrollo de Software Adaptable de Highsmith (ASD)

Jim Highsmith ha pasado años trabajando con metodologías predictivas. Él las desarrolló, instaló, enseñó, y concluyó que son profundamente defectuosas para los negocios modernos.

Jim, se enfoca en la naturaleza adaptable de las nuevas metodologías con énfasis en aplicar las ideas que se originaron en el mundo de los sistemas complejos adaptables (conocida como teoría del caos). No proporciona el tipo de prácticas detalladas como lo hace la XP, pero proporciona la base fundamental de por qué el desarrollo adaptable es importante y las consecuencias a los más profundos niveles de la organización y la gerencia.

En el corazón del ASD hay tres fases solapadas, no lineales: especulación, colaboración, y aprendizaje.

Highsmith ve la planificación como una paradoja en un ambiente adaptable ya que los resultados son naturalmente imprevisibles. En la planificación tradicional, las desviaciones del plan son errores que deben corregirse. En un ambiente adaptable, sin embargo, las desviaciones guían hacia la solución correcta.

En este ambiente imprevisible se necesita que las personas colaboren de la mejor manera para tratar con la incertidumbre. La atención de la gerencia es menor en lo que tiene que hacer la gente y mayor sobre la comunicación alentadora para que las personas puedan proponer las respuestas creativas por su cuenta.

En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se ponen de antemano y entonces se sigue ese diseño.

En un ambiente adaptable, aprender desafía a todos - desarrolladores y sus clientes - a examinar sus asunciones y a usar los resultados de cada ciclo de desarrollo para adaptar el siguiente.

El aprendizaje como tal es un rasgo continuo e importante: uno asume que los planes y los diseños deben cambiar conforme avanza el desarrollo.

El beneficio atropellado, poderoso, indivisible y predominante del Ciclo de Vida de Desarrollo Adaptable obliga a confrontar los modelos mentales que están en la raíz de un autoengaño. Obliga a estimar con realismo la habilidad.

5

Con este énfasis, el trabajo de Highsmith se enfoca directamente en fomentar las partes difíciles del desarrollo adaptable, en particular cómo fomentar la colaboración y el aprendizaje dentro del proyecto.

Ilustración 1. Proceso del ASD

4.3 Scrum

Scrum ha estado durante tiempo en los círculos orientados a objetos. De nuevo se enfoca en el hecho de que procesos definidos y repetibles sólo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles.

Scrum divide un proyecto en iteraciones (carreras cortas) de 30 días. Antes de que comience una carrera, se define la funcionalidad requerida para esa carrera y entonces se deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la carrera.

Sin embargo, la gerencia no se desentiende durante la carrera corta. Todos los días el equipo sostiene una junta corta (quince minutos) llamada scrum, dónde el equipo discute lo que hará al día siguiente. En particular se muestra a los bloques de la gerencia los impedimentos para progresar que se atraviesan y que la gerencia debe resolver. También informan lo que se ha hecho para que la gerencia tenga una actualización diaria de por dónde va el proyecto.

Scrum se enfoca principalmente en la planeación iterativa y el seguimiento del proceso. Es muy cercana a las otras metodologías ágiles en muchos aspectos y debe funcionar bien con las prácticas de código de la XP.

6

4.4 XP (Programación Extrema)

De todas las metodologías ágiles, ésta es la que ha recibido más atención. Esto se debe en parte a la notable habilidad de los líderes XP, en particular Kent Beck, para llamar la atención. También se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento y tomar un papel principal en él. Sin embargo, la popularidad de XP se ha vuelto un problema, pues ha acaparado la atención fuera de las otras metodologías y sus valiosas ideas.

Las raíces de la XP yacen en la comunidad de Smalltalk y en particular gracias a la colaboración cercana de Kent Beck y Ward Cunningham a finales de los 1980s. Ambos refinaron sus prácticas en numerosos proyectos a principios de los 90s, extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente.

El paso crucial de la práctica informal a una metodología ocurrió en la primavera de 1996. A Kent se le pidió revisar el progreso del proyecto C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compañía contratista y estaba en problemas. Debido a la baja calidad del código, Kent recomendó tirar la base del código en su totalidad y empezar desde el principio. El proyecto entonces reinició bajo su dirección y subsecuentemente se volvió el buque insignia temprano y el campo de entrenamiento de la XP.

La primera fase del C3 fue exitosa y comenzó a principios de 1997. El proyecto continuó desde entonces y después se encontró con dificultades que llevaron a la cancelación del desarrollo en 1999. (Lo cual prueba que XP no es garantía de éxito)

XP empieza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje. Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir. Muchas de estas prácticas son técnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la mayoría de los procesos planeados. Además de resucitar estas técnicas, la XP las teje en un todo sinérgico dónde cada una refuerza a las demás. Una de las más llamativas y atractivas es su fuerte énfasis en las pruebas. Mientras todos los procesos mencionan a las pruebas, la mayoría lo hace con muy poco énfasis. La XP pone la comprobación como fundamento del desarrollo con cada programador escribiendo pruebas cuando escriben su código de producción. Las pruebas se integran una plataforma altamente estable para el desarrollo futuro. En esta plataforma, XP construye un proceso de diseño evolutivo basado en re-factorar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada para necesidades futuras. El resultado es un proceso de diseño disciplinado; combina la disciplina con la adaptabilidad de manera que indiscutiblemente la hace la más desarrollada entre todas las metodologías adaptables.

4.5 La Familia de Cristal de Cockburn

Alistair Cockburn ha estado trabajando en metodologías desde que la IBM le encargó escribir sobre metodologías a inicios de los 90. Su acercamiento no es como la mayoría de los metodologistas. En lugar de partir solo de su experiencia personal para construir una teoría de cómo deben hacerse las cosas, él complementa su experiencia directa con la búsqueda activa de proyectos donde puede ver cómo trabajan. Además él no teme alterar sus puntos de vista con base en sus descubrimientos.

7

Él ha explorado más los métodos ágiles viniendo con la familia de metodologías Crystal. Es una familia porque él cree que los tipos diferentes de proyectos requieren tipos diferentes de metodologías. Él mira esta variación a lo largo de dos ejes: el número de personas en el proyecto y las consecuencias de los errores. Cada metodología encaja en una parte diferente de la reja; para un proyecto de 40 personas que puede perder dinero discrecionalmente tiene una metodología diferente a la de un proyecto vital de 6 personas.

Los Cristales comparten con la XP una orientación humana pero esta centralización en la gente se hace de una manera diferente. Alistair considera que las personas encuentran difícil seguir un proceso disciplinado así que más que seguir la alta disciplina de la XP, Alistair explora la metodología menos disciplinada que aun podría tener éxito, intercambiando conscientemente productividad por facilidad de ejecución. Él considera que aunque Cristal es menos productivo que la XP, más personas serán capaces de seguirlo.

Alistair también pone mucho peso en las revisiones al final de la iteración, animando al proceso a ser auto-mejorable. Su aserción es que el desarrollo iterativo está para encontrar los problemas temprano y entonces permitir corregirlos. Esto pone más énfasis en la gente supervisando su proceso y afinándolo conforme desarrollan.

4.6 Desarrollo Manejado por Rasgos (FDD)

El Desarrollo Manejado por Rasgos (FDD por sus siglas en inglés) fue desarrollado por Jeff De Luca y el viejo gurú de la OO Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran solo dos semanas.

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

• Desarrol lar un Modelo Global

• Construir una Lista de los Rasgos

• Planear por Rasgo

• Diseñar por Rasgo

• Construir por Rasgo

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.

Los desarrolladores entran en dos tipos: dueños de clases y programadores jefe. Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir. Sin embargo, ellos no los construyen solos. Solo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo y desarrollar ese rasgo. El programador jefe actúa como coordinador, diseñador líder y mentor, mientras los dueños de clases hacen gran parte de la codificación del rasgo.

8

5 Desarrollo Teórico-Práctico

5.1 Diseño del Sistema Experto

Para el diseño del sistema experto basado en reglas (SBR), primero se ha seleccionado una lista de atributos preguntables y otra de atributos objetivos. No se ha listado atributos intermedios. Como atributos preguntables han sido elegidos los requisitos determinantes de los métodos ágiles de desarrollo. Y como atributos objetivos están los métodos ágiles de desarrollo considerados en este trabajo de investigación.

AAtteenncciióónn:: Los atributos o rasgos preguntables son aquellos destinados al usuario. Los atributos intermedios son una subfamilia pero no la conclusión. Y los atributos objetivos son la solución que se quiere obtener.

Para simplificar la extensión del documento, a continuación se muestra solo parte de la tabla de los atributos preguntables y objetivos usados en este proyecto:

AAttrriibbuuttooss PPrreegguunnttaabblleess AAttrriibbuuttooss OObbjjeettiivvooss

La colaboración interpersonal ASD

Orientación a objetos Scrum

Sobre las pruebas intensivas XP, Cristal de Cockburn

Sobre valores humanos XP

Sobre la auto-supervisión Cristal de Cockburn

Sobre ciclos cortos de producción FDD

Y así la lista continúa…

Es importante mencionar que, a mayor cantidad de atributos, mayor la precisión en la respuesta obtenida mediante el sistema experto.

Y para cumplir con la completitud del diseño del sistema experto en cuestión, a continuación se expone solo una parte de la red de inferencia lograda a partir de la tabla anterior.

9

ScrumXP Cristal de Cockburn

ReunionesDiarias

Orientacióna Objetos

PruebasIntensivas

Ilustración 2. Parte de la Red de Inferencia del Sistema Experto

5.2 Implementación del Sistema Experto en Visual Basic 5

La implementación en Visual Basic 5 consiste en la programación de una plataforma de sistema experto bautizada como “Mentor 1.0”. Esta plataforma sirve para hacer las preguntas al usuario, “calcular” la inferencia con su correspondiente ponderación y mostrar los resultados con su valor de certidumbre. La plataforma hace uso de las siguientes transacciones:

Entradas: 1

Sal idas: 1

Archivos internos: 2

La entrada ha sido elaborada usando un formulario que hace la pregunta al usuario, que da una pauta o aclaración sobre la pregunta y que pide una valoración del 0 al 10 para la respuesta. El valor máximo o 10 puede interpretarse como un “sí absoluto” y el valor mínimo 0 puede interpretarse como un “no absoluto”. La ilustración 3 muestra el formulario de entrada.

La salida ha sido construida también mediante un formulario. Este formulario muestra la respuesta o método ágil recomendado, las razones que respaldan dicha respuesta y un valor de certidumbre expresado en porcentaje. El valor de certidumbre refleja cuánto se corresponde la respuesta con el caso de estudio que se haya introducido por medio de las preguntas. Si hay más de una respuesta con valores de certidumbre de aprobación, pueden verse usando el botón “Otro” situado en la parte inferior del formulario. Si se obtiene un valor de certidumbre menor al 51%, el programa no muestra ninguna respuesta o método ágil y sugiere considerar la revisión de métodos tradicionales de desarrollo de software. La ilustración 4 muestra el formulario de salida.

10

Ilustración 3. Formulario de Entrada del Sistema Experto

Ilustración 4. Formulario de Salida del Sistema Experto

11

Por otra parte, el archivo interno llamado “origen1.DAT” consiste en la información fuente relacionada con los atributos preguntables y atributos objetivos; es decir, contiene todas las preguntas y sus correspondientes pautas que se realizan durante la etapa de los formularios de entrada. La ilustración 5 muestra parte del contenido de este archivo interno. Y la ilustración 6 muestra parte del código en Visual Basic que se encarga de la recuperación de este mismo archivo interno.

** ""¿¿CCóómmoo eess llaa aatteenncciióónn ddee llaa ggeerreenncciiaa ccoonn rreellaacciióónn aa llaa ccoommuunniiccaacciióónn aalleennttaaddoorraa??"" ""LLaa ccoommuunniiccaacciióónn aalleennttaaddoorraa hhaaccee qquuee llaass ppeerrssoonnaass ppuueeddaann pprrooppoonneerr rreessppuueessttaass ccrreeaattiivvaass ppoorr ssuu ccuueennttaa.."" AASSDD,, 11 ** ** ""¿¿HHaayy pprreeddiissppoossiicciióónn ddee llaass ppeerrssoonnaass ppaarraa ccoollaabboorraarr ddee llaa mmeejjoorr mmaanneerraa??"" ""LLaa ccoollaabboorraacciióónn eess nneecceessaarriiaa ppaarraa ttrraattaarr ccoonn llaa iinncceerrttiidduummbbrree.."" AASSDD,, 11 **

Ilustración 5. Parte de la Estructura del Archivo Interno “origen1.DAT”

PPuubb ll ii cc SSuubb rr ee (( )) nn == 00 OOppeenn "" oo rr ii ggeenn11 ..DDAATT"" FFoorr II nnppuu tt AAss ##11 DDoo DDoo II nnppuu tt ##11 ,, rr LLoooopp UUnn tt ii ll rr == cc OOrr EEOOFF((11 )) II ff rr == cc TThheenn nn == nn ++ 11 II nnppuu tt ##11 ,, qq ((nn )) II nnppuu tt ##11 ,, ee ((nn )) oo == 00 DDoo II nnppuu tt ##11 ,, ss II ff ss <<>> cc TThheenn II nnppuu tt ##11 ,, tt oo == oo ++ 11 mm((nn ,, oo )) == ss ff (( nn ,, oo )) == VVaa ll (( tt )) EEnndd II ff LLoooopp UUnn tt ii ll ss == cc EEnndd II ff LLoooopp UUnn tt ii ll EEOOFF((11 )) CC ll oossee ##11 EEnndd SSuubb

Ilustración 6. Parte del Código en Visual Basic para la Recuperación del Archivo Interno “origen1.DAT”

12

6 Casos de Estudio

Para ejemplificar el uso del sistema experto “Mentor 1.0” se planteará un problema o caso de estudio que se introducirá y resolverá por medio de dicha aplicación.

6.1 Caso de Estudio 1

6.1.1 Problema

Una empresa de software desea emplear un método ágil para su próximo proyecto de desarrollo consistente en un programa para el análisis y diseño de estructuras en el campo de la ingeniería civil. Se tiene la siguiente información: Los requisitos son inicialmente fijos aunque puede considerarse algún cambio en caso de ser necesario. Los desarrolladores son sujetos responsables pero no altamente motivados. Aunque los clientes no entienden en un 100%, se involucrarán en el proceso. No hay mucha preocupación por parte de la gerencia con relación a la comunicación. Las personas del equipo de trabajo están dispuestas a colaborar entre sí en todo lo que sea necesario. El software a ser desarrollado está totalmente orientado a objetos. Se trata de un proyecto totalmente nuevo para la empresa. Hay muy pocas posibilidades de reuniones diarias. Los valores humanos del equipo inicialmente están altos. Se ha establecido la necesidad de pruebas intensivas. El equipo puede abordar un trabajo disciplinado aunque no del todo rígido. Las personas son apenas capaces de supervisar su propio trabajo. Hay opción de ciclos de trabajo cortos. No hay desarrolladores capaces de trabajar por rasgos. Se prevé un equipo de unas 30 personas.

6.1.2 Solución

La valoración de la información durante su introducción puede estar sujeta a la subjetividad por parte del usuario. De cualquier manera, a continuación se ha reunido las preguntas y respuestas correspondientes a este caso de estudio.

PPrreegguunnttaa VVaalloorraacciióónn ((11 aall 1100))

¿Requisitos inciertos y volátiles? 6

¿Hay desarrolladores responsables y motivados? 8

¿Los clientes entienden y se involucrarán en el proceso? 8

¿Cómo es la atención de la gerencia con relación a la comunicación alentadora?

6

¿Hay predisposición de las personas para colaborar de la mejor manera?

9

13

¿Se trata de un proyecto orientado a objetos? 10

¿Se trata de un problema definido y repetible? 0

¿Hay posibilidad de reuniones diarias de equipo? 5

¿Cómo está la predisposición a la comunicación, retroalimentación, simplicidad y coraje?

9

¿Hay disponibilidad para pruebas intensivas? 9

¿Hay predisposición para un trabajo disciplinado? 8

¿Hay personas capaces de supervisar su propio proceso? 6

¿Hay disponibilidad para ciclos de producción cortos? 7

¿Hay desarrolladores experimentados capaces de trabajar por rasgos?

0

¿El equipo de trabajo está entre las 20 y 50 personas? 10

¿El equipo de trabajo está entre las 100 personas? 0

Luego de responder a todas las preguntas según el resumen anterior, se tiene el siguiente resultado que recomienda en primer lugar al método ágil de programación extrema o XP:

Ilustración 7. Solución Principal al Caso de Estudio

14

Después de pulsar el botón “Otro” aparecen las soluciones secundarias. Entonces, un resumen de los métodos ágiles recomendados por el sistema experto “Mentor 1.0”, es el siguiente:

RReeccoommeennddaaddooss CCeerrttiidduummbbrree

XP 82%

ASD 74%

Cristal de Cockburn 65%

FDD 65%

Scrum 52%

Nótese que el método ágil Scrum es el de menor certidumbre; razón por la cual, es el menos recomendado para el presente caso de estudio.

7 Conclusiones y Recomendaciones

Se revisaron ventajas de los métodos ágiles, como ser: iteraciones en ciclos cortos que permiten correcciones/verificaciones, tiempo para cada ciclo de dos a ocho semanas, adaptables al surgimiento de nuevos riesgos, orientación hacia las personas y estilo de trabajo en equipo. Y algunas desventajas, como ser: la filosofía de adaptarse al cambio puede llevar al caos en el proceso de desarrollo, la dificultad de mantener el interés de los clientes que participan en el proceso de desarrollo, el definir las prioridades de los cambios puede ser difícil de establecer cuando existen múltiples personas involucradas en el proyecto, el hecho de mantener la simplicidad significa un trabajo extra y la definición de los contratos puede ser un problema.

Para el sistema experto de métodos ágiles “Mentor 1.0” fue necesario plasmar su diseño discriminando los atributos preguntables de los atributos objetivos. Los atributos preguntables se correspondieron con las características principales de dichos métodos. Y los atributos objetivos se correspondieron con los mismos métodos.

Para una versión futura del sistema experto desarrollado, podría mejorarse el número y la calidad de los atributos preguntables en base a una revisión aún más extensa de la literatura sobre métodos ágiles. Porque, a mayor número de atributos preguntables, mayor precisión en la solución.

Importante apuntar que, no siempre podrá encontrarse un método ágil de desarrollo capaz de encajar en un 100% con los requisitos de un emprendimiento. Además puede haber más de una opción de método ágil aunque de distinto valor de certidumbre.

Finalmente, él área de la inteligencia artificial puede constituirse en una herramienta de apoyo para la ingeniería del software, tal como se mostró en este trabajo.

15

8 Referencias

• MARTIN FOWLER (2003) “La Nueva Metodología”. Chief Scientist, ThoughtWorks

• LUIS G. SALINAS (2007) "Métodos Ágiles". Presentación PowerPoint. Postgrado en Informática. UMSA. LP-BOL.

• DANIEL GÁLVEZ L. (2007) "Sistemas Expertos". Presentación PowerPoint. Postgrado en Informática. UMSA. LP-BOL.

• PETER NORTON (2002) "New Inside The PC". Second Edition. SAMS. Indiana-USA. 2002.

Apéndices

A Sistemas Expertos

Sistemas Basados en Reglas (SBR)

Los SBR son los más conocidos de los sistemas basados en el conocimiento clásicos (SBC). Los SBR son SBC en los que la forma de representación del conocimiento usado son las reglas de producción y como método de inferencia utiliza la regla de modus ponens. Los SBR son llamados frecuentemente sistemas de producción.

Las reglas utilizan un formato IF - THEN para representar el conocimiento. La parte IF de una regla es una condición (también llamada premisa o antecedente) y la parte THEN de la regla (también llamada acción, conclusión o consecuente) permite inferir un conjunto de hechos nuevos si se verifican las condiciones establecidas en la parte IF.

Las reglas pueden expresar un amplio rango de asociaciones:

a) Situación – acción

Si esta lloviendo y va a salir, entonces debe buscar una capa.

b) Premisa – conclusión

Si su temperatura es de 400 grados, entonces usted tiene fiebre.

c) Antecedente – consecuente

Si x es un gato, entonces x es un animal.

16

Los SBR son frecuentemente confundidos con sistemas lógicos; sin embargo, estos se definen en dos ideas principales:

• Los SBR son generalmente no monotónicos; es decir, los hechos pueden variar su veracidad durante el proceso de razonamiento.

• Los SBR aceptan incertidumbre en el proceso deductivo.

Proceso de Razonamiento

El proceso de solución de problemas en un SBR consiste en crear una cadena de inferencias que constituye un camino entre la definición del problema y su solución. Esta cadena de inferencias puede construirse por dos vías (direcciones de búsqueda):

1- Comenzar con todos los datos conocidos y progresar hacia la conclusión (data driven o forward chaining).

2- Seleccionar una conclusión posible y tratar de probar su validez buscando evidencias que la soporten (goal driven o backward chaining).

La dirección forward es apropiada cuando hay pocos datos de entrada o la cantidad de conclusiones posibles es grande. Entre los campos de aplicación para esta dirección de búsqueda están monitoreo y diagnóstico en sistemas de control en tiempo real, diseño y planificación.

La dirección backward es apropiada cuando hay pocas conclusiones posibles o cuando los valores de entrada no son adquiridos automáticamente. Los problemas de diagnóstico y clasificación son frecuentemente resueltos con esta dirección de búsqueda.

Información incierta en los SBR

Otra de las facilidades del SBR es la manipulación de la incertidumbre. La necesidad de considerar la incertidumbre se origina en dos hechos:

• Imprecisiones en los datos.

• Falta de seguridad en las reglas.

Tanto los datos que describen el problema a resolver como las reglas pueden no ser totalmente ciertos durante el proceso de razonamiento. Entonces, se hace necesario calcular la certidumbre para cada nuevo valor inferido. Y al terminar el proceso de inferencia la respuesta debe tener asociado su grado de certidumbre.

17

Explicaciones

El SBR debe ser capaz de ofrecer explicaciones al usuario cuando éste pida. Usualmente hay dos momentos donde el usuario puede preguntar:

• Cuando se pide un nuevo dato el usuario.

o En este caso el usuario puede querer saber por qué se le hace esa pregunta.

• Cuando se termina el proceso de inferencia

o El usuario puede querer saber cómo se alcanzó la respuesta que se le da.