SISTEMA DE ESTIMATIVA DE DESENVOLVIMENTO DE SOFTWARES BASEADO EM CASOS 1

Transcrição

1 SISTEMA DE ESTIMATIVA DE DESENVOLVIMENTO DE SOFTWARES BASEADO EM CASOS 1 Helene Carrer <helenecarrer@gmail.com> Fabiana Lorenzi <fabilorenzi@gmail.com> Orientador Universidade Luterana do Brasil (ULBRA) Curso de Ciência da Computação Câmpus Canoas Av. Farroupilha, Bairro São José CEP Canoas - RS RESUMO 29 de novembro de 2010 Este artigo apresenta o desenvolvimento de um sistema de estimativa de desenvolvimento de softwares baseado em casos. Para estimar o tempo de desenvolvimento de um software serão utilizadas algumas técnicas de estimativa existentes no mercado hoje, ajustando-as a necessidade da empresa. Através da utilização da abordagem de Raciocínio Baseado em Casos, o sistema possibilitará minimizar o equívoco do tempo estimado atualmente na alocação de desenvolvedores para realização de tarefas bem como, auxiliar para que o prazo de entrega das atividades seja respeitado. Palavras-chave: Raciocínio Baseado em Casos; Técnicas de Estimativa; Desenvolvimento de Softwares. ABSTRACT Title: Estimated System Software Development case-based. This article presents the development of a system for estimating software development case-based. To estimate the development time of software will be used some techniques to estimate the market today, with adaptation to the needs of the company. By using the approach of Case Based Reasoning, the system will allow minimize the misunderstanding of the time currently estimated in the allocation of developers to perform tasks as well as to assist the delivery of activities be respected. Key-words: Case-based Reasoning; techniques to estimate; software development. 1 INTRODUÇÃO O setor de tecnologia da informação brasileiro vive um bom momento, o mercado de TI encerrou 2009 com crescimento de 9,3% e uma receita anual aproximada de R$ 52,8 bilhões (Softex, 2010). Na área de serviços de TI, o período também é promissor, conforme dados da IDC Brasil, a expectativa de crescimento em 2010 é de 5,1%, o que representa um mercado de aproximadamente R$ 19,4 bilhões. Nos primórdios da computação, onde esse crescimento de serviços de TI não era tão expressivo, os custos do software compreendiam uma pequena porcentagem do custo global do projeto. Um erro de uma ordem de magnitude nas estimativas de custo do software tinha relativamente pouco impacto. Atualmente, grandes erros de estimativa de custos podem fazer a diferença entre lucro e prejuízo. Custos excedentes podem ser desastrosos para o projeto. (Pressman, 2006). A estimativa de tempo e custo de desenvolvimento é uma atividade que exige atenção e que exerce grande influência no processo de desenvolvimento de software. Principalmente para instituições e organizações privadas, a realização de uma estimativa correta e precisa é fundamental para a sobrevivência e para a viabilidade das atividades da organização (Monteiro 2004, Pereira et. al 2005). Atualmente uma fábrica de Softwares, que servirá de modelo para este trabalho, recebe solicitações de recursos de desenvolvimento de tarefas dos setores de análise de sistemas da empresa. Desta forma os desenvolvedores trabalham em vários projetos diferentes ao mesmo tempo. Esses projetos geralmente são grandes, complexos e inovadores, e entregá-los no prazo estipulado pelo cliente nem sempre é possível. O grande problema existente hoje nos prazos de entrega das atividades nesta fábrica de Softwares se deve à estimativa realizada pelo setor de análise referente ao tempo de desenvolvimento da tarefa. Essa estimativa não leva em consideração a complexidade do que está sendo desenvolvido, não existindo também uma base histórica de atividades similares já desenvolvidas. 1 Artigo Final da disciplina de Trabalho de Conclusão de Curso em Ciência da Computação II, submetido ao Curso de Ciência da Computação da Universidade Luterana do Brasil, Câmpus Canoas; 1

2 Assim, a grande maioria das atividades recebe um tempo de desenvolvimento muito curto, ou são alocadas para profissionais que não estão de acordo com a experiência necessária para o desenvolvimento de tal tarefa. Quando é alocado um desenvolvedor com pouca experiência para atividades complexas, com certeza o tempo de desenvolvimento dessa tarefa será maior, e a sua qualidade pode estar comprometida. Como consequência disso o prazo de entrega das tarefas sofre um consecutivo replanejamento de datas. Baseado nessa realidade, onde se faz necessária uma forma de estimar o tempo de desenvolvimento de uma tarefa, propõe-se a utilização da abordagem de Raciocínio Baseado em Casos. O sistema prevê a utilização de tempos utilizados em antigas tarefas para novas tarefas. Com isto, o sistema será capaz de estimar o prazo adequado para o desenvolvimento e minimizar os futuros problemas relacionados ao prazo de entrega da tarefa. 2 FUNDAMENTAÇÃO TEÓRICA Esta seção tratará a abordagem da Inteligência Artificial (IA) chamada de o Raciocínio Baseado em Casos (RBC) e a Estimativa de Desenvolvimento de Softwares como referências para solucionar o problema de estimar o tempo de um desenvolvimento em uma fábrica de software. 2.1 Raciocínio Baseado em Casos O Raciocínio Baseado em Casos (RBC) surgiu em 1977, em uma pesquisa desenvolvida por Schank e Abelson com o desejo de compreender como as pessoas conseguem recuperar informações e que as mesmas, frequentemente, resolvem problemas lembrando-se de como solucionaram casos similares no passado (Anita Maria da Rocha Fernandes, 2003). Neste trabalho, os autores afirmam que o conhecimento é armazenado através de scripts. Estes scripts descrevem informações sobre situações que ocorrem com seres humanos, por exemplo, ir a um museu, jantar, almoçar. Porém, experimentos com fatos mostraram que somente os scripts não representavam todo o conhecimento armazenado na memória. Era comum pessoas misturarem fatos parecidos, como consulta médica e consulta dentária, no momento da recuperação da informação (Schank apud Beppler, 2001). RBC é um enfoque para a solução de problemas e para o aprendizado baseado em experiência passada. Através desta abordagem é possível resolver problemas ao recuperar e adaptar experiências passadas, chamadas casos, armazenadas em uma base de casos. Um novo problema pode ser resolvido com base na adaptação de soluções de problemas similares já conhecidos. (Wangenhein, 2003, p.8). O Ciclo de funcionamento de um sistema de RBC, engloba um ciclo de raciocínio contínuo composto por quatro tarefas principais (Aamodt e Plaza, 1994) que são elas: recuperação, reutilização, revisão e retenção dos casos. A Figura 1 ilustra o ciclo de funcionamento de um sistema de RBC e suas quatro tarefas. No centro do ciclo está o conjunto de casos representando as experiências armazenadas. Estas experiências serão recuperadas na busca da similaridade com o problema atual e serão reutilizadas realizando adaptações, caso necessário. Após sua retenção na base de casos o problema resolvido representará uma nova experiência armazenada. Figura 1 - O Ciclo de RBC (Aamodt e Plaza, 1994). 2

