S.I.NFORMEsi.facol.com/wp-content/uploads/2012/09/SInforme2012.pdf · Osman da Costa Lins (FACOL),...
57
Transcript of S.I.NFORMEsi.facol.com/wp-content/uploads/2012/09/SInforme2012.pdf · Osman da Costa Lins (FACOL),...
ISSN 2316-5804
S.I.NFORME
Revista de Tecnologia da Informação do Curso de Sistemas de Informação
Faculdade Escritor Osman da Costa Lins - FACOL
Vitória de Santo Antão, PE – ANO 1, Nº. 1 – dez.2012
S.I.nforme Publicação anual Revista do Curso de Sistemas de Informação – Bacharelado da Faculdade Escritor Osman da Costa Lins – Facol Diretor da FACOL: Dr. Paulo Roberto de Leite Arruda Vice-Diretor da FACOL: Túlio Albuquerque Duarte Diretor Pedagógico: Prof. Péricles Tavares Austregésilo Filho Coordenadora Geral Acadêmica: Profª. Nancy Farias Martins Leite Coordenador do Curso de Sistemas de Informação Prof. MSc. Cleyton Mário de Oliveira Rodrigues
Conselho Editorial: Cleyton Mario de Oliveira Rodrigues Elcias Ferreira da Costa Péricles Tavares Austregésilo Filho José Procópio da Silveira Gleibson Rodrigo Silva de Oliveira Conselho Científico: Prof. MSc. Cleyton Mário de Oliveira Rodrigues Prof. MSc. Ryan Ribeiro de Azevedo Profª. MSc. Ana Cristina Freitas CesarStefano Toscano Profª. Esp. Audrey Bezerra de Vasconcelos Prof. Esp. Iuri Santos Souza Profª. Msc. Jailze de Oliveira Santos Profº. Esp. Gleibson Rodrigo Silva de Oliveira Diagramação: Evandro Bonifácio de Andrade – Departamento de Web Design. Publicação: Associação Vitoriense de Educação, Ciências e Cultura, entidade mantenedora da Faculdade Escritor Osman da Costa Lins – FACOL. CNPJ: 03.391.726/0001-90.
Endereço: Rua do Estudante, 85, Bairro Universitário, Vitória de Santo Antão/PE. CEP 55612-650. Tel. (81) 3114-1200 www.facol.com - e-mail: [email protected] IMPRESSÃO: Luci Artes Gráficas Ltda [email protected]
REVISTA DE TECNOLOGIA DA INFORMAÇÃO DO CURSO DE SISTEMAS DE INFORMAÇÃO: S.I.nforme Vitória de Santo Antão, PE: Facol, a. 1, n.1 ___. 2012, ____p.
ISSN 2316-5804
1
SUMÁRIO
SEVAC: Um Estudo de Caso do Uso de Sistemas Especialistas na Educação Básica _ 2
Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum ___________________________________________________________ 12
LSVF: A heuristic search to reduce the backtracking calls when solving Constraint Satisfaction Problems __________________________________________________ 19
O Lixo eletrônico no Brasil: Leis e Impactos Ambientais ______________________ 28
An Experimental Research on the Relationships between Preferences for TechnicalActivities and Behavioural Profile in Software Development ___________ 34
CHRrf ∨: A Logic Inference Engine to Resolution Leveraged by Heuristics _______ 51
2
EDITORIAL
S.I.NFORME
“Meus Filhos terão computadores, sim, mas antes terão livros. Sem livros, sem leitura, os nossos filhos serão incapazes de escrever – inclusive a sua própria história”. Bill Gates
A humanidade sempre buscou novos meios que alavancassem a comunicação em todos os seus aspectos. Tanto que, a evolução da sociedade pode ser demarcada em quatro grandes divisões, todas embasadas na Comunicação: a Sociedade Oral, a Sociedade Escrita, a Sociedade da Imprensa e a Sociedade Tecnológica. A cada mudança de paradigma, novos recursos foram agregados, tornando a comunicação mais rápida e de maior alcance. Os Sistemas de Informação tiveram (e tem) um papel importante nisso, tanto que ditam o norte da nova sociedade, a Tecnológica. Neste momento contemporâneo, as chamadas Tecnologias de Informação e Comunicação (TICs) propõe a comunicação assíncrona, atemporal, confrontando as barreiras geográficas e ideológicas. Assim, o acesso à Informação é tido, hoje mais que sempre, como divisor de águas. A propriedade deste bem abre as fronteiras do Conhecimento e da Competência. Em face deste novo mundo, as TICs assumem o papel de prover novas metodologias, processos e ferramentas que venham a acelerar este quadro, tanto no contexto organizacional, quanto social. O avanço intermitente do estado da arte, nas mais diversas áreas, requer a celeridade na fomentação e difusão do Conhecimento propiciado pelas TICs. A revista do Curso de Bacharelado em Sistemas de Informação da Faculdade Escritor Osman da Costa Lins (FACOL), S.I.NFORME, elaborada pelo corpo Docente e Discente do Curso de Sistemas em conjunto com colaboradores externos, assume seu compromisso de participar ativamente deste processo contínuo de renovação tecnológica difundindo os resultados alcançados pelas pesquisas desenvolvidas. Ao assumir um caráter técnico-científico, a revista S.I.NFORME preocupa-se em tornar os avanços acessíveis às todas as áreas direta ou indiretamente abordadas pelas TIC’s, seja numa perspectiva Empresarial, Acadêmica, e mesmo Humano-Social. Cleyton Mário de Oliveira Rodrigues Coordenação do Curso de Sistemas de Informação da FACOL
3
SEVAC: Um Estudo de Caso do Uso de Sistemas Especialistas na Educação Básica
Maria José dos Santos Takeshita1, Cleyton Mário de Oliveira Rodrigues2
1 Sistemas de Informação– Faculdade Escritor Osman da Costa Lins (FACOL) Vitória de Santo Antão – PE – Brasil
2Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código Postal 7851 – RECIFE – PE – Brasil
[email protected], [email protected]
Abstract. To evaluate the knowledge acquired by students of Elementary Education is a subject that involves areas of cognitive psychology, approaches and styles of teaching/learning process and, more recently, the use of techniques that concern the field of Artificial Intelligence. This article, in this context, presents a proposal using the I. A. to assess and diagnose the learning of elementary school students based on an Expert System. This proposal was substantiated through a case study within a context of knowledge in particular; it also presents the questionnaires through which we sought to assess the acceptability of the system developed by both the teachers as the student body.
Resumo. Avaliar o conhecimento adquirido pelos alunos da Educação Elementar é um tema que envolve áreas da Psicologia Cognitiva, das abordagens e estilos do processo Ensino/Aprendizagem e, mais recentemente, do uso de técnicas que tangem o domínio da Inteligência Artificial. Este artigo, neste contexto, apresenta uma proposta utilizando a I. A. para avaliar e diagnosticar o aprendizado de alunos do Ensino Fundamental baseado em um Sistema Especialista. Tal proposta foi fundamentada através de um estudo de caso, dentro de um contexto de conhecimento em particular; ela também apresenta questionários através do qual se pretendeu avaliar a aceitação do sistema desenvolvido tanto pelo corpo docente, como pelo corpo discente.
1. Introdução
De acordo com [Valente 2009] “o termo Informática na Educação significa a inserção do computador no processo de aprendizagem dos conteúdos curriculares em todos os níveis e modalidades de educação. Para tanto, o professor da disciplina curricular deve ter conhecimento e domínio sobre o potencial educacional do computador e ser capaz de alternar adequadamente atividades tradicionais de ensino-aprendizagem e atividades que usam o computador” para que dessa forma a apropriação do conhecimento transmitido seja bem adquirida pelo aluno.
Os computadores são vistos como um importante recurso para auxiliar o processo de ensino-aprendizagem, aprimorando os conceitos básicos já conhecidos [Andrade e Lima 1996], e “possibilitando a busca e compreensão de novas idéias e valores; quando utilizado como máquina de ensinar aborda os métodos de ensino tradicional ou instrucionista” [Valente 2009]. Vale salientar, contudo, que mesmo o aluno construindo seu conhecimento através de ambientes de aprendizagem
4
informatizados, a máquina não deve ser usada exclusivamente e isoladamente, pelo contrário, como ferramenta não é capaz de trazer sozinha, avanços educacionais.
Paralelamente ao desenvolvimento do Construtivismo-Interacionista de Piaget [Piaget 1972], sistemas computacionais como a Inteligência Artificial, e, em particular, subáreas de atuação, como os Sistemas Especialistas [Giarratano e Riley 1998] e os Sistemas Tutores Inteligentes [Wenger 1987] surgiram, permitindo novas formas para buscar, construir e manter conhecimentos, porém mais adaptáveis às características cognitivas dos alunos. Tais avanços fomentaram a criação e o desenvolvimento de novas idéias que pudessem auxiliar todo o processo de ensino-aprendizagem, vivenciado nas escolas afora.
Este presente trabalho, contudo, delimita-se ao estudo/avaliação das técnicas atuais usadas em sala para avaliar o nível de aprendizado dos alunos. Enquanto pelo lado discente, há recorrentes reclamações acerca das provas elaboradas (tediosas e estáticas), pelo lado do corpo docente, há a necessidade de poder criar provas mais ricas de detalhes, há um baixo custo de tempo e, sobretudo, que não acarrete sobrecargas de trabalhos durante a correção, podendo prejudicar, sobretudo, a imparcialidade na avaliação dos alunos. É neste contexto, que este trabalho apresenta o SEVAC, uma ferramenta desenvolvida durante o trabalho de graduação, que incorpora características da Inteligência Artificial, particularmente de Sistemas especialistas, e que serve como uma proposta de avaliação rápida, dinâmica, e imparcial ao nível de assimilação dos alunos.
Este trabalho está estruturado como se segue. Na seção 2, revisitaremos as principais características dos Sistemas Especialistas. De forma a poder avaliar bem o SEVAC, a seção 3 explica os métodos comuns utilizados nas redes de ensino como formas de avaliação do aprendizado. Em seguida, a seção 4 apresenta o SINTA, o framework básico através do qual o SEVAC, discutido na seção 5, foi desenvolvido. Por fim, a seção 6 resume os principais resultados alcançados até então, e a seção 7 encerra este trabalho com as conclusões e as perspectivas de trabalhos futuros.
2. Sistemas Especialistas
Os sistemas especialistas fazem parte da área de interesse da Inteligência Artificial (IA), podendo ser considerado, inclusive, como um ramo da I.A., [Giarratano e Riley 1998], como pode ser observado na figura 1.
5
Figura 1: Áreas da Inteligência Artificial [Giarrat ano & Riley. 1998]
Um sistema especialista é um programa de computador que usa o conhecimento e inferências para resolver problemas muito difíceis e que requerem a expertise humana, ou seja, habilidades intelectuais que uma pessoa tenha em uma determinada área do conhecimento para solucioná-los [Harmon, Maus e Morrisey 1988] [Metaxiotics, Askounis e Nikolopoulos 2006].
Figura 2: Arquitetura de um Sistema Especialista [N ikolopoulos 1997]
Os Sistemas Especialistas possuem uma arquitetura composta de (figura 2) [Nikolopoulos 1997]: uma base de conhecimento responsável por estruturar todo o conhecimento sobre o domínio da aplicação, um motor de inferência contendo os algoritmos com regras que serão satisfeitas pelos fatos ou objetos implantados, um módulo para aquisição do conhecimento o qual é constantemente refinado aumentando o conhecimento adquirido do especialista, módulo de explanação responsável por justificar os passos utilizados para chegar ao resultado final e uma interface, através da qual o sistema especialista interage com o usuário.
Parafraseando [Mendes 1997], os resultados obtidos através da utilização da técnica de sistema especialista são diferentes daqueles encontrados por meio de sistemas tradicionais, por tratar-se de sistemas dotados de inteligência e conhecimento. Podemos destacar alguns exemplos, tais como:
6
• O sistema habilita tanto um especialista, bem como leigos a serem capazes de tomar decisões mais coerentes;
• Melhora a produtividade e desempenho, uma vez que o conhecimento está armazenado em uma base de dados e pode ser usado de forma distribuída, tantas vezes quantas necessárias forem, mantendo sempre a integridade nas decisões tomadas; e
• Podem servir de instrumento para coleta de informações sobre o desempenho dos usuários, permitindo que o próprio sistema possa ser reformulado para adequar-se cognitivamente a este grupo de usuários.
Este trabalho, portanto, explora mais largamente o terceiro item acima; a partir do diagnóstico do nível de aprendizado dos alunos em uma área de conhecimento em particular, é possível que o sistema evolua continuamente até atingir um nível adequado de avaliação.
3. Métodos Tradicionais de Avaliação de Aprendizado
De acordo com [Kraemer 2005], “avaliar é atribuir um valor sobre a propriedade de um processo para a aferição da qualidade do seu resultado está associada a medir conhecimentos adquiridos pelos alunos”. A avaliação da aprendizagem é marcada pelo desenvolvimento de testes padronizados para medir quais aptidões e habilidades foram adquiridas pelos alunos. No âmbito escolar, tal informação é necessária para que o professor encontre meios e estratégias que possam ajudar os alunos a absorver da melhor forma possível os conteúdos estudados. Os tipos de avaliação são enquadrados em três grandes tipos [Haydt 1997]:
• A Avaliação Diagnóstica é aquela em que é verificada a posição do aluno face às novas aprendizagens que lhe vão ser propostas e a aprendizagens anteriores que servem de base àquelas, no sentido de identificar as dificuldades futuras e, em certos casos, de resolver situações presentes.
• A Avaliação Formativa permite constatar se os alunos estão, de fato, atingindo os objetivos pretendidos, verificando a compatibilidade entre tais objetivos e os resultados efetivamente alcançados durante o desenvolvimento das atividades propostas.
• A Avaliação Somativa busca traduzir o quão distante o avaliado ficou de atingir uma meta estipulada inicialmente. Esse tipo de avaliação deve ser aplicado em momentos específicos ao longo de um curso, como por exemplo, no final de um período ou ano letivo.
Atualmente é notória a necessidade da inserção dos novos recursos tecnológicos na área escolar, uma vez que a sociedade busca por profissionais qualificados, capazes de enfrentar situações diversas, e o uso dessas novas tecnologias visam adequá-los a esse meio fazendo com que alunos e professores façam parte dessas mudanças sociais, culturais e profissionais que o terceiro milênio visa proporcionar.
Tais avanços tecnológicos, em destaque o computador, assim como os softwares educativos, emergem como o artefato principal, oferecendo suporte na aprendizagem. Pois é através dele que se expande o raciocínio e a criatividade dos alunos. É grande a necessidade no uso dos recursos computacionais em salas e/ou laboratórios de
7
informática, sejam eles utilizados como instrumento para auxiliar na aprendizagem do conteúdo, ou para avaliação da aprendizagem servindo como suporte ao professor.
4. SINTA O Sistema Especialista Expert SINTA [LIA 2010] é um software desenvolvido na Universidade Federal do Ceará – UFC que utiliza linguagem Shell, um projeto da UFC/UECE, criado pelo Grupo SINTA - Sistemas Inteligentes Aplicados, o qual utiliza em sua criação técnicas de Inteligência Artificial.
Seu conjunto de instruções utiliza um modelo de representação do conhecimento, através de regras de produção e probabilidades, objetivando reduzir o trabalho de implantação na construção de sistemas especialistas. Adicionalmente, utiliza uma máquina de inferência compartilhada, com suporte à construção automática de telas e menus, modelando dessa forma uma base de conhecimento, ao mesmo passo que já provê para o usuário a GUI – Guide User Interface.
Sendo assim, é bastante viável a utilização desse sistema para classificação de problemas, uma vez que o usuário responde a uma seqüência de perguntas e o sistema fica encarregado de fornecer respostas que sejam adequadas às solicitações feitas pelo usuário. Este foi um dos motivos que levou à escolha desta ferramenta neste projeto de pesquisa. Saliente-se também que é uma ferramenta grátis, diferente de outras pesquisadas.
5. SEVAC
O SEVAC - Sistema Especialista Voltado a Avaliação do Conhecimento, visa priorizar e analisar o nível de aquisição do conhecimento do aluno no domínio do Reino Animal, uma vez que o computador deve ser utilizado também, na construção do conhecimento do mesmo. A criação de um Sistema voltado ao domínio do Reino animal visa explorar de forma contínua os conceitos vistos em sala de aula, como também fazer uma avaliação do nível de aprendizagem do aluno relativo ao conteúdo estudado. No caso, o domínio proposto para estruturação desse software visa explorar os animais vertebrados onde o aluno deverá identificar tanto sua classificação, quanto as características, habitat e reprodução dos mesmos.
A escolha por esse tipo de domínio para desenvolvimento do software está diretamente relacionada à necessidade da professora de ciências da escola analisada, uma vez que o conteúdo apresentado faz parte da grade curricular da disciplina para a unidade vigente. Dessa forma, essa aplicação apresenta uma metodologia onde se possibilita a utilização de Sistema Especialista na aula de ciências, promovendo assim melhor assimilação e aprendizagem do conteúdo apresentado. Pretende-se com esta proposta atingir os objetivos e validar o uso do Sistema Especialista SEVAC como um recurso didático.
A arquitetura desenvolvida para o SEVAC é composta pela Base de conhecimentos, a qual possui informações que um especialista utiliza. Ela é armazenada em diversas estruturas de árvore binária, onde a interface do programa armazena diretamente as regras encontradas nas estruturas. A Máquina de Inferência é a parte do sistema especialista responsável pelas deduções sobre a base do conhecimento. Por fim, o Banco de Dados Global tem a função de representar as evidências apontadas pelos usuários do sistema especialista durante a consulta.
8
Figura 3: Exemplo de Tela do SEVAC
A consulta se desenvolve por meio de menus de múltipla (ou única) escolha, tal como a figura 3. Até então foram criadas 26 perguntas com respostas.
Figura 4: Tela de Resultados
A tela de resultados (figura 04) exibe, ao final, os conhecimentos corretos obtidos através das respostas assinaladas pelo usuário. Pode aparecer em uma consulta tantas vezes quanto for o número de objetivos a serem alcançados. Sendo assim as janelas são dividas e exibidas por classe (mamíferos, peixes, répteis, anfíbios e aves) onde cada classe tem uma quantidade de perguntas e respostas, capazes de suprir a necessidade de uma avaliação sobre a mesma, as questões assinaladas erroneamente são descartadas pelo sistema apresentando assim apenas às opções corretas, dando sequência à consulta das demais classes; o professor nesse caso soma os acertos e atribui uma nota ao aluno.
6. Resultados
A fim de avaliar a ferramenta desenvolvida, foi selecionado um grupo de alunos e professores que fizeram uso do sistema e, em seguida, responderam a um miniquestionário ressaltando seus pontos positivos e negativos. Todos os alunos entrevistados fazem parte da 6ª série do ciclo fundamental, de uma escola pública municipal.
9
No intuito de comparar as visões do corpo docente e discente, foram criados, de fato, dois questionários, um para cada grupo. O objetivo era investigar como cada grupo via o sistema: pelo lado discente era importante investigar se a ferramenta era mais atrativa e de simples uso; já pelo lado docente, era necessário investigar se ela poderia ser utilizada como recurso pedagógico.
A aplicação da ferramenta junto ao corpo discente foi de grande valia, pois foi possível avaliar através da mesma, a assimilação do conteúdo estudado durante a unidade, de forma interativa e nova. Ficou constatado que tal ferramenta é de fato capaz de dinamizar o processo avaliativo, deixando-o de ser monótono e cansativo tanto para os alunos quanto para os professores. Este questionário foi realizado durante 1 semana. Inicialmente, todos os alunos responderam uma prova tradicional. Em seguida, houve um pequeno curso para explicar o uso do SEVAC para, só então, aplicar uma nova prova por intermédio deste sistema.
Tabela 1: Resultado Parcial do Questionário Aplicad o ao Corpo Discente
10
Tabela 2: Resultado Parcial do Questionário Aplicad o ao Corpo Docente
Analisando os dados obtidos através do questionário aplicado ao corpo discente, observou-se que a grande maioria dos alunos mostrou-se receptível ao sistema desenvolvido. Foram questionados tanto os pontos fortes (interatividade, dinamismo e praticidade) quanto os pontos fracos da ferramenta. O motivo de tal análise foi averiguar principalmente o que falta ser adicionado à ferramenta para deixá-la mais completa. No caso, os itens mais relatados foram: (i) manter um histórico das avaliações, (ii) projetar uma interface com mais recursos visuais.
Ao analisar os dados encontrados na aplicação do questionário junto aos professores, observou-se que a maioria dos docentes está disposta a utilizar o Sistema Especialista como uma ferramenta de avaliação em suas aulas. Uma minoria mostrou alguma reserva e resistência ao sistema e, conseqüentemente, às mudanças necessárias quando se busca uma educação de qualidade.
7. Conclusão
Foi analisada através de questionários a carência de um sistema automatizado e digital, sendo este capaz de tornar a avaliação do ensino elementar mais dinâmica. A partir das análises feitas, foi proposta uma ferramenta capaz de suprir tal necessidade: a utilização de um Sistema Especialista implantado com uma base de conhecimentos capaz de avaliar os conteúdos estudados pelo usuário a partir de suas respostas.
Surge, então, a oportunidade de pensar na aplicação desse sistema como uma forma avaliativa, compreendendo-o como um recurso didático de auxílio pedagógico. Analisando se o conteúdo estudado foi assimilado de forma eficiente, o sistema permitirá ao aluno tomar consciência do seu limite e das suas necessidades de avanço. Considerando que a missão da escola é a auto-formação assistida, visando o pleno desenvolvimento do educando, então a avaliação da aprendizagem, focalizada apenas em conteúdos, não é suficiente. É necessário agregar à avaliação escolar, ao nível do indivíduo, indicadores de avaliação, como este sistema especialista, que permite acompanhar o domínio de competências e habilidades.
11
Saliente-se também que esta pesquisa foi enriquecida através das pesquisas de campo e bibliográficas, entendendo melhor como funciona os Sistemas Especialistas e aplicando-o como uma ferramenta de avaliação no âmbito escolar, trazendo-o como instrumento construtivista na prática docente, podendo assim melhorar a qualidade do ensino-aprendizagem entre professor e aluno.
O sistema especialista desenvolvido nesse trabalho é apenas um protótipo, servindo como base para os trabalhos futuros, uma vez que se faz necessário um aplicativo que disponibilize uma interface mais atrativa ao usuário, com figuras, help on-line, que seja mais flexível e adequada à realidade dos alunos.
Referências
Andrade, P. F. and Lima, M. C. M. (1996). Programa nacional de informática educativa: A utilização da informática na escola pública brasileira (1970-2004). Technical report, MEC: Secretaria de Educacão à Distância.
Giarratano, J. C. and Riley, G. D. (1998). Expert Systems: Principles and Programming, Third Edition. Course Technology, 3 edition.
Harmon, P., Maus, R., and Morrissey, W. (1988). Expert systems: tools and applications. John Wiley & Sons, Inc., New York, NY, USA.
Haydt, R. (1997). Avaliacão do Processo Ensino Aprendizagem. São Paulo, SP, 6 edition.
Kraemer, M. E. P. (2005). A avaliação da aprendizagem como processo construtivo de um novo fazer. http://www.gestiopolis.com/Canales4/rrhh/aprendizagem.htm.
LIA (2010). Expert synta: Manual do usuário. http://www.lia.ufc.br.
Mendes, R. D. (1997). Inteligência artificial: sistemas especialistas no gerenciamento da informação. Ciência da Informação, 26.
Metaxiotis, K. S., Askounis, D., and Nikolopoulos, K. (2006). Identifying the characteristics of successful expert systems: an empirical evaluation. IJITM, pages 21–36.
Nikolopoulos, C. (1997). Expert Systems: Introduction to First and Second Generation and Hybrid Knowledge Based Systems. Marcel Dekker, Inc., New York, NY, USA, 1st edition.
Nilsson, N. J. (1998). Artificial Intelligence: A New Synthesis. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1st edition.
Piaget, J. (1972). Desenvolvimento e aprendizagem.
Valente, J. A. (2009). Diferentes usos do computador. http://www.educacaopublica.rj.gob.br/biblioteca/educacao/edu2007.ghtm.
Wenger, E. (1987). Artificial intelligence and tutoring systems: computational and cognitive approaches to the communication of knowledge. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.
12
Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum
Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves
Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código Postal 7851 – RECIFE – PE – Brasil
{abv,iss2,ifs3,kao}@cin.ufpe.br
Abstract. The increasing demand for software development with higher quality increases its competitiveness and turns critical the creation of a software testing process in parallel with the development’s, including projects that adopt agile methodologies. In this context, the use of tools that support the management of testing activities is essential to project success. This paper presents an open source tool integrated to the FireScrum – a tool for projects management using Scrum - that allows the management of these activities.
Resumo. Com o aumento da competitividade e complexidade no âmbito dodesenvolvimento de software, e a conseqüente exigência por produtos com qualidade assegurada, torna-se imprescindível a realização do processo de testes de software em paralelo ao processo de desenvolvimento, inclusive em projetos que adotam metodologias ágeis. Neste contexto, o uso de ferramentas de suporte à gestão das atividades de testes é essencial para o sucesso dos projetos. Este trabalho apresenta uma ferramenta de código aberto integrada ao FireScrum – ferramenta para gestão de projetos ágeis utilizando Scrum – a qual permite gerenciar as principais atividades de testes.
1. Introdução
É notável a crescente necessidade do uso de produtos de software pelas organizações, sendo muitas vezes essencial à sua sobrevivência. O crescimento da indústria de desenvolvimento de software acarretou um aumento significativo na competitividade entre as organizações provedoras desse serviço. Os usuários de software, consumidores desse serviço, estão cada vez mais exigentes quanto aos atributos de qualidade do software, tais como: desempenho, confiabilidade e usabilidade.
Uma técnica de verificação e validação para certificar artefatos de software, como testes de software, é uma abordagem que contribui para o aumento da qualidade ao longo do processo de desenvolvimento de software [Sommerville 2007]. Todavia, testar software não é uma tarefa trivial, pois envolve pessoas, processos, ferramentas, aplicações, releases (conjunto de artefatos), grupos de scripts (roteiros de testes), dentre outros. Além disso, o uso de planilhas ou documentos de textos não é eficaz para uma gestão de testes produtiva e com baixo custo.
Na literatura da engenharia de software, observa-se que um projeto típico de desenvolvimento de software tem 30% a 50% do custo total do projeto referente aos testes [Myers 1979], [Pressman 2006], [Sommerville 2007] e este número ainda pode ser mais alto para sistemas críticos [Harrold 2000].
13
Dessa forma, para que o custo da atividade de testes não seja um fator limitador para a sua aplicação, usar uma ferramenta adequada para auxiliar na execução dessas atividades otimiza a produtividade.
Neste contexto, ferramentas para gestão de testes em um âmbito de desenvolvimento ágil de software devem auxiliar os desenvolvedores nas tarefas de planejamento e execução dos testes [Beizer 1990]. A partir da execução dos ciclos de testes é possível extrair métricas sobre os casos de testes que obtiveram sucesso ou falha em sua execução. Outras características desejáveis para essas ferramentas de gestão de testes consistem no relacionamento entre casos de testes e requisitos, além do mapeamento e monitoramento dos defeitos detectados.
2. Uma Ferramenta para Gerenciamento de Testes
Esta seção apresenta a ferramenta Test-Module, desenvolvida com o objetivo de auxiliar a especificação e gestão das atividades de teste em projetos de desenvolvimento de software que adotam metodologias ágeis, em particular Scrum, integrada à ferramenta FireScrum [FireScrum 2010]. A Test-Module permite criar casos de testes, associá-los aos requisitos, organizá-los em bibliotecas, gerenciar planos para as execuções de testes em projeto de software e gerenciar ciclos de testes que serão executados, além de captar resultados das execuções, coletar métricas, registrar e monitorar defeitos.
2.1. Visão Geral da Test Module
A Test-Module possui um fluxo lógico de execução. Primeiramente, é necessário criar a biblioteca de casos de teste (Test Suite), que consiste em um agrupamento de casos de testes relacionados. A Figura 1 apresenta a tela de cadastro de bibliotecas, na qual se observa como exemplo a biblioteca “Test Suite Cadastro Evento”.
A Figura 2 apresenta a tela de cadastro de casos de teste (Test Cases), na qual se observa o caso de teste “Test Case – Validar Campos Cadastro Eventos”. Durante o cadastro de casos de testes, a ferramenta permite associá-los a requisitos do projeto (Backlog Item), além de cadastrar o tipo de execução do teste (manual, automático, semi-automático), a prioridade, o cenário e os passos para execução do teste.
Após criar um conjunto de casos de testes, cria-se o plano de testes para o projeto. A Figura 3 apresenta a tela de cadastro de planos de testes (Test Plan), na qual se observa um plano de testes “Test Plan – Validação Cadastros Sistema de Eventos”.
Durante o cadastro do plano de testes, o usuário seleciona os casos de testes, além de inserir o objetivo, a estratégia, a agenda e outros dados importantes para um planejamento de testes.
14
Figura 1: Cadastro de bibliotecas de casos de teste (Test Suites)
Figura 2: Cadastro de casos de teste (Test Cases)
Na última etapa desse fluxo de gerenciamento de testes, o usuário define o ciclo de execução dos testes. A Figura 4 apresenta a tela para a criação de ciclo de testes (Test Cycle) para o plano de testes selecionado. O fluxo lógico apresentado acima segue a seqüencia de agrupamento, criação e planejamento de testes, podendo ser realizado em outra ordem, a critério do usuário. Além desse, ainda há o fluxo de execução, coleta de resultados e coleta de métricas, também contemplados na ferramenta.
15
Figura 3: Cadastro de planos de teste (Test Plans)
2.2. Arquitetura da Teste-Module
A arquitetura geral da ferramenta Test-Module compreende o uso de Adoble Flex [Adobe Flex 2010] como camada de apresentação (front-end) e JAVA [Java 2010] com BlazeDS [BlazeDS 2010] como camada de processamento (back-end). A Figura 5 apresenta uma visão simplificada, porém completa, da arquitetura utilizada. A camada de visão foi desenvolvida através de uma interface RIA (Rich Internet Applications) [RIA 2010]. A camada de negócios empregou o uso de JAVA com o uso de padrões de projeto. O acesso aos dados é realizado através do framework Hibernate [Hibernate 2010], o qual fornece a característica de independência do banco de dados. A seguir, são explanados mais detalhes sobre os elementos presentes na arquitetura.
16
Figura 4: Cadastro de ciclos de execução (Test Cycl es)
Figura 5: Arquitetura geral da Test-Module no FireScrum
2.2.1 Camada de Apresentação
A camada de apresentação fornece ao usuário experiência de uso otimizado dos componentes e menus do sistema construídos com o Adobe Flex – um framework multi-plataforma para desenvolvimento de aplicações RIA. Assim, a aplicação cliente processa algumas informações do sistema no terminal cliente e o processamento complexo fica a cargo do servidor da aplicação no Back-end.
2.2.2 Camada de Processamento
Esta camada utiliza diversas tecnologias para prover todas as funcionalidades desejadas. A linguagem JAVA foi utilizada como plataforma de desenvolvimento e controle dos objetos necessários à Test-Module. O BlazeDS foi utilizado para conectar os dados do back-end com o front-end em Adobe Flex, e a persistência dos dados foi realizada através do framework Hibernate. Mais detalhes sobre a ferramenta Test-Module encontra-se na página do FireScrum [FireScrum 2010].
17
3. Trabalhos Relacionados
Geralmente as ferramentas comerciais para gestão de teste de software limitam-se a oferecer suporte para as principais atividades de teste de software, como criação e gestão de planos, casos e roteiros de testes, além do registro dos resultados e elaboração de relatórios [Beizer 1990]. Um exemplo é o software HP TestDirector, produzido e comercializado pela Hewlett-Packard [HP 2010], que adicionalmente tem suporte a gerenciamento de defeitos. Cobrindo todas as etapas de testes definidas pelo processo unificado da Rational, há o software fabricado e comercializado pela IBM Rational: o Rational TestManager [Rational 2010]. Oferecendo, além das principais atividades de teste, suporte ao desenvolvimento distribuído com gestão ágil de projetos de software, a Borland produziu e comercializa a SilkCentral Test Manager [Borland 2010].
Dentre as ferramentas de código aberto com licença GPL destaca-se a QaTraq [Traq Software 2010a], desenvolvido pela Traq Software, que atualmente também oferece versão comercial [Traq Software 2010b]. A QaTraq oferece suporte para as principais atividades de testes de software, além de modelos de relatórios para resultados de execuções de teste. Outra ferramenta popular de gestão das atividades de testes de software é a TestLink [TestLink 2010], que foi desenvolvida colaborativamente por uma comunidade composta por engenheiros de testes. Esta ferramenta oferece recursos adicionais, tais como priorização e atribuição de tarefas e suporte para integração com ferramentas de gerenciamento de defeitos.
A FireScrum Test-Module destaca-se, em relação a essas ferramentas, por centralizar em uma única aplicação as seguintes características: possui código aberto; está integrada a uma ferramenta de gestão ágil de processo de software; organiza os casos de testes em bibliotecas autônomas, facilitando o reuso destes; gestão dos ciclos execução; interface rica na camada de apresentação web; possui integração direta com ferramenta de gerenciamento de defeitos; e ainda possibilita o monitoramento dos passos que não alcançarem os resultados esperados durante a execução de um caso de teste.
4. Conclusões e Trabalhos Futuros
Neste trabalho foi apresentada uma ferramenta que auxilia os desenvolvedores de software, em contexto ágil, a fazer gestão de testes do projeto de software. A ferramenta Test-Module permite aos usuários definir planos e bibliotecas de testes, casos de testes, ciclos de execução e associá-los aos requisitos. Além disso, a ferramenta permite a integração com ferramenta de gerenciamento de defeitos rastreando a execução ao defeito identificado.
Para trabalhos futuros, a ferramenta deverá evoluir para atender a necessidade de relatórios mais elaborados, ampliar a coleta de métricas e permitir a integração com outras ferramentas de gerenciamento de defeitos consolidadas na comunidade, a exemplo do Bugzilla [Bugzilla 2010] e do Mantis [Mantis 2010]. Por ser um ferramenta de código aberto, e originalmente idealizada dentro do projeto FireScrum, a Test-Module também terá uma evolução associada ao progresso das necessidades oriundas da comunidade de software livre que estiver interessada em gestão ágil de projetos e gestão de testes.
18
5. Referências
Adobe Flex. (2010). http://www.adobe.com/products/flex/, Maio.
Beizer, B. (1990). Software Testing Techniques, John Wiley & Sons, Inc., New York, NY, USA.
BlazeDS. (2010). http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/, Maio.
Borland. (2010). “SilkCentral Test Manager”, http://www.borland.com/us/products/silk/ silkcentral_test/index.html, Maio.
Bugzilla. (2010). http://www.bugzilla.org/, Maio.
FireScrum. (2010). “FireScrum ...the open source Scrum Tool”, http://www.firescrum.com/, Maio.
GPL. (2010). http://www.gnu.org/licenses/gpl.html, Maio.
Harrold, M. J. (2000). "Testing: A Roadmap." Em International Conference on Software Engineering.
Hibernate. (2010). http://www.hibernate.org/, Maio.
HP. (2010). “HP Quality Center”, https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24_4000_100__, Maio.
Java. (2010). http://www.java.com/en/download/faq/whatis_java.xml, Maio.
Mantis. (2010). http://www.mantisbt.org/, Maio.
Myers, G. J. (1979). Art of Software Testing, John Wiley & Sons, Inc.
Pressman, R. S. (2006). Engenharia de Software, McGraw Hill, 6ª Edição.
Rational. (2010). “Rational TestManager”, http://www-01.ibm.com/software/awdtools/test/manager/, Maio.
RIA. (2010). http://en.wikipedia.org/wiki/Rich_Internet_application, Maio.
Sommerville, I. (2007). Engenharia de Software, Addison Wesley, 8ª Edição.
TestLink. (2010). http://testlink.sourceforge.net/docs/testLink.php, Maio.
Traq Software. (2010a). “QaTraq - Open Source”, http://sourceforge.net/projects/qatraq/, Maio.
Traq Software. (2010b). “QaTraq Software”, http://www.testmanagement.com/, Maio.
19
LSVF: A heuristic search to reduce the backtracking calls when solving Constraint Satisfaction Problems
Cleyton Rodrigues1, Eric Galvão1, Ryan Azevedo1
¹ Centro de Informática, Universidade Federal de Pernambuco, Av. Professor Luís Freire 50740-540, Recife, Pernambuco, Brasil
{cmor, ergd, rra2}@cin.ufpe.br
Abstract. Along the years, many researches in the Artificial Intelligence (AI) field seek for new algorithms to reduce the amount of memory and time consumed for general searches in the family of constraint satisfaction problems. Normally, these improvements are reached with the use of some heuristics which either prune useless tree search branches or even “indicate” the path to reach the solution (many times, the optimal solution) more easily. Many heuristics were proposed in the literature, like Static/ Dynamic Highest Degree heuristic (SHD/DHD), Most Constraint Variable (MCV), Least Constraining Value (LCV), and while some can be used at the pre-processing time, others just at running time. In this paper we propose a new pre-processing search heuristic to reduce the amount of backtracking calls, namely the Least Suggested Value First (LSVF). LSVF emerges as a practical solution whenever the LCV can not distinguish how much a value is constrained. We present a pedagogical example to introduce the heuristics, realized through the general Constraint Logic Programming CHRv, as well as the preliminary results.
Keywords: Constraint, Satisfaction Problem, Heuristics, Constraint Logic Programming.
1 Introduction
Constraint Satisfaction Problems (CSP) remains as one of the most prominent AI research fields. Having a wide range of applicability, such as planning, resource allocation, traffic air routing, scheduling [Brailsford, Potts and Smith 1999], CSP has been largely used either for toys or even for real large complex applications. Furthermore, in general, CSP are NPcomplete and they are combinatorial in nature.
Amongst the various methods developed to handle this sort of problems, in this paper, our focus concerns the search tree approach coupled with the backtracking operation. In particular, we address some of the several heuristics used so far to reduce (without guaranties) the amount of time need to find an solution, namely: Static/ Dynamic Highest Degree heuristic (SHD/DHD), Most Constraint Variable (MCV) and Least Constraining Value (LCV) [Russel and Norvig 2003].
Some problems, however, like the ones common referred as instances of the Four Color Map Theorem [Robertson et al 1997], present the same domain for each entity, making the LCV heuristic impossible to decide the best value to the asserted first.
20
For these cases, we propose a new pre-processing heuristic, namely Least Constraint Value First (LCVF), which can bring significant gains by a simple domain value sorting, respecting an order made by the following question “Which is the least used value to be suggested now?”. Additionally, we enumerate some assumptions to improve the ordering. Along the paper, we show some preliminary results with remarkable reduce of backtracking calls.
This paper is organized as follows: Section 2 explains briefly the formal definition of CSP and the most common heuristics used in the class of CSP; following, Section 3 details what is CHRv and why we have chosen it to our examples; Section 4 introduces the LCVF heuristic with a pedagogical example, highlighting some preliminary results, and finally, Section 5 presents the final remakes and the future works.
2 CSP and Heuristics
Roughly speaking, CSP are problems defined by a set of variables X = {X1, X2,…, Xn}, where each one (Xi) ranges in a known domain (D), and a set of Constraints C = {C1, C2,…, Cn} which restricts specifically one or a group of variables with the values they can assume. A consistent complete solution corresponds to a full variable valuation, which is further in accordance with the constraints imposed. Along the paper, we refer to the variables as entities. Figure 1 depicts a pedagogical problem.
Figure 1 - A pedagogical Constraint Satisfaction Pr oblem.
In the above figure, the entities are {X1, X2, X3, X4, X5, X6, X7} and each one can assume one of the following value: D = {r,g,b}, referring to the colors, red, green, and blue, respectively. The only constraint imposed restricts the neighboring places (that is, each pair of nodes linked by an arc) to have different colors. As usual, this problem can be reformulated into a search tree problem, where the branches represent all the possible paths to a consistent solution. By definition, each branch not in accordance with C, must be pruned. The backtracking algorithm, a special case of depth-first, is neither complete nor optimal, in case of infinite branches [Vilain, Kautz and Beek 1989]. As we have not established an optimal solution to the problem, our worries rely only upon the completeness of the algorithm. However, we only take into account problems in which search does not lead to infinite branches, and thus, the completeness of the problem is ensured.
21
2.2 Search Heuristics
Basically, the backtracking search is used for this sort of problems. Roughly, in a depth-first manner, a value from the domain is assigned, and whenever na inconsistency is detected, the algorithm backtracks to choose another color (another resource). Although simple in conception, the search results are far to be satisfactory. Further, this algorithm lacks for not being intelligent, in the sense to re-compute partial valuations already prove to be consistent. A blind search, like the backtracking, is improved in efficiency employing some heuristics. Regarding CSP, general heuristics (that is, problem-independent, opposite to domain-specific heuristics, as the ones in A* search [Dechter and Pearl 1985]) methods speed up the search while removing some sources of random choice, as:
• Which next unassigned variable should be taken?
• Which next value should be assigned?
The answer for the questions above arises by a variable and value ordering. The most famous heuristics are highlighted below. Note that the two first methods concern the variable choice, and the later refers to the value ordering:
• Most Constrained Variable avoids useless computations when an assignment will eventually lead the search to an inconsistent valuation. The idea is to try first the variables more prone to error;
• When the later method is useless, the Degree Heuristic serves as a tie-breaker, once it calculates the degree (number of conflicts) of each entity;
• The Least Constraining-Value, in turn, sorts decreasingly the values in a domain respecting how much the value conflicts with the related entities (that is, the values less shared are tried first).
As said before, we have restricted our scope of research to the class of problems similar to the family of the four color theorem, where the domain is the same for each variable. In this sense, the LCV heuristic is pointless since the “level” of constraining for each value is the same. This drawback force us to search alternatives for sort the values of CSP in similar situations, but also improving the efficiency. However, before to present the solution, it is worth to explain why we have used the logic constraint programming CHRv to carry out the tests.
3 CHRV
Constraint Handling Rules with Disjunction (CHRV) [Abdennadher and Schütz 1985] is a general concurrent logic programming language, rule-based, which have been adapted to a wide set of applications as: constraint satisfaction [Wolf 2005], abduction [Gavanelli, Alberti and Lamma 1985], component-development engineering [Fages, Rodrigues and Martinez 2008], and son on. It is designed for creation of constraint solvers.
CHRV is a fully accepted logic programming language, since it subsumes the
main types of reasoning systems [Frühwirth 2008]: the production system, the term rewriting system, besides Prolog rules. Additionally, the language is syntactically and semantically well-defined [Abdennadher and Schütz 1985].
22
Concerning the syntax, a CHRv program is a set of rules defined as:
rule_name@�� ⁄ �� ⇔ G|B
Rule_name is the non-compulsory name of the rule. The head is defined by the predicates represented by Hk and Hr, with which an engine tries to match with the constraints in the store. Further, G stands for the set of guard predicates, that is, a condition imposed to be verified to fire any rule. Finally, B is the disjunctive body, corresponding to a set of constraints added within the store, whenever the rule fires. The logical conjunction and disjunction of predicates are syntactically expressed by the symbols ‘,’ and ‘;’, respectively. Logically, the interpretation of the rule is as follows:
∀��� �� → ���� ∧ � ↔ �∃�� ��⁄ � ∧ �� �� ,�ℎ����� =����� ∪ ������ ∪ �����,�� ��⁄ = ����� ���⁄
(1)
For the sake of space, we ask the reader to check the bibliography for further reference to the declarative semantics.
The problem depicted in figure 1 is represented by the logical conjunction of the following rules: �@����� ==> �, ���1,�1,���7,�7,���4,�4,���3,�3, ���2,�2,���5, �5,���6, �6 �1@���1,� ==> � = ��;� = ����;� = � !�. �7@���7,� ==> � = ��;� = ����;� = � !�. �4@���4,� ==> � = ��;� = ����;� = � !�. �3@���3,� ==> � = ��;� = ����;� = � !�. �2@���2,� ==> � = ��;� = ����;� = � !�. �5@���5,� ==> � = ��;� = ����;� = � !�. �6@���6,� ==> � = ��;� = ����;� = � !�. �@� ≤> ���1, �2,�,���1, �4,���1, �7, ���2, �6, ���3, �7, ���4, �7,���4, �5,���5, �7, ���5, �6. �1@��"#,"$,��"#,�#,��"$,�% <=> �# = �$|��#
The first rule ‘f’ introduces the constraints into the store, which is a set of predicates with functor d and two arguments: the entity and a variable to store the valuation of the entity. The seven following rules relate the entity with the respective domain. Additionally, rule ‘m’ adds all the conceptual constraints, in the following sense: n(Ri,Rj) means there is an arc linking Ri to Rj, thus, both entities could not share the same color. Finally, the last rule is a sort of integrity constraint. It fires/ whenever the constraints imposed is violated. Logically, it says that if two linked entities n(Ri,Rj) shares the same color (condition ensured by the guard), then the engine needs to backtrack to a new (consistent) valuation.
In the literature, many operational semantics was proposed, as [Abdennadher, Frühwirth and Meuss 1999]. However, the ones most used in CHRv implementations are based on the refined semantics [Duck at al 2004] (as the SWI-Prolog version 5.6.52 [SWI-Prolog 2010] used in the examples carried out along this paper). According the refined operational semantics, when more than one rule is possible to fire, it takes into
23
account the order in which the rules were written in a program. Hence, as SHD heuristic orders the entities to be valued in accordance with the level of constraining, this pre-analysis help us to write the rules based on this sort. Thus, we could concentrate our effort on the order of the values in the domain.
4 Least Suggested Value First – LSVF
The last section has introduces the rule-based constraint language, CHRv. Many aspects of the operational semantics were left unexplained, and we encourage the reader to check the references for additional information. However, some points need be discussed to clarify the technique developed to improve the search, decreasing the amount of backtracking calls. The first point, “which rule will trigger”, was discussed before. The second important subject of discussion is the order of which the values are taken from the domain in the search. We have already said that the logical disjunction is denoted in the body of a CHRV
rule, syntactically expressed by ‘;’. In order to maintain consistency with the declarative semantics, CHRV
engine tries all the alternatives since the user tell the engine to do so. A disjunctive body is always evaluated from left-to-right.
�1@���1,� ==> � = ��;� = ����;� = � !�
Taking a rule from the example (as stated above), the engine tries the following order of valuation for X1: (1) red, (2) green and, (3) blue. All the rules were created respecting the same valuation order.
At first glance, we can note a relevant problem: if all the entities try first the same color, and we know that these entities are related, a second evaluated entity always needs to backtrack. Furthermore, since the entities shares the same domain, LCV is pointless: each value has the same level of constraining. In order to make our idea clear, we introduce a second example.
Figure 2 - An example regarding the order of the co lors.
The Figure 2 shows the motivation problem for the new heuristics discussed. There are 3 entities {X1,X3,X7}, each one sharing the same domain. Let us respect the order of valuation from left to right, and the order of variable chosen based on the numerical order. Thus, the engine works as follows:
I. X1 is chosen, and the color red is taken;
II. X3 is chosen, and the color red is taken;
III. Inconsistency found: backtracking;
24
IV. X3 is chosen, and the color blue is taken;
V. X7 is chosen, and the color red is taken;
VI. Inconsistency found: backtracking;
VII. X7 is chosen, and the color blue is taken;
VIII. Inconsistency found: backtracking;
IX. X7 is chosen, and the green is taken.
Following, in the figure 3, the values order is changed to avoid, as much as possible, the conflicts.
Figure 3 - The same example with domain reordered.
The engine now works as stated below:
I. X1 is chosen, and the color red is taken;
II. X3 is chosen, and the color blue is taken;
III. X7 is chosen, and the color green is taken.
The above modification prevented the backtracking calls, and the solution was reached just with three steps, unlike the last example, which did the same, in 9 steps. Evidently, in practice, we can not avoid all backtracking calls, but each reduction is well-suited for the overall search time-consumption.
4.1 How the heuristic works?
Our propose is to enjoy the operational semantics addressed by the CHRV
implementation to sort the order in which the values from the domain is asserted, decreasing the amount of backtracking calls. We believe this reduction can be well appreciated in large and complex problems, where the time is a relevant factor.
The approach does not yield only the first color, but the entire domain. In our case, the focus is in problems with three or four colors. In this context, the members of the set of entities are categorized in accordance with the level of corresponding restriction:
• Soft Entities, that is, less constrained;
• Middle Entities, that is, half constrained;
• Hard Entities, that is, more constrained.
25
Hence, instead of proposing a solution of random sorting, we have taken the following assumptions:
• Usually, the entities less constrained are likely linked to others more constrained, and, further, the entities less restricted are not connected to each other (if this were the case, the entities owned other restrictions than those that connect them, and they would be deemed more constrained). Thus, the domain of these entities are sorted in the same manner;
• Normally, hard entities are linked to middle ones, and thus the order of valuation must be in conformance to this fact, example, if a hard entities domain is ordered like (1)red, (2)green, (3)blue, the middle should be sorted like (1)blue, (2) green (3)red, that is, the less suggested value first.
• The first value assumed by the hard entities should be the last for the soft and middle entities, since potentially both are linked to the former (this is why they were classified as hard).
In order to exemplify this approach, we are going to show the reformulation of the example used along this paper, illustrating gradually the gains obtained.
With respect the problem, we divided the set of entities as follows: (i) soft entities: {X2,X3,X6}, (ii) middle entities: {X4,X5}, and (iii) hard entities {X1,X7}, with 6, 9 and 12 conflicts, respectively. What was considered for division was precisely the amount of conflict in relation to other variables, done according the Static Highest Degree (SHD) heuristic.
Table 1 summarizes the amount of inferences made and the number of backtracking calls. The time is a relevant aspect only when evaluated to large problems.
Table 1 - First Results with the LSVF Heuristic
Sorting Level Inferences Backtracking Calls
I 4,897 8
II 4,694 7
III 4,415 6
IV 4,208 5
Not accidentally, the table was populated according to the level of values sorted in respect to the assumptions raised earlier. Each level corresponds to a different CHRV
program. The Sorting Levels are the following:
Table 2 - Domain used for Entities
Level Soft Midle Hard
I red, green blue red, green blue red, green blue
II red, green blue blue, red, green red, green blue
III green, red blue blue, red, green red, green blue
IV green, blue, red blue, green, red red, green blue
In the Level I, the heuristic was not used. It is worth to keep their results in the table to compare with the other levels, where the assumptions (which define the LSVF)
26
were gradually applied. Level II has changed the first suggested color of the Middle entities with respect the hard. Following, the level III has changed the first color of domain of soft entities with respect the others (middle and hard). There has been a reduction of 25% of backtrack calls in accordance with the level I. Finally, the level IV has used all assumptions talked, and both measures were visibly reduced. In this latter case, the engine backtracks 5 times, three calls less than the original program. Note that level IV obeys all the assumptions discussed, and the results obtained were remarkable.
5 Final Remakes and Future Work
The preliminary results obtained were very satisfactory. We might see that, as we organize the values of the domain of the entities, gradually the search has been getting more efficient with respect to the number of inferences necessary to reach a solution. A small comparison between the level I and level IV, the program without the heuristic and the program totally in accordance with LSVF, respectively, shows a significant reduction in the amount of backtrackings and inferences realized.
It was important to mention that we are neither worried with optimal solutions nor with all the solutions for the problem. We only focus on our overall effort to reach a solution, and nothing else.
In order to validate completely the LSVF heuristics, our next step is to analyze the approach with more complex problems. Additionally, our aim is to check the time resource allocated for this kind of problem, since this was not possible due to the size of the example discussed (all instances executed in less than one second).
Acknowledgments. We acknowledge REUNI for financial support and the Center of Informatics of Federal University of Pernambuco – CIn/UFPE – Brazil for support in this research.
References
Brailsford, S., Potts, C., Smith, B. (1999) Constraint satisfaction problems: Algorithms and applications. European J. Operat. Res. 119, 557—581.
Russel, S., Norvig, P. (2003) Artificial Intelligence: A Modern Approach. New Jersey: Prentice-Hall, 2nd edition, 143—144.
Robertson, N., Sanders, D. P., Seymour, P. D., Thomas, R. (1997) The four colour theorem, J. Combin. Theory Ser. B., 2--44
Vilain, M., Kautz, H., Beek, P. (1989) Constraint propagation algorithms for temporal reasoning: A revised report. In D. S. Weld and J. de Kleer, editors, Readings in Qualitative Reasoning about Physical Systems, 373--381.
Dechter, R., Pearl, J. (1985) Generalized best-first search strategies and the optimality of A*. J. ACM 32, 505—536.
Abdennadher, S., Schütz, H. (1985) CHRv: A Flexible Query Language, In Proceedings of the Third International Conference on Flexible Query Answering Systems, pp.1--14, May 13-15.
27
Wolf, A. (2005) Intelligent search strategies based on adaptive Constraint Handling Rules. Theory Pract. Log. Program. 5, 4-5 (Jul. 2005), 567—594.
Gavanelli, M., Alberti, M., Lamma, E. (1985) Integrating Abduction and Constraint Optimization in Constraint Handling Rules. In Proceeding of the 2008 Conference on ECAI 2008: 18th European Conference on Artificial intelligence. M. Ghallab, C. D. Spyropoulos, N. Fakotakis, and N. Avouris, Eds. Frontiers in Artificial Intelligence and Applications, vol.178. IOS Press, Amsterdam, The Netherlands, 903—904.
Fages, F., Rodrigues, C. M. O., Martinez, T. (2008). Modular CHR with ask and tell. In T. Schrijvers, F. Raiser, and T. Frühwirth, editors, CHR '08: Proc. 5th Workshop on Constraint Handling Rules, Hagenberg, Austria, 95--110, 2008. RISC Report Series 08-10, University of Linz, Austria.
Frühwirth, T. (2008) Welcome to Constraint Handling Rules. In Constraint Handling Rules: Current Research Topics, T. Schrijvers and T. Frühwirth, Eds. Lecture Notes In Artificial Intelligence, vol. 5388. Springer-Verlag, Berlin, Heidelberg, 1—15.
Abdennadher, S., Frühwirth, T., Meuss, H. (1999) Confluence and Semantics of Constraint Simplification Rules.Constraints 4, 2 (May. 1999), 133-165.
Duck, G. J., Stuckey, P. J., De la Banda, M. G., Holzbaur, C. (2004) The Refined Operational Semantics of Constraint Handling Rules. In Proceedings of the 20th International Conference on Logic Programming, B. Demoen and V. Lifschitz, Eds., 90-104.
SWI-Prolog (2010) Reference Manual. Avaliable in http:// gollem.science.uva.nl/SWIProlog/Manual/ Contents.html. Last access in 15th March 2010.
28
O Lixo eletrônico no Brasil: Leis e Impactos Ambientais
Rodrigo Diego Gonçalves Ferreira1, Cleyton Mário de Oliveira Rodrigues2
1 FACOL – Faculdade Osman da Costa Lins, Vitória de Santo Antão – PE – Brasil 2 Centro de Informática – Universidade Federal de Pernambuco, (CIn/UFPE) Código
Postal 7851 – RECIFE – PE – Brasil
[email protected], [email protected]
Resumo: Uma preocupação mundial e com forte impacto social, econômico e, principalmente, ecológico é o desenvolvimento sustentável. Muito se fala sobre degradação do meio ambiente, contudo, pouco se faz para conter esse problema que ameaça as futuras gerações do planeta. Este artigo informativo denota, neste âmbito, uma visibilidade aos fatores que levaram o Brasil a ser criticado por instituições não-governamentais de diversos lugares do mundo por não ter uma legislação vigente sobre os aspectos do lixo eletrônico, bem como a falta de regulamentação de práticas sustentáveis de recolhimento das sucatas eletroeletrônicas pelos seus respectivos fabricantes. Também são motivos de debate e questionamento as metas do poder executivo e legislativo do país, com respeito às ações dos fabricantes de eletroeletrônicos.
1. Introdução
Com o grande avanço das tecnologias e das suas inovações em meio ao consumismo na busca da comodidade e do conforto, a população sente a necessidade de sempre estar atenta às novas tendências do mercado, ou seja, equipamentos mais modernos e poderosos, com novas funções e serviços integrados. Com o aumento do poder de compra do consumidor brasileiro, tornou-se comum a constante troca de seus equipamentos tecnológicos, como: celulares, computadores, notebooks, TVs, geladeiras, entre outros. Neste contexto, observa-se que a velocidade com que os consumidores passam a procurar por novos produtos, é bem superior ao que acontecia há tempos atrás [Planeta Sustentável 2008].
O ciclo de vida destes produtos é curto, aumentando conseqüentemente, o descarte irregular de materiais eletrônicos no meio-ambiente. A poluição ambiental, gerada pela poluição eletrônica através de seus metais pesados, ocasiona danos não só ao meio ambiente, mas também à saúde humana. Grande parte desse lixo tóxico proveniente das sucatas eletrônicas é jogado em terrenos baldios, queimado a céu aberto ou recolhido pela coleta de lixo fornecida pelos governos municipais, mas sem que exista nenhum tipo de seleção ou tratamento destes materiais tóxicos.
Instituições mundiais voltadas à preservação do meio ambiente apontaram, nos últimos meses, o Brasil como um dos maiores produtores de lixo eletrônico entre os países emergentes: Brasil, México, Índia e China. O país foi apontado por abandonar aproximadamente 96,8 mil toneladas de componentes utilizados em computadores e mais de 35 milhões de toneladas de sucatas eletrônicas por ano, uma produção de lixo maior que a média dos outros países [Ecodebate 2010]. Mesmo com a grande produção de lixo eletrônico, não houve nenhuma mudança legislativa com a formulação de normas nacionais, impossibilitando uma fiscalização adequada de combate ao desperdício irracional de eletroeletrônicos.
29
Este artigo toma o aspecto técnico-ambiental, objetivando a conscientização dos consumidores e mostrando o posicionamento político, legislativo, de Organizações Não Governamentais (ONGs) e de fabricantes que atuam no mercado Brasileiro.
2. Brasil: atual situação e legislação
É chamado de lixo eletrônico, também conhecido como e-lixo ou sucata eletrônica, todo material que é descartado e compõe os eletroeletrônicos, como resíduos sólidos, componentes tóxicos e metais pesados. O Greenpeace [GREENPEACE] e a Organização das Nações Unidas (ONU) [ONU] consideram o Brasil como o país emergente que gera maior volume de lixo eletrônico, além de maior produtor de e-lixo per capita por ano. Também, o país tem o maior número de toneladas de geladeiras abandonadas a cada ano por pessoa, e é um dos líderes em descartar celulares, TVs e impressoras, entre os países emergentes. Na composição de um computador, por exemplo, são utilizados diversos produtos considerados tóxicos ao ser humano, como: sílica, plástico, ferro, alumínio, cobre e chumbo. A tabela 1 relaciona alguns destes metais com os problemas que podem causar à saúde das pessoas.
Tabela 1 - Danos causados por metais pesados
METAL PESADO DANOS À SAÚDE
Chumbo Atinge o sistema nervoso, a medula óssea e os rins, gerando lesão renal e cerebral e fraqueza muscular.
Mercúrio Concentra-se em diversas partes do corpo como pele, cabelo, glândulas sudoríparas e salivares, tireóide, sistema digestivo, pulmões, pâncreas, fígado, rins, aparelho reprodutivo e cérebro, provocando inúmeros problemas de saúde. (Intoxicação do sistema nervoso central).
Manganês Causa problemas respiratórios e efeitos neurotóxicos.
Sílica Causa problemas respiratorios, provocando o endurecimento dos pulmões, podendo assim ser fatal.
Alumínio A ingestão pode causar: demência, danos ao sistema nervoso central, perda de memória e dores musculares.
Com as políticas de incentivo e marketing pela compra de computadores por todos os segmentos da sociedade, o computador está cada vez mais barato e conseguir um destino ecológico e socialmente correto para a máquina antiga torna-se complicado. Seu destino acaba sendo, dessa forma, o lixo comum. As autoridades brasileiras devem criar e fazer valer o cumprimento das leis e regimentos estaduais de combate a degradação da natureza causada pelo e-lixo. Cabe também aos órgãos ligados ao meio ambiente a fiscalização e autuação aos fabricantes que descumprirem o normativo nacional. Existe em tramitação, a Política Nacional de Resíduos Sólidos (PNRS) [PNRS 2010]. Aprovado depois de 19 anos pala Câmara dos Deputados, o projeto ainda passará pelo senado e, por último, pelo executivo. Os eletroeletrônicos estão inseridos no artigo 33 do plano, sendo divididos em três categorias: eletrodomésticos, bens de informática e eletrônicos em geral.
30
Constam no PNRS penalidades previstas na Lei 13576, que trata de crimes ambientais. As leis que atualmente regem as ações no Plano Nacional Ambiental Brasileiro não são específicas aos resíduos eletrônicos, e sim, aos resíduos sólidos de forma geral. Alguns estados, como Minas Gerais, Paraná, Rio de Janeiro, Piauí, Espírito Santo e Pernambuco contam com uma legislação direcionada apenas aos resíduos sólidos (de uma forma geral), incluindo a poluição por metais pesados, entretanto, não existe citação sobre o recolhimento de produtos eletrônicos pelos respectivos fabricantes, exceto quando há punições.
No estado de São Paulo existe a lei 13.576/09, da autoria do Deputado Estadual Paulo Alexandre Barbosa (PSDB), a qual instituiu que os fabricantes de eletrônicos são responsáveis pela reciclagem, gerenciamento e destino final do lixo tecnológico. Essa é a única lei específica sobre elixo. O Brasil ainda é, de uma forma geral, carente de um normativo relacionado à poluição eletrônica. A lei 3.968 de 31 de agosto de 1981, que estabelece a PNMA [PNMA], seus fins e mecanismos de formulação e aplicação, constituiu o Sistema Nacional do Meio Ambiente (SISNAMA) [SISNAMA] e instituiu o Cadastro de Defesa Ambiental. A PNMA tem como principais objetivos a melhoria e preservação da qualidade ambiental, defendendo o desenvolvimento socioeconômico do país, bem como a segurança e a vida humana.
Como abordado ao longo do artigo, o Brasil tem um normativo regido por órgãos estaduais e nacionais de preservação do meio ambiente, baseado numa legislação interna a cada departamento ambiental. Nestes últimos anos, existe uma preocupação parlamentar nacional para formulação de um plano de reciclagem e reaproveitamento de resíduos eletroeletrônicos, onde torna o fabrincante responsável pelo recolhimento dos produtos gerados em suas unidades fabris, incluídos nas leis de resíduos sólidos.
3. Legislação internacional do e-lixo
A União Européia (UE) possui a diretiva ROSH [Lei Lixo Eletrônico] que restringe em seis substâncias tóxicas a produção de eletroeletrônicos, onde responsabiliza também os produtores pela redução destas substâncias: chumbo, mercúrio, cádmio, crómio hexavalente, polibromatos (PBB e PBDE). Esta legislação foi implantada e adaptada pela China em 2006, três anos após a implantação da UE. A Eletronic Equipament Collection dos Estados Unidos (EUA) impõe as responsabilidades da reciclagem e reaproveitamento ao fabricante. A legislação foi criada em 2008 e estima que até 2015 aproximadamente 25% de todo lixo eletrônico produzido pelo país será reaproveitado, além de deixar claro que os fabricantes devem submeter um plano de tratamento às prefeituras, tornando-se proibido descatar lixo eletrônico junto ao lixo comum, isto é, deve-se destiná-los a aterros sanitários.
No Canadá e nos EUA, além da obrigação do recolhimento de produtos ser dos fabricantes, a legislação ajudou a definir as reponsabilidades do consumidor (exemplo, mandar o produto para reciclagem), do fabricante (criação da rede coletora) e do estado (mantenedora da reciclagem e dos recursos utilizados). No Japão, o governo é o responsável pelo processo de coleta e logística reversa, os fabricantes são responsáveis pela reciclagem e neutralização adequada dos componentes tóxicos (a legislação Home Appliance Recycling Law). Com base nessa legislação, muitas empresas se adaptaram as regras estabelecidas internacionalmente, mas outras não.
31
4. Como as grandes empresas comportam-se hoje em dia?
A maioria dos fabricantes de eletroeletrônicos, eletrodomésticos e empresas de tecnologia não anexam nos seus produtos informações suficientes sobre o recolhimento dos equipamentos descartados, como: Apple, CCE, Le novo, LG, Positivo e Samsung. Mais grave ainda, empresas como Acer, Dell, Philips, Siemens, TIM e Semp Toshiba não dispõem de nenhuma informação sobre a devolução de seus produtos.
As seis primeiras empresas citadas, nos dias de hoje, procuram realizar ações sustentáveis na fabricação de seus produtos, como exemplo, os equipamentos levam em sua composição matériasprimas recicladas, como o plástico. Além disso, em seus componentes, os metais pesados são utilizados em quantidades menores, assim as fabricantes integram um rank no programa do Guia de Eletrônicos Verdes do Greenpeace [Baixaki 2010].
As grandes empresas mundiais estão seguindo um padrão de reutilização e mudança de matéria-prima na fabricação de produtos eletroeletrônicos integrando assim a corrente da TI VERDE (Tecnologia da Informação Verde). Empresas como Samsung, Toshiba, Nokia, Sony, Lenovo e Dell estudam políticas internas de reciclagem com a participação e adesão de ações sugeridas pelas instituições voltadas à defesa e à preservação do meio ambiente, como o Greenpeace. A instituição mostra para o mundo um rank de empresas que realizam atividades em favor do meio ambiente, o chamado Guia de Eletrônicos Verdes. O guia é publicado trimestralmente, como forma de fazer com que a indústria de eletrônicos encare o problema do lixo que produz. A intenção é fazer que os fabricantes parem de usar produtos tóxicos em seus produtos.
5. Reciclagem: Um caminho aberto a novas oportunidades
O setor de reciclagem de Resíduos de Aparelhos Elétricos e Eletrônicos, ou simplesmente RAEE, é um nicho do mercado cheio de potencial e que já começou a ser trabalhado. O ramo ganha espaço à medida que aumenta o consumo de eletroeletrônicos em geral. Desmontar, triturar e transformar diversos equipamentos é o que as empresas de remanufatura fazem, e ao mesmo tempo evitam a contaminação do ambiente por materiais tóxicos. Com o crescimento do mercado brasileiro, existem empresas que encontraram a partir das sucatas uma oportunidade de oferecer reciclagem para grandes fabricantes. Uma delas é a Oxil (lixo ao contrário), de Paulínia no Estado de São Paulo [OXIL].
A companhia tem nove grandes clientes, dos quais não revela os nomes por motivos contratuais, e processa 2 mil toneladas de produtos por ano. A empresa conseguiu reciclar 99,7% do material enviado. O ato de transformar equipamentos fora de uso em matéria-prima é chamado de “manufatura reversa”. Na Universidade de São Paulo (USP) foi criado, em 2009, o primeiro centro de descarte e reciclagem de equipamentos eletrônicos, criação pioneira de um órgão público no Brasil. O projeto visa recuperar computadores, notebooks e equipamentos de telefonia móvel e fixa. Os equipamentos podem ter dois destinos: são encaminhados para reciclagem ou destinados a ONGs e projetos sociais, caso possam ainda ser usados. O projeto cria a oportunidade de reutilização gerando a inclusão digital em comunidades carentes administradas por instituições não governamentais.
As grandes empresas também garantem a reutilização de seus produtos, como a IBM que encontrou uma saída criativa para o descarte de seus monitores. Até o ano
32
2000, o destino dos resíduos descartados era o aterro. A partir daquele ano, o processo foi interrompido e os monitores foram armazenados até que uma solução ambiental fosse encontrada. Em 2008, 180 toneladas de monitores foram para a reciclagem. Um parceiro da IBM coletou o vidro e o transformou em bolinhas de gude, que hoje estão por aí, no mercado, à venda. Quanto à Dell, seus equipamentos usados podem ter dois destinos, ou são mandados para a reciclagem ou são recondicionados e doados para projetos sociais (mais de 46 milhões de toneladas de equipamentos). No Brasil, algumas das empresas acima citadas não desenvolvem estas atividades de recuperação/reciclagem, por ausência de ações repressivas por parte do cumprimento de leis e normas dos órgãos ambientais, levando em consideração que nosso país ainda não tem uma legislação específica sobre o e-lixo.
6. Concluindo
O lixo eletrônico aumenta a cada dia, pois com o constante crescimento das inovações tecnológicas o consumidor segue a mudança de equipamentos com a mesma frequência. O Brasil ainda hoje é alvo de críticas por parte das instituições internacionais, pela grande quantidade de sucata gerada e pela carência de políticas ambientais relacionadas ao assunto. Neste ano de 2010, depois de um 2009 de críticas, a Câmara dos Deputados resolveu aprovar um projeto de lei engavetado há 19 anos.
Além das ações de grandes fabricantes e do surgimento de empresas voltadas para reciclagem das sucatas eletrônicas, em algumas cidades, projetos de recuperação de sucatas tecnológicas são desenvolvidos por grupos de amigos, que recolhem equipamentos computacionais descartados para serem recuperados e, posteriormente, destinados a crianças carentes e entidades sociais, como forma de inclusão digital. O problema do lixo eletrônico no Brasil será resolvido (amenizado, pelo menos) quando houver efetivamente as devidas leis criadas, e os órgãos de defesa possam fiscalizar e punir os fabricantes que infringirem as resoluções contidas no normativo nacional. Por fim, é importante destacar que cada consumidor pode atuar como um elemento ativo nesse processo, seja conscientizando os menos informados, seja procurando empresas que preguem a sustentabilidade, ou até atuando criativamente na transformação do e-lixo em algo novo, que possa ser usado por aqueles menos afortunados.
Recursos
Planeta Sustentável (2008) Consumismo Gera Lixo - http://planetasustentavel.abril.com.br/noticia/atitude/conteudo_278998.shtml
Ecodebate (2010) Estudo mostra Brasil no topo do ranking de produção per capita de lixo eletrônico vindo de computadores - http://www.ecodebate.com.br/2010/03/25/estudo-mostra-brasil-no-topo-do-rankingde-producao-per-capita-de-lixo-eletronico-vindo-de-computadores/
GREENPEACE BRASIL - http://www.greenpeace.org/brasil/
ONU – Organização das Nações Unidas - http://www.onu-brasil.org.br/
PNRS (2010) http://www.revistasustentabilidade.com.br/documentos-de-referencia/pnrs-textoaprovado-na-camara-10-03-2010
PNMA - http://www.semarh.al.gov.br/programas/programa-nacional-do-meio-ambiente
33
SISNAMA - www.mma.gov.br/port/conama/estr1.cfm
Lei Lixo Eletrônico. LEI ROSH DA UNIÃO EUROPÉIA - http://www.lixoeletronico.org/system/files/UE_ROHS_PT.pdf
Baixaki (2010) Ranking de Empresas Verdes - http://www.baixaki.com.br/info/3634-ranking-de-empresasverdes.htm
OXIL MANUFATURA REVERSA - http://oxil.com.br/
Revista Sustentabilidade (2010) LEI BRASILEIRA DO E-LIXO - http://www.revistasustentabilidade.com.br/documentos-dereferencia/pnrs-texto-aprovado-na-camara-10-03-2010
34
An Experimental Research on the Relationships between Preferences for TechnicalActivities and Behavioural Profile in
Software Development
Fabio Q. B. da Silva, Ana Cristina F. César
Centro de Informática – UFPE Recife, Brasil
{fabio, acfc}@cin.ufpe.br
Resumo - Este artigo descreve uma pesquisa de campo conduzida a fim de identificar as correlações entre preferência por atividades técnicas e o perfil de comportamento no trabalho em equipe de engenheiros de software. O universo da pesquisa foram estudantes de graduação em engenharia de software do Estado de Pernambuco. As informações sobre preferências e comportamento, obtidas em uma pesquisa de campo envolvendo 100 estudantes, receberam tratamento estatístico através do cálculo do coeficiente de correlação por posto de Spearman. Os resultados contribuem para um melhor entendimento da gestão de equipes de desenvolvimento de software.
Abstract - This article describes a survey conducted to identify correlations between preferences for technical activities and behavioral profiles for work in a team of software engineers. The context of the research was software engineering undergraduate students at State University of Pernambuco, Brazil. The information about preferences and behavior obtained in a field study involving 100 students received a statistical treatment using the Spearman rank correlation coefficient. The results contributed to a better understanding of the construction of effective software development teams
Perfis de comportamento; perfis de equipe; engenharia de sofware.
1. INTRODUÇÃO
O gerenciamento de pessoas é uma atividade reconhecidamente complexa. Para entender esta complexidade, o ponto de partida é a compreensão, já consolidada nos estudos da psicologia humana, de que as pessoas são diferentes em diversos aspectos. Por exemplo, na solução de problemas, na forma de obtenção de informação, na tomada de decisão, na relação como o ambiente e as outras pessoas, no comportamento durante o trabalho em equipe, entre vários outros. Estas diferenças influenciam motivação, preferência por atividades profissionais, efetividade no trabalho em equipe e, em última instância, desempenho individual e coletivo. Além disso, as diversas atividades técnicas e gerenciais do desenvolvimento de software exigem diferentes níveis qualitativos e quantitativos de processos mentais e sociais, tais como, criatividade, atenção a detalhes, comunicabilidade, persistência, flexibilidade, liderança, etc.
A gestão de pessoas é especialmente importante para a indústria de software, por três motivos: (1) o desenvolvimento de software é uma atividade mental e, portanto, intensiva em pessoas; (2) é, quase sempre, desenvolvido em equipe; e (3) é composto de diversas atividades técnicas cujo agrupamento define papéis funcionais distintos em uma equipe de desenvolvimento. Estas características, de forma isolada e nas suas interações, aumentam a complexidade e a importância da gestão de pessoas no
35
desenvolvimento de software quando comparada com setores menos intensivos em atividades mentais.
Nos últimos anos, diversas pesquisas têm buscado aplicar teorias da psicologia à engenharia de software com o objetivo de obter teorias, técnicas e ferramentas específicas para projetos de software, em dois aspectos complementares: na alocação de pessoas a papéis funcionais (técnicos e gerenciais) do desenvolvimento de software; e na composição e gerenciamento das equipes de desenvolvimento.
Entre estas pesquisas, de forma geral, podem ser distinguidas duas vertentes: • Trabalhos que têm como foco o indivíduo, sua personalidade e seus traços de
omportamento, e como estes elementos influenciam o trabalho individual no desenvolvimento de software [Acuna, Juristo e Moreno 2006],[Capretz 2002],[ Capretz 2003],[Cunha 2007].
• E trabalhos que colocam o indivíduo no contexto do trabalho em equipe, analisando as formas de interação e os papéis em equipe, e como estes elementos influenciam o trabalho em equipe em software [Gorlae Lam 2004],[Karn e Cowling 2006].
Certamente as duas vertentes são importantes e complementares, uma vez que cada indivíduo isoladamente contribui para o trabalho em equipe e a equipe, por sua vez, cria um contexto social e organizacional que pode moldar ou ajustar o comportamento individual. Este trabalho busca contribuir com a interação destas duas vertentes. O objetivo é estudar as relações entre a preferência individual por atividades técnicas e gerenciais do desenvolvimento de software (foco no indivíduo) e os perfis de comportamento individual no trabalho em equipe (foco no trabalho em equipe). E para contemplar este objetivo, este artigo é guiado pelas seguintes perguntas de pesquisa:
• Existem atividades técnicas ou gerenciais no desenvolvimento de software preferidas pelos engenheiros de software?
• Existem perfis de comportamento no trabalho em equipe com maior tendência de ocorrência entre os engenheiros de software?
• Finalmente, existem correlações entre a preferência por atividades técnicas e os perfis de comportamento dentre os engenheiros de software?
Para responder a estas perguntas foi realizada uma pesquisa de campo (survey), de natureza quantitativa, cuja unidade experimental foi o engenheiro de software, estudante de cursos de graduação em engenharia de software. O universo da pesquisa é formado 341 estudantes do Centro de Informática da UFPE e foram coletados dados de uma amostra de 100 estudantes (29% do universo) entre os meses de setembro de 2008 e março de 2009.
O instrumento de coleta de informações de campo foi um questionário estruturado com perguntas fechadas composto de três partes: (I) informações de controle; (II) preferência por atividades; e (III) perfil de comportamento no trabalho em equipe. A parte II foi desenvolvida neste trabalho tomando por base as atividades técnicas e gerenciais descritas na norma ISO/IEC 12207 e no Rational Unified Process (RUP). Para identificar os perfis de comportamento no trabalho em equipe foi utilizada a Teoria de Papéis em Time de Belbin (Belbin’s Team Role Theory) apresentada em (BELBIN, 1981) e, desta forma, a parte III do questionário é o instrumento associado à esta teoria,
36
denominado Team Role Self-Perception Inventory (TRSPI), que é fornecido em [Belbin 1981].
Este artigo está organizado da seguinte forma: na Seção 2 é apresentado o referencial teórico do trabalho composto pela Teoria Teoria de Papéis em Time de Belbin (Belbin’s Tearm Role Theory) e pela descrição das atividades técnicas e gerenciais segundo a norma ISO/IEC 12207 e o RUP. Na Seção 3, é apresentada a metodologia e os métodos experimentais utilizados no trabalho. Na Seção 4, são apresentados e analisados os resultados da pesquisa. Finalmente, na Seção 5, são apresentadas conclusões e direções para pesquisas futuras.
2. REFERENCIAL TEÓRICO
Para responder às perguntas da pesquisa, é necessário selecionar uma teoria de papéis e definir claramente as atividades técnicas e gerencias do desenvolvimento de software, para então estudar as suas correlações. A literatura sobre teoria de papéis é ampla, conforme apresentado em [Aritzeta, Swailes e Senior 2007], e uma avaliação teórica do assunto está fora do escopo deste artigo. Neste trabalho, a teoria de papéis utilizada é a Teoria de Papéis em Time de Meredith Belbin [Belbin 1981], escolhida por um conjunto de razões:
• A teoria é focada em papéis relacionados ao trabalho em equipe, atendendo a um requisito deste trabalho que é estudar o comportamento individual no trabalho em equipes de desenvolvimento de software.
• A teoria e os instrumentos de avaliação (questionários e escalas de medição) passaram por um extenso trabalho de crítica teórica e testes experimentais, com a conclusão de que a teoria é consistente e os instrumentos são válidos conforme resumido em [Aritzeta, Swailes e Senior 2007], [Senior 1998].
• A teoria e os instrumentos de avaliação não são oficialmente aceita pelos conselhos de psicologia no rasil (assim como outros testes muito utilizados na prática, como o MBTI). Porém, os riscos da teoria não ser adequada ao contexto brasileiro é baixa uma vez que foi construída a partir de extensa pesquisa de campo envolvendo indivíduos de diversos países e culturas distintas, procurando eliminar um possível viés cultural.
• Existem diversos trabalhos na área de engenharia de software que utilizam a Teoria de Belbin, permitindo que os resultados deste trabalho possam ser comparados, entre eles [Stevens 1998], [Henry e Stevens 1999],[Schoenhoff 2001],[Rajendran 2005],[França e Da Silva 2007],[Ferreira e Da Silva 2007].
• Finalmente, apesar da Teoria de Belbin ter sido originalmente construída para times de gerentes, existem estudos que demonstram sua utilização consistente em times de quaisquer naturezas [Fisher, Hunter e Macrosson 2002] p. 15.
Para a identificação e descrição das atividades do desenvolvimento de software foi utilizado como fundamento a norma ISO/IEC 12207 e o RUP. A primeira por ser uma norma formalmente estabelecida e que possui ampla utilização prática. O segundo por ser um modelo de processo largamente utilizado na prática e apresentar uma definição precisa das atividades do desenvolvimento.
37
2.1 Teoria de Papéis de Time de Belbin
Durante os anos 70, Meredith Belbin e sua equipe de pesquisadores do Henley Management College, na Inglaterra, estudaram vários comportamentos de gerentes de várias nacionalidades, durante um período de nove anos. Neste estudo, os gerentes foram submetidos a testes psicométricos para avaliar traços de personalidades, modos de interação, preferências intelectuais e estilos de comportamento. Os testes usados foram o 16 Personality Factors (16PF), o Watson-Glaser Critical Thinking Appraisal (CTA) e o Personal Preference Questionnaire (PPQ). A partir deles, os gerentes foram alocados em equipes de diversas composições, com o apoio de um grupo de observadores que registravam todas as ações [Belbin 1981].
A partir dos resultados dos testes e da observação do comportamento dos indivíduos em situações de trabalho em equipe, vários grupos de comportamento foram identificados e consistentemente relacionados ao sucesso ou fracasso das equipes. Os padrões de comportamento identificados foram classificados e nomeados, originalmente, em oito tipos de papéis em times (team roles): Company Worker, Team Worker, Monitor Evaluator, Chairman, Plant, Shaper, Resource Investigator e Completer Finisher. Neste trabalho serão mantidos os nomes originais em inglês dos papéis uma vez que uma tradução livre poderia causar distorções de significado e prejudicar o entendimento dos resultados.
Na Teoria de Belbin, um papel em time é definido como “uma tendência para se comportar, contribuir e se relacionar com outros de uma forma particular em um trabalho em equipe”. A Teoria de Papéis em Time advoga que estes papéis quando alocados de forma balanceada em uma mesma equipe melhoram as chances de sucesso do trabalho coletivo uma vez que aumentam a coesão e sintonia entre os membros, criando equilíbrio entre as forças e fraquezas inerentes a cada papel individual.
Belbin [Belbin 1993] apresenta uma extensão da Teoria de Papéis com a adição do papel de Specialist. Além disso, foram alterados os nomes de dois papéis de time para melhor representar seu significado: Chairman passou a ser chamado Co-ordinator e Company Worker passou a Implementer. A utilização do papel Specialist possui críticas na literatura por não possuir poder discriminatório suficiente [Aritzeta, Swailes e Senior 2007], [Senior 1998]. Por esta razão, este trabalho considera os oito papéis originais da Teoria, mas com os novos nomes Co-ordinator e Implementer.
A Tabela 1 explica de forma resumida cada perfil de comportamento de Belbin, especificando suas características, pontos fortes e fracos.
A Teoria de Papéis de Belbin é complementada por uma ferramenta de análise chamada Team Role Self-Perception Inventory (TRSPI), apresentada em [Belbin 1981], com o qual é possível identificar os papéis que um indivíduo tenderá a assumir em uma situação de trabalho em equipe. O TRSPI é brevemente descrito na Seção 3.4.
2.2 Atividades Técnicas e Gerenciais
A Norma ISO/IEC NBR 12207 [NBR 1998] foi desenvolvida pela ISO (International Organization for Standardization) e a IEC (International Electrotechnical Commission) e tem como objetivo estabelecer uma estrutura comum para os processos de ciclo de vida de software. O escopo da ISO/IEC 12207 abrange todo o ciclo de vida de software,
38
desde sua concepção até a descontinuidade do projeto de software, e os processos são agrupados em três classes: Fundamentais, de Apoio e Organizacionais.
O Rational Unified Process© (RUP©), descrito em 15], é um processo genérico para engenharia de software, que descreve atividades e papéis funcionais que servem de base para implantação de processos de desenvolvimento em uma ampla variedade de organizações que desenvolvem software.
Neste trabalho, foi realizado um estudo das atividades associadas aos processos Fundamentais e de Apoio da Norma e dos 32 papéis funcionais descritos no RUP, juntamente com as atividades a eles atribuídas, com o objetivo de consolidar um conjunto pequeno de atividades técnicas que fosse capaz de cobrir a maioria das atividades envolvidas em um processo genérico de desenvolvimento de software.
Tabela 1 - CARACTERIZAÇÃO DOS PAPÉIS EM TIME
Papel em time (Título
Original)
Sigla Descritores Pontos Fortes Possíveis Fraquezas
Completer Finisher
CF Ansioso, consciencioso, introvertido, tem autocontrole, tem autodisciplina, submisso e preocupado.
Meticuloso, consciencioso, rocura por erros e omissões, entrega sem atraso.
Tendência a se preocupar demais. Relutante a delegar.
Implementer (former Company Worker)
IMP Conservador, controlado, disciplinado, eficiente, inflexível, metódico, sincero, estável e sistemático.
Disciplinado, confiável, conservador e eficiente, transforma idéias em ações práticas.
Um tanto inflexível. Lento para responder a novas possibilidades.
Team Worker TW Extrovertido, amigável, leal, estável, submisso, confortante, não assertivo e não competitivo.
Cooperativo, suave, boa percepção e diplomático, escuta, constrói, evita atritos, acalma o clima.
Indeciso em situações de conflito.
Monitor Evaluator
ME Seguro, fidedigno, justo, introvertido, aberto a mudanças, sério, estável e sem ambições.
Sóbrio, estratégico e perspicaz, visualiza todas as opções, julga com precisão.
Não tem impulso e habilidade para inspirar outras pessoas.
Co-ordinator (former Chairman)
CO Dominante, confia nos demais, extrovertido, maduro, positivo, tem autocontrole, tem autodisciplina, estável.
Maduro, confiante, bom diretor, esclarece objetivos, promove a tomada de decisão, delega bem.
Pode ser visto como manipulador. Sobrecarregado com trabalho.
Plant PL Dominante, imaginativo, introvertido, original, pensamento radical, cheio de confiança, não se inibe.
Criativo, não ortodoxo, soluciona problemas difíceis.
Muito absorto em pensamentos; dificuldade para se comunicar efetivamente.
39
Shaper SH Abrasivo, ansioso, arrogante, competitivo, dominante, irritável, emocional, extrovertido, impaciente, impulsivo, autoconfiante.
Desafiador, dinâmico, prospera sob pressão, tem impulso e coragem para vencer obstáculos.
Suscetível a provocações.
Ofende o sentimento das pessoas.
Resource Investigator
RI Diplomático, dominante, entusiasta, extrovertido, flexível, inquisitivo, otimista, persuasivo, positivo, descontraído, social e estável.
Extrovertido, comunicativo, explora oportunidades, desenvolve contatos.
Excessivamente otimista. Perde interesse depois do entusiasmo inicial.
Esta consolidação é apresentada na Tabela 2 e teve como meta reduzir a quantidade de valores para as variáveis da pesquisa. As características apresentadas na Tabela 2 foram utilizadas para construir o questionário de avaliação das preferências individuais por atividades técnicas e gerenciais, que é discutido na Seção 3.4.
Tabela 3 - ATIVIDADES DO DESENVOLVIMENTO DE SOFTWAR E CONSOLIDADAS
ATIVIDADES OBJETIVOS CARACTERÍSTICAS Análise Identificar as necessidades
dos usuários e avaliação e concepção do sistema.
1. Identificação requisitos e modelagem de caso de uso; 2. Especificar dados e avaliar resultados; 3. Detalhar as funcionalidades do sistema; 4. Entender o domínio da aplicação; 5. Investigar o que o cliente deseja.
Desenvolvimento Transformar especificações em código.
1. Identificação dos componentes do software; 2. Definir abordagem de teste e assegurar sua correta implementação; 3. Seguir padrões adotados para o projeto; 4. Seguir o projeto e a arquitetura definida; 5. Realizar testes unitários.
Teste Executar teste em programas ou sistemas de programação com a finalidade de encontrar erros.
1. Buscar falhas no sistema; 2. Verificar os requisitos quanto a sua consistência, completude e previsão; 3. Avaliar a qualidade global da interface; 4. Gerar relatório de teste; 5. Verificar os componentes gerados
Revisão Avaliar os artefatos de planejamento e do projeto nos pontos principais de revisão do ciclo de vida do projeto.
1. Planejar e conduzir as revisões; 2. Verificar código fonte; 3. Observar detalhes; 4. Revisar requisitos; 5. Revisar código.
Gerenciamento Planejar e gerenciar os riscos do projeto.
1. Coordenar as interações com cliente e usuários; 2. Analisar decisões; 3. Manter a equipe de projeto concentrada na meta certa. 4. Acompanhar atividades; 5. Procurar alternativas quando surge algum problema.
40
3. METODOLOGIA
Esta pesquisa apóia-se no método de abordagem hipotético-dedutivo, onde a hipótese geral é de que existem correlações entre preferências por atividades e perfis de Belbin. Quantos aos meios, a pesquisa utiliza uma abordagem quantitativa apoiada no método de procedimento estatístico. Os fenômenos observados são as preferências por atividades técnicas e perfis de comportamento de Belbin entre engenheiros de software. As variáveis têm natureza quantitativa. Quantos aos fins, a pesquisa é descritiva, pois objetiva colher um conjunto de variáveis a partir de um estudo de campo e identificar correlações existentes entre estas variáveis.
3.1 Fases da Pesquisa
Este trabalho foi estruturado em três fases: • Fase 1: esta pesquisa iniciou-se com uma revisão não sistemática da bibliografia
sobre equipes de desenvolvimento de software e comportamento do trabalho em equipe. Ao final desta revisão, a norma ISO/IEC 12207 e o RUP foram escolhidos como fundamento para descrição das atividades técnicas e gerenciais no desenvolvimento de software e a Teoria de Belbin foi escolhida para descrever o comportamento individual no trabalho em equipe. Estas escolhas foramjustificadas na Seção 2
• Fase 2: após o estudo e a seleção das teorias apropriadas, uma pesquisa de campo foi cuidadosamente planejada e executada. A coleta de dados ocorreu entre os meses de setembro de 2008 e março de 2009, em duas iterações, e envolveu um total de 100 estudantes de graduação do Centro de Informática da UFPE, em Recife, PE. Esta coleta foi realizada utilizando um questionário objetivo, de questões fechadas, desenhado especificamente para este fim.
• Fase 3: após a finalização da pesquisa de campo, os resultados foram gerados utilizando-se o tratamento estatístico em duas fases. Primeiro houve a identificação das preferências por atividades e dos perfis de comportamento de Belbin. Em seguida, foram calculadas as correlações entre as atividades técnicas e os perfis de comportamento através do coeficiente “_” de Spearman que mede a intensidade destas relações. Uma vez com estes resultados, seguiu-se a análise e elaboração de conclusões.
3.2 Unidade Experimental, Universo e Amostra da Pesquisa
A unidade experimental da pesquisa é o estudante de engenharia de software dos cursos de graduação em Ciência e Engenharia de Computação do Centro de Informática da UFPE, localizado em Recife – PE. Para caracterizar formalmente o universo, foram considerados os estudantes que já haviam completado com sucesso (aprovação) a disciplina de Engenharia de Software quando responderam ao questionário. Para validar esta caracterização foi realizada uma verificação dos respondentes no sistema de informação SIGA da UFPE.
De acordo com os dados fornecidos pela Coordenação de Graduação do CIn-UFPE a população compreendia na época da coleta de dados 341 estudantes (135 de Engenharia da Computação e 206 de Ciências da Computação). Esta população está segmentada por gênero em ambos os cursos da seguinte forma: 91% de estudantes do sexo masculino e 9% do sexo feminino.
41
A pesquisa utilizou uma amostra estratificada, proporcional à segmentação por gênero da população. O tamanho da amostra, de 100 estudantes, correspondendo à 29% do universo, foi calculado a priori para atingir um nível de confiança aceitável (95%), com um intervalo de confiança de 8,25%.
3.3 Definição de Variáveis e Escalas
As variáveis desta pesquisa são a preferência por atividades técnicas extraídas da norma ISO/IEC 12207 e do RUP e os papéis em time de Belbin, sumarizadas no Quadro 1.
Quadro 1 - Variáveis
Preferência por Atividades Papéis em Time de Belbin AN Análise DE Desenvolvimento TE Teste RE Revisão GE Gerenciamento
IMP Implement CO Co-ordinator SH Shaper PL Plant RI Resource Investigator ME Monitor Evaluator TW Team Worker CF Completer Finisher
Na Teoria de Tipos de Belbin, os papéis em time são medidos utilizando uma escala razão com valores inteiros que variam entre 0 e 70. As pontuações são convertidas para uma escala ordinal para refletir as tendências específicas de cada experimento. Belbin (1981) utiliza uma conversão para uma escala ordinal de quatro valores Baixo, Médio, Alto e Muito Alto, obtida a partir dos percentuais apresentados no Quadro 2.
Quadro 2 - TABELA DE NORMAS DE BELBIN
Papel Baixo 0-33 %
Médio 33-66 %
Alto 66-85 %
Muito Alto
85-100%
Média
IMP 0-6 7-11 12-16 17-23 10,0
CO 0-6 7-10 11-13 14-18 8,8
SH 0-8 9-13 14-17 18-36 11,6
PL 0-4 5-8 9-12 13-29 7,3
RI 0-6 7-9 10-11 12-21 7,2
ME 0-5 6-9 10-12 13-19 8,2
TW 0-8 9-12 13-16 17-25 10,9
CF 0-3 4-6 7-9 10-17 5,5
Esta conversão reflete as tendências específicas de determinadas amostras de apresentarem ocorrências maiores ou menores de alguns perfis. Estas tendências representam características sócio-culturais que não seriam capturadas na utilização direta dos valores. A mesma conversão foi utilizada na amostra desta pesquisa e será apresentada na Seção 4.
42
Para manter a compatibilidade com a variável Papel em Time, a variável Preferência por atividade também é medida por uma escala razão com valores inteiros entre 0 e 25. Os valores são obtidos através de um questionário semelhante ao TRSPI (explicado abaixo), garantindo a possibilidade de correlacionar os valores das duas variáveis. Da mesma forma que para os Papéis em Time, os valores da Preferência por Atividades são convertidos para uma escala ordinal de valores Baixo, Médio, Alto e Muito Alto, utilizando os mesmos percentuais no Quadro 2.
3.4 Instrumento da Pesquisa
O instrumento de coleta de informações de campo foi um questionário estruturado com perguntas objetivas (fechadas) composto de três partes: (I) informações de controle; (II) preferência por atividades; e (III) perfil de comportamento no trabalho em equipe. A parte II foi desenvolvida neste trabalho tomando por base as atividades técnicas e gerenciais descritas na norma ISO/IEC 12207 e no RUP. Esta parte é composta de cinco questões, com cinco itens por questão. Cada questão descreve uma situação do desenvolvimento de software e cada item descreve uma preferência dentro desta situação e está relacionada a uma atividade técnica ou gerencial. A Figura 1 apresenta uma das questões como exemplo.
O respondente deve atribuir cinco pontos (números inteiros) entre os cinco itens em cada questão, de forma a refletir a sua preferência em cada situação. Assim, para cada atividade do desenvolvimento de software a pontuação no questionário varia entre o mínimo de 0 e o máximo de 25.
Para identificar os perfis de comportamento no trabalho em equipe foi utilizada a Teoria de Papéis em Time de Belbin (Belbin’s Team Role Theory) e, desta forma, a parte III do questionário é o instrumento associado à esta teoria, denominado Team Role Self-Perception Inventory (TR-SPI), que é fornecido em [Belbin 1981]. O TRSPI (versão original com oito papéis) é composto de sete questões, com oito itens por questão. Cada item descreve um comportamento relativo a uma situação de trabalho em equipe e está relacionada a um papel em time. A Figura 2 apresenta uma das questões como exemplo.
O respondente deve atribuir 10 pontos (números inteiros) entre os oito itens em cada questão, de forma a refletir a sua auto-percepção de como se comportaria em cada situação descrita. Assim, para cada papel em time a pontuação no questionário varia entre o mínimo de 0 e o máximo de 70.
Figura 1 - Questionário de Preferência por Atividad es Técnicas e Gerenciais
43
Figura 2 - Questionário de Preferência por Atividad es Técnicas e Gerenciais
3.5 Métodos e Ferramentas Estatísticas
Durante a coleta de dados, estes foram tabulados na ferramenta Microsoft Office Excel 2007. Ao final da coleta, as análises estatísticas foram realizadas com o pacote SPSS (Statistical Package for Social Sciences) versão 13.0. Para verificar a existência de correlação entre a por atividades e o papel em equipe na Teoria de Papéis de Time de Belbin foi utilizado o coeficiente correlação de Posto de Spearman, normalmente designado “rho” (_), e definido pela seguinte fórmula:
& = 1 − & ∑ ����
��
� − � ,(���, −1 ≤ & ≤ +1
Onde, n representa o número de pares (Xi, Yi) e d é diferença entre os postos para as duas observações dentro de um par ((postos de Xi dentro os valores de X) – (postos de Yi dentro os valores de Y)). O coeficiente _ de Spearman varia entre -1 e 1. Quanto mais próximo estiver destes extremos, maior será a associação entre as variáveis. O sinal negativo da correlação significa que as variáveis variam em sentido contrário, isto é, as categorias mais elevadas de uma variável estão associadas a categorias mais baixas da outra variável.
4. RESULTADOS E ANÁLISE
A PESQUISA ENVOLVEU UM TOTAL DE 100 ESTUDANTES DE INFORMÁTICA, DOS CURSOS DE CIÊNCIAS DA COMPUTAÇÃO E ENGENHARIA DE SOFTWARE DO CENTRO DE INFORMÁTICA – CIN DA UNIVERSIDADE FEDERAL DE PERNAMBUCO - UFPE, CONSIDERANDO APENAS OS RESPONDENTES VÁLIDOS.
Quadro 3 ilustra a amostra estratificada dos estudantes de informática em relação ao sexo.
Quadro 3 - UNIVERSO E AMOSTRA DA PESQUISA
Curso Masculino % Feminino % Total
Universo
Ciência da Computação 215 91% 21 9% 236
Engenharia da Computação 123 91% 12 9% 135
Amostra
Ciência da Computação 61 91% 6 9% 67
44
Engenharia da Computação 30 91% 3 9% 33
4.1 Conversão das Escalas
Conforme explicado na Seção 3, os valores das variáveis devem ser convertidos para uma escala ordinal para refletir as características específicas da amostra da pesquisa. Assim, utilizando o procedimento definido em [Belbin 1981], duas tabelas de normas foram construídas para as variáveis Preferência por Atividades e Papéis em Time e estão apresentadas no Quadro 4 e no Quadro 5, respectivamente.
Quadro 4 - NORMAS PARA AS PREFERÊNCIAS POR ATIVIDAD ES
Papel Baixo 0-33 %
Médio 33-66 %
Alto 66-85 %
Muito Alto
85-100%
Média
AN 0-7 8-10 11-13 14-19 9,2
DE 0-6 7-9 10-12 13-19 8,1
TE 0-4 5-8 9-10 11-18 7,0
RE 0-3 4-5 6-8 9-12 4,9
GE 0-3 4-7 8-10 11-17 5,9
Quadro 5 - NORMAS PARA OS PAPÉIS EM TIME
Papel Baixo 0-33 %
Médio 33-66 %
Alto 66-85 %
Muito Alto
85-100%
Média
IMP 0-8 9-11 12-15 16-22 10,7
CO 0-6 7- 9 10-13 14-21 8,8
SH 0-7 8-11 12-14 15-22 8.5
PL 0-6 7-10 11-13 14-20 8,5
RI 0-5 6-8 9-11 12-18 7,2
ME 0-5 6-8 9-12 13-23 7,7
TW 0-7 8-11 12-15 16-36 10,7
CF 0-5 6-9 10-11 12-20 7,9
O Quadro 6 compara as médias apresentadas por Belbin (1981) e as obtidas neste trabalho.
Quadro 6 - COMPARAÇÃO COM AS MÉDIAS DE BELBIN
Papel Baixo 0-33 %
Médio 33-66 %
Alto 66-85 %
Muito Alto
85-100%
IMP 10,0 10,7 0,7 -7%
CO 8,8 8.8 0,0 0%
45
SH 11,6 8.5 -3,1 26%
PL 7,3 8.5 1,2 -16%
RI 7,8 7.2 -0,6 7%
ME 8,2 7.8 0,4 5%
TW 10,9 10.7 0,2 2%
CF 5,5 7.8 2,4 -43%
É importante ressaltar três diferenças significativas nos resultados acima. Primeiro, existe uma diminuição nos valores para o papel SH, demonstrando que a amostra exibe este papel associado à liderança em menor nível que no estudo original de Belbin, que é consistente com o fato de que o estudo de Belbin utilizou somente gerentes atuantes no mercado, para os quais se esperava um percentual alto de papéis de liderança. Segundo, existe um aumento nos valores para o papel PL, que pode ser considerado consistente com o fato da amostra desta pesquisa ser composta de sujeitos com perfil de criação e solução de problemas complexos.
Finalmente, existe um considerável aumento nos valores do papel CF, considerado um papel que possui baixa ocorrência na população em geral. Este perfil, de acordo com [Ferreira e Da Silva 2007] está associado aos processos de garantia de qualidade e aderência a processos. Neste caso, uma hipótese que pode ser levantada é que a área de engenharia de software está atraindo indivíduos com tendências a exibir este papel em time, pois este papel está sendo valorizado no mercado em função das necessidades crescentes de aumento de qualidade e aderência a processos de desenvolvimento bem definidos. No entanto, esta hipótese ainda precisa ser testada.
4.2 Tendências na Preferência por Atividades e pelos Pa péis em Time
Uma tentativa inicial de responder às perguntas de pesquisa 1 e 2 (Seção 1) é através da análise da freqüência de ocorrência de valores Alto e Muito Alto para as duas variáveis. Porém, uma inspeção simples destas ocorrências não permite concluir se existem tendências na amostra para determinadas preferências ou papéis. Para buscar respostas mais conclusivas para as perguntas 1 e 2, foi analisada a uniformidade da distribuição das médias dos valores numéricos dos variáveis, utilizando o teste de Bonferroni. Os próximos quadros apresentam os resultados do teste.
O quadro 7. mostra que as médias mais elevadas registradas nas Preferências por Atividades foram AN (9.2) e DE (8,1) e a menos elevada correspondeu à atividade RE (4,9). Através do resultado do teste de Bonferroni (letras semelhantes entre parêntesis) comprovam-se diferenças significantes entre o par AN-DE com cada uma das variáveis TE, RE e GE. Portanto, mostrasse que a preferência por atividades técnicas e gerenciais não é uniformes na amostra. Conclui-se que as atividades de análise e desenvolvimento têm uma tendência a despertar maior interesse dos engenheiros de software, enquanto revisão e gerenciamento despertam menor interesse.
Explicações para este resultado podem ser atribuídas a dois fatores. Primeiro, a ênfase na formação dos engenheiros de software é nas atividades relacionadas à solução de problemas e implementação de sistemas: análise e desenvolvimento. Portanto, atividades como teste e revisão, são apresentadas com ênfase menor. Segundo, as
46
atividades de gerenciamento (GE) demandam maturidade pessoal e profissional que o os participantes desta pesquisa não possuem. É, portanto, consistente a baixa preferência por atividades de gerenciamento.
O quadro 8 mostra as maiores médias para os papéis TW e IMP com valores idênticos (10,7) e a menor média para o perfil RI (7,2). O teste de Bonferroni agrupa os papéis TW e IMP em uma categoria (letras iguais entre parêntesis), expressando uma tendência da amostra nestes papéis. O teste também agrupa as médias de CO, SH, PL, CF, ME e RI. Estes agrupamentos evidenciam que, também para os papéis em time, existe uma tendência, respondendo à pergunta 2 da pesquisa.
Com os resultados acima é possível mostrar que existem tendências tanto para as Preferências como para os Papéis. Porém, estes testes não permitem avaliar se existem relações entre estas tendências, o que será realizado na próxima seção.
Quadro 7 - COMPARAÇÕES PAREADAS DE BONFERRONI DAS M ÉDIAS DAS PREFERÊNCIAS
Preferência por Atividades AN DE TE GE RE
Média dos Valores Numéricos 9,2(4.1) 8,1(4.1) 7,0(4.2) 5,9(4.2) 4,9(4.2)
Quadro 8 - MÉDIA DOS PAPÉIS E COMPARAÇÕES PAREADAS DE BONFERRONI
Papeis em Time
TW IMP CO SH PL CF ME RI
Média dos Valores
Numéricos
10.7(4.1) 10.7(4.1) 8.8(4.1,4.2) 8.5(4.2) 8.5(4.2) 7.9(4.2) 7.8(4.2) 7.2(4.2)
4.3 Correlações entre Preferências por Atividades e Pap éis em Time
Nesta seção serão estudas as possíveis correlações entre as duas variáveis, utilizando o coeficiente de correlação _ de Spearman. No Fonte: Elaboração própria Quadro 9, os valores grifados em negrito mostram as correlações significantes.
Quadro 9 - CORRELAÇÃO ENTRE PREFERÊNCIAS E PAPÉIS
IMP CO SH PL RI ME TW CF
AN -.149 .059 -.271(*) .133 177 .076 .080 -.033
DE .207(*) -.295(**) .164 .184(*) -.231(*) .013 -.065 -.028
TE .041 -.121 -.024 -.153 -.124 .161 .119 -.025
RE .073 .038 .069 .028 .078 -.104 -.210(*) .199(*)
GE -.199(*) .286(**) .122 -.119 .236(**) -.145 -.025 -.054
Tabela 3 - CORRELAÇÕES ENTRE AS VARIÁVEIS
47
Variáveis Correlação Explicação Preliminar
AN-SH (-) Esta correlação negativa era esperada. A análise envolve “investigar o que o cliente deseja” enquanto o perfil Shaper é “abrasivo, ansioso, arrogante” podendo “ofender o sentimento alheio. A necessidade de relacionamento supostamente amigável com o cliente deve levar a pessoas que exibam o papel de Shaper a não ter preferência por atividades de análise.
DE-IMP (+) Esta correlação positiva é esperada e corroborada por França e da Silva (2007). Pessoas com papel Implementer apresentam o comportamento de transformar planos em ação, e devem ter uma tendência a preferir atividades de implementação.
DE-CO (-) Esta correlação negativa não é óbvia, mas é consistente com a correlação negativa entre GE e IMP e a positiva entre DE-IMP.
DE-PL (+) A correlação positiva não é prevista em França e da Silva (2007), mas é corroborada por Stevens (1998), Schoenhoff, (2001) e Rajendram (2005), em particular quando existem problemas não triviais no desenvolvimento.
DE-RI (-) A correlação pode ser entendida uma vez que o Resource-Investigator “perde interesse depois do entusiasmo inicial”, sendo um papel que deve preferir atividades com maior desafio intelectual e menos características operacionais.
RE-TW (-) Esta correlação negativa não é imediatamente decorrente do referencial teórico nem da análise comparativa entre papéis e atividades. Novas pesquisas devem aprofundar este achado experimental.
RE-CF (+) Esta correlação é esperada uma vez que a atividade de Revisão envolve “observar detalhes” e o papel Completer-Finisher é “meticuloso, consciencioso, procura por erros e omissões”. Rajendram (2005) associa o papel CF com as atividades de Revisão e Teste.
GE-IMP
GE-CO
GE-RI
(-)
(+)
(+)
As três correlações da atividade Gerenciamento estão previstas nos trabalhos de França e da Silva (2007) e Fernandes e da Silva (2007). Em particular, a correlação negativa também pode ser explicada pois o papel Implementer tende a ter um comportamento “inflexível e lento para responder a novas possibilidades”, características que não ser adéquam à atividade de Gerenciamento.
É importante notar que não foi encontrada nenhuma correlação entre a Preferência pela Atividade de Teste e os Papéis em Time. Uma explicação possível é que esta preferência (alta ou baixa) está uniformemente espalhada entre os papéis fazendo com que não existe uma correlação significativa com nenhum grupo em particular.
O teste estatístico de correlação não determina a relação de causa e efeito. Portanto, não é possível concluir se é o papel que determina a preferência, apesar de que esta é uma hipótese razoável. Além disso, não faz parte do escopo da análise quantitativa explicar o porquê dos resultados, no caso, as correlações.
No entanto, utilizando resultados da literatura (principalmente [Stevens 1998], [Schoenhoff 2001],[França e Da Silva 2007],[Ferreira e Da Silva 2007]) e a caracterização dos papéis em time da tabela 1, é possível apresentar explicações preliminares para estes resultados, que devem ser analisadas com mais profundidade em um estudo qualitativo futuro. A Tabela 3 apresenta estas explicações.
5. CONSIDERAÇÕES FINAIS
Neste trabalho foram investigadas relações entre preferências individuais por atividades técnicas e gerenciais do desenvolvimento de software e papéis que descrevem comportamento pessoal no trabalho em equipe. Três perguntas centrais nortearam o
48
desenvolvimento da pesquisa: (1) existe tendência nas preferências por atividades; (2) existe tendência na ocorrência de papéis em time; (3) existe correlação entre preferências e papéis. Para as três perguntas, as respostas obtidas através de uma pesquisa de campo foram positivas:
1. As atividades de Análise e Desenvolvimento são preferidas em relação às de Teste, Revisão e Gerenciamento.
2. Os papéis Teamworker e Implementer tendem a ocorrer mais freqüentemente na amostra do que os outros seis papéis.
3. Das 40 possíveis combinações entre Preferências e Papéis, 10 apresentam correlação significativa de acordo com o coeficiente por Posto de Spearman.
A resposta para (1) evidencia que os estudantes de engenharia de software têm uma tendência a preferir atividades diretamente relacionadas à solução de problemas e construção de sistemas. Seria importante realizar um estudo qualitativo para saber se esta preferência está relacionada a uma percepção dos estudantes de que estas atividades são mais intelectualmente desafiadoras. Os resultados em (2) mostram que os papéis associados ao desenvolvimento (Implementer) e ao trabalho em equipe (Teamworker) ocorrem com mais frequência.
As correlações encontradas como resposta para (3) contribuem nos processos de composição de equipes de desenvolvimento de software, principalmente quando utilizadas em conjunto com os resultados da literatura e em particula [Fernandes e Fabio 2007], [Ferreira e Da Silva 2007], [França e Da Silva 2007]. Estes resultados podem ser utilizados para auxiliar na alocação de pessoas aos papéis funcionais em uma equipe de desenvolvimento levando em consideração suas características comportamentais e pessoais.
Quanto à validade, a pesquisa possui validade de conclusão, uma vez que existe correlação entre as variáveis, confirmada pela análise estatística, dentro dos limites do nível de confiança (95%) e do intervalo de confiança (8,25%). Não é possível afirmar a validade interna da pesquisa pois não foram estabelecidas relações de cause-efeito entre as variáveis. Trabalhos futuros devem investigar estas relações. A generalização dos resultados, validade externa, está restrita a populações com perfis comparáveis ao deste trabalho: estudantes de cursos de ciência ou engenharia da computação que tenham cursado disciplinas de engenharia de software. Estudos com populações distintas (por exemplo, profissionais atuantes no mercado) estão sendo conduzidas com o objetivo de ampliar a validade externa deste trabalho.
Como trabalho futuro propõe-se a investigação do impacto da formação de equipes considerando características comportamentais e pessoais no desempenho das equipes. Além disso, aspectos sociais e organizacionais serão acrescentados ao problema de formação e desenvolvimento de equipes com o objetivo de se estabelecer modelos e processos de suporte à gestão de equipes de melhor desempenho em engenharia de software. Esta pesquisa tem o objetivo mais amplo de estudar os vários aspectos relacionados ao ciclo de vida de equipes de desenvolvimento de software e este trabalho é uma contribuição nesta direção.
49
REFERÊNCIAS
Acuna, S. T.; Juristo, N.; Moreno, A. M. (2006) Emphasizing human capabilities in software development. IEEE Software, vol. 23:(2), 2006, pp. 94–101.
Aritzeta, A., Swailes, S., And Senior, B. (2007) "Belbin`s Team Role Model: Development, Validity and Applications for Team Building". Journal of Management Studies, vol. 44:(1), 2007, pp. 96-118.
Belbin, M. R. (1981) Management Teams: Why they succeed or Fail? Butterworth-Heinemann Ltd., 1981.
Belbin, M. R. (1993) Team Roles at Work. Elsevier Butterworth-Heinemann Ltd., 1993.
Capretz, L. F. (2002) Implications of MBTI in Software Engineering Education. SIGCSE Bulletin, vol. 34:(4), 2002.
Capretz, L. F. (2003) Personality types in software engineering. Int. J. Human-Computer Studies vol. 8, 2003, pp. 207–214.
Cunha, A. D. (2007) Greathead, D. Does personality matter? : an analysis of code-review ability. Communications of the ACM. New York, USA: Associatiom for Computing Machinery, vol. 50:(5), 2007, pp. 109-112.
Fernandes, F.; Da Silva, Fabio Q. B. (2007) Relações entre competências pessoais e tipos de personalidade do gerente de projetos. Anais do 2º Congresso Brasileiro em Gerenciamento de Projetos, Salvador, BA, 2007.
Ferreira, P.G.; Da Silva, F. Q. B. (2008). Fatores que influenciam a utilização de processos de software. Anais do VII Simpósio Brasileiro de Qualidade de Software, Florianópolis, SC, 2008.
Fisher, S. G., Hunter, T. A. And Macrosson, W. D. (2002) ‘Belbin’s team role theory: for non-managers also? ’. Journal of Managerial Psychology, vol. 17, 2002, pp. 14–20.
França, A.C.; Da Silva, F. Q. B. (2007). Um estudo sobre Relações entre Papéis Funcionais do RUP e o Comportamento Pessoal no Trabalho em Equipe em Fábricas de Software. III WOSES -Workshop Um Olhar Sociotécnico sobre a Engenharia de Software, 2007.
Gorla, N., And Lam, Y.W. (2004) Who should work with whom? Building effective software project teams. Communication of the ACM, vol. 47:(6), 2004.
Henry, S. M.; Stevens, K. T. (1999) Using Belbin’s Leadership Role to Improve Team Effectiveness: an empirical investigation, Journal of Systems and Software, vol. 44:(3), 1999, pp. 241-250.
Karn, J. And Cowling, T. (2006) A Follow up Study of the Effect of Personality on the Performance of Software Engineering Teams. Proceedings of the 2006 ACM/IEEE International Symposium on Empirical Software Engineering (ISESE’06), Rio de Janeiro, Brazil, 2006, pp. 232-241.
Kruchten, P. (2003) Introdução ao RUP – Rational Unified Process, Rio de Janeiro: Editora Ciência Moderna Ltda., 2003.
50
NBR ISO/IEC 12207. (1998) NBR ISO/IEC 12207 – tecnologia de informação: processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998.
Rajendran, M. (2005) Analysis of team effectiveness in software development teams working on hardware and software environments using Belbin Self-perception Inventory, Journal of Management Development, vol. 24:(8), 2005, pp. 738-753, Emerald Group Publishing Limited, 0262-1711, DOI 10.1108/02621710510613753.
Schoenhoff, P.K. (2001) Belbin's Company Worker, The Self-Perception Inventory, and Their Application to Software Engineering Teams. Master Thesis, Virginia Polytechnic Institute and State University, 2001.
Senior, B. (1998) An empirically-based assessment of Belbin s team roles Human Resource Management. Human Resource Management Journal, vol. 8:(3), 1998, pp. 54-60.
Stevens, K.T. (1998) The Effects of Roles and Personality Characteristics on Software Development Team Effectiveness. Doctoral Thesis, Virginia Polytechnic Institute and State University, 1998.
Swailes, S. And Aritzeta, A. (2006) Scale Properties of the Team Role Self-Perception Inventory. International Journal of Selection and Assessment, vol. 14:(3), 2006, pp. 292-298.
51
�����∨ : A Logic Inference Engine to Resolution Leveraged by
Heuristics
Cleyton Rodrigues, Renata Maria de Souza
Federal University of Pernambuco, Informatics Center, CDU, 7851, Recife, Pernambuco, Brazil.
{cmor,rms6}@cin.ufpe.br
Abstract . Automated Reasoning (AR) has been a traditional research area. In this field, Theorem Proving (TP) concerns the deductive view of a problem solving. Many theorem prover were created in the literature, however, while some of them are not fully-automatic (requires human interaction along the proof calculus), others are not clear-cut enough to work with the engine. Further, many of these are highly inflexible, in other words, they do not allow to be extended with new heuristics. Thus, this work proposes the ��"�
∨ (Constraint Handling Rule Engine for Resolution/Factoring) a resolution Classical First Order Logic (CFOL) inference engine built upon the general declarative logic constraint language ��"∨. In this paper, we show how a ��"∨
inference engine can also support the following form of fully automated theorem proving: entailment of a disjunction of conjunctions of atomic formulas by an arbitrary first-order logic formula.
1. Introduction
Automated Reasoning is the Artificial Intelligence field which studies computational knowledge representation and reasoning in terms of Decidability, “that is, there exists an algorithm such that for every formula in the system the algorithm is capable of deciding in finitely many steps whether the formula is valid in the system or not” [NationMaster 2010], and others properties such as completeness, monotonicity and consistency. Decidability can be reformulated as a task of logical consequence. In short, it is the reasoning in which, given a formula H and a set of assumptions KB (in other words, a domain-specific knowledge base for the representation and acquisition of knowledge), H is a logical consequence of KB in a deduction system, if there is a proof of H from KB, notated as: KB |= H. In this sense, this paper presents ��"�
∨ , an
automatic resolution inference engine for theorem proving, which can also be easily extend to addresses some heuristics, special maneuvers leading to a more skillful theorem prover.
This paper is organized as follows: section 2 and 3 resumes, briefly, the main concepts of Resolution and ��"∨ (the language used to implement the ��"�
∨ system),
respectively; further, in section 4 the system is detailed and the first results are outlined, and finally section 5 presents the conclusion and the future works.
2. Resolution
When working with theorem provers, completeness becomes a critical factor in choosing the best logic inference engine. However, this is not possible in CFOL when inferences as Modus Ponens is used. Therefore, there is the urgency of working with Resolution. Coupled with Factoring, this procedure is complete for CFOL clauses. Actually, Resolution is a refutation completeness [Russell and Norvig 2003]
52
inference procedure in the sense that, it can not derive from the the knowledge base all the true sentences, but it can reason about the entailment of any one. Furthermore, Refutation, or reduction ad absurdum is a proof by contradiction, where to check whether KB entails H, is enough to check the unsatisfiability of KB ^ ¬H. In Resolution, it is essential that all clauses assume the Conjunctive Normal Form (CNF) notation. According to it, a clause is represented by a disjunction of literals. We say that two literals can be resolved if they are complementary, in the sense that the positive literal is unifiable with the negative one. Factoring, by other side, is an auxiliary mechanism coupled with resolution, which removes copies of the same literals in the consequent clause. A copy of one literal is not necessarily equivalent, but unifiable with it.
3. CHRV in a Nutshell
Constraint Handling Rules with Disjunction (��"∨) [Abdennadher and Schtz 1998] is a general concurrent logic programming language, rule-based, which have been adapted to a wide set of applications as: constraint satisfaction [Wolf 2005], abduction [Gavanelli, Alberti and Lamma 2008], componente-development engineering [Fages, Rodrigues and Martinez 2008], and son on. It is designed for creation of constraint solvers. ��"∨is a fully accepted logic programming language, since it subsumes the main types of reasoning systems: the production system, the term rewriting system, besides Prolog rules. Additionally, the language is syntactically and semantically well-defined (check the references for further details). Concerning the syntax, a ��"∨program is a set of rules defined as:
rule_name@�� ⁄ �� ⇔ G|B
Rule name is the non-compulsory name of the rule. The head is defined by the predicates represented by Hk and Hr (user-defined predicates), with which na engine tries to match with the constraints in the store. Further, G stands for the set of guard predicates (built-in predicates), that is, a condition imposed to be verified to fire any rule. Finally, B is the disjunctive body (a collection of user-defined and built-in predicates), corresponding to a set of constraints added within the store, whenever the rule fires. The logical conjunction and disjunction of predicates are syntactically expressed by the symbols , and ;, respectively. Logically, the interpretation of the rule is as follows:
∀��� �� → ���� ∧ � ↔ �∃�� ��⁄ � ∧ �� �� ,�ℎ�����= ����� ∪ ������ ∪ �����,�� ��⁄ = ����� ���⁄
4. )*+��∨ : Experiments and Outcome
This sections addresses the reformulation of CNF clauses (the refutation rule, inclusive), enjoying the ability of program user defined constraints in CHR_engine. Roughly speaking, CHR_rf is a rule system capable to perform the basic inference rules presented in the previous section, namely: resolution and factoring. Therefore, for each pair of these user constraints, the engine tries to resolve based on the complementary literals. Each new resolution is taken to resolve itself until no resolution is possible or the CHR_engine derives a constraints with no parameters (logically, the empty-clause). Initially, all CFOL clauses and the refutation rule are expressed in CNF notation. Then,
53
each conjunctive clause of the form: ¬& ∨ ¬&� ∨ ¬& ∨ ¬&� turns onto a implies/6 ��"∨user defined constraint:
#�, #�������-., -&, &�., (�-., -&, &�., /����, 0�, 01_�(����#��, // where: -&, &�.represents a list with the negative literals, -&, &�. represents a list with the positive literals, Stage corresponds to the current status of the constraint, thus indicating which operation is possible to be realized (possible values are: toSort, toFactor, and toResolve); Id corresponds to a integer (unique) associated with the constraint; ID Constraint corresponds to a list of identifiers of constraints, with which the constraint has already tried to resolve (thus, before resolving the constraints, the engine checks if this process had not tried yet, avoiding trivial non-termination); SS is a enumeration type which can assume one of the values: n which says that the implies token is not part of the Set of Support, or y, otherwise.
Once all clauses in CNF have been reformulated to implies/6 CHR_constraints, we apply (manually) some additional steps to fix mismatches between both representations (CFOL and ��"∨), they are: (i) universal vs. existential quantifiers and (ii) unification vs. matching. In (i), we add additional variables in the head of ��"∨rules1 (for all the local existential variables), which changes the variable semantics to be universally quantified, as a skolemized CFOL formula, while for (ii) the engine uses a prolog predicate which preforms a sound-unification unify with occurs check (+Term1,+Term2), since, in nature, ��"∨performs matching, that is, one-side unification.
��"� ∨ system operates in three well-defined phases: phase 1 (toSort)- both list of
constraints are sorted to help the resolution and factoring, phase 2 (to-Factor) - each list from implies/6 constraint are revisited to delete equivalente terms2; phase 3 (toResolve) - each pair of constraints is tried to resolve; if not possible, the identifier of each constraint is added to the list of the partner, to avoid further futile attempts. On the other hand, if the resolution occurs, a new constraint is created with status toSort and its id is formed by junction of the parents identifiers. In order to improve the system, ��"∨is flexible enough to extend with some heuristics, like: Set of Support and Linear Resolution. For the former case, as mentioned earlier, the field SS for the constraints tells which constraint is part of the set (in our context, only the refutation clause and all the clauses derived by resolution). For the Linear Resolution, in turn, we ensure that a constraint from the SS may resolve with the others (not part of the set) or with any of its ancestor (this is possible, since the id keeps a track of all the parents constraints). The table below outlines some results with the engine. The problems and ��"�
∨ can be found at http://cin.ufpe.br/~cmor/JELIA/.
Table 1 - Results for the �����∨system
Problem/Puzzle Nr. Implies Refutation Query Time(s)
Fido 4 die(Fido) 0,016
1 Variables in ��"∨head rules are universally quantified, while the ones presented locally in ��"∨body rules are existentially quantified 2 In this context, equivalents terms are a variant of each other, or in other word, they have the same functor and the variables are renamed.
54
Lucky 7 happy(john) 0,062
Tuna 8 kill(curiosity,tuna) 2,403
Happy 11 loves(melinda,bill) 0,172
Marcus-Caesar 9 hate(marcus,caesar) 5,772
5. Final Remakes and Future Works
��"∨is a very versatile constraint language to knowledge representation and inference. This article showed briefly a resolution inference system coupled with some heuristics deployed by the ��"∨language. In order to validate the engine, some benchmark tests will be carried out to compare with some research related. Further, we will improve the engine to hold others inference algorithm, such as, forward chaining and backward chaining.
References
NationMaster (2010) Encyclopedia-decidability
Russell, S., Norvig, P. (2003) Constraints Satisfaction Problems. In: Artificial Intelligence: A Modern Approach. 2nd edition edn. Prentice-Hall, Englewood Cliffs, NJ (2003) 214
Abdennadher, S., Schtz, H. (1998) Chrv: A flexible query language. In: In FQAS 98: Proceedings of the Third International Conference on Flexible Query Answering Systems, Springer-Verlag (1998) 1–14
Wolf, A. (2005) Intelligent search strategies based on adaptive constraint handling rules. Theory Pract. Log. Program. 5(4-5) (2005) 567–594
Gavanelli, M., Alberti, M., Lamma, E. (2008) Integrating abduction and constraint opti- mization in constraint handling rules. In: Proceeding of the 2008 conference on ECAI 2008, Amsterdam, The Netherlands, The Netherlands, IOS Press (2008) 903–904
Fages, F., Mário de Oliveira Rodrigues, C., Martinez, T. (2008). Modular CHR with ask and tell. In: CHR ’08: Proc. 5th Workshop on Constraint Handling Rules, (Linz, Austria) 95–110
