Raciocínio Baseado em Casos

A engenharia de software é uma área que requer muito conhecimento e o gerenciamento efetivo desse conhecimento tem sido visto como um fator crítico para a sobrevivência das organizações de software (BJØRNSON e DINGSØYR, 2008; RICHARDSON et al., 2009). Assim, modelar o conhecimento associado a experiências vividas na organização se mostra bem relevante.

No entanto, para que seja possível aproveitar o conhecimento adquirido no passado, uma organização precisa ser capaz de aprender a partir de suas experiências e reconhecer quando um aprendizado anterior se mostra adequado ao cenário atual. Para que a transferência de conhecimento seja possível e viável, é necessário que as experiências adquiridas sejam catalogadas e armazenadas de modo que elas não sejam futuramente esquecidas ou perdidas (SOUZA, 2002).

Nesse contexto, o Raciocínio Baseado em Casos - RBC (Case-Based Reasoning -

CBR) foi proposto por SCHANK (1982) com base na premissa de que uma solução

ótima para um dado problema pode ser recuperada com base em experiências similares, reforçando a idéia de aprendizado com a experiência (KANG et al., 2010). O RBC descreve um enfoque de aprendizado contínuo e incremental que utiliza o conhecimento de situações concretas acontecidas no passado - representadas como casos - para resolver novos problemas e aprender por meio da experiência adquirida (WANGENHEIM et al., 1998). O principal objetivo da abordagem RBC é o desenvolvimento de um conjunto de experiências práticas e o fornecimento de um amplo suporte ao desenvolvimento de sistemas apoiado nesta base de conhecimento (WANGENHEIM e WANGENHEIM, 2003).

O raciocínio contínuo proposto pelo RBC é descrito pelo “Ciclo de RBC”, um ciclo de quatro etapas principais: recuperação, reutilização, revisão e retenção. A Figura 3.1 apresenta esse ciclo.

Problema

(novo caso) Recuperação Caso armazenado Solução confirmada Solução adaptada Casos mais similares Casos mais

similaresCasos mais similares Reutilização Revisão Retenção Base de Casos

Figura 3.1 – Ciclo do RBC (adaptado de WANGENHEIM e WANGENHEIM, 2003)

Algumas vantagens oferecidas pelo RBC, em relação a outras abordagens de gerência de conhecimento são: (i) trata somente dos problemas que realmente ocorreram; (ii) aborda casos mal-sucedidos, permitindo ao usuário evitar possíveis riscos; (iii) permite a exploração de domínios de conhecimento pouco explorados; (iv) promove maior colaboração com os usuários, uma vez que as soluções recomendadas são derivadas do raciocínio humano (SHEPPERD, 2002; WANGENHEIM e WANGENHEIM, 2003).

A literatura apresenta diversos trabalhos relacionados ao uso da abordagem RBC e de outras aplicações que de alguma forma fazem recomendações ao usuário. SANTOS e CORTÉS (2010) propõem uma abordagem baseada em RBC para reutilização de processos de software que apóia a definição, a adaptação e a melhoria do processo padrão da organização. Um ambiente baseado em RBC para apoiar a reutilização de conhecimento durante o planejamento e a execução de atividades de ensino e aprendizado é apresentado em (BOMFIM et al., 2007). TONELLA et al. (2006) apresentam uma técnica de priorização de casos de teste baseada em conhecimento utilizando o RBC. Em KIRSOPP et al. (2002), é apresentado um sistema de raciocínio baseado em caso otimizado que é usado para estimar esforço de projetos de software. ALTHOFF et al. (1999) propõem o uso do RBC como apoio à melhoria de processos. Em SHEPPERD (2002) são descritas algumas aplicações do RBC na engenharia de software, mais especificamente na predição de esforço e defeitos em projetos de software e na reutilização de software.

Como citado anteriormente, ao utilizar o RBC, a recuperação de soluções para novos problemas depende diretamente da capacidade de identificar problemas similares ao problema atual. Por isso, a seção a seguir apresenta uma breve revisão sobre análise de similaridade no contexto de projetos de software.

3.3.1 Análise de Similaridade entre Projetos de Software