3 Primeiramente, antes do desenvolvimento das etapas do RBC é imprescindível a realização da aquisição do conhecimento, onde serão obtidas todas as informações do problema a ser resolvido com o especialista no assunto Aquisição do Conhecimento Nesta etapa é extraído o máximo de conhecimento do especialista no problema. O especialista é alguém que conhece o problema a ser resolvido e será capaz de transmitir esse conhecimento. A aquisição do conhecimento é desenvolvida em seis etapas: a identificação e estudo do problema, entrevistas com o especialista, análise do conhecimento, proposta de representação de conhecimento, implementação e teste do sistema e validação e teste junto ao especialista. O engenheiro do conhecimento exerce a função de extrair o máximo de conhecimento do especialista para efetuar uma tarefa no seu domínio. Através deste conhecimento, será possível que o engenheiro obtenha todas as informações necessárias para representação de um caso. A forma mais utilizada para a aquisição do conhecimento é a entrevista com o especialista que será dividida em duas etapas: Entrevista não estruturada: quando as informações são obtidas através de conversa com o especialista diretamente. Ele apresenta livremente o problema e a forma como ele é resolvido atualmente. Entrevista estruturada: nesta etapa o engenheiro do conhecimento analisa as informações obtidas da entrevista não estruturada e então determina quais informações são úteis para serem exploradas e o engenheiro do conhecimento utiliza técnicas para obter informações específicas Representação dos Casos Um caso é uma peça de conhecimento contextualizado representando uma experiência ou episódio concreto. Contém a lição passada, que é o conteúdo do caso e o contexto em que a lição pode ser usada. (Wangenhein, 2003, p.63). Ele é composto tipicamente dos seguintes componentes principais: Problema: que descreve o estado em que o problema ocorreu; Solução: que postula a solução derivada para aquele problema; Para que um caso seja representado é necessário definir os atributos que o caracterizam. Atributos da situação do problema e relacionamentos entre essas suas partes. No geral, na descrição de um problema deve ser incluída toda a informação explicitamente considerada ao se adquirir o seu objetivo específico Indexação dos Casos Os sistemas de RBC possuem a habilidade de recuperar casos relevantes da base de casos de maneira eficiente. Para que isto seja feito é necessário saber como a base de casos deve ser indexada, para que o processo de recuperação seja mais preciso e eficiente (LORENZI, 2007). Os índices de um caso são combinações de seus atributos mais importantes, que permitem distinguilos de outros e identificar casos úteis para uma dada descrição de problema. Existem vários métodos de indexação, manuais e automáticos, que identificam as Entidades de Informação (EI) relevantes Recuperação dos Casos O objetivo da recuperação é encontrar um caso ou um pequeno conjunto de casos na base de casos que contenha uma solução útil para o problema ou situação atual. Os sistemas de RBC possuem a habilidade de recuperar casos relevantes da base de casos de maneira eficiente. Para que isto seja feito é necessário saber como a base de casos deve ser indexada, para que o processo de recuperação seja mais preciso e eficiente (LORENZI, 2007). A recuperação de casos é feita usando as características do novo caso que são relevantes na solução 3

4 de um problema. A tarefa inicia com a descrição de um problema e termina quando o caso mais similar é encontrado. Três tipos de recuperação principais têm sido aplicados. São eles (LORENZI, 2007): Vizinho mais próximo: combina casos recuperados com base no somatório de pesos das características do novo problema. Os casos com o total de comparações com alguma similaridade métrica são retornados do processo de comparação. Método de recuperação Indutivo: torna-se o melhor método quando a meta da recuperação é bem definida. Casos são indexados com base nas características mais importantes. A árvore resultante provê tempos de recuperação mais rápidos do que o método de recuperação do vizinho mais próximo. Recuperação baseada em Conhecimento: aplica o conhecimento do domínio para localizar casos relevantes. Esta abordagem é semelhante a sistemas especialistas baseados em regras, nos quais um especialista determina as características usadas para classificar os casos. O conhecimento não precisa ser completo Reutilização dos Casos Uma vez que um caso adequado é recuperado da base de casos, a solução sugerida por este caso é objetivo de uma tentativa de reutilização para a solução do problema atual. A reutilização consiste principalmente na adaptação da solução do caso anterior ao caso atual, e as técnicas tratadas na reutilização de casos tentam resolver os problemas envolvidos na adaptação de casos, que são: quais aspectos da situação devem ser adaptados, quais modificações devem ser realizadas para esta adaptação, que método aplicar para realizar a adaptação e como controlar este processo Revisão dos Casos Quando uma solução para um caso gerada na fase de reutilização não é totalmente apropriada para o problema em questão, a etapa de revisão dos casos apresenta a oportunidade de adaptação da solução proposta. Esta etapa de revisão dos casos consiste de duas tarefas (Wangenhein, 2003, p.207): Avaliação da solução do caso gerada pela reutilização (adaptação): A avaliação da tarefa utiliza o resultado da aplicação da solução no ambiente real. O resultado da aplicação da solução pode levar algum tempo para surgir, dependendo do tipo da aplicação. O caso pode ainda ser aprendido e estar disponível na base de casos no período intermediário, mas ele deve ser marcado como não avaliado. A solução pode também ser aplicada em um programa de simulação apto a gerar a solução correta. Reparo da solução do caso usando conhecimento de domínio específico: Este processo envolve detectar erros da solução atual e recuperar ou gerar explicações de porque os erros aconteceram, para que as falhas não ocorram mais Retenção dos Casos A etapa de retenção dos casos é o processo de incorporação ao conhecimento já existente, daquilo que é útil de um novo episódio de solução de um problema. O objetivo de se reter continuamente conhecimento toda vez que um novo problema é resolvido é o de constantemente atualizar e estender a base de casos, tornando o sistema de RBC mais poderoso com o passar do tempo e de sua utilização. O processo de retenção é refinado em duas fases: 1) A base de casos é atualizada não importando de que maneira o problema foi resolvido. Se ele foi resolvido através do uso de um caso anterior, um novo caso deve ser construído. Se o problema foi resolvido com a intervenção do especialista, o novo caso adaptado deverá ser construído. 2) Integração de Casos: Esta é a etapa final da atualização da base de conhecimento com a obtenção de um novo caso. Com a modificação da indexação de casos existentes, por exemplo, sistemas de RBC podem aprender a se tornarem melhores na utilização deste caso para a solução de novo problema. 4

