TOMADA DE DECISÃO PARA APLICABILIDADE DO PSP UTILIZANDO A LÓGICA PARACONSISTENTE ANOTADA EVIDENCIAL ET

Transcrição

1 TOMADA DE DECISÃO PARA APLICABILIDADE DO PSP UTILIZANDO A LÓGICA PARACONSISTENTE ANOTADA EVIDENCIAL ET Fábio Vieira do Amaral 1, Renato Hildebrando Parreira 2, Dolores Pineiro Mejuro 3, Helio Corrêa de Araújo 4, Ivan Ferraz 5, Ricardo Pim da Rocha 6, Jair Minoro Abe 7, Marcelo Nogueira 8 Abstract This article presents the Annotated Paraconsistent Evidential Logic Eτ enforcement (Eτ Logic) in assessing the feasibility of using the PSP as a tool to control the software processes quality. Using the favorable levels of evidence and unfavorable levels of evidence, we can define the certainty and uncertainty levels for decision making regarding the presented proposition. Index Terms component; PSP, Paraconsistent Logic INTRODUÇÃO Projetos de software em geral não atingem os objetivos (custos, prazos, satisfação do cliente), ou seja, os projetos fracassam por falta de um bom gerenciamento de projetos.[1][4]. Em um estudo mundial da Standish Group [2][4], 53% dos projetos de TI, ultrapassam em quase 90% as estimativas de custo e prazo, representando um prejuízo de 59 bilhões de dólares por ano. Outros 31% dos projetos são cancelados antes de serem concluídos, gerando um prejuízo de 81 bilhões de dólares, enquanto que apenas 16% dos projetos são completados dentro do prazo e orçamento previstos. No processo de desenvolvimento de um software, a qualidade depende de um esforço contínuo realizado por todos os profissionais envolvidos onde deve existir o compromisso de verificar e validar o produto a ser entregue em cada etapa do processo. Em De Marco[3][4], na Anatomia do fracasso do projeto, o autor relata que muitos projetos fracassam por falta de competência do gerente, mas em outros casos o fracasso ocorre pelas expectativas presunçosas e irracionais no planejamento do projeto. Segundo levantamento realizado nas empresas e Instituições Norte Americanas [5][4], o principal fator organizacional que contribui para a ineficiência dos gerentes de projetos é a falta de comprometimento organizacional, e a principal razão que levam os projetos a terem problemas de extrapolação dos prazos e custos estimados, é com 39,5 %, a falha em utilizar ferramentas de gerenciamento de projeto sistematicamente. O caos no gerenciamento de projetos de software impede que o uso de técnicas de engenharia de software traga os benefícios e resultados esperados [6][4]. Pensando em uma melhora gradual no processo de desenvolvimento dos projetos de software o Personal Software Process (PSP) pode ser empregado nos estágios iniciais de um plano mais amplo de qualidade. O PSP é um processo focado na medição pessoal de um indivíduo, servindo como treinamento para o CMMI (Capability Matury Model Integration). O PSP pode ser utilizado no processo de escolha das pessoas que farão parte de um determinado projeto, ou até mesmo fornecer subsídios mais reais a um gerente de projeto no momento de definição de custos e prazos baseados na produtividade dos elementos da equipe. O PSP jamais pode ser utilizado para demitir um membro da equipe, pois a performance de cada individuo pode variar conforme o tema abordado por cada projeto. Do ponto de vista acadêmico o PSP é uma boa prática que deve ser adotada pelas equipes de desenvolvimento de software. Neste trabalho será realizado um estudo sobre a impressão dos desenvolvedores durante o processo de confecção dos templates do PSP e se seria aceitável utilizar tais práticas nas suas atividades profissionais. Para avaliar este estudo será utilizada a ferramenta Paraanalizador, que 1 Fábio Vieria do Amaral, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, favamaral@gmail.com 2 Renato Hildebrando Parreira, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, renatodoryusen@hotmail.com.br 3 Dolores Pineiro Mejuto, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, dolorespm@terra.com.br 4 Hélio correa de Araujo, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, hhca@globo.com 5 Ivan Ferraz, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, ivanferraz1105@hotmail.com.br 6 Ricardo Pim da Rocha, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, ricardopim@msn.com 7 Jair Minoro Abe, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, jairabe@uol.com.br 88 Marcelo Nogueira, Grupo de Pesquisa de Engenharia de Software aplicada à criação de Sistemas Críticos UNIP, Rua Antonio Macedo, Parque São Jorge São Paulo SP Brazil, marcelo@noginfo.com.br DOI /WCSEIT