A análise de similaridade é claramente um fator crítico na aplicação do RBC (SMYTH, 2007). A eficácia do RBC depende essencialmente da escolha de um conceito de similaridade adequado para o domínio da aplicação e a estrutura dos casos usados (WANGENHEIM e WANGENHEIM, 2003). Assim, pode-se afirmar que na aplicação do RBC, as seguintes premissas devem ser satisfeitas com relação à análise de similaridade (WANGENHEIM e WANGENHEIM, 2003):

• A similaridade entre o problema atual e os casos anteriores implica em utilidade;

• A similaridade é baseada em fatos a priori; e,

• A similaridade precisa prover uma medida, uma vez que casos podem ser mais ou menos úteis em relação ao problema atual.

No contexto de monitoração de objetivos e projetos de software, a caracterização dos projetos é muito importante para determinar a similaridade. Características como duração do projeto, nível de experiência do gerente, grau de estabilidade dos requisitos, dentre outras, se mostram relevantes para a identificação de situações similares em organizações de software, como descrito em vários trabalhos na literatura. SANTOS e CORTÉS (2010) apresentam uma lista de características usadas para determinar a similaridade entre projetos de software e, com base nessa similaridade, identificar oportunidades de reutilizar os processos de software executados nos projetos. Essa lista inclui o modelo de ciclo de vida, a complexidade do projeto, o tamanho do projeto, o tamanho da equipe, a duração do projeto, o nível de conhecimento da equipe sobre Engenharia de Software, e o paradigma de desenvolvimento adotado no projeto.

Em LI et al. (2007) e PEISCHL et al. (2009) a caracterização de projetos é usada para apoiar métodos de estimativa de esforço para projetos de software. Algumas características consideradas nesses trabalhos foram o tipo de desenvolvimento (por exemplo: novo desenvolvimento, manutenção, customização), o modelo de ciclo de vida, o tamanho do projeto, a tecnologia utilizada e o domínio da aplicação. A

caracterização de projetos também tem sido usada para apoiar a gerência de riscos de projetos (FARIAS, 2002) e o planejamento de um novo projeto com base em projetos anteriores similares (YANG e WANG, 2008). Algumas características de projeto são usadas para apoiar a adaptação de processos para os projetos (BERGER, 2003; PREEZ

et al., 2008; KANG et al., 2008). Em HONG et al. (2008) é apresentado um modelo

para predizer a distribuição dos defeitos ao longo do projeto, com base nas características do projeto. Em SOUZA (2008) a caracterização de projetos também é considerada na seleção de projetos para compor o portfólio de projetos de uma organização.

No RBC, normalmente as características usadas para determinar a similaridade entre os casos são denominadas índices. Assim, dados dois casos, é possível determinar o grau de similaridade entre os casos considerando cada característica ou índice específico. Essa similaridade entre dois casos para um determinado índice é considerada similaridade local. Após analisar a similaridade para cada índice específico, é necessário analisar a similaridade entre os dois casos considerando a similaridade local para todos os índices. Essa similaridade entre os dois casos considerando todos os índices é denominada similaridade global (WANGENHEIM e WANGENHEIM, 2003).

Uma das formas de analisar a similaridade é através de uma medida. No contexto do RBC, uma das medidas de similaridade mais conhecidas é a Nearest Neighbor (the NN

technique), que mede a similaridade entre dois casos considerando a soma da

similaridade entre cada característica (também denominada índice do caso) (WANGENHEIM e WANGENHEIM, 2003; SMYTH, 2007). Para permitir a representação de níveis diferentes de importância para cada característica, um peso específico para cada característica pode ser considerado no cálculo dessa medida. Nesse caso, a medida Nearest Neighbor é denominada Weighted Nearest Neighbor - WNN (WANGENHEIM e WANGENHEIM, 2003; SMYTH, 2007).

De forma geral, a análise de similaridade tem sido usada para apoiar os sistemas de recomendação na identificação de situações semelhantes que forneçam subsídios para recomendações mais adequadas. Nesse contexto, a seção a seguir apresenta uma revisão sobre sistemas de recomendação.