5 2.2 Estimativas de desenvolvimento de softwares. Uma das atividades fundamentais do processo de gerenciamento de projetos de softwares é o planejamento. Quando o projeto de softwares é planejado, estimativas do esforço humano exigido, duração cronológica do projeto e custo devem ser derivadas. As estimativas de custo e de esforço de software jamais serão uma ciência exata. Muitas variáveis humanas, técnicas, ambientais e políticas podem afetar o custo final do software e do esforço aplicado para desenvolvê-lo. Entretanto, as estimativas de projetos de softwares podem ser transformadas de magia negra em uma série de passos sistemáticos que oferecem estimativas com riscos aceitáveis. (Pressman, 2006). Em muitos casos, estimativas são feitas utilizando-se a experiência passada como único guia. Se uma nova tarefa de desenvolvimento de software for muito semelhante, em termos de tamanho e função a uma tarefa passada, provavelmente essa nova tarefa exigirá aproximadamente a mesma quantidade de esforço, tomará o mesmo tempo de calendário e custará o mesmo valor que o trabalho mais antigo. Essa técnica de utilização de experiências passadas para solução de problemas atuais é solucionada utilizando o RBC, visto na seção anterior. Existem casos onde o desenvolvimento rompe novos horizontes, não permitindo assim que o RBC seja a única fonte de estimava para determinar o esforço de uma atividade. Podem ocorrer casos em que é solicitado o desenvolvimento de uma aplicação inovadora, onde serão utilizadas novas metodologias de desenvolvimento e até mesmo uma mudança de linguagem de programação. Para isso existe uma série de técnicas de estimativa existentes hoje, com seus potenciais e fragilidades para auxiliar no momento da estimativa de desenvolvimento Técnicas de Estimativa de Desenvolvimento de Softwares. Existem várias técnicas de estimativas de tamanho de software, e a seguir serão apresentadas, de forma resumida, as mais utilizadas hoje: COCOMO (Constructive Cost Model): Segundo Boehm(2000), COCOMO é um método que busca medir esforço, prazo, tamanho de equipe e custo necessário para o desenvolvimento do software. Utilizando as equações desenvolvidas pelo autor para prever o número de programadores-mês e o tempo de desenvolvimento; podem ser calculados usando medidas de linhas de código ou Pontos de Função. Devem ser realizados ajustes nas equações a fim de representar as influências sobre os atributos, hardware e software durante o ciclo de vida do projeto. Uma desvantagem desta técnica é que os coeficientes da métrica (a,b,c,d) não são aplicáveis a tamanho ou seja a produtividade é diferente, o que torna difícil realizar comparações. Linhas de Código (LOC): A técnica de mensuração por linhas de código é uma das mais antigas medidas de tamanho de projeto de desenvolvimento de software. Ela consiste na contagem da quantidade de número de linhas de código de um programa de software. Além de ser muito simples é também muito fácil automatizar sua implementação, mas, apresenta algumas desvantagens: a dependência da linguagem de software e do desenvolvedor; ausência de padrão de contagem e o fato de somente poder ser aplicada após a fase de codificação (PRESSMAN,2006). Modelo de Putman: É um modelo de estimativa que busca medir esforço e prazo através da dinâmica de múltiplas variáveis que pressupõe distribuição de esforços específicos ao longo da existência de um projeto de software. Relaciona o número de linhas de código ao tempo e esforço de desenvolvimento. Uma desvantagem da técnica é sua vinculação a linguagem usada e a exigência de certo tempo para obterem-se valores reais para os parâmetros da fórmula. (PRESSMAN,2006). Pontos por Caso de Uso (PCU): Os Pontos de Casos de Uso (PCU) foram criados em 1993 por Gustav Karner da empresa Objectory AB. Esta métrica permite fazer estimativas no início do projeto com base no modelo de casos de uso. A filosofia dos Pontos de Casos de Uso é baseada na definição da Análise de Pontos por Função (APF), na qual a funcionalidade vista pelo 5

6 usuário é a base para a estimativa do tamanho do software (BELGAMO apud Heimberg e Grahl, 2005). Análise por Pontos de Função (APF): é uma técnica para a medição de projetos de desenvolvimento de software. Primeiro tornado público por Allan Albrecht da IBM em 1979, a técnica APF quantifica as funções contidas no software em termos que sejam significativos para os usuários do software. A medida está diretamente relacionada com os requisitos de negócio que o software se destina a tratar. Como consequência, pode ser facilmente aplicada através de uma ampla gama de ambientes de desenvolvimento e durante toda a vida de um projeto de desenvolvimento, dos requisitos iniciais para a definição completa da utilização operacional. Outras medidas, tais como a produtividade do processo de desenvolvimento e o custo por unidade de apoio ao software, também podem ser facilmente derivadas (IFPUG,2010). 2.3 Trabalhos Relacionados Abaixo seguem alguns artigos que mostram a utilização do RBC como solução para problemas relacionados a projetos de softwares e artigos que demonstram a utilização de técnicas de estimativas para projetos. No trabalho apresentado por Leandro Borba de Souza (Souza, 2007), o autor utiliza a abordagem de RBC para a construção de um protótipo de ferramenta que indica possíveis riscos a serem considerados em um novo projeto baseando-se em casos (projetos já executados e seus respectivos riscos). A abordagem de RBC utilizada como solução do problema neste artigo parece bastante viável, a desvantagem de sua utilização para o gerenciamento de riscos se dá no caso de surgirem novos riscos, onde deve ser definido um limiar de similaridade, indicando o quanto um caso é similar ao outro. A dificuldade existente na utilização de limiares se dá no momento de definir quais serão os limiares ideais na recuperação dos casos. No artigo apresentado por Roberto Pereira (PEREIRA, 2007), o autor propõe a utilização da técnica de estimativas de Pontos por Caso de Uso, e sua inserção dentro do processo de desenvolvimento de uma organização que busca alcançar o nível 2 do CMM (Capability Maturity Model). Porém, assim como relatado pelo autor, a técnica de Pontos por Caso de Uso deve ser aplicada somente se a empresa utiliza o Caso de Uso como forma de expressão de requisitos, caso contrário, se torna inviável. A vantagem de sua utilização associada ao RBC é a geração de estimativas mais precisas e seguras. Já no artigo apresentado por José Daltro Martins Junior (JUNIOR, 2010), o autor propõe a utilização de RBC para tomada de decisão na contratação e desenvolvimento de projetos web e utiliza o algoritmo do vizinho mais próximo para recuperação de novos casos. O sistema proposto não utiliza na sua metodologia o ciclo de RBC de forma completa, faltando a revisão, onde os casos são adaptados à nova realidade e a retenção dos casos, que se trata do armazenamento dos novos casos na base. 3 DESENVOLVIMENTO DO SISTEMA A metodologia utilizada neste trabalho englobou as quatro tarefas do Ciclo de Funcionamento de um sistema de RBC, que são elas: a recuperação, reutilização, revisão e retenção dos casos. 3.1 Aquisição do Conhecimento A aquisição do conhecimento foi realizada através de entrevistas não estruturadas e estruturadas com o especialista no assunto, que é o coordenador da fábrica de software Entrevista não estruturada As informações foram obtidas através de uma conversa aberta com o coordenador da fábrica de software, cuja função principal é receber as solicitações de recurso para desenvolvimento de tarefas do setor de análise, a alocação dos profissionais e o controle das datas das tarefas em desenvolvimento. Durante a conversa foi relatado o processo atual de desenvolvimento utilizado pela empresa e o funcionamento do seu ciclo. Foram discutidas questões sobre o modelo de estimativa utilizado hoje na alocação de desenvolvedores e os seus principais problemas. Durante o relato, o especialista ressaltou a dificuldade existente hoje em acertar o tempo real de desenvolvimento de uma tarefa no momento da alocação. A estimativa existente hoje, que é adquirida pelo setor de análise, muitas vezes não condiz com o tempo necessário para o desenvolvimento da tarefa. Durante 6

7 o relato também foi abordado sobre as técnicas de estimativas existentes no mercado hoje. Muitas metodologias existentes hoje são difíceis de serem implantadas em uma fábrica de software devido à alocação não ser realizada para projetos de software como um todo, e sim as distintas tarefas que o compõem. Desta forma não seria possível se ter uma visão geral sobre as regras, casos de uso, e itens de contagem utilizados hoje em projetos. Com essa dificuldade a estimativa se torna limitada. Outro relato importante obtido durante a entrevista foi quanto ao processo atual de estimativa realizado pelo setor de análise não levar em consideração no momento da alocação à diferença de níveis de experiência existentes hoje entre os desenvolvedores, gerando assim prazos pequenos para desenvolvedores Júnior Entrevista estruturada Tendo em mãos a entrevista não estruturada, as informações foram analisadas para identificar e organizar os principais problemas descritos pelo especialista na busca de possíveis soluções. Foi apresentada ao especialista a proposta do RBC como solução do problema e a união de algumas técnicas de estimativa existentes no mercado hoje a fim de identificar os itens que farão parte da base de casos. Esta etapa de entrevista estruturada permitiu que fossem identificados os itens mais relevantes que serão utilizados na recuperação dos casos e foi possível obter situações que servirão como base histórica para o inicio deste trabalho. 3.2 Representação dos Casos Um caso é composto pela descrição do problema, que descreve o estado do mundo quando o caso ocorreu e da descrição da solução, que postula a solução derivada para aquele problema. No sistema proposto um caso foi representado por uma tarefa anteriormente desenvolvida, suas características relevantes e o seu tempo real de trabalho. Para compor o problema a ser resolvido foram analisados somente os atributos que são possíveis de mensurar antes do desenvolvimento e toda a informação explícita, características e propriedades, cuja quantificação fosse relevante para representação e posterior recuperação do caso. Para definição dos atributos do problema, foram utilizadas algumas técnicas de estimativa por Pontos de Função e Pontos por Casos de Uso. A Tabela 1 apresenta os atributos que representam a descrição do problema a ser resolvido, os tipos de dados e valores para cada atributo, bem como o atributo que representa a solução do problema. Tabela 1: Atributos de representação do caso. Atributos do Problema Tipo de Dado Valores Peso Número de Regras do Caso de Uso Inteiro [0 N] 3 Número de Entradas Inteiro [0 N] 2 Número de Saídas Inteiro [0 N] 2 Quantidade de Tabelas Envolvidas Inteiro [0 N] 4 Número de Códigos-Fonte alterados Inteiro [0 N] 4 Quantidade de Aplicações Inteiro [0 N] 3 Atributo de Solução Tipo de Dado Valores Tempo Inteiro [0 N] - 7

8 O atributo Número de Regras do Caso de Uso trata das regras contidas na documentação de Caso de Uso elaborado pelos analistas de negócios. Este atributo possibilitou obter a informação dos requisitos e regras na visão do usuário do sistema sobre a tarefa. Para os atributos Número de Entradas e Número de Saídas foram enumerados todos os dados de entrada e saída alterados pelas telas da tarefa. Todas as tecnologias e classificações trabalham com este atributo. O atributo Número de tabelas envolvidas obteve todas as tabelas do banco de dados que sofreram inclusão, alteração ou deleção de valores durante o desenvolvimento. Esta informação estará contida no Modelo Entidade Relacionamento (Modelo ER), que será fornecido pelo setor de análise. Da mesma maneira, o atributo Número de Códigos-Fonte alterados e Quantidade de Aplicações contêm o número de códigos fontes que foram modificados ou incluídos pela tarefa, e a quantidade de aplicações que a tarefa está trabalhando. 3.3 Geração da base de casos Inicialmente, a base de casos do sistema foi gerada obtendo os atributos de tarefas desenvolvidas anteriormente pela fábrica de software. Buscaram-se os reais valores dos atributos, que já foram obtidos na etapa de representação dos casos, para cada tarefa e armazenados no sistema. O tempo real utilizado para o desenvolvimento das tarefas no passado foi expresso como a solução para aquele problema na época. Através da população da base de casos foi possível inflá-la ao máximo, para garantir que todo problema informado no sistema possua na base de casos uma solução suficientemente similar. 3.4 Indexação dos casos Na etapa de indexação do sistema, foram utilizados índices em conjunto, que identificaram o objeto a ser recuperado. As informações Tecnologia e Classificação atuaram como itens eliminatórios na etapa de recuperação dos casos. O índice Tecnologia contém todas as tecnologias de desenvolvimento que a fábrica de software trabalha atualmente. Todas as solicitações recebidas do setor de análise devem respeitar as limitações de cada tecnologia, a fim de optar pela mais apropriada para tal tarefa. São elas: Java: utilizada para manter aplicações internas e externas da empresa e processos internos. PowerBuilder: a tecnologia é utilizada para aplicações internas e processos que realizam operações para os clientes. ColdFusion: mantém todos os sistemas externos de acesso dos clientes. SQL: linguagem utilizada para desenvolvimento de Triggers e Stored Procedures no banco de dados Sybase e Oracle. Já o índice Classificação recebeu a funcionalidade da tarefa, que é definida pelos itens: Tela: Fazem parte desta classificação todas as tarefas que realizarem modificações ou inovações em telas do sistema. Esta classificação foi utilizada para as Tecnologias Java, PowerBuilder e ColdFusion. Processamento: Nesta classificação se enquadram tarefas de processamento (Java e PowerBuilder), e tarefas de alteração diretamente no banco de dados, Tecnologia SQL, podendo ser Triggers e Stored Procedures. Relatório: Já nesta classificação se enquadram tarefas especificas de relatórios. Hoje todas as quatro tecnologias trabalham com a geração de relatórios. Nas tecnologias Java, ColdFusion e PowerBuilder esses relatórios podem ser apresentados nas telas do sistema, já para a tecnologia SQL, foi utilizada essa classificação somente se tratando de uma Stored Procedure que tem como funcionalidade principal a geração de um relatório. A Tabela 2 apresenta a união dos índices Tecnologia e Classificação nas suas possíveis combinações. 8

9 Tabela 2 Funcionamento dos índices do sistema. Tecnologia Classificação Funcionalidade Java Power Builder ColdFusion SQL Tela Processamento Relatório Tela Processamento Relatório Tela Relatório Processamento Relatório Qualquer inclusão ou alteração realizada em uma das telas de sistemas da Linguagem Java. Processos ExecuteJob realizados pelas aplicações Java. Inclusões ou alterações realizadas nos relatórios gerados pelas aplicações Java. Qualquer inclusão ou alteração realizada em uma das telas dos sistemas da Linguagem PowerBuilder. Processos realizados pelos operadores PowerBuilder. Inclusões ou alterações realizadas nos relatórios gerados pelas aplicações PowerBuilder. Qualquer inclusão ou alteração realizada em uma das telas dos sistemas ColdFusion. Inclusões ou alterações realizadas nos relatórios gerados pelas aplicações ColdFusion. Stored Procedures que realizam alterações nos dados do sistema ou Triggers que contenham regras de negócio. Stored Procedures que geram relatórios que serão utilizados nos sistemas. 3.5 Recuperação dos casos A etapa de recuperação de casos inicia com uma descrição do problema e finaliza quando um melhor caso for encontrado. Para isso o sistema procura na base de casos o caso mais parecido com o novo problema. Para julgar qual caso armazenado na base é parecido ou igual ao novo problema é preciso medir a similaridade entre eles. A cada inclusão de nova estimativa no sistema, preenchendo os atributos definidos na representação do caso, foi buscado na base de dados uma solução em uma tarefa similar ao problema atual. Como nem sempre é possível encontrar desenvolvimentos de tarefas com atributos idênticos à tarefa atual, foi utilizada a metodologia do vizinho mais próximo, para a recuperação dos casos similares. O algoritmo do vizinho mais próximo, que utiliza a distância euclidiana ponderada, está representado na Figura 2, onde sim é a função de similaridade e w é o peso de cada atributo definido. Distância ( x, c) wf * sim( x f, c f Figura 2 Fórmula de similaridade do vizinho mais próximo (Michie apud Lorenzi, 1998). A metodologia do vizinho mais próximo consiste em calcular o módulo da distância ponderada entre cada atributo do novo caso e do caso recuperado. Para isso deve-se considerar a importância de cada item, definindo um peso maior para os itens mais importantes a serem recuperados. Através desta metodologia os atributos Número de Regras do Caso de Uso, Número de Entradas, Número de Saídas, Quantidade de Tabelas Envolvidas, Número de códigos-fonte alterados e Quantidade de Aplicações foram definidos por grau de importância através da fórmula representada na Figura 2. A partir daí, foi utilizado o vizinho mais próximo para recuperação dos demais atributos. A Figura 3 representa os casos recuperados pelo sistema, e o problema a ser solucionado. Baseado na definição de pesos e na metodologia aplicada, o cálculo de distância ponderada para os casos representados na Figura 3, ficariam da seguinte forma: Distancia (Caso 1, Novo Caso) = ((3* 3-4 ) 2 + (2* 2-2 ) 2 + (2* 1-1 ) 2 + (4* 4-5 ) 2 + (4* 1-1 ) 2 + (3* 2-1 ) 2 ) ½ Distancia (Caso 2, Novo Caso) = ((3* 8-4 ) 2 + (2* 3-2 ) 2 + (2* 4-1 ) 2 + (4* 3-5 ) 2 + (4* 2-1 ) 2 + (3* 3-1 ) 2 ) ½ 2 ) 9