2 utiliza a Lógica Paraconsistente Anotada Evidencial Et como método de tomada de decisão. PERSONAL SOFTWARE PROCESS (PSP) O objetivo das organizações de software é: Entregar produtos de software de alta qualidade, de acordo com os custos e o cronograma estabelecido. [7] a) O que as organizações têm feito? Programas de Qualidade (TQM) CMMI - The Capability Maturity Model Integration SPICE (ISO/IEC TR 15504) Normas para Software: ISO/IEC 9126, ISO/IEC 12207, etc b) Qual a deficiência destes métodos? Dizem o quê e não como fazer Focam a organização e não o indivíduo c) PSP É um framework para auxiliar o desenvolvedor a estimar e planejar suas tarefas, acompanhar sua performance em relação ao planejado e melhorar a qualidade dos produtos produzidos. Ao contrário de outros modelos diz como fazer. d) Objetivo do PSP Criado para ajudar engenheiros de software a realizarem um bom trabalho. Ele diz como aplicar avançados métodos de engenharia em suas atividades diárias, promovendo detalhados métodos de estimativa e planejamento, mostra aos engenheiros como acompanhar seu desempenho em relação ao planejado e explica como os processos definidos podem orientar os seus trabalhos [7]. Formado por um conjunto de templates de formulários e listas de verificações que são utilizadas para:[7] Coletar dados e medir o desempenho de um indivíduo de forma consistente em uma determinada tarefa para um melhor gerenciamento do tempo. Gerenciar defeitos onde os engenheiros registram todos os defeitos encontrados e corrigidos, incluindo revisões, inspeções, compilação etestes. Conduzir os indivíduos em uma efetiva revisão de design e código, ajudando-os a encontrar ecorrigir defeitos no início de um processo. FIGURA 1 NIVEL DO PSP LÓGICA PARACONSISTENTE ANOTADA EVIDENCIAL ET A lógica Paraconsistente teve inicio com o polonês S. Jaskowski em 1948 e pelo brasileiro N.C.A. Da Costa em1954. Da Costa aprofundou seus estudos e desenvolveuaplicações paraconsistentes utilizando todos os níveis lógicosatuais e é visto pela ciência moderna recente como um dosidealizadores da Lógica Paraconsistente. Mais recentemente, J. M. Abe e outros pesquisadores têmdesenvolvido pesquisas e aplicações para a Lógica Paraconsistente Anotada Evidencial Eτ no ramo de Ciência dacomputação, Robótica, Inteligência Artificial, entre outros. ALGORITMO PARA-ANALISADOR A Lógica Paraconsistente Anotada Evidencial Et pertenceàs lógicas não-clássicas. Ela consiste em elaborar métodos deinterpretação, sendo que sua estrutura teórica é apresentada emtrabalhos relevantes de pesquisas anteriores, como [8][9][11]. Na Lógica Et, após estabelecer uma proposição p, são identificados os fatores, os graus de certeza (μ) e incerteza (λ)como valores de anotação agregados a proposição,sendo que oprimeiro representa a evidência favorável, ou certeza, e osegundo a evidência desfavorável, ou incerteza, representando valores independentes que podem variar em limites mínimos amáximos, de 0 a 1. O algoritmo consiste em aplicar as técnicas de maximizaçãonos graus de evidência favorável (μ), de minimização nosgraus de evidência desfavorável (λ) quando considerado ooperador lógico OU (OR), de acordo com a notação: (μ1, λ1) OR (μ2, λ2) = (máx{ μ1, μ2};{mín{ λ1, λ2}) Em seguida, sobre este resultado, deve-se aplicar a minimização nos graus de evidência favorável, a maximização nos graus de evidência desfavorável quando considerado o operador lógico E (AND), de acordo com a notação: 206

3 (μ1, λ1) AND (μ2, λ2) = (mín{ μ1, μ2};{máx{ λ1, λ2}) Com base nos valores de maximização e minimização são calculados os graus de certeza e de incerteza de μ e λ. Grau de Certeza: Gcer (μ e λ) = μ λ Grau de Incerteza: Ginc (μ e λ) = μ + λ -1 Dois valores limites (Vcve = Valor de controle de veracidade e Vcfa = Valor de controle de falsidade) determinam quando o grau de certeza resultante é alto o suficiente para que a proposição analisada seja considerada totalmente verdadeira ou totalmente falsa. Da mesma forma, dois valores limites (Vcic = Valor de controle de inconsistência e Vcpa = Valor de controle deparacompleteza) determinam quando o valor do grau deincerteza resultante da análise é tão alto que se podeconsiderar a proposição totalmente inconsistente ou totalmente paracompleta. Os estados lógicos extremos são os seguintes: TABELA 1 VALORES LIMITES EXTERNOS [11] Os estados lógicos não extremos são os seguintes: TABELA 2 VALORES LIMITES NÃO-EXTERNOS [11] FIGURA 2 DIAGRAMA COM OS GRAUS DE INCERTEZA E DE CERTEZA, COM VALORES AJUSTÁVEIS DE CONTROLE LIMITE INDICADOS NOS EIXOS.[11] Caracterização dos estados: Estado Verdadeiro: Gin(, ) = - = Gve(, ) ½ e ½ e ½ Estado Falso: Gin(, ) = - = Gfa(, ) -½ e ½ e ½ Estado Inconsistente: Gce(μ, l) = μ + l - 1 = Gct(μ, l) ³ ½ e μ ³ ½ e l ³ ½ Estado Paracompleto: Gce(μ, l) = μ + l - 1 = Gpa(μ, l) -½ e μ ½ e l ½ Estado Quase-Verdadeiro tendendo ao Inconsistente: Gin(μ, l) = μ - l = Gve(μ, l) ½ e μ ³ ½ e Gce(μ, l) = μ + l - 1 = Gct(μ, l) ³ 0 Estado Quase-Verdadeiro tendendo ao Paracompleto: Gin(μ, l) = μ - l = Gve(μ, l) ½ e μ ³ ½ e Gce(μ, l) = μ + l - 1 = Gpa(μ, l) 0 Estado Quase-Falso tendendo ao Inconsistente: Gin(μ, l) = μ - l = Gfa(μ, l) ³ -½ e μ ½ e Gce(μ, l) = μ + l - 1 = Gct(μ, l) ³ 0 Estado Quase-Falso tendendo ao Paracompleto: Gin(μ, l) = μ - l = Gfa(μ, l) -½ e μ ½ e Gce(μ, l) = μ + l - 1 = Gct(μ, l) 0 Estado Quase-Inconsistente tendendo ao Verdadeiro: Gce(μ, l) = μ + l - 1 = Gct(μ, l) ½ e l ³ ½ e Gin(μ, l) = μ - l = Gve(μ, l) ³ 0 Estado Quase-Inconsistente Falso tendendo ao Falso: Gce(μ, l) = μ + l - 1 = Gct(μ, l) ½ e μ ³ ½ e Gin(μ, l) = μ - l = Gfa(μ, l) 0 Estado Quase-Paracompleto tendendo ao Verdadeiro: Gce(μ, l) = μ + l - 1 = Gpa(μ, l) ³ -½ e μ ½e Gin(μ, l) = μ - l = Gve(μ, l) ³ 0 Estado Quase-Paracompleto tendendo aofalso: Gin(μ, l) = μ + l - 1 = Gpa(μ, l) ³ -½ e μ ½e Gce(μ, l) = μ - l = Gfa(μ, l) 0 A FERRAMENTA PARAANALISADOR.EXE Para facilitar a aplicação da Lógica Paraconsistente Anotada Evidencial Et foi desenvolvido o software ParaAnalizador, atendendo os seguintes processos: 207

4 FIGURA 3 FLUXO BPMN DO SOFTWARE PARAANALISADOR.EXE O ParaAnalisador.exe compreende três operações básicas que estão divididas em dados de entrada, processamento do algoritmo para-analisador e apresentação dos resultados. ESTUDO DE CASO Antes da realização do estudo de caso tratado a seguir, umgrupo de profissionais foi treinado nas práticas do PSP nointuito de disseminar tais praticas nas suas respectivasempresas. Para análise da aplicabilidade do PSP nas equipes de desenvolvimento foi estabelecido como caso de uso 10 fatoresque atendem a proposição: É viável a utilização do PSP no seu dia a dia como profissional. a) Escolha dos Fatores F1. Participar de um treinamento para utilização do PSP. F2. Apoio da gerência. F3. Capacitar a planejar, projetar e construer software com qualidade. F4. Conhecer a produtividade do indivíduo para planejar melhor o seu trabalho, assumer compromissos com mais segurança e cumpri-los com maior regularidade. F5. Ajudar o indivíduo a tratar de maneira realista e objetiva os defeitos no programa que resultam dos seus erros. F6. Custo e disponibilidade de tempo para registro dos dados. F7. Possibilidade de utilização dos dados para retaliações pela gerência. F8. Dificuldade no preenchimento dos templates para a coleta dos dados. F9. Não aplicável às atividades do trabalho. F10. Gerar competitividade entre os indivíduos da equipe. b) Justificativa dos Fatores Fator 1: O treinamento proporciona maior clareza quanto a estrutura do PSP e as medições necessárias paraavaliação do desempenho do profissional. Fator 2: Os esforços para utilizar o PSP serão mais recompensáveis quando a gerência do profissional compartilhar de seus interesses e objetivos. Fator 3: Gerência e profissional deverão ter uma confiança mútua de que os dados informados somente serão utilizados para melhoria do processo e esempenho. Fator 4: Para ser capaz de planejar, projetar e construir software com qualidade, o profissional necessita reconhecer suas limitações, entender melhor seus pontos fortes e fracos, ter objetivos para o aperfeiçoamento profissional. Fator 5: Para o desenvolvimento do processo são necessárias aproximadamente 1 a 2 horas por template, e as atualizações são necessárias pelo menos a cada 3 meses. Fator 6: O PSP é composto por 7 fases totalizando 24 templates. Cada template tem a sua particularidade e precisa ser bem compreendida para o seu correto preenchimento. Fator 7: O profissional necessita de uma estrutura de processo e de medições para a avaliação do seu desempenho, assim poderá se comprometer apenas com o que é possível cumprir e conseguirá lidar com as pressões para não aceitar compromissos impossíveis. Fator 8: O profissional deverá registrar todas as ocorrências ao longo do processo e será capaz de entender as suas limitações de uma forma realista e objetiva. Um dos principais e mais polêmicos templates do PSP é o Time Recording Log. Fator 9: Dependendo da atividade que o profissional estiver executando, as tabelas do PSP não se aplicam. Fator 10: Poderá ocorrer competitividade entre os profissionais. a) A Pesquisa e a obtenção dos resultados Os dados da pesquisa foram coletados e lançados no software ParaAnalisador.exe. A apresentação dos resultados do processamento possibilita medir os graus de certeza e incerteza de cada fator da proposição e fornece base para a tomada de decisão. b) Especialistas Entrevistados Os grupos de especialistas estão definidos a seguir: Grupo A Programadores Grupo B Coordenador de Porjetos GrupoC Analista de Sistemas c) Construção da Base de Dados Para a pesquisa foram selecionados 9 especialistas, 3 para cada grupo (item d), e cada um informou sua opinião sobre cada um dos fatores da pesquisa. Os dados da pesquisa foram coletados e inseridos no ParaAnalisador.exe. d) Análise dos Resultados Após a solicitação de análise do ParaAnalisador.exe, obtivemos a seguinte tabela de resultados do processamento: 208

