Para o desenvolvimento de software, na maior parte do tempo, as decisões tomadas pela equipe do projeto ainda são feitas com base na experiência de cada indivíduo. No entan- to, as atividades dessa área são coletivas e, por isso, os indivíduos precisam se comunicar, compartilhando conhecimentos para alcançar o resultado desejado (GUIMARÃES, 2009, p. 19).
Esse compartilhamento proporciona não só o enriquecimento do conhecimento pessoal dos envolvidos (adquirido através do amadurecimento das ideias, provenientes das exposi- ções) como também do amadurecimento organizacional (resultado da aplicação positiva dos conhecimentos compartilhados e evoluídos) (RIEGE, 2005).
Decisões tomadas indevidamente, durante o desenvolvimento de software, contribuem significativamente para extrapolar datas e orçamentos, além do risco de entregar produtos falhos (BOOKS, 1986).
Em contrapartida, os projetos que envolvem decisões têm crescido em complexidade, tanto em relação à lógica envolvida, quanto à própria organização da equipe, cada vez maior e dispersa geograficamente. As atividades realizadas nesses projetos precisam ser coordenadas, comunicadas e preservadas, de forma a permitir a propagação das atitudes corretas tomadas.
Ao abordar o processo de aprendizado organizacional, Huber (1991, p. 90) propõe quatro construtos relacionados (Figura 2):
Aquisição de conhecimento: processo pelo qual o conhecimento é obtido;
Distribuição da Informação: processo responsável pelo compartilhamento da informa- ção por intermédio de fontes diferentes, resultando em novas informações;
Interpretação da Informação: é o processo que faz uso das informações distribuídas pro- porcionando os mais variados entendimentos e interpretações;
Memória Organizacional: é o meio pelo qual o conhecimento é armazenado para usos posteriores.
Figura 2: Processo de aprendizado organizacional
A instanciação, no desenvolvimento de software, do processo proposto por Huber (1991, p. 90) pode ser um caminho viável para enfrentar a complexidade vivenciada neste contexto.
Preocupado com as barreiras existentes no processo de captura de DR, Burge (2008) sugere três incentivos:
Integração com CMMi: um incentivo para o uso do DR na Engenharia de Software po- de ser encontrado na área de processo de Análise e Resolução de Decisão (DAR), do CMMi. Essa área envolve avaliação formal de alternativas de decisão, incluindo ele- mentos como identificação da alternativa, determinação de critérios de avaliação, sele- ção de métodos de avaliação e uso e, finalmente, seleção de alternativas escolhidas de acordo com os critérios identificados. Além disso, o CMMi salienta a importância desse procedimento em decisões identificadas como de “alto risco”.
Gestão do Conhecimento: DR possui a habilidade de capturar o conhecimento corpora- tivo. Para a engenharia de software o capital intelectual é um recurso essencial para uma organização de software (RUSS e LINDVALL, 2002). Os desafios encontrados pelos
usuários de DR são bastante semelhantes aos enfrentados pela GC (SMITH e FARGU- HAR, 2000): (i) Incentivar e encorajar o compartilhamento do conhecimento e (ii) Tor- nar a captura do conhecimento parte das práticas do negócio.
Engenharia de Software baseada em valor (VBSE): Nem todos os requisitos de software possuem valor igual entre os stakeholders, por isso deve-se considerar o valor agregado ao negócio quando da tomada de uma decisão. Boehm e Ross (1989) propuseram uma metodologia para capturar rationales considerando a utilidade, dependência, decisão e controle; usando o valor como um direcionador nas decisões relacionadas a Engenharia de Software, indicando qual valor, assim como métodos, que auxiliam a avaliação de cada solução alternativa. No entanto, essas avaliações envolvendo identificação de valo- res não eram tarefas triviais, pois envolviam muitas incertezas, tais como custos, confli- tos de interesses e benefícios intangíveis (ERDOGMUS, FAVARO e HALLING., 2006). Muitas dessas informações podem ser coletadas com o uso do DR.
Em complementação a esses incentivos, Gordon et al. (2001), ao perceberem a impor- tância de organizações de aprendizagem de software, concentram as atenções em habilitar os membros desse tipo de organização em solucionar situações, levando em conta as experiên- cias passadas. Sem deixar para trás o fortalecimento da comunicação interna (aprendizado em grupo), incluindo documentação de conhecimentos relevantes e o seu armazenamento na me- mória organizacional.
As barreiras identificadas por Horner e Attwood (2006), apesar de terem sido identifi- cadas há alguns anos, ainda retratam a realidade vivenciada pelas equipes em projetos de sof- tware, quando o assunto é gestão do conhecimento.
No entanto, muitos são os ganhos com a preservação e gestão do conhecimento. A re- presentação de casos representativos de situações rotineiras, como acontece em processos de Help Desk, por exemplo, auxiliam a padronização de orientações, garantindo resultados posi- tivos.
Quando se tratarem de casos mais robustos, envolvendo um grau mais elevado de ris- co, o uso de uma situação passada semelhante como base para sua resolução, facilita o proces- so de resolução, permitindo uma reflexão sobre formas de decisões acertadas ou mesmo con- duções sem sucesso.
Para que o conteúdo representado nos casos possa agregar conforme acima descrito, faz-se necessária a contemplação de todas as informações envolvidas no processo decisório: a situação problema, as alternativas consideradas para sua resolução, a decisão final e as justifi- cativas para o descarte das alternativas desconsideradas. Além disso, é importante garantir
uma avaliação posterior da resolução do caso, proporcionando maior segurança no conteúdo por ele representado.
A partir da caracterização do processo de tomada de decisão no desenvolvimento de software, fica claro o apelo ao uso do DR, suportado por técnicas de RBC, como possível so- lução para o reuso do conhecimento envolvido.
3 TRABALHOS CORRELATOS
Esta seção é resultado da investigação realizada sobre trabalhos relacionados aos te- mas fundamentados no referencial teórico deste trabalho, com foco em frameworks de apoio a decisão.
3.1 GIBIS
O sistema faz uso da notação de argumentação IBIS, representando a atividade de ar- gumentação realizada pelos desenvolvedores. Esse sistema tem o intuito de facilitar, capturar, estruturar e gravar a discussão entre os desenvolvedores, promovendo a formação de uma rede representativa da discussão (FRANCISCO, 2004). Além disso, é incorporado ao vocabu- lário IBIS uma representação gráfica através de um grafo direcional, apresentando o conteúdo dos nós e a navegação em janelas distintas, promovendo uma visão hierárquica da informação (MEDEIROS, 2006).
Nessa ferramenta, criação dos nós é realizada de forma controlada, sendo todos eles classificados e relacionados a um nó apropriado, seja ele classificado como Tema ou mesmo como uma Posição (MEDEIROS, 2006).
O gIBIS pode ser considerada uma ferramenta de navegação pela rede de nós, em de- trimento da avaliação de rationale ou apoio de tomada de decisão (MEDEIROS, 2006).
3.2 QUESTMAPTM
O QuestMap é uma versão da ferramenta gIBIS, porém com algumas modificações: ao nós “Tema” e “Posição” passam a ser representados por “Questão” e “Ideia”, e o nó “Argu- mento” apresenta uma divisão representando argumentos positivos e negativos (MEDEIROS, 2006).
Além disso, existe a possibilidade de adicionar diferentes tipos de informações, tais como vídeos, textos e figuras (MEDEIROS, 2006).
3.3 JANUS
JANUS é um sistema baseado na notação PHI voltado para ambientes de projetos de cozinhas planejadas (FISCHER & MCCALL,1989). Possui design arquitetural que integra um editor CAD com uma crítica de design baseada em regra e ambiente para documentação hi- pertexto.
Dessa forma, os desenhos em CAD são monitorados a medida que são elaborados, apresentando ao projetista avisos de violação de diretrizes. Além disso, pode ser requisitada pelo usuário a argumentação que justifica aquela violação, proporcionando insumo para a compreensão da regra (MEDEIROS, 2006).
3.4 DOCRATIONALE
O DocRationale é uma ferramenta desenvolvida por Francisco (2004) com objetivo principal de prover a captura, representação e recuperação de DR, relacionados a artefatos de software. No sentido de facilitar e estimular o uso, a representação do DR foi elaborada para ser realizada de forma simples.
Essa ferramenta não dispõe de recursos envolvendo inteligência artificial, pois a pre- missa é a colaboração através de registros efetuados por membros de equipes de desenvolvi- mento, para posterior consulta em projetos distintos.
O DocRationale é baseado, de forma simplificada, no modelo PHI com três nós: ques- tões, posições (respostas) e argumentos. Além disso, combina as perspectivas de comunicação e de argumentação promovendo a preservação de todas as formas de comunicação digital (ar- quivos de áudio, vídeo e e-mail, dentre outras) de forma a complementar documentações do rationale, sendo todas elas capturadas de forma hierárquica e ordenadas cronologicamente.
No intuito de fornecer suporte ao DR de artefatos de software, o DocRationale é orien- tado a processos possibilitando a manutenção de fases, atividades e artefatos de um projeto abrangendo todo o ciclo de desenvolvimento de software. Dessa forma, para cada projeto, diversos artefatos deveriam ser elaborados, de acordo com uma série de questões, posições e argumentos ou mesmo de outros arquivos de comunicação.
A ferramenta também possui funcionalidades de controle de acesso às informações possuindo quatro diferentes perfis de usuários: Administrador de Usuários, Administrador de Projetos, Membro do Projeto e Visitante.
3.5 INFORAT
Baseado na notação DRL, o InfoRat (Inference Over Rationale) é um sistema capaz de realizar inferências sobre DR de um determinado design, com o intuito de detectar inconsis- tências e estimar o impacto de mudanças (FIGUEIREDO, 2006).
A ferramenta foi desenvolvida para ser utilizada de forma integrada no ambiente de desenvolvimento Eclipse. Além disso, promove a visualização de uma ontologia de critérios a serem utilizados durante a avaliação e seleção das alternativas (FIGUEIREDO, 2006).
No entanto, a captura é realizada de forma manual e de forma separada do processo de design, agregando um custo elevado ao processo de software (NUNES e MEDEIROS, 2009).
3.6 SIBYL
O SYBIL é um sistema qualitativo de gerenciamento de decisão baseado em lingua- gem DRL. Esse sistema visa auxiliar seus usuários no gerenciamento e representação dos as- pectos qualitativos envolvidos no processo de tomada de decisão (MEDEIROS, 2006).
Nele, as tarefas de decisão são apoiadas através de gráficos de decisão, proporcionan- do a visualização das diferentes alternativas envolvidas e suas respectivas avaliações (ME- DEIROS, 2006).
Por ser dividido em duas partes (interface visual do usuário e conjunto de serviços), o SIBYL promove facilidade de manipulação pelo usuário e, ao mesmo tempo, gerenciamento de dependências, precedências e avaliações, apoiando a tomada de decisão baseada na quali- dade das informações (MEDEIROS, 2006).
3.7 SEURAT
Software Engineering Using RATionale – SEURAT foi desenvolvido com intuito de apoiar o uso de DR na manutenção de software. Proporciona uma visualização do rationale e possíveis inferências apontando questões não resolvidas ou inconsistentes resultantes de mo- dificações em software (MEDEIROS, 2006).
Esse sistema faz uso de uma representação baseada em DRL chamada RATSpeak, que promove a geração de uma ontologia de argumentos, promovendo uma hierarquia de argu- mentos comuns representando tipos de restrições que se aplicam em um software. A represen- tação então é realizada através de alternativas para cada problema, relacionadas a requisitos,
alternativas, restrições e suposições capazes do promover seu apoio ou rejeição (MEDEIROS, 2006).
O SEURAT é integrado com o ambiente de desenvolvimento Eclipse, proporcionando a captura e uso do rationale mais fácil, rápido e prático, tendo em vista que a captura, recupe- ração de um rationale é apresentada no mesmo ambiente que o usuário estará trabalhando (MEDEIROS, 2006).
3.8 ANALOGUS
Com o propósito de auxiliar o ensino de alunos iniciantes na área de desenvolvimento de software, foi desenvolvido um ambiente totalmente virtual que atua na resolução de pro- blemas de programação: o Analogus (SANTOS JUNIOR, 2009).
Para que este ambiente fosse capaz de sugerir problemas de programação similares ao atual, foi realizada a integração de um sistema baseado em casos chamado jColibri. Além disso, visando simular um professor virtual, foi associado à solução um mecanismo de agente inteligente de diálogo.
A partir do recebimento de um conjunto de informações sobre um problema de pro- gramação informado por um aluno, o sistema efetua a busca na base de casos por problemas já resolvidos e com características semelhantes ao novo problema. Esse conjunto de casos é então disponibilizado ao agente inteligente, que interage com o aluno apresentando aspectos semelhantes entre os casos.
O aluno, então, soluciona o novo problema, reutilizando os conhecimentos adquiridos por meio de situações passadas, apresentadas pelo agente. Por fim, um professor confere a resolução proposta pelo aluno e verifica a necessidade de ajustes, encaminhando-as ao aluno quando necessário. Um problema é considerado como resolvido, quando todas as considera- ções do professor são atendidas. Somente após essa sinalização de resolução que o problema é disponibilizado na base de casos para se consultado em futuras pesquisas.
No intuito de avaliar a assertividade da apresentação de problemas similares, foi reali- zado um experimento envolvendo 200 problemas de programação, extraídos de listas de exer- cícios de disciplinas de introdução à programação, obtidas na internet. Tais problemas foram divididos em dois grupos:
Conjunto de consulta: correspondendo a 25% do total dos problemas, esse grupo repre- senta os novos problemas a serem cadastrados no Analogus.
de casos, simbolizando problemas já resolvidos por alunos.
Os problemas retornados como sugestão de situações similares foram avaliados de forma subjetiva visando verificar o grau de semelhança entre estes e o novo problema.
O experimento também envolveu a análise comparativa de seis funções de similarida- de local, conforme apresentadas no Quadro 2. Porém, para a similaridade global foi utilizada a função do vizinho mais próximo.
Quadro 2: Funções de similaridade local avaliadas no Analogus
Função Enunciado Assuntos da Disciplina Padrões Complexidade Categoria
Cosine Similarity Dice’s Coefficient Overlap Coefficient Jaccard Coefficient Max String Equal
A partir de uma sequência de testes entre as funções de similaridade e diversos pesos, foi possível obter as seguintes conclusões:
Os resultados com maiores assertividades eram obtidos quando o peso do atributo as- sunto era consideravelmente maior do que os demais (assunto possuía peso 5, enquanto os demais atributos peso 1).
Embora a média das similaridades encontradas seja inferior a 70%, os valores de desvio padrão e coeficiente de variação são bem elevados, o que leva a conclusão de que as funções de similaridade adotadas não estão adequadas o suficiente para o domínio do problema.
Com os resultados obtidos, um novo ciclo de experimento foi realizado. Desta vez, foi utilizada uma função de pré-processamento para o atributo textual enunciado, o que possibili- tou a observação de uma melhora significativa na média das similaridades encontradas: supe- rando os 70%.
Após o ajuste das funções e pesos para as similaridades locais (Tabela 2), o Analogus foi experimentado por 10 estudantes do curso de Ciências da Computação da Universidade Federal de Campina Grande, com idade média de 19 anos e experiência em programação de 6 meses a 1 ano. A partir da avaliação dos problemas recuperados como similares e dos feed- backs dos participantes, foi possível a comprovação de que a representação do caso foi ade- quada para o domínio. No entanto, acredita-se que para a mensuração de resultados mais con- sistentes, faz-se necessária a aplicação do experimento em um número maior e mais variado de participantes, em um período de tempo mais extenso (durante alguns semestres).
Tabela 2: Funções e pesos de similaridade local adotadas no Analogus
Atributo Similaridade Local Peso Categoria do Problema Equal() 1.0
Complexidade Equal() 1.0 Enunciado do Problema CosineCoefficient() 1.0 Assuntos Tratados CosineCoefficient() 5.0 Padrões de Programação CosineCoefficient() 1.0
O Analogus, embora auxilie na tomada de decisão, não abrange mecanismos capazes de fazer o decisor obter, de forma automática, situações similares entre a decisão atual e casos anteriores.
3.9 ECOCADE E MODECOCA
O ECoCADe (Evidência, Contexto e Casos para Apoiar Decisão) é um framework conceitual para apoiar tomadas de decisão baseadas em evidências, contexto e casos, o qual possui dois objetivos gerais, os quais o contexto é sempre considerado (LOPES, 2010):
O apoio a projetos de elementos arquiteturais para um sistema híbrido sem SIG e SBC;
O auxílio a desenvolvedores na modelagem de evidências e na representação de casosjustificados por evidências em domínios de PBE.
O ModECoCa (Modelagem de Evidências com Contexto e representação de Casos) é um subframework do ECoCADe, uma instanciação desse modelo conceitual, que representa o ECoCADe posto em prática.
Abordagem metodológica desse subframework é um mix entre as atividades do ciclo básico de processamento de RBC com procedimentos da PBE, considerando a diversidade de contextos (ator do problema, geração de evidências e tomado de decisão), amparada pelo pro- cesso decisório de Simon (1987). Dessa forma, é construída baseada no conjunto de ativida- des decisórias encontradas nos domínios médico e jurídico, com flexibilidade de apoio a es- pecialistas de outras áreas.
Devido a crescente disponibilização de informações digitais, associada à casos com- plexos, o framework ECoCADe foi customizado para agir em um Subsistema de Penas Alter- nativas, dos Tribunais de Justiça Estadual de Pernambuco e Justiça Federal do Rio Grande do Norte, caracterizado pela interoperabilidade entre juízes no processo de tomada de decisão. O Subsistema de Penas Alternativas contempla o processo geral de tomada de decisão judicial, abrangendo as necessidades dos juízes que julgam os casos, dos participantes do fato jurídico (ofensor e vitima) e do assessor judiciário. Dessa forma, a solução abrange:
O entendimento do fato jurídico: fase de inteligência, responsável por identificar o pro- blema e seu autor, coletando os dados do caso, tais como dados do ofensor, da vitima, circunstâncias do fato, dentre outras;
A busca de fatos jurídicos similares: responsável pela apresentação de casos anterior- mente resolvidos e similares ao atual, com objetivo de apoiar o julgamento;
A Busca por instituições: responsável pela sugestão de instituições adequadas para o cumprimento das penas alternativas, de acordo com o perfil do ofensor;
A pesquisa e avaliação de evidências: utilizada quando for necessário aplicar evidências utilizadas na organização;
A realização de julgamento: corresponde ao julgamento propriamente dito do caso, fa- zendo uso de todas as informações e sugestões oferecidas pelo sistema;
Designar atividade ou instituição: relacionado a escolha da pena alternativa cabível ao caso;
Avaliação: utilizado para registrar a análise de resultados da aplicação da pena e das de- cisões efetuadas no processo decisório.
O sistema ainda oferece opções para tratamento de situações as quais se caracterizam descumprimentos ou mesmo a suspensão de pena.
Para que fosse possível a obtenção de casos jurídicos semelhantes, foram definidas as seguintes funções para similaridade local (Quadro 3).
Quadro 3: Funções de similaridade local adotadas no ECoCADe
Atributo Similaridade Local
Descrição do Fato Coeficiente de Jaccard Nome Cosine Similarity Bairro Residencial Distância Euclidiana Bairro de Trabalho Distância Euclidiana Habilidades Distância Euclidiana Já a similaridade global é obtida através da seguinte função:
(6) Para a avaliação do framework, foram utilizados três tipos de casos, cada um com um grau de complexidade distinto e, ao final foi submetido a um teste de aceitação junto aos seus usuários.
positiva em seu domínio de aplicação, porém, alguns pontos de melhoria foram identificados: (i) inclusão de arquivos de mídias (som, imagem e vídeo) visando apoiar a fase de inteligên- cia; (ii) desenvolvimento de ferramenta de extração automática ou semiautomática de infor- mações de documentos; (iii) criação de procedimentos para tratamento de excepcionalidades, no caso de casos sem sugestões; (iv) criação de mecanismo que possibilite a tomada de deci- são em grupo.
4 METODOLOGIA
4.1 CLASSIFICAÇÃO DA PESQUISA
Este trabalho se fundamenta em um levantamento envolvendo a interrogação direta de um grupo específico de especialistas. Além disso, pode ser considerada uma pesquisa partici- pante, na qual existe a interação entre os pesquisadores e os membros das situações investiga- das.
Quanto à forma da pesquisa, diante da impossibilidade de realizar a investigação e compreensão por meio de dados estatísticos, a mesma classifica-se como qualitativa na qual a relação entre a situação proposta e o universo compreendido será estudada, baseando-se em fenômenos voltados para a percepção, intuição e subjetividade. Por se tratar de um estudo voltado ao aprimoramento de ideias ou de descobertas de intuições, a pesquisa pode ser classi- ficada quanto aos fins como exploratória e quanto aos meios como um estudo de caso, já que o objeto de estudo estará realçando a relação entre a representação de conhecimento com os seus consumidores ou mesmo geradores.
4.2 PRESSUPOSTOS
Esta pesquisa parte dos seguintes pressupostos: (i) a preservação de todas as decisões envolvidas durante o desenvolvimento de um projeto aumenta as suas chances de sucesso, além de servirem de auxílio para novos projetos; (ii) uma tomada de decisão pode ser reutili- zada em casos semelhantes, proporcionando celeridade na execução de uma atividade; (iii) Escolhas previamente realizadas e avaliadas podem contribuir para o aumento de maturidade de uma nova decisão; (iv) alternativas descartadas em soluções anteriores podem auxiliar a