10 Distancia (Caso 1, Novo Caso) = ( ) ½ = 34 = 5,83. Distancia (Caso 2, Novo Caso) = ( ) ½ = 300 = 17,42. Conclui-se através da aplicação da fórmula que o melhor caso para representar o problema atual é o Caso 1, pois representou a menor distância euclidiana ponderada. Figura 3 - Comparação de casos, representando a busca da solução para o problema atual. 3.6 Reutilização dos casos Uma vez que um caso é recuperado da base de casos, as soluções sugeridas pelo sistema são objetos de uma tentativa de reutilização para a solução do problema atual. Os casos recuperados pelo sistema podem requerer adaptações às necessidades do problema atual para assim serem reutilizados. Como estratégia para realizar a adaptação dos casos, adotou-se uma solução de contorno, inflando ao máximo a base de casos para garantir que toda nova tarefa de desenvolvimento recebida possua na base de casos outra tarefa que seja suficientemente similar a atual, de maneira que não necessite ser adaptada. Para situações em que mesmo com casos similares na base, as soluções apresentadas pelo sistema não se adequarem com o problema atual, foi utilizada a filosofia de interação com o usuário. Para esta filosofia de interação com o usuário, o sistema sugere um conjunto de soluções potenciais e a navegação sobre estas soluções, de maneira a permitir que o especialista, que neste caso é o coordenador da fábrica de software, explore as respostas sobre todos os aspectos e reutilizar a solução mais adequada no seu ponto de vista, modificando manualmente uma solução, se considerar necessário. 3.7 Revisão dos casos Após a recuperação dos casos ser realizada pelo sistema, o especialista tem a oportunidade de avaliar as soluções propostas. Estas soluções nem sempre estarão totalmente similares ao problema atual, por este 10

11 motivo o especialista, que domina o contexto do problema, tem a possibilidade de adaptar esta solução. A revisão possibilitará ao sistema um aprendizado cada vez maior as novas situações encontradas. A revisão dos casos foi realizada através da interação do especialista, que é o coordenador da fábrica de softwares. Ele avalia a solução proposta, caso a solução não seja apropriada, ele ajusta este valor para torná-lo viável ao problema atual. 3.8 Retenção dos casos A retenção dos casos foi realizada no sistema utilizando a extração e a indexação do novo caso. A solução encontrada para o problema é armazenada na base de casos. Quando o problema foi resolvido através das soluções propostas, ou adaptado pela intervenção do especialista, deve ser incluído um novo registro na base de casos representando essa solução. Ao acrescentar uma nova solução na base de casos, ela é indexada pela sua Tecnologia e Classificação, conforme detalhado na seção de Indexação de Casos. Através desta indexação, o caso armazenado pode ser indicado como uma possível solução para problemas futuros. 4 IMPLEMENTAÇÃO DO SISTEMA Para o desenvolvimento deste sistema foi utilizada a linguagem de programação C# integrante do framework.net Microsoft. A estrutura de banco de dados deste sistema, que armazena todas as tarefas já desenvolvidas e futuras tarefas, foi implementada utilizando SQL Server Contact Edition. O sistema foi desenvolvido visando sua utilização por dois perfis diferentes de usuários: o usuário especialista e o usuário comum. Cada módulo de utilização tem suas permissões de acesso a determinados menus e funcionalidades do sistema, de acordo com a sua real necessidade. 4.1 Módulo Especialista O perfil especialista foi designado ao coordenador da fábrica de software, que é o principal conhecedor da técnica utilizada pelo sistema e o responsável por manter os seus dados atualizados. Através deste perfil especialista, somente o coordenador tem a possibilidade de incluir novos usuários no sistema, dando-lhes a permissão desejada, a cadastrar novas tecnologias e classificações de tecnologias a serem utilizadas pelo sistema e realizar as associações entre tecnologias e classificações. Através do perfil de especialista, é possível visualizar os cadastros criados no sistema. Esses cadastros foram adicionados visando um futuro crescimento da empresa. Este crescimento pode ocorrer tanto no que se refere a tecnologias utilizadas hoje pela fábrica de software quanto a novas classificações de desenvolvimentos para cada tecnologia. Para isso foram criados três cadastros principais: Cadastro Usuários, Cadastro Tecnologias e Cadastro Classificações. Além de inserir novos usuários para a aplicação, na tela de Cadastro Usuários é possível editar as permissões e características de cada usuário, como identificar se ele é especialista ou não e definir a porcentagem aceita de similaridade nos resultados retornados pelas consultas. Cada usuário cadastrado no sistema pode alterar a porcentagem de similaridade dos casos que deseja pesquisar na base. É também através deste cadastro que o usuário pode limitar o número de resultados que ele deseja que a busca por tarefas similares retorne, dando assim mais flexibilidade as preferências de cada usuário do sistema. A figura 4 apresenta a tela de Cadastro de Usuários do sistema. Neste exemplo o usuário em questão solicitou que na recuperação de tarefas similares somente sejam exibidas tarefas com similaridade acima de 70% e que estes resultados não ultrapassem cinco registros. 11

12 Figura 4 - Tela de Cadastro dos Usuários Na tela de Cadastro de Tecnologias é realizada a inclusão e alteração das tecnologias de desenvolvimento existentes na empresa hoje. As tecnologias incluídas são utilizadas na indexação dos casos pelo sistema. Atualmente a empresa em questão utiliza as tecnologias Java, PowerBuilder, ColdFusion e SQL, porém novas tecnologias poderão ser utilizadas futuramente pela empresa, e o sistema possibilitará essa inclusão. Na tela de Classificações é realizada a inclusão e alteração das classificações de desenvolvimento existentes hoje. Esta classificação foi desenvolvida para facilitar a indexação dos casos junto com a Tecnologia. São consideradas em um primeiro momento as classificações Tela, Relatório e Processamento, porém novas classificações poderão surgir conforme a necessidade e estas serão cadastradas neste menu. No menu de Classificações também foi desenvolvida a tela Associar Tecnologia e Classificações. Esta associação funciona conforme mostrado na tabela 2 na seção 3.4. Esta funcionalidade foi definida no sistema, pois poderão existir tecnologias utilizadas pela empresa hoje que trabalham com classificações diferentes de outras tecnologias mais atuais. Além das telas de cadastro do sistema, o perfil especialista tem a opção de alterar os pesos definidos para cada atributo da representação dos casos. O menu Parâmetros permite que os valores dos parâmetros Número de Regras do Caso de Uso, Número de Entradas, Número de Saídas, Quantidade de Tabelas Envolvidas, Número de códigos-fonte alterados e Quantidade de Aplicações sejam alterados conforme identificada esta necessidade pelo especialista. Inicialmente os parâmetros foram configurados conforme a tabela 1 apresentada na seção Módulo Usuário O perfil de usuário comum do sistema foi criado visando sua utilização pelo profissional responsável pela realização da estimativa. Este perfil foi criado para caso haja interesse de alguém que não seja o especialista realizar a estimativa, não esteja disponível para esse usuário as funcionalidades de configuração do sistema. Neste perfil o usuário somente tem permissão para a geração de nova estimativa, cujo funcionamento seja explicado mais detalhadamente nas próximas seções. O sistema de Estimativa de Desenvolvimento de Softwares será utilizado exclusivamente pela equipe da fábrica de softwares da empresa. Atualmente ela recebe solicitações de recursos para o desenvolvimento de tarefas do setor de análise da empresa. Esta solicitação é enviada ao coordenador da equipe, que neste momento obtém os seguintes dados em mãos: Projeto em questão Nome da tarefa ou produto de trabalho Tecnologia Documento de especificação de tarefa 12