5 F6. Custo e disponibilidade de tempo para registro dos dados. F9. Não aplicável às atividades do trabalho. FIGURA 4 ESTADOS RESULTANTES. Ao analisarmos o grau de certeza, podemos concluir que: a proposição será verdadeira quando o valor do grau de certeza for maior ou igual a 0,55; a proposição será falsa quando o grau de certeza for menor ou igual a -0,55; a proposição será inconclusiva quando o grau de certeza estiver situado entre -0,55 e 0,55. Com todos os valores considerados representativos da Lógica Eτ apresentados no quadrado unitário de todas as regiões que definem os estados lógicos resultantes da saída. Os fatores com estado resultante inconsistentes indicam uma contradição e necessitam de um levantamento mais específico com os especialistas para que possamos obter novos resultados. CONSIDERAÇÕES FINAIS O PSP é uma prática para melhoria de processos de software que pode ser conduzida no âmbito individual, onde uma coleta contínua de dados sobre um trabalho realizado ajuda a desenvolver estratégias para melhorias, identificando os pontos fortes e fracos de um desenvolvedor. O estudo de caso nos comprova uma resistência por parte dos profissionais em utilizar o PSP de forma completa, apesar de responderam positivamente a pesquisa. Os templates constantes no PSP0 e PSP0.1 se mostraram mais eficientes do ponto de vista do convencimento da utilização do método. A desconfiança por parte da equipe que os dados obtidos possam ser utilizados como critério de demissão também contribui para negativa de aceitação. REFERENCIAS [1] Sant Anna, N. Um ambiente Integrado para o apoio ao desenvolvimentoe gestão de projetos de software para sistemas de controle de satélites. São José dos Campos, INPE, setembro [2] Bottoni, F. Só 16% dos projetos de TI cumprem o prazo e o orçamento. São Paulo, InfoExame, maio FIGURA 5 REPRESENTAÇÃO QUPC. Analisando a representação QUPC da proposição, podemos concluir que com os valores 0,79 e 0,23 temos um estado lógico resultante verdadeiro para a proposição de viabilidade de uso do PSP, nos mostrando uma decisão viável em 56% de certeza e somente 2% de incerteza. Os fatores com estado resultante verdadeiros direcionam para a viabilidade da utilização do PSP, fatores esses que são: F1. Participar de um treinamento para utilização do PSP. F2. Apoio da gerência. F3. Capacitar a planejar, projetar e construir software com qualidade. F4. Conhecer a produtividade do indivíduo para planejar melhor o seu trabalho, assumir compromissos com mais segurança e cumpri-los com maior regularidade. F5. Ajudar o indivíduo a tratar de maneira realista e objetiva os defeitos no programa que resultam dos seus erros. [3] De Marco, T. Controle de projetos de software: gerenciamento,avaliação, estimativa. Rio de Janeiro, Campus, [4] Fernando Borrego Filho, Luiz; Sant Anna, Nilson; Gonçalves Cereja Júnior, Moacyr; Canhadas Genvigir, Elias. Análise e Modelagem para Automação de Processos de Gerenciamento de Projetos. [5] Zimmerer, T. W.; Yasin, M. M. A leadership profile of American Project managers. IEEE Engineering Management Review, v 26, n.4, [6] Belloquim, A. Modelagem de Software: Ontem, hoje e amanhã. Rio de Janeiro, Developers Magazine, junho [7] Humphrey, Watts S., A Discipline for Software Engineering, EditoraAddison Wesley, 1ª. Edição, p. [8] Da Costa,N.C.A.; Abe, J.,M.; Murolo, A. C.; Da Silva Filho, J. I.; Leite, C. F. S. Lógica Paraconsistente Aplicada. São Paulo, Atlas, 1999 [9] Da Silva Filho, J. I.; Abe, J. M. Fundamentos das Redes Neurais Artificiais Paraconsistentes destacando aplicações em Neurocomputação. São Paulo, Arte & Ciência, p.298, [10] Abe, J. M.; Da Silva Filho, J. I.; Celestino, U.; Corrêa, de A. H.. Lógica Paraconsistente Anotada Evidencial Et. Santos, Editora Comunicar,