13 Documento de caso de uso da tarefa Tempo estimado pelo analista de sistemas. Atualmente ao receber esta solicitação, já é alocado um desenvolvedor para este trabalho, assumindo assim que o tempo proposto está correto e que toda a documentação necessária para o desenvolvedor trabalhar esteja contemplada nesta solicitação. Se durante o desenvolvimento fosse encontrado alguma inconformidade de análise, ou falta de informações para prosseguir, era necessário que o desenvolvedor interrompesse seu trabalho para solicitar a correção da documentação. A Figura 5 apresenta o funcionamento do ciclo de alocação de desenvolvedores na fábrica de softwares e o momento da realização da estimativa por parte do coordenador utilizando o sistema. Figura 5 - Fluxo do Processo de Alocação de Recurso para a fábrica de software Através destas premissas recebidas pelo setor de análise, o coordenador tem informações suficientes para utilizar a ferramenta de estimativa em busca do tempo mais adequado para a alocação do desenvolvedor nesta atividade e juntamente com isso validando a documentação recebida. Com a solicitação de recurso feita pelo setor de análise, e obtidas as informações necessárias, o coordenador passa então para a etapa de identificação da nova tarefa recebida. Primeiramente ele informará no sistema os atributos Projeto e Tarefa. Estes atributos possuem finalidade de histórico, mantendo os projetos no qual a equipe participou e o número de tarefas desenvolvidas para este projeto. Também fazem parte da identificação da tarefa os atributos Tecnologia e Classificação. Estes dois atributos serão responsáveis pela indexação dos casos no momento da busca por tarefas similares. Após esta etapa, é realizada a contagens dos atributos: Número de Regras do Caso de Uso, Número de Entradas, Número de Saídas, Quantidade de Tabelas Envolvidas, Número de códigos-fonte alterados e Quantidade de Aplicações serão alterados presentes nesta nova tarefa. Estes campos no sistema são do tipo numérico e serão obtidos através da leitura e entendimento da documentação recebida pelo setor de análise. Todas estas informações são de preenchimento obrigatório e fazem parte do algoritmo de busca desenvolvido. 13

14 De posse de todos os dados relevantes da tarefa a ser desenvolvida, o coordenador então realiza a busca por tarefas similares no sistema. Os atributos Tecnologia e Classificação serão os primeiros limitadores de resultados desta busca, pois possuem finalidade de indexação dos casos. É através destes dois campos que o sistema filtra a busca por tarefas similares de acordo com os valores informados. Após filtrar a busca somente pela Tecnologia e Classificação preenchidas, o sistema verifica qual a porcentagem de similaridade mínima aceita por este usuário e qual a quantidade máxima de tarefas similares ele pretende visualizar no resultado desta busca. Estas informações são obtidas através dos valores informados nos campos Percentual Similaridade e Qtd. Máxima Casos no cadastro de usuário. Para cada tarefa que se enquadrou na indexação dos casos com a tarefa atual o sistema realiza o cálculo da similaridade dos casos, através do algoritmo do vizinho mais próximo, para obter a distância ponderada da tarefa atual com as tarefas já desenvolvidas anteriormente. Realizada esta comparação, o retorno desta pesquisa do sistema, obterá no seu resultado as tarefas mais similares com a tarefa atual, mostrando para o usuário a sua porcentagem de similaridade, e todos os demais atributos das tarefas similares. O retorno das tarefas similares exibe para o usuário todos os atributos das tarefas, exibindo também a qual projeto e tarefa aquela estimativa anteriormente realizada pertencia, e principalmente: qual o tempo alocado para o desenvolvimento destas tarefas, de forma que esses resultados possam auxiliar o coordenador na escolha da tarefa mais similar. Ao utilizar a busca por tarefas similares o usuário tem a opção de clicar sobre a tarefa mais similar com a atual, selecionando assim o tempo de desenvolvimento desta tarefa para a sua tarefa. Nem sempre este tempo selecionado na tarefa similar será o mais apropriado para a tarefa atual, então o coordenador tem a opção de alterar o tempo proposto, incluindo neste campo um valor de acordo com a sua percepção. Depois de decidido o tempo de desenvolvimento da nova tarefa recebida, o coordenador salva esses dados para que futuramente essa tarefa possa ser utilizada e quem sabe similar a futuras tarefas que serão desenvolvidas. O sistema grava no seu banco de dados todos os atributos preenchidos na tarefa e o tempo obtido através da busca de casos similares, podendo futuramente ser utilizada como referência para outros problemas. A figura 6 mostra a utilização do sistema pelo coordenador da fábrica de softwares para geração de uma nova estimativa de tempo. Figura 6 Geração de Nova Estimativa buscando tarefas similares. 14

15 Caso o coordenador não tenha interesse em buscar tarefas similares na base de casos ou deseje assumir o tempo estimado pelo setor de análise, ele simplesmente informa os dados de Identificação da Tarefa e os Atributos da Tarefa, informa o tempo desejado e clica no botão Salvar. Esta estimativa será salva no banco de dados assim como as demais, permitindo inclusive que a mesma seja utilizada como referência para as próximas tarefas desenvolvidas de mesma tecnologia e classificação. Esta análise de atributos e tempo realizada pelo coordenador permite que a tarefa seja analisada mais detalhadamente antes da alocação do desenvolvedor. Esta contagem de itens e busca de tarefas similares permite assim que qualquer inviabilidade de desenvolvimento, limitação de sistema ou falta de alguma documentação de análise, seja identificada pela coordenação da área sem haver a necessidade de alocar um desenvolvedor para tal. 5 VALIDAÇÃO DO SISTEMA E RESULTADOS APRESENTADOS Para a validação do sistema foram inseridas na base de casos tarefas desenvolvidas anteriormente pela fábrica de softwares. Para o cadastro destas tarefas foi considerado o tempo real de desenvolvimento da atividade e não o tempo estimado pelo analista. Esta consideração foi feita, pois frequentemente o tempo estimado pelo analista não é igual ao tempo real utilizado pelo desenvolvedor. Desta forma estas tarefas inseridas na base de dados do sistema representam a verdadeira estimativa de desenvolvimento do setor, sem a utilização do RBC como solução para o problema. Foram eleitas primeiramente cem tarefas desenvolvidas, sendo vinte e cinco tarefas de cada tecnologia que a empresa trabalha atualmente: Java, PowerBuilder, ColdFusion e SQL. Entre as vinte e cinco tarefas de cada tecnologia, foram inseridas tarefas de todas as classificações que esta tecnologia trabalha atualmente, são elas: Tela, Relatório e Processamento. Essa divisão foi feita, para que todas as tecnologias e classificações pudessem ser testadas pelo sistema. Para a inserção destas cem tarefas na base foi utilizado o menu Nova Estimativa, inserindo corretamente os dados de Identificação da Tarefa e os Atributos da Tarefa, conforme apresentado na seção anterior. Para cada tarefa inserida não foi utilizado o botão Buscar Tarefas Similares, pois neste primeiro momento não se tinha o intuito de utilizar o RBC como solução para definição de tempo e sim popular a base de casos, inserindo no campo Tempo o tempo utilizado na tarefa. Na tela de Parâmetros do sistema foram inseridos os pesos de cada atributo da tarefa. Inicialmente foram considerados os pesos descritos na tabela 1 apresentada na seção 3.2. Tendo estas cem tarefas inseridas na base contemplando todas as possíveis solicitações de recurso existentes, foram selecionadas mais cem tarefas já desenvolvidas, diferentes das anteriores, que foram inseridas no sistema simulando novas solicitações de recurso. Foi utilizada a busca por tarefas similares na base de casos, utilizando assim o RBC como solução para estimar o tempo de desenvolvimento de tal atividade e não mais utilizar o tempo proposto pelo analista de sistemas. Para cada uma das cem novas tarefas inseridas pelo sistema, foi utilizado o menu Nova Estimativa onde foram informados todos os atributos da tarefa e utilizado o botão Buscar Tarefas Similares para pesquisar na base o melhor tempo para o problema atual. A partir disto começou-se a verificar a solução proposta pelo sistema. Os testes foram divididos em duas etapas, onde para cada um delas foram validadas as funcionalidades do sistema de modo geral, e os possíveis ajustes a serem realizados para atingir o objetivo proposto. Na primeira etapa foram validadas todas as funcionalidades do sistema, como o cálculo do algoritmo do vizinho mais próximo e sua eficácia, a seleção de um caso como similar, e as adaptações do caso atual para utilizá-lo como solução do problema. Foi validado também o comportamento do sistema para cada usuário logado, verificando suas permissões e preferências cadastradas para a busca de casos similares. A segunda etapa se destinou a verificação dos pesos definidos para os atributos. Foi verificado se havia ou não a necessidade de ajustar estes pesos para que os tempos propostos pelo RBC sejam os mais similares possíveis das tarefas que foram utilizadas como comparação. 15

16 Os resultados dos testes da primeira etapa foram satisfatórios. A escolha do algoritmo do vizinho mais próximo como solução para a etapa de recuperação dos casos funcionou de forma bastante eficiente para as tarefas cadastradas. O campo similaridade foi bastante útil para a escolha da tarefa mais semelhante a atual e a adaptação dos casos ocorreu da forma correta, selecionando a tarefa similar e alterando o seu tempo proposto conforme a percepção do especialista. As diferentes visualizações e preferências dos usuários logados se comportaram de maneira correta. Na segunda etapa foi possível observar que para algumas tecnologias e classificações cadastradas a busca por tarefas similares obteve um resultado muito positivo, trazendo tarefas da base de casos com tempos muito similares ao tempo real utilizado pelo desenvolvedor, de acordo com os atributos informados. Porém foi possível identificar algumas classificações onde estes tempos estimados pelo sistema estavam distantes do tempo real utilizado na tarefa. A tabela 3 demonstra os resultados obtidos nesta fase dos testes. Tabela 3 Demonstração dos resultados dos testes realizados. Tecnologia Classificação % de acerto do tempo estimado Java Power Builder ColdFusion SQL Tela 62,12 Processamento 71,27 Relatório 81,98 Tela 74,02 Processamento 59,94 Relatório 69,10 Tela 78,50 Relatório 80,11 Processamento 78,94 Relatório 71,99 Para estes casos onde o sistema não obteve um tempo estimado condizente com a realidade foram realizados ajustes em alguns parâmetros do sistema, alterando o peso dos parâmetros Número de Regras do Caso de Uso e Número de Entradas. Estes ajustes são feitos no menu Parâmetros, onde o peso de cada um deles pode ser editado. A tabela 4 mostra os ajustes realizados nos pesos depois de concluída esta etapa dos testes. Tabela 4 Ajustes dos pesos. Parâmetros Peso Inicial Peso após ajuste Número de Regras do Caso de Uso 3 5 Número de Entradas 2 4 Número de Saídas 2 2 Quantidade de Tabelas Envolvidas 4 4 Número de Códigos-Fonte alterados 4 4 Quantidade de Aplicações 3 3 Após esta alteração foram inseridas novamente mais cinquenta tarefas de classificações variadas para a validação do tempo estimado. Com isso obteve-se um resultado, apresentado em percentual de eficácia, para a busca de tarefas similares, apresentado na tabela 5. 16

17 Tabela 5 Demonstração dos resultados dos testes realizados. Tecnologia Classificação % de acerto do tempo estimado Java Power Builder ColdFusion SQL Tela 84,52 Processamento 93,15 Relatório 91,12 Tela 74,69 Processamento 86,05 Relatório 70,75 Tela 76,29 Relatório 79,08 Processamento 80,95 Relatório 76,08 Na tabela 3, a coluna % de acerto do tempo estimado calcula a diferença do tempo estimado pela tarefa mais similar com o tempo real utilizado pela tarefa. Através desta diferença é estabelecido o percentual de eficácia do sistema como solução de estimativa. Com a realização dos testes e validações do sistema foi possível identificar a contribuição do raciocínio baseado em casos para solução na estimativa de desenvolvimento de softwares. Apesar de, para algumas classificações, o sistema apresentar um percentual de acerto inferior a 85%, pode ser considerado muito eficiente quando associado ao conhecimento do especialista para estimar o tempo a ser alocado para o desenvolvedor. Cabe também salientar que quanto mais casos forem inseridos na base de dados mais preciso e eficiente será sua utilização, dando assim maior confiabilidade ao sistema proposto neste trabalho. 6 CONCLUSÕES O RBC estabeleceu-se nos últimos anos como uma das tecnologias mais populares e disseminadas para o desenvolvimento de sistemas que busquem o conhecimento através de experiências passadas. O RBC é capaz de utilizar de forma explicita o conhecimento específico sobre situações concretas vivenciadas anteriormente. Este conhecimento adquirido através de experiências anteriores pode ser utilizado de maneira inteligente para resolver um futuro problema semelhante. O conhecimento do especialista é essencial para que o sistema defina os problemas a serem resolvidos, buscando na base de casos situações muito similares ao problema atual. Sem este conhecimento do problema como um todo e da experiência do especialista o sistema pode trazer resultados parcialmente similares, não correspondendo assim com a realidade atual. Atualmente o RBC vem sendo utilizado em inúmeras aplicações com sucesso, adaptando as suas necessidades e utilizando algoritmos de similaridade robustos e efetivos, agregando também a retenção dos casos visando um futuro aproveitamento da solução do problema atual no futuro. Para o sistema proposto neste artigo, buscou-se uma solução para o problema de estimativa de tempo de desenvolvimento de uma tarefa em uma determinada fábrica de softwares. Tratando-se de estimativa de desenvolvimento a sua solução deve ser encontrada de maneira justa e correta para que o trabalho dos desenvolvedores não seja prejudicado por um cálculo incorreto na estimativa. Para tal, buscou-se uma forma de reutilizar o tempo real de tarefas já desenvolvidas em tarefas atuais semelhantes. Existem várias técnicas de estimativas muito conceituadas que são utilizadas pelas empresas atualmente, porém todas elas possuem algum tipo de limitação ou exigência de modelagens e itens nos quais a empresa em questão não se adéqua atualmente, o que necessitaria assim uma mudança em toda a metodologia de desenvolvimento existente na empresa. Outro fator importante para a não utilização de técnicas de estimativas já existentes hoje se deve ao seu trabalho ser focado no projeto de software como um todo, muitas vezes tendo a visão de usuário do sistema, e não a visão das pequenas funcionalidades do projeto no momento da estimativa, que seriam suas tarefas. 17

18 A utilização do RBC deu-se pelo fato da simplicidade com que um problema pode ser modelado e representado. A fácil adaptação às necessidades da empresa na representação de um caso possibilitou que todas as modelagens e atributos utilizados pela empresa no desenvolvimento do software pudessem ser encaixados a representação dos casos. Desta forma foi possível tratar um caso como uma simples tarefa, que faz parte de um projeto grande, não necessitando assim a visão geral de negócio para a realização da estimativa de parte dele. O RBC foi implementado utilizando as quatro etapas do seu fluxo de desenvolvimento, o que possibilitou que o sistema obtivesse uma base de casos mais íntegra a cada dia, com a retenção de novos casos, adaptados ou não pelo especialista. A partir deste sistema, a estimativa de desenvolvimento de softwares, que antes era feita pelo analista de sistemas através somente do seu conhecimento da tarefa, ganhou um novo processo dentro da equipe da fábrica de softwares. O coordenador da equipe ao receber a solicitação de recurso para um desenvolvimento pela equipe de analise estimará o tempo que será alocado a este desenvolvedor verificando as características mensuráveis desta tarefa, que são os atributos criados na representação dos casos. Com estas informações em mãos, ele utiliza o sistema proposto, que será de grande auxilio para ele recordar o que já foi desenvolvido pela equipe com estes mesmos atributos. Com essa busca de tarefas similares ele tem a autonomia, através de seu conhecimento, de alocar o desenvolvedor com um tempo mais preciso, utilizando o tempo de uma tarefa similar a essa, ou até mesmo adicionando algumas horas a uma tarefa que é parcialmente similar a atual. A criação deste sistema dentro do processo de alocação de recurso por parte do coordenador apresentou, além das vantagens apresentadas pelo RBC, a possibilidade de validação das informações recebidas pelo setor de análise antes que a tarefa seja realmente alocada. Desta forma o coordenador no momento da contagem dos atributos da tarefa consegue identificar se todas as informações imprescindíveis para o desenvolvimento estão contidas naquela documentação. Esta ação diminui o tempo de correção da documentação, que atrasaria o prazo estipulado inicialmente para o desenvolvimento, pois só seria observada pelo desenvolvedor na data de inicio de seu trabalho naquela tarefa. Como trabalhos futuros relacionados a este sistema, o desenvolvimento de um módulo de integração por parte da ferramenta de alocação de recursos utilizada pela empresa com a ferramenta de estimativa seria uma grande utilidade para o coordenador. Em situações onde o tempo real de desenvolvimento superar o tempo proposto pelo sistema de estimativa, no momento da retenção das tarefas na base a ferramenta de integração salvaria na base de casos o tempo já ajustado pelo coordenador para esta tarefa. Um módulo de estatísticas sobre as tarefas desenvolvidas poderia ser implementado, para que a gerência da equipe consiga visualizar as tecnologias e classificações mais desenvolvidas, as que custam mais caro para a fabrica de softwares, e as que poderiam ser migradas para novas tecnologias. Para que assim a equipe possa tomar ações de melhoria sobre as informações contidas nesta base de tarefas. Os resultados obtidos com o desenvolvimento deste trabalho e após os testes e validações realizados mostram que o RBC atingiu os objetivos deste sistema na estimativa de desenvolvimento de softwares. A alocação de recursos pode ser feita de forma mais confiável e mantendo assim os tempos alocados pelo sistema disponíveis para serem reutilizados em futuras alocações. Conclui-se com estes resultados, que o sistema de estimativa de desenvolvimento pode contribuir muito para desempenho da equipe da fábrica de softwares e para a empresa como um todo. Atualmente sendo proposto como utilização somente pela fabrica de softwares, futuramente pode vir a favorecer o trabalho de muitas outras equipes, quando aplicado a cada realidade do setor. REFERÊNCIAS AAMODT, A., and E. Plaza. Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches. Artificial Inteligence Communications, Março de ABEL, M. (1996) Um estudo sobre Raciocínio Baseado em Casos. Universidade Estadual do Rio Grande do Sul, Pós-Graduação em Ciência da Computação, Porto Alegre. 18

19 BEPPLER, Fabiano Duarte. Emprego de RBC para recuperação inteligente de informações. Disponível em : < FabianoDuarteBeppler.pdf>. Acesso em: 13 abril BITTENCOURT, Guilherme. Inteligência Artificial: Ferramentas e Teorias. 2. ed. Florianópolis: Editora da UFSC, BOEHM, Barry et al. Software Cost Estimation With COCOMO II. Prentice Hall PTR, FERNANDES, Anita Maria Da Rocha. Inteligência Artificial: noções gerais. Florianópolis: Visual Books, HEIMBERG Viviane; GRAHL Everaldo Artur. Estudo de Caso de Aplicação da Métrica de Pontos de Casos de Uso numa Empresa de Software. Disponível em: < Acesso em: 13 abril IFPUG. International Function Point Users Group. Disponível em: < Acesso em: 13 abril JUNIOR, Jose Daltro Martins. Ferramenta de Recomendação de Projetos Web. Trabalho de Conclusão I Curso de Ciência da Computação. ULBRA. LAGEMANN, Gerson Volney. RBC para o Problema de Suporte ao Cliente nas Empresas de Prestação de Serviço de Software: O Caso Datasul. Dissertação (Mestrado em Engenharia de Produção) Universidade Federal de Santa Catarina, Florianópolis Disponível em: < Acesso em: 10 abril LORENZI, Fabiana; FRANCESCHI, Analucia Schiaffino Morales De. (2007) Inteligência Artificial. Canoas: [s.n.]. Disponível em < Acesso em: 10 abril PEREIRA Roberto, TAITI Tania F. C., CASTRO Cristiane Y. H., TRINDADE Daniela F. G., SILVA José Valderlei Da. Estimativas de Software: O Estudo de uma Aplicação Prática Utilizando a Técnica de Use Case Points. Disponível em: < org.br/bibliotecadigital/download.php?paper=686>. Acesso em: 11 abril PRESSMAN, Roger S. Engenharia de Software. São Paulo: Makron Books, SOFTEX. Associação para Promoção da Excelência do Software Brasileiro. Disponível em: bilhoes.html. Acesso em: 13 abril SOUZA, Leandro Borba De. Ferramenta de Análise de Riscos em Gerência de Projetos Baseado em Casos. Disponível em: < %20de%20Souza.pdf>. Acesso em: 11 abril WANGENHEIM, Christiane Gresse Von; WANGENHEIN, Aldo Von. Raciocínio Baseado em Casos. Barueri: Manole,