Tese Fuzzy Belchior

UM MODELO FUZZY PARA AVALIAO DA QUALIDADE DE SOFTWARE
Arnaldo Dias Belchior

TESE SUBMETIDA AO CORPO DOCENTE DA COORDENAO DOS PROGRAMAS DE PS-GRADUAO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSRIOS PARA A OBTENO DO GRAU DE DOUTOR EM CINCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAO.
Aprovada por: _________________________________________ Profa. Ana Regina Cavalcanti da Rocha, D.Sc.
_________________________________________ Prof. Geraldo Bonorino Xexo, D.Sc.
_________________________________________ Prof. Arndt von Staa, Ph.D.
_________________________________________ Prof. Carlos Alberto Nunes Cosenza, D.Sc.
_________________________________________ Prof. Jos Carlos Maldonado, D.Sc.
_________________________________________ Prof. Jano Moreira de Souza, Ph.D.
Rio de Janeiro, RJ - Brasil
Maio / 1997
BELCHIOR, ARNALDO DIAS Um Modelo Fuzzy para Avaliao da Qualidade de Software [Rio de Janeiro] 1997 xii, 185 p. 29,7 cm (COPPE/UFRJ, D.Sc., Engenharia de Sistemas e Computao, 1997) Tese - Universidade Federal do Rio de Janeiro, COPPE 1. Engenharia de Software 2. Avaliao da Qualidade de Software 3. Teoria dos Conjuntos Fuzzy I. COPPE/UFRJ II. TTULO (srie)
ii
SALMO 22 (de Davi) O Senhor meu pastor, nada me faltar. Em verdes prados ele me faz repousar, Conduz-me junto s guas refrescantes, Restaura as foras de minha alma. Pelos caminhos retos ele me leva, Por amor do seu nome. Ainda que eu atravesse o vale escuro, Nada temerei, pois estais comigo. Vosso bordo e vosso bculo So o meu amparo. Preparais para mim a mesa A vista de meus inimigos. Derramais o perfume sobre minha cabea, Transborda a minha taa. A vossa bondade e misericrdia ho de seguir-me Por todos os dias da minha vida, E habitarei na casa do Senhor Por longos dias.
iii
AGRADECIMENTOS
Ao Banco do Nordeste do Brasil (BNB) por ter tornado possvel este trabalho. Professora Ana Regina por sua orientao segura e sua objetividade, um especial agradecimento por minha formao a nvel de ps-graduao. Ao Professor Geraldo Xexo por sua co-orientao, incentivo e entusiasmo contagiante de pesquisador. Aos Professores Arndt, Cosenza, Maldonado e Jano pela honra de t-los em minha banca examinadora. Aos professores Guilherme, Cludia Werner, Ftima Gaio e Vera pelo apoio. Aos colegas e funcionrios da COPPE/Sistemas pela amizade, especialmente, Morganna, Gisela, Karina, Ktia, Cristina, Rosa, Renata, Fernanda, Jos Xexo, Arlindo, Claudinha, Ana Paula e Mercedes. A Clifton Clunie por ter me cedido, gentilmente, os dados de sua pesquisa de campo, que me foi de grande utilidade neste trabalho. Aos colegas da Agncia BNB-Rio, Alberto, Mrcio, Flvio, Ana Paula e Isabel. A amizade de Ferreirinha, Porfrio, Bezerra, Julinha, Alba, Clia, Manoel Otvio, Jacob, Elvira, Maria Helena, Avany, Jos Antnio, Luzia, Myrian, Maria de Lourdes, Maria Ivany, Ana Maria, Daisy, Jlio, Norma, Renata, Pe. Marques, Pe. Freitas, Joo Fonseca, Maria Lcia, Lcia Barros, Lcia Lessa, Debra, e tantos outros ... A meu Pai, a minha Me, s minhas irms (Neyla, Dayne, Suely e Luciana), avs e tios, pelo apoio e incentivo recebidos. Ao CNPQ pelo auxlio. minha mulher, Ftima, por seu suporte indispensvel ao longo desta caminhada. A meus filhos, Arnaldo e Mairon, dom precioso recebido de Deus, pelo carinho. A Deus Uno e Trino, minha fortaleza, meu porto seguro, a que no tenho palavras cabveis de gratido, confiana e esperana. Obrigado, Senhor, por ter muito mais a agradecer do que a pedir! Obrigado, Maria, Nossa Senhora Rainha da Paz, a quem aprendi a amar e confiar, pelas abundantes graas e bnos recebidas de me. Obrigado Jesus, Maria e Jos!
iv
Resumo da Tese apresentada COPPE/UFRJ como parte dos requisitos necessrios para a obteno do grau de Doutor em Cincias (D.Sc.)
UM MODELO FUZZY PARA AVALIAO DA QUALIDADE DE SOFTWARE
Maio / 1997
Orientador: Profa. Ana Regina Cavalcanti da Rocha Co-Orientador: Prof. Geraldo Bonorino Xexo
Programa: Engenharia de Sistemas e Computao
Este trabalho desenvolve um modelo fuzzy para a avaliao da qualidade de software, a partir da extenso de um modelo para avaliao da qualidade, anteriormente proposto, e utiliza, para isto, conceitos e propriedades da teoria dos conjuntos fuzzy. O modelo proposto possui cinco etapas para a execuo de seus objetivos, podendo envolver trs situaes distintas. A primeira, objetiva obter um padro de qualidade para o produto de software ou para o domnio de aplicao considerado. A segunda, avalia a qualidade de um produto de software, apoiando-se em um padro de qualidade j definido, anteriormente, para esse produto ou seu domnio de aplicao. A terceira, estima a qualidade de um produto de software, quando no h um padro de qualidade disponvel. Uma experincia com a avaliao da qualidade de especificaes de software foi realizada atravs deste modelo fuzzy com o objetivo de valid-lo e exemplificar seu uso. Os resultados experimentais obtidos corroboram com os resultados previstos axiomaticamente.
vi
Abstract of Thesis presented to COPPE/UFRJ as partial fulfillment of the requirements for the degree of Doctor of Science (D.Sc.)
A FUZZY MODEL TO SOFTWARE QUALITY EVALUATION
May / 1997
Advisor: Profa. Ana Regina Cavalcanti da Rocha, D. Sc. Co-advisor: Prof. Geraldo Bonorino Xexo, D. Sc.
Department: Computing and Systems Engineering
This work presents a fuzzy model to software quality evaluate, extending a software quality model previously proposed, and using to do this concepts and properties of fuzzy sets theory. The proposed model has five steps to do its objectives, embracing three different situations. The first aims to get a quality standard to a software product or application domain considered. The second evaluates the quality of a software product, supported by a quality standard previously defined to this product or its application domain. The third assesses the quality of a software product, when there is no quality standard available. An experience with evaluation of software quality specification was realized through this fuzzy model intending to validate them and to exemplify its use. The experimental results agree with those predicted axiomatically.
vii
ndice
I INTRODUO ...................................................................................... 1 II QUALIDADE DE SOFTWARE ........................................................... 4 II.1. Conceitos de Qualidade .................................................................. 6 II.2 Em Busca da Qualidade ................................................................... 8 II.2.1 Qualidade de Processos de Software ...................................... 9 II.2.1.1 O CMM ..................................................................... 10 II.2.1.2 Bootstrap e Trillium................................................... 12 II.2.1.3 O Projeto SPICE ........................................................ 12 II.2.2 Qualidade de Produtos de Software ....................................... 13 II.2.2.1 Modelos para Avaliao da Qualidade de Software.. 15 II.2.2.1.1 O Paradigma GQM .................................... 16 II.2.2.1.2 O Projeto SCOPE ...................................... 17 II.2.2.1.3 O Modelo Rocha ....................................... 18 II.3 Mtricas de Qualidade de Software ................................................. 19 II.3.1 Categorias de mtricas ........................................................... 21 II.3.2 Caractersticas das Mtricas ................................................... 23 II.3.3 A Aplicao de Mtricas ........................................................ 26 II.3.3.1 As Medies por Estimativas .................................... 28 II.3.4 Validao de Mtricas de Software ........................................ 30 II.4 Tcnicas para Controle da Qualidade ............................................... 31 II.4.1 Walkthrough e Inspees ........................................................ 32 II.4.2 Testes de Software .................................................................. 35 II.4.3 Mtodo Cleanroom ................................................................. 36 II.4.4 Modelos de Confiabilidade ..................................................... 36 II.5 A Gesto da Qualidade de Software ................................................. 37 II.5.1 A Instalao de um Programa de Qualidade ........................... 38 II.5.2. Programa de Mtricas ............................................................ 40 II.5.3 Custos com a Qualidade .......................................................... 42 II.5.4 Gerenciamento da Qualidade Total ......................................... 43 II.5.5 Recursos Humanos .................................................................. 44
viii
II.6 Concluso .......................................................................................... 45 III ENFOQUES SOBRE A TEORIA FUZZY ........................................... 46 III.1 Conceitos Bsicos de Conjuntos Fuzzy ............................................ 47 III.2 Operaes com Conjuntos Fuzzy ..................................................... 55 III.2.1 Complemento Fuzzy ............................................................ 55 III.2.2 Interseo Fuzzy ................................................................... 56 III.2.3 Unio Fuzzy .......................................................................... 57 III.2.4 Operaes Algbricas com Conjuntos Fuzzy ....................... 59 III.3 Agregao de Conjuntos Fuzzy ....................................................... 60 III.3.1 Operadores Fuzzy ................................................................. 64 III.3.1.1 Classes t-norms e t-conorms .................................. 65 III.3.1.2 Outras classes de operadores fuzzy ........................ 66 III.4 Nmeros Fuzzy ............................................................................... 67 III.4.1 Conjuntos fuzzy tipo-LR ...................................................... 69 III.5 Variveis Lingsticas ..................................................................... 70 III.6 A Lgica Fuzzy ............................................................................... 72 III.7 A Teoria das Incertezas e Aplicaes ............................................. 74 III.7.1 Sistemas Baseados em Conhecimento Fuzzy ....................... 75 III.7.2 Tomada de Deciso em Ambientes Fuzzy ............................ 76 III.7.3 Modelos de Deciso Fuzzy .................................................. 78 III.7.3.1 Mtodo de Anlise Hierrquica ..............................79 III.7.3.2 Mtodo Fuzzy Hierrquico de Avaliao ............... 80 III.7.3.3 Mtodo de Agregao de Similaridades ................ 80 III.7.3.4 Modelo Hierrquico para Estruturas de Risco ....... 81 III.7.3.5 Modelo para Localizao Industrial ....................... 82 III.7.3.6 Outros Modelos ...................................................... 82 III.8 Os Sistemas Fuzzy ........................................................................... 84 III.9 Concluso ....................................................................................... 85 IV MODELO FUZZY PARA AVALIAO DA QUALIDADE DE SOFTWARE .................................................................................... 86 IV.1. Extenso do Modelo Rocha ............................................................ 87 IV.2 Uso da Teoria Fuzzy em Qualidade de Software ............................. 89 IV.3 Etapas do Modelo Fuzzy para Avaliao da Qualidade de Software 92
ix
IV.3.1 Caractersticas do Modelo Fuzzy para Avaliao da Qualidade de Software .......................................................... 110 IV.4 Definio de ndices de Qualidade de Software .............................. 111 IV.5 Concluso ......................................................................................... 112 V UMA EXPERINCIA DE UTILIZAO DO MODELO FUZZY ... 113 V.1 Avaliao dos Atributos de Qualidade ................................................ 113 V.2 Uma experincia com o Modelo Fuzzy ............................................... 114 V.2.1 Determinao do Padro de Qualidade para ERS ..................... 115 V.2.2 Avaliao de uma ERS .............................................................. 122 V.3 Concluso ............................................................................................ 124 VI CONCLUSO .......................................................................................... 125 VI.1. Perspectivas Futuras ........................................................................ 127 REFERNCIAS BIBLIOGRFICAS ........................................................ 128 APNDICE I - Questionrio de Identificao do Perfil do Especialista ........ 155 APNDICE II - Atributos de Qualidade de Especificaes de Requisitos de Software ........................................................................... 161 APNDICE III - Instrumento para Hierarquizar Critrios de Qualidade para Especificaes de Requisitos de Software ................. 168 APNDICE IV - Formulrio de Avaliao da Qualidade de Especificaes de Requisitos de Software ................................................... 172
ndice de Figuras
Figura II.1: Avaliao de Processos de Software: Projeto SPICE .................. 12 Figura III.1: O Princpio da Extenso ............................................................. 54 Figura III.2: Comparao de um nmero real e um intervalo ntido com um nmero fuzzy e um intervalo fuzzy respectivamente ................... 68 Figura III.3: Varivel lingstica Idade ....................................................... 70 Figura III.4: Varivel lingstica Verdade ................................................... 72 Figura IV.1: Modelo Rocha .............................................................................88 Figura IV.2: Modelo Rocha Estendido ............................................................ 89 Figura IV.3: Funes de pertinncia de nmeros fuzzy, para termos lingsticos .................................................................................. 92 Figura V.1: Critrio Correo da Notao ...................................................... 113 Figura V.2: Hierarquizao dos critrios do objetivo Confiabilidade da Representao para ERS ............................................................. 116 Figura V.3: Hieraquizao dos critrios do objetivo Confiabilidade Conceitual para ERS .................................................................... 117 Figura V.4: Hierarquizao dos critrios do objetivo Utilizabilidade para ERS .............................................................................................. 119 Figura V.5: Hierarquizao dos subfatores de qualidade da ERS ...................120 Figura V.6: Hierarquizao dos fatores de qualidade de ERS ........................ 121
xi
ndice de Tabelas
Tabela II.1: Caractersticas e subcaractersticas de software-ISO/IEC 9126 ..14 Tabela III.1: Exemplo de conjuntos fuzzy ........................................................ 49 Tabela III.2: Categorias genricas de aplicaes de sistemas fuzzy ................. 84 Tabela IV.1: Nmeros fuzzy normais para termos lingsticos (abrangente) .. 91 Tabela IV.2: Nmeros fuzzy normais para termos lingsticos (simplificado) 91 Tabela IV.3: Nmeros fuzzy normais para termos lingsticos (por relevncia) .................................................................................. 91 Tabela IV.4.: Resultados do QIPE .................................................................. 96 Tabela IV.5: Termos lingsticos (nmeros fuzzy), usados pelos especialistas na avaliao do critrio, Correo da Notao.... 100 Tabela IV.6: rea de interseo entre os especialistas Ei e Ej na avaliao do critrio, Correo da Notao...................................................... 100 Tabela IV.7: Matriz de Concordncia entre os especialistas Ei e Ej na avaliao do critrio, Correo da Notao................................. 101 Tabela IV.8: Concordncia relativa, grau de concordncia relativa, e coeficiente de concordncia entre os Ei e Ej na avaliao do critrio, Correo da Notao..................................................... 102 Tabela IV.9: Critrios que compem o subfator Correo no Uso do Mtodo, com seus respectivos pesos W..................................................... 107 Tabela IV.10: rea de interseo entre os critrios Ci e Cj do objetivo Confiabilidade da Representao ............................................... 108 Tabela IV.11: Matriz de Concordncia entre os critrios Ci e Cj na avaliao dos atributos agregados: subfatores, fatores do objetivo Confiabilidade da Representao ............................................... 108 Tabela IV.12: Estado relativo de agregao, grau do estado relativo de agregao, coeficiente de consenso do atributo, e os argumentos a e b das funes
xii
lineares dos critrios, que participaram do processo de ............... 109
xiii
Tabela V.1: Avaliao do objetivo Confiabilidade da Representao de ERS, atravs de nmeros fuzzy.................................................... 116 Tabela V.2: Avaliao do Objetivo Confiabilidade Conceitual de ERS, atravs de nmeros fuzzy.............................................................. 117 Tabela V.3: Avaliao do objetivo Utilizabilidade de ERS, atravs de nmeros fuzzy ............................................................................. 119 Tabela V.4.: Resultados do QIPE para ERS real ............................................ 122 Tabela V.5: Relao entre os nmeros fuzzy normais do PQ e da CAERS .. 123 Tabela V.6: Resultados da avaliao para o objetivo Confiabilidade da Representao ............................................................................. 123 Tabela V.7: Resultados da avaliao para o objetivo Confiabilidade Conceitual ................................................................................... 124 Tabela AII.1 - Caractersticas de qualidade relacionadas ao objetivo Confiabilidade da Representao para ERS ........................... 164 Tabela AII.2 - Caractersticas de qualidade relacionadas ao objetivo Confiabilidade Conceitual para ERS ...................................... 163 Tabela AII.3 - Caractersticas de qualidade relacionadas ao objetivo Utilizabilidade para ERS ......................................................... 165 Tabela AII.4 - Caractersticas de qualidade do objetivo Confiabilidade da Representao, relacionadas ao objetivo Utilizabilidade para ERS .................................................................................. 167 Tabela AII.5 - Caractersticas de qualidade do objetivo Confiabilidade Conceitual, relacionadas ao objetivo Utilizabilidade para ERS .................................................................................. 167 Tabela AIII.1 - Escala de Valores ................................................................... 169 Tabela AIV.1 - Graus de Presena do Critrio ............................................... 173
xiv
Captulo I INTRODUO
No processo de avaliao da qualidade de software, no basta apenas identificar que atributos determinam essa qualidade, mas tambm que procedimentos adotar, para controlar seu processo de desenvolvimento, de forma a atingir o nvel de qualidade desejado. Isto realizado atravs da aplicao de mtricas de forma organizada e bem projetada, tornando os desenvolvedores mais conscientizados da relevncia do gerenciamento e dos compromissos para com a qualidade. Uma mtrica vlida deve obedecer a condies de representao da teoria de medidas, tal que o entendimento intuitivo de alguns atributos seja preservado, quando mapeado para um sistema de relao numrica (FENTON, 1994). Portanto, o uso de mtricas de qualidade de software deve estar apoiado em um mtodo para o controle da qualidade, para que se alcance, convenientemente, os objetivos almejados. Uma proposta para avaliao da qualidade de software o modelo proposto por Rocha (ROCHA, 1983) que, neste trabalho, estendido atravs do uso de conceitos e propriedades da teoria dos conjuntos fuzzy, por no resolver, satisfatoriamente, o problema de agregao de medidas, utilizando-a de forma bastante ad-hoc. Com o advento da teoria dos conjuntos fuzzy, obteve-se uma importante ferramenta para a representao de vrias facetas do conhecimento humano (YAGER, 1991), capturando suas imprecises, atravs de uma estrutura formal quantitativa (DUBOIS, 1991). A mente humana opera com conceitos subjetivos tais como alto, baixo, velho e novo, que so incorporados em classes de objetos nessa teoria, onde a transio de pertinncia ou no de um elemento a um conjunto, realiza-se de maneira gradual, e no abrupta (ZADEH, 1990).
Captulo I Introduo ___________________________________________________________________________
A teoria fuzzy usada, essencialmente, para mapear modelos qualitativos de tomada de deciso, e para mtodos de representao imprecisa (KLIR, 1995b). Neste contexto, que se pode utiliz-la no processo de avaliao da qualidade de software, que envolve uma enorme gama de conceitos subjetivos e no precisos. A princpio, pode parecer incoerente a utilizao da teoria fuzzy (nebulosa) para a avaliao da qualidade de software. Para justificar esta escolha, cita-se a argumentao de ZIMMERMANN (1991): A teoria dos conjuntos fuzzy fornece uma estrutura matemtica estrita (no h nada de nebuloso na teoria dos conjuntos fuzzy!), na qual um fenmeno conceitual vago pode ser precisa e rigorosamente estudado. Uma estrutura de avaliao de software bem definida tem por objetivo estimar a sua qualidade, atravs de um conjunto bsico de atributos, evidenciando seus aspectos relevantes. Para isto, as informaes sobre o objeto de avaliao devem estar dispostas de forma organizada, onde caractersticas especficas do software possam ser identificadas para otimizar o processo de tomada de deciso (BOLOIX, 1995). Uma vez que o processo de tomada de deciso centrado em pessoas humanas, como tambm o o processo de avaliao de software, com suas inerentes subjetividades e inconsistncias na definio do problema, os conjuntos fuzzy so adequados nesta rea, pois (IBRAHIM et al., 1992): possuem a habilidade para a representao de atributos; detm formas convenientes e avaliveis para a agregao de atributos, que podem estar vaga ou precisamente definidos; e manuseiam diferentes graus de importncia para cada atributo considerado. Neste contexto, a utilizao do Modelo Rocha Estendido, suportado pela robustez da teoria fuzzy, pode atuar como um mecanismo capaz de interpretar resultados e sintetizar informaes (BOLOIX, 1995), atravs de procedimentos normatizados para a avaliao da qualidade (BASILI et al., 1995). Com a extenso desse Modelo, foi proposto o Modelo Fuzzy para Avaliao da Qualidade de Software, que envolve trs situaes distintas, desenvolvidas ao longo deste trabalho: Determinao do padro de qualidade para um produto de software ou para um domnio de aplicao;
Captulo I Introduo ___________________________________________________________________________
Avaliao da qualidade de um produto de software especfico, apoiando-se em um padro de qualidade previamente definido; Avaliao de um produto de software, mesmo que no haja um padro de qualidade j estabelecido. Esta tese constitui-se de cinco captulos, alm desta introduo, e de quatro apndices, descritos, resumidamente, a seguir: No Captulo II, Qualidade de Software, discorre-se sobre qualidade de processos e produtos de software, evidenciando-se a sua relevncia, segundo o padro ISO/IEC. Outras questes tratadas so o emprego de mtricas, tcnicas para controle da qualidade, modelos de avaliao e de gesto da qualidade. No Captulo III, Enfoques sobre a Teoria Fuzzy, procura-se fornecer uma viso ampla sobre os aspectos estruturais da teoria fuzzy, para melhor fundamentar o modelo proposto, baseado nessa teoria. No Captulo IV, Modelo Fuzzy para Avaliao da Qualidade de Software, so apresentadas as etapas do modelo fuzzy para avaliao da qualidade de software, atravs da extenso do Modelo Rocha. No Captulo V, Uma Experincia de Utilizao do Modelo Fuzzy, efetua-se uma experincia de uso do modelo fuzzy proposto, com o intuito de valid-lo e de
exemplificar a sua utilizao. No Capitulo VI, Concluso, so apresentadas as concluses deste trabalho, suas possveis implementaes e perspectivas futuras. O Apndice I contm o Questionrio de Identificao do Perfil do Especialista. O Apndice II apresenta o conjunto dos atributos de qualidade de especificaes de requisitos de software. O Apndice III mostra o instrumento para hierarquizar critrios de qualidade de especificaes de requisitos de software. Finalmente, o Apndice IV possui o formulrio utilizado para a avaliao da qualidade de especificaes de requisitos de software para sistemas reais.
Captulo II QUALIDADE DE SOFTWARE

A globalizao da economia, a evoluo clere da tecnologia de informao e o movimento irreversvel da qualidade esto alavancando o processo de restruturao de conceitos, princpios e crenas, onde organizaes bem sucedidas fundamentam suas estratgias e seus planejamentos, para assegurar a vantagem competitiva no mercado (ALMEIDA et al., 1995). Esta a chamada era das organizaes baseadas em conhecimento ou era do capitalismo intelectual (BELASCO et al., 1994, PETERS, 1993). A introduo do Brasil, na conjuntura das economias mais desenvolvidas, est subordinada modernizao de sua indstria, alinhada a grandes reformas estruturais. Nesta direo, surgiu o Programa Brasileiro da Qualidade e Produtividade (PBQP), com o intuito de estabelecer um conjunto ordenado de aes indutoras modernizao industrial e tecnolgica brasileira, contribuindo para a retomada do desenvolvimento econmico e social. Posteriormente, foi criado o Subprograma Setorial da Qualidade e Produtividade em Software (SSQP/SW) que, entre outras funes, fornece o diagnstico do setor em relao qualidade e produtividade, analisa tendncias mundiais, e traa aes estratgicas, que influenciam na aquisio de padres internacionais de qualidade e produtividade (WEBER et al., 1997). Neste contexto, o engenheiro de software solicitado a atuar como um agente para promover a qualidade de produtos e servios. No entanto, a consolidao das prticas de engenharia de software ainda depende (LUCENA, 1991): do entendimento do processo de desenvolvimento de software; do desenvolvimento de uma tecnologia de reuso robusta (ROCHA et al., 1996, WERNER et al., 1996, CALDIERA, 1991); da larga utilizao de ferramentas de software;
4
Captulo II Qualidade de Software ___________________________________________________________________________
da estabilidade no gerenciamento de software (mtricas); da transferncia conjunta de tecnologia (treinamento) e de pesquisa. O desenvolvimento de produtos de software tem-se mantido uma atividade complexa, devido necessidade de serem construdos projetos, que combinem mltiplos requisitos entre si, envolvam vrias equipes de trabalho e produtos no materiais, associados a seus programas e suas documentaes (HAASE et al., 1994, SCHWARE, 1992). Um software perfeito, para um sistema complexo, no pode ser garantido na prtica (COBB et al., 1990). Um software, que atenda a suas especificaes satisfatoriamente, pode conter erros, uma vez que essas especificaes podem estar incorretas. Um software que tenha uma especificao isenta de erros e atenda a ela, pode ser usado indevidamente por seus usurios. A questo , portanto, quando tornar o software operacional e como salvaguardar seus usurios de erros, que possam ser evitados. Neste contexto, o software difere de outros produtos, em vrios aspectos crticos (COLLINS et al., 1994): erros graves podem permanecer no produto de software, mesmo depois de testes rigorosos, em virtude de sua complexidade lgica; no trivial estabelecer padres uniformes de software, que possam ser matria de regulamentao e inspeo; o software afeta um grande e crescente nmero de indivduos, devido a sua fcil reproduo e maleabilidade em computadores (MOOR, 1985), largamente propalados; uma pequena equipe e a baixo custo, pode produzir software, levando no somente a proliferao de fornecedores de software, como tambm a produtos de qualidade inferior. Atualmente, a tendncia das instituies reduzir o nmero de seus fornecedores de software, excluindo de seus negcios os que no esto habilitados a proverem software de boa qualidade, uma vez que a qualidade passou a ser um fator crtico para a sobrevivncia e o sucesso das organizaes (MILLER et al., 1993, SANDERS et al., 1994).
II.1. Conceitos de Qualidade

No se pode pensar em qualidade como sinnimo de perfeio. Trata-se de algo factvel, relativo, substancialmente dinmico e evolutivo, amoldando-se granularidade dos objetivos a serem atingidos. Consider-la como algo absoluto e definitivo seria transportar-se para o inatingvel e, com base neste sofisma, propiciar entraves a qualquer esforo de produzi-la. Para se ter uma noo mais abrangente sobre qualidade, descreve-se, a seguir, a viso conceitual de vrios pesquisadores neste assunto. Qualidade uma caracterstica intrnseca e multifacetada de um produto (BASILI, et al., 1991, TAUSWORTHE, 1995). A relevncia de cada faceta pode variar com o contexto e ao longo do tempo, pois as pessoas podem mudar seus posicionamentos e atualizar seus referenciais, com relao a um objeto ou a uma questo. Portanto, a qualidade no absoluta, mas depende da perspectiva do avaliador. Como tal, qualquer medida de qualidade deve ser subjetiva, sumarizando as impresses de alguma classe particular de indivduos, que interajam com o produto (GENTLEMAN, 1996). Qualidade um conceito complexo, porque possui significados diversos para diferentes pessoas, em um contexto altamente dependente. Portanto, no trivial haver medidas simples de qualidade aceitveis para todos. Para estimar ou melhorar a qualidade de software numa organizao, deve-se definir as caractersticas de qualidade, que se est interessado e, ento, decidir como sero medidas (KITCHENHAM et al., 1996). Qualidade um conceito multidimensional, realizando-se por intermdio de um conjunto de atributos ou caractersticas. As empresas responsveis pelo desenvolvimento de software devem assumir a responsabilidade de estabelecer este nvel aceitvel de qualidade e meios para verificar se ele foi alcanado. Qualidade de software , portanto, um conjunto de propriedades a serem satisfeitas, em determinado grau, de modo que o software satisfaa as necessidades de seus usurios (ROCHA, 1987). Qualidade de software o grau para que o software processe uma combinao desejvel de atributos (IEEE, 1988). Para realizar uma alta qualidade de software, essa combinao desejada de atributos deve ser claramente definida, caso contrrio a qualidade passa a ser intuio (SCHNEIDEWIND, 1993, BELCHIOR, 1992b). Quando se deseja um produto de software de alta qualidade, deve-se assegurar que cada uma de suas partes constituintes possua alta qualidade (HUMPHREY, 1995).
6
Portanto, os resultados intermedirios, no processo de produo, devem ser imediatamente examinados aps sua concluso, procurando garantir que erros e inadequaes no produto sejam detectados o mais cedo possvel, pois a qualidade final do produto uma funo de todas as fases anteriores de seu ciclo de desenvolvimento. Em IEEE (1990), a qualidade j definida como o grau pelo qual um sistema, um componente ou um processo satisfazem seus requisitos especificados, e as necessidades ou expectativas de clientes ou usurios. A ISO 8402 (ISO, 1994) enuncia qualidade como a totalidade de caractersticas de uma entidade, que lhe confere a capacidade de satisfazer suas necessidades explcitas e implcitas. A ISO/IEC 9126 (ISO, 1991) fornece o significado de caractersticas de qualidade de software, como sendo uma referncia bsica qualidade de um produto de software, utilizada em uma avaliao. PFLEEGER (1991) props que um software de alta qualidade deve possuir caractersticas, que atendam s necessidades de usurios, desenvolvedores e manutenedores. Seguindo o mesmo enfoque, PRESSMAN (1992) define qualidade de software como o conjunto das adequaes aos requisitos funcionais e de desempenho, documentao inteligvel dos padres de desenvolvimento e caractersticas implcitas esperadas por todos os seus profissionais. Para CROSBY (1990), qualidade a conformidade do produto com os requisitos ou especificaes estabelecidos. Vrios pesquisadores conceituam qualidade de software apenas como uma implementao correta de sua especificao (TINNIRELLO, 1995, JOYCE, 1994, HAILSTONE, 1991, SCHACH, 1990). Esta definio pode ser usada durante o desenvolvimento de produtos, mas inadequada para se realizar comparaes entre produtos (SIMMONS, 1996). Na viso de CAMPOS (1990), o conceito de qualidade acomoda-se no equilbrio dos seguintes fatores: qualidade intrnseca do produto ou servio: pode ser atestada por estar em conformidade com as normas, ou avaliada pela ausncia ou presena de certos critrios; custo: corresponde ao preo, pelo qual o usurio se dispe a pagar;
atendimento: pode ser entendido como a satisfao do usurio quanto a tempo, espao e quantidade. Qualidade, portanto, no significa somente excelncia ou um outro atributo de um certo produto final. A qualidade dever ser perseguida dentro da organizao, pois, certamente, isto o que os usurios esperam de um produto.
II.2 Em Busca da Qualidade

H muitas maneiras de se selecionar uma estratgia de qualidade: (i) buscar a melhoria de processos, pois muitos erros no produto so conseqncias do processo utilizado; (ii) esforar-se em melhorar a forma de encontrar e corrigir defeitos; (iii) identificar a causa dos erros, que produziram defeitos (GALE et al., 1990, MAYS et al., 1990). DEMING (1986) sugere o ciclo Planejar-Executar-Verificar-Agir (Plan-DoCheck-Act), para processos orientados qualidade, na construo de um produto. Na fase Planejar, so estabelecidos os alvos a serem atingidos, na medio dos atributos de qualidade do produto. Na fase Executar, o produto elaborado em concordncia com os padres de desenvolvimento e guias de qualidade. Na fase Verificar, o produto confrontado com seus objetivos de qualidade. Na fase Agir, so gerados relatrios de possveis problemas, que se tornam base para aes corretivas. A garantia da qualidade do software est diretamente relacionada com as caractersticas de qualidade dos produtos intermedirios e de seu processo de desenvolvimento (TROSTER et al., 1995, BAZZANA et al., 1993). Os padres ISO 9000 enfatizam que a melhoria contnua de processos resultar na melhoria de produtos e servios (SCHMAUCH, 1994). Um padro efetivo se, quando, usado apropriadamente, melhora a qualidade dos resultados e reduz os custos dos produtos de software (FENTON, 1996). H fortes evidncias de que padres e seus guias relacionados contribuam para a melhoria da qualidade do produto (SCHNEIDEWIND, 1996). A ISO 9000 um padro internacional de qualidade, que aplica o gerenciamento da qualidade do processo para gerar produtos, que atentam s expectativas de seus usurios. Esses padres foram criados sob a premissa de que, se o desenvolvimento e o gerenciamento do sistema so de boa qualidade, ento, o produto ou o servio resultante
tambm ser de boa qualidade. Um sistema de qualidade em conformidade com a ISO 9000 assegurar que seu processo de desenvolvimento possui um nvel de controle, disciplina e repetibilidade, garantindo a qualidade de seus produtos (SCHMAUCH, 1994). A busca de qualidade e produtividade no desenvolvimento tem sido intensa. No entanto, ainda no est bem definido como se desenvolver software de qualidade. A avaliao da qualidade e a tentativa de corrigir erros no produto, por si s, mostrou-se insuficiente e limitada para garantir a qualidade. Atualmente, tem-se evidenciado que a qualidade do produto depende, fortemente, da qualidade e adequao de seu processo de desenvolvimento. Desta forma, a qualidade do processo passou a ser vista como um prrequisito e condicionante da qualidade do produto (ROCHA, 1997, ROCHA et al., 1994).
II.2.1 Qualidade de Processos de Software

O processo de software uma seqncia de estgios para desenvolver ou manter o software, apresentando estruturas tcnicas e de gerenciamento para o uso de mtodos e ferramentas, e incluindo pessoas para as tarefas do sistema (HUMPHREY, 1995). A avaliao de processos de software objetiva (OLIVEIRA et al., 1995c): a compreenso do estado dos processos de uma organizao, para a melhoria dos mesmos; estabelecer a conformidade dos processos de uma organizao para com um requisito em particular ou uma classe de requisitos; determinar a adequao dos processos de uma outra organizao com um contrato ou uma classe de contratos. A ISO/IEC 12207 define os processos do ciclo de vida do software, como sendo constitudos por um conjunto de atividades, formadas tambm por um conjunto de tarefas. As atividades, que devem ser realizadas durante o ciclo de vida do software, esto divididas em cinco processos primrios (aquisio, fornecimento, desenvolvimento, operao e manuteno), em oito processos de suporte (documentao, gerncia de configurao, garantia da qualidade, verificao, validao, reviso conjunta, auditoria e resoluo do problema) e em quatro processos organizacionais (gerenciamento, infraestrutura, melhoria e treinamento) (ISO, 1995).
Os padres ISO 9000-3 enunciam procedimentos para a garantia da qualidade de software em relao a seu processo de desenvolvimento, presumindo que o produto de software o resultado de um acordo contratual entre um cliente e um fornecedor, sendo este ltimo uma organizao com um sistema de qualidade suportado pela ISO 9000. A ISO 9000-3 est constituda de trs partes (ISO, 1990): Estrutura: envolve aspectos organizacionais da produo de software. Atividades do ciclo de vida: define as aes necessrias para as fases ao longo do processo de desenvolvimento. Atividades de apoio: estabelece atividades de suporte produo, operao e manuteno de software. A aceitao do padro internacional de qualidade ISO 9000 tem despertado um grande interesse das organizaes, pois, atravs dele, podem conquistar sua certificao de qualidade. Essa certificao, significa alcanar um padro internacional em seus processos. Da mesma forma, os clientes, que adquirem produtos e servios, vem, nessa certificao, um indicador que assegura a qualidade de seus fornecedores (WEBER et al., 1997, DAVIS et al., 1993, SANDERS et al., 1994). Muitas organizaes buscam novos paradigmas, que conduzam a uma melhoria contnua e progressiva da qualidade de seus processos, atenuando os problemas com o desenvolvimento de seus produtos de software. Assim, surgiram alguns modelos, como o Modelo de Maturidade e Capacidade do Software (Capability Maturity Model CMM) (SEI, 1995).
II.2.1.1 O CMM
Desde o incio desta dcada, o CMM vem sendo implantado em muitas organizaes urbe et orbi, objetivando a padronizao e a melhoria de processos de desenvolvimento de software. Esse objetivo segue a tendncia da globalizao da economia mundial, onde a padronizao da produo de software surge como um elemento estratgico, para a obteno de novos mercados e seu posterior controle (BASTOS, 1996). O princpio fundamental desse modelo que a qualidade do produto de software alcanada atravs da melhoria da qualidade de seus processos (SANDERS et al., 1994).
10
O CMM estruturado em cinco nveis em ordem crescente de maturidade. Quando a organizao se encontra em um certo nvel, deve seguir atividades determinadas pelo modelo, para atingir o nvel seguinte (HUMPHREY, 1991): Nvel 1 ou inicial: as organizaes no possuem um ambiente estvel para o desenvolvimento e a manuteno de software, ficando na dependncia exclusiva da habilidade e eficcia de seu pessoal tcnico. Nvel 2 ou repetitivo: a instituio j possui projetos, cujos processos so gerenciados, medidos, documentados, tendo sua equipe devidamente treinada. Nvel 3 ou definido: h uma retroalimentao contnua do aprendizado dos processos utilizados na empresa, havendo, para isto, uma biblioteca de processos padres, que podem ser escolhidos durante a fase de planejamento. Nvel 4 ou gerenciado: so estabelecidas mtricas mais estritas, para a identificao de pontos crticos e oportunidades de melhoria. Nvel 5 ou otimizado: a organizao se encontra em uma contnua melhoria de seus processos. A partir do nvel 2 do CMM, so includos grupos de atividades chaves, KPAs (key process areas), que tm por objetivo segmentar e facilitar o trabalho de melhoria dos processos de software, em cada nvel considerado. As KPAs so conjuntos de atividades a serem seguidas, visando a obteno de um novo nvel de maturidade, e esto subdividas em: (i) alvos, (ii) desempenho de execuo, (iii) habilidades para execuo, (iv) atividades de execuo, (v) medidas e anlise, e (vi) verificao da implementao (SAIEDIAN et al., 1995). Conforme estudos do SEI/CMU, uma empresa de software, que alcance certificao ISO 9001, atende a todos os requisitos para ser classificada no nvel 2 do CMM, mesmo que tenha alcanado alguns dos requisitos de nveis superiores (WEBER, 1997). O CMM possui quatro critrios para determinar se h compromissos e habilidade para a garantia da qualidade (JONES, 1995): Existe pessoal designado para uma unidade organizacional, responsvel pela garantia da qualidade? H recursos financeiros (e outros) suficientes e disponveis para a realizao do trabalho desse pessoal?
11
O pessoal responsvel pela qualidade tem sido treinado, de tal forma que estejam conscientes do que esperado deles e de como faro o seu trabalho? O grupo de garantia da qualidade tido como pessoal de alto nvel, que est satisfeito com o que faz? Entretanto, o CMM tem sido criticado por alguns pesquisadores por no ter uma base terica formal, sendo fundamentado na experincia de um grupo de pessoas. BACH (1994), por exemplo, argumenta que o CMM uma mistificao do processo evolutivo e no uma representao legtima do processo de software, podendo levar a organizao a um colapso em seu potencial competitivo.
II.2.1.2 Bootstrap e Trillium

O Bootstrap (KUVAJA et al., 1994), derivado do modelo CMM, um projeto que faz parte do Projeto Esprit, desenvolvido na Comunidade Europia, para avaliao de organizaes. O Bootstrap desenvolve um mtodo de avaliao, medio quantitativa e melhoria do processo de software. Avalia, tambm, as unidades produtoras de software e seus projetos. Alm disso, determina o nvel de maturidade da organizao, identificando mritos e deficincias, fornecendo guias para aperfeioamento da mesma. O Trillium (BELL, 1994), desenvolvido no Canad, derivado, tambm, do modelo CMM e de outros modelos para a avaliao de organizaes. O objetivo do Trillium prover um mtodo para o incio e a conduo de um programa de melhoramento contnuo da qualidade de processos. O projeto Trillium orientado s telecomunicaes, fornecendo uma perspectiva do produto, segundo os padres ISO, sendo desenvolvido sob a perspectiva do cliente (TRILLIUM, 1997).
II.2.1.3 O Projeto SPICE

O Projeto SPICE (Software Process Improvement and Capability dEtermination), figura II.1, objetiva a criao de normas para avaliao de processos e a contnua melhoria desses processos, baseando-se nas melhores caractersticas de modelos de avaliao como o CMM, Trillium e Bootstrap.
Processo examinado pela 12 identifica capacidade e riscos d
identifica mudanas no
Avaliao do Processo leva Melhoria do Processo motiva Capacitao do Processo leva
Figura II.1: Avaliao de Processos de Software: Projeto SPICE (OLIVEIRA et al., 1995c)
A melhoria de processos realizada atravs de avaliaes, que descrevam prticas usuais da organizao, de uma unidade organizacional ou de um projeto. A anlise dos resultados feita em relao s necessidades do negcio da organizao, levantando aspectos negativos e positivos, como tambm os riscos envolvidos no processo. O Projeto SPICE pode ser usado por organizaes com atividades de planejamento, gerenciamento, monitorao, controle, fornecimento, desenvolvimento, operao e suporte de software. Esse projeto interessante por seu direcionamento e sua flexibilidade, para que as organizaes que o utilizem, determinem a capacitao de cada um de seus processos com o intuito de promover melhorias contnuas nos mesmos. Desta forma, obtm-se uma avaliao mais detalhada do estado da organizao (TSUKUMO et al., 1996b). A estratgia de melhoria de processos deve ser dinmica, pois, para assegurar a qualidade de produtos de software, as habilidades se multiplicam, a tecnologia modificada, e surgem novos ambientes de trabalho (HUMPHREY, 1995).
II.2.2 Qualidade de Produtos de Software

Para a avaliao da qualidade de produtos de software, as organizaes internacionais de normalizao ISO/IEC definiram as seguintes normas (SCALET, 1995): Caractersticas de qualidade e mtricas: compreendendo (i) caractersticas e subcaractersticas da qualidade, (ii) mtricas externas e (iii) mtricas internas. Avaliao dos produtos de software: envolvendo (i) a viso geral do produto, (ii) o planejamento e o gerenciamento, (iii) o processo para equipe de desenvolvimento, (iv) o processo para adquirentes, (v) o processo para avaliadores, e (vi) os mdulos de avaliao. Requisitos de qualidade e teste de pacote de software.
13
A estrutura da ISO/IEC 9126 possui, tambm, um conjunto de documentos tcnicos, que definem caractersticas de qualidade de software e seus indicadores, orientando o planejamento e a execuo da avaliao (SCALET, 1995): ISO/IEC 9126-1: fornece caractersticas e subcaractersticas de qualidade, sendo uma norma essencialmente de definies (WEBER, 1997, TSUKUMO et al., 1995, HAUSEN et al., 1993), com representado na tabela II.1. ISO/IEC 9126-2: define mtricas externas para a medio das caractersticas e subcaractersticas de qualidade da ISO/IEC 9126-1. Essas mtricas referem-se a medies indiretas de um produto de software, a partir da medio do comportamento do sistema computacional, do qual o produto faz parte. ISO/IEC 9126-3: estabelece mtricas internas para a avaliao de um produto de software. Essas mtricas referem-se a medies diretas de um produto, a partir de sua caractersticas internas, sem que seja necessria a execuo do programa.
QUALIDADE DE PRODUTOS DE SOFTWARE - ISO/IEC 9126 CARACTERSTICAS FUNCIONALIDADE: as funes e propriedades especficas do produto, satisfazem as necessidades do usurio Subcaractersticas Adequao: existncia de um conjunto de funes apropriadas para as tarefas requeridas Acurcia: produo de resultados ou efeitos corretos Interoperabilidade: habilidade de interao do produto de software com outros produtos Conformidade: o produto est de acordo com as convenes, as normas ou os regulamentos estabelecidos Segurana: aptido para evitar acessos no autorizados a programas e dados. CONFIABILIDADE: o produto de software capaz de manter seu nvel de desempenho, ao longo do tempo, nas condies estabelecidas Maturidade: estado de maturao do software, detectada por sua baixa freqncia de falhas Tolerncia a falhas: o nvel de desempenho mantido, quando ocorrem falhas Recuperabilidade: existem mecanismos que restabelecem e restauram os dados aps a ocorrncia de falhas USABILIDADE: esforo necessrio para a utilizao do sistema, baseado em um conjunto de implicaes e de condies do usurio EFICINCIA: os recursos e os tempos envolvidos so compatveis com o nvel de desempenho requerido pelo software Inteligibilidade: facilidade de entendimento dos conceitos utilizados no produto de software Apreensibilidade: facilidade de aprendizado do software Operacionalidade: faculdade de operar e controlar operaes pertinentes ao software Comportamento no tempo: refere-se ao tempo de resposta de processamento Comportamento dos recursos: relaciona-se com a quantidade dos recursos empregados
14

MANUTENIBILIDADE: refere-se ao esforo necessrio para a realizao de alteraes especficas, no produto de software Analisabilidade: caracterstica de ser possvel diagnosticar deficincias e causas de falhas Modificabilidade: caracterstica que o produto deve ter de forma a facilitar modificaes e remoes de defeitos. Estabilidade: ausncia de riscos ou ocorrncias de defeitos inesperados no software Testabilidade: facilidade de o produto ser testado PORTATILIDADE: facilidade de o software pode ser transferido de um ambiente para outro Adaptabilidade: faculdade de o produto poder ser adaptado a novos ambientes Instalabilidade: facilidade de instalao do produto de software Conformidade com padres de portatilidade: o produto est segundo os padres ou convenes de portatilidade Substituibilidade: o produto de software pode ser substitudo por outro, sem grandes esforos
Tabela II.1: Caractersticas e subcaractersticas de software - ISO/IEC 9126
Alm das caractersticas de qualidade do produto e processo, SIMMONS (1996) aponta o resultado do desenvolvimento do software como o terceiro nvel de qualidade, considerado como de grande interesse no gerenciamento dos negcios. BAZZANA et al. (1993) considera a norma ISO/IEC 9126 (ISO, 1991) como o padro para a modelagem da qualidade de software, pois, em uma pesquisa realizada em pases da Comunidade Europia, 70% dos entrevistados j haviam, pelo menos, ouvido falar dela. Apesar da grande relevncia da ISO/IEC 9126, h dificuldades em adequar sua aplicabilidade na avaliao prtica de produtos de software (TSUKUMO et al., 1996a), pois as caractersticas de qualidade, por ela determinadas, no so diretamente mensurveis (KITCHENHAM et al., 1996). Portanto, para que se obtenha a qualidade desejada de produtos de software, fazemse necessrios modelos que viabilizem a avaliao da qualidade desses produtos. Segundo STAA (1987), no mais tolerado o uso de modelos artesanais na elaborao de programas, pois necessrio assegurar um nvel elevado de qualidade de produtos de software.
II.2.2.1 Modelos para Avaliao da Qualidade de Software

O principal propsito da avaliao da qualidade de software fornecer resultados quantitativos referentes aos produtos de software, que sejam compreensveis, aceitveis
15
e confiveis por qualquer parte interessada (ISO, 1987). A satisfao dos usurios e o retorno econmico so, tambm, importantes consideraes que devem conduzir efetivamente a avaliao da qualidade de um produto de software (KUMAR et al., 1992). A avaliao da qualidade de software pode ser feita em vrias etapas: (i) definio dos requisitos de qualidade, (ii) seleo de mtricas e definio de nveis de graduao, (iii) medio e graduao, (iv) estimativa (DROMEY, 1996, BOEGH et al., 1992, BOEGH et al., 1993, MIYOSHI et al., 1993). Sem um conjunto bem definido de requisitos de qualidade, os projetos de software tornam-se vulnerveis a falhas (BOEHM et al., 1996). Para a anlise e a robustez de novos projetos de software, podem ser usados requisitos de qualidade de projetos j concludos, com caractersticas semelhantes (BOLOIX et al., 1995). A quantificao dos nveis de requisitos de qualidade implica na escolha de mtricas apropriadas e na definio de modelos para medir essas mtricas (MAININI et al., 1990). Os modelos devem mapear a realidade, e/ou os requisitos pretendidos pelo usurio, enfocando as mltiplas questes referentes construo do produto, e monitorando possveis desvios. Neste contexto, os modelos de avaliao da qualidade esto diretamente associados com o processo de medio, determinando como as medidas sero executadas e planejadas (OLIV et al., 1996). Um bom mtodo de desenvolvimento no garante, necessariamente, um produto de qualidade. Deve-se considerar, tambm, fatores de suporte deciso, como a qualidade da equipe de desenvolvimento, e a presso do tempo sob a qual os elementos da equipe devem trabalhar (STRIGINI, 1996). Ganhos significativos em qualidade de software no sero alcanados at que haja um modelo compreensivo e disponvel de qualidade de produto. O maior desafio na proposio de um modelo de qualidade de software encontrar uma estrutura que possa acomodar a riqueza do conhecimento disponvel sobre qualidade, de forma que seja construtivo, refinvel e intelectualmente gerencivel. Neste contexto, um modelo deve fornecer (DROMEY, 1995):
16
orientao sistemtica para o desenvolvimento de produtos de software de qualidade; recursos para identificar e classificar caractersticas de qualidade e defeitos em software; uma estrutura que seja inteligvel, refinvel e adaptvel em uma camada de nveis. Tm surgido vrios modelos para avaliao da qualidade de software, como, por exemplo, o Paradigma GQM (BASILI et al., 1987), o Projeto SCOPE (BOEGH et al., 1993), e o Modelo Rocha (ROCHA, 1983). II.2.2.1.1 O Paradigma GQM O paradigma GQM (Goal/Question/Metric) uma estrutura para o desenvolvimento de um programa de mtricas: definio, planejamento, construo, anlise e feedback. Foi desenvolvido para vrias reas de estudo, especialmente aquelas concernentes a questes de melhoramento, e consiste nas trs etapas seguintes (BASILI et al., 1994, BASILI et al., 1987): Gerar um conjunto de alvos: baseando-se nas necessidades da organizao, determina-se o que se quer melhorar e, ento, definem-se alvos em termos de propsitos, perspectivas e ambientes, usando-se modelos genricos. i. Propsito: manuseia (caracteriza, avalia, prediz, etc.) o objeto (processo, produto, modelo, mtrica, etc.), com o propsito de entender (estimar, gerenciar, melhorar, etc.) esse objeto. ii. Perspectiva: examina custo, correo, defeitos, mudanas, mtricas de produto, confiabilidade, etc. sob o ponto de vista do desenvolvedor, gerente, cliente, etc. iii. Ambiente: consiste em fatores (de processo, pessoas, problemas, etc.) e mtodos, ferramentas, restries, etc. Derivar um conjunto de questes: as questes quantificam os alvos como sendo possveis, requerendo a interpretao de termos nebulosos, dentro do contexto do ambiente de desenvolvimento. As questes so classificadas como sendo relacionadas a produtos ou processos e fornecem feedback da perspectiva de qualidade.
17
Desenvolver um conjunto de mtricas: essas mtricas fornecem as informaes necessrias para responder a cada questo. As mtricas podem ser objetivas e subjetivas e possuem guias de interpretao, isto , um valor que indique se o produto de alta qualidade. Geralmente, uma questo no respondida simplesmente por uma mtrica, mas por uma combinao de mtricas. Uma vez definidos os alvos, derivadas as questes, e desenvolvidas as mtricas, so criadas matrizes para relacionar alvos/questes/mtricas.
II.2.2.1.2 O Projeto SCOPE Na estrutura de pesquisa e desenvolvimento do Projeto Esprit, o projeto que trata das questes de certificao da qualidade de produtos de software chamado SCOPE (Software CertificatiOn Programme in Europe). Um dos mais importantes resultados desse projeto a definio de uma estrutura de avaliao, que tem sido experimentada em muitos estudos de caso. A avaliao realizada para vrios ciclos de vida, atravs do uso de diversas classes de mtricas como o tamanho, a estrutura de fluxo de controle, a modularidade e fluxo de informao, a estrutura de dados, a eficincia e complexidade de algoritmos, e medidas gerais de complexidade. Os principais objetivos do Projeto SCOPE so (BAZZANA et al., 1993): elucidar o relacionamento entre fornecedores e clientes, atravs de procedimentos de definio, permitindo concesses de um selo de qualidade, quando um produto possui um determinado conjunto de atributos de qualidade; desenvolver tecnologias de avaliao eficientes e efetivas, para a concesso do selo de certificao; promover a divulgao de modernas tecnologias de engenharia de software, para que sejam usadas durante o desenvolvimento de produtos de software. II.2.2.1.3 O Modelo Rocha O Modelo Rocha (ROCHA, 1983) para qualidade de produtos de software, define qualidade a partir dos seguintes conceitos: 1. Objetivos da qualidade: so as propriedades gerais, que o produto deve possuir.
18
2. Fatores de qualidade: determinam a qualidade na viso dos diferentes usurios do produto. Podem ser compostos por subfatores, quando estes no definem completamente, por si s, um objetivo. 3. Critrios: so atributos primitivos, possveis de serem avaliados. 4. Processos de avaliao: determinam o processo e os instrumentos a serem utilizados, de forma a se medir o grau de presena, no produto, de um determinado critrio. 5. Medidas: so o resultado da avaliao do produto, segundo os critrios. 6. Medidas agregadas: so o resultado da agregao das medidas obtidas ao se avaliar de acordo com os critrios, e quantificam os fatores. Os objetivos de qualidade so atingidos atravs dos fatores de qualidade, que podem ser compostos por subfatores. Objetivos, fatores e subfatores no so, diretamente, mensurveis e s podem ser avaliados atravs de critrios. Um critrio um atributo primitivo. Nenhum critrio isolado uma descrio completa de um determinado fator ou subfator. Da mesma maneira, nenhum fator define completamente um objetivo. O Modelo Rocha foi utilizado para definir qualidade em especificao de requisitos (CLUNIE, 1987), especificaes de requisitos e projetos orientados a objetos (CLUNIE, 1997), especificaes de projeto (PASSOS, 1991) e cdigo (BELCHIOR, 1992a, ANDRADE, 1991). Segundo Chung (CHUNG et al., 1995), os modelos para avaliao da qualidade de produtos de software devem considerar, tambm, as caractersticas peculiares dos domnios de aplicao (TERVONEN, 1996, BAZZANA et al., 1993), definindo um conjunto de requisitos da qualidade e seus processos de avaliao. Neste contexto, o Modelo Rocha foi utilizado, tambm, para definir vrios domnios de aplicao, juntamente com seus processos de avaliao: software cientfico (COMMERLATO, 1994, BAHIA, 1992, PALERMO et al., 1989), software financeiro (BELCHIOR, 1992b), software educacional (CAMPOS, 1994a, CAMPOS, 1994b), sistemas especialistas (OLIVEIRA, 1995b), software mdico (CARVALHO, 1994), sistemas de informao (BLASCHEK, 1995), sistemas de acesso pblico (VALLE, 1997) e software orientado a objetos (CLUNIE, 1997, COELHO, 1997). No captulo IV,
19
o Modelo Rocha estendido, para suportar a utilizao da teoria fuzzy, na avaliao de produtos de software. A medio a pedra angular de modelos industriais, que retratam um processo estvel e divisvel em um nmero de etapas, onde o processo monitorado e medies so realizadas e comparadas, para a padronizao de suas caractersticas (DUNN, 1990). As mtricas so, por conseguinte, inseparveis do modelo de desenvolvimento de produto de software (ROMBACH, 1990).
II.3 Mtricas de Qualidade de Software

Muitos trabalhos tm usado a teoria das medies para mtricas de software (FENTON et al., 1997, KITCHENHAM et al., 1996, PRATHER, 1996, ROSSI et al, 1996, ZAGE et al., 1995, FENTON, 1994, AMBRIOLA et al., 1994, MLLER, 1993, SCHNEIDEWIND, 1992, FENTON et al., 1991, BAKER, 1990, ZUSE, 1990, INCE, 1990, SHEPPERD, 1989, FINKELSTEIN, 1984), e aplicado mtricas para controlar e estimar desenvolvimento formal (RAFFY, 1995, WHITTY, 1990). Um projeto de software um processo de tomada de deciso, onde mtricas podem ser usadas para fornecer uma base de identificao de procedimentos, que no estejam em conformidade com os alvos pretendidos, e medidas de atributos de projeto, alm de auxiliar na elaborao de novas solues, que levem melhoria da qualidade (YU, 1995). J no mais aceitvel conceber projetos de engenharia de software, que lidem com alvos firmados em ambigidades e abstraes (GILB, 1996). Menos que o perfeito bom o bastante (YOURDON, 1995). Somente os alvos e as prioridades podem determinar quanto menos que o perfeito pode ser aceitvel. O primeiro passo de qualquer pesquisa, baseada em mtricas, formular os alvos a serem alcanados: Qual o propsito da pesquisa? Quem usar as medidas e para que fim? Assim, os alvos podem ser refinados em questes mais especficas, identificando-se mtricas, que forneam respostas quantitativas a estas questes (SHEPPERD, 1990). Mtricas podem ser definidas como um processo pelo qual nmeros ou smbolos so atribudos a requisitos de entidades do mundo real, descrevendo-as segundo regras claramente definidas (MELTON, 1996, HABRIAS, 1995, SHEPPERD, 1992, FENTON et al., 1991, INCE, 1990).
20
CARD et al., (1990) define mtricas como uma escala de valores possveis, que corresponde s variaes observadas, em uma determinada caracterstica. KARISSON (1995) afirma que as mtricas so valores, que avaliam uma ou mais caractersticas de um produto. INCE (1990) conceitua mtricas de qualidade de software como medidas numricas, empregadas para quantificar vrios aspectos de um produto de software. MARIANO (1996) considera as mtricas de software como nmeros que, de alguma forma, caracterizam o software produzido ou o processo, que utilizado para produzi-lo. Para MOONEY (1993), as mtricas definem uma base para medies quantitativas de propriedades relevantes e atividades de desenvolvimento e manuteno de software. Embora no haja concordncia universal na teoria de medio, os enfoques so voltados para as seguintes consideraes (FENTON, 1994): o que e o que no medio; que tipos de atributos podem ou no podem ser medidos e em que tipo de escala; como se sabe se um atributo foi realmente medido; como definir escalas de medidas; quando uma margem de erro aceitvel ou no; que declaraes sobre medio so significativas. Um modelo estrutural para medio de software permite descrever os objetos envolvidos na medio e seus relacionamentos como (KITCHENHAM et al., 1995): Entidades: so os objetos observados no mundo real, que so capturados em suas caractersticas e manipulados formalmente. Por exemplo, produtos e processos. Atributos: so propriedades que as entidades possuem. Para um dado atributo, h um relacionamento de interesse no mundo emprico, que, formalmente, se quer apreender no mundo matemtico. Relacionamento entre entidades e atributos: uma entidade pode ter vrios atributos, enquanto que um atributo pode qualificar diferentes entidades. Quando se mede um atributo, aplica-se uma unidade de medida especfica a uma entidade, para se obter um valor correspondente. Quando se considera unidades de medidas, necessrio conhecer os tipos de escala mais comuns: nominal, ordinal, intervalar e proporcional (FENTON et al., 1991).
21
A estrutura das mtricas de qualidade introduz categorias, que se estendem atravs das fases do ciclo de vida do produto, sendo independente do mtodo de desenvolvimento (MLLER, 1993).
II.3.1 Categorias de mtricas

As principais categorias de mtricas de qualidade so: objetivas/subjetivas, absolutas/relativas, explcitas/derivadas, dinmicas/estticas e preditivas/explanatrias. As mtricas objetivas so facilmente quantificadas e medidas atravs de expresses numricas ou representaes grficas dessas expresses, e calculadas de documentos de software. As mtricas subjetivas so medidas relativas baseadas em estimativas pessoais ou de grupo, sendo obtidas por termos lingsticos como alto, mdio, baixo (MLLER, 1993). As mtricas absolutas so tipicamente invariantes para a medio de novos itens, enquanto que as mtricas relativas no o so. As mtricas explcitas ou diretas no dependem da medida de outro atributo, quantificando um fator observado no produto. As mtricas derivadas ou indiretas de um atributo envolvem medidas de um ou mais atributos a ele relacionados (FENTON 1994, PRESSMAN, 1992). As mtricas dinmicas possuem uma dimenso temporal. As mtricas estticas permanecem invariveis a despeito do tempo. As mtricas preditivas ou mtricas a priori (KARISSON, 1995) podem ser obtidas ou geradas previamente, para realizar prognsticos do valor de uma propriedade do sistema, que somente se tornar diretamente observvel em um estgio posterior a seu desenvolvimento (PONNAMBALAM, 1996, FENTON, 1994, SCHNEIDEWIND, 1992, FARBEY, 1990, ZUSE, 1990, KITCHENHAM et al., 1990c, BROCKLEHURST et al., 1990). Para as mtricas preditivas, tambm, necessita-se definir procedimentos (estatsticos ou probabilsticos, por exemplo), para determinao de parmetros de seu modelo de medio e interpretao de resultados (FENTON, 1994). As mtricas explanatrias, tambm conhecidas como mtricas de resultado (INCE 1990), mtricas descritivas (PONNAMBALAM, 1996) ou mtricas a posteriori (KARISSON, 1995) so geradas depois do fato ocorrido, baseadas em dados coletados,
22
indicando, simplesmente, o estado atual do produto. Por exemplo, a medio do nmero de falhas de testes (SCHNEIDEWIND, 1995), em um perodo de tempo, pode indicar a confiabilidade do software. Existem, tambm, as mtricas de produto (PONNAMBALAM, 1996,
BERTOLINO et al., 1996, LIGGESMEYER, 1995, BROEK et al., 1995, BIEMAN, 1994, BACHE et al., 1994, INCE, 1990, McCABE, 1976) e as mtricas de processo (MLLER, 1993, MOONEY, 1993, INCE, 1990). As mtricas de produto indicam, objetivamente, caractersticas mensurveis do produto de software tal como tamanho, complexidade, acoplamento (PONNAMBALAM, 1996). As mtricas de processo medem aspectos de desenvolvimento e manuteno e so, geralmente, usadas para caracterizar os custos destas atividades, como, por exemplo, quo efetivo o processo de remoo de defeitos (MOONEY, 1993). PONNAMBALAM (1996) considera, tambm, mtricas de projeto, como sendo da mesma importncia que as mtricas de produto e de processos. As mtricas de projeto mensuram caractersticas de projeto e sua execuo como, por exemplo, o custo, o cronograma e o nmero de desenvolvedores de software. MUNSON (1995) sugere uma taxonomia para atributos de software, envolvendo alm das mtricas de processo e de produto, tambm, mtricas de pessoal e de ambiente. As mtricas de pessoal consideram os recursos humanos, ao longo do processo de desenvolvimento. As mtricas de ambiente quantificam as circunstncias fsicas, que se referem organizao. Na concepo de MLLER (1993), as mtricas podem ser classificadas, ainda, em mtricas globais e mtricas de fase. Mtricas globais so indicadores de alto nvel, que se disseminam ao longo do processo de desenvolvimento do software, fornecendo direcionamentos para os gerentes. Mtricas de fase so indicadores somente para fases especficas do processo de desenvolvimento do produto de software. A qualidade de software geralmente expressa em funo de diversas mtricas de software, onde diferentes ndices (COLEMAN et al., 1994) medem diferentes aspectos de qualidade (PONNAMBALAM, 1996, OMAN et al., 1994). Na prtica, com o processo de medio, deseja-se saber se um bom software um bom negcio
23
(KITCHENHAM et al., 1996). A seguir, apresentar-se- as principais caractersticas das mtricas de qualidade.
II.3.2 Caractersticas das Mtricas

Uma mtrica pode ser identificada em termos de suas caractersticas. A definio de uma mtrica deve conter (MARIANO, 1996): Nome: identifica a mtrica para o seu uso na organizao. Procedimento de obteno: definio da metodologia de extrao da mtrica (JONES, 1991), pela descrio de seu processo operacional e de seus clculos de construo. Critrios: subsdios para a avaliao dos dados obtidos pelo uso da mtrica. Objetivos: definem a mtrica, favorecendo a sua conveniente interpretao. Localizao: descrio de onde a mtrica deve ser usada, durante o processo de desenvolvimento. As mtricas podem ser classificadas, segundo suas caractersticas gerais, em organizacionais e tcnicas. As caractersticas organizacionais so usadas no ambiente organizacional. So elas (MLLER, 1993): Processo de software e gerenciamento de projeto: mtricas globais so usadas durante todo o ciclo de vida do software e no somente na codificao. Alta visibilidade: uso de um nmero limitado de mtricas, tornando-as mais visveis interna e externamente na organizao. Consistncia na aplicao: aplicao de mtricas de forma consistente em projetos, fornecendo indicaes de sua qualidade relativa, para uma melhoria contnua. Interesse do gerenciamento e suporte: o programa de mtricas deve ter o suporte da gerncia da corporao, para que seja bem sucedido. Aceitao organizacional: o sucesso da aplicao de mtricas depende de sua aceitao pela organizao e, por isso, deve haver uma reviso extensiva das mesmas antes de serem introduzidas como procedimento, para congregar a cultura da instituio.
24
Poltica: o programa de mtricas deve ser bem estruturado, e imune a mudanas infundadas, procurando evitar ofensas a sentimentos pessoais ou causar impactos moralmente negativos (KITCHENHAM et al., 1986). Disponibilidade de dados histricos: altamente desejvel que as mtricas possam utilizar dados, previamente coletados pela organizao, para identificar com destreza o estado corrente de prtica dessa organizao, e seus alvos. Conformidade com o processo de desenvolvimento do produto: as mtricas selecionadas devem estar de acordo com o processo de desenvolvimento do produto de software, apontando reas desse processo, que possam ser melhoradas. Alvos de melhoria do processo: eleger um conjunto de mtricas, que dem suporte aos alvos de melhoria de processo, atravs de um plano coerente. Pacincia: pacincia e persistncia devem ser caractersticas de desenvolvedores de um programa de mtricas, pois muitos dados de mtricas, altamente valorosos para a melhoria de muitos processos, somente podem ser coletados ao longo dos anos. As caractersticas tcnicas das mtricas aplicam-se definio da prpria mtrica (MLLER, 1993): Nmero limitado: recomendado um nmero limitado de mtricas (cinco ou menos), para facilitar o seu uso e visibilidade, pela equipe de desenvolvimento. Facilidade de clculo: as mtricas devem ser prontamente calculadas, para poderem ser identificadas ou preditas com rapidez, quando um processo de desenvolvimento de software exibe uma tendncia negativa. Disponibilidade de dados: os dados usados nos clculos das mtricas devem estar acessveis. Preciso na definio: as mtricas selecionadas devem ser precisas e suas definies inteligveis. Apoio de ferramentas: as mtricas devem estar apoiadas por ferramentas acessveis, resultando num menor esforo manual na coleta e publicao de dados.
25
Experimentao: de bom alvitre que os desenvolvedores experimentem cuidadosamente as mtricas, que utilizam, podendo substitu-las por outras mais consistentes, quando necessrio. Padronizao: a identificao de padres , extremamente, difcil devido larga variao encontrada nos diferentes tipo de desenvolvimento de aplicaes de software, e ausncia de uniformizao de seus processos. Muitas organizaes usam mtricas, mas falta-lhes um enfoque sistemtico para a coleta e anlise de dados, alm de no darem importncia suficiente e necessria interpretao do uso dessas mtricas, nem questo da padronizao das mesmas (KITCHENHAM, 1990a). Na avaliao do uso de mtricas de software, importante considerar a qualidade das prprias mtricas (SHAW, 1981). Segundo WATTS (1987), as caractersticas que tornam uma mtrica de software de qualidade so: Objetividade: os resultados so independentes de seu medidor; Confiabilidade: os resultados so repetveis e precisos; Validabilidade: os resultados medem as caractersticas pretendidas; Padronizao: a mtrica no possui ambigidades, seguindo um mesmo padro;
Comparabilidade: pode ser comparada com outras medidas para os mesmos
critrios; Economia: a mtrica parcimoniosa e simples em sua utilizao; Utilidade: a mtrica deve comunicar uma necessidade e no simplesmente uma medida para seu prprio fim; Consistncia: a mtrica no deve combinar fatores conflitantes entre si; Automao: a mtrica deve ser mensurvel, atravs de ferramentas apropriadas. H relatos na literatura, que mostram aplicaes de mtricas em ambientes industriais, que tiveram xito na melhoria de processos de desenvolvimento e de produtos de software em KHOSHGOFTAAR et al. (1996), STARK et al. (1994) e GRADY (1994), aumentando a credibilidade na cincia das mtricas. No entanto, ainda existem muitas questes no resolvidas no uso de mtricas de software em aplicaes do mundo real (PONNAMBALAM, 1996).
26
II.3.3 A Aplicao de Mtricas

A aplicao de mtricas, de uma maneira organizada e projetada, apoiada por uma metodologia, possui efeito benfico, tornando os desenvolvedores conscientes da real importncia do gerenciamento e dos compromissos para com a qualidade do produto, oferecendo as seguintes vantagens (MARIANO, 1996, KARISSON, 1995, IEEE, 1987, CONTE, 1986): estabelecer requisitos de qualidade para um sistema, desde o princpio de seu desenvolvimento; definir critrios de aceitao, padronizao e classificao; desenvolver um plano de medidas, baseado nos requisitos estabelecidos; avaliar o nvel de qualidade realizado, confrontando-o com os requisitos estabelecidos; controle do processo de desenvolvimento; melhorar o gerenciamento do produto, oferecendo meios de serem detectadas anomalias ou pontos potenciais de problemas no sistema, ao longo do desenvolvimento; predizer o nvel de qualidade, que ser realizado no futuro; comparar os atributos de qualidade de um sistema com outro; quantificar as mudanas, que podem ser feitas por gerentes na alocao de recursos; monitorar a degradao da qualidade, durante a fase de manuteno; calcular o custo do produto ao longo de seu ciclo de vida. Um dos mtodos para a aplicao de mtricas usar valores de forma similar ao controle estatstico convencional de qualidade, isto , identificar o intervalo numrico que seja aceitvel ou no aceitvel para itens, e rejeitar ou reparar itens com valores de mtricas no aceitveis. Este procedimento para produtos de software mais difcil porque (KITCHENHAM et al., 1990b): Os valores de mtricas aceitveis para componentes de software diferiro de produto para produto. Itens podem ter valores de mtricas em uma regio no aceitvel por diferentes razes, algumas das quais poderia significar que o item
27
de alta qualidade. Portanto, a deciso de rejeitar um item e o mtodo apropriado de reparar so problemas distintos. A indstria de software no pode se basear apenas em distribuies estatsticas convencionais (mdia e desvio padro), para identificar intervalos de medidas, porque as mtricas de software so, invariavelmente, dependentes do produto desenvolvido. Alm disso, os itens de software, que esto sendo mensurados, usualmente no so obtidos de um experimento aleatrio de itens equivalentes. Um problema adicional que, normalmente, o controle da qualidade est baseado em medidas simples. Entretanto, muitos componentes de software somente so de fato avaliados, quando vrios valores de mtricas so agregados. Diferentes observadores de um mesmo produto de software podem obter diferentes medidas, ainda quando a mesma propriedade medida. Os usurios, por exemplo, estimam a qualidade do produto em termos de sua interao com o produto final, isto , esto interessados na confiabilidade e na usabilidade. J a qualidade, segundo a viso da produo, sugere duas caractersticas de medida: contagem de defeitos e custo de retrabalho (KITCHENHAM et al., 1996). A utilizao de mtricas de qualidade, tambm, oferece algumas limitaes (CONTE, 1986): a medio deve ser consistente, com o mnimo de subjetividade, e apoiada em definies precisas, de modo que a anlise dos dados no seja prejudicada; alguns ambientes requerem um ajuste das mtricas utilizadas, para que se reduzam as possibilidades de falhas no processo de avaliao; as mtricas auxiliam no processo de tomada de deciso, todavia no substituem o gerente; as mtricas avaliam o desempenho do produto e no da equipe tcnica. No obstante as mtricas tenham-se mostrado eficientes para auxiliar o desenvolvimento de software, muitos engenheiros de software ainda relutam em utilizlas, pois temem que sejam aplicadas para avaliar o seu prprio desempenho. Isto gera um sentimento de rejeio ao uso de mtricas ou promove a manipulao de nmeros ou do prprio produto de software, para que os alvos da medio sejam alcanados (ZAGE et al., 1995). Neste sentido, GRADY (1992) alerta que as mtricas no sero
28
consistentes e suficientemente definidas, quando algum considera que o uso delas para medir e avaliar pessoas. Um dos propsitos do uso de mtricas , tambm, identificar os aspectos fortes e frgeis da organizao e prover recomendaes para melhorias, baseadas em laudos de estimativa, que forneam organizao uma linha bsica, confrontada por prticas aceitas como adequadas pela indstria de software (MILLER et al., 1993). II.3.3.1 As Medies por Estimativas Na indstria de software, mais do que em outras reas, decises importantes podem depender de julgamentos subjetivos. difcil obter critrios objetivos para essas decises, porque faltam modelos matemticos do comportamento do produto ou dados estatsticos sobre experincias passadas. O argumento para a aceitao de um produto de software deve fundamentar-se, sempre que possvel, em resultados de testes, na solidez das prticas usadas na engenharia de software, principalmente, no rigor da documentao, e no controle da configurao (STRIGINI, 1996). Se os julgamentos subjetivos forem reforados com anlises cientficas podero ter sua confiabilidade incrementada. Entretanto, todo mtodo cientfico, no auxlio a tomada de deciso, tambm, possui suas limitaes, pois as informaes empricas no podem predizer o futuro com absoluto grau de certeza. Alinhando-se os julgamentos subjetivos disciplina cientfica, possvel concluir que deve-se (STRIGINI, 1996): usar mtodos quantitativos, sempre que possvel; projetar experimentos cujos resultados dependam, mais de fatos concretos do que de influncias individuais; explorar como o uso da teoria pode ser refutado por experimentos; verificar a consistncia das conjecturas sobre si mesmas e com fatos conhecidos. Psiclogos, reportando-se a julgamentos intuitivos, tm observado que (AYTON, 1993): no se pode esperar que pessoas sem a devida preparao possam resolver corretamente problemas de intuio em domnios estatsticos e probabilsticos, especialmente, quando as questes so formuladas indiretamente;
29
um especialista geralmente far melhores predies, em sua rea de atuao do que um no especialista. Uma das vantagens de estimativas obtidas de especialistas que estes conhecem a fora potencial e as deficincias do objeto julgado, e como estud-las. A desvantagem que, por conhecer muito, o especialista pode no reconhecer obstculos que impediriam o uso do software por usurios novos ou advindos de outras reas. Em geral, especialistas, que realizam boas estimativas, possuem um razovel conhecimento do ambiente, alm de: (i) fazerem prognsticos freqentemente, (ii) receberem rpidos feedback sobre seus sucessos ou erros, (iii) serem treinados em questes especficas, e (iv) executarem medies. Na realizao de estimativas subjetivas, deve-se tomar alguns cuidados com relao ao questionrio a ser aplicado (STRIGINI, 1996): as questes devem estar expostas claramente e sem ambigidades; as frases das questes formuladas devem ser variadas para ser possvel a verificao de interpretaes intuitivas errneas; desenvolver implicaes das hiptese formuladas, procurando evidncias de refutao. O uso de padres largamente aceitos e reconhecidos pode auxiliar de sobremaneira nas medies por estimativas. Neste sentido, o padro IEEE Std 1061-1992 fornece uma metodologia para o estabelecimento de requisitos de qualidade e identificao, implementao, anlise e validao de mtricas de qualidade de software, aplicada s fases de seu ciclo de vida. Esse padro de mtricas pode ser empregado por uma organizao, em suas aplicaes, independentemente de suas mtricas particulares, mas essencial que essas medidas sejam validadas (SCHNEIDEWIND, 1993).
II.3.4 Validao de Mtricas de Software

Pesquisadores e a indstria em geral preocupam-se com a falta de validao emprica para mtricas de software, mormente para projetos e especificaes, e a ausncia de ferramentas de suporte (MUNSON, 1995, ANGER et al., 1994, SCHNEIDEWIND, 1992, INCE, 1990).
30
Na opinio de GRADY (1992), mtricas que no estejam mensuradas e provadas no deveriam ser aceitas como engenharia de software, devendo haver uma anlise rigorosa que as validasse. O propsito da validao identificar mtricas de produto e processo, que possam predizer fatores de qualidade especificados, que sejam representaes quantitativas de requisitos de qualidade. As mtricas devem indicar, acuradamente, se os requisitos de qualidade foram alcanados ou se, provavelmente, o sero (SCHNEIDEWIND, 1993). Segundo a teoria das medidas, pode-se eleger dois nveis de validao: interna e externa. Uma medida de software internamente vlida, se fornece uma caracterizao numrica de algum atributo intuitivamente entendido, e que no seja dependente do ambiente. Em todos os casos, deve-se saber em que aspecto, o produto (ou processo) de uma dada medida, foi definido e se h um modelo formal para tal definio (garantindo a no ambigidade). Uma medida de software externamente vlida, se pode ser vista como sendo um importante componente ou preditor de qualquer atributo de software de interesse, isto , de um atributo dependente de um ou mais aspectos do ambiente, mesmo que no possa ser diretamente mensurvel (FENTON, 1990). Para decidir se uma medio vlida, necessita-se assegurar a (KITCHENHAM et al., 1995): validade do atributo: investiga-se se o atributo de interesse exibido pela entidade, que se est medindo, considerando-se medidas diretas ou indiretas. validade da unidade: averigua-se se a unidade de medio usada, tem um significado condizente com a medio do atributo; validade do instrumento: certifica-se a validade do modelo de medio, e se o instrumento de medio est calibrado apropriadamente; validade do protocolo: verifica-se se o protocolo de medio adotado aceitvel. Uma mtrica de software, para ser considerada vlida, deve demonstrar um alto grau de correlao (KHOSHGOFTAAR et al., 1996) com os fatores de qualidade que representa. Uma mtrica pode ser vlida com relao a certos critrios de validade e invlida com relao a outros critrios, como os que seguem, para produtos ou processos (SCHNEIDEWIND, 1993):
31
correlao: a variao dos valores de um fator de qualidade deve estar em um intervalo especificado; rastreabilidade: a alterao do valor de um fator de qualidade deve ser acompanhada por uma alterao correspondente no valor de uma mtrica; consistncia: se h uma ordenao de valores dos fatores de qualidade, ento os valores das mtricas correspondentes devem ter a mesma ordenao; prognosticao: se a mtrica usada para predizer um fator de qualidade, seu prognstico deve ter uma acurcia especfica; fora discriminativa: uma mtrica deve ser capaz de discriminar produtos ou processos de alta ou baixa qualidade; confiabilidade: uma mtrica deve demonstrar as propriedades da correlao, rastreabilidade, consistncia, prognosticao e fora discriminativa, descritas acima, para uma percentagem especificada de suas aplicaes. As mtricas de qualidade de software so dotadas de potencial para auxiliar na garantia da qualidade de grandes projetos. A validao dessas mtricas tem o propsito de controlar e avaliar a qualidade de software, durante o projeto (SCHNEIDEWIND, 1993).
II.4 Tcnicas para Controle da Qualidade

O controle da qualidade o conjunto planejado e sistematizado de todas as aes necessrias, para produzir a confiana suficiente de que o componente ou produto esto em conformidade com os requisitos tcnicos estabelecidos (ANSI, 1993). O planejamento do controle da qualidade envolve a identificao de caractersticas de qualidade do produto, o levantamento do grau de importncia de cada uma dessas caractersticas, para que as necessidades do usurio sejam satisfeitas, e a identificao do relacionamento entre essas caractersticas. Para que o controle da qualidade tenha sucesso, so necessrios alguns procedimentos (WEINGBERG, 1993, CARD et al., 1990): construir um banco de dados comum, que armazene os resultados das avaliaes realizadas, formando assim, um histrico para possveis comparaes e referncias;
32
proporcionar um conjunto bsico de ferramentas para facilitar as atividades de coleta de dados; definir um conjunto de requisitos, documentando os conceitos de qualidade para o projeto em desenvolvimento, no contexto da organizao; elaborar um sistema consistente de revises. As revises so uma importante tcnica de controle, para a garantia da qualidade de um produto, evitando que engenheiros de software gastem tempo e recursos, projetando e construindo um produto errado. As revises podem identificar defeitos e promover sua reparao a baixo custo, desde as primeiras fases do processo de desenvolvimento (WEINGBERG, 1993). A seguir, so apresentadas algumas tcnicas de controle de qualidade.
II.4.1 Walkthrough e Inspees

O walkthrough uma reviso minuciosa de um produto feita por uma equipe, com o objetivo de melhorar a qualidade desse produto, atravs de refinamentos sucessivos. um processo pouco formal, envolvendo atividades de planejamento, preparao e uma reunio, onde participam de trs a cinco pessoas, com durao em torno de duas horas. O planejamento envolve a marcao da reunio e a seleo dos participantes. Todo o material a ser avaliado distribudo previamente para os avaliadores, que faro suas observaes dos problemas detectados (YOURDON, 1989, PAGE-JONES, 1988, FREEDMAN et al., 1984). O grupo de pessoas, que se rene no walkthrough, deve ser de mesmo nvel tcnico, para a observao e a deteco de erros, no produto em questo. Conta-se com a presena de um moderador, usurios, e membros da equipe de desenvolvimento, alm de avaliadores externos ao projeto. O narrador e o secretrio so escolhidos da equipe de desenvolvedores. Para (WEINGBERG, 1993), quando ambos usurios e desenvolvedores esto presentes, o walkthrough pode ser mais efetivo, descobrindo-se e resolvendo-se omisses e mal entendidos. No trmino da reunio, os participantes decidem pela aceitao do produto sem modificaes, com modificaes parciais ou rejeitam-no. Sempre que houver qualquer correo no produto, este ser submetido a um novo walkthrough.
33
Assemelhando-se ao walkthrough, tem-se a tcnica de inspeo (FAGAN, 1976), embora seja mais formal por estar embasada em critrios para avaliao de caractersticas de qualidade, definidos previamente. As inspees so parte de um processo de engenharia, isto , o produto repetidamente examinado por outros engenheiros, para descobrirem erros ou defeitos remanescentes no projeto (VOTTA et al. 1993). As inspees suportam a anlise de dados, durante o ciclo de desenvolvimento de um produto de software (KIRKHAM, 1996), desempenhando um importante papel na reduo de falhas estruturais no esperadas (IBRAHIM, 1992). A inspeo um procedimento de reviso estruturado, cobrindo, por vez, uma pequena poro do produto, por uma equipe de revisores, que varia de quatro a seis participantes (MASHAYEKHI, 1993, FAGAN, 1986). Pode ser realizada em vrias etapas: planejamento, preparao, reunio e apresentao. Na etapa de apresentao, os desenvolvedores exibem todo o material a ser inspecionado, destacando o que deve ser analisado, em torno de trinta minutos. Os inspetores devem analisar o material de acordo com a lista de critrios definida previamente. O narrador sumariza cada seo do material, para assegurar que todos os critrios definidos foram considerados. No final da reunio, a lista de todos os critrios deve ter sido analisada, trazendo respostas consensuais a todas as questes, sendo decidido a aceitao ou no do produto, podendo haver outras inspees. YOURDON (1989) e HUMPHREY (1989) desenvolveram alguns enfoques, onde os membros da equipe, com o conhecimento tcnico requerido para detalhar a inspeo, preparam-se individualmente, assistem reunio de inspeo, e descobrem defeitos que resultam em itens de ao. Na Tcnica de Yourdon, os revisores lem o material em questo e descrevem, informalmente, defeitos e referncias. Os revisores so, tambm, encorajados a anotar aspectos positivos do material apreciado. Na Tcnica de Humphrey, cada revisor cria uma lista de defeitos e a entrega para o produtor do material antes do encontro, que relaciona os defeitos e os apresenta na reunio de inspeo. H, tambm, uma reunio introdutria opcional, durante a qual os participantes revisam os materiais anteriores e os critrios da inspeo.
34
As reunies so consideradas como um ponto central nas inspees. VOTTA et al. (1993) cita algumas razes importantes para as reunies de inspeo, dispostas em ordem decrescente de freqncia: i. Sinergia: a interao entre os revisores, conduz identificao de muitos defeitos durante a reunio, que no foram identificados pelos revisores individualmente, ao se prepararem para um reunio. ii. Formao: os revisores de menor experincia aprendem com os revisores de maior experincia, ao longo do processo de inspeo. iii. Prazo final de planejamento: a inspeo cria um evento planejado, para que os participantes possam trabalhar convenientemente. iv. Incentivo: os participantes da reviso publicam suas contribuies e ganham a estima de seus examinadores e, portanto, esforam-se por melhorar a si mesmos. v. Requisitos: o documento do processo de inspeo especifica que a reunio deve trazer coletados os comentrios dos revisores. KNIGHT et al. (1993) sugeriu a inspeo por fases, que uma tcnica mais disciplinada e rigorosa do que a inspeo comum, podendo ser avaliados todos os produtos gerados ao longo do processo de desenvolvimento. Cada fase da avaliao objetiva verificar se o produto possui uma ou mais propriedades, detectando possveis erros. As propriedades, j avaliadas, podem ser utilizadas em fases posteriores, servindo assim para assegurar a qualidade do produto. As avaliaes, em cada fase, podem ser feitas por inspetores individuais ou mltiplos inspetores. Com inspetores individuais, a avaliao parcial mais minuciosa, sendo controlada por uma lista de questes a serem respondidas pelo avaliador. Com mltiplos inspetores, a avaliao parcial executada para a anlise de questes subjetivas, com o objetivo de obter um consenso entre os avaliadores. As inspees tm um custo relevante e obrigam que os seus participantes se desloquem para o local da reunio. Esses custos poderiam ser reduzidos, em ambientes de reunies distribudas e colaborativas, que eliminem a necessidade de reunies face-aface. Assim, as reunies poderiam ser feitas em ambientes geograficamente distribudos, onde os participantes se reunissem atravs de suas estaes de trabalho, e onde a verso corrente de todo o material fosse acessvel via on-line (MASHAYEKHI et al., 1993).
35
II.4.2 Testes de Software

Os teste so, tambm, tcnicas de controle de qualidade, que avaliam diretamente o produto, que est sendo construdo, atuando, basicamente, na identificao e remoo de erros, e devem ser conduzidos de forma sistemtica, para que sejam bem sucedidos (PRESSMAN, 1992). Consoante LEVENDEL (1990), as mudanas no produto de software so, provavelmente, as atividades com maior tendncia a erros, pois enquanto se remove um erro, outros podem ser introduzidos. O problema se amplia, porque o processo de correo de erros (GALE et al., 1990) altamente propenso a defeitos, os testes so caros, e a demora na liberao do produto pode impactar em sua rentabilidade. Uma das atividades principais em testes de software o projeto e a avaliao de casos de teste, onde se utilizam tcnicas, mtodos e critrios, teoricamente embasados, que sistematizam essa atividade. Em geral, as tcnicas podem ser classificadas em: funcional, estrutural, baseada em erros ou uma combinao delas (VILLAS et al., 1995). A tcnica funcional orienta a seleo dos casos de testes, baseada na especificao do software. Essa tcnica, no entanto, no garante que todos os requisitos do programa foram satisfeitos. A tcnica estrutural apoia-se na implementao, principalmente no fluxo de controle de dados (MALDONADO et al., 1995, SRI, 1994, DELAMARO, 1993, CHAIM, 1991). A tcnica baseada em erros emprega informaes de erros padres cometidos, no processo de desenvolvimento de software, para derivar requisitos de teste. COWARD (1988) sugere, tambm, a tcnica no funcional, que usada para identificar se o software atende s obrigaes legais, possui um desempenho em conformidade com o que foi especificado e se foi codificado segundo normas e padres estabelecidos. Tradicionalmente, os defeitos so tidos como inevitveis, usando-se tcnicas de remoo de defeitos, como parte integrante do processo de desenvolvimento. No entanto, reconhece-se que a remoo de defeitos uma atividade ineficiente e propensa a erros, consumindo recursos, que poderiam ser alocados na elaborao correta do cdigo
36
fonte desde o princpio. Com este intuito, foi criado o mtodo cleanroom (LINGER, 1994).
II.4.3 Mtodo Cleanroom

O mtodo cleanroom tem demonstrado que pode melhorar tanto a produtividade de desenvolvedores, que o utilizam, quanto a qualidade do software que estes produzem. A engenharia de software cleanroom um processo orientado equipe, que torna o desenvolvimento gerencivel e preditvel, porque feito sob o controle estatstico da qualidade (LINGER, 1994). O processo cleanroom baseado no desenvolvimento e na certificao de um fluxo incremental de informaes de software, elaborado por pequenas equipes independentes. Nesse processo, a correo obtida pela equipe de desenvolvimento (geralmente prxima de zero defeitos), atravs de especificao, projeto e verificao formais. A equipe de verificao da correo substitui os teste de unidade e a conseqente depurao, passando o software diretamente para a fase de testes do sistema, sem que seja executado previamente pela equipe de desenvolvimento.
II.4.4 Modelos de Confiabilidade

Modelos estatsticos vm sendo usados amplamente nas indstrias manufatureiras, como uma tcnica de controle de qualidade. Os modelos estatsticos, para o clculo da confiabilidade do hardware, baseiam-se no envelhecimento de seus componentes e, para a confiabilidade do software, apoia-se em seu perfil operacional (DYER, 1992). Segundo MUSA et al., (1987), um modelo de confiabilidade de software, geralmente, tem a forma de um processo aleatrio, descrevendo o comportamento de falhas no tempo. Esses modelos so usados para caracterizar e predizer possveis comportamentos de um produto de software. Os modelos de confiabilidade de software conhecidos podem ser classificados em (ASANOME, 1995): Modelos de confiabilidade baseados em injeo de falhas: utilizado nas fases de teste de depurao, requerendo que faltas sejam introduzidas num determinado programa ou mdulo, assumindo-se que a distribuio das mesmas igual a das faltas intrnsecas do programa ou mdulo.
37
Modelos baseados no domnio do tempo: faz algumas suposies bsicas como: (i) o tempo entre falhas independente, (ii) os testes so representativos do perfil operacional utilizado, (iii) novas faltas ou falhas no so introduzidas durante a correo do programa, (iv) faltas achadas durante os teste so corrigidas logo que encontradas. Modelos baseados no domnio da entrada de dados: calculam a probabilidade de um software falhar, obtida ao execut-lo com muitos casos de testes selecionados atravs de amostras do domnio de entradas do software. Modelos baseados no domnio de cobertura: concebem testes funcionais sem considerar o perfil operacional, sendo que a taxa de deteco de faltas alcanada atravs das faltas remanescentes e da cobertura obtida. Notoriamente, para se obter uma qualidade consistente de software, necessita-se controlar os processos de produtos e servios, atravs de tcnicas para este fim. No entanto, no se pode controlar acuradamente um processo, sem que haja informaes confiveis. Para que isto seja possvel, deve-se investir na gesto da qualidade, onde se define, planeja e controla todas as aes a serem desenvolvidas, para manter a qualidade do produto (ARTHUR, 1993).
II.5 A Gesto da Qualidade de Software

Entre outras atividades, a gerncia da qualidade dissemina na organizao uma cultura voltada para a qualidade, evidenciando a sua relevncia (SEFCIK, 1994, JACK, 1993, GARVIN, 1988). Alm disso, a gerncia controla todos os procedimentos, garantindo a qualidade atravs de auditoria e da certificao do produto. O gerenciamento da qualidade envolve os seguintes aspectos (CROSBY, 1990, BERGAMO, 1991): a gerncia entende a funo de qualidade; a qualidade definida em conformidade com os requisitos; a qualidade conseguida atravs de preveno; os custos da qualidade esto implantados e so gerenciados; existe um sistema formal da qualidade; o processo o principal enfoque.
38
Muitas falhas, no gerenciamento da engenharia de software, so derivadas de deficincias na observao, pois, em qualidade, nada to pequeno que no merea ser observado (WEINGBERG, 1993). DEMING (1986) notou que indivduos, que no conseguem visualizar em que trabalham, certamente tero dificuldades em dar uma real contribuio qualidade. A motivao para a melhoria da qualidade sempre comea com o estudo do valor da qualidade (CROSBY, 1990), embora muitos gerentes confundam, conceitualmente, custo e valor. DeMARCO (1987) afirma que o esforo move o que contado. A contagem do custo leva reduo do custo; a contagem do valor conduz a um aumento do valor. Questes relacionadas ao custo so limitadas pelo oramento da organizao; o incremento do valor de um produto no tem limites. Neste contexto, tem-se utilizado vrias tcnicas de benchmarking (GILB, 1996, DARKIN, 1996), para que seja alcanado um desempenho superior em reas crticas de trabalho, auxiliando no aprendizado de inovaes e melhorando as prticas j existentes (DALE et al., 1992). A qualidade deve ser perseguida dentro da organizao, pois, com certeza, isto o que os usurios esperam de um produto. Neste contexto, para que a gesto da qualidade seja eficaz e efetiva, necessria a instalao de um programa de qualidade, dentro da organizao. No entanto, a implementao desse programa de qualidade requer, sobretudo, vontade poltica de seus dirigentes e, para que isto acontea, necessrio que estes estejam despertados para este propsito.
II.5.1 A Instalao de um Programa de Qualidade

Na instalao de um programa de qualidade, necessrio que se estabelea uma anistia geral, ou seja, o que aconteceu at aquele momento, no culpa de ningum. A principal meta enfrentar os problemas existentes, em benefcio de todos. Contudo, os seguintes aspectos devem ser contnua e dinamicamente avaliados e melhorados: a estratgia geral da empresa, o planejamento, e os meios disponveis com vistas ao estabelecimento de condies favorveis, para se alcanar os objetivos almejados. Um programa de melhoria da qualidade leva ao estabelecimento de um sistema de qualidade, que deve envolver aspectos tcnicos e culturais, que so igualmente importantes. O aspecto tcnico envolve o desenvolvimento de padres e procedimentos
39
para implementar a qualidade em todas as atividades. O aspecto cultural est diretamente relacionado com a aceitao da qualidade por todos os indivduos da organizao. Para se iniciar um programa de qualidade pode-se seguir as seguintes etapas (SANDERS et al., 1994): Prepararo de uma poltica de qualidade: a iniciativa da elaborao de um programa de qualidade deve advir do topo da gerncia, formulando uma poltica de qualidade, a ser publicada e comunicada de tal forma que seja entendida e implementada em todos os nveis da organizao. Estabelecimento de um suporte qualidade: criao de um comit de conduo da qualidade e uma equipe de melhoria da qualidade. O comit direciona as estratgias, estabelece a equipe de melhoria da qualidade, autoriza e aprova o oramento, e fornece suporte de alto nvel para o programa de qualidade. A equipe de melhoria da qualidade estima as necessidades da organizao, e projeta, planeja e monitora o sistema de qualidade. Ainda segundo o mesmo autor, o planejamento de um programa de qualidade tem as seguintes etapas: Estimativa da organizao: medio da prtica corrente, atravs de um padro apropriado, onde a organizao seleciona o ndice que melhor lhe satisfaa. Projeto do sistema de qualidade: os resultados da estimativa da organizao so analisados, os objetivos de seu sistema de qualidade so definidos e, ento, a equipe de melhoria da qualidade projeta-o, gerando a primeira verso do manual de qualidade. Plano de implementao do programa de qualidade: com a primeira verso do manual de qualidade, a equipe de melhoria da qualidade pode determinar o montante de trabalho necessrio para a implementao do sistema de qualidade e, convenientemente, elaborar cronogramas e atividades, estabelecer marcos e alocar recursos para este fim. Implementao de um programa cultural: para um programa de qualidade ter sucesso necessrio o suporte de toda a organizao e, para isto, um programa cultural deve ser cuidadosamente planejado e implementado desde cedo, para a formao de conscincias voltadas para a qualidade, e encorajar a participao de todos.
40
Implementao do programa tcnico: envolve (i) adoo de um ciclo de vida, (ii) desenvolvimento de procedimentos e padres, (iii) seleo e implementao de mtodos e ferramentas, (iv) definio e implementao de um programa de medio, e (v) treinamento. Reviso e avaliao: componentes do sistema de qualidade, procedimentos e padres, mtodos, ferramentas e recursos devem ser revistos regularmente e devem ser tomadas aes para assegurar sua contnua efetividade. Um plano de qualidade, como o descrito pela ISO 9000-3 (ISO, 1990), auxilia as organizaes a medir e controlar a qualidade de seus produtos de software e, para isto, deve-se considerar quatro fatores crticos (SEFCIK, 1994): Ambiente de desenvolvimento: deve facilmente incorporar mudanas, onde novas ferramentas e novos procedimentos possam ser implementados para a coleta de mtricas, documentao adicional e revises. Cronograma: deve ajustar o tempo, para a melhoria de novos processos. Utilidade: uso de anlises custo/benefcio, no gerenciamento de processos. Organizao: deve dar suporte s necessidades de melhoria de processos dos produtos de software em desenvolvimento. As organizaes, buscando a melhoria de seus processos e produtos, que tm investido em mtricas, tomam decises mais fundamentadas e em tempo hbil, e esto obtendo maior vantagem competitiva sobre outras que no o fazem (GRADY, 1992). Mas, para que este investimento seja profcuo, necessria, tambm, a criao de um programa de mtricas de qualidade na organizao, cujos benefcios se estendero no somente s aplicaes existentes, mas tambm a projetos futuros.
II.5.2. Programa de Mtricas

Quando se decide implementar um programa de mtricas de qualidade, o passo seguinte como faz-lo. A maneira como um programa de mtricas desenvolvido pode determinar seu sucesso ou fracasso. Inicialmente, deve-se investigar as ferramentas disponveis e adquirir novas ferramentas, se for o caso, para que a coleta de dados de mtricas seja feita de forma automatizada, preferencialmente. A coleta de dados deve ser monitorada, para que no se incorra na tentativa de colher dados em demasia,
41
dificultando o seu uso, e tornando a prpria coleta dispendiosa (ROSENBERG et al., 1996). Os dados obtidos atravs de um programa de mtricas so teis para: (i) estabelecer objetivos, (ii) melhorar a qualidade, (iii) aumentar a produtividade, (iv) planejar, gerenciar e monitorar projetos, e (v) aumentar a confiana do usurio. Um programa de mtricas dever viabilizar estimativas, o monitoramento e a identificao de aes de melhoria, para que os objetivos de qualidade e produtividade da organizao sejam alcanados. No entanto, muitas organizaes no aceitam de imediato os conceitos para a implementao de um programa de mtricas, porque (MLLER, 1993): consideram que as mtricas podem restringir o processo criativo; geram trabalho adicional; os benefcios a serem alcanados no so bem elucidados; existem receios de que seja um meio para medir a prpria organizao; h dificuldades em admitir que a melhoria necessria. H dois grandes componentes de um programa de mtricas de qualidade: medida da satisfao do usurio e medida de defeitos. Por razes sociolgicas, os programas de mtricas so geralmente estabelecidos em seqncia, como uma tentativa de medir todos os fatores simultaneamente. A seqncia de medio abaixo tem sido utilizada com sucesso (JONES, 1991): i. Medidas operacionais: envolvem principalmente as medidas de uso do computador, tempo ocioso de mquina e tempo de resposta. ii. Medidas do projeto atual: acompanham o projeto em desenvolvimento. iii. Medidas de biblioteca: referem-se produo de relatrios de ocorrncia. iv. Medidas da satisfao do usurio: reportam-se a entrevistas com os usurios. v. Medidas do projeto completo: medem o projeto final. vi. Medidas de fatores imprecisos: referem-se a dados sem alto grau de preciso. vii.Medidas de defeitos: mensuram os defeitos do software. viii. Medidas demogrficas: arrolam os recursos humanos, enquadrando-os em classes de habilidades relevantes para a organizao.
42
A organizao precisa certificar-se das vantagens geradas pela instalao e manuteno de um programa de qualidade, e de um programa de mtricas de qualidade. essencial, portanto, que ela saiba o quanto custa melhorar e manter a qualidade desejada de seus produtos e servios. Alm disso, importante, tambm, que estejam bem identificadas todas as reas, que devam ser atacadas neste processo, para que os custos sejam reduzidos.
II.5.3 Custos com a Qualidade

Um agente fomentador da poltica de qualidade o reconhecimento de que os desenvolvedores tm alcanado um incremento considervel na produtividade e conseqente reduo de custos de seus produtos (ACKERMAN et al., 1989). JURAN et al. (1988) descreve o custo da medio da qualidade como uma forma de quantificar o tamanho do problema da qualidade em uma linguagem, que ter impacto na administrao superior. Os custos com a qualidade dividem-se nas seguintes categorias, de acordo com (BERGAMO, 1991, MANDEVILLE, 1990): custos de preveno: relacionam-se, diretamente, com as equipes de desenvolvimento, implementao e manuteno do sistema de qualidade, incluindo, tambm, os custos das aes preventivas, efetuadas durante o processo produtivo; custos de avaliao: associados s atividades de controle, avaliao ou auditoria de produtos ou servios, para assegurarem se esto em conformidade com as especificaes ou so adequados ao uso; custos de falhas internas: ligados aos custos com produtos ou com servios, que no esto em conformidade com as especificaes, ou no so adequados ao uso, assim como os custos de anlise de falhas; custos de falhas externas: gerados por produtos, que no atendem s especificaes da qualidade, aps sua entrega ao usurio. O custo da correo de defeitos de produtos de software cresce quase que em ordem geomtrica, quando se percorre de forma ascendente as etapas de seu ciclo de vida (SANDERS et al., 1994, MLLER, 1993, PRESSMAN, 1992, BOEHM, 1987). Na
43
tentativa de alcanar produtos de alto valor qualitativo e a um custo aceitvel, entre outras alternativas, surgiu o gerenciamento da qualidade total (Total Quality Management - TQM) (DEMING, 1989).
II.5.4 Gerenciamento da Qualidade Total

O TQM pode ser compreendido como um conjunto de princpios e mtodos, que visam a mobilizao e a cooperao de todos os participantes de uma organizao (FIORINI, 1995), para melhorar a qualidade de seus produtos e servios, suas atividade e seus objetivos, para obter a satisfao dos usurios e um incremento do bem estar de seus membros (XAVIER, 1992), a um custo compatvel. Isto exige um gerenciamento de liderana e um esforo de todos os membros da instituio, apoiado por uma cultura direcionada para a qualidade (SOARES et al., 1994). O TQM possui trs componentes chaves: o planejamento, a soluo do problema e o gerenciamento do processo. A qualidade comea com a definio dos requisitos dos usurios e tem seu pice na satisfao desses usurios (ARTHUR, 1993). O planejamento da qualidade deve ser conduzido pela alta gerncia da organizao: na conduo de esforos de melhorias da qualidade; no estabelecimento de uma poltica de qualidade e produtividade de software; na criao de estruturas de apoio (reconhecimento, recompensa, treinamento, entre outras), requeridas para alcanar os objetivos de qualidade. A soluo do problema dever ser obtida atravs de uma equipe, que busque a satisfao do usurio, eliminando razes das causas dos problemas como, por exemplo, a falta de correo de requisitos ou a dificuldade de interpretar especificaes. O gerenciamento do processo envolve muitas atividades repetitivas ao longo do desenvolvimento do produto de software, possuindo requisitos prprios, que sero medidos convenientemente, para assegurar a qualidade. MILLET et al. (1993) relata alguns princpios da qualidade total aplicados rea de informtica: (i) a satisfao total do cliente, (ii) a gerncia participativa, (iii) a delegao de poderes, (iv) o desenvolvimento de recursos humanos, (v) a constncia de propsitos, (vi) a gerncia de processos, e (vii) o aperfeioamento contnuo.
44
Muitos gerentes, apesar de seus mritos pessoais e tcnicos, no utilizam todo o potencial, que a informtica lhes pode oferecer, nem dispem das habilidades administrativas necessrias, para gerirem adequadamente os recursos humanos de que dispem. Alm destes agravantes, no possuem uma viso gerencial macroscpica dos processos organizacionais da empresa, seja por falta de iniciativa prpria, pelas dificuldades internas de obter tais informaes, ou at pela ausncia desses dados (BELCHIOR, 1995a).
II.5.5 Recursos Humanos

Administrar recursos humanos talvez se tenha tornado o desafio mais importante e mais difcil de vencer dos prximos dez ou quinze anos, pelo menos entre os pases em desenvolvimento (DRUCKER, 1990). Empresrios e pesquisadores das reas de gesto da qualidade, produtividade e do comportamento organizacional afirmam que a filosofia de administrao das empresas, que almejam o sucesso, deve estar direcionada para o princpio da valorizao do ser humano, como razo maior de sua existncia, e como agente motivador de seu contnuo crescimento (PFEFFER, 1994, ISHIKAWA, 1993). Portanto, tem-se buscado a qualidade de vida no trabalho como uma estratgia na administrao de recursos humanos, promovendo a harmonizao do indivduo com o ambiente de trabalho e sua realizao pessoal e profissional (ALMEIDA et al., 1995). COELHO (1997) prope que os aspectos sociais, que permeiam a cultura da empresa, sejam analisados periodicamente (LVY, 1993), a fim de assegurar a seus funcionrios a qualidade de vida no trabalho e o sucesso na implantao do software. Isto porque o padro comportamental do empregado influencia, significativamente, na produtividade da organizao e na qualidade dos produtos ou servios gerados. Portanto, a tendncia dos programas de melhoria da qualidade e produtividade em empresas no investir somente em processos e tecnologia de software, mas dar relevo ao treinamento melhorado e sistemtico de seus recursos humanos (HEFLEY et al., 1995, HAMMER, 1990, DAVENPORT et al., 1990). Na rea de software, o treinamento uma atividade primordial devido rpida evoluo de seus produtos e a seus ciclos de tecnologia, relativamente curtos (WEBER et al., 1997).
45
II.6 Concluso
No desenvolvimento de produtos de software, muitas decises importantes ainda dependem de julgamentos subjetivos. Faltam modelos matemticos do comportamento do produto e no se tem dados disponveis sobre experincias passadas. Se os julgamentos subjetivos fossem reforados com anlises cientficas poder-seia aumentar a confiabilidade do software (STRIGINI, 1996) e, conseqentemente, garantir a qualidade do produto. No captulo seguinte, apresentar-se- alguns enfoques sobre a teoria fuzzy, na tentativa de fornecer um suporte matemtico subjetividade das estimativas, realizadas na avaliao da qualidade de um produto de software.
46
Captulo III
ENFOQUES SOBRE A TEORIA FUZZY
A teoria dos conjuntos fuzzy (nebulosos) usada para representar modelos de raciocnio impreciso, que possuem um papel essencial na notvel habilidade humana de tomar decises racionais, em ambientes de incertezas e imprecises (ZADEH, 1988). A principal motivao da teoria dos conjuntos fuzzy o desejo de construir uma estrutura formal quantitativa, capaz de capturar as imprecises do conhecimento humano, isto , como esse conhecimento formulado na linguagem natural. Essa teoria visa ser a ponte, que une modelos matemticos tradicionais, precisos, de sistemas fsicos, e a representao mental, geralmente imprecisa, desses sistemas (DUBOIS, 1991). A mente humana opera com conceitos subjetivos tais como alto, baixo, velho e novo, que so incorporados em classes de objetos na teoria fuzzy, onde a pertinncia ou no de um elemento a um conjunto d-se de forma gradual e no abrupta (ZADEH, 1990). Com o advento dessa teoria, obteve-se substanciais instrumentos, para a representao de vrias facetas cognitivas humanas (YAGER, 1991). Ela prov ferramentas robustas para a aplicao do conhecimento, da experincia e do pensamento humano em muitos sistemas industriais, de trfego, cincia mdica, entre outros (SUZUKI, 1993). GILES (1988) levanta dois enfoques, igualmente importantes, para a formulao da teoria dos conjuntos fuzzy: o axiomtico e o semntico. No axiomtico, uma funo numrica usada para modelar o conjunto fuzzy, fornecendo uma interpretao consistente para o mesmo, embora no evidencie, diretamente, a estrutura sob esse conjunto (FRENCH, 1989, FRENCH, 1986). Para a adoo de certas definies de operaes de conjuntos fuzzy, condio necessria e suficiente que essas definies
46
Captulo III Enfoques sobre a Teoria Fuzzy ___________________________________________________________________________
sejam avaliadas por vrios pesquisadores (BELLMANN et al., 1973) e que se utilizem do enfoque axiomtico. No enfoque semntico, analisado, empiricamente, o significado fsico dos conceitos do sistema envolvido, modelando-os atravs de conjuntos fuzzy. Esses conceitos so precisamente formulados como axiomas quantitativos, produzindo no somente uma teoria consistente, mas, tambm, uma interpretao especfica dos mesmos. Esse enfoque pode, ainda, ser dividido em mtodos normativos e descritivos (FRENCH, 1986). O mtodo normativo conjectura como as pessoas poderiam organizar seus julgamentos em uma situao particular, atravs de conjuntos fuzzy. O descritivo (mais usado) investiga como de fato as pessoas realizam seus julgamentos (SDORRA et al., 1993). Ambos os enfoques, axiomtico e semntico, tm sido reportados na literatura atual em medidas de funes fuzzy ou simplesmente funes de pertinncia. Enfoques hbridos tm sido mencionados, onde mtodos experimentais foram usados em conjuno com os formais, testando e validando suas hipteses e conseqncias (TURKSEN, 1991). A seguir, sero abordados alguns conceitos da teoria dos conjuntos fuzzy, que daro suporte ao propsito deste trabalho, isto , a aplicao dessa teoria na avaliao da qualidade de software.
III.1 Conceitos Bsicos de Conjuntos Fuzzy

Um conjunto ntido (ou ordinrio) definido como uma coleo de elementos x X, onde X o conjunto universo. Cada elemento pode pertencer ou no a um conjunto A, onde A X. Em um conjunto fuzzy, representado por em X, cada elemento x pode ter um grau de pertinncia, usualmente no intervalo real [0, 1], em decorrncia de sua funo de pertinncia caracterstica. Portanto, cada funo de pertinncia mapeia elementos de um dado conjunto universo X, que sempre um conjunto ntido, para um nmero real em [0, 1]. Em casos limites, se o grau de pertinncia 0, o elemento no pertence ao conjunto e, se 1, o elemento pertence 100% ao conjunto (TURKSEN, 1991, ZIMMERMANN, 1991).
47
Qualquer representao adequada de um conjunto fuzzy envolve o entendimento bsico de cinco smbolos conceituais diferentes, relacionados entre si (TURKSEN, 1991):
Conjunto de elementos : por exemplo, item em estoque.
Varivel lingstica V: rtulo para um atributo dos elementos , como o
nvel de estoque de uma empresa.

Termo lingstico T: referente a uma varivel lingstica, correspondendo a um
adjetivo ou a um advrbio, como estoque baixo, relacionado com possveis nveis de estoque de uma empresa.
Conjunto referencial X [-, ]: um atributo particular de V, num conjunto de
elementos , como, por exemplo, [250, 750] unidades para nvel de estoque.
Grau de pertinncia (): valor de pertinncia de um elemento em relao ao
conjunto de elementos, rotulado por uma varivel lingstica V, e identificado pelo termo lingstico T. Por exemplo, seja o valor de pertinncia dado por um gerente a estoque, atravs do adjetivo baixo, envolvendo os nveis de estoque sob seu gerenciamento. Os conceitos bsicos de conjuntos fuzzy, apresentados a seguir, esto baseados em (KLIR et al., 1995a, ZIMMERMANN, 1991, FUHRMANN, 1990, KLIR et al., 1988, DUBOIS, 1980, ZADEH, 1965). Funo de pertinncia A funo de pertinncia o componente crucial de um conjunto fuzzy, e muitas operaes so definidas em conformidade com ela (ZADEH, 1965). Muitas vezes, a estimao da funo de pertinncia (x), em situaes do mundo real, vem de informaes imprecisas e incompletas. Dado um conjunto fuzzy , duas notaes so comumente empregadas, para caracterizar essas funes: (x) : X [0, 1] ou : X [0, 1]
48
De acordo com a primeira notao, o identificador do conjunto fuzzy distinguido do smbolo de sua funo de pertinncia (x). Na segunda, esta distino no feita. No entanto, no h ambigidades nos resultados desta dupla utilizao, pois cada conjunto fuzzy completa e unicamente definido por uma funo de pertinncia particular e, conseqentemente, identificadores das funes de pertinncia podem ser tambm usados como smbolos de seus conjuntos fuzzy associados. Neste trabalho, utilizar-se- a primeira notao.
Exemplo III.1: Seja X o conjunto universo de idades, e os subconjuntos fuzzy, contidos em X, classificados como infantil, adulto, jovem, e velho, envolvendo todas as possibilidades de subconjuntos fuzzy de X, que denotado por (X), como mostra a Tabela III.1. X = {5, 10, 20, 30, 40, 50, 60, 70, 80}
IDADES 5 10 20 30 40 50 60 70 80 Infantil 0 0 0 0 0 0 0 0 0 Adulto 0 0 0,8 1 1 1 1 1 1 Jovem 1 1 0,8 0,5 0,2 0,1 0 0 0 Velho 0 0 0,1 0,2 0,4 0,6 0,8 1 1
Tabela III.1: Exemplo de conjuntos fuzzy (KLIR et al., 1988)
Representao de um conjunto fuzzy Os conjuntos fuzzy prestam-se s representaes de conceitos vagos, expressados na linguagem natural, dependendo do contexto em que so usados. Usar-se-, a seguir, a formalizao de conjuntos fuzzy com suporte finito (uma das vrias existentes na literatura). Um conjunto fuzzy denotado por um conjunto de pares ordenados, em que o primeiro elemento x X, e o segundo, (x), o grau de pertinncia ou a funo de pertinncia de x em , que mapeia X para o espao de pertinncia M. Quando M contem somente os pontos 0 e 1, no-fuzzy (ZIMMERMANN, 1991):
49
= {(x, (x)) | x X}
Exemplo III.2: O conjunto fuzzy , jovens, da Tabela III.1, pode ser descrito como: = {(5; 1), (10; 1), (20; 0,8), (30; 0,5), (40; 0,2), (50; 0,1)}
Suporte O suporte de um conjunto fuzzy , em um conjunto universo X, o conjunto ntido, que contm todos os elementos de X com graus de pertinncia diferentes de zero em . ~ O suporte de um conjunto fuzzy em X, denotado por supp() ou S(), onde P (X) contem todos os subconjuntos fuzzy possveis, obtido pela funo: ~ S: P (X) P (X) onde, S() = {x X | (x) > 0}
Exemplo III.3: O suporte do conjunto fuzzy , jovem, da Tabela III.1 o conjunto ntido S() = {5, 10, 20, 30, 40, 50}
O conjunto fuzzy infantil um conjunto vazio, no conjunto universo escolhido. Neste caso, o suporte tambm vazio, isto , sua funo de pertinncia assinala 0 a todo elemento do conjunto universo. Supremo
~ ( x) , de um conjunto fuzzy o maior grau de pertinncia O supremo, sup A xX
obtido nesse conjunto por um desses elementos, isto , sua altura, h(). O contradomnio de uma funo de pertinncia um subconjunto de nmeros reais no negativos, cujo supremo finito. Ento,
~ ( x) h() = sup A xX
Normalizao Embora uma funo de pertinncia no esteja limitada ao contradomnio [0, 1], por convenincia, isto usualmente considerado como verdade, ou seja, assume-se que um
50
conjunto fuzzy normal ou normalizado. Portanto, um conjunto fuzzy chamado

~ ( x) = 1. Se sup ~ ( x) < 1, ele passa a se denominar subnormal. normal, quando sup A A xX xX
A normalizao de um conjunto fuzzy , no vazio, efetuada por:

~ ( x) '(x) = (x) / sup A xX
Conjuntos de corte- Dado um conjunto fuzzy , definido em X, a partir do grau de pertinncia [0, 1], o conjunto de corte- (-cut) o conjunto ntido A, contendo todos os elementos de X, que possuem graus de pertinncia em maiores ou iguais do que o valor especificado em . Ento, A = {x X | (x) } O conjunto de corte- robusto (strong -cut), A', inclui apenas os elementos de graus de pertinncia maiores que . Ento, A' = {x X | (x) > } Neste caso, percebe-se que o suporte de corresponde, exatamente, ao conjunto de corte- robusto de para = 0.
Exemplo III.4: Ainda em referncia Tabela III.1, os conjuntos de corte- possveis, para o conjunto fuzzy , jovem, so: A0,1 = {5, 10, 20, 30, 40, 50} A0,2 = {5, 10, 20, 30, 40} A0,5 = {5, 10, 20, 30} A0,8 = {5, 10, 20} A1,0 = {5, 10} Neste caso, o conjunto de corte- robusto para = 0,8 A = {5, 10}.
O conjunto de todos os nveis [0, 1], que representa distintos conjuntos de corte- de um dado conjunto fuzzy , definido em X, denominado conjunto de nvel de , , dado por: = { | (x) = para todo x X}
51
A seguinte propriedade pode ser deduzida dos conjuntos de corte- e corte- robusto: Qualquer conjunto fuzzy , com 1, 2 [0, 1] e 1 2, para 1 < 2, tem-se: A1 A2 e A1 A2
Em conseqncia dessa propriedade, todos os conjuntos de corte- de um conjunto fuzzy , em X, formam uma famlia de subconjuntos ntidos, aninhados em X. Convexidade A convexidade de conjuntos fuzzy definida em R , para todo n N, como sendo
n
uma generalizao do conceito de convexidade de conjuntos ntidos. Para isto requerido que os conjuntos de corte- de um conjunto fuzzy convexo sejam convexos para todo (0, 1]. Portanto, um conjunto fuzzy convexo, se todos os seus conjuntos de corte- so convexos. De forma simplificada, trabalhando-se em
R, e para todo x1, x2 X e [0, 1],
onde min caracteriza o operador mnimo (trabalha com o menor valor em um conjunto de valores), um conjunto fuzzy convexo se: (x1 + (1 - )x2) min ((x1), (x2)) Cardinalidade A cardinalidade escalar ou, simplesmente, cardinalidade, | |, de um conjunto fuzzy , definido em X, o somatrio dos graus de pertinncia de todos os elementos de X em . Formalmente, ||=
xX
~ A
( x)
Para um conjunto universo infinito X, a cardinalidade, que nem sempre existe ( necessrio que (x) seja integrvel), dada por: | | = A ~ ( x)dx
x
A cardinalidade relativa, || ||, de um conjunto fuzzy depende da cardinalidade do conjunto universo considerado. Assim, deve-se escolher o mesmo conjunto universo X, caso se queira comparar conjuntos fuzzy atravs de sua cardinalidade relativa. Pode
52
ser interpretada como a frao dos elementos de X, presentes em , medidos por seus graus de pertinncia: || || = | | / | X |
Exemplo III.5: A cardinalidade escalar do conjunto fuzzy , velho, da Tabela III.1 : | | = 0 + 0 + 0,1 + 0,2 + 0,4 + 0,6 + 0,8 + 1 + 1 = 4,1 A cardinalidade escalar do conjunto fuzzy , infantil, 0. A cardinalidade relativa do conjunto fuzzy , velho, : || || = 4,1 / 9 = 0,456
Fuzificao A fuzificao (fuzzification) acontece, quando um conjunto fuzzy obtido pelo alargamento fuzzy de um conjunto ntido, isto , um conjunto ntido convertido em um conjunto fuzzy apropriado, para expressar medidas de incertezas.
Exemplo III.6: Seja o conjunto ntido A = {x | 7 < x < 10}, ento, pelo processo da fuzzificao, < < ter-se-ia o seguinte conjunto fuzzy = {x | 7 x 10}, onde o smbolo denominado um fuzzificador, e significa aproximadamente.
Defuzificao A defuzificao a converso de um conjunto fuzzy em um valor ntido (ou um vetor de valores) (OLIVEIRA, 1995a, SONG, 1994, FILEV, 1993, MABUCHI, 1993, YAGER et al., 1993a). Na literatura de controle fuzzy, predominam alguns mtodos de defuzificao (LEE, 1990), entre eles, o mtodo do centro de gravidade ou mtodo centride. Princpio da extenso O princpio da extenso utilizado para generalizar conceitos da matemtica clssica para a teoria fuzzy (ZADEH, 1973a, DUBOIS, 1980). Sejam X o produto cartesiano dos conjuntos universos X = X1, X2, ..., Xr e r conjuntos fuzzy 1, 2, ..., r em X1, X2, ..., Xr, respectivamente. Se f um mapeamento de X para um conjunto universo Y, y = f(x1, x2, ..., xr), ento, pelo princpio da extenso, pode-se definir um conjunto ~ fuzzy B em Y, onde f -1 a funo inversa de f.
53
~ ~ (x)) | y = f(x , x , ..., x ), (x , x , ..., x ) X} B = {(y, B 1 2 r 1 2 r onde

1 min{ A sup ( y) ~ ( x1 ), ~ ( x2 ), ..., ~ ( xr )} se f A2 Ar 1 1 ( x1 , x2 , ..., xr ) f ( y ) B ~ ( y) = outros casos 0
Para r = 1, o princpio da extenso, reduz-se a: ~ ~ (x)) | y = f(x), x X} B = f() = {(y, B onde

1 sup A xf 1 ( y ) ~ ( x ), se f ( y ) B ~ ( y) = outros casos 0
Exemplo III.7: Sejam = {(-1; 0,5), (0; 0,8), (1; 1), (2; 0,4)} e f(x) = x2 Aplicando-se o princpio da extenso, ilustrado na Figura III.1, obtm-se:
~ B = f() = {(0; 0,8), (1; 1), (4; 0,4)}
4 3 2 1 0 -1 S()
- 4 - 3 - 2 - 1 - 0 - -1
~ S( B )
Figura III.1: O Princpio da Extenso (ZIMMERMANN, 1991)
Funes fuzzy Uma funo fuzzy uma extenso do conceito de uma funo clssica f, podendo ser obtida atravs de diferentes graus de fuzificao (SASAKI, 1993, TURKSEN, 1991, ZIMMERMANN, 1991):
54
i. Mapeamento clssico de um conjunto fuzzy, que se realiza ao longo do processo de fuzificao do domnio da funo, sendo que seu contradomnio seria ntido. ii. Mapeamento fuzzy de um conjunto fuzzy, tornando seu contradomnio tambm fuzzy. Este processo conhecido como fuzzifying funes. iii. Funes ntidas podem ter propriedades fuzzy ou estarem sujeitas a restries fuzzy. Dada uma funo clssica f: X Y e um domnio fuzzy , em X, pelo princpio da ~ extenso gerada uma imagem fuzzy de B com a funo de pertinncia (DUBOIS, 1980):
B ~ ( y ) = sup ~ ( x ) A
xf
1
( y)
Em funo dos conceitos bsicos dos conjuntos fuzzy apresentados, sero mostradas algumas de suas operaes mais importantes, no contexto deste trabalho.
III.2 Operaes com Conjuntos Fuzzy

As operaes fuzzy - complemento, interseo e unio - constituem uma estrutura consistente da teoria dos conjuntos fuzzy, para a extenso de conjuntos ntidos (ZADEH, 1965). Nessas operaes padres, so utilizados os operadores min (mnimo) e max (mximo) para a interseo e a unio de conjuntos fuzzy, respectivamente. Outros operadores tm sido sugeridos (YAGER et al., 1993a, DUBOIS et al., 1982, YAGER, 1980), variando em generalidade e adaptabilidade, satisfazendo a certas propriedades, dependendo do contexto empregado.
III.2.1 Complemento Fuzzy

A funo de pertinncia padro do complemento de um conjunto fuzzy , c(x), para todo x X, definida por: c(x) = 1 - (x)
Exemplo III.8: O complemento do conjunto fuzzy , velho, da Tabela III.1, c, no-velho, que representado por:
55
Captulo III Enfoques sobre a Teoria Fuzzy ___________________________________________________________________________ c(x) = {(5; 1), (10; 1), (20; 0,9), (30; 0,8), (40; 0,6), (50; 0,4), (60; 0,2)}
~ O complemento fuzzy genrico de dois conjuntos e B pode ser denotado pela operao binria, no intervalo unitrio por: c : [0, 1] [0, 1] [0, 1] O complemento fuzzy de de tipo c, c(x), pode ser interpretado no somente como o grau de pertinncia pelo qual x pertence c, mas tambm como o grau pelo qual x no pertence ao conjunto fuzzy . Assim, (x) pode ser entendido como o grau pelo qual x no pertence c. Dado um conjunto fuzzy , obtemos c aplicando-se a funo c aos valores (x) para todo x: c(x) = c((x)) Para produzir complementos fuzzy convenientes, a funo c deve satisfazer, no mnimo, os dois axiomas seguintes (KLIR, 1995a): Axioma c1: c(0) = 1; e c(1) = 0 (condies de contorno), isto , a funo c
produz o mesmo complemento para conjuntos ntidos. Axioma c2: para todo a, b [0, 1], se a b, ento c(a) c(b) (monotonicidade).
Pode considerar, tambm, os seguintes requisitos para complemento fuzzy. Cada um deles reduz a generalizao do complemento fuzzy para subclasses especiais. Axioma c3: c uma funo contnua. Axioma c4: c involutiva, isto , c(c(x)) = x, para todo x [0, 1].
III.2.2 Interseo Fuzzy

~ ~ A interseo fuzzy padro dos conjuntos fuzzy e B o conjunto fuzzy B , para todo x X, de modo que:
A ~ ~ ( x ) = min [ (x), ~ ( x ) ] B B
Exemplo III.9: A interseo dos conjuntos fuzzy , velho, e de B , jovem,da Tabela III.1, dada por:
A ~ ~ ( x ) = {(20; 0,1), (30; 0,2), (40; 0,2), (50; 0,1)} B
56
~ A interseo fuzzy genrica de dois conjuntos e B , geralmente, especificada pela operao binria no intervalo unitrio, isto , pela funo na forma: i : [0, 1] [0, 1] [0, 1] Os argumentos para essa funo so o par constitudo pelo grau de pertinncia de ~ cada elemento x, em , e o grau de pertinncia de seu correspondente em B . A funo ~ retorna, ento, com o grau de pertinncia do elemento em B . Portanto,
A ~ ~ ( x ) = i [(x), ~ ( x ) ] B B
A funo i, para poder ser considerada como interseo fuzzy, deve satisfazer os quatro axiomas abaixo (Klir 95a]: Axioma i1: i(1, 1) = 1; i(0, 1) = i(1, 0); i(0, 0) = 0 (condies de contorno). A
funo i comporta-se como a interseo clssica de conjuntos ntidos. Axioma i2: i(a, b) = i(b, a); isto , i comutativa. Assim sendo, no importa a
ordem, na qual os conjuntos so combinados. Axioma i3: Se a a' e b b', ento, i(a, b) i(a', b') (monotonicidade). Portanto, ~ um decrscimo no grau de pertinncia de ou de B no pode produzir um ~ acrscimo no grau de pertinncia de B . Axioma i4: i(i(a, b), c) = i(a, i(b, c)) (associatividade). possvel fazer a
interseo de qualquer quantidade de conjuntos, em qualquer ordem de agrupamentos desejada. Os requisitos adicionais para interseo de conjuntos fuzzy, que so desejveis em certas aplicaes, so expressados pelos seguintes axiomas: Axioma i5: i uma funo contnua. Neste caso, um pequeno incremento no ~ grau de pertinncia de ou de B , no produzir uma variao substancial no grau ~ de pertinncia de B . Axioma i6: i(a, a) = a (idempotncia). A interseo de um conjunto fuzzy
consigo mesmo produz o mesmo conjunto fuzzy.
III.2.3 Unio Fuzzy

~ ~ A unio fuzzy padro dos conjuntos e B o conjunto fuzzy B , para todo x X, formalizada por:
57
A ~ ~ ( x ) = max [ (x), ~ ( x ) ] B B
Exemplo III.10: A unio dos conjuntos fuzzy , velho, e de B , jovem, da Tabela III.1, dada por:
A ~ ~ ( x ) = {(5; 1), (10; 1), (20; 0,8), (30; 0,5), (40; 0,4), (50; 0,6), B
(60; 0,8), (70; 1), (80; 1)}
~ A unio fuzzy genrica dos conjuntos e B , de maneira semelhante interseo, representada, geralmente, pela funo: u : [0, 1] [0, 1] [0, 1] Para cada elemento x X, essa funo possui, como argumentos, o par constitudo ~ dos graus de pertinncia dos elementos de e de B , produzindo o grau de pertinncia ~ do conjunto unio B . Formalmente, temos: A ~ ~ ( x ) = u [(x), ~ ( x ) ] B B Qualquer que seja a forma da funo u, para que seja qualificada como unio fuzzy, deve atender, no mnimo, os quatro axiomas seguintes (KLIR, 1995a): Axioma u1: u(0, 0) = 0; u(0, 1) = u(1, 0); u(1, 1) = 1 (condies de contorno). A
funo u comporta-se como a unio clssica de conjuntos ntidos. Axioma u2: u(a, b) = u(b, a) (comutatividade). Portanto, a ordem, pela qual os
conjuntos so combinados, no relevante. Axioma u3: Se a a' e b b', ento, u(a, b) u(a', b') (monotonicidade). Um ~ decrscimo no grau de pertinncia de ou de B no pode produzir um incremento ~ no grau de pertinncia de B . Axioma u4: u(u(a, b), c) = u(a, u(b, c)) (associatividade). Pode-se efetuar a
unio de qualquer nmero de conjuntos e em qualquer ordem de agrupamentos desejados. Outros requisitos, igualmente importantes, para a unio de conjuntos fuzzy so mostrados abaixo: Axioma u5: u uma funo contnua.
58
Axioma u6: u(a, a) = a (idempotncia). Semelhantemente interseo, a unio
de um conjunto fuzzy consigo mesmo gera, precisamente, o mesmo conjunto. Em BELLMANN (1973), a interpretao da interseo como e lgico, e da unio como ou lgico fundamentada axiomaticamente. Entretanto, os operadores min e max no so os nicos, que podem ser escolhidos, respectivamente, para as operaes de interseo e de unio de conjuntos fuzzy. A seguir, sero mostradas algumas operaes algbricas com conjuntos fuzzy.
III.2.4 Operaes Algbricas com Conjuntos Fuzzy

As operaes algbricas so, tambm, extenses dos conceitos bsicos dos conjuntos fuzzy, envolvendo suas definies e operaes (ZIMMERMANN, 1991). Produto cartesiano Sejam os conjuntos fuzzy, 1, 2, ..., n, em X1, X2, ..., Xn. Ento, o produto cartesiano o conjunto fuzzy no espao do produto X1 X2 ... Xn, com a funo de pertinncia: (1 2 ...n)(x) = min {i(xi) | x = (x1, x2, ..., xn), xi Xi}
i
Soma algbrica ~ ~ A soma algbrica C = + B definida como ~ C = {(x, A ~ ~ ( x )) | x X} +B onde

A ~ ~ ( x ) = (x) + ~ ( x ) - (x) ~ ( x ) B B +B
Soma de contorno ~ ~ A soma de contorno C = B definida como ~ C = {(x, A ~ ~ ( x ) ) | x X} B onde A ~ ~ ( x ) = min {1, (x) + ~ ( x ) } B B Diferena de contorno
59
~ ~ A diferena de contorno C = B definida como ~ C = {(x, A ~ ~ ( x ) ) | x X} B onde

~ ~ ( x ) = max {0, (x) + ~ ( x ) - 1} A B B
Produto algbrico ~ ~ O produto algbrico de dois conjuntos fuzzy C = B definido como ~ C = {(x, (x) B ~ ( x ) ) | x X}
Exemplo III.11: Sejam os conjuntos fuzzy (x) = {(3; 0,5), (5; 1), (7; 0,6)} e
~ B (x) = {(3; 1), (5; 0,6)}

Aplicando-se as definies acima, tem-se os seguintes resultados: B = {[(3; 3); 0,5], [(5; 3); 1], [(7; 3); 0,6], [(3; 5); 0,5], [(5; 5); 0,6], [(7;5); 0,6]} = {(3; 0,25), (5; 1), (7; 0,36)} + B = {(3; 1), (5; 1), (7; 0,6)} B = {(3; 1), (5; 1), (7; 0,6)} B = {(3; 0,5), (5; 0,6)} B = {(3; 0,5), (5; 0,6)}
2
Muitas operaes com conjuntos fuzzy esto direcionadas para a agregao de suas funes de pertinncia. Esta uma questo de particular interesse em qualidade de software, isto , a agregao de informaes pertinentes a atributos de qualidade do produto ou do processo considerado.
III.3 Agregao de Conjuntos Fuzzy

A agregao um processo utilizado em muitas tecnologias (YAGER, 1994), especialmente na tomada de deciso multicriterial (ZIMMERMANN, 1997). Tm sido propostas muitas alternativas para este fim, como o processo de deduo e inferncia lgica e outros tipos de conhecimento indutivo. As redes neurais artificiais (ZOVCS, 1996, KASABOV et al., 1996, KOSKO, 1995, BUCKLEY et al., 1994, GUPTA, 1992),
60
por exemplo, esto baseadas em agregaes de taxas de sinais para cada neurnio, gerando um sinal de sada (YAGER, 1993b). A idia principal do processo de agregao obter-se um grau de consenso entre as informaes disponveis, calculando-se um valor final. Se estes dados forem extrados de especialistas, ento ter-se- a taxa de aceitao ou rejeio entre eles, isto , o grau pelo qual especialistas concordam em suas estimativas, tornando possvel a elaborao de classificaes das avaliaes realizadas (KUNCHEVA et al., 1996). DAY (1988) argumenta que os modelos de consenso so potencialmente frteis e podem ser usados em vrios domnios de aplicao. Os mtodos de consenso referemse, principalmente, a esquemas de graduao, expandindo-se para relaes de preferncia (FEDRIZZI et al., 1993, GILARDONI et al., 1993, KACPRZYK et al., 1992), decises de grupo (CARLSSON et al., 1996, GRABISH, 1995, SAKAWA et al., 1994) e estimativas lingisticamente definidas (MICH et al., 1993). O grau de consenso tem sido estimado, usando-se alguns operadores de agregao fuzzy, atravs das preferncias individuais de n especialistas, para cada atributo considerado, e gerando-se uma matriz de deciso, chamada em (KUNCHEVA, 1995) de perfil de deciso. Segundo BARDOSSY et al (1993), as seguintes propriedade podem ser desejveis, quando se utiliza funes de agregao: i. Preservao da concordncia: se todas as estimativas so idnticas, o resultado da combinao dever ser a prpria estimativa (requisito de consistncia). ii. Independncia de ordem: o resultado no deve depender da ordem com que opinies ou estimativas individuais so combinadas (requisito de consistncia). iii. Invarincia da transformao: transformaes ocorridas no ambiente, onde se processa a agregao, no devero afetar seu resultado. iv. Conservao da possibilidade: se um dado valor for considerado possvel para uma nica estimativa, ento, ele permanece possvel para toda a combinao. v. Conservao do intervalo de possibilidade: um certo valor localizado entre dois valores, considerados como estimativas possveis, tido tambm como possvel. ~ vi. Incertezas individuais versus globais: a medida de incerteza, H( Ri ), de uma ~ estimativa individual, Ri , definida como a rea sob sua funo de pertinncia:
61

~ ~ ( x ) dx H( Ri ) = R i
~ medida de incerteza global, H( R ), isto , a combinao de todas as estimativas ~ individuais, R , tambm pode ser medida analogamente. vii.Convenincia da estimativa dos resultados: combinao de vrias caractersticas de tcnicas de agregao, que so avaliadas pelos critrios expostos nos itens acima, atravs de uma escala subjetiva, variando de A (excelente) a E (pssimo). Conceitualmente, operaes de agregao fuzzy so combinaes de vrios conjuntos fuzzy (n 2), de uma forma desejvel, para produzirem um nico conjunto. Em geral, uma operao de agregao representada pela funo: h : [0, 1]n [0, 1] Quando a funo h aplicada para n conjuntos fuzzy, 1, 2, ..., n, definidos em X e operando com os graus de pertinncia de cada x X, produzido um conjunto fuzzy agregado . Assim, para cada x X: (x) = h(1(x), 2(x), ..., n(x)) Para que h seja qualificada como uma funo de agregao, deve satisfazer, no mnimo, os trs axiomas a seguir (KLIR, 1995a): Axioma h1: h(0, 0, ..., 0) = 0 e h(1, 1, ..., 1) = 1 (condies de contorno). Axioma h2: para qualquer par a1, a2, ..., an e b1, b2, ..., bn de n-tuplas tal que
ai, bi [0, 1] para todo i Nn, h monotnica incremental em todos os seus argumentos, se para ai bi , i Nn, ento, h(a1, a2, ..., an) h(b1, b2, ..., bn) Axioma h3: h uma funo contnua, isto , garante-se que uma variao
infinitesimal em qualquer argumento de h no produz mudanas considerveis na agregao. Dois axiomas adicionais so tambm empregados para operaes de agregao, embora no sejam essenciais: Axioma h4: h uma funo simtrica em todos os seus argumentos, para
qualquer permutao p em Nn, isto ,

62
h(a1, a2, ..., an) = h(ap(1), ap(2), ..., ap(n)) Axioma h5: h uma funo idempotente, para todo a [0, 1], isto : h(a, a, ..., a) = a A unio e a interseo fuzzy qualificam-se, normalmente, como operaes de agregao. Embora sejam definidas primariamente para dois argumentos, suas propriedades de associatividade, garantidas pelos axiomas i4 e u4, fornecem um mecanismo para extenso de suas definies para qualquer nmero de argumentos. Qualquer operao de agregao h que satisfaa os axiomas h2 e h5, satisfaz, tambm, todas as n-tuplas a1, a2, ..., an [0, 1]n, para as seguintes inequaes: min(a1, a2, ..., an) h(a1, a2, ..., an) max(a1, a2, ..., an) Neste caso, a operao de agregao h chamada operao de mdia. Portanto, os operadores padres max e min representam os limites entre as operaes de mdia e a unio e a intercesso fuzzy, respectivamente. YAGER (1988) desenvolveu a classe de operaes de mdia de pesos ordenados ou OWA (Ordered Weighted Averaging), que satisfazem os axiomas de h1 a h5. Dado um vetor de pesos, w, tal que wi [0, 1] para todo i Nn, ento, w = w1, w2, ..., wn, e
w
i =1
=1
Em uma operao OWA associada ao vetor w, onde bi o maior i-simo elemento em a1, a2,...,an, para qualquer i Nn, isto , b1, b2, ..., bn uma permutao do vetor a1, a2, ..., an, no qual os elementos esto ordenados: bi bj, se i < j para qualquer par i, j Nn, ento, hw(a1, a2, ..., an) = w1b1 + w2b2 + ... + wnbn
Exemplo III.12: Dado w = 0,3; 0,1; 0,2; 0,4, tem-se que hw (0,6; 0,9; 0,2; 0,7) = 0,3 0,9 + 0,1 0,7 + 0,2 0,6 + 0,4 0,2 = 0,54.
Em toda operao de agregao, os operadores fuzzy exercem uma grande influncia no resultado final. Um nmero significativo desses operadores foram
63
propostos (CHEN et al., 1992, KRISHNAPURAM et al., 1992, ZIMMERMANN, 1991, DUBOIS, 1984, DUBOIS, 1985), e a escolha apropriada dos mesmos para uma determinada situao, de grande relevncia.
64
III.3.1 Operadores Fuzzy

Embora haja muitos operadores de agregao desenvolvidos, no h enfoques semnticos para a escolha apropriada destes conectivos, para uma situao em particular, uma vez que no existem mtodos formais de anlise independentes da situao-problema (FELIX, 1994). Quando se usa a teoria fuzzy para modelar fenmenos reais, apenas justificativas puramente matemticas dos operadores no so suficientes. Alm da adequao da modelagem do problema necessrio que esta tenha sido provada empiricamente (THOLE et al., 1979). Com a variedade de operadores para a agregao de conjuntos fuzzy, pode ser difcil decidir qual deles usar para um modelo especfico ou em uma determinada situao. H alguns critrios que podem ser teis na seleo apropriada desses conectivos (ZIMMERMANN, 1991): Fora axiomtica: devem satisfazer a seus axiomas, em seus mnimos detalhes, tendo certas qualidades formais (tais como comutatividade, associatividade). Idoneidade emprica: devem modelar convenientemente o comportamento de sistemas reais, podendo ser obtidos atravs de testes empricos. Adaptabilidade: devem ser adaptveis a uma semntica ou a um contexto especfico (atravs de parametrizao, por exemplo). Eficincia numrica: requerem um certo esforo computacional, que deve ser considerado, principalmente, em problemas de grande porte. Compensao: o grau de pertinncia de um conjunto fuzzy agregado dado por: Ag(xk) = f( (xk), B ~ ( x k )) = k onde f uma funo compensatria, se Ag(xk) = k for obtida para diferentes (xk), alterando-se B ~ ( x k ). O operador-min, por exemplo, no compensatrio, enquanto que o operador-produto o . Intervalo de Compensao: em geral, quanto maior for o intervalo de
compensao, melhor o operador compensatrio.
65
Ambiente de agregao: para conjuntos fuzzy normais ou subnormais, o grau de
pertinncia do conjunto agregado depende, freqentemente, da quantidade dos conjuntos combinados e geralmente no incremental. Nvel de escala requerido das funes de pertinncia: o nvel de escala
(nominal, intervalar, taxao e absoluta) (TURKSEN, 1991), no qual as informaes de pertinncia podem ser obtidas, depende de vrios fatores. Em sees anteriores, a interseo de conjuntos fuzzy, interpretada pelo operador lgico e, foi modelada pelo operador-min, e a unio, interpretada por ou, pelo operador-max. Outros operadores tm sido sugeridos de acordo com a sua generalidade ou adaptabilidade, bem como pela justificativa emprica ou axiomtica de sua escolha. A seguir, sero investigadas as duas classes de operadores mais utilizadas, no processo de agregao: operadores para a interseo e a unio de conjuntos fuzzy, referenciados como classe padro triangular (t-norm) e classe de co-padro triangular (t-conorm). Uma outra classe, a dos operadores de mdia, modela conectivos para conjuntos fuzzy entre t-norms e t-conorms (DUBOIS, 1985, ALSINA, 1985, KLEMENT et al., 1982], possuindo operadores parametrizados ou no. III.3.1.1 Classes t-norms e t-conorms As classes t-norms englobam os operadores: min, produto e diferena de contorno. A interseo de conjuntos fuzzy (ZADEH, 1965) foi delineada pelo operador-min e o produto algbrico. A interseo-robusta (GILES, 1976) foi modelada pela diferena de contorno. As classes t-norms so funes t bivaloradas de [0, 1] [0 ,1], que satisfazem as seguintes condies (DUBOIS, 1980): i. t(0, 0) = 0; t((x), 1) = t(1, (x)) = (x), ii. t((x), B ~ ( x )) t( ~ ( x ) , ~ ( x )) C D se (x) C ~ ( x) e ~ ( x) ~ ( x) D B iii. t((x), B ~ ( x )) = t( ~ ( x ) , (x)) B iv. t((x), t( B ~ ( x ) , ~ ( x ))) = t(t((x), ~ ( x )) , ~ ( x )) C C B (monotonicidade) (comutatividade) (associatividade) xX
As classes t-conorms englobam os operadores: max, soma algbrica e soma de contorno. A unio de conjuntos fuzzy (ZADEH, 1965) foi delineada pelo operador-max e a soma algbrica. A unio-robusta (GILES, 1976) foi modelada pela soma de
66
contorno. As classes t-conorms so funes s bivaloradas de [0, 1] [0 ,1], que atendem s seguintes propriedades (DUBOIS, 1985): i. s(1, 1) = 1; s((x), 0) = s(0, (x)) = (x), ii. s((x), B ~ ( x )) s( ~ ( x ) , ~ ( x )) C D se (x) C ~ ( x) e ~ ( x) ~ ( x) D B iii. s((x), B ~ ( x )) = s( ~ ( x ) , (x)) B iv. s((x), s( B ~ ( x ) , ~ ( x ))) = s(s((x), ~ ( x )) , ~ ( x )) C C B ALSINA (1985) definiu t-conorm, s, em funo de t-norm, t: t((x), B ~ ( x )) = 1 s(1 (x), 1 ~ ( x )) B III.3.1.2 Outras classes de operadores fuzzy YAGER et al. (1993a) criou os operadores MICA (Monotonic Identify Commutative Aggregation), possuindo um elemento identidade, que pode ser adicionado ao argumento de uma agregao sem mudar o valor agregado. Neste caso, t-norm e tconorm so casos especiais desses operadores. YAGER et al. (1996) unificou e generalizou, tambm, os operadores t-norm e t-conorm, nas classes uni-norms. Um operador uni-norm R, mapeado de [0, 1] [0, 1] em [0, 1], tem as propriedades abaixo: i. R(a, b) = R(b, a) ii. R(a, b) R(c, d) se a c e b c iii. R(a, R(b, c)) = R(R(a, b), c) (comutatividade) (monotonicidade) (associatividade) (monotonicidade) (comutatividade) (associatividade) xX
iv. H elementos (identidade) e [0, 1], tal que para todo a [0,1], R(a, e) = a. Portanto, t-norm um caso especial de uni-norm com e = 1, enquanto que t-conorm um caso especial com e = 0. Existem outras formas de combinao de conjuntos fuzzy. O uso dos operadores e e ou so casos limites especiais, no processo de agregao. Foram sugeridos, ento, modelos generalizados para os operadores lgicos e e ou representados, respectivamente, por e fuzzy e ou fuzzy (WERNERS, 1984). A combinao desses operadores tem levado a resultados satisfatrios, em dados empricos, permitindo compensaes entre os graus de pertinncia dos conjuntos agregados.
67
usual, em processos de agregao, a combinao de nmeros fuzzy, representando o julgamento de um especialista para uma varivel lingstica, na avaliao de um determinado produto ou processo (HSU et al., 1996, HAPKE et al., 1994, RMER et al., 1995, BARDOSSY et al., 1993, LASEK, 1992, RUONING et al., 1992, KAUFMANN et al., 1991, GENEST, 1984).
III.4 Nmeros Fuzzy

Em um processo de avaliao de resultados, os dados obtidos dos especialistas so geralmente imprecisos e contm muitas ambigidades, principalmente, em virtude de como foram capturados. A origem dessas ambigidades pode ser (RMER et al., 1995): a no acurcia dos dispositivos utilizados, envolvendo erros de medio de natureza fuzzy (BANDEMER et al., 1990); a natureza lingstica dos dados observados; a natureza subjetiva dos dados obtidos. Muitas informaes vagas podem ser convenientemente modeladas por nmeros fuzzy (HSU et al., 1996, HAPKE et al., 1994, RUONING et al., 1992, KAUFMANN, 1991, DUBOIS, 1985. O conceito de nmeros fuzzy em incertezas fuzzy desempenha um papel semelhante ao de uma varivel aleatria, nas relaes de incertezas probabilsticas (SAADE, 1996). Um nmero fuzzy (ou um intervalo fuzzy) um conjunto fuzzy convexo e normalizado definido no conjunto dos nmeros reais
R,
tal que sua funo de
pertinncia tem a forma (ZIMMERMANN, 1991, KLIR et al., 1995a): : R [0, 1] Um nmero fuzzy deve capturar a concepo intuitiva de nmeros ou intervalos aproximados, tal como valores que esto prximos de um certo nmero real, ou valores que esto em torno de um dado intervalo de nmeros reais. Tais conceitos so essenciais para a caracterizao dos estados das variveis fuzzy e,
conseqentemente, so importantes para aplicaes tais como controle fuzzy, tomada de deciso, raciocnio aproximado e estatstica.
68
Para qualificar um nmero fuzzy, um conjunto fuzzy em
deve possuir, no
mnimo, as seguintes propriedades (KLIR et al., 1995a, YU, 1993, ZIMMERMANN, 1991): i) deve ser um conjunto fuzzy normalizado; ii) deve ser um intervalo fechado para todo (0, 1], isto , todo nmero fuzzy convexo; iii) o suporte de deve ser limitado. Casos especiais de nmeros fuzzy incluem nmeros e intervalos reais ordinrios, como mostra a Figura III.2: (a) um nmero real 3; (b) um intervalo ntido [3, 4]; (c) um nmero fuzzy dado pela proposio prximo a 3 (nmero fuzzy triangular); (d) um nmero fuzzy com uma regio plana (um intervalo fuzzy ou nmero fuzzy trapezoidal).
1
0 1 2 3 4 5
0 (b) 1 2 3 4 5
0 (c) 1 2 3 4 5
0 (d) 1 2 3 4 5
Figura III.2: Comparao de um nmero real e um intervalo ntido com um nmero fuzzy e um intervalo fuzzy respectivamente (KLIR et al., 1995a)
Embora as funes de pertinncia de nmeros fuzzy tenham, usualmente, as formas triangular ou trapezoidal, existem outras formas para represent-las, que nem sempre so simtricas, dependendo do contexto da aplicao, como funes com forma de sino, funes estritamente crescentes ou decrescentes. Dados imprecisos podem ser modelados pelo significado de nmeros fuzzy L-R (HAPKE et al., 1994, ROUBENS, 1990, NAKAMURA, 1986,), que uma outra importante forma de representao de funes de pertinncia desses nmeros (DUBOIS, 1980).
69
III.4.1 Conjuntos fuzzy tipo-LR

Um nmero fuzzy do tipo-LR, se houver as funes de referncia L (para a esquerda (left)), R (para a direita (right)), os nmeros escalares > 0 e > 0 (extenses da esquerda e da direita, respectivamente), e o nmero real m, chamado valor mdio de . Neste caso, um nmero fuzzy triangular. Simbolicamente, denotado por (m, , )LR (ZIMMERMANN, 1991, DUBOIS et al., 1980):
m x para x m L N ~ ( x) = x m R para x m
Baseando-se em (LEE, 1996a, HSU, 1996, KAUFMANN, 1991), um nmero fuzzy triangular normal do tipo-LR pode ser representado por, = (a; m; b), onde a = m - | | e b = m + | |. Se m no um nmero real, mas um intervalo [m, m ], o nmero fuzzy se transforma em um intervalo fuzzy (nmero fuzzy trapezoidal). Um intervalo fuzzy do
2 tipo-LR, se houver funes na forma L e R e, tambm, os parmetros (m, m ) R {-
, +}, a, b. O intervalo fuzzy denotado, ento, por = (m, m , a, b)LR (DUBOIS et al. 1988):
m x para x m L N para m x m ~ ( x ) = 1 xm R para x m Um intervalo fuzzy normal do tipo-LR pode ser representado por = (a, m, m , b)LR, onde a = m - | | e b = m + | |. A teoria dos conjuntos fuzzy (notadamente os nmeros fuzzy) utilizada no raciocnio aproximado, para efetivamente manusear a ambigidade envolvida na avaliao de dados e em propriedades imprecisas de variveis lingsticas (LEE, 1996b).
70
III.5 Variveis Lingsticas

Uma varivel lingstica totalmente caracterizada por uma quntupla (x, T(x), U, G, M ). O nome da varivel x. O conjunto dos termos lingsticos de x T(x), ou simplesmente T, que se refere a uma varivel base u, cujos valores esto no conjunto universo U. G uma regra sinttica, para a gerao dos termos lingsticos. M uma regra semntica, que associa a cada termo lingstico t T o seu significado, M (t), que um conjunto fuzzy em U (ZIMMERMANN, 1991).
Exemplo III.13 (ZADEH, 1973a): Seja X uma varivel lingstica identificada por Idade com U = [0, 100] e seus termos lingsticos, que tambm so conjuntos fuzzy, velho, jovem, muito velho, etc. A varivel base u a idade em anos de vida. M (t) a regra que atribui um significado, isto , um conjunto fuzzy, para estes termos.
~ M (velho) = {(u, velho(u)) | u [0, 100]}, onde, para u [0, 50] 0 1 velho (u) = u 50 2 para u [50, 100] 1 + 5
T(x) define o conjunto de termos da varivel x, que, neste caso, : T(Idade) = {velho, muito velho, no to velho, mais ou menos jovem, inteiramente jovem, muito jovem} onde G(x) uma regra que gera os rtulos dos termos no conjunto de termos, conforme a Figura III.3 abaixo.
IDADE Variel lingstica Termos lingsticos
muito jovem
jovem
velho
muito velho
1 0,8
0,6 1 0,9 0,8 0,6
0,6 0,8 0,9 1
0,7 0,8 0,9 1
20
25
30
35
40 45
x(idade)
50
55
60
65
70
75
80 (idade)
varivel base
Figura III.3: Varivel lingstica Idade (ZADEH, 1973b)

71
Portanto, cada varivel lingstica, definida em termos de uma varivel base, tem seu estado denotado por termos lingsticos, que so interpretados como nmeros fuzzy especficos. Os termos lingsticos representam valores aproximados de uma varivel lingstica, relacionados a uma aplicao particular. Uma varivel base uma varivel no sentido clssico, exemplificada por uma varivel fsica (temperatura, presso, velocidade) ou por uma varivel numrica (desempenho, confiabilidade, probabilidade) (KLIR et al., 1995a). ZADEH (1977) observou que os termos lingsticos podem ser modelados atravs de funes, cujos valores so graus no domnio de uma funo de pertinncia, e que cada representao fundamental para a modelagem do raciocnio aproximado. Limitadores lingsticos so termos lingsticos especiais, que modificam outros termos lingsticos, como por exemplo, menos, muito, razoavelmente, fracamente e extremamente. Qualquer limitador lingstico pode ser interpretado como uma operao unria (ou modificadora), h, em um intervalo unitrio [0, 1]. Por exemplo, o limitador muito freqentemente interpretado como uma operao unria h(a) = a2, enquanto que razoavelmente interpretado como h(a ) = a (a [0, 1]). Conhecendo-se o significado de um termo lingstico e de sua operao modificadora, pode-se estabelecer regras semnticas, que traduzam o significado desse termo. BALDWIN (1979), baseado tambm nos conceitos acima, delineou um conjunto de termos lingsticos da varivel lingstica Verdade, mostrado na Figura III.4. verdadeiro = {(v, verdadeiro(v) = v) | v [0, 1]} falso = {(v, falso(v) = 1 - verdadeiro(v)) | v [0, 1]} muito verdadeiro = {(v, (verdadeiro(v))2) | v [0, 1]} razoavelmente verdadeiro = {(v, (verdadeiro(v))1/2) | v [0, 1]} indeciso = {(v, 1) | v [0, 1]} Muito falso e razoavelmente falso so definidos semelhantemente, e absolutamente verdadeiro = {(v, av(v)) | v [0, 1]},
1 onde av (v ) = 0 para v = 1 outros
72
absolutamente falso = {(v, af(v)) | v [0, 1]},
1 onde, af(v) = af (v ) 0
para v = 0 outros
Figura III.4: Varivel lingstica Verdade (BALDWIN, 1979)
Os termos lingsticos podem ser, tambm, caracterizados por quantificadores fuzzy que so, em geral, nmeros fuzzy, estendidos do escopo da lgica fuzzy (ZADEH, 1973a, VIOT, 1993), sendo usados para representar uma certa maioria, aproximando-se da percepo humana real (KACPRZYK et al., 1992, NOVK, 1992).
III.6 A Lgica Fuzzy

A lgica fuzzy (difusa) uma extenso da lgica (boleana) convencional, que lida com conceitos de verdade parcial - valores verdade entre completamente verdade e completamente falso modelando as incertezas da linguagem natural
(KANTROWITZ et al., 1996). Neste contexto, uma deciso, tida como correta, poder ser alterada posteriormente, quando novas informaes adicionais estiverem disponveis (CHIUEH et al., 1992). A lgica fuzzy utiliza predicados fuzzy (velho, raro, perigoso, etc.), quantificadores fuzzy (muito, pouco, quase tudo, usualmente, e semelhante), valores-verdade fuzzy (totalmente verdadeiro, mais ou menos verdadeiro, muito falso, etc.) (ZIMMERMAN, 1991).
73
Os quantificadores fuzzy, de particular interesse para os termos lingsticos fuzzy, podem ser (BOSC et al., 1995): i. absolutos: definidos em R e denotados por um nmero, como, por exemplo, no mnimo 7; ii. relativos: definidos no intervalo [0,1], referindo-se a uma proposio quantificada lingisticamente (YAGER, 1983a, YAGER, 1983b, ZADEH, 1983) como, por exemplo, muitos especialistas so convincentes. Uma proposio quantificada lingisticamente pode ser apresentada como (KACPRZYK et al., 1992): Q ys so F, Q um quantificador lingstico (por exemplo, muitos), Y = {y} um conjunto de objetos de um conjunto universo (por exemplo, especialistas), e F uma propriedade, isto , um predicado fuzzy (por exemplo, convincentes). Pode-se atribuir a y particulares (objetos) uma importncia diferente (relevncia, competncia, ...), B, e adicion-la equao anterior, gerando: Qbys so F. No caso da importncia (um predicado fuzzy) ser adicionada, B definido como um
~ (yi) [0, 1] um grau de pertinncia de yi. Assim sendo, o conjunto fuzzy em Y e B
~ (yi) tambm definido como a possibilidade de B assumir o valor de pertinncia B
valor yi. Por este motivo, a lgica fuzzy chamada tambm de teoria da possibilidade. A teoria da possibilidade (ZADEH, 1978) est, intrinsecamente, ligada linguagem natural, onde a possibilidade melhor interpretada do que a probabilidade. No entanto, a possibilidade no substitui a probabilidade - ambas lidam com incertezas e se complementam entre si. Observa-se que um alto grau de possibilidade no implica em um alto grau de probabilidade, todavia, se um evento no possvel, tambm improvvel, isto , a possibilidade o limite superior da probabilidade (ZIMMERMANN, 1991). A lgica fuzzy possui, tambm, alguns operadores bsicos fuzzy, definidos no intervalo de 0 (falso) a 1 (verdadeiro), pelas operaes binrias: fuzzy AND (f-AND),
74
fuzzy OR (f-OR), probabilidade AND (p-AND) e probabilidade OR (p-OR), e uma operao unria, NOT (RICHARDS, 1988): i. a f-AND b = min (a, b); ii. a f-OR b = max (a, b);
iii. a p-AND b = a b; iv. a p-OR b = a + b (a b); v. NOT a = 1 a.
Vrias aplicaes da teoria fuzzy envolvem o uso de uma base de regras fuzzy para modelos complexos, como os sistemas de controle de lgica fuzzy, os sistemas de controle fuzzy multivarivel (GEGOV, 1995) e os sistemas adaptativos (GRMAN, 1995). Todos os sistemas de controle fuzzy (HERTZ et al., 1991, KAUFMANN et al., 1991, LEE, 1990, NEGOITA, 1985, ZADEH, 1973b) so baseados em regras, e se aplicam quase que, exclusivamente, a sistemas de produo e controle (DUBOIS, 1989, GRAHAM et al., 1988). Geralmente, essas regras no so extradas de especialistas humanos atravs do sistema, mas produzidas, explicitamente, por seus projetistas. A idia bsica incorporar a experincia de um processo executado por um operador humano, no projeto de um controlador. De um conjunto de regras lingsticas, que descrevem a estratgia de controle dos operadores, um algoritmo de controle construdo, onde seus termos so definidos como conjuntos fuzzy (KICKERT et al., 1978). Portanto, a lgica fuzzy simula o pensamento humano, incorporando sua inerente falta de preciso a um sistema fsico. A incerteza o resultado da impreciso no aleatria de medies ou da impossibilidade de se obter uma descrio numrica exata para quantidades observadas (NICULESCU et al., 1992).
III.7 A Teoria das Incertezas e Aplicaes

A incerteza est relacionada com o ambiente e aumenta com a inerente impreciso de uma classificao ou descrio especfica. Muitas entidades possuem medidas com acurcia limitada, imprecises, falta de informao, de observao e de sensibilidade
75
das condies iniciais. O termo incerteza pode ser comparado ao termo aleatrio, sendo que, nos conjuntos fuzzy, a incerteza refere-se ao grau de pertinncia de um elemento, enquanto que, estatisticamente, a incerteza refere-se probabilidade do resultado de um experimento aleatrio (ROTHMAN, 1989). Existem trs princpios de incertezas, aplicveis somente nas situaes, onde emergem deficincias de informaes, dependendo da teoria pela qual a incerteza conceitualizada (KLIR, 1995b): i. princpio de incerteza mnima: seleo das alternativas mais importantes do conjunto soluo, reduzindo-se, tanto quanto possvel, o nmero das informaes iniciais. ii. princpio da incerteza mxima: procura-se usar todos os dados disponveis, evitando-se, porm, que informaes adicionais sejam inadvertidamente adicionadas. iii. princpio da invarincia da incerteza: requer que uma quantidade de incertezas (e de informaes) sejam preservadas, independentemente da representao terica usada, isto , garante que informaes no sejam inapropriadamente adicionadas ou eliminadas, somente pela troca da estrutura matemtica, na qual um fenmeno particular foi formalizado. Devido conexo ntima entre incerteza e informao, esses princpios podem ser concebidos, tambm, como princpios de informao. A quantidade de incertezas pode ser reduzida pela obteno de novas informaes relevantes, como o resultado de algumas aes (observao de um fato novo, execuo de um experimento, obteno de um registro histrico) (KLIR, 1995b). O gerenciamento das incertezas desempenha um importante papel nos sistemas baseados em conhecimento (SBCs) fuzzy, e nos sistemas de tomada de deciso em ambientes fuzzy, apresentados a seguir.
III.7.1 Sistemas Baseados em Conhecimento Fuzzy

Vrias propostas tm sido publicadas sobre como se usar a teoria fuzzy em SBCs (SIMONELLI, 1996, FICKAS et al., 1992, CHAN, 1991, HULL et al., 1991, DUBOIS et al., 1988, ZIMMERMANN, 1988, ZADEH, 1973a). Essa propostas tm, em comum,
76
a preocupao de que esses sistemas sejam providos com mecanismos, que manuseiem incertezas, otimizando o seu desempenho (LEE, 1994). A incerteza das informaes na base do conhecimento, por exemplo, induz incertezas nas concluses. Assim sendo, a mquina de inferncia (LESMO et al., 1982) deve ser equipada com capacidade computacional, para analisar a transmisso de incertezas das premissas para as concluses, associando-as a algumas medidas de incertezas, que sejam inteligveis e interpretadas convenientemente pelo usurio (ZIMMERMANN, 1991). Um dos principais benefcios de um SBC fuzzy sua habilidade de usar e assimilar o conhecimento de mltiplos especialistas, outorgando-lhes uma expressividade no existente em sistemas convencionais de suporte a deciso (COX, 1995). Tanto os SBCs fuzzy, quanto os sistemas de controle fuzzy, objetivam modelar a experincia e o ambiente humano de tomada de decises (CARCHIOLO et al., 1995, SUGENO, 1985, ZADEH, 1973a).
III.7.2 Tomada de Deciso em Ambientes Fuzzy

Um dos problema de tomada de deciso consiste na escolha da melhor alternativa de acordo com critrios estabelecidos, a partir de uma certa quantidade de informaes, com o propsito de atingir um objetivo estabelecido (GRABISCH, 1995, SLOWINSKI et al., 1990, TURBAN, 1988). Atualmente, a multidimensionalidade a principal caracterstica dos problemas de tomada de deciso do mundo real, tendo objetivos econmicos, ambientais, sociais e tcnicos (SAKAWA, 1994). Desde que a teoria dos conjuntos fuzzy foi sugerida como uma estrutura conceitual apropriada de tomada de deciso (BELLMANN, 1970), duas direes relevantes podem ser observadas. A primeira reflete a fuzificao de enfoques convencionais. A segunda est baseada na assuno de que o processo de tomada de deciso pode ser modelado por operadores de agregao especificados automaticamente (DUBOIS, 1984). Tipicamente, trs formas de impreciso podem ser identificadas em tomada de deciso em ambientes fuzzy (RIBEIRO et al., 1995): i. No completitude: quando no h dados suficientes como, por exemplo, ausncia de alguns atributos ou alternativas;
77
ii. Impreciso: quando h dificuldades na obteno de conceitos precisos para melhor caracterizar atributos ou critrios; iii. Iluso da validade (TVERSKY et al., 1990): deteco de sadas errneas, tais como a seleo de alternativas, que no cumpram os critrios impostos. Na tomada de deciso em ambientes fuzzy, termos como multiobjetivos, multiatributos e multicritrios so, geralmente, usados indistintamente, embora haja diferenas entre eles (RIBEIRO, 1996, KOSKO, 1992 CHEN et al. 1992): i. Tomada de deciso multiobjetivos (MODM) (ZIMMERMANN, 1991): consiste de um conjunto de objetivos conflitantes, que no podem ser alcanados simultaneamente. ii. Tomada de deciso multiatributos (MADM) (YAGER, 1978, HWANG, 1981): escolha de uma alternativa em um conjunto de alternativas, caracterizada por seus atributos. iii. Tomada de deciso multicriterial (MCDM): aplicada tanto tomada de deciso, envolvendo multiobjetivos, quanto multiatributos (CARLSSON et al., 1996, FODOR et al., 1994, CHEN et al., 1993, LUHANDJULA, 1989,). Neste caso, algumas consideraes importantes foram feitas (ZELENY, 1992): a presso do tempo reduz o nmero de critrios a serem considerados; quanto mais completa e precisa for a definio do problema, menos critrios so necessrios; indivduos que tomam deciso em sistemas estritamente hierrquicos, geralmente utilizam menos critrios do que indivduos, que lidam com outros tipos de sistemas; o isolamento de perturbaes no ambiente, reduz a necessidade de mltiplos critrios; o conhecimento maior (ou completo) e integrado do problema leva utilizao de mais critrios, enquanto que o conhecimento parcial (ou limitado) e no integrado restringe o nmero de critrios;
78
organizaes com cultura voltada para o planejamento central e tomadas de decises coletivas, apoiam-se na agregao e na reduo de critrios, para alcanar um consenso. Um dos elementos bsicos na tomada de deciso de grupo o conceito de maioria, isto , a soluo encontrada destaca a opinio mais aceitvel pela maioria dos membros do grupo. Uma maioria menos rgida (uma concordncia geral, sem a necessidade de uma inferncia individual) pode auxiliar, certamente, a formao de modelos de deciso de grupo mais consistentes e humanizados (KACPRZYK, 1992). Um outro elemento empregado, habitualmente, nas cincias de deciso a mdia de pesos, atravs de parmetros quantificveis. Na coleta de informaes, busca-se a estimativa do avaliador, que esteja mais prxima do modelo de requisitos. Sendo assim, as estimativas coletadas e a apurao de seus resultados so essenciais neste processo e, sem isto, a avaliao poderia tornar-se irrealista (ROBINS, 1995). Um modelo fuzzy de deciso adequado deve incluir processos de identificao, medio e combinao de critrios e alternativas, promovendo a modelagem conceitual, da deciso e a avaliao em ambientes nebulosos (RIBEIRO, 1996). A seguir, sero apresentados alguns modelos fuzzy de deciso, encontrados na literatura.
III.7.3 Modelos Fuzzy de Deciso

Tem sido, freqentemente, evidenciado que a relevncia (ou a qualidade) de um modelo influencia fortemente a qualidade da soluo. Se o mtodo no relevante, pode ser inapropriado continuar a busca de solues do problema em questo, ou ser necessrio reformul-lo com algumas extenses. As trs etapas, que se sucedem, podem auxiliar na tarefa de identificao da relevncia de um modelo fuzzy (PEDRYCZ, 1990): i. aquisio e determinao de dados requeridos pela estrutura do modelo; ii. estimao de parmetros; iii. validao do modelo fuzzy. No entanto, embora aferida a qualidade do mtodo escolhido, h outros fatores que podem conduzir a inconsistncias de seus resultados (DYER, 1992): i. a ausncia de informaes ou de experincias sobre o objeto avaliado;
79
ii. o desinteresse ou a falta de concentrao dos avaliadores, no processo de julgamento. Portanto, de grande importncia selecionar com acuidade os avaliadores, conduzir com destreza todo o processo de aquisio das opinies dos especialistas, seja individualmente ou em reunies prprias para a tomada de deciso. Muitos modelos de estimativas, fundamentados na teoria fuzzy, efetuam alguns procedimentos bsicos, que podem ser dispostos em trs estgios (SCHMUCKER, 1984): i. Primeiro estgio: traduo de expresses da linguagem natural para conjuntos fuzzy, atravs de operaes fuzzy correspondentes. ii. Segundo estgio: agregao desses conjuntos fuzzy em um conjunto resultante, que reproduza o sistema, que est sendo medido, como um todo. iii. Terceiro estgio: associao do conjunto fuzzy resultante a expresses naturais convenientes, que definam o sistema apropriadamente. Vrios modelos fuzzy de estimativas, apoiaram-se de algum modo na estrutura do mtodo de anlise hierrquica (SAATY, 1980). Portanto, embora esse mtodo no utilize a teoria fuzzy, ser apresentado sucintamente, juntamente com outros, que se servem dessa teoria.
III.7.3.1 Mtodo de Anlise Hierrquica
O Mtodo de Anlise Hierrquica (SAATY, 1980) parte de uma situao no estruturada e complexa, decompondo-a em partes ordenadas hierarquicamente e, atravs de julgamentos sucessivos, obtm a melhor soluo para o problema. Esse mtodo combina o uso de duas abordagens: (i) a abordagem dedutiva, que decompe o sistema em partes, para a melhor compreenso do comportamento e funcionamento das mesmas; (ii) a abordagem de sistema, que busca analisar o comportamento do sistema, no importando suas partes constituintes. Esse mtodo utiliza uma escala de propores, atravs de comparaes de pares de elementos em relao a um dado critrio imediatamente superior, partindo do topo da hierarquia. Para m critrios, C1, C2, ..., Cm, construda uma escala de proporo, que evidencia a importncia relativa de cada critrio em relao a cada um dos outros. Isto feito atravs do julgamento de especialistas, que se baseiam em uma escala de nmeros,
80
para representar a importncia relativa de um elemento sobre outro. Os julgamentos quantificados em pares de critrios Ci e Cj so reproduzidos em uma matriz m m: M = {aij: i = 1, 2, ..., m; j = 1, 2, ..., m} As entradas dessa matriz so definidas pelas seguintes regras: Regra 1: se aij = ento aji = 1/, onde 0. Regra 2: se Ci julgado ser da mesma importncia relativa de Cj, ento aij = aji. Todos os elementos diagonais aii = 1 para 1, 2, ..., m. A prioridade obtida da comparao de cada par de elementos em relao a um critrio ascendente denominada prioridade local. A prioridade de um elemento em relao ao objetivo geral chamada de prioridade global. Em sntese, pode-se afirmar que uma das principais vantagens desse mtodo que busca um resultado final, atravs da sntese de julgamentos de vrios participantes, no insistindo no consenso entre eles.
III.7.3.2 Mtodo Fuzzy Hierrquico de Avaliao
LASEK (1992) props um mtodo fuzzy hierrquico para a avaliao e a classificao de problemas com mltiplos atributos, isto , estruturas hierrquicas de avaliao fuzzy para a anlise de alvos estratgicos de empresas. No topo da hierarquia desse mtodo, esto os objetivos mais gerais, que so decompostos em subobjetivos e estratgias, nos nveis mais inferiores. Nesta metodologia, a impreciso de dados representada por conjuntos fuzzy, onde os nmeros reais so tratados como um caso especial de nmeros fuzzy, com grau de pertinncia igual a um e exprimem prioridade, classificao ou o resultado de uma avaliao. Dependendo dos relacionamentos existentes entre objetivos, subobjetivos e estratgias usado o enfoque da dependncia funcional ou da relao de preferncia. Na dependncia funcional, os julgamentos feitos pelos especialistas so realizados nos nveis mais baixos da hierarquia. As avaliaes dos outros nveis da hierarquia processam-se atravs da execuo de operaes algbricas fuzzy. Nas relaes de preferncias, so indicadas somente as prioridades (pesos) dos objetivos, subobjetivos e estratgias e, para isto, empregado o Mtodo de Anlise Hierrquica (SAATY, 1980).
81
III.7.3.3 Mtodo de Agregao de Similaridades
HSU et al. (1996) combina opinies individuais para formar uma opinio consensual de um grupo de especialistas, atravs de um mtodo de agregao de similaridade. As opinies dos especialistas so representadas por nmeros fuzzy trapezoidais, assumido que estes tm uma interseo comum, em um conjunto de corte de nvel-, onde (0, 1]. Esta uma condio imposta por esse mtodo, para que a agregao dos resultados das opinies dos especialistas seja aceitvel. Se no houver interseo entre as estimativas iniciais do k-simo e do l-simo especialista usado, ento, o Mtodo Delphi, para auxiliar na obteno de mais informaes, objetivando ajustar os dados fornecidos por cada especialista, para que haja essa interseo. Posteriormente, introduzida uma funo de medida de similaridade, para medir o grau de concordncia entre as opinies dos especialistas, e estas informaes so postas em uma matriz de concordncia. Finalmente, as opinies dos especialistas so combinadas, podendo-se levar em considerao, tambm, a importncia de cada especialista participante do processo de avaliao.
III.7.3.4 Modelo Hierrquico para Estruturas de Risco
LEE (1996a) desenvolveu uma estrutura de tomada de deciso de grupo, considerando os riscos no desenvolvimento de software. Partiu do princpio de que a avaliao de custos de software caracterizada p ela alta incerteza, existindo muitos problemas ao longo do processo de desenvolvimento, como a postergao de cronograma, o aumento de despesas, a ineficincia e o abandono de projeto. Nessa estrutura, a teoria fuzzy utilizada para manusear, efetivamente, as ambigidades envolvidas na avaliao de taxas de fatores de risco e para lidar com propriedades vagas, atravs de expresses lingsticas. Para isto, os nmeros fuzzy triangulares foram empregados, para representar a impreciso dos dados quantitativos do modelo. Um grupo de n especialistas selecionado, para a avaliao da taxa de agressividade do risco de um projeto de software em desenvolvimento. O processo de agregao dos julgamentos desses especialistas promovido de duas maneiras: (i)
82
atravs da mdia desses julgamentos, para produzir o resultado final; (ii) a agregao dos julgamentos individuais de cada especialista, para a obter a mdia dos resultados. Esse modelo compe-se de um conjunto de atributos que, por sua vez, so compostos por itens de risco. Cada atributo, juntamente com seus itens de risco, possui um grau de risco e o grau de importncia (peso), que podem ser ajustados at que o resultado esperado seja alcanado.
III.7.3.5 Modelo para Localizao Industrial
O modelo para localizao industrial objetiva facilitar a estruturao de um sistema de informaes, que possibilite ao Governo a formulao conveniente de polticas de desenvolvimento industrial. Esse modelo est baseado na teoria fuzzy, onde a anlise de alternativas se apoia na construo de hierarquia ponderada para cada proposio (COSENZA, 1981). Esse modelo foi adaptado por CAMPOS (1994b) para a rea de qualidade de software educacional, visando confrontar, sistematicamente, a demanda de fatores de qualidade do produto de software (matriz de demanda), atravs de critrios selecionados e validados por professores, para a avaliao e a oferta desses produtos (matriz de oferta). Atravs dos dados das matrizes acima, foram geradas: (i) a matriz de possibilidade de alocao, descrevendo, em valores absolutos, o grau de satisfao dos usurios por produto de software, e (ii) a matriz de resultados, contendo os ndices de alocao, que representam o resultado final do experimento, evidenciando o grau de satisfao dos usurios por cada produto analisado.
III.7.3.6 Outros Modelos
ENGEMANN et al. (1997) propuseram um mtodo geral para seleo de uma alternativa debaixo de incertezas para casos do mundo real, envolvendo riscos de gerenciamento. PRESEDO (1996) apresenta um modelo fuzzy de um sistema especialista, na deteco de isquemia baseada em eletrocardiograma, para resolver o problema de transformaes do conhecimento impreciso, fornecido pelos especialistas, em estruturas computveis.
83
COMMERLATO (1994) desenvolveu um modelo e uma ferramenta de software, para a identificao de componentes FORTRAN, pretensos reutilizao, segundo medidas obtidas atravs de mtricas de software e seleo atravs de variveis lingsticas e termos lingsticos fuzzy predeterminados. Definiu, tambm, um processo de avaliao de candidatos reutilizao em trs etapas: (i) medio, (ii) definio de variveis e termos lingsticos (representam critrios de qualidade), e (iii) seleo de candidatos, atravs dessas variveis. GARCIA et al. (1992) formaliza uma metodologia de avaliao lingstica em situaes de risco, usando tcnicas fuzzy. Neste mtodo, o clculo do risco global de um sistema, estruturado hierarquicamente, obtido atravs da avaliao do risco de cada um de seus componentes, em termos de seus descendentes. RUONING et al. (1992) prope um mtodo de tomada de deciso de grupo, em sistemas complexos, envolvendo uma grande variedade de fatores, e constri uma matriz de julgamento fuzzy, atravs de um mtodo estatstico, provando que cada elemento dessa matriz pode ser representado por um nmero fuzzy. Segundo ele, tericos de sistemas argumentam que relacionamentos complexos podem sempre ser analisados, tomando-se pares de atributos e relacionando-os entre si. Em KACPRZYK et al. (1992) e TANINO (1984) foi proposta uma relao de preferncia fuzzy para cada especialista, da qual derivada a relao fuzzy de preferncia para o grupo de especialistas, no sentido de determinar a melhor alternativa para a soluo do problema. ISHIKAWA et al. (1993) e XU et al., (1992) propuseram que cada especialista representasse o julgamento de critrios avaliados por eles, atravs de um grau de importncia obtido de um intervalo numrico fuzzy. A partir deste resultado, gerada uma distribuio de freqncia cumulativa, para derivar o julgamento consensual do grupo. BARDOSSY et al (1993) sugeriu que as estimativas de critrios, avaliadas por especialista, fossem representadas por nmeros fuzzy e combinadas atravs de operaes fuzzy. A teoria fuzzy tem sido aplicada com sucesso em muitas reas de pesquisas de modelos e em diversos estgios de processos de pesquisas, como, por exemplo,
84
reconhecimento de padres (KUMAR et al. 1996, SEONG, 1995, PAL et al. 1992), surgindo os chamados sistemas fuzzy.
85
III.8 Os Sistemas Fuzzy

Com o emprego de sistemas fuzzy (COX, 1995, DRIANKOV et al. 1993, KANDEL et al. 1993) de forma apropriada, julga-se ter produzido respostas mais rpidas e suaves que os sistemas convencionais. A maneabilidade, a robustez e, sobretudo, o baixo custo so fatores de qualidades caractersticos dos sistemas fuzzy, contribuindo para um melhor desempenho dos mesmos. So teis para problemas ou aplicaes complexas, que envolvam descries humanas ou pensamento indutivo. A Tabela III.2 mostra suas principais reas de aplicao.
Categorias
Controle Reconhecimento de Padres Anlise Quantitativa Inferncia
Aplicaes
utilizado em larga escala em aplicaes industriais processamento de imagem, udio e sinal pesquisa operacional, estatstica e gerenciamento sistemas especialistas para diagnstico, planejamento e predio processamento de linguagem natural interfaces inteligentes robs inteligentes engenharia de software
Recuperao de Informaes
base de dados
Tabela III.2: Categorias genricas de aplicaes de sistemas fuzzy (MUNAKATA et al., 1994)
Os principais passos para o desenvolvimento de um sistema fuzzy so (MUNAKATA et al., 1994): i. Constatao de que o conhecimento sobre o ambiente da aplicao em questo descrito de forma aproximada ou com regras heursticas. ii. Identificao das entradas e sadas do sistema e seus respectivos intervalos de valores. iii. Definio de uma funo para cada parmetro de entrada ou sada. A quantidade de funes requeridas depende do desenvolvedor e do ambiente do sistema. iv. Construo de uma base de regras pelo projetista, que determine quantas regras sero necessrias e quando parar de adicionar novas regras.
86
v. Verificao das sadas da base de regras e se seus intervalos de valores esto corretos e em conformidade com o conjunto de entradas usado, permitindo uma posterior validao. Vrios mtodos tm sido utilizados para o desenvolvimento e a implementao de sistemas fuzzy. Os mais comuns so: o mtodo de desenvolvimento baseado em especialistas humanos, e o mtodo de desenvolvimento baseado em tentativa e erro. Os principais problemas e limitaes de sistemas fuzzy so (MUNAKATA et al., 1994):
Estabilidade: no h garantias tericas de que um sistema fuzzy no venha a
atingir um estado catico e que seja estvel. No entanto, a experincia tem mostrado que uma expressiva maioria dos sistemas fuzzy so estveis.
Capacidade de aprendizagem: falta-lhes a capacidade de aprendizagem e no
possuem memria do que foi especificado previamente. Atualmente, sistemas hbridos, particularmente os sistemas neurofuzzy vm suprindo esta limitao.
Determinao ou refinamento de funes e regras fuzzy apropriadas: mesmo
depois de muitos testes, pode ser ainda difcil o estabelecimento conveniente das funes fuzzy requeridas.
Conceituao: h ainda um entendimento errneo do termo fuzzy, como
significando impreciso ou imperfeio, e como se no tivesse uma fundamentao matemtica sedimentada.
Verificao e validao: geralmente requerem testes extensivos.
No entanto, os benefcios intrnsecos na utilizao de sistemas fuzzy excedem a suas limitaes e seus problemas e podem ser sumariados na reduo do custo do desenvolvimento, da execuo e da manuteno da aplicao (COX, 1995).
III.9 Concluso
Neste captulo, apresentou-se a teoria fuzzy em seus aspectos mais gerais, sendo que alguns temas foram mais aprofundados, objetivando-se uma melhor fundamentao para o desenvolvimento de um modelo fuzzy para a avaliao da qualidade de software, o que ser feito no prximo captulo.
87
Captulo IV MODELO FUZZY PARA AVALIAO DA QUALIDADE DE SOFTWARE

Uma estrutura de avaliao de software tem por objetivo estimar a sua qualidade, atravs de um conjunto bsico de atributos, evidenciando seus aspectos mais relevantes. Para isto, as informaes sobre o objeto da avaliao devem estar dispostas de forma organizada, onde caractersticas especficas do software podem ser identificadas acurada e tempestivamente, para otimizar o processo de tomada de deciso (BOLOIX et al., 1995). A tomada de deciso pode ser vista como um processo de seleo de alternativas suficientemente boas ou da escolha de cursos de aes, para a obteno de um objetivo. Esse processo envolve incertezas e, portanto, necessrio que se tenha a habilidade de manusear informaes imprecisas e vagas, levando-se em considerao diferentes vises, atitudes e crenas das partes envolvidas (RIBEIRO, 1996). Portanto, importante fazer a conexo entre a informao e a deciso de um indivduo, que deve escolher uma ao entre muitas possveis, em reas distintas (SIMONELLI, 1996). Uma vez que o processo de tomada de deciso centrado em pessoas humanas, como tambm o o processo de avaliao de software, com suas inerentes subjetividades e inconsistncias na definio do problema, os conjuntos fuzzy so potencialmente adequados nesta rea, pois (IBRAHIM et al., 1992): i. possuem a habilidade de representar atributos; ii. detm formas convenientes e avaliveis para a combinao de atributos, que podem estar vaga ou precisamente definidos; iii. manuseiam diferentes graus de importncia para cada atributo considerado.
86
Captulo IV Modelo Fuzzy para Avaliao da Qualidade de Software ___________________________________________________________________________
Como em muitas outras reas do conhecimento humano, a avaliao da qualidade de software envolve a apreciao de mltiplos atributos, atravs do julgamento de um grupo de especialistas (SANDRI, 1997). Cada especialista tem a sua prpria opinio e estima um grau de importncia para cada atributo julgado, segundo sua percepo ou o seu nvel de entendimento da questo proposta. Da o interesse de se conseguir um processo de agregao, que consolide o consenso dos especialistas envolvidos, na avaliao. No processo de avaliao da qualidade de software no basta, apenas, identificar que atributos determinam essa qualidade, mas tambm que procedimentos adotar, para controlar seu processo de desenvolvimento de forma a atingir o nvel de qualidade desejado. Isto realizado atravs da aplicao de mtricas de forma organizada e projetada, tornando os desenvolvedores mais conscientizados da relevncia do gerenciamento e dos compromissos para com a qualidade (BELCHIOR, 1992b). A medio de atributos de software tem estabelecido, por si mesma, um importante e incremental papel no entendimento e controle da prtica do desenvolvimento de software. Portanto, essencial usar mtricas vlidas e acuradas, que representem os atributos, que se pretende observar e quantificar (FENTON et al., 1997). O uso de mtricas de qualidade de software deve estar apoiado em um mtodo de controle de qualidade, para que se alcance, convenientemente, os objetivos almejados (IEEE, 1987). Neste trabalho, o mtodo escolhido para a avaliao da qualidade de software o Mtodo Rocha (ROCHA, 1983), por j ter sido utilizado satisfatria e eficazmente em uma grande quantidade de domnios de aplicao. Para alinhar a confiabilidade desse mtodo s propriedades da teoria fuzzy, prope-se uma extenso do mesmo, para suportar o Modelo fuzzy para Avaliao da Qualidade de Software.
IV.1. Extenso do Modelo Rocha

Como apresentado na Seo II.2.2.1.3, o Modelo Rocha para avaliao da qualidade de produtos de software, Figura IV.1, originalmente, define qualidade de software a partir dos seguintes conceitos: 1. Objetivos da qualidade: so as propriedades gerais, que o produto deve possuir.
87
2. Fatores de qualidade: determinam a qualidade na viso dos diferentes usurios do produto. Podem ser compostos por subfatores, quando estes no definem completamente, por si s, um objetivo. 3. Critrios: so atributos primitivos, possveis de serem avaliados. 4. Processos de avaliao: determinam o processo e os instrumentos a serem utilizados, de forma a se medir o grau de presena, no produto, de um determinado critrio. 5. Medidas: so o resultado da avaliao do produto, segundo os critrios. 6. Medidas agregadas: so o resultado da agregao das medidas, obtidas ao se avaliar de acordo com os critrios, e quantificam os fatores. Os objetivos de qualidade so atingidos atravs dos fatores de qualidade, que podem ser compostos por subfatores. Objetivos, fatores e subfatores no so, diretamente, mensurveis e s podem ser avaliados atravs de critrios. Um critrio um atributo primitivo, e pode qualificar diferentes subfatores ou fatores. Nenhum critrio isolado uma descrio completa de um determinado subfator ou fator. Da mesma maneira, nenhum fator define completamente um objetivo.
Relaes Quantitativas Relaes Lgicas Objetivos
so atingidos por
Medidas quantificam agregadas

Agregar
Fatores
compem-se de
compem-se de quantificam
Medidas
Critrios determinamProcesso de Avaliao
Avaliao Software
Figura IV.1: Modelo Rocha (ROCHA, 1983)
Este modelo no fornecia formas adequadas para realizar o processo de agregao, por ele apresentado. A proposta, que descrita a seguir, vem resolver este problema. Definiu-se, ento, a extenso do Modelo Rocha atravs da utilizao de conceitos e propriedades da teoria dos conjuntos fuzzy e, assim, o Modelo Rocha Estendido foi dotado da potencialidade dessa teoria em mapear modelos qualitativos de tomada de
88
deciso e da consistncia dessa teoria no tratamento de incertezas e na agregao de informaes. Neste contexto, alguns conceitos do Modelo Rocha foram estendidos (), outros foram acrescidos () (Figura IV.2): Medidas: so o resultado da avaliao do produto, segundo os critrios, atravs de termos lingsticos fuzzy, mapeados por nmeros fuzzy. Medidas agregadas: so o resultado da agregao das medidas obtidas ao se avaliar de acordo com os critrios. So, tambm, o resultado da agregao de critrios em subfatores, fatores, objetivos, e no valor final do produto de software. Funes fuzzy: mapeiam os atributos de qualidade primitivos ou agregados, atravs do conjunto de termos lingsticos estabelecido, quantificando-os.
Relaes Quantitativas Relaes Lgicas Objetivos Medidas quantificam agregadas
so atingidos por
Relaes Interpretativas
interpretam
Fatores Funes Fuzzy F ti

interpretam
compem-se de
Agregar
compem-se de
Medidas
quantificam
Critrios determinam Processo de Avaliao
Avaliao Fuzzy Software
Figura IV.2: Modelo Rocha Estendido
A avaliao fuzzy segundo o Modelo Rocha estendido ser mostrada, a seguir, atravs de um modelo fuzzy para avaliao da qualidade de software.
IV.2 Uso da Teoria Fuzzy em Qualidade de Software

Na tica da teoria fuzzy, cada atributo de qualidade de software pode ser visto como uma varivel lingstica, relacionada a um conjunto de termos lingsticos, associados a funes de pertinncia, em um conjunto referencial estabelecido previamente. Cada critrio de qualidade ser uma composio de termos lingsticos, obtidos em um processo de avaliao, feito atravs do julgamento de especialistas selecionados. Assim sendo, tambm sero nmeros fuzzy. Por sua vez, os atributos agregados, constitudos por um subconjunto de critrios, sero tambm nmeros fuzzy.
89
Os termos lingsticos Ti, para i = 1, 2, ..., n, sero representados por nmeros fuzzy ~ normais triangulares positivos N i (ai, mi, bi) do tipo-LR (LEE, 1996b, HSU, 1996, RMER et al., 1995, HAPKE et al., 1994, BARDOSSY et al., 1993, LASEK, 1992, RUONING et al., 1992, KAUFMANN et al., 1991, GENEST, 1984, DUBOIS et al., 1980), que denotaro o grau de importncia de cada atributo considerado, onde ai < bi, embora possa se ter ai mi ou mi bi. O valor de n pode ser estabelecido de acordo com as convenincias do projeto, possveis peculiaridades do domnio de aplicao ou determinao da equipe gestora da qualidade. Isto porque a quantidade de termos lingsticos e eles prprios, a serem usados em uma aplicao especfica, podem ser escolhidos, dependendo da situao em questo. Na medio do nvel de presso sangnea, por exemplo, pode ser suficiente apenas os trs termos lingsticos: alta, normal e baixa, para que se consiga diagnosticar um paciente apropriadamente. J na aplicao de conceitos a alunos universitrios, por exemplo, muitas vezes so utilizados quatro termos lingsticos: excelente (A), bom (B), regular (C) e deficiente (D). Entretanto, uma vez estabelecido o valor de n e o conjunto de termos lingsticos para o domnio de aplicao, ou para o objeto a ser apreciado, isto deve permanecer constante ao longo de todo o processo de avaliao. Nas situaes apresentadas acima, no se poderia usar, por exemplo, as expresses: presso deficiente (a presso estaria alta ou baixa?), nem aluno normal (o conceito desse aluno seria A, B ou C?). Sendo assim, baseado em HSU et al. (1996), LEE (1996a), KACPRZYK et al. (1992), BALDWIN (1979), ZADEH (1977), so sugeridos alguns conjuntos de termos lingsticos, que podero ser utilizados, na avaliao da qualidade de um produto de software. A Tabela IV.1 mais abrangente, possuindo graus de pertinncia no intervalo [0, 10], isto , ai, mi, bi [0, 10] e n = 11. Como 10 um fator de 100, a utilizao dessa tabela pode facilitar o processo de avaliao, isto , tem-se uma viso percentual do objeto avaliado. Seja, por exemplo, o termo lingstico mdio, de grau de importncia 5,0 que corresponderia a 50%.
90
A Tabela IV.2 uma simplificao da anterior, possuindo graus de pertinncia no intervalo [0, 5], isto , ai, mi, bi [0, 5] e n = 6. Pode ser usada quando no houver necessidade de maiores detalhamentos dos termos lingsticos bsicos. A Tabela IV.3 possui graus de pertinncia no intervalo [0, 4], isto , ai, mi, bi [0, 4] com n = 5. Os termos lingsticos dessa tabela tm sido largamente utilizados em muitos trabalhos de pesquisa, especialmente na rea de qualidade de software, utilizando-se o Modelo Rocha (CLUNIE, 1997, OLIVEIRA, 1995b). Por este motivo, que essa tabela empregada, no experimento realizado no prximo captulo, para a validao do mtodo fuzzy, que definimos na seo a seguir. Grau de importncia 0,0 1,0 2,0 3,0 4,0 5,0 6,0 7,0 8,0 9,0 10,0 Simbologia N EB MB B LB M LA A MA EA I Termo Lingstico Nenhum ou ausente Extremamente baixo Muito Baixo Baixo Ligeiramente Baixo Mdio Ligeiramente Alto Alto Muito Alto Extremamente Alto Imprescindvel Nmero fuzzy normal
~ N 1 = (0,0; 0,0; 1,0) ~ N 2 = (0,0; 1,0; 2,0) ~ N 3 = (1,0; 2,0; 3,0) ~ N 4 = (2,0; 3,0; 4,0) ~ N 5 = (3,0; 4,0; 5,0) ~ N 6 = (4,0; 5,0; 6,0) ~ N 7 = (5,0; 6,0; 7,0) ~ N 8 = (6,0; 7,0; 8,0) ~ N 9 = (7,0; 8,0; 9,0) ~ N 10 = (8,0; 9,0; 10,0) ~ N 11 = (9,0; 10,0;10,0)
Tabela IV.1: Nmeros fuzzy normais para termos lingsticos (abrangente)
Grau de importncia 0,0 1,0 2,0 3,0 4,0
Simbologia N MB B M A
Termo Lingstico Nenhum ou ausente Muito Baixo Baixo Mdio Alto
Nmero fuzzy normal ~ N 1 = (0,0; 0,0; 1,0) ~ N 2 = (0,0; 1,0; 2,0) ~ N 3 = (1,0; 2,0; 3,0) ~ N 4 = (2,0; 3,0; 4,0) ~ N 5 = (3,0; 4,0; 5,0)
91
5,0
MA
Muito Alto
~ N 6 = (4,0; 5,0; 5,0)
Tabela IV.2: Nmeros fuzzy normais para termos lingsticos (simplificado)
Grau de importncia 0,0 1,0 2,0 3,0 4,0
Simbologia NR PR R MR I
Termo Lingstico Nenhuma Relevncia Pouca Relevncia Relevante Muito Relevante Imprescindvel
Nmero fuzzy normal
~ N 1 = (0,0; 0,0; 1,0) ~ N 2 = (0,0; 1,0; 2,0) ~ N 3 = (1,0; 2,0; 3,0) ~ N 4 = (2,0; 3,0; 4,0) ~ N 5 = (3,0; 4,0; 4,0)
Tabela IV.3: Nmeros fuzzy normais para termos lingsticos (por relevncia)
O conjunto dos termos lingsticos das trs tabelas propostas acima possuem as seguintes funes de pertinncia, adaptadas de LEE (1996b):
~ N 1 = (0,0; 0,0; 1,0)
1 x , N1 ( x ) = 0,
0, x ( k 2), Nk ( x) = k x, 0,
0 x1 1 x n
0 x k -2 k - 2 x k -1 k -1 x k kxn
~ N k = (k - 2; k - 1; k)
para k = 2, ..., (n1)
0, 0 x n2 ~ N n = (n 2; n1; n1) Nn ( x ) = x (n 2), n 2 x n 1

Como neste trabalho ser utilizado o conjunto de termos lingsticos da Tabela IV.3, apresenta-se abaixo o grfico de suas funes de pertinncia, na Figura IV.3.
92

NR . . PR R MR I
1 0,8 0,6 0,4 0,2 0 0 1 2 3 4
Figura VI.3: Funes de pertinncia de nmeros fuzzy, para termos lingsticos
Depois de estabelecido o conjunto de termos lingsticos e suas funes caractersticas, apresenta-se, a seguir, a etapas do Modelo Fuzzy para Avaliao da
Qualidade de Software.
IV.3 Etapas do Modelo Fuzzy para Avaliao da Qualidade de Software

O mtodo fuzzy para avaliao da qualidade de software possui cinco etapas, para a consecuo de seus objetivos, que podem envolver trs situaes distintas:
Determinao do Padro de Qualidade (PQ) de um produto de software ou

de um domnio de aplicao. Procura-se obter de especialistas do produto (ou do
domnio de aplicao) o grau de importncia para cada atributo, de forma que o produto seja considerado de qualidade, tomando-se, como base, o objeto da avaliao. Isto significa dizer que o peso atribudo a cada atributo, por um especialista, deve retratar como o produto deveria estar. Portanto, neste caso, no se est avaliando o estado de um certo produto, mas o padro ideal de qualidade que ele deveria apresentar.
Avaliao da qualidade de um produto de software, apoiando-se em um

PQ j previamente definido. Cada especialista julga o conjunto de atributos de
qualidade, considerando o estado em que o software se encontra. Os resultados deste julgamento sero confrontados com o PQ, j estabelecido para o produto ou para o domnio de aplicao. So gerados, ento, ndices de qualidade, para cada atributo considerado, chegando-se medio da qualidade do produto final. Esses ndices medem o quanto o produto avaliado atinge, percentualmente, do padro ideal de qualidade estabelecido, que tem ndice igual a 1.
93
Estimativa da qualidade de um produto de software, sem que haja um PQ

j estabelecido. Neste caso, como no h um PQ definido, os resultados sero apurados
levando-se em conta apenas o julgamento dos especialistas para o produto em questo. Com este procedimento, a equipe de desenvolvimento ou a equipe gestora da qualidade do produto ter um conjunto de dados teis, que podero auxiliar na continuidade do desenvolvimento do produto ou servir de parmetros para possveis melhorias em um produto j desenvolvido. A seguir, as etapas do modelo fuzzy para avaliao da qualidade de software so apresentadas e, aps cada etapa, fornecido um exemplo de utilizao deste modelo. Esse exemplo est baseado em uma pesquisa de campo realizada por CLUNIE (1997), para avaliao do padro de qualidade para especificaes de requisitos de software.
1. PRIMEIRA ETAPA: identificao do objeto a ser avaliado, do conjunto de atributos de qualidade de software a ser considerado na avaliao e das instituies pesquisadas. 1.1. Estabelecer o objeto da avaliao: nesta etapa, estabelece-se qual o
produto de software que ser objeto da avaliao. Podem ser avaliados subprodutos gerados durante as diversas fases do ciclo de vida de um produto de software ou o prprio produto final.
1.2. Definir o conjunto de atributos de qualidade: o conjunto de atributos
definido considerando-se o objeto a ser avaliado, o domnio da aplicao e a tecnologia de desenvolvimento. Podem acontecer duas situaes. Na primeira, os atributos j estarem definidos, fruto de trabalhos anteriores. Para o Modelo Rocha e, portanto, passveis de utilizao com o Modelo Rocha Estendido, proposto neste trabalho, tem-se conjuntos de atributos definidos para diversos domnios de aplicao, como mostra a Seo 2.2.1.3. Na segunda situao, os atributos ainda no esto definidos e deve-se, portanto, proceder sua identificao, podendo-se para isto contar com a ferramenta proposta por (PASSOS, 1996).
1.3. Selecionar a(s) instituio(es) onde a pesquisa ser realizada:
Em uma nica instituio: quando esta processa a avaliao de atributos de qualidade de um produto de software, que lhe prprio.
94
Em vrias instituies: quando dados so coletados com o objetivo de ser definido o padro de qualidade de um determinado produto de software, em uma rea de aplicao especfica.
EXEMPLO Etapa 1: 1.1. Objeto da avaliao: especificaes de requisitos de software (ERS). 1.2. Conjunto de atributos: o conjunto de atributos de qualidade considerados para ERS, foram definidos por CLUNIE (1997), segundo o Modelo Rocha (ROCHA, 1983), Apndice II, e esto distribudos da seguinte forma: Objetivo Confiabilidade da Representao: 19 critrios, 8 subfatores e 2 fatores. Objetivo Confiabilidade Conceitual: 9 critrios, 5 subfatores e 2 fatores. Objetivo Utilizabilidade: 13 critrios (que lhe so prprios), 28 critrios (no pertencentes diretamente a esse objetivo, mas a ele relacionados), 12 subfatores e 4 fatores. 1.3. Instituies onde a pesquisa foi realizada: foram selecionadas 3 instituies, com larga experincia na elaborao de ERS: uma empresa estatal e uma multinacional, ambas de grande porte, e a COPPE/ Sistemas, da UFRJ.
2. SEGUNDA ETAPA: escolha dos especialistas.
De uma maneira geral, todos os indivduos, que esto ou j estiveram, direta ou indiretamente, envolvidos com produtos similares ao objeto de avaliao podero participar do processo de avaliao.
2.1. Obter o perfil dos especialistas: obteno do perfil dos especialistas
(ISHIKAWA et al., 1993), Ei (i = 1, 2, ..., n), que participaro do processo de investigao, atravs do Questionrio de Identificao do Perfil Especialista (QIPE), Apndice I, para se ter a indicao da importncia relativa de cada um deles. (Tem-se encontrado, na literatura, a atribuio de pesos aos especialistas, sem uma estrutura formal de clculo).
2.2. Calcular o peso do especialista: calcula-se o grau de importncia relativa de
cada especialista, isto , o peso pEi, atravs dos dados obtidos pelo preenchimento do QIPE, levando-se em considerao os seguintes critrios:
95
cada QIPE contm as informaes de um nico especialista; O total de escores de cada especialista, tQIPEi, calculado, segundo indicaes contidas na apurao dos resultados do QIPE. o peso de cada especialista pEi, que seu peso relativo em relao aos outros especialistas (mdia ponderada), definido por: pEi =
tQIPEi
tQIPE
i =1
EXEMPLO Etapa 2: Foram selecionados 16 especialistas, que esto, ou j estiveram, diretamente envolvidos com a elaborao de especificaes de requisitos de software. 2.1. Perfil dos especialistas: o perfil de cada especialista, Ei, que participou desse processo de investigao, foi obtido atravs do Questionrio de Identificao do Perfil Especialista (QIPE), Apndice I, para se ter a indicao da importncia relativa de cada um deles. 2.2. Clculo do peso de cada especialista: para cada um dos 16 especialista Ei, foram preenchidos os 7 itens do QIPE (i1, i2, ..., i7). Os escores de cada item foram obtidos, segundo o Apndice I, chegando-se, finalmente, ao o peso pEi relativo de cada especialista, como exibe a Tabela IV.4. Apurao dos Resultados do QIPE
Ei / item 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Total 16 i1 2,60 1,70 1,90 1,70 2,10 1,70 4,50 2,60 1,40 3,10 0,80 2,30 3,60 2,60 1,70 2,60 i2 2,30 1,70 2,00 3,60 2,70 1,90 2,60 1,30 1,70 3,00 1,30 2,00 3,30 1,70 1,70 3,30 i3 3,60 2,40 3,90 3,60 3,10 1,80 3,60 2,40 3,60 3,90 3,60 3,60 3,60 2,40 2,40 3,60 i4 0,30 0,30 0,70 1,00 0,00 0,00 1,00 0,30 0,00 0,70 0,00 0,00 0,70 0,30 0,30 0,00 i5 0,90 0,90 0,70 0,90 0,90 1,00 1,00 0,70 0,70 0,90 0,90 0,70 0,90 0,70 0,70 1,00 i6 0,70 0,60 0,60 0,80 0,80 1,00 1,00 0,80 0,70 0,80 0,70 0,40 1,00 0,70 0,70 0,80 i7 tQIPE pEi 1,40 4,149 0,059 4,00 3,578 0,051 2,00 4,134 0,059 4,90 5,384 0,077 7,80 4,321 0,062 10,80 4,211 0,060 8,10 6,278 0,090 4,00 3,667 0,052 2,70 3,317 0,047 9,20 5,641 0,080 7,40 3,640 0,052 4,60 3,449 0,049 12,80 6,240 0,089 4,00 3,678 0,052 4,00 3,478 0,050 9,30 4,944 0,071 Total Total 70,108 1,000
Tabela IV.4.: Resultados do QIPE

96
3. TERCEIRA ETAPA: determinao do grau de importncia de cada atributo de qualidade, identificado na Etapa 1.
O processo de investigao consiste em se obter dos especialistas, a serem selecionados, graus de importncia, para obter o julgamento destes em relao a cada um dos atributos de qualidade mensurveis (critrios), atravs do uso do conjunto de termos lingsticos, caracterizados por nmeros fuzzy triangulares normais do ~ tipo-LR, N i (ai, mi, bi), previamente delineados (por exemplo, a Tabela IV.3).
~ Caso o especialista avaliador deseje utilizar um outro nmero fuzzy N k (ak, mk,
bk), que no pertena ao conjunto previamente estabelecido, poder faz-lo, desde que k [0, n1] e 1 < k < n. Por exemplo, se a Tabela IV.2 for usada, um especialista, em sua avaliao de um determinado atributo, poderia optar pelo ~ nmero fuzzy N k = (2,5;3,7;4,8), com significado semntico entre os termos lingsticos mdio e alto, uma vez que n = 6 e, ak, mk, bk [0, 5]. Nesta etapa, os especialistas devero ser comunicados de que o processo de investigao, que est sendo aplicado, para o levantamento de um determinado Padro de Qualidade (PQ), ou apenas uma avaliao do estado de um produto de software real, para que possam realizar seus julgamentos convenientemente.
3.1. Definir o procedimento de investigao: esse procedimento poder
consistir na elaborao de um questionrio ou um outro dispositivo de investigao, e na definio de tcnicas de aplicao prprias para o mesmo, usando-se graus de importncia (dos termos lingsticos) estabelecidos.
3.2. Aplicar o dispositivo de investigao aos especialistas: o dispositivo de
investigao aplicado aos especialistas selecionados na etapa anterior.

EXEMPLO Etapa 3: 3.1. Procedimento de investigao: consistiu na elaborao de um questionrio e na definio de tcnicas para o manuseio do mesmo (Apndice III). 3.2. Aplicao do questionrio: o questionrio foi aplicado a uma pesquisa de campo (CLUNIE, 1997), sendo obtido de cada especialista avaliador, graus de importncia para cada um dos atributos de qualidade mensurveis (critrios), selecionados na primeira etapa, atravs da utilizao somente
97
Captulo IV Modelo Fuzzy para Avaliao da Qualidade de Software ___________________________________________________________________________ do conjunto de termos lingsticos, caracterizados por nmeros fuzzy normais triangulares do tipo-LR, delineados na Tabela IV.3
4. QUARTA ETAPA: tratamento dos dados coletados dos especialistas, na avaliao de cada atributo de qualidade mensurvel considerado (critrio).
Nesta etapa, os prognsticos individuais, obtidos de cada especialista (nmeros fuzzy normais triangulares), so combinados, para cada um dos atributos de qualidade diretamente mensurveis (critrios), gerando-se uma opinio consensual entre esses especialistas, para cada critrio avaliado, sendo formalizada por uma ~ funo de pertinncia fuzzy caracterstica N , onde:
~ ~ ~ ~ N = f ( N 1 , N 2 ,..., N n )
4.1. Calcular o grau de concordncia (HSU et al., 1996, CHEN et al., 1993, ~ ~ ZWICK et al., 1987): calcula-se o grau de concordncia, C ( N i , N j ) ,
combinando-se os julgamentos dos especialistas Ei e Ej, atravs da razo entre a rea de interseo entre eles e a rea total, de suas funes de pertinncia, isto :
~ ( x)})dx x(min{N~i (x), N ~ ~ j C( Ni , N j ) = ~ ( x), ~ ( x)})dx x(max{N N
i j
4.2. Construir a matriz de concordncia: calculados todos os graus de
concordncia entre cada par de especialistas Ei e Ej, constri-se uma matriz de concordncia, MC, que fornece as indicaes da aquiescncia entre eles, ~ ~ onde Cij = C ( N i , N j ) , se i j e Cij = 1, se i = j. 1 M MC = Ci1 M Cn1 C12 M Ci 2 M Cn 2 ... C1 j M ... Cij M ... Cnj ... C1n M M ... Cin M M ... 1
Aps a construo da matriz MC, deve-se observar os seguintes itens:
98
i. Caso Cij = 0, isto , no h interseo entre o i-ensimo e o j-simo especialista, obtm-se mais informaes desses especialistas (segundo a convenincia da avaliao), com o objetivo de ajustar (convergir) suas opinies, isto , chegar a uma interseo entre eles. ii. Depois de obtidas as novas informaes, conforme o item (i), se persistir algum grau de concordncia nulo, consider-lo na matriz MC, pois, no processo de agregao (item 4.6), os valores nulos (isto , os que destoaram do consenso geral entre os especialistas) tero peso zero no resultado final da agregao. iii. Atentar para o fato de que se houver uma grande disparidade de respostas (isto , um baixo consenso entre os especialistas), isto pode significar que estes no entenderam convenientemente a definio do objeto de investigao (DYER, 1992). Neste caso, o item (i) deve ser executado, tanto quanto possvel, no sentido de se chegar ao maior consenso entre esses especialistas.
4.3. Calcular a concordncia relativa: atravs dos dados obtidos de MC,
calcula-se a concordncia relativa de cada especialista (CRi) envolvido neste processo, pela mdia quadrtica do grau de concordncia entre eles: CRi =
1 n Cij 2 n 1 j =1
j i
Com este procedimento, o clculo de CRi tender para os maiores ndices de consenso entre os especialistas avaliadores.
4.4. Calcular o grau de concordncia relativa: o grau da concordncia
relativa, GCRi, de um especialista, em relao a todos os outros especialistas, obtido pela mdia ponderada de CRi de cada especialista: GCRi =
CRi
CR
i =1
4.5. Calcular o coeficiente de consenso dos especialistas: o coeficiente de
consenso, obtido para cada especialista (CCEi) considerar tanto o GCRi,

quanto o peso, pEi (item 2.2), de cada um deles.
99
CCEi =
GCRi pEi
(GCR p
i =1 i
Ei
4.6. Avaliar o critrio de qualidade: o resultado da avaliao de cada critrio de ~ qualidade ser dado por N , que tambm um nmero fuzzy normal
triangular, onde o produto algbrico fuzzy (HSU et al., 1996, KAUFMANN et al., 1991):
~ n ~ N = (CCEi N i )
i =1
EXEMPLO Etapa 4: Neste exemplo, sero apresentados os clculos da avaliao do critrio, Correo da Notao, que um dos atributos de qualidade pertencentes ao objetivo Confiabilidade da Representao. 4.1. Clculo do grau de concordncia: o clculo do grau de concordncia,
~ ~ C ( N i , N j ) , entre os especialistas Ei e Ej, foi obtido atravs da razo entre

a rea de interseo das funes de pertinncia, i e j, Tabela IV.6, correspondentes aos termos lingsticos, utilizados no julgamento do critrio, por esses especialistas, Tabela IV.5, e a rea de unio dessas mesmas funes de pertinncia.
Especialistas avaliadores 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Nmeros fuzzy a b m 2,00 4,00 3,00 2,00 4,00 3,00 3,00 4,00 4,00 3,00 4,00 4,00 3,00 4,00 4,00 2,00 4,00 3,00 1,00 3,00 2,00 3,00 4,00 4,00 2,00 4,00 3,00 2,00 4,00 3,00 3,00 4,00 4,00 2,00 4,00 3,00 3,00 4,00 4,00 2,00 4,00 3,00 3,00 4,00 4,00 3,00 4,00 4,00 rea de 1,00 1,00 0,50 0,50 0,50 1,00 1,00 0,50 1,00 1,00 0,50 1,00 0,50 1,00 0,50 0,50
Tabela IV.5: Termos lingsticos (nmeros fuzzy), usados pelos especialistas na avaliao do critrio, Correo da Notao.
100

rea E5/ Ej 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25 de Interseo entre Ei e Ej E6/ E7/ E8/ E9/ E10/ E11/ E12/ Ej Ej Ej Ej Ej Ej Ej 1,00 0,25 0,25 1,00 1,00 0,25 1,00 1,00 0,25 0,25 1,00 1,00 0,25 1,00 0,25 0,00 0,50 0,25 0,25 0,50 0,25 0,25 0,00 0,50 0,25 0,25 0,50 0,25 0,25 0,00 0,50 0,25 0,25 0,50 0,25 1,00 0,25 0,25 1,00 1,00 0,25 1,00 0,25 1,00 0,00 0,25 0,25 0,00 0,25 0,25 0,00 0,50 0,25 0,25 0,50 0,25 1,00 0,25 0,25 1,00 1,00 0,25 1,00 1,00 0,25 0,25 1,00 1,00 0,25 1,00
Ei/ Ej Ei/E1 Ei/E2 Ei/E3 Ei/E4 Ei/E5 Ei/E6 Ei/E7 Ei/E8 Ei/E9 Ei/E1
0
E1/ Ej 1,00 1,00 0,25 0,25 0,25 1,00 0,25 0,25 1,00 1,00
E2/ Ej 1,00 1,00 0,25 0,25 0,25 1,00 0,25 0,25 1,00 1,00
E3/ Ej 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25
E4/ Ej 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25
E13/ Ej 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25
E14/ Ej 1,00 1,00 0,25 0,25 0,25 1,00 0,25 0,25 1,00 1,00
E15/ Ej 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25
E16/ Ej 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25
Ei/E1 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25 0,50 0,25 0,50 0,50 0,50 0,50
1
Ei/E1 1,00 1,00 0,25 0,25 0,25 1,00 0,25 0,25 1,00 1,00 0,25 1,00 0,25 1,00 0,25 0,25
2
Ei/E1 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25 0,50 0,25 0,50 0,25 0,50 0,50
3
Ei/E1 1,00 1,00 0,25 0,25 0,20 1,00 0,25 0,25 1,00 1,00 0,25 1,00 0,25 1,00 0,25 0,25
4
Ei/E1 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25 0,50 0,25 0,50 0,25 0,50 0,50
5
Ei/E1 0,25 0,25 0,50 0,50 0,50 0,25 0,00 0,50 0,25 0,25 0,50 0,25 0,50 0,25 0,50 0,50
6
Tabela IV.6: rea de interseo entre os especialistas Ei e Ej na avaliao do critrio, Correo da Notao.
4.2. Construo da matriz de concordncia: calculados todos os graus de concordncia entre cada par de especialistas Ei e Ej, foi construda a matriz de concordncia, MC, Tabela IV.7.
Matriz de Concordncia (MC) E1/ E2/ E3/ E4/ E5/ E6/ E7/ E8/ E9/ E10/ E11/ Ej Ej Ej Ej Ej Ej Ej Ej Ej Ej Ej 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 0,14 0,14 0,00 0,00 0,00 0,14 1,00 0,00 0,14 0,14 0,00 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 101
Ei/ Ej Ei/E1 Ei/E2 Ei/E3 Ei/E4 Ei/E5 Ei/E6 Ei/E7 Ei/E8 Ei/E9 Ei/E10 Ei/E11 Ei/E12 Ei/E13 Ei/E14 Ei/E15 Ei/E16
E12/ Ej 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 1,00 0,20 1,00 0,20 0,20
E13/ Ej 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 0,20 1,00 0,20 1,00 1,00
E14/ Ej 1,00 1,00 0,20 0,20 0,20 1,00 0,14 0,20 1,00 1,00 0,20 1,00 0,20 1,00 0,20 0,20
E15/ Ej 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 0,20 1,00 0,20 1,00 1,00
E16/ Ej 0,20 0,20 1,00 1,00 1,00 0,20 0,00 1,00 0,20 0,20 1,00 0,20 1,00 0,20 1,00 1,00

Tabela IV.7: Matriz de Concordncia entre os especialistas Ei e Ej na avaliao do critrio, Correo da Notao.
Aps a construo da matriz MC acima, observou-se que apenas o especialista E7 possui graus de concordncia nulos, isto , no h concordncia de seu julgamento com os julgamentos dos especialistas E3, E4, E5, E8, E3, E11, E13, E15 e E16. Como este trabalho utiliza os dados da pesquisa de campo realizada por CLUNIE (1997), o acesso posterior a todos os especialistas, que participaram desta pesquisa, tornou-se muito difcil. Como o ajuste para a convergncia das opinies entre todos os especialistas, isto , Cij 0, para cada um dos 41 critrios avaliados, demandaria vrias entrevistas com esses especialistas, tendo em conta a dificuldade de acesso a vrios deles, decidiu-se pela utilizao apenas das informaes originais da pesquisa de campo, uma vez que isto possvel no MFAQS. Com este procedimento, os graus de concordncia nulos, de um dado especialista, agiro no sentido de reduzir o peso desse especialista no julgamento final do atributo avaliado. 4.3. Clculo da concordncia relativa: atravs dos dados obtidos da matriz MC, calculou-se a concordncia relativa (CRi) de cada especialista envolvido neste processo, pela mdia quadrtica do grau de concordncia entre eles, Tabela IV.8. Para o especialista E1, por exemplo, tem-se:
CR1=
1 (1,00 2 + 0,20 2 + 0,20 2 + 0,20 2 + 1,00 2 + 0,14 2 +...+0,20 2 ) = 0,6501 16 1
4.4. Clculo do grau de concordncia relativa: o grau da concordncia relativa, GCRi, de cada especialista, em relao aos demais especialistas, foi obtido pela mdia ponderada de CRi de cada especialista, mostrado na Tabela IV.8. Para o especialista E1, por exemplo, tem-se: GCR1 = 0,6501 / 10,1723 = 0,06391 4.5. Clculo do coeficiente de consenso dos especialistas: o coeficiente de consenso foi obtido para cada especialista (CCEi), sendo considerado tanto o GCRi, quanto o peso, pEi, Tabela IV.8, de cada um deles. Para o especialista E1, por exemplo, tem-se:
CCE1 =
0,06391 0,0592 = 0,0621 0,0610

CRi 0,6501 102 GCRi 0,0639 CCEi 0,0621
Especialistas 1

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Total 16 0,6501 0,6967 0,6967 0,6967 0,6501 0,0976 0,6967 0,6501 0,6501 0,6967 0,6501 0,6470 0,6501 0,6967 0,6967 Total 10,1723 0,0639 0,0685 0,0685 0,0685 0,0639 0,0096 0,0685 0,0639 0,0639 0,0685 0,0639 0,0636 0,0639 0,0685 0,0685 Produto 0,0610 0,0535 0,0663 0,0863 0,0693 0,0630 0,0141 0,0588 0,0496 0,0844 0,0583 0,0516 0,0929 0,0550 0,0557 0,0792 Total 1,0000
Tabela IV.8: Concordncia relativa, grau de concordncia relativa, e coeficiente de concordncia entre os Ei e Ej na avaliao do critrio, Correo da Notao.
4.6. Avaliao do critrio de qualidade: o resultado da avaliao do Critrio, Correo da Notao, dado por N , que tambm um nmero fuzzy normal triangular:
~ ~ ~ N = { [0,0621 N 1 ] + . . . + [0,0792 N16 ] }

= { [(0,0621 2,00) + . . . + (0,0792 3,00)]; [(0,0621 3,00) + . . . + (0,0792 4,00)]; [(0,0621 4,00) + . . . + (0,0792 4,00)] } N = (2,55; 3,55; 3,99)
5. QUINTA ETAPA: agregao dos atributos de qualidade de software, em cada nvel hierrquico do modelo de qualidade.
Nesta etapa, faz-se a agregao dos atributos de qualidade (BELCHIOR et al., ~ 1995c, BELCHIOR et al., 1996a, BELCHIOR et al., 1996b) do tipo N , de acordo com o Modelo Rocha Estendido, gerando-se uma funo de pertinncia fuzzy caracterstica, para cada subconjunto de atributos de qualidade em questo, isto , os atributos agregados:
Objetivos Fatores SubfatoresCrit rios Software (1, o) (1, f ) (0, s) (1, c)
103
Assim sendo, tem-se de 1 a o objetivos de qualidade para um produto de software. Para cada objetivo, so definidos de 1 a f fatores de qualidade a ele relacionados. Cada fator contm de 0 a s subfatores. Cada fator/subfator possui de 1 a c critrios (BELCHIOR, 1992b).
~ Cada atributo agregado avaliado, N , composto por seus atributos constituintes, ~ ~ ~ N 1 , N 2 ,..., N n , tambm ser formalizado por:
~ ~ ~ ~ N = f ( N 1 , N 2 ,..., N n )
5.1 Estabelecer o padro de qualidade: quando se tratar do estabelecimento do
padro de qualidade (PQ) para um determinado produto de software ou para um domnio de aplicao especfico, calcula-se o peso Wi (BELCHIOR et al., 1995b, BELCHIOR et al., 1996c, CHEN et al., 1995, LIOU et al., 1992), isto , o grau de contribuio de cada atributo, que compe o atributo agregado avaliado. O peso de cada atributo Wi ser obtido pela mdia ponderada dos graus de importncia de cada um de seus atributos constituintes, isto , o valor wi, que ser calculado atravs da defuzificao ~ de seu nmero fuzzy N i (ai, mi, bi) correspondente. Portanto: i. O valor wi ser dado por: wi = mi, que corresponde ao valor com grau de pertinncia igual a 1, isto , este o valor ntido (clssico) do atributo de qualidade. ii. O peso Wi, ser dado por: Wi = wi / wi
5.2 Calcular o grau de concordncia agregado: calcula-se o grau de ~ ~ concordncia, C ( N i , N j ) , entre os atributos de qualidade, que esto sendo
~ agregados (que so nmeros fuzzy N ) da mesma maneira que no item 4.1.

5.3 Construir a matriz de concordncia de agregao: aps o clculo de todos
os Cij dos atributos pertencentes ao subconjunto, que est sendo agregado, gera-se a matriz de concordncia de agregao (MCA) similarmente ao item 4.2. Se Cij = 0, isto , no h interseo entre os atributos i e j, procedese ao clculo do grau da no concordncia, Cij , entre esses atributos, que dever ser um valor no intervalo [-1, 0]:
104
Cij =
d r , onde: D
i. d a menor distncia entre os dois nmeros fuzzy considerados (atributos) , ou seja, d = aj bi ou d = ai bj (utiliza-se o menor valor absoluto de d). ii. D a maior distncia entre o maior e o menor nmero fuzzy do conjunto ~ ~ de termos lingsticos considerados, isto , N n e N 1 respectivamente. Portanto, D = an b1.
~ ~ iii. r a razo entre as reas dos nmeros fuzzy N i e N j , sendo que 0 < r 1, da:
(
r=
(
x
~ Ni ~ Nj
( x ))dx ( x ))dx
(
ou r=
(
x
~ Nj ~ Ni
( x ))dx ( x ))dx
5.4 Construir a matriz dos estados de agregao: constri-se a nova matriz do
estado de agregao, MEA, que conter os valores de Cij e Cij , isto , os grau dos estados de agregao, Eij, substituindo a matriz MCA.
5.5 Calcular o estado relativo de agregao: obtm-se o estado relativo de
agregao, ERA (era), atravs da concordncia ou no concordncia de cada um dos atributos, que esto sendo agregados, atravs de dois procedimentos: i. Quando existe algum grau de no concordncia, Cij , na matriz MA, calcula-se, inicialmente, o era de cada atributo, pela mdia aritmtica do grau de concordncia e do grau de no concordncia do atributo em questo com os outros que esto sendo agregados, quantificando-se, assim, o quanto o atributo concorda ou diverge em relao aos demais, no processo de agregao.
1 n erai = E n 1 j =1 ij
j i
Com este procedimento, visualiza-se o estado de cada atributo no processo de agregao, isto , o quanto cada atributo realmente contribui na composio do novo atributo agregado. Quando algum atributo agregante tiver seu era no positivo (condio de alerta), deve-se inquirir se, de fato, esse atributo deveria pertencer ou no quele ramo da
105
hierarquia de composio dos atributos do produto de software, que est sendo avaliado. Esta pode ser uma informao til, para a validao da rvore hierrquica dos atributos de qualidade de software. ii. Uma vez que os atributos, que esto sendo agregados, realmente pertencem ao ramo hierrquico da rvore dos atributos de qualidade em questo, procede-se ao clculo do ERA pela mdia quadrtica de todos os graus dos estados de agregao, Eij, de seus atributos agregantes. ERAi = 1 n Eij 2 n j =1
Neste caso, os graus negativos (de no concordncia) so tratados e exercem a mesma influncia como se fossem positivos. Com este procedimento, objetiva-se chegar a um valor compensatrio da contribuio de cada atributo no processo de agregao, atravs do modelo fuzzy proposto. Desta forma, preservando-se as caractersticas particulares de composio dos atributos, isto , sua localizao na rvore hierrquica de atributos de qualidade de software, estabelecida pela equipe gestora da qualidade na organizao, executa-se o processo de agregao. Se for detectado algum erro de localizao nessa rvore, este deve ser tratado pela equipe responsvel pela qualidade do produto avaliado, com sugerido no item (i) anterior, ou atravs de outro procedimento estabelecido ou utilizado por essa equipe, sendo seus resultados de inteira responsabilidade da mesma. Exemplificando: se um determinado atributo de qualidade de software for composto por dois outros atributos com graus de importncia diferentes entre si, para um determinado produto de software, e se um desses atributos tiver um grau de importncia baixo e o outro alto, isto significaria que eles contribuiriam em uma percentagem baixa e alta, respectivamente, para a composio do atributo agregado considerado. Atravs do procedimento (ii) acima, obter-se- para o atributo agregado um grau de importncia mdio. Portanto, o atributo agregado avaliado tem grau de importncia mdio, sendo composto por dois atributos, que possuem graus de importncia baixo e alto.
106
No entanto, se na anlise dos resultados, este processo de agregao no for conveniente, para o produto que est sendo avaliado, deve-se justificar o motivo da agregao no poder ser realizada com tal, relacionando-se apenas os graus de importncia de cada atributo, que seria agregado.
5.6 Calcular o grau do estado relativo de agregao: o grau do estado relativo
de agregao, GERA, de cada atributo agregado obtido pela mdia ponderada entre seus atributos constituintes: GERAi = ERAi
ERA
i =1
5.7 Calcular o coeficiente de consenso do atributo: o coeficiente de consenso
do atributo (CCAi), obtido para cada atributo, que compe o atributo que est sendo agregado, considerar tanto o GERAi, como tambm o peso Wi (item 5.1 (ii)) de cada um desses atributos. Caso no haja ainda um padro de qualidade (PQ) estabelecido, ou se esteja determinado PQ para o produto de software, que est sendo avaliado, ou para o seu domnio de aplicao, deve-se considerar Wi = 1, isto , CCAi = GERAi (item 5.6). CCAi =
GERAi Wi
(GERA W )
i =1 i i
5.8 Avaliar o atributo agregado: o resultado da avaliao de cada atributo de ~ qualidade agregado ser dado, tambm por N , que tambm um nmero
fuzzy, onde o produto algbrico fuzzy (KAUFMANN et al., 1991), formalizado por:
~ n ~ N = (CCAi N i )
i =1
EXEMPLO Etapa 5: Neste exemplo, sero apresentados os clculos da avaliao do subfator, Correo do Uso do Modelo, que um atributo agregado pertencente ao objetivo Confiabilidade da Representao, Apndice II. 5.1 Estabelecimento do padro de qualidade: por se tratar do
estabelecimento do padro de qualidade (PQ) para ERS, foram calculados

107
Captulo IV Modelo Fuzzy para Avaliao da Qualidade de Software ___________________________________________________________________________ os pesos Wi, isto , o grau de contribuio (mdia ponderada) de cada atributo, que compe o atributo agregado avaliado, conforme a Tabela V.6.
Critrios 1 2 3 4 Total 4 Nmeros Fuzzy a b m 2,55 3,55 3,99 2,40 3,40 3,95 2,86 3,86 4,00 2,06 3,06 3,82 rea Clculo de do peso W 0,717 0,2560 0,2449 0,775 0,2784 0,569 0,2207 0,880 Total 1,0000
Tabela IV.9: Critrios que compem o subfator Correo no Uso do Mtodo, com seus respectivos pesos W.
5.2 Clculo do grau de concordncia agregado: o clculo do grau de concordncia, C ( N i , N j ) , entre os atributos de qualidade, que esto sendo agregados, foi feito da mesma forma que no item 4.1. Neste caso, foi gerada uma nica matriz, por objetivo de qualidade, contendo as rea de interseo entre todos os seus critrios constituintes, Tabela IV.10, que servir como base na agregao dos subfatores, fatores e do prprio objetivo de qualidade. Para o subfator, dado como exemplo, sua rea total est na Tabela IV.9.
rea de Interseo entre os critrios Ci e Cj
Ci/ Cj Ci/C1 Ci/C2 Ci/C3 Ci/C4 Ci/C5 Ci/C6 Ci/C7 Ci/C8 Ci/C9 Ci/C10 Ci/C11 Ci/C12 Ci/C13 Ci/C14 Ci/C15 Ci/C16 Ci/C17 Ci/C18 Ci/C19 C1/ Cj 0,72 0,63 0,44 0,46 0,54 0,70 0,31 0,15 0,63 0,51 0,63 0,65 0,56 0,66 0,41 0,34 0,42 0,71 0,53 C2/ Cj 0,63 0,77 0,38 0,58 0,47 0,61 0,41 0,22 0,76 0,63 0,55 0,62 0,69 0,58 0,35 0,29 0,37 0,62 0,66 C3/ Cj 0,44 0,38 0,57 0,26 0,51 0,45 0,16 0,05 0,39 0,30 0,47 0,38 0,34 0,46 0,53 0,44 0,55 0,45 0,31 C4/ Cj 0,46 0,58 0,26 0,88 0,33 0,44 0,65 0,40 0,62 0,85 0,40 0,46 0,73 0,42 0,24 0,19 0,25 0,45 0,72 C5/ Cj 0,54 0,47 0,51 0,33 0,63 0,56 0,22 0,09 0,48 0,38 0,58 0,48 0,42 0,57 0,48 0,40 0,49 0,55 0,39 C6/ Cj 0,70 0,61 0,45 0,44 0,56 0,71 0,30 0,14 0,62 0,49 0,65 0,63 0,54 0,67 0,42 0,35 0,44 0,71 0,51 C7/ Cj 0,31 0,41 0,16 0,65 0,22 0,30 0,97 0,66 0,44 0,63 0,27 0,32 0,53 0,28 0,14 0,11 0,15 0,31 0,52 C8/ Cj 0,15 0,22 0,05 0,40 0,09 0,14 0,66 0,97 0,24 0,38 0,12 0,15 0,31 0,13 0,04 0,03 0,05 0,15 0,30 C9/ Cj 0,63 0,76 0,39 0,62 0,48 0,62 0,44 0,24 0,83 0,67 0,56 0,61 0,74 0,58 0,36 0,30 0,38 0,63 0,70 C10/ Cj 0,51 0,63 0,30 0,85 0,38 0,49 0,63 0,38 0,67 0,90 0,44 0,51 0,79 0,46 0,28 0,23 0,29 0,50 0,77 C11/ Cj 0,63 0,55 0,47 0,40 0,58 0,65 0,27 0,12 0,56 0,44 0,68 0,57 0,49 0,66 0,44 0,36 0,45 0,64 0,46 C12/ Cj 0,65 0,62 0,38 0,46 0,48 0,63 0,32 0,15 0,61 0,51 0,57 0,66 0,56 0,59 0,35 0,28 0,36 0,64 0,53 C13/ Cj 0,56 0,69 0,34 0,73 0,42 0,54 0,53 0,31 0,74 0,79 0,49 0,56 0,87 0,51 0,31 0,26 0,33 0,55 0,82 C14/ Cj 0,66 0,58 0,46 0,42 0,57 0,67 0,28 0,13 0,58 0,46 0,66 0,59 0,51 0,69 0,43 0,36 0,44 0,67 0,48 C15/ Cj 0,41 0,35 0,53 0,24 0,48 0,42 0,14 0,04 0,36 0,28 0,44 0,35 0,31 0,43 0,55 0,46 0,54 0,42 0,28 C16/ Cj 0,34 0,29 0,44 0,19 0,40 0,35 0,11 0,03 0,30 0,23 0,36 0,28 0,26 0,36 0,46 0,50 0,45 0,35 0,23 C17/ Cj 0,42 0,37 0,55 0,25 0,49 0,44 0,15 0,05 0,38 0,29 0,45 0,36 0,33 0,44 0,54 0,45 0,56 0,43 0,30 C18/ Cj 0,71 0,62 0,45 0,45 0,55 0,71 0,31 0,15 0,63 0,50 0,64 0,64 0,55 0,67 0,42 0,35 0,43 0,72 0,52 C19/ Cj 0,53 0,66 0,31 0,72 0,39 0,51 0,52 0,30 0,70 0,77 0,46 0,53 0,82 0,48 0,28 0,23 0,30 0,52 0,82
~ ~
Tabela IV.10: rea de interseo entre os critrios Ci e Cj do objetivo Confiabilidade da Representao 108
Captulo IV Modelo Fuzzy para Avaliao da Qualidade de Software ___________________________________________________________________________ 5.3 Construo da matriz de concordncia de agregao: calculados todos os graus de concordncia entre cada par de critrio Ci e Cj, foi construda a matriz de concordncia, MC, Tabela IV.11.
Ci/ Cj Ci/C1 Ci/C2 Ci/C3 Ci/C4 Ci/C5 Ci/C6 Ci/C7 Ci/C8 Ci/C9 Ci/C10 Ci/C11 Ci/C12 Ci/C13 Ci/C14 Ci/C15 Ci/C16 Ci/C17 Ci/C18 Ci/C19
Matriz de Concordncia (MC) C1/ C2/ C3/ C4/ C5/ C6/ C7/ C8/ C9/ C10/ C11/ C12/ C13/ C14/ C15/ C16/ C17/ C18/ C19/ Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj Cj
1,00 0,73 0,52 0,40 0,67 0,95 0,23 0,10 0,70 0,45 0,83 0,90 0,55 0,88 0,48 0,39 0,50 0,97 0,52 0,73 1,00 0,39 0,53 0,50 0,69 0,30 0,14 0,91 0,60 0,62 0,76 0,73 0,65 0,36 0,29 0,38 0,71 0,71 0,52 0,39 1,00 0,22 0,75 0,55 0,12 0,04 0,39 0,26 0,61 0,45 0,31 0,58 0,90 0,70 0,95 0,54 0,29 0,40 0,53 0,22 1,00 0,28 0,39 0,55 0,28 0,57 0,90 0,34 0,43 0,73 0,36 0,20 0,16 0,21 0,39 0,74 0,67 0,50 0,75 0,28 1,00 0,71 0,16 0,06 0,49 0,32 0,80 0,59 0,39 0,75 0,68 0,54 0,71 0,69 0,37 0,95 0,69 0,55 0,39 0,71 1,00 0,22 0,09 0,67 0,43 0,88 0,85 0,53 0,93 0,50 0,41 0,52 0,97 0,50 0,23 0,30 0,12 0,55 0,16 0,22 1,00 0,51 0,32 0,50 0,19 0,24 0,41 0,20 0,11 0,08 0,11 0,22 0,41 0,10 0,14 0,04 0,28 0,06 0,09 0,51 1,00 0,15 0,26 0,08 0,10 0,20 0,08 0,03 0,02 0,03 0,09 0,20 0,70 0,91 0,39 0,57 0,49 0,67 0,32 0,15 1,00 0,63 0,60 0,70 0,77 0,63 0,36 0,30 0,38 0,68 0,75 0,45 0,60 0,26 0,90 0,32 0,43 0,50 0,26 0,63 1,00 0,39 0,48 0,81 0,41 0,24 0,19 0,25 0,44 0,81 0,83 0,62 0,61 0,34 0,80 0,88 0,19 0,08 0,60 0,39 1,00 0,74 0,47 0,94 0,55 0,45 0,58 0,86 0,45 0,90 0,76 0,45 0,43 0,59 0,85 0,24 0,10 0,70 0,48 0,74 1,00 0,58 0,79 0,41 0,32 0,43 0,88 0,56 0,55 0,73 0,31 0,73 0,39 0,53 0,41 0,20 0,77 0,81 0,47 0,58 1,00 0,49 0,28 0,23 0,30 0,54 0,94 0,88 0,65 0,58 0,36 0,75 0,93 0,20 0,08 0,63 0,41 0,94 0,79 0,49 1,00 0,53 0,43 0,56 0,90 0,47 0,48 0,36 0,90 0,20 0,68 0,50 0,11 0,03 0,36 0,24 0,55 0,41 0,28 0,53 1,00 0,77 0,94 0,49 0,26 0,39 0,29 0,70 0,16 0,54 0,41 0,08 0,02 0,30 0,19 0,45 0,32 0,23 0,43 0,77 1,00 0,73 0,40 0,21 0,50 0,38 0,95 0,21 0,71 0,52 0,11 0,03 0,38 0,25 0,58 0,43 0,30 0,56 0,94 0,73 1,00 0,51 0,27 0,97 0,71 0,54 0,39 0,69 0,97 0,22 0,09 0,68 0,44 0,86 0,88 0,54 0,90 0,49 0,40 0,51 1,00 0,51 0,52 0,71 0,29 0,74 0,37 0,50 0,41 0,20 0,75 0,81 0,45 0,56 0,94 0,47 0,26 0,21 0,27 0,51 1,00
Tabela IV.11: Matriz de Concordncia entre os critrios Ci e Cj na avaliao dos atributos agregados: subfatores, fatores do objetivo Confiabilidade da Representao
Como todos os Cij 0, isto , h interseo entre os critrios i e j, no necessrio proceder-se ao clculo do grau da no concordncia, Cij , entre esses critrios. A no ocorrncia de Cij pode ser um forte indcio de que a rvore hierrquica dos atributos, que est sendo avaliada, esteja disposta coerentemente. 5.4 Construo da matriz do estado de agregao: neste experimento, a matriz do estado de agregao, MEA, a mesma da Tabela V.8, uma vez que no h Cij . 5.5 Clculo do estado relativo de agregao: como no h Cij , procede-se ao clculo de ERAi, apresentado na Tabela IV.12. 5.6 Clculo do grau do estado relativo de agregao: o grau do estado relativo de agregao, GERA, de cada atributo agregado obtido pela mdia ponderada entre seus critrios constituintes, como mostra a Tabela IV.12.
109

SUBFATOR: Correo no Uso do Mtodo f(x)R = ax + b Critrios ERAi GERAi CCAi f(x)L = ax + b aL bL aR bR 0,7004 0,2672 0,2672 1,00 -2,55 -2,31 9,20 1 7,19 0,7018 0,2678 0,2678 1,00 -2,40 -1,82 2 29,13 0,6073 0,2317 0,2317 1,00 -2,86 -7,28 3 5,03 0,6115 0,2333 0,2333 1,00 -2,06 -1,31 4 Total Total Prod. Total 4 2,6209 1,0000 1,0000 Tabela IV.12: Estado relativo de agregao, grau do estado relativo de agregao, coeficiente de consenso do atributo, e os argumentos a e b das funes lineares dos critrios, que participaram do processo de agregao.
5.7 Clculo do coeficiente de consenso do atributo: o coeficiente de consenso do atributo, obtido para cada atributo (critrio) i (CCAi), que compe o atributo que est sendo agregado, considerou apenas o valor de GERAi, porque se est estabelecendo o padro de qualidade para ERS. Neste caso, Wi = 1 e, portanto, CCAi = GERAi (item 5.6 anterior). 5.8 Avaliao do atributo agregado: o resultado da avaliao do Subfator Correo do Uso do Mtodo, tambm ser um nmero fuzzy N , e segue os mesmos procedimentos de clculo do item 4.6, sendo dado por: = (2,47; 3,47; 3,94)
IV.3.1 Caractersticas do Modelo Fuzzy para Avaliao da Qualidade de Software

O Modelo fuzzy para avaliao da qualidade de software, proposto neste captulo, possui algumas caractersticas relevantes: i. Preservao da concordncia (HSU et al., 1996, BARDOSSY et al., 1993): se todas as estimativas forem idnticas, a combinao resultante ser a estimativa comum entre elas, isto , se i = j para todo i, j, ento = i. Prova: tomando-se o item 5.8 (Etapa 5)
~ n ~ N = (CCAi N i )
i =1
110
~ ~ n N = N i (CCAi )
i =1
Como
~ ~ =N (CCA ) = 1, ento, N
i =1 i
ii. Independncia da ordem de combinao (BARDOSSY et al., 1993): o resultado da agregao no depende da ordem da combinao das opinies individuais. Se {(1), (2), ..., (n)} uma permutao de {1, 2, ..., 3}, ento = f(1, 2, ..., n) = f((1), (2), ..., (n)) iii. Influncia do grau de concordncia e do peso do especialista: se a estimativa de um especialista se distancia da estimativas dos demais (pequeno ndice de concordncia), e/ou o peso do perfil desse especialista inferior aos dos demais, ento sua estimativa ter uma importncia reduzida, no processo de avaliao. iv. Preservao do nmero fuzzy: se as opinies de todos os especialistas podem ser representadas por um nmero fuzzy triangular normal positivo, ento a funo de pertinncia da combinao tambm um nmero fuzzy triangular normal positivo. Baseando-se nos resultados obtidos deste modelo fuzzy para avaliao da qualidade de software, pode-se obter ndices de qualidade, na avaliao de novos produtos de software, de acordo com um padro de qualidade estabelecido.
111
IV.4 Definio de ndices de Qualidade de Software

Se houver um padro de qualidade (PQ), j definido por este modelo ou por um outro compatvel, para o produto de software, que est sendo avaliado ou seu domnio de aplicao, pode-se comparar os resultados obtidos pela aplicao do modelo fuzzy proposto com esse padro estabelecido. Com isto, obtm-se um ndice de qualidade, que indicar se o produto de software avaliado est ou no dentro do padro de qualidade desejado, e em que percentagem. Neste contexto, pode-se determinar o ndice de qualidade do produto avaliado, atravs dos seguintes procedimentos: 1. Redefinio da funo caracterstica do atributo de qualidade: redefinir a funo fuzzy de cada atributo de qualidade do tipo i = (ai, mi, bi), obtida na definio do padro de qualidade, para a funo fuzzy do padro de qualidade, ~ Qi = (ai, mi, mi , bi), isto , um nmero fuzzy normal trapezoidal. O mapeamento ~ ~ de i para Qi resultar, ento, na funo Qi = (ai, mi, bn, bn), onde n o limite superior do conjunto referencial j definido. Esse mapeamento possvel, porque pode-se considerar que qualquer valor acima do padro de qualidade ( direita da funo caracterstica), tambm de qualidade e, portanto, plenamente aceitvel. 2. Clculo do ndice de qualidade: o ndice de qualidade, qk, de cada atributo k, que est sendo avaliado, ser formalizado por:
qk =
( min{ ( x ), ( x )}) dx ( ( x ))dx

x ~ Qi ~ Nk x ~ Nk
Uma vez que q [0, 1], quando q = 1, isto significa que o atributo avaliado atinge totalmente o padro de qualidade; se q = 0, ento o atributo avaliado est totalmente fora do padro de qualidade; se 0 q 1, o atributo est dentro do padro de qualidade, na proporo do valor de q, isto , o atributo avaliado q % do padro de qualidade.
112
No clculo do ndice de qualidade para atributos agregados, se algum de seus atributos constituintes tiver q = 1, considerar, neste caso, o valor do padro de qualidade (PQ) desse atributo constituinte.
IV.5 Concluso
Neste captulo, foi definido um modelo fuzzy para avaliao da qualidade de software, a partir do Modelo Rocha. Com a extenso do Modelo Rocha, o ganho mais significativo foi realizar a agregao de atributos de qualidade de software, atravs de conceitos e propriedades da teoria fuzzy. Com isto, esse modelo foi provido de uma fundamentao matemtica, para o tratamento de suas medidas subjetivas. No captulo a seguir, mostrar-se- os resultados de uma experincia de uso do modelo fuzzy proposto, realizada com o objetivo de valid-lo.
113
Captulo V UMA EXPERINCIA DE UTILIZAO DO MODELO FUZZY

No captulo anterior, foi definido o modelo fuzzy para avaliao da qualidade de software, sendo exemplificada cada uma de suas cinco etapa. Neste captulo, descrita a experincia completa de sua utilizao com especificaes de requisitos de software (ERS), realizada com o objetivo de valid-lo. Um atributo de qualidade de software pode ser avaliado, segundo sua funo caracterstica, com mostrado a seguir.
V.1 Avaliao dos Atributos de Qualidade

Cada atributo de qualidade de software avaliado pode ser representado por sua funo de pertinncia (caracterstica) correspondente, como, por exemplo, o critrio Correo da Notao, exemplificado no Captulo anterior, e mostrado na Figura V.1.
1 0,8 0,6 0,4 0,2 0 0 1 2 3 4 Figura V.1: Critrio Correo da Notao NR PR R MR I
De acordo com a Figura V.1, pode-se obter as equaes Eq. V.1 do atributo de qualidade avaliado, que tambm um nmero fuzzy do tipo = (a, m, b), atravs da seguinte frmula:
113
Captulo V
Uma Experincia de Utilizao do Modelo Fuzzy
____________________________________________________________________________________ _
1 1 a , a x b x m a m a fN ~ ( x) = 1 1 x , m x b b b m b m
(Eq. V.1)
Assim sendo, o critrio Correo da Notao tem a seguinte funo de pertinncia:

x 1, 2,55 x 3,55 fN ~ (x) = 9,068 0,44 x , 3,55 x 3,99
O valor de m = 3,55 do critrio avaliado, que corresponde ao valor de qualidade desejvel desse critrio (na matemtica clssica), pode ser utilizado nas equaes dos termos lingsticos MR (muito relevante) e I (imprescindvel), conforme Seo IV.2, uma vez que este valor pertence ao intervalo de abrangncia de cada uma dessas funes: [3, 4]. Assim sendo: Para MR: f(x) = 4 - x; para 3 x 4 = 4 - 3,55 = 0,45 Para I: f(x) = x - 3; para 3 x 4 = 3,55 - 3 = 0,55 Pode-se, ento, fazer as seguintes dedues a respeito do critrio Correo da Notao, para especificaes de requisitos de software em geral: i. Na linguagem matemtica clssica, considerando-se a escala numrica de 0 a 4, previamente estabelecida, Tabela IV.3, o padro de qualidade do critrio avaliado encontra-se no intervalo de [2,55; 3,99] e o seu valor de qualidade desejvel 3,55. ii. Na linguagem da teoria fuzzy, o padro de qualidade do critrio avaliado o nmero fuzzy = (2,55; 3,55; 3,99), cuja funo de pertinncia est na Figura V.1 e o seu valor de qualidade desejvel 45% muito relevante e 55% imprescindvel. A seguir, sero mostrados todos os experimentos realizados, atravs do modelo fuzzy, para ERS, com o objetivo de valid-lo.
V.2 Uma Experincia com o Modelo Fuzzy
114
Captulo V
____________________________________________________________________________________ _
Considerando-se as situaes previstas para a utilizao do modelo fuzzy, descritas na Seo IV.3, foram objeto do experimento as seguintes:
Determinao do Padro de Qualidade (PQ) de um produto de software. Um

conjunto de 16 especialistas, em engenharia de software, avaliou um conjunto de atributos de qualidade, identificados para especificaes de requisitos de software (ERS). A definio desses atributos, cuja lista est no Apndice II, e a pesquisa de campo correspondente foram realizadas por CLUNIE (1997). O objetivo era obter de cada especialista o grau de importncia de cada um dos atributos avaliados, para que uma especificao de requisitos fosse considerada de qualidade, isto , o padro de qualidade que uma especificao de requisitos deveria apresentar.
A avaliao da qualidade de um produto de software, apoiada em um PQ j

previamente definido. Um grupo de 3 especialistas avaliou a modelagem de dados do mdulo financeiro do Sistema SIGAH-Multimdia, um sistema de informao hospitalar em desenvolvimento, na Unidade de Cardiologia e Cirurgia Cardiovascular do Hospital Universitrio da UFBA / Fundao Bahiana de Cardiologia (UCCV/FBC), com a colaborao da rea de Engenharia de Software da COPPE/UFRJ. Nesta avaliao, foi considerado um subconjunto dos atributos de qualidade de ERS, relacionados no Apndice IV. Os resultados destes julgamento foram confrontados com o PQ, estabelecido para ERS, obtidos no item anterior. Desta forma, foram gerados ndices de qualidade, para cada atributo avaliado, chegando-se medio da qualidade do modelo de dados, um subproduto da ERS. A seguir, sero descritos os resultados das duas situaes expostas acima.
V.2.1 Determinao do Padro de Qualidade para ERS

A determinao do padro de qualidade (PQ) para especificaes de requisitos de software segue as etapas do modelo fuzzy para avaliao da qualidade de software (MFAQS), Seo IV.3, segundo a notao utilizada no Modelo Rocha Estendido, Seo IV.1. Foram analisados todos os critrios, subfatores e fatores para cada um dos trs objetivos de qualidade, apresentados no Apndice II, para ERS em geral. A Tabela V.1 apresenta os resultados obtidos, atravs da aplicao do MFAQS, para o objetivo da Confiabilidade da Representao de especificaes de requisitos de
115
Captulo V
____________________________________________________________________________________ _
software, incluindo os pesos correspondentes para cada um desses critrios na agregao de subfatores (WSUB), de fatores (WFAT) e do prprio objetivo de qualidade (WOBJ).
116
Captulo V
____________________________________________________________________________________ _
ATRIBUTOS DE QUALIDADE DE SOFTWARE OBJETIVO:CONFIABILIDADE DA REPRESENTAO FATOR: COMUNICABILIDADE (COB) Subfator: Correo no Uso do Mtodo (CUM) Correo da Notao (CNT) Correo Sinttica (CST) Correo Semntica (CSM) Correo no Uso do Formato de Document. (CFD) Subfator: Uniformidade de Terminologia (UTE) Uniformidade de Termos (UTT) Uniformidade de Notao (UNT) Subfator:Uniformidade no Nvel deAbstrao(UNA) Uniformidade de Detalhes daDocumentao(UDD) Independncia de Detalhes do Projeto (IDP) Subfator: Modularidade da Documentao (MDO) Coeso de Informaes (COI) Acoplamento entre as Sees (ACS) Estrutura da Documentao (EDO) Subfator: Conciso (COC) Complementabilidade (COM) Subfator: Conformidade (COF) Aderncia s Normas Org. Desenvolvedora (ANO) Aderncia s Normas estab. p/ Contratante (ANC) FATOR: MANIPULABILIDADE (MAP) Subfator: Disponibilidade (DIS) Acessibilidade (ACE) Estar Atualizada (ETA) Subfator: Rastreabilidade (RAS) Organizao da Documentao (ORD) Localizabilidade Interna (LOI) Localizabilidade Externa (LOE) PQ para ERS (2,48; 3,48; 3,93) (2,39; 3,39; 3,91) (2,47; 3,47; 3,94) (2,55; 3,55; 3,99) (2,40; 3,40; 3,95) (2,86; 3,86; 4,00) (2,06; 3,06; 3,82) (2,66; 3,66; 4,00) (2,74; 3,74; 4,00) (2,57; 3,57; 4,00) (1,55; 2,55; 3,48) (1,72; 2,72; 3,65) (1,37; 2,37; 3,31) (2,36; 3,36; 3,97) (2,35; 3,35; 4,00) (2,10; 3,10; 3,91) (2,64; 3,64; 3,99) (2,55; 3,55; 3,86) (2,55; 3,55; 3,86) (2,41; 3,41; 3,97) (2,22; 3,22; 3,95) (2,61; 3,61; 3,99) (2,75; 3,75; 3,98) (2,95; 3,95; 4,00) (2,90; 3,90; 4,00) (3,00; 4,00; 4,00) (2,56; 3,56; 3,96) (2,88; 3,88; 4,00) (2,56; 3,56; 4,00) (2,23; 3,23; 3,87)
WSUB WFAT WOBJ
0,2560 0,2449 0,2784 0,2207
0,0760 0,0727 0,0826 0,0655
0,0544 0,0520 0,0591 0,0469
0,5114 0,4886 0,5336 0,4664 0,3321 0,3071 0,3608 1,0000 0,4709 0,5291
0,0800 0,0765 0,0581 0,0508 0,0717 0,0662 0,0778 0,0759 0,0688 0,0773
0,0573 0,0547 0,0416 0,0364 0,0513 0,0474 0,0557 0,0543 0,0492 0,0553
0,4940 0,5060 0,3638 0,3336 0,3025
0,2102 0,2153 0,2090 0,1917 0,1738
0,0598 0,0612 0,0595 0,0545 0,0494
Tabela V.1: Avaliao do objetivo Confiabilidade da Representao de ERS, atravs de nmeros fuzzy.
Com base nos dados da tabela acima, foi elaborada a Figura V.2, que apresenta os resultados defuzificados, isto , o valor de m do nmero fuzzy = (a, m, b) deste objetivo de qualidade, em ordem descendente do grau de relevncia de seus critrios constituintes, para ERS em geral.
117
Captulo V
____________________________________________________________________________________ _
4,00 3,50 3,00 2,50 2,00 1,50 1,00 0,50 0,00
Figura V.2: Hierarquizao dos critrios do objetivo Confiabilidade da Representao para ERS
Observa-se que 89% dos critrios desse objetivo esto entre MI (muito importante) e I (imprescindvel), segundo o conjunto de termos lingsticos da Tabela IV.3. Como est evidenciado no grfico acima, os critrios Estar Atualizada (ETA) e Acessibilidade (ACE) possuem os graus de relevncia mais altos. Segundo CLUNIE (1997), esta tendncia pode ser entendida pela preocupao de se ter uma especificao que possa ser facilmente manuseada por seus diversos usurios e na verso atualizada, ao longo do processo de desenvolvimento, devendo ainda atender s necessidades de manuteno. Os critrios Uniformidade de Detalhes da Documentao (UDD) e Independncia de Detalhes de Projeto (IDP) so os que apresentaram graus de relevncia mais baixos. Isto pode ser explicado porque, na elaborao de uma especificao de requisitos de software, geralmente, muitas questes ainda no se encontram bem definidas, nem completamente entendidas. Assim sendo, neste contexto, esses dois critrios no se tornam to importantes quanto os outros. A Tabela V.2 apresenta os dados obtidos, atravs da aplicao do MFAQS, para o objetivo da Confiabilidade Conceitual de especificaes de requisitos de software, incluindo os pesos correspondentes a cada um desses critrios na agregao de subfatores (WSUB), de fatores (WFAT) e do prprio objetivo de qualidade (WOBJ).
ATRIBUTOS DE QUALIDADE DE SOFTWARE OBJETIVO: CONFIABILIDADE CONCEITUAL FATOR: FIDEDIGNIDADE (FID) Subfator: Consistncia (CON) Consistncia Interna (COI) Consistncia Externa (COE) Subfator: No Ambigidade (NAB) PQ para ERS (2,49; 3,49; 3,90 (2,69; 3,69; 3,97) (2,67; 3,67; 3,94) (2,89; 3,89; 4,00) (2,45; 3,45; 3,88) (2,70; 3,70; 3,99)
WSUB WFAT WOBJ
0,5303 0,4697
0,2640 0,2338
0,1257 0,1113
118
Captulo V
____________________________________________________________________________________ _
Ser Explcita EXP) Preciso (PRC) FATOR: SUFICINCIA (SUF) Subfator: Necessidade (NEC) Necessidade dos Requisitos (NRQ) Subfator: No Redundncia (NRD) No Redundncia de Informaes (NRI) Subfator: Completitude (COP) Completitude Relao Roteiro def. p/ Org. (CRO) Completitude c/Relao Mtodo Desenv(CMM) Completitude com Relao aos Requisitos(COR) (2,81; 3,81; 3,99) (2,60; 3,60; 3,99) (2,23; 3,23; 3,81) (2,92; 3,92; 4,00) (2,92; 3,92; 4,00) (1,84; 2,84; 3,61) (1,84; 2,84; 3,61) (2,18; 3,18; 3,83) (2,28; 3,28; 3,89) (1,63; 2,63; 3,58) (2,57; 3,57; 4,00) 0,5143 0,4857 0,2583 0,2439 0,1230 0,1161
1,0000 1,0000 0,3462 0,2775 0,3763
0,2412 0,1746 0,2022 0,1621 0,2199
0,1264 0,0915 0,1060 0,0849 0,1152
Tabela V.2: Avaliao do Objetivo Confiabilidade Conceitual de ERS, atravs de nmeros fuzzy.
Com base nos dados da tabela acima, a Figura V.3 mostra, tambm, os resultados defuzificados em ordem descendente do grau de relevncia dos critrios do objetivo confiabilidade conceitual, para ERS em geral.
Figura V.3: Hierarquizao dos critrios do objetivo Confiabilidade Conceitual para ERS
Um ndice de 77% dos critrios pertencentes a este objetivo de qualidade, tambm, esto no intervalo de muito importante a imprescindvel, enfatizando o quo importante o entendimento, a consistncia e a completitude conceitual da especificao. Se uma especificao no precisa, e devidamente definida, por certo no atender, plenamente, s necessidades e reivindicaes de seus usurios. O critrio mais relevante, neste grupo, Necessidade dos Requisitos (NRQ). Assim sendo, extremamente necessrio que os requisitos considerados imprescindveis ao produto sejam descritos, pois, sem eles, a especificao perde o sentido.
119
CMM
PRC
EXP
COR
NRQ
COE
COI
CRO
NRI
4 3,5 3 2,5 2 1,5 1 0,5 0
Captulo V
____________________________________________________________________________________ _
O critrio, que vem logo a seguir em grau de importncia, a Consistncia Interna (COI), uma vez que de vital para a consecuo acurada de uma especificao de requisitos, que no existam conflitos entre partes da mesma. J os critrios No Redundncia de Informaes (NRI) e Completitude com Relao ao Mtodo de Desenvolvimento (CMM) foram consideram de menor monta. Isto pode ser atribudo ao fato de que, durante os procedimentos de elaborao de uma ERS, ainda no h consenso e um direcionamento bem definido sobre muitos aspectos conceituais. Portanto, algumas questes podem se repetir, at mesmo para serem melhor elucidadas. Por este mesmo motivo, pode-se no se ter ainda todas as informaes requeridas por um mtodo de desenvolvimento. A Tabela V.3 mostra os dados obtidos, atravs da aplicao do MFAQS, para o objetivo Utilizabilidade de especificaes de requisitos de software, considerando, tambm, os pesos correspondentes a cada de seus critrios na agregao de subfatores (WSUB), de fatores (WFAT) e do prprio objetivo de qualidade (WOBJ).
ATRIBUTOS DE QUALIDADE DE SOFTWARE OBJETIVO: UTILIZABILIDADE FATOR: AVALIABILIDADE (AVA) Subfator: Verificabilidade (VER) Subfator: Validabilidade (VAL) FATOR: MANUTENIBILIDADE (MAT) Subfator: Modificabilidade (MOD) Subfator: Evolutibilidade (EVO) FATOR: REUTILIZABILIDADE (REU) Subfator: Adaptabilidade (ADA) Subfator: Generalidade (GEN) FATOR: IMPLEMENTABILIDADE (IMP) Subfator: Viabilidade Econmica (VEC) Aceitabilidade de Custos (ACC) Relevncia dos Benefcios (REB) Compatibilidade Custo/Benefcio (CCB) Subfator: Viabilidade Financeira (VFI) Existncia de Capital (ECT) Disponibilidade de Capital (DCT) Subfator: Viabilidade Tecnolgica (VTE) Existncia da Tecnologia (ETE) Disponibilidade da Tecnologia (DTE) Subfator: Viabilidade de Mo de Obra (VMO) Existncia de Mo de Obra (EMO) Disponibilidade de Mo de Obra (DMO) Subfator: Viabilidade de Cronograma (VCR) Adequabilidade de Cronograma (ACR) Flexibilidade de Cronograma (FCR) Subfator: Viabilidade Social (VSO) Aceitabilidade da Engenharia Humana (AEH) Aceitabilidade dos Impactos Sociais (AIS) PQ para ERS -- (2,51; 3,51; 3,93) ---- (2,51; 3,51; 3,92) ---- (2,60; 3,60; 3,98) ---- (2,74; 3,74; 3,97) (2,82; 3,82; 4,00) (2,80; 3,80; 3,99) (2,90; 3,90; 4,00) (2,75; 3,75; 4,00) (2,96; 3,96; 4,00) (2,99; 3,99; 4,00) (2,93; 3,93; 4,00) (2,89; 3,89; 4,00) (2,96; 3,96; 4,00) (2,82; 3,82; 4,00) (2,66; 3,66; 3,96) (2,63; 3,63; 3,99) (2,69; 3,69; 3,94) (2,71; 3,71; 4,00) (2,60; 3,60; 4,00) (2,83; 3,83; 4,00) (2,06; 3,06; 3,79) (1,91; 2,91; 3,69) (2,22; 3,22; 3,89)
WSUB WFAT WOBJ
0,3319 0,3408 0,3273 0,5039 0,4961 0,5094 0,4906 0,4961 0,5039 0,4845 0,5155 0,4743 0,5257
0,0792 0,0813 0,0781 0,0831 0,0818 0,0825 0,0795 0,0756 0,0768 0,0749 0,0797 0,0605 0,0671
120
Captulo V
____________________________________________________________________________________ _
Tabela V.3: Avaliao do objetivo Utilizabilidade de ERS, atravs de nmeros fuzzy.
A Figura V.4 apresenta a hierarquizao dos critrios que fazem parte apenas do fator Implementabilidade. Os outros fatores desse objetivo, segundo CLUNIE (1997) esto relacionados a critrios dos objetivos Confiabilidade da Representao e Confiabilidade Conceitual, que foram analisados anteriormente.
4,00 3,50 3,00 2,50 2,00 1,50 1,00 0,50 0,00
ECT
ETE
DMO
EMO
REB
FCR
DCT
DTE
CCB
ACC
ACR
AEH
Figura V.4: Hierarquizao dos critrios do objetivo Utilizabilidade para ERS.
Novamente, a grande maioria dos critrios desse objetivo de qualidade se inserem no intervalo muito importante e imprescindvel (cerca de 92%). Os atributos de qualidade Existncia de Capital (ECT) e Existncia de Tecnologia (ETE) so os mais importantes neste grupo. Realmente, se no existirem recursos pecunirios e tecnolgicos para a implementao de uma ERS, por certo ela no ser vivel. Os critrios Aceitabilidade dos Impactos Sociais (AIS) e Aceitabilidade da engenharia humana (AEH) foram os que tiveram a menor relevncia, entre os avaliadores. Como esta pesquisa de campo foi realizada com um grupo de especialistas, essencialmente tcnico, provavelmente os possveis impactos sociais decorrente do desenvolvimento de uma ERS foram, por eles, visualizados de forma secundria. O critrio AEH diz respeito ao grau de satisfao e ao desenvolvimento do potencial humano dos usurios. provvel que este baixo escore reflita ainda o tradicional conflito entre usurios e especialistas em computao (BELCHIOR, 1994, FREEDMAN, 1993). MUMFORD (1972) j alertava para a excepcional falta de contato entre os especialistas de computador e os usurios finais, que possuem deficincias alarmantes no somente em consultas mas em relao comunicao.
121
AIS
Captulo V
____________________________________________________________________________________ _
A Figura V.5 mostra a disposio dos subfatores de qualidade avaliados para ERS, tambm, em ordem decrescente do grau de importncia. Os subfatores so atributos agregados de qualidade, compostos por um conjunto de critrios, segundo o Modelo Rocha estendido.
4 3,5 3 2,5 2 1,5 1 0,5 0
Figura V.5: Hierarquizao dos subfatores de qualidade de ERS
Dentre os subfatores avaliados, a Viabilidade Financeira (VFI), a Disponibilidade (DIS) e Necessidade (NEC) foram, respectivamente, os mais relevantes, o que condiz com a avaliao dos critrios a eles pertinentes. Sem sombra de dvidas, o desenvolvimento de um ERS sem a existncia e a disponibilidade de um suporte financeiro para este fim, dificilmente ter algum xito. Uma vez atendido a este pre-requisito, uma ERS no atualizada e de difcil acesso impactar, diretamente e de forma negativa, no desenvolvimento do prprio produto. Mesmo que uma ERS atenda convenientemente aos dois subfatores anteriores, mas seus requisitos tidos como imprescindveis no forem estabelecidos devidamente, estar fadada ao insucesso. Os subfatores de menor relevncia, neste grupo, so, respectivamente, Uniformidade de Abstrao, No Redundncia e Viabilidade Social, o que condiz com a avaliao de seus respectivos critrios de qualidade. A Figura V.6 apresenta a agregao dos subfatores de qualidade avaliados para ERS, em ordem decrescente de seu grau de relevncia. Os fatores que mais se destacaram foram a Manipulabilidade (MAP), Implementabilidade (IMP) e Fidedignidade (FID).
122
Captulo V
____________________________________________________________________________________ _
4 3,5 3 2,5 2 1,5 1 0,5 0
IMP
FID
MAT
MAP
Figura V .6: H ierarquizao dos fatores qualidade de E R S
COB
REU
AVA
de
Portanto, deve-se procurar desenvolver especificaes de requisitos que sejam facilmente manipulveis, para diversas formas de uso, isto , estejam disponveis para seus usurios em sua verso mais atualizada e cujo contedo possa ser rastreado sem muito custo ou esforo, desde sua viso mais global at a mais detalhada e vice-versa. O fator Implementabilidade (IMP) veio em segundo lugar em grau de importncia, embora possua o subfator Viabilidade Financeira (VFI), avaliado como o mais relevante entre todos os subfatores. Esse fator, tambm, contm o subfator Viabilidade Social (VSO), avaliado com sendo de pouca relevncia. Neste sentido pode-se fazer algumas ponderaes: i. O subfator Viabilidade Social deveria, realmente, compor o ramo da rvore hierrquica de qualidade do fator Implementabilidade? ii. O processo de avaliao dos atributos agregados deveria simplesmente assumir o valor de seu atributo constituinte de maior importncia, para ressaltar o grau de qualidade deste? Ou deveria assumir o grau de seu atributo de menor importncia, considerado como o elo mais frgil da corrente (do grupo)? O processo de avaliao dos atributos agregados, utilizado pelo MFAQS, leva em considerao todos os graus de importncia de cada atributo, que compe o ramo da rvore hierrquica, que est sendo agregado. O resultado desta agregao tende sempre (pela estrutura do prprio modelo - quinta etapa, captulo IV) para o maior grau de concordncia entre os atributos da composio, como tambm considera o peso relativo de cada um deles, segundo o padro de qualidade apurado, se for o caso.
V.2.2 Avaliao de uma ERS

123
SUF
Captulo V
____________________________________________________________________________________ _
Na seo anterior, foi estabelecido um padro de qualidade (PQ) para ERS em geral, atravs do MFAQS proposto. Atravs deste padro, pode obter-se ndices de qualidade (Seo IV.4), para a avaliao de especificaes, o que indicar se ela est ou no dentro do PQ estabelecido. Foi avaliada a Modelagem de dados, subproduto da Especificao de Requisitos do Mdulo Financeiro do sistema SIGAH-Multimdia, da UCCV/FBC. A avaliao realizada por 3 especialistas, que no participaram de sua confeco, baseados em uma cpia da mesma, fornecida a cada um deles. A tcnica de avaliao utilizada foi inspeo individual. O perfil de cada especialista avaliador est na Tabela V.4, que retrata a apurao dos resultado do QIPE (Questionrio de Identificao do Perfil do Especialista).
Apurao dos Resultados do QIPE
Ei / item 1 2 3 Total 3 i1 i2 i3 i4 i5 i6 i7 tQIPE pEi 2,80 1,30 2,40 0,30 0,70 0,80 5,90 4,177 0,260 2,70 6,00 2,50 0,70 1,00 0,80 9,00 5,990 0,373 3,10 3,00 3,90 0,70 0,90 0,80 9,20 5,900 0,367 Total Total 16,067 1,000
Tabela V.4.: Resultados do QIPE para ERS real
O conjunto de termos lingsticos utilizados nesta avaliao est descrito no questionrio CAERS, Apndice IV, e possui uma relao direta com os termos lingsticos, estabelecidos no levantamento do padro de qualidade (PQ), com mostrado na Tabela V.5 abaixo.
Grau de importncia 0,0 1,0 2,0 3,0 4,0 Termo Lingstico do PQ Nenhuma Relevncia Pouca Relevncia Relevante Muito Relevante Imprescindvel Termo Lingstico da CAERS Total Ausncia Baixa Presena Moderada Presena Alta Presena Total presena Nmero fuzzy normal
~ N 1 = (0,0; 0,0; 1,0) ~ N 2 = (0,0; 1,0; 2,0) ~ N 3 = (1,0; 2,0; 3,0) ~ N 4 = (2,0; 3,0; 4,0) ~ N 5 = (3,0; 4,0; 4,0)
Tabela V.5: Relao entre os nmeros fuzzy normais do PQ e da CAERS
Na avaliao, foi considerado um subconjunto dos atributos de qualidade de ERS, pertinente ao subproduto sob avaliao. Este subconjunto, pode ser identificado nas Tabelas V.6 e V.7.
124
Captulo V
____________________________________________________________________________________ _
Os resultados dessa avaliao e seus respectivos ndices de qualidade (IQ), tambm so exibidos nas Tabelas V.6 e V.7.
ATRIBUTOS DE QUALIDADE DE SOFTWARE OBJETIVO:CONFIABILIDADE DA REPRESENTAO FATOR: COMUNICABILIDADE (COB) Subfator: Correo no Uso do Mtodo (CUM) Correo da Notao (CNT) Correo Sinttica (CST) Correo Semntica (CSM) Correo no Uso do Formato de Document. (CFD) Subfator: Uniformidade de Terminologia (UTE) Uniformidade de Termos (UTT) Uniformidade de Notao (UNT) Subfator:Uniformidade no Nvel deAbstrao(UNA) Uniformidade de Detalhes daDocumentao(UDD) Independncia de Detalhes do Projeto (IDP) Subfator: Modularidade da Documentao (MDO) Coeso de Informaes (COI) Acoplamento entre as Sees (ACS) Estrutura da Documentao (EDO) Subfator: Conciso (COC) Complementabilidade (COM) Subfator: Conformidade (COF) Aderncia s Normas Org. Desenvolvedora (ANO) Aderncia s Normas estab. p/ Contratante (ANC) FATOR: MANIPULABILIDADE (MAP) Subfator: Disponibilidade (DIS) Acessibilidade (ACE) Estar Atualizada (ETA) Subfator: Rastreabilidade (RAS) Organizao da Documentao (ORD) Localizabilidade Interna (LOI) Localizabilidade Externa (LOE) PQ para ERS (2,48; 3,48; 3,93) (2,39; 3,39; 3,91) (2,47; 3,47; 3,94) (2,55; 3,55; 3,99) (2,40; 3,40; 3,95) (2,86; 3,86; 4,00) (2,06; 3,06; 3,82) (2,66; 3,66; 4,00) (2,74; 3,74; 4,00) (2,57; 3,57; 4,00) (1,55; 2,55; 3,48) (1,72; 2,72; 3,65) (1,37; 2,37; 3,31) (2,36; 3,36; 3,97) (2,35; 3,35; 4,00) (2,10; 3,10; 3,91) (2,64; 3,64; 3,99) (2,55; 3,55; 3,86) (2,55; 3,55; 3,86) (2,41; 3,41; 3,97) (2,22; 3,22; 3,95) (2,61; 3,61; 3,99) (2,75; 3,75; 3,98) (2,95; 3,95; 4,00) (2,90; 3,90; 4,00) (3,00; 4,00; 4,00) (2,56; 3,56; 3,96) (2,88; 3,88; 4,00) (2,56; 3,56; 4,00) (2,23; 3,23; 3,87) ERS ---- (3,00; 4,00; 4,00) (3,00; 3,00; 4,00) (3,00; 3,00; 4,00) (3,00; 4,00; 4,00) (3,00; 4,00; 4,00) (2,17; 3,17; 3,75) (2,17; 3,17; 3,51) (2,17; 3,17; 4,00) (2,47; 3,47; 4,00) (2,00; 3,00; 4,00) (3,00; 4,00; 4,00) -------- (1,65; 2,65; 3,27) (1,65; 2,65; 3,27) -------- (2,48; 3,48; 3,93) (2,32; 3,32; 3,66) (1,04; 2,04; 2,70) ---- (0,00; 1,00; 1,00) ---
IQ
1,000 1,000 1,000 1,000 1,000 0,477 0,328 0,607 1,000 1,000 1,000
0,199 0,199
0,000 0,000
0,000
Tabela V.6: Resultados da avaliao para o objetivo Confiabilidade da Representao

ATRIBUTOS DE QUALIDADE DE SOFTWARE OBJETIVO: CONFIABILIDADE CONCEITUAL FATOR: FIDEDIGNIDADE (FID) Subfator: Consistncia (CON) Consistncia Interna (COI) Consistncia Externa (COE) Subfator: No Ambigidade (NAB) Ser Explcita EXP) Preciso (PRC) FATOR: SUFICINCIA (SUF) Subfator: Necessidade (NEC) Necessidade dos Requisitos (NRQ) Subfator: No Redundncia (NRD) No Redundncia de Informaes (NRI) Subfator: Completitude (COP) Completitude Relao Roteiro def. p/ Org. (CRO) Completitude c/Relao Mtodo PQ para ERS (2,49; 3,49; 3,90 (2,69; 3,69; 3,97) (2,67; 3,67; 3,94) (2,89; 3,89; 4,00) (2,45; 3,45; 3,88) (2,70; 3,70; 3,99) (2,81; 3,81; 3,99) (2,60; 3,60; 3,99) (2,23; 3,23; 3,81) (2,92; 3,92; 4,00) (2,92; 3,92; 4,00) (1,84; 2,84; 3,61) (1,84; 2,84; 3,61) (2,18; 3,18; 3,83) (2,28; 3,28; 3,89) (1,63; 2,63; 3,58) ERS ---- (2,90; 3,90; 4,00 (2,82; 3,82; 4,00 (3,00; 4,00; 4,00 (2,71; 3,71; 4,00 (3,00; 4,00; 4,00 (2,40; 3,40; 4,00 (2,88; 3,88; 4,00 (3,00; 4,00; 4,00 (3,00; 4,00; 4,00 (2,82; 3,82; 4,00 (2,82; 3,82; 4,00 ---- (2,00; 3,00; 4,00
IQ
0,961 0,876 1,000 0,871 1,000 0,770 1,000 1,000 1,000 1,000 1,000
1,000
125
Captulo V
____________________________________________________________________________________ _
Desenv(CMM) Completitude com Relao aos Requisitos(COR)
(2,57; 3,57; 4,00)
---
Tabela V.7: Resultados da avaliao para o objetivo Confiabilidade Conceitual
A partir dos resultados apresentados nas duas tabelas anteriores, pode-se inferir que o produto avaliado est dentro do padro de qualidade (PQ) para ERS, segundo o MFAQS. Neste caso, dos atributos avaliados pelos especialistas, 58% esto com PQ = 1, isto , com qualidade ideal, 26% dos critrios esto dentro do PQ, e apenas 16% dos esto abaixo do padro de qualidade. Os atributos que no atingiram a qualidade ideal (q = 1), mas que esto dentro do padro de qualidade, em termos percentuais, so: (i) Uniformidade de Termos - 32,8%; (ii) Uniformidade de Notao - 60,7%; (iii) Complementabilidade - 19,9%; (iv) Consistncia Interna - 87,6%; e (v) Preciso - 77,0%.
V.3 Concluso
Neste captulo, foi apresentado um experimento para validar o MFAQS, baseado em uma pesquisa de campo realizada, para levantar o padro de qualidade de especificaes de requisitos de software. Baseado no padro de qualidade obtido, foi tambm avaliada uma ERS real, obtendo-se os ndices de qualidade para os atributos avaliados. Neste contexto, o MFAQS atendeu, convenientemente, a seus objetivos nesta experincia: (i) estabeleceu um padro de qualidade para o produto de software considerado, e (ii) avaliou um produto de software (similar) real, com base nesse padro estabelecido.
126
Captulo VI CONCLUSO
Neste trabalho, foram discutidos vrios tpicos referentes a qualidade de processos e de produtos de software, em conformidade com o padro ISO/IEC, juntamente com alguns modelos de avaliao mais representativos, tendo sido discutido, tambm, a temtica de medio do software (Captulo II). Discorreu-se ainda sobre vrios conceitos e propriedades da teoria dos conjuntos fuzzy, que vem sendo o elo de ligao entre muitos modelos imprecisos (subjetivos) do mundo real e a sua representao matemtica (Captulo III), para que pudessem dar suporte ao modelo fuzzy para avaliao da qualidade de software, proposto a partir da extenso do Modelo Rocha (Rocha, 1983) (Captulo IV). Aps a definio do modelo fuzzy, foi realizada uma experincia de sua utilizao (Captulo V), objetivando-se validar o modelo e fornecer um exemplo de sua utilizao. Este trabalho teve as seguintes contribuies: i. A extenso do Modelo Rocha para suportar os conceitos da teoria fuzzy, atravs do modelo fuzzy para avaliao da qualidade de software, fornecendo, assim, uma base matemtica slida e um mecanismo capaz de interpretar, na linguagem do desenvolvedor e/ou usurio, os resultados da medio do software. ii. A utilizao do peso do especialista em qualidade de software, atravs da elaborao do Questionrio de Identificao do Perfil do Especialista, como tambm a definio de uma metodologia de apurao de seus resultados. Estes dados podero, tambm, ser usados para avaliar e selecionar, antecipadamente, o grupo de especialistas, que participaro da avaliao do produto de software.
125
Captulo VI Concluso ___________________________________________________________________________
iii. A aplicao de funes de pertinncia (nmeros fuzzy normais triangulares), para representar um atributo de software, em qualquer ramo da rvore hierrquica de qualidade a que pertena. iv. A agregao de atributos de qualidade de software, nos vrios nveis de sua rvore hierrquica de qualidade, considerando-se, alm do grau de importncia, o peso de cada atributo agregante (primitivo), obtido no levantamento de seu padro de qualidade (se tiver sido estabelecido). Com este procedimento, visa-se evitar (ou minimizar) possveis distores na apurao dos resultados da avaliao, isto , atributos que tenham sido avaliados com valores muitos diferentes (para mais ou para menos) daqueles estabelecidos como padro de qualidade. v. Aplicao do conceito de similaridade (usado em tomada de deciso), para a avaliaes da qualidade de software, na apurao das estimativas dos especialistas. Assim sendo, o resultado final da avaliao tende para onde houve maior grau de consenso, no gerando um resultado de tendncia central. Quando, por exemplo, um especialista divergir totalmente dos outros especialistas, isto , seu estado de concordncia em relao a todos os outros for nulo, seu julgamento automaticamente desprezado, pelo prprio modelo. vi. A extenso do conceito do grau de concordncia nulo, para o grau de no concordncia, no intervalo [-1, 0], para o processo de agregao de atributos de qualidade de software. Isto porque todos os atributos de qualidade, que compem um atributo agregado, independentemente de seu grau de importncia, influencia o ramo hierrquico ao qual pertence, e no deve ser simplesmente desprezado, como ocorre em (v). O grau de concordncia e grau de no concordncia passaram a se chamar, ento, estado de concordncia. Com isto, quando algum atributo agregante tiver seu estado de concordncia no positivo, passa a ser considerado, tambm, no processo de agregao. Nesta situao, pode-se ponderar se, de fato, esse atributo deveria pertencer ou no quele ramo hierrquico, que est sendo avaliado, e tomar a deciso, se for o caso, de rearranjar o atributo em sua rvore hierrquica de qualidade. vii.Definio de procedimentos para clculo de ndices de qualidade, baseados em um padro de qualidade j tenha sido estabelecido, mediante o modelo proposto.
126
127
VI.1 Perspectivas Futuras

Vrias so as perspectivas para dar continuidade a este trabalho, que podem ser sugeridas: Automao do modelo fuzzy proposto para avaliao da qualidade de software, de maneira que possa ser facilmente utilizado como uma ferramenta de avaliao. Utilizao deste modelo na avaliao da qualidade de outros produtos de software ou de domnios de aplicao, para melhor ser validado e refinado. Continuar investindo na aplicao da teoria dos conjuntos fuzzy no processo de avaliao da qualidade software, por esta ser uma teoria robusta, fundamentada axiomaticamente, e que manuseia, convenientemente, conceitos subjetivos e vagos, normalmente encontrados ao longo do ciclo de vida de um produto de software. A experincia do uso da teoria fuzzy na avaliao da qualidade de software, especialmente em especificaes de requisitos, foi enriquecedora, motivando-nos cada vez mais a pesquisar outras reas afins, que possam fornecer subsdios e contribuir para a consolidao e maturidade da engenharia de software.
128
REFERNCIAS BIBLIOGRFICAS
ACKERMAN, A. F. et al., 1989, Software Inspections: An Effective Verification Process, IEEE Software. ALMEIDA, M. S., MORAES, L. F. R., 1995, Qualidade de Vida no Trabalho dos Profissionais de Informtica e Cultura da Qualidade nas Empresas de Informtica, Workshop de Qualidade, IX SBES, Recife. ALSINA, C., 1985, On a family of connectives for fuzzy sets, Fuzzy Sets and Systems 16, 231-235, in (ZIMMERMMAN, 1991). AMBRIOLA, V. et al., 1994, Applying a metric framework to the software process: an experiment, European Workshop Software Process Technology 94, in (MARIANO, 1996). ANDRADE, C. J., 1991, ANAFOR: um analisador de Programas FORTRAN, Tese de mestrado, COPPE/UFRJ, Rio de Janeiro. ANGER, F. D. et al., 1994, Temporal Complexity and Software Faults, Proceeding of IEEE International Symposium on Software Reliability Engineering 94, IEEE Computer Society, Los Alamitos, CA, in (MUNSON, 1995). ANSI/IEEE Std-730, 1993, Standard for Software Quality Assurance Plans (ANSI), IEEE Standards Collection, Software Engineering. ARTHUR, L. J., 1993, Improving Software Quality - An Insiders Guide to TQM, Wiley Professional Computing. ASANOME, C. R.,1995, Modelagem da Confiabilidade de Software, Publicaes Tcnicas COPPE/UFRJ, ES-336/95. AYTON, P., 1993, On the Competence and Incompetence of Expert, Expertise and Decision Support, Wright and F. Bolger, eds., Plenum Press, in (STRIGINI, 1996). BACH, J., 1994, The Imaturity of the CMM, American Programmer, New York, September, in (BASTOS, 1996). BACHE, R., BAZZANA, G., 1994, Software Metrics for Product Assessment, Mc Graw Hill Book Company, in (MARIANO, 1996).
128
Referncias Bibliogrficas ____________________________________________________________________________________ _
BAHIA, A. S., 1992, Avaliao da Complexidade de Software Cientfico, Tese de mestrado, COPPE/UFRJ, Rio de Janeiro. BALDWIN, J. F., 1979, A new approach to approximate reasoning using a fuzzy logic, Fuzzy Sets and Systems, 2,309-325, in (ZIMMERMANN, 1991). BANDEMER, H., KRAUT, A., 1990, A case study on modelling impreciseness and vagueness of observations to evaluate a functional relationship, in W. H. Janko, Ed., Progress in Fuzzy Sets and Systems (Kluwer Academic, Netherlands), in (RMER, 1995). BAKER, A. et al., 1990, A philosofhy for software measurement, Journal of System Software, vol. 12, July, in (FENTON, 1994). BARDOSSY, A., DUCKSTEIN, L., BOGARDI, I., 1993, Combination of fuzzy number representing expert opinions, Fuzzy Sets and Systems 57, 173-181. BASILI, V., ROMBACH, H. D., 1987, Tailoring the Software Process to Project Goals and Environments, Department of Computer Science, University of Maryland, ACM, 1987, in (ROSENBERG, 1996). BASILI, V. R., MUSA, J. D., 1991, The Future Engineering of Software: A Management Perspective, IEEE Computer, September. BASILI, V. et al., 1994, The Goal Question Metric Approach, University of Maryland, ftp.cs.umd.edu/pub/sel/papers/gqm.ps. BASILI, V. R., BRIAND, L., Melo, W., 1995, A Validation of Object-Oriented Design Metrics, Technical Report CS-TR-3443, University of Maryland, Dep. of Computer Science, April, in (CLUNIE, 1997). BASTOS, A. R. G., 1996, Um estudo sobre adoo de um modelo que visa promover melhorias no processo de desenvolvimento de software: O caso do CMM em uma empresa do setor financeiro no Brasil, Tese de Mestrado, COPPE/UFRJ, Rio de Janeiro. BAZZANA, G. et al., 1993, ISO 9126 and ISO 9000: Friends or Foes?, Software Engineering Standards Symposium, Brighton, UK.
129
BELASCO, J. A., STAYER, R. C., 1994, O vo do bfalo: decolando para a excelncia, aprendendo a deixar os empregados assumirem a direo, Editora Campus, Rio de Janeiro, in (ALMEIDA et al., 1995). BELCHIOR, A. D., 1992a, Caractersticas de Qualidade de Programas, Relatrio Tcnico ES-265/92, COPPE/UFRJ, Rio de Janeiro. BELCHIOR, A. D., 1992b, Controle da Qualidade de Software Financeiro, Tese de Mestrado, COPPE/UFRJ, Rio de Janeiro. BELCHIOR, A. D., GAIO, F. J., 1994, A Tecnologia de Informao Apoiando os Novos Desafios Empresariais: Um Estudo de Casos, VII Congreso Latino-Ibero Americano de Investigacion de Operaciones e Ingenieria de Sistemas (CLAIO), XVII Taller de Ingenieria de Sistema, Santiago-Chile. BELCHIOR, A. D., GAIO, F. J., 1995a, Aspectos no Tecnolgicas Envolvidos no Desenvolvimento de Software: Um Estudo de Casos, Anais do IX SBES, Recife. BELCHIOR, A. D., XEXO, G. B., 1995b, Um Modelo Fuzzy para Qualidade de Software, Relatrio Tcnicos ES-344/95 da COPPE/UFRJ. BELCHIOR, A. D., XEXO, G., ROCHA, A. R. C., 1995c, Uma Proposta Fuzzy para Medio de Atributos de Qualidade de Software, Anais do IX SBES, Recife. BELCHIOR, A. D., XEXO, G. B., ROCHA, A. R. C., 1996a, , Aplicao da Teoria Fuzzy em Requisitos de Qualidade de Software, XX II Conferencia Latinoamericana de Informtica (CLEI), Bogot de Santa F, Colmbia. BELCHIOR, A. D., XEXO, G. B., ROCHA, A. R. C., 1996b, , Agregao de Atributos de Qualidade de Software usando-se a Teoria Fuzzy, Workshp de Qualidade e Produtividade de Software, X Simpsio Brasileiro de Engenharia de Software (SBES), So Carlos - SP. BELCHIOR, A. D., XEXO, G. B., ROCHA, A. R. C., 1996c, Evaluating Software Quality Requirements using Fuzzy Theory, International Conference on Information Systems Analysis and Synthesis (ISAS), Orlando, USA. BELL Canada Inc., 1994, Trillium: Model for Telecom Product Development and Suport Process Capability, release 3.0, December, in (OLIVEIRA, 1995c).
130
BELLMANN, R. E., 1970, Decision making in a fuzzy enviroment, Management Sci. 17, in (FELIX, 1994). BELLMANN, R. E., GIERTZ, M., 1973, On the analytic formalism of theory of fuzzy set, Information Science 5, 149-157, in (SDORRA, 1993). BERGAMO Filho, V., 1991, Gerncia econmica da qualidade atravs do TQC: controle total da qualidade, Editora Makron, McGraw Hill, So Paulo. BERTOLINO, A., STRIGINI, L., 1996, On the use of testability measures for dependability assessment, IEEE Transaction on Software Engineering, vol. 22, no 2, February, in (MARIANO, 1996). BIEMANN, J. M. and OTT, L. M., 1994, Measuring functional cohesion, IEEE Transaction on Software Engineering, vol. 20, no 8, August, in (MARIANO, 1996). BLASCHECK, J. R., 1995, Planejamento de Projetos, Tese de Doutorado, COPPE/UFRJ, junho. BOEGH, J. et al., 1992, Guide to software product evaluation - The evaluators guide, Draft technical report, ISO/IEC/JTC1/SC7, October, in (BOEGH, 1993). BOEGH, J. et al., 1993, A Practitioners Guide to Evaluation of Software, IEEE Computer, August. BOEHM, B., 1987, Industrial software metrics top ten list, IEEE Software, September. BOEHM, B., HOH, I., 1996, Identifying Quality-Requirement Conflits, IEEE Software, March. BOLOIX, G., et al., 1995, A Software System Evaluation Framework, IEEE Software, December. BOSC, P. et al., 1995, Quantified Statements in a Flexible Relational Query Language, Proceedings of the 1995 ACM Symposium on Applied Computing, Nashville, February. BROCKLEHURST, P. Y et al., 1990 Recalibrating software reliability models, IEEE Transaction Software Engineering, vol. 16, no 4, April, in (FENTON, 1994).
131
BROEK, P. M., BERG, K. G., 1995, Generalised approach to software structure metrics, Software Engineering Journal, vol. 10, no 2, March, in (MARIANO, 1996). BUCKLEY, J. J., HAYASHI, Y., 1994, Fuzzy neural networks: A survey, Fuzzy Sets and Systems 66, 1-13. CALDIERA, G., BASILI, V. R., 1991, Identifying and Qualifying Reusable Software Components, IEEE Computer, February. CAMPOS, V. F., 1990, Gerncia da Qualidade Total: Estratgia para Aumentar a Competitividade da Empresa Brasileira, Fundao Christiano Ottoni, Escola de Engenharia da UFMG, Belo Horizonte. CAMPOS, F. C., 1994a, Hipermdia na Educao: Paradigmas e Avaliao da Qualidade, Tese de mestrado, COPPE/UFRJ, Rio de Janeiro, agosto. CAMPOS, G. H. B., 1994b, Metodologia para avaliao da qualidade de software educacional: Diretrizes para desenvolvedores e usurios, Tese de Doutorado, COPPE/ UFRJ, Rio de Janeiro, novembro. CARCHIOLO, V., MALGERI, M., 1995, A fuzzy approach to co-design system partitioning, Proceedings of the 1995 ACM Symposium on Applied Computing, Nashville, February. CARD, D. N., GLASS, R. L., 1990, Measuring Software Desing Quality, PrenticeHall, July. CARLSSON, C., FULLR, R., 1996, Fuzzy multiple criteria decision making: Recent developments, Fuzzy Sets and Systems 78, 139-153. CARVALHO, D., 1994, Requisitos de Qualidade para o Software Mdico, Relatrio Tcnico, Fundao Bahiana de Cardiologia. CHAIM, M. L., 1991, POKE-TOOL - Uma Ferramenta para Suporte ao Teste Estrutural de Programas Baseado em Anlise de Fluxo de Dados, Tese de Mestrado, DCA/FEE/UNICAMP, Abril, in (VILLAS, 1995). CHAN, C. B. I., 1991, Case Observations and Lessons, in The Knowledge Engineering Review, volume 6:2, 91.
132
CHEN, S. J., HWANG, C. L., 1992, Fuzzy Multiple Attribute Decision-making, Methods and Applications, Lecture Notes in Economics and Mathematical Systems, Vol. 375, Springer, Heidelberg, in (CARLSSON, 1996). CHEN, C. T., HSY, H. M., 1993, A study of fuzzy TOPSIS model, Proc. of the Chinese Institute of Industrial Engineers National Conference, in (HSU, 1996). CHEN, J. E., OTTO, K. N., 1995, Constructing membership function using interpolation and measurement theory, Fuzzy Sets and Systems 73, 313-327. CHIUEH, T., 1992, Optimization of Computer, May. CHUNG, L. et al., 1995, Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach, 17th International Conference on Software Engineering, Seattle, EUA, in (WEBER, 1997). CLUNIE, C. E., 1987, Verificao e Validao de Software na fase de Especificao de Requisitos, Tese de Mestrado, COPPE/UFRJ. CLUNIE, C. E., 1997, Avaliao da Qualidade de Especificaes Orientadas a Objeto, Tese de Doutorado, COPPE/UFRJ. COBB, R. H. et al., 1990, Engineering software under statistical quality control, IEEE Software, 7, 6, November, in (COLLINS et al., 1994). COELHO, A. C. B., 1997 Atributos de Qualidade para uma Abordagem Sociotcnica na Aquisio de Software, Tese de Mestrado, COPPE/UFRJ, Rio de Janeiro, abril. COLEMAN, D. et al., 1994, Using metrics to evaluate software systems maintainability, IEEE Computer, August. COLLINS, W. R. et al., 1994, How Good is Good enough?, Communication of the ACM, January. COMMERLATO, C. A., 1994, Uma Ferramenta para Seleo de Mdulos Reutilizveis, Tese de Mestrado, COPPE/UFRJ, Rio de Janeiro, julho. CONTE, S. D. et al., 1986, Software Engineering Metrics and Models, The Benjamim/Cummings Pulishing Company, Inc. Fuzzy Logic Inference Architecture,
133
COSENZA, C. A. N., 1981, Modelo para Localizao Industrial, Tese de Doutorado. COWARD, P. D., 1988, A Review of Software Testing, Information and Software Tecnology, vol. 30, no 3, April 1988, in (OLIVEIRA, 1995b). COX, E. D., 1995, Fuzzy logic for business and industry, Rockland, Massachusetts. CROSBY, P. B., 1990, Qualidade - falando Srio, Editora McGraw Hill, traduo de Jos Carlos Barbosa dos Santos, So Paulo. DARKIN. K., 1996, Keys to Engineering a Workable Contract, IEEE Software, January. DALE, C. J. et al., 1992, Software productivity metrics: Who needs them?, Information and Software Technology, vol. 34 (11), November, in (CAMPOS, 1995b). DAVENPORT, THOMAS H. et al., 1990 The New Industrial Engineering Information Technology and Business Process Redesign, Sloan Management Review, Summer. DAVIS, C. J. et al., 1993, Industrial Acceptance of Software Quality Assurance Standards, IEEE Computer, August. DAY, W. H. E., 1988, Consensus methods as tools for data analysis, in H.H. Bock, Ed., Classification and Related Methods for Data Analysis (Elservier, Amsterdam), 317-324, in (KUNCHEVA, 1996). DELAMARO, M. E., 1993, Proteum - Um Ambiente de Teste Baseado na Anlise de Mutantes, Tese de Mestrado, ICMSC-UDP, Outubro, in (VILLAS, 1995). DeMARCO, T., LISTER, T., 1987, Pleopleware: Productive Projects and Teams, New York: Dorset House Publishing, in (WEINBERG, 1993). DEMING, W. E., 1986, The Deming Management Method, New York: Dodd, Mead & Co., in (WEINBERG, 1993). DEMING, W. E., 1989, Out of Crisis, MIT Center for Advanced Engineering Study, MIT Press, Cambridge, Mass. DRIANKOV, D. et al., 1993, An Introduction to Fuzzy Logic Control, Springer, Berlin, in (YAGER, 1994).
134
DROMEY, R. G., 1995, A Model for Software Product Quality, IEEE Transactions on Software Engineering, vol. 21, no 2, February. DROMEY, R. G., 1996, Cornering the Chimera, IEEE Software, January. DRUCKER, P. F., 1990, The Comming of the new Organizations, Harvard Bussines Review. DUBOIS, D., PRADE, H., 1980, Fuzzy Sets and Systems: Theory and Applications, Academic Press, New York. DUBOIS, D., PRADE, H., 1982, A class of fuzzy measures based on triangular norms, Inter. J. Gen. Syst. 8, 43-61, in (ZIMMERMANN, 1991). DUBOIS, D., PRADE, H., 1984, Criteria aggregation and ranking of alternatives in the framework of fuzzy set theory, Studies in Management Sci, 20, in (FELIX, 1994). DUBOIS, D., 1985, A review of fuzzy set aggregation connectives, Information Science 36 85-121. DUBOIS, D., PRADE, H., 1988, Processing of imprecision and uncertainty in expert system reasoning models, In C.J. Ernst, 67-88, in (ZIMMERMANN, 1991). DUBOIS, D., PRADE, H., 1989, Fuzzy sets, probability and measurement, European J. Oper. Res. 40, in (TURKEN, 1991). DUBOIS, D., PRADE, H., 1991, Fuzzy sets in approximate reasoning, Part 1: Inference with possibility distributions, Fuzzy Sets and Systems, IFSA, Special Memorial Volume: 25 years of fuzzy sets, North-Holland - Amsterdam. DUNN, R. H., 1990, Software Quality, Concepts and Plans, Prentice-Hall, Englewood Cliffs, NJ, in (ZAGE, 1995). DRUCKER, PETER F., 1990, The Comming of the new Organizations, Harvard Bussines Review. DYER, M., 1992, The Cleanroom Approach to Quality Software Development, John Wiley & Sons, Inc. New York. ENGEMANN, K. J., YAGER, R. R., 1997, Risk Management with Imprecise Information, in Fuzzy information engineering: a guide tour of applications, edited by Didier Dubois, Henri Prade, and Ronald R. Yager, Jonh Wiley & Sons, Inc., USA.
135
FAGAN, M. E., 1976, Design and Code Inspection to Reduce Error in Program Development, IBM System Journal 15. FAGAN, M., 1986, Advances in Software Inspections, IEEE Transactions on Software Engineering, vol. SE-12, no 7, July, in (HUMPHREY, 1995). FARBEY, B., 1990, Software quality metrics: considerations about requirements and requirement specifications, Information and Software Technology, vol. 32, no 1, January/February. FEDRIZZI, M., KACPRZYK, J., 1993, Consensus degrees under fuzzy majorities and preferences using OWA (Ordered Weighted Average) operators, Proc. 5th IFSA World Congress, Seoul, Korea, in (KUNCHEVA, 1996). FELIX, R., 1994, Relationships between goals in multiple attribute decision making, Fuzzy Sets and Systems 67, 47-52. FENTON, N. E., 1990, Software Metrics: theory, tools and validation, Chapman and Hall, in (HUMPHREY, 1995). FENTON, N. E., 1991, Software Metrics: A Rigorous Approach, Chapman and Hall. FENTON, N., 1994, Software Measurement: A Necessary Scientific Basis, IEEE Transaction on Software Engineering, vol. 20, no 3, March. FENTON, N., 1996, Improve Quality?, IEEE Software, January. FENTON, N. E., PFLEEGER, S. L., 1997, Software Metrics: A Rigorous & Practical Approach, Second Edition, PWS Publishing Company. FICKAS, S., HELM, B. R., 1992, Knowledge Representation and in the Design of Composite Systems, IEEE Transaction on Software Engineering,vol.18, no 6, June. FILEV, D. P., 1993, An adaptive approach to defuzzificaton based on level sets, Fuzzy Sets and Systems 54, 355-360. FINKELSTEIN, L., 1984, A review of the fundamental concepts of measurement, Measurement, vol. 2, no 1, in (FENTON, 1994). FIORINI, S. T., 1995, TQM, CMM e Ambientes de Desenvolvimento de Software uma idia, Workshop de Qualidade de Software, IX SBES, Recife.
136
FODOR, J. C., ROUBENS, M., 1994, Fuzzy Preference Modelling and Multicriteria Decision Support, Kluwer, Dordrecht. FREEDMAN, D. P., WEINBERG, G. M., 1984, Reviews, Walkthroughs and Inspections, IEEE Transaction of Software Engineering, January. FREEDMAN, A. L., 1993, Computer Systens Development: History, Organization and Implementation, John Wiley & Sons Ltda, England. FRENCH, S., 1986, Decision Theory: An Introduction to the Mathematics of Rationality, John Wiley and Sons, New York, in (SDORRA, 1993). FRENCH, S., 1989, Fuzzy sets: the unanswered questions, Report 89.6, School of Computer Studies Research Report Series, University of Leeds, in (SDORRA, 1993). FUHRMANN, G., 1990, Note on the Generality of Fuzzy Sets, Information Sciences 2, 143-152. GALE, J. L. et al., 1990, Implementing the Defect Prevention Process in the MVS Interactive Programming Organization, IBM Systems Journal, vol. 29, no 1, in (HUMPHREY, 1995). GARCIA, J., PAZOS, J., ROS, J., 1992, Methodology of linguistics evaluation in risk situations using fuzzy techniques, Fuzzy Sets and Systems 48, 185-194. GARVIN, D. A., 1988, Managing Quality: The Strategic and Competitive Edge, Free Press, New York, in (SIMMONS, 1996). GEGOV. A. E., 1995, Hierarchical fuzzy control of multivariable systems, Fuzzy Sets and Systems 72, 299-310. GENEST. C., 1984, Um conflict between two axioms for combining subjective distributions, J. R. Statist. Soc., in (BARBOSSY, 1993). GENTLEMAN, W. M., 1996, Is software quality is a perception, how do we measure it?, The 6th I.C. on Software Quality, Ottawa, October. GILARDONI, G. L., CLAYTON, M.K., 1993, On reaching a consensus using DeGroots iterative pooling, Ann. Statist, 21, in (KUNCHEVA, 1993). GILB, T., 1996, Level 6: Why We Cant Get There from Here, IEEE Software, January.
137
GILES, R., 1976, Lukasiewicz logic and fuzzy theory, Inter. J. Man-Mach, Stud. 8, 313-327, in (ZIMMERMANN, 1991). GILES, R., 1988, The concept of grade of membership, Fuzzy Sets and Systems 25, 297-323, in (SDORRA, 93). GRABISCH, M., 1995, Fuzzy integral in multicriteria decision making, Fuzzy Sets and Systems 69, 279-298. GRADY, R. B., 1992, Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Engelewooe Cliffs, NJ. GRADY, R. B., 1994, Successfully applying software metrics, IEEE Computer, September. GRAHAM, B. P., NEWELL, R. B., 1988, Fuzzy identification and control of a liquid level rig., Fuzzy Sets and Systems, 26(3), 47-65, in (KLIR et al., 1995a). GUPTA, M. M., 1992, Fuzzy logic and neural network, Proc. 2nd Internat. Conf. on Fuzzy Logic and Neural Networks, Iizuka, Japan, 157-160, in (BUCKLEY, 1994). GRMAN, N. T., 1995, Generation and Improvement of Fuzzy Classifier with Incremental Learning using Fuzzy RuleNet, Proceedings of the 1995 ACM Symposium on Applied Computing, Nashville, February. HAASE, V. et al., 1994, Bootstrap: Fine-tuning Process Assessment, IEEE Software. HABRIAS, H., 1995, Mesure du logiciel, Editions Teknea, in (MARIANO, 1996). HAILSTONE, R., 1991, Quality management and software engineering, Software Quality and Reliability, Tools and methods, ed. Darrel Ince, Chapman & Hall, London, in (GENTLEMAN, 1996). HAMMER, Michael, 1990, Reengineering Work: Don't Automate, Obliterate, Harvard Bussines Review. HAPKE, M. et al., 1994, Fuzzy project scheduling system for software development, Fuzzy Sets and Systems 67, 101-117. HAUSEN, HANS-Ludwig et al., 1993, Guides to Software Evaluation, Arbeitspapiere der GMD 746, April.
138
HEFLEY, W. E. et al., 1995, The People Capability Maturity Model: Status and Progress, 5th International Conference on Software Quality (5ICSC), Austin, EUA, October, in (WEBER, 1997). HERTZ, J., KROGH, A., PALMER, R., 1991, Introduction to the Theory of Neural Computation, Addison-Wesley, Reading, Mass., in (MUNAKATA, 1994). HSU, H. M., CHEN, C. T., 1996, Aggregation of fuzzy opinions under group decision making, Fuzzy Sets and Systems 79, 279-285. HULL, L. G et al., 1991, Expert System Development Methodology and Management, Proceedings of the IEEE/ACM International Conference on Development and Managing Expert System Programs, Washington, D.C. HUMPHREY, W. S., 1989, Managing the Software Process, Addison-Wesley, Mass., in (MASHAYEKHI, 1993). HUMPHREY, W. S. et al., 1991 Software Process Improvement at Hughes Aircraft, IEEE Software, July. HUMPHREY, W. S., 1995, A discipline for Software Engineering, AddisonWesley Publishing Company. HWANG, C., YOON, K., 1981, Multiple Attribute Decision Making: Methods and Applications, Springer-Verlag, New York, in (KLIR et al., 1995a). IBRAHIM, A., AYYUB, B. M., 1992, Multi-criteria ranking of components according to their priority for inspection, Fuzzy Sets and Systems 48, 1-14. IEEE, 1987, Draft Version 13b, Standard for a Software Quality Metrics Methodology, IEEE Quality Metrics Standard Committee: P1061, July. IEEE, 1988, Standard for a Software Quality Metrics Methodology. IEEE, 1990, Standard Glossary of Software Engineering Terminology (ANSI). INCE, D., 1990, Software Metrics: Introduction, Information and Software Technology, vol. 32, May. ISHIKAWA, A et al., 1993, The max-min Delphi method and fuzzy Delphi method via fuzzy integration, Fuzzy Sets and Systems 55, 241-253.
139
ISO, 1987, ISO 9000, Quality management and quality assurance standards, Internacional Standards Organisation, in (BOEGH, 1993). ISO, 1990, ISO 9000-3, Quality Management and Quality Assurance Standards Part 3: Guidelines for the Application of ISO9001 to the Development, Supply and Maintenance of Software, ISO, September. ISO, 1991, ISO/IEC 9126, Information Technology - Software Product Evaluation, Quality characteristics and guidelines for their use. ISO, 1994, ISO DIS 8402, Quality Vocabulary, in (TSUKUMO, 1996). ISO, 1995, ISO/IEC 14598, International Standard, Information Technology Software product evaluation - Parts 1 to 6, (Working Draft), in (TSUKUMO, 1996). JACK, R., 1993, Applying ISO 9001 to Small Scale Software Development Project, IEEE Computer, August. JONES, C., 1991, Applied Software Measurement: Assuring Productivity and Quality, McGraw Hill, Software Engineering Series, New York. JONES, D. W., 1995a, Repeatable Software Development, Part I: Quality Assurance, Software Development Magazine, May. JONES, WEINBER, G. M., 1995b, Assessment and control of software risk, (book), USA. JOYCE, D. T., 1994, Examining the Potencial of Fuzzy Software Requirements Specifications, Information Sciences 2, 85-102. JURAN, J. M et al., 1988, Jurans Quality Control Handbook, Fourth Edition, New York, McGrawHill Book Company, in (HUMPHREY, 1995). KACPRZYK, J. et al., 1992, Group decision making and consensus under fuzzy preference and fuzzy majority, Fuzzy Sets and Systems 49, 21-31. KANDEL, A. et al., 1993, Fuzzy Control Systems, CRC Press, Boca Raton, Fl, (YAGER, 1994). KANTROWITZ, M. et al., 1996, Answers to Questions about Fuzzy Logic and Fuzzy Expert Systems, http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/ fuzzy/faq/fuzzy.faq, (last modified: 25/07/06), in 11/12/96.
140
KARISSON, E. A., 1995, Software reuse: a holistic Approach, John Wiley & Sons. KASABOV, N. K. et al., 1996, Foundations of Neural Networks, Fuzzy Systems and Knowledge Engineering; Massachusetts Institute of Technology. KAUFMANN, A., GUPTA, M. M., 1991, Introduction to Fuzzy Arithmetic: Theory and Applications, Van Nostrand Reinhold, New York. KHOSHGOFTAAR, T. M. et al., 1996, Reuse history in software quality models, IEEE Software, in (PONNAMBALAM, 1996). KICKERT, W. J. M., MANDANI, E. H., 1978, Analysis of a fuzzy logic controller, Fuzzy Sets and Systems, 1(1), 29-44, in (KLIR et al., 1995a). KIRKHAM, D. M. et al., 1996, Experiences in Analyzing Software Inspection Data, The 6th I.C. on Software Quality, Ottawa, October. KITCHENHAM, B. A et al., 1986, Software Metrics and Integrated Project Support Environments, Software Engineering Journal, January, in (MLLER, 1993). KITCHENHAM, B., 1990a, Editorial: Software reliability and metrics, IEE Software Engineering Journal., January. KITCHENHAM, B. et al., 1990b, An evaluation of some design metrics, IEE Software Engineering Journal., January. KITCHENHAM, B. A. et al., 1990c, Cost modelling and estimation, Software Reliability Handbook, P. Rook Ed., New York: Elsevier Applied Science, in (FENTON, 1994). KITCHENHAM, B. et al., 1995, Towards a Framework for Software Measurement Validation, IEEE Transaction on Software Engineering, vol. 21, no 12, December. KITCHENHAM, B. et al., 1996, Software Quality: The Elusive Target, IEEE Software, January. KLEMENT, E. P., SCHWYHLA, W., 1982, Correspondence between fuzzy measures and classical measures, FSS 7, 57-70, in (ZIMMERMANN, 1991). KLIR, G. J., FOLGER, T. A., 1988, Fuzzy Sets, Uncertainty and Information, Prentice Hall, New Jersey.
141
KLIR, G. J., YUAN, B., 1995a, Fuzzy Sets and Fuzzy Logic: Theory and Applications, Prentice Hall, New Jersey. KLIR, G. J., 1995b, Principles of uncertainly: What ar they? Why do we need them?, Fuzzy Sets and Systems 74, 15-311. KNIGHT, J. C., MYERS, E. A., 1993, An Improved Inspection technique, Communications of the ACM, November. KOSKO, B.; 1995, Neural Networks ans Fuzzy Systems: A dynamical systems approach to machine intelligence; Prentice Hall, Englewood Cliffs, NJ. KRISHNAPURAM, R., LEE, J., 1992, Fuzzy connective-based hierarchical aggregation networks for decision making, Fuzzy Sets and Systems 46, 21-31, in (KUNCHEVA, 1996). KUNCHEVA, L. I., 1995, Using degree of consensus in two-level fuzzy pattern recognition, European J. Oper. Res. 80, 365-370, in (KUNCHEVA, 1996). KUNCHEVA, L. I., KRISHNAPURAM, R., 1996, A fuzzy consensus aggregation operator, Fuzzy Sets and Systems 79, 347-356. KUMAR, S. R. et al., 1992, Methodology Engineering: A proposal for situation specific methodology construction, Challenges and Strategies for Research in Systems Development, John Wiley & Sons, Washington, in (ROSSI, 1996). KUMAR, S. R., GHOSHAL, J., 1996, Approximate reasoning approach to pattern recognition, Fuzzy Sets and Systems 77, 125-150. KUVAJA, P. et al., 1994, Software Process Assessment & Improvement - The Bootstrap Approach, Blackwell Publishers, Oxford, in (OLIVEIRA, 1995c). LASEK, M., 1992, Hierarchical structures of fuzzy ratings in the analysis of strategic goal of enterprises, Fuzzy Sets and Systems 50, 127-134. LEE, C. C., 1990, Fuzzy logic in control systems: fuzzy logic controller - parte I e II, IEEE Trans. Systems Man Cybernet. 20, 2, 404-418, 419-435. LEE, K. C., 1994, Fuzzy post adjustment mechanisms to improve the quality of knowledge-based solutions, Fuzzy Sets and Systems 68, 67-81.
142
LEE, H. M., 1996a, Applying fuzzy set theory to evaluate the rate of aggregative risk in software development, Fuzzy Sets and Systems 79, 323-336. LEE, H. M., 1996b, Group decison making using fuzzy theory for evaluating the rate of aggregative risk in software development, Fuzzy Sets and Systems 80, 261-271. LESMO, L., SAITTA, L., TORASSA, P., 1982, Learning of fuzzy production rules for medical diagnosis, in (ZIMMERMANN, 1991). LEVENDEL, Y., 1990, Reliability Analysis of Large Software Systems: Defect Data Modeling, IEEE Transaction on Software Engineering, vol. 16, no 2, February, in (HUMPHREY, 1995). LVY, P., 1993, As Tecnologias da Inteligncia - O Futuro do Pensamento na Era da Informtica, Editora 34, Rio de Janeiro, in (COELHO, 1995). LIGGESMEYER, P., 1995, A set of complexit measures for guiding the software teste process, Software Quality Journal, vol. 4, in (MARIANO, 1996). LINGER, R. C., 1994, Cleanroom Process Model, IEEE Software, March. LIOU, T. S., JIUN, M., WANG, J., 1992, Fuzzy weighted average: An improved algorithm, Fuzzy Sets and Systems 49, 307-315. LUCENA, C. J. P., 1991, Tecnologias de Software: Tendncias e Interesses para o Brasil, Seminrio Avanado de Software, CITS, Curitiba, Outubro, in (WEBER 97). LUHANDJULA, M. K., 1989, Fuzzy optimization: an appraisal, Fuzzy Sets and Systems 30, 139-153. MABUCHI, S., 1993, A proposal for defuzzification strategy by the concept of sensitivity, Fuzzy Sets and Systems 55, 1-14. McCABE, T. J., 1976, A Complexity Measure, IEEE Transactions on Software Engineering; vol. SE 2, December. MAININI, M. T., BILLOT, L., 1990, PERFIDE: an environment for evaluation and monitoring of software reliability metrics during the test phase, IEE Software Engineering Journal, January.
143
MALDONADO, J. C. et al., 1995, Anlise de Mutantes: Uma Avaliao Empritca do Axioma de Antiextensionalidade e da Propriedade de Equivalncia, Workshop de Qualidade, IX SBES, Recife. MANDEVILLE, W. A, 1990, Software Cost of Quality, IEEE Journal on Select Areas in Communications, vol. 8, no 2, February, in (HUMPHREY, 1995). MARIANO, G., 1996, Metrics in software engineering, http://estas1.inrets.fr:8001/ Public/Mariano.Georges/DundeeB/node3.html, (also node 4,5,6,7), in 21/01/97. MASHAYEKHI, 1993, V. et al., Distributed, Collaborative Software Inspection, IEEE Software, September. MAYS, R. G. et al., 1990, Experiences with Defect Prevention, IBM Systems Journal, vol. 29, no 1, in (HUMPHREY, 1995). MELTON, A., 1996, Software Measurement, International Thomson Computer Press, in (MARIANO, 1996). MICH, L., FEDRIZZI, M., GAIO, L., 1993, Approximate reasoning in the modeling of consensus in group decisions, Proc. FLAI 93, Lecture Note in Artificial Intelligence, Vol. 695, 91-102, in (KUNCHEVA, 1996). MILLER, S. E. et al., 1993, Quality Standards: The Role of Software Process Assessments, IEEE Computer, August. MILLET, P. B. et al., 1993, Os princpios da qualidade total aplicados informtica, Rio de Janeiro, LTC. MIYOSHI, T., AZUME, M., 1993, An Empirical Study of Evaluating Software Development Environment Quality, IEEE Transactions on Software Engineering, vol. 19, no. 5, May. MLLER, K. H., 1993, Software Metrics: a practitioners guide to improved product development, Chapman & Hall Computing. MOONEY, J. D., 1993, Issues in the Specification and Measurements of Software Portability, http:www.cs.wvu.edu/~jdm/research/portability/reports/TR_93-6.html# RT FToC17, in 24/10/96. MOOR, J., 1985, What is computer ethics?, Metaphilosophy 16, 4, October 1985, in (COLLINS et al., 1994).
144
MUMFORD, E., 1972, Job Satisfactin: A Stude of Computer Specialist, Longman, London, in (FREEDMAN, 1993). MUNAKATA, J., JANI, Y., 1994, Fuzzy Systems: An Overview, Communications of the ACM, vol. 37, no 3, March. MUNSON, J. C., 1995, Software measurement: Problens and practice, Annals of Software Engineering 1, 255-285. MUSA, J. D., IANINO, A., OKUMOTO, K., 1987, Software Reliability Measurement, Prediction, Application, McGraw-Hill, Inc., Singapore, in (ASANOME, 1995). NAKAMURA, K., 1986, Preference relation on a set of fuzzy utilities, Fuzzy Sets and Systems 20, 279-285. NEGOITA, C. V.; 1985, Expert Systems and Fuzzy Systems, Menlo Park, Reading, London, Amsterdam, in (ZIMMERMANN, 1991). NICULESCU, S. P., VIERTL, R., 1992, Bernoullis Law of Large Numbers for vague data, Fuzzy Sets and Systems 50, 167-173. NOVK, V., 1992, Fuzzy logic as a basis of approximate reasoning, in Fuzzy Logic for the Management of Uncertainty, edited by Lotfi Zadeh and Janusz Kacprzyk, John Wiley & Sons, USA. OLIV, A., SANCHO, M. R., 1996, Validating Conceptual Specifications through Model Execution, Information Systems, Vol. 21, no.2 (167-186). OLIVEIRA, J. V., 1995a, A set-theoretical defuzzification method, Fuzzy Sets and Systems 76, 63-71. OLIVEIRA, K. M., 1995b, Avaliao da Qualidade de Sistemas Especialistas, Tese de mestrado, COPPE/UFRJ, Rio de Janeiro, maro. OLIVEIRA, A. M. et al., 1995c, Avaliao de Processos de Software: Modelos e o TAQS-PROC, Workshop de Qualidade de Software, IX SBES, Recife. OMAN, P. et al., 1994, Construction and testing of polynomials predicting software software maintainability, Journal of System and Software, 24(3), in (PONNAMBALAM, 1996).
145
PAGE-JONES, M., 1988, Projeto Estruturado de Sistemas, McGraw-Hill, So Paulo. PAL, S. K. et al., 1992, Fuzzy geometry in image analysis, Fuzzy Sets and Systems 48, 23-40, in (SEONG, 1995). PALERMO, S., ROCHA, A. R. C., 1989, An experience on Evaluating Software Quality for High energy Physics, Computer Physics Communications. PASSOS, 1991, M. C. J. F., Uma Ferramenta para Construo e Avaliao de Grficos de Estrutura, Tese de mestrado, COPPE/UFRJ, Rio de Janeiro, maio. PASSOS, M. C. J. F., ROCHA, A. C. R., WERNECK, V. M. B., 1996, Uma Experincia em Aquisio de Modelagem do Conhecimento com o Mtodo KadsEstendido; Workshop sobre Sistemas Baseados em Conhecimento, Vitria. PEDRYCZ, W., 1990, Relevancy of Fuzzy Models, Informations Sciences 52, 285302. PETERS, T., 1993, Rompendo as barreiras da administrao para enfrentar a nova realidade, Editora Harbra, So Paulo, in (ALMEIDA et al., 1995). PFEFFER, J., 1994, Vantagens competitiva atravs de pessoas, Editora Makron Bolks, So Paulo, in (ALMEIDA et al., 1995). PFLEEGER, S. L., 1991, Software Engineering: The Production of Quality Softwre, Second Ed., Macmillan, New York. PONNAMBALAM, K., 1996, Analyzing Sensitivities of Software Qualities to Various Metrics, The 6th I.C. on Software Quality, Ottawa, October. PRATHER, R. E., 1996, Convexity and independence in software metric theory, Software Engineering Journal, July. PRESEDO, J. et al., 1996, Fuzzy modelling of the experts knowledge in ECGbased ischaemia detection, Fuzzy Sets and Systems 77, 63-75. PRESSMAN, R., 1992, Software Engineering - A Practioners Approach, Third Edition, McGraw Hill International Edition. RAFFY, J. L., 1995, Mesures de complexit de spcifications crites en Estelle, CFIP'95, May, in (MARIANO, 1996).
146
RIBEIRO, R. A. et al., 1995, Uncertainty in decision making: an abductive perspective, Decision Support Systems, 13, in (RIBEIRO, 1996). RIBEIRO, R. A., 1996, Fuzzy multiple attribute decision making: A review and new preference elicitation techniques, Fuzzy Sets and Systems 78, 155-181. RICHARDS, B. L., 1988, When Facts Get Fuzzy, Byte, April. ROBINS, Edward, 1995, The weighted average and its limitations in decision supports, Available: http://www.arlingsoft.com/wt_avr.htm. ROCHA, A. R. C., 1983, Um Modelo para Avaliao da Qualidade de Especificaes. Tese de Doutorado, PUC-RJ, Rio de Janeiro. ROCHA, A. R. C., 1987, Anlise e Projeto Estruturado de Sistemas, Editora Campus, Rio de Janeiro. ROCHA, A. R. C. et al., 1994, Uma Experincia na Definio do Processo de Desenvolvimento e Avaliao de Software segundo as Norma ISO, Anais do Workshop de Qualidade de Software, Curitiba. ROCHA, A. R. C. et al., 1996, Processo de Desenvolvimento de Software Baseado em Reutilizao, Relatrio Tcnico do Projeto MEMPHIS, 1/96, COPPE/UFRJ. ROCHA, A. R. C., 1997, Tedncias da Qualidade e Produtividade em Software, in (WEBER, 1997). ROMBACH, H. D., 1990, Design measurement: Some lessons learned, IEEE Software, March, in (CAMPOS, 1995b). RMER, C., KANDEL, A., 1995, Statistical tests for fuzzy data, Fuzzy Sets Systems 72, 1-26. ROSENBERG, L. et al., 1996, Develping An Effective Metrics Program, European Space Agency Software Assurance Symposium, Netherlands, March, in http:/satc.gsfc. nasa.gov/paper/esa_met.html, in 09/11/96. ROSSI, M., BRINKKEMPER, S., 1996, Complexity Metrics for Systems Development Methods and Techniques, Information Systems, Vol. 21, no 2 (209-227). ROTHMAN, P., 1989, Selecting an Uncertainty Management System, AI Expert, July.
147
ROUBENS, M., 1990, Inequality constraints between fuzzy number and their use in mathematical programming, in (SLOWINSKI, 1990). RUONING, X., XIAOYAN, Z., 1992, Extensions of the analytic hierachy process n fuzzy environment, Fuzzy Sets and Systems 52, 251-257. SAADE, J. J., 1996, Mapping convex and normal fuzzy sets, Fuzzy Sets and Systems 81, 251-256. SAATY, T. L., 1980, The Analytic Hierarchy Process, McGraw-Hill, New York. SAIEDIAN, H., KUZARA, R., 1995, SEI Capability Maturity Models Impact on Contractors, IEEE Computer, January. SAKAWA, M., SAWADA, K., 1994, An interactive fuzzy satisficing method for large-scale multiobjective linear programming problems with block angular structure, Fuzzy Sets and Systems 67, 5-17. SANDERS, J., CURRAN, E., 1994, Software Quality, Dublin: ACM Press Books. SANDRI, S. A., 1997, Elicitation, Pooling, and Assessment of Expert Opinion in the Possibilistic Framework, in Fuzzy information engineering: a guide tour of applications, edited by Didier Dubois, Henri Prade, and Ronald R. Yager, Jonh Wiley & Sons, Inc., USA. SASAKI, M., 1993, Fuzzy functions, Bull Sect., Fuzzy Sets and Systems 60, 336, North-Holland, in (BUCKLEY, 1994). SCALET, D., 1995, Avaliao da Qualidade do Produto de Sotfware, Workshop da Qualidade e Produtividade em Software e IX SBES/SBC, Recife, Outubro. SCHACH, S. R., 1990, Software Engineering, Aksen Associates Inc., Homewood, IL, in (GENTLEMAN, 1996). SCHMAUCH, C. H., 1994, ISO-9000 for Software Developer. SCHMUCKER, K. J., 1984, Fuzzy Sets, Natural Language Science Press, Rockville, MD, in (KLIR et. al., 1995a). SCHNEIDEWIND, N. F., 1992, Methodology for validating software metrics, IEEE Transaction Software Engineering, vol. 18, no 5, May, in (FENTON, 1994).
148
SCHNEIDEWIND, N. F., 1993, Report on the IEEE standard for a software quality metrics methodology, IEEE, Conference on Software Measurements, Montreal, Canada, September. SCHNEIDEWIND, N. F., 1995, Software metrics validation: Space Shuttle flight software example, Annals of Software Engineering 1, 287-309 SCHNEIDEWIND, N. F., 1996, Do Standards, IEEE Software, January. SCHWARE, R., 1992, Software Entry Strategies for Developing Countries: A Walking on Two Legs Proposition, World Development, vol. 20, no. 2. SCHWARTZ, D. G., KLIR, G. J., 1992, Fuzzy logic flowers in Japan, IEEE Spectrum, July, in (JOYCE, 1994). SDORRA, P. B., et al., 1993, A measure-theoretic axiomatization of fuzzy sets, Fuzzy Sets and Systems 60, 295-307. SEFCIK, J. G., 1994, Critical Sucess Factors for Implementing Software Quality Plans, ACM SIGSOFT, Software Engineering Notes, vol. 19 no 1, January. SEI, 1995, Software Engineering Institute, The Capability Maturity Model, Reading, Massachussetts, Addison-Wesley Co. SEONG, K. A., 1995, -Kernel problem with fuzzy visibility, Fuzzy Sets and Systems 73, 377-388. SHAW, M., 1981, When is Good Enough? Evaluating and Selecting Software Metrics, in Software Metrics: An Analysis and Evaluation, Perlis, A. et al., The MIT Press Cambridge. SHEPPERD, M., 1989, Metrics, Outlier Analysis and the Software Design Process, Information and Software Technology, 31, 2, 91-98, in (YU, 1995). SHEPPERD, M., 1990, Design metrics: an empirical analysis, IEE Software Engineering Journal, January. SHEPPERD, M., 1992, Products, progress and metrics, Information and Software Tecnology, vol. 34 no 10, October, in (OLIVEIRA, 1995b). SIMMONS, P., 1996, Quality Outcomes: Determining Business Value, IEEE Sofware, January.
149
SIMONELLI, M. R., 1996, On fuzzy interactive knowledge, Fuzzy Sets and Systems 80, 159-165. SLOWINSKI, R et al., 1990, Stochastic Versus Fuzzy Approaches to Multiobjetive Mathematical Programming under Uncertainty, Kluwer Academic Publishers, Dordrecht, in (HAPKE, 1994). SOARES, M. T. D. et al., 1994, Total Quality Strategies in Industry: the Experience of Two Multinacionals in Brazil, Quality Management Journal, no 1, Milwawkee, ASQC, Quality Press, in (FIORINI, 1995). SONG, Q., BORTOLAN, G., 1994, Some properties of defuzzification neural networks, Fuzzy Sets and Systems 61, 83-89. SRI, 1994, Software Research Inc., STW/Coverage Tool Suite for C, User Manual, Release 2, May, in (VILLAS, 1995). STAA, A. v., 1987, Engenharia de Programa, Livros Tcnicos e Cientficos Editora, 2a edio, Rio de Janeiro. STARK, G. et al., 1994, Using metrics in management decision making, IEEE Computer, September. STRIGINI, L., 1996, Limiting the Dangers of Intuitive Decision Making, IEEE Software, January. SUGENO, M., 1985, Industrial application of fuzzy control, North Holland, in (CARCHIOLO, 1995). SUZUKI, H., 1993, Fuzzy sets and membership functions, Fuzzy Sets and Systems 58, 123-132. TANINO, T., 1984, Fuzzy preference orderings in group decision making, Fuzzy Sets and Systems 12, 117-131. TAUSWORTHE, R. C., 1995, Software quality management through process and product modeling, Annals of Software Engineering 1, 119-139. TERVONEN, I., 1996, Support for Quality-Based Design and Inspection, IEEE Software, January.
150
TINNIRELLO, P. C., 1995, Handbook of Application Development, Second Edition, Auerbach Publication, Boston, in (GENTLEMAN, 1996). THOLE, U., ZIMMERMANN, H. J., Zysno, P., 1979, On the suitability of minimum and product operator for the intersection of fuzzy sets, Fuzzy Sets and Systems 2, 167-180. TRILLIUM, 1997, Trillium Model Overview, http://ricis.cl.uh.du/process_maturity/ trillium /t3modc1.html, in 21/01/97. TROSTER, J., TIAN, J., 1995, Measurement and defect modeling for a legacy software system, Annals of Software Engineering 1, 95-118. TSUKUMO, A. N. et al., 1995, ISO/IEC 9126: An Experiment of Application on Brazilian Software Products, 2nd International Software Engineering Standards Symposium (ISESS95), Montreal, Quebec, Canada, August. TSUKUMO, A. N et al., 1996a, Avaliao incremental de Qualidade de Produto de Software baseada na ISO/IEC 9126 (NBR 13596), SBES96 - Workshop de Qualidade, So Carlos. TSUKUMO, A. N et al., 1996b, Modelos de Processos de Software: Viso Global e Anlise Comparativa, Anais do VII CITS - Conferncia Internacional de Tecnologia de Software: Qualidade de Software, Curitiba. TURBAN, E., 1988, Decision Support and Expert Systems, Macmillan, New York, in (RIBEIRO, 1996). TURKSEN, I. B., 1991, Measurement of membership functions and their acquisition, Fuzzy Sets and Systems, IFSA, Special Memorial Volume: 25 years of fuzzy sets, North-Holland - Amsterdam. TVERSKY, A., KAHNEMANN, D., 1990, Judgement under uncertainty: heuristics and biases, in Shafer and Pearl, Eds. Reading in Uncertain Reasoning, in (RIBEIRO, 1996). VALLE, C., 1997, Sistemas de Acesso Pblico para a Educao de Pacientes, Tese de Mestrado, COPPE/UFRJ, Rio de Janeiro, Maio.
151
VILLAS-Boas, A. et al., 1995, Estudo Comparativo de Critrios de Teste de Software para o Estabelecimento de Estratgias de Aplicao, Workshop de Qualidade, IX SBES, Recife. VIOT, G., 1993, Fuzzy Logic in C, Dr. Dobbs Journal, February. VOTTA Jr., L. G., 1993, Does Every Inspection Need a Meeting?, ACM SIGSOFT, Software Engineering. WATTS, R., 1987, Measuring software quality, NCC Publications, in (PONNAMBALAM, 1996). WEBER, K. C., DeLUCA, J. C. M., ROCHA, A. R. C., 1997, Qualidade e Produtividade em Software: Termo de Referncia do Subprograma Setorial da Qualidade e Produtividade em Software, do Programa Brasileiro da Qualidade e Produtividade -PBQP, 2a edio, Makron Books, So Paulo. WEINGBERG, G. M., 1993, Quality Software Management, Vol. 2, First-Order Measurement, Dorset House Publishing, N.Y. WERNER, C. M. L., 1996, MEMPHIS: Um Ambiente para Desenvolvimento de Software Baseado em Reutilizao - Definio da Arquitetura, Relatrio Tecnico COPPE/UFRJ, 3/96. WERNERS, B., 1984, Interaktive Entscheidungsuntersttzung values, Fuzzy Sets and Systems 23, 131-147, in (ZIMMERMANN, 1991). WHITTY, R. W., 1990, Structural metrics for Z specifications, Proceedings of the 4th annual Z User Meeting, in (MARIANO, 1996). XAVIER, A. C. R., 1992, Reflexes sobre a qualidade da educao e a Gesto da qualidade total nas escolas, Tecnologia Educacional, vol 20 (101), Rio de Janeiro, jul/ago, in (CAMPOS 95b). XU, R. N., Zhai, X. Y., 1992, Extensions of the analytic hierarchy process in fuzzy environment, Fuzzy Sets and Systems 52, 117-131. YAGER, R. R., 1978, Fuzzy decision making including unequal objectives, Fuzzy Sets and Systems 1, 87-95, in (RIBEIRO, 1996), YAGER, R. R., 1980, On a general class of fuzzy connectives, FSS 4, 235-242, in (ZIMMERMANN, 1991).
152
YAGER R. R., 1983a, Quantifiers in the formulation of multiple objective decision functions, Informations Science 31, 107-138. YAGER R. R., 1983b, Quantifiers propositions in a linguistic logic, Internat. J. Man-Machine Stud. 19, 195-227, in (ZACPRZYK, 1992). YAGER, R. R., 1988, On ordered weighted averagingh aggregation operators in multicriteria decision making, IEEE Trans. on Systems, Man and Cybernectics, 18 (1) 183-190, in (KLIR, 1995a). YAGER R. R., 1991, Connectives and quantifiers in fuzzy sets, Fuzzy Sets and Systems, IFSA, Special Memorial Volume: 25 years of fuzzy sets, North-Holland Amsterdam. YAGER R. R., FILEV, D., 1993a, On general class of fuzzy connectives, Fuzzy Sets and Systems 55, 255-271. YAGER R. R., 1993b, Toward a General Theory of Information Aggregation, Information Sciences 68, 191-206. YAGER R. R., 1994, Aggregation operators and fuzzy systems modeling, Fuzzy Sets and Systems 67, 129-145. YAGER, R. R., RYBALOV, A., 1996, Uninorm aggregation operators, Fuzzy Sets and Systems 80, 111-120. YOURDON, E., 1989, Structured Walkthroughs, Prentice Hall, Englewood Cliffs, N.J. YOURDON, E., 1995, When Good Enough Software is Best, IEEE Software, May. YU, C., 1993, Correlation of fuzzy numbers, Fuzzy Sets and Systems 55, 303-307. YU, X., LAMB, D. A., 1995, Metrics applicable to software design, Annals of Software Engineering 1, 23-41. ZADEH, L. A., 1965, Fuzzy sets, Information and Control 8, 338-353. ZADEH, L. A., 1973a, Outline of a new approach to the analysis of complex systems and decision process, IEEE Trans. on Systems, Man, Cybernectics, vol SMCL, no. 1, January.
153
ZADEH, L. A., 1973b, The concept of a linguistic variable, ERL-M Memo, Berkeley, October, in (JOYCE, 1994). ZADEH, L. A., 1977, A theory of approximate reasoning, Memorandoum no. UCB/ERLM 77/58, in (TURKEN, 1991). ZADEH, L. A., 1978, Fuzzy sets as a basis for the theory of possibiliy, Fuzzy Sets and Systems 1. ZADEH, L. A., 1983, A computacional approach to fuzzy quantifiers in natural languages, Computer Mathematics with Applications, 9, 149-184. ZADEH, L. A., 1988, Fuzzy logic, IEEE Transaction Comput. 35, in (TURKEN, 1991). ZADEH, L. A., 1990, The birth and evolution of fuzzy logic, in I.B. Turksen, Ed., Proceeding of NAFIP90 (June, 6-8). ZAGE, W. M., ZAGE, D. M., 1995, Avoiding metric monsters: A design metrics approach, Annals of Software Engineering 1, 43-55. ZELENY, M., 1992, An essay into a philosophy of MCDM: a way of thinking or another algorithm?, Comput. Oper. Res. 19, 563-566, in (CARLSSON, 1996). ZIMMERMANN, H. J., 1988, Fuzzy sets theory - and inference mechanism, Mitra, 727-741, in (ZIMMERMANN, 1991). ZIMMERMANN, H. J., 1991, Fuzzy Set Theory and Its Applications, Kluwer Boston, 2nd revised edition. ZIMMERMANN, H. J., 1997, Operators in Models of Decision Making, in Fuzzy information engineering: a guide tour of applications, edited by Didier Dubois, Henri Prade, and Ronald R. Yager, Jonh Wiley & Sons, Inc., USA. ZOVCS, Z. L., 1996, Redes Neurais Artificiais: fundamentos e aplicaes, Editora Acadmica. ZUSE, H., 1990, Software Complexit: Measures and Methods, Amsterdam: de Gruyter, in (FENTON, 1994). ZWICK, R. et al., 1987, Measures of similarity among fuzzy concepts: A comparative analysis, Internat, J. Approximate Reasoning 1, in (HSU, 1996).
154
Apndice I
Questionrio de Identificao do Perfil do Especialista
155
Apndice I Questionrio de Identificao do Perfil do Especialista ___________________________________________________________________________
I. Questionrio de Identificao do Perfil do Especialista

O Questionrio de Identificao do Perfil do Especialista (QIPE) pode e deve ser adaptado de acordo com as necessidades de quem o est aplicando, bem como o estabelecimento dos pesos para cada um de seus subitens, para a obteno de resultados convenientes. Neste trabalho, utilizou-se um QIPE, que contm apenas 7 itens (questes) e cada item possui vrios subitens, como mostrado na Seo I.1. Sugere-se que a apurao dos resultados do QIPE siga a escala de pesos apresentada na Seo I.2, e que o escore total de cada item seja normalizado, quando necessrio. ROBINS (1995) adverte que a definio de escores rdua, pois estes freqentemente levam a incertezas nos valores finais da avaliao. Neste contexto, os resultados do QIPE sero obtidos como se segue: i. A apurao de cada item do QIPE feita pelo somatrio de seus subitens selecionados pelo especialista, Ei, que o avaliou, de acordo com escores, previamente definidos para cada um desses subitens (Seo I.2). ii. Se for especificado pelo especialista, um valor Maior que 7 para qualquer um dos subitens (quantificveis) acima descritos, acrescentar ao escore
correspondente, para cada acrscimo de 7 (isto , > 14, > 21, ... ), o seu fator base, ou seja, o ndice que quantifica a opo Entre 1 e 2. Por exemplo, algum que tenha marcado no item 2 do QIPE, no subitem sistemas de Grande Porte, simplesmente a opo Maior que 7, receber o escore igual a 3 . Mas, se tiver, por exemplo, tiver indicado a quantidade 18, para sistemas de Grande Porte que tenha desenvolvido, seu escore ser 4, isto , 3 + 1 ( >14); se tiver indicado 25, seria 3 + 2 (> 21), e assim por diante. Note-se que, neste caso, o escore 1 corresponde a seu fator base, isto , o escore pertencente opo
Entre 1 e 2 deste subitem exemplificado. iii. Cada item do QIPE, quando necessrio, deve ser normalizado, isto , deve ter seu valor, no mximo, igual a 1. Para isto, quando um determinado item, considerando-se este mesmo item para todos os especialistas participantes do processo de avaliao, possui um escore-total, eti, maior que 1 (um), calcula-se o escore-normalizado, eni, desse item em particular, para cada Ei, onde o smbolo representa o maior valor do item, que est sendo apurado. Neste
156
caso, o escore-final do item avaliado escore-normalizado. Formalizando-se: eni = eti / eti iv. Finalmente, procede-se ao somatrio de todos os escores-finais dos itens (questes) do QIPE, obtendo-se, assim, o total do QIPE, tQIPE, por especialista. Neste trabalho, como se tem apenas 7 itens definidos no QIPE, ento, tQIPEi 7. A seguir, os escores so definidos para cada item e subitem do QIPE, como tambm as regras para a apurao de seus resultados.
I.1 QIPE
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COPPE/UFRJ - Programa de Engenharia de Sistemas e Computao Linha de Pesquisa: Engenharia de Software
Questionrio de Identificao do Perfil do Especialista

Produto de Software: _____________________________ Instituio:__________ Avaliador: ______________________________________ Fone/fax: ___________ 1) Marque sua experincia ou as atividades (cargos) que j exerceu ou exerce, na rea de computao: Gerente de projeto Professor (universitrio) de informtica (ou de cursos de informtica de mais de 40 horas) Analista de sistemas Programador Projetista Usurio Outra ______________
2) J participou do desenvolvimento de quantos sistemas de computao? Grande Porte: Mdio Porte: Pequeno Porte: Nenhum Nenhum Nenhum Entre 1 e 2 Entre 1 e 2 Entre 1 e 2
157
Entre 3 e 7 Entre 3 e 7 Entre 3 e 7
Maior que 7 ____ Maior que 7 ____ Maior que 7 ____
3) Se for o caso, em que fases do ciclo de vida de um produto de software j participou? Especificao de Requisitos Codificao Projeto Manuteno Teste Outra(especificar) _________
4) Quantos produtos de software (especificaes, projetos, sistemas, etc.) similares ao que est sendo avaliado j desenvolveu? Nenhum Entre 1 e 2 Entre 3 e 7 Maior que 7 ____
5) Como voc classificaria seu entendimento em relao ao produto de software em questo (conceituao, objetivos e viabilidade do sistema): Excelente Alto Bom Mdio Baixo Nenhum
6) Marque a opo que melhor caracteriza seu grau de escolaridade? Segundo Grau Terceiro Grau (rea) _______________________
Especializao (a nvel de ps-graduao) __________________________ Mestrado (rea) ________________ Doutorado (rea) _______________
7) Marque os subitens (e a quantidade a eles referentes), que dizem respeito a seu grau de treinamento em informtica: Cursos (at 8 hs): que 7 __ Cursos (at 40 hs): Cursos (mais de 40 hs): Simpsios/Congressos: Nenhum Nenhum Nenhum Entre 1 e 2 Entre 1 e 2 Entre 1 e 2 Nenhum Nenhum Entre 3 e 7 Entre 3 e 7 Entre 3 e 7 Entre 1 e 2 Entre 1 e 2 Maior que 7 __ Maior que 7 __ Maior que 7 __ Entre 3 e 7 Entre 3 e 7 >7__ >7__ Nenhum Entre 1 e 2 Entre 3 e 7 Maior
Publicaes de artigos nacionais: Publicaes de artigos internacionais:
158
I.2 Definio dos Escores do QIPE

1) Escore-total do item: ____________ Gerente de projeto 1 Escore-final do item: _______
Professor (universitrio) de informtica 0,9 (ou de cursos de informtica de mais de 40 horas)
Analista de Sistemas 0,8 Programador 0,6
Projetista Usurio
0,7 0,5 0,3
Outros (considerar o escore, se for pertinente informtica) 2) Escore-total do item: ___________ Grande Porte: Nenhum 0 Entre 1 e 2 Mdio Porte: 1
Escore-final do item: _______ Entre 3 e 7 2 Maior que 7 3 .
Nenhum 0 Entre 1 e 2 0,7 Entre 1 e 2 0,3
Entre 3 e 7 1,4 Maior que 7 2,1 . Entre 3 e 7 0,6 Maior que 7 0,9 .
Pequeno Porte: Nenhum 0
3) Escore-total do item: ___________ Especificao de Requisitos 1 Codificao 0,6
Escore-final do item: _______ Teste 0,7 Outra (se pertinente) 0,3
Projeto 0,8 Manuteno 0,5
4) Escore-total do item: ___________ Nenhum 0 Entre 1 e 2 0,3
Escore-final do item: _______ Entre 3 e 7 0,7 Maior que 7 1 .
5) Escore-total do item: ___________ Excelente 1 Alto 0,9 Bom 0,7
Escore-final do item: _______ Mdio 0,5 Baixo 0,3 Nenhum 0
6) Escore-total do item: ___________ Segundo Grau 0,2
Escore-final do item: _______
Terceiro Grau 0,6 (rea de informtica) 0,4 (outras reas)
Especializao (a nvel de ps-graduao)
0,7 (rea de informtica) 0,5 (outras reas)
Mestrado 0,8 (rea de informtica) 0,6 (outras reas) 7) Escore-total do item: ___________
159
Doutorado 1 (rea de informtica) 0,8 (outras reas) Escore-final do item: _______
Cursos (at 8 hs): Nenhum 0 Entre 1 e 2 0,3 Entre 3 e 7 0,6 Maior que 7 0,9. Cursos (at 40 hs): Nenhum 0 Entre 1 e 2 0,6 Entre 3 e 7 1,2 Maior que 7 1,8 . Cursos (mais de 40 hs): Nenhum 0 Entre 1 e 2 0,8 Entre 3 e 7 1,6 Maior que 7 2,4. Simpsios/Congressos: Nenhum 0 Entre 1 e 2 0,5 Entre 3 e 7 1,0 Maior que 7 1,5. Publicaes de artigos nacionais: Nenhum 0 Entre 1 e 2 0,8 Entre 3 e 7 1,6 > 7 2,4. Publicaes de artigos internacionais: Nenhum 0 Entre 1e2 1 Entre 3 e 7 2 >7 3. TOTAL DE ESCORES DO QIPE (tQIPE): ___________
160
Apndice II
Atributos de Qualidade de Especificaes de Requisitos de Software
161
Apndice II Atributos de Qualidade para ERS ____________________________________________________________________________________ _
II. Atributos de Qualidade para ERS

Os produtos de software so desenvolvidos para atenderem a determinadas necessidades dos usurios. Depois de serem colocados em operao, espera-se que tenham uma vida til longa e produtiva. Para que isto se concretize, devem ser atingidos os seguintes objetivos de qualidade: confiabilidade da representao, confiabilidade conceitual e utilizabilidade (ROCHA, 1987). Neste apndice, as tabelas apresentam o conjunto de atributos de qualidade para especificaes de requisitos de software (ERS) em geral, definido em CLUNIE (1997), por objetivo de qualidade, segundo o Modelo Rocha. O objetivo Confiabilidade da Representao refere-se s caractersticas que tornam a especificao confivel para seus usurios, considerando-se aspectos referentes sua forma, e que tornam possvel a sua compreenso e manipulao, tendose em conta que a especificao evolui ao longo do desenvolvimento, sendo modificada durante a vida til do produto ao serem feitas manutenes. Este objetivo se realiza atravs dos fatores de qualidade: Comunicabilidade e Manipulabilidade.
OBJETIVO: CONFIABILIDADE DA REPRESENTAO
Conjunto de atributos de qualidade que avaliam a capacidade da especificao de comunicar seu contedo. Correo no Uso do Conjunto de atributos de qualidade que avaliam a correo da especificao do ponto de vista do uso do mtodo de Mtodo desenvolvimento. Caracterstica que avalia se a notao do mtodo foi usada de forma Correo da correta. Notao Correo Sinttica Caracterstica que avalia se o conjunto de regras sintticas definidas no mtodo foi usado de forma correta. Caracterstica que avalia se o conjunto de regras semnticas Correo definidas no mtodo foi usado de forma correta. Semntica Correo no Uso do Caracterstica que avalia se o formato de documentao definido no mtodo foi usado de forma correta. Formato de Documentao Conjunto de atributos de qualidade que avaliam se a especificao Uniformidade de foi escrita com uniformidade de termos e notao. Terminologia Uniformidade de Caracterstica que avalia se os termos tcnicos foram utilizados de forma uniforme ao longo do texto e de acordo a definies Termos preestabelecidas. Uniformidade de Caracterstica que avalia se a notao foi utilizada de forma uniforme ao longo do texto. Notao Uniformidade no Nvel Conjunto de atributos de qualidade que avaliam se a especificao possui um nvel de detalhe uniforme, considerando-se um de Abstrao determinado estgio do desenvolvimento. Legenda Fatores de qualidade Critrios de qualidade Subfatores de qualidade COMUNICABILIDADE
Tabela AII.1 - Caractersticas de qualidade relacionadas ao objetivo Confiabilidade da Representao para ERS (CLUNIE, 1997)
162
OBJETIVO: CONFIABILIDADE DA REPRESENTAO (cont.)

Caracterstica que avalia se todos os aspectos esto descritos na especificao com o mesmo nvel de detalhamento, considerandose um determinado estgio de desenvolvimento. Caracterstica que avalia na especificao de requisitos a existncia de restries com relao escolha de alternativas de soluo prprias da fase de projeto. Conjunto de atributos de qualidade que avaliam se as partes da especificao podem ser entendidas e modificadas de forma independente. Caracterstica que avalia o grau de associao das informaes de Coeso de um captulo e, dentro deste, sees. Informaes Acoplamento entre Caracterstica que avalia o grau de interdependncia entre os mdulos - captulos ou sees - . as Sees Caracterstica que avalia se a estrutura, composta de captulos e, Estrutura da dentre destes, sees, est organizada numa seqncia lgica. Documentao Conjunto de atributos de qualidade que avaliam se a especificao contm um volume mnimo de texto por ter-se maximizado o Conciso volume de informao por unidade de texto. Caracterstica que avalia se a especificao faz uso de documentos Complementabilidade auxiliares - referncias, glossrios, dicionrios de dados - que facilitam seu entendimento. Conjunto de atributos de qualidade que avaliam se a especificao foi gerada considerando as normas estabelecidas para o Conformidade desenvolvimento do produto. Caracterstica que avalia se a especificao foi gerada obedecendo Aderncia a Normas as normas estabelecidas pela organizao desenvolvedora. da Organizao Desenvolvedora foi gerada Aderncia a Normas Caracterstica que avalia se a especificao estabelecidas pelo considerando as normas estabelecidas pelo contratante. Contratante Conjunto de atributos de qualidade que avaliam a facilidade de MANIPULABILIDADE manipulao da especificao para diversas formas de uso. Conjunto de atributos de qualidade que avaliam a facilidade de acesso de uma especificao para seus usurios autorizados, na sua Disponibilidade verso mais atualizada. Caracterstica que avalia se qualquer usurio autorizado pode Acessibilidade facilmente consultar a especificao e/ou obter uma cpia da mesma. Caracterstica que avalia se a especificao reflete a informao Estar Atualizada mais recente. Conjunto de atributos de qualidade que avaliam a facilidade de se percorrer as especificaes de requisitos e de projeto, Rastreabilidade identificando a agregao de detalhes a um determinado aspecto, desde sua viso mais global at a mais detalhada e vice-versa. Caracterstica que avalia se o conjunto de especificaes est Organizao da organizado, de forma a facilitar sua manipulao. Documentao Caracterstica que avalia se existem facilidades para se localizar Localizabilidade todos os elementos, dentro de uma especificao, relacionados Interna com determinado aspecto ou assunto. Caracterstica que avalia se existem facilidades para localizar Localizabilidade todas as especificaes e demais documentos relacionados a um Externa determinado aspecto ou assunto. Legenda Fatores de qualidade Critrios de qualidade Uniformidade de Detalhes da Documentao Independncia de Detalhes do Projeto Modularidade da Documentao Subfatores de qualidade
Tabela AII.1 - Caractersticas de qualidade relacionadas ao objetivo Confiabilidade da Representao para ERS (continuao)
163
164
O objetivo Confiabilidade Conceitual refere-se s caractersticas que avaliam se um especificao confivel para seus usurios, segundo o seu contedo, satisfazendo os requisitos que motivaram a sua construo. Este objetivo se realiza atravs dos fatores de qualidade: Fidedignidade e Suficincia.
OBJETIVO: CONFIABILIDADE CONCEITUAL
Conjunto de atributos de qualidade que avaliam se a especificao representa o que entendido como sendo as necessidades e expectativas dos usurios do produto. Conjunto de atributos de qualidade que avaliam se a especificao Consistncia est isenta de contradies entre os aspectos especificados. Consistncia Interna Caracterstica que avalia se existem conflitos entre aspectos especificados na mesma especificao. Caracterstica que avalia se existem conflitos entre aspectos Consistncia especificados em outras especificaes ou entidades externas. Externa Conjunto de atributos de qualidade que avaliam seu o contedo da especificao est expresso, de forma a evitar a possibilidade de No Ambigidade diferentes interpretaes para qualquer aspecto ou assunto. Caracterstica que avalia se na especificao existem condies, Ser Explcita hipteses e/ou restries definidas por contexto. Caracterstica que avalia se os aspectos especificados esto Preciso descritos de forma precisa e, sempre que possvel quantificada. Conjunto de atributos de qualidade que avaliam se esto presentes SUFICINCIA na especificao todos os aspectos necessrios e somente estes. Conjunto de atributos de qualidade que avaliam se todos os Necessidade aspectos considerados na especificao so imprescindveis. Caracterstica que avalia se na especificao esto descritos os Necessidade dos requisitos considerados imprescindveis. Requisitos Conjunto de atributos de qualidade que avaliam se existem No Redundncia aspectos repetitivos na especificao. No Redundncia de Caracterstica que avalia se um mesmo aspecto descrito em mais de um lugar da especificao. Informaes Conjunto de atributos de qualidade que avaliam se todos os Completitude aspectos que devem ser especificados esto presentes na especificao. Completitude com Caracterstica que avalia se o roteiro definido pela organizao Relao ao Roteiro desenvolvedora foi totalmente coberto pela especificao. definido pela Organizao Completitude com Caracterstica que avalia se foram utilizados todos os recursos Relao ao Mtodo previstos no mtodo de desenvolvimento. de Desenvolvimento Completitude com Caracterstica que avalia se na especificao esto definidos todos os requisitos estabelecidos para o produto. Relao aos Requisitos Legenda Fatores de qualidade Critrios de qualidade FIDEDIGNIDADE Subfatores de qualidade
Tabela AII.2 - Caractersticas de qualidade relacionadas ao objetivo Confiabilidade Conceitual para ERS (CLUNIE, 1997)
165
O objetivo Utilizabilidade refere-se s caractersticas de qualidade que tornam possvel a utilizao da especificao, sob as mais diversas formas e propsitos, durante o processo de desenvolvimento, avaliao, manuteno e implementao. Este objetivo se realiza atravs dos fatores de qualidade: Avaliabilidade, Manutenibilidade, Reutilizabilidade e Implementabilidade.
OBJETIVO: UTILIZABILIDADE
AVALIABILIDADE Verificabilidade Validabilidade MANUTENIBILIDADE Conjunto de atributos de qualidade que avaliam a capacidade da especificao poder ser avaliada com relao sua forma e contedo. Conjunto de atributos de qualidade que avaliam a facilidade de se avaliar uma especificao segundo sua forma. Conjunto de atributos de qualidade que avaliam a especificao com relao ao seu contedo. Conjunto de atributos de qualidade que avaliam a capacidade da especificao poder ser facilmente modificada e detalhada. Conjunto de atributos de qualidade que avaliam a capacidade da especificao poder ser alterada com facilidade sem com isso perder a sua qualidade. Conjunto de atributos de qualidade que avaliam a facilidade de se poder introduzir novos requisitos ou realizar refinamentos em especificaes sem que esta perca a qualidade. Conjunto de atributos de qualidade que avaliam se a especificao de tem os seus componentes organizados e desenvolvidos de maneira a permitir sua reutilizao parcial ou total em outras aplicaes similares. Conjunto de atributos de qualidade que avaliam a capacidade da especificao poder ser adaptada para corresponder a outra aplicao similar. Conjunto de atributos de qualidade que avaliam se a especificao tem os seus componentes desenvolvidos de forma a poderem ser utilizados em outros contextos. Conjunto de atributos de qualidade que avaliam se uma especificao poder ser implementada, tendo em conta aspectos econmicos, financeiros, tecnolgicos, de mo de obra, de cronograma e sociais. Conjunto de atributos de qualidade que avaliam a compatibilidade entre o custo estimado para o desenvolvimento e operao do software e os benefcios esperados com sua utilizao. Caracterstica que avalia se as estimativas de custos, para o desenvolvimento e/ou produo do software, so aceitas por usurios e desenvolvedores. Caracterstica que avalia se as estimativas de benefcios tangveis e intangveis so aceitas como relevantes, por usurios e desenvolvedores. Caracterstica que avalia se os custos estimados para o desenvolvimento e operao so compatveis com os benefcios esperados com sua utilizao. Critrios de qualidade
Modificabilidade
Evolutibilidade
REUTILIZABILIDADE
Adaptabilidade
Generalidade
IMPLEMENTABILIDADE
Viabilidade Econmica
Aceitabilidade de Custos Relevncia dos Benefcios Compatibilidade Custo/Benefcio
Legenda Fatores de qualidade Subfatores de qualidade
Tabela AII.3 - Caractersticas de qualidade relacionadas ao objetivo Utilizabilidade para ERS (CLUNIE, 1997)
166
OBJETIVO: UTILIZABILIDADE (cont.)

Conjunto de atributos de qualidade que avaliam a existncia e Viabilidade Financeira disponibilidade de capital necessrio para conduzir o desenvolvimento do produto especificado. Existncia de Capital Caracterstica que avalia se a organizao possui capital suficiente para custear o desenvolvimento. Disponibilidade de Caracterstica que avalia se a organizao capaz de tornar Capital disponvel o capital necessrio para o desenvolvimento. Conjunto de atributos de qualidade que avaliam a existncia e Viabilidade disponibilidade da tecnologia necessria para conduzir o Tecnolgica desenvolvimento do produto especificado. Existncia da Caracterstica que avalia se existe o nvel de tecnologia Tecnologia necessrio para conduzir o desenvolvimento. Disponibilidade da Caracterstica que avalia se a equipe encarregada do Tecnologia desenvolvimento tem disponvel a tecnologia necessria para conduzir o desenvolvimento. Conjunto de atributos de qualidade que avaliam a existncia e Viabilidade de Mo disponibilidade da mo de obra necessria para conduzir o de Obra desenvolvimento do produto especificado. Existncia de Mo de Caracterstica que avalia se existe na instalao a mo de obra Obra necessria para o desenvolvimento. Disponibilidade de Caracterstica que avalia se esto disponveis os recursos Mo de Obra humanos com o conhecimento e experincia necessrios para realizar o desenvolvimento e operao do software. Conjunto de atributos de qualidade que avaliam se o software Viabilidade de pode ser construdo dentro do limite de tempo estabelecido. Cronograma Caracterstica que avalia se o software pode ser construdo no Adequabilidade de tempo previsto pelo cronograma, considerando possveis Cronograma ocorrncias de imprevistos e sem descuidar da qualidade definida para o produto. Flexibilidade de Caracterstica que avalia se o cronograma aceito para o Cronograma desenvolvimento pode atender, na medida do possvel, fatores tais como introduo de atividades no projetadas, contingncias etc. Conjunto de atributos de qualidade que avaliam as implicaes que o software que vai ser construdo ter sobre o grupo social ao Viabilidade Social qual este dever servir, assim como sobre qualquer outro grupo social externo. Aceitabilidade da Caracterstica que avalia se o software que vai ser construdo leva Engenharia Humana em considerao o grau de satisfao e o desenvolvimento do potencial humano previsto para os usurios. Aceitabilidade dos Caracterstica que avalia se o software que vai ser construdo leva Impactos Sociais em considerao seus impactos sobre o sistema social ao qual dever servir. Legenda Fatores de qualidade Critrios de qualidade Subfatores de qualidade
Tabela AII.3 - Caractersticas de qualidade relacionadas ao objetivo Utilizabilidade para ERS (continuao)
Os critrios relacionados aos subfatores: (i) verificabilidade (VER) e validabilidade (VAL) do fator avaliabilidade, (ii) modificabilidade (MOD) e evolutibilidade (EVO) do
167
fator manutenibilidade, (iii) adaptabilidade (ADA) e generalidade (GEN) do fator reutilizabilidade, deste objetivo de qualidade, esto indicados nas Tabelas AII.4 e AII.5.
UTILIZABILIDADE
VER VAL MOD EVO ADA GEN
C O N F I A B I L I D A D E R E P R E S E N T A O
COMUNICABILIDADE Correo no Uso do Mtodo Correo da Notao Correo Sinttica Correo Semntica Correo no Uso do Formato de Documentao Uniformidade de Terminologia Uniformidade de Termos Uniformidade de Notao Uniformidade no Nvel Abstrao Uniformidade de Detalhes da Documentao Independncia de Detalhes de Projeto Modularidade da Documentao Coeso das Informaes Acoplamento entre as Sees Estrutura da Documentao Correo da Arquitetura Conciso Complementabilidade Conformidade Aderncia a Normas da Organizao Desenvolvedora Aderncia a Normas estabelecidas pelo Contratante MANIPULABILIDADE Disponibilidade Acessibilidade Estar Atualizada Rastreabilidade Organizao da Documentao Localizabilidade Interna Localizabilidade Externa
X X X X X X X X X X
X X X X X X X X X X X
X X X
X X X X X
X X X X X
X X X X X
X X X X X
X X X X X
Tabela AII.4 - Caractersticas de qualidade do objetivo Confiabilidade da Representao, relacionadas ao objetivo Utilizabilidade para ERS (CLUNIE, 1997)
UTILIZABILIDADE
VER VAL MOD EVO ADA GEN
C O N F C O N C E I T U
FIDEDIGNIDADE Consistncia Consistncia Interna Consistncia Externa No Ambigidade Ser Explcita Preciso SUFICINCIA Necessidade Necessidade dos Requisitos No Redundncia No Redundncia de Informaes Completitude Completitude com Relao ao Mtodo de Desenvolvimento
X X X X
X X X X
X X X X
X X X X X X
168
Apndice II Atributos de Qualidade para ERS ____________________________________________________________________________________ _ A Completitude com Relao ao Roteiro Definido pela Organizao X L Completitude com Relao aos Requisitos X
Tabela AII.5 - Caractersticas de qualidade do objetivo Confiabilidade Conceitual, relacionadas ao objetivo Utilizabilidade para ERS (CLUNIE, 1997)
169
Apndice III
Instrumento para Hierarquizar Critrios de Qualidade para Especificaes d R i it d S ft
168
Apndice III Instrumento para Hierarquizar Critrios de Qualidade para ERS ____________________________________________________________________________________ _
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COPPE - PROGRAMA DE ENGENHARIA DE SISTEMAS E COMPUTAO Linha de Pesquisa - Engenharia de Software
Instrumento para Hierarquizar Critrios de Qualidade para Especificaes de Requisitos de Software (CLUNIE, 1997)
I. Objetivo Determinar o grau de importncia de um conjunto de atributos de qualidade para especificaes de requisitos de software em geral.
II. Instrues Atribua valores de 0 a 4, segundo a escala apresentada na Tabela AIII.1, aos critrios de qualidade definidos para Especificaes de Requisitos de Software de acordo com o grau de importncia na sua opinio e/ou experincia.
Grau de Importncia
Explicao
0 1 2 3 4
Indica que a caracterstica que est sendo apresentada no tem nenhuma importncia. Indica que a caracterstica que est sendo apresentada tem pouca importncia. Indica que a caracterstica que est sendo apresentada tem importncia em algumas circunstncias mas nem sempre. Indica que a caracterstica que est sendo apresentada muito importante. Indica de maneira absoluta que no h dvida que a caracterstica que est sendo apresentada imprescindvel. Tabela AIII.1 - Escala de Valores
III. Identificao do Avaliador
Nome do Avaliador: ______________________________________________ Instituio: ______________________________________________________
169
IV. Hierarquizao dos Critrios de Qualidade de Especificaes em Geral

OBJETIVO: CONFIABILIDADE DA REPRESENTAO Critrios Correo da Notao Correo Sinttica Correo Semntica Correo no Uso do Formato de Documentao Uniformidade de Termos Uniformidade de Notao Uniformidade de Detalhes da Documentao Independncia de Detalhes de Projeto Coeso das Informaes
1. 2. 3. 4. 5. 6. 7. 8. 9.
10. Acoplamento entre Sees 11. Estrutura da Documentao 12. Complementabilidade 13. Aderncia s Normas da Organizao Desenvolvedora 14. Aderncia s Normas Estabelecidas pelo Contratante 15. Acessibilidade 16. Estar Atualizada 17. Organizao da Documentao 18. Localizabilidade Interna 19. Localizabilidade Externa
Importncia 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4
170
1. 2. 3. 4. 5. 6. 7. 8. 9.
OBJETIVO: CONFIABILIDADE CONCEITUAL Critrios Consistncia Interna Consistncia Externa Ser Explcita Preciso Necessidade dos Requisitos No Redundncia das Informaes Completitude com Relao ao Roteiro definido pela Organizao Desenvolvedora Completitude com Relao ao Mtodo de Desenvolvimento Completitude com Relao aos Requisitos
Importncia 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4
OBJETIVO: UTILIZABILIDADE Critrios 1. 2. 3. 4. 5. 6. 7. 8. 9. Aceitabilidade de Custos Relevncia dos Benefcios Compatibilidade Custo/Benefcio Existncia de Capital Disponibilidade de Capital Existncia de Tecnologia Disponibilidade de Tecnologia Existncia de Mo de Obra Disponibilidade de Mo de Obra
10. Adequabilidade de Cronograma 11. Flexibilidade de Cronograma 12. Aceitabilidade dos Impactos Sociais 13. Aceitabilidade da Engenharia Humana
Importncia 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4
171
Apndice IV
Formulrio de Avaliao da Qualidade de Especificaes de Requisitos de Software
172
Apndice IV Formulrio de Avaliao da Qualidade de ERS ____________________________________________________________________________________ _
Critrios de Avaliao de Especificaes de Requisitos de Software (CAERS)

I. Instrues
Assinale de acordo com a escala abaixo, Tabela AIV.1, o valor que lhe parece melhor representar o grau em que cada critrio foi atingido (adaptado de CLUNIE, (1997)).
ESCALA
EQUIVALNCIA
INTERPRETAO
0 1 2 3 4
Indica de maneira absoluta que o critrio est ausente ou no possui nenhuma importncia. Baixa Presena Indica um baixo grau de presena do critrio, seja por deficincia ou pouca importncia do mesmo. Moderada Presena Indica um grau de presena moderada (aceitvel) do critrio. Alta Presena Indica um alto grau de presena do critrio, mas no de forma plena. Total Presena Indica que no h dvidas de que o critrio est totalmente presente.
Total Ausncia
Tabela AIV.1 - Graus de Presena do Critrio
Nome do Avaliador: _______________________________________ Fone: _________________ Instituio: _______________________
173
Especificaes de Requisitos de Software

OBJETIVO: Confiabilidade da Representao
1. Correo da Notao
Tcnica de Avaliao: Inspeo Individual
Definio: caracterstica que avalia se a notao do mtodo foi usada de forma correta. Processo de Avaliao: A especificao est escrita utilizando de forma correta a notao pr-definida no mtodo de especificao? Comentrios: Valores 1 2 3
2. Correo Sinttica
Definio: caracterstica que avalia se o conjunto de regras sintticas, pr-definidas no mtodo de especificao, foi usado de forma correta. Processo de Avaliao: Valores 0 1 2 3 4 A especificao est escrita utilizando de forma correta o conjunto de regras sintticas pr-definidas no mtodo de especificao? Comentrios:
3. Correo Semntica
Definio: caracterstica que avalia se o conjunto de regras semnticas pr-definidas no mtodo foi usado de forma correta. Processo de Avaliao: Valores 0 1 2 3 A especificao est escrita utilizando de forma correta o conjunto de regras semnticas pr-definidas no mtodo de especificao? Comentrios:
4. Correono Uso do Formato de Documentao Tcnica de Avaliao: Inspeo Individual Definio: caracterstica que avalia se o formato de documentao definido no mtodo foi usado de forma correta. Processo de Avaliao: Valores 0 1 2 3 4 A especificao est escrita utilizando de forma correta o formato de documentao definido no mtodo? Comentrios:
174
5. Uniformidade de Termos
Definio: caracterstica que avalia se os termos tcnicos foram utilizados de forma uniforme ao longo do texto e de acordo com as definies pr-estabelecidas. Processo de Avaliao: Valores 0 1 2 3 4 Os termos tcnicos so utilizados de forma uniforme ao longo da especificao e obedecem a definies pr-estabelecidas? Comentrios:
6. Uniformidade de Notao
Definio: caracterstica que avalia se a notao foi utilizada de forma uniforme ao longo do texto. Processo de Avaliao: A notao foi utilizada de forma uniforme ao longo da especificao e obedece a definies pr-estabelecidas? Comentrios: Valores 1 2 3
7. Uniformidade de Detalhes da Documentao
Tcnica de Avaliao: Reunio de Inspeo / Inspeo Individual Definio: caracterstica que avalia se todos os aspectos esto descritos na especificao com o mesmo nvel de detalhamento, considerando-se um determinado estgio de desenvolvimento. Processo de Avaliao: Valores 0 1 2 3 4 Os aspectos descritos na especificao apresentam o mesmo nvel de detalhamento, considerando-se o estgio de desenvolvimento? Comentrios:
8. Independncia de Detalhes de Projeto
Tcnica de Avaliao: Reunio de Inspeo / Inspeo Individual Definio: caracterstica que avalia na especificao de requisitos a existncia de restries com relao escolha de alternativas de soluo prprias da fase de projeto. Processo de Avaliao: Valores 0 1 2 3 4 A especificao de requisitos no apresenta descritas, restries com relao escolha de alternativas prprias da fase de projeto e/ou implementao? Comentrios:
175
9. Coeso de Informaes
Tcnica de Avaliao: Reunio de Inspeo / Inspeo Individual Definio: caracterstica que avalia o grau de associao das informaes de um captulo e, dentro deste, sees. Processo de Avaliao: Valores 0 1 2 3 4 A informao que apresenta o mdulo - captulo ou seo - descreve aspectos relacionados ao captulo ou seo que est sendo descrito? Comentrios:
10. Acoplamento entre Sees
Definio: caracterstica que avalia o grau de interdependncia entre os mdulos - captulos ou sees - da especificao. Processo de Avaliao: Valores 0 1 2 3 4 O contedo de um mdulo - captulo ou seo - faz referncia ao contedo de outro mdulo, apenas como complemento, sem modificlo? Comentrios:
11. Estrutura da Documentao
Definio: caracterstica que avalia se a estrutura, composta de captulos e, dentre sees, est organizada numa seqncia lgica. Processo de Avaliao: Valores 0 1 2 3 4 A especificao tem seus captulos e sees organizadas numa seqncia lgica? Comentrios:
12. Complementabilidade
Definio: caracterstica que avalia se a especificao faz uso de documentos auxiliares referncias, glossrios, dicionrios de dados - que facilitam seu entendimento. Processo de Avaliao: Valores 1. Existe um glossrio com definies de termos tcnicos, simbologia 0 1 2 3 4 e notao utilizados na especificao e que no so de uso comum? 2. Existe um dicionrio de dados centralizando as informaes? 3. Existe referncia a documentos prvios e/ou complementares necessrios ao entendimento da especificao? Comentrios: 0 0 1 1 2 2 3 3 4 4
176
13. Aderncia s Normas da Organizao Desenvolvedora
Definio: caracterstica que avalia se a especificao foi gerada considerando as normas estabelecidas pela organizao desenvolvedora. Processo de Avaliao: Valores A especificao foi gerada considerando as normas estabelecidas 0 1 2 3 4 pela organizao desenvolvedora? Comentrios:
14. Aderncia s Normas estabelecidas
pelo Contratante
Definio: caracterstica que avalia se a especificao foi gerada considerando as normas estabelecidas pelo contratante. Processo de Avaliao: Valores 0 1 2 3 4 A especificao foi gerada considerando as normas estabelecidas pelo contratante? Comentrios:
15. Acessibilidade
Definio: caracterstica que avalia se qualquer usurio autorizado pode facilmente consultar a especificao e/ou obter uma cpia da mesma. Processo de Avaliao: Valores 1. A especificao possvel de ser acessada por todos os seus 0 1 2 3 4 usurios autorizados? 2. A especificao pode ser facilmente reproduzida? 0 1 2 3 4 3. Existe uma cpia de segurana da especificao fora do local de trabalho? Comentrios: 0 1 2 3 4
16. Estar Atualizada
Definio: caracterstica que avalia se a especificao reflete a informao mais recente. Processo de Avaliao: 1. O contedo da especificao corresponde informao mais recente, fruto da ltima manuteno? 2. As atualizaes realizadas esto todas datadas? 3. As atualizaes realizadas esto claramente indicadas? Comentrios: Valores 1 2 3 1 1 2 2 3 3
0 0 0
4 4 4
177
17. Organizao da Documentao
Definio: caracterstica que avalia se o conjunto de especificaes est organizado de forma a facilitar sua manipulao. Processo de Avaliao: Valores 0 1 2 3 4 O conjunto de especificaes facilmente manusevel, em virtude da organizao de sua documentao? Comentrios:
18. Localizabilidade Interna
Definio: caracterstica que avalia se existem facilidades para se localizar todos os elementos, dentro de uma especificao, relacionados com determinado aspecto ou assunto. Processo de Avaliao: Valores 1. A especificao apresenta um sumrio? 0 1 2 3 4 2. Existem ndices remissivos? 3. Existem referncia cruzadas explcitas? Comentrios: 0 0 1 1 2 2 3 3 4 4
19. Localizabilidade Externa
Definio: caracterstica que avalia se existem facilidades para se localizar todas as especificaes e demais documentos relacionados a um determinado aspecto assunto. Processo de Avaliao: Valores 1. Existem sumrios que organizam os documentos? 0 1 2 3 4 2. Existem ndices remissivos? 3. Existem referncia cruzadas explcitas? Comentrios: 0 0 1 1 2 2 3 3 4 4
178

OBJETIVO: Confiabilidade Conceitual
1. Consistncia Interna
Tcnica de Avaliao: Reunio de Inspeo / Inspeo Individual Definio: caracterstica que avalia a existncia de conflitos entre aspectos especificados na mesma especificao. Processo de Avaliao: Valores 1. A especificao no apresenta termos diferentes que possuem o 0 1 2 3 4 mesmo significado e que so utilizados para descrever um mesmo objeto, que tratado em contextos e lugares diferentes? 2. A especificao no apresenta contradies entre caractersticas 0 1 2 3 4 especficas do produto? 3. A especificao no apresenta conflitos lgicos ou temporais entre requisitos do produto que dependem do tempo? 4. A especificao no apresenta conflitos na descrio de aspectos de comportamento do produto? Comentrios: 0 0 1 1 2 2 3 3 4 4
2. Consistncia Externa
Tcnica de Avaliao: Reunio de Inspeo / Inspeo Individual Definio: caracterstica que avalia a existncia de conflitos entre aspectos especificados em outras especificaes ou entidades externas. Processo de Avaliao: Valores 0 1 2 3 4 A especificao no apresenta aspectos conflitantes com relao a outras especificaes ou entidades externas? Comentrios:
3. Ser Explcita
Tcnica de Avaliao:Reunio de Inspeo/ Inspeo Individual Definio: caracterstica que avalia se na especificao existem condies, hipteses e/ou restries definidas por contexto. Processo de Avaliao: Valores 0 1 2 3 4 A especificao no apresenta aspectos definidos por contexto? Comentrios:
179
4. Preciso
Tcnica de Avaliao:Reunio de Inspeo/ Inspeo Individual Definio: caracterstica que avalia se os aspectos especificados esto descritos de forma precisa e, sempre que possvel, quantificada. Processo de Avaliao: Valores 1. Os termos de significado mltiplo, apresentam uma definio 0 1 2 3 4 precisa? 2. Os requisitos do produto esto descritos de forma possvel de serem validados? Comentrios: 0 1 2 3 4
5. Necessidade dos Requisitos
Tcnica de Avaliao:Reunio de Inspeo/ Inspeo Individual Definio: caracterstica que avalia se na especificao esto descritos os requisitos considerados imprescindveis. Processo de Avaliao: Valores 0 1 2 3 4 Os aspectos descritos na especificao so considerados imprescindveis? Comentrios:
6. No Redundncia de Informaes
Tcnica de Avaliao: Reunio de Inspeo / Inspeo Individual Definio: caracterstica que avalia se um mesmo aspecto descrito em mais de um lugar da especificao. Processo de Avaliao: Valores 0 1 2 3 4 A especificao no apresenta aspectos redundantes? Comentrios:
7. Completitude com Relao ao Roteiro Tcnica de Avaliao: Inspeo Individual Definido pela Organizao Desenvolvedora Definio: caracterstica que avalia se o roteiro definido pela organizao desenvolvedora foi totalmente coberto pela especificao. Processo de Avaliao: Valores O roteiro definido pela organizao desenvolvedora foi totalmente 0 1 2 3 4 coberto pela especificao? Comentrios:
180
8. Completitude com Relao ao
Mtodo de Desenvolvimento
Definio: caracterstica que avalia se foram utilizados todos os recursos previstos no mtodo de desenvolvimento. Processo de Avaliao: Valores 0 1 2 3 4 Todos os recursos que auxiliam na produo da documentao, que o mtodo que est sendo aplicado fornece, so utilizados? Comentrios:
9. Completitude com Relao aos
Tcnica de Avaliao:Reunio de Inspeo/ Inspeo Individual Requisitos Definio: caracterstica que avalia se na especificao esto definidos todos os requisitos do produto. Processo de Avaliao: Valores 1. Todas as funes a serem desempenhadas pelo software esto 0 1 2 3 4 definidas e modeladas? 2. Todas as necessidades de informao esto identificadas? 3. Todas as interfaces com o usurio esto identificadas? 4. Todas as interfaces com o ambiente de hardware esto identificadas? 5. Todas as interfaces com outros software esto identificadas? 6. Todas as possveis respostas que o sistema deve fornecer para todas as possveis classes de entrada constatadas, vlidas ou invlidas, esto identificadas? 7. Todas as caractersticas relativas ao desempenho do software esto identificadas? 8. Todas as caractersticas de qualidade exigidas pelo usurio esto identificadas? 9. Todas as caractersticas de qualidade inerentes ao software so identificadas? 10. Todas as categorias possveis de tratamento de erros e excees, por falhas de hardware e software esto identificadas? Comentrios: 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 4 4 4 4 4
0 0 0 0
1 1 1 1
2 2 2 2
3 3 3 3
4 4 4 4
181

OBJETIVO: Utilizabilidade
1. Aceitabilidade de Custos
Produto: Especificao de Requisitos
Definio: Caracterstica que avalia se as estimativas de custos, para o desenvolvimento e/ou produo do software, so aceitas por usurios e desenvolvedores. Processo de Avaliao: Valores 1. O custo estimado para o desenvolvimento do software aceitvel? 0 1 2 3 4 2. O custo estimado para operao do software aceitvel? Comentrios: 0 1 2 3 4
2. Relevncia de Benefcios
Definio: Caracterstica que avalia se as estimativas de benefcios tangveis e intangveis so aceitas como relevantes, por usurios e desenvolvedores. Processo de Avaliao: Valores 1. As estimativas de benefcios tangveis so aceitveis? 0 1 2 3 4 2. As estimativas de benefcios intangveis (atribuindo valores) so aceitveis? Comentrios: 0 1 2 3 4
3. Compatibilidade Custo/Benefcio
Definio: Caracterstica que avalia se os custos estimados para o desenvolvimento e operao do produto so compatveis com os benefcios esperados com sua utilizao. Processo de Avaliao: Valores 0 1 2 3 4 A relao custo/benefcio aceitvel? Comentrios:
4. Existncia de Capital
Definio: Caracterstica que avalia se a organizao possui capital suficiente para custear o desenvolvimento. Processo de Avaliao: Valores 0 1 2 3 4 A empresa possui capital suficiente para custear o desenvolvimento?
182
Comentrios:
5. Disponibilidade de Capital
Definio: Caracterstica que avalia se a organizao capaz de tornar disponvel o capital necessrio para o desenvolvimento. Processo de Avaliao: Valores 1. Existem recursos financeiros disponveis para o desenvolvimento? 0 1 2 3 4 2. Caso no estejam disponveis os recursos, existe a possibilidade de serem obtidos? Comentrios: 0 1 2 3 4
6. Existncia de Tecnologia
Definio: Caracterstica que avalia se existe o nvel de tecnologia necessrio para conduzir o desenvolvimento. Processo de Avaliao: Valores Existe a tecnologia necessria para desenvolver o software 0 1 2 3 4 especificado? Comentrios:
7. Disponibilidade de Tecnologia
Definio: Caracterstica que avalia se a equipe encarregada do desenvolvimento tem disponvel a tecnologia necessria para conduzir o desenvolvimento. Processo de Avaliao: Valores 1. A equipe encarregada pelo desenvolvimento dispe da tecnologia que 0 1 2 3 4 precisa em termos de hardware? 2. Caso a tecnologia de hardware no esteja disponvel, ela pode ser adquirida? 3. A equipe encarregada pelo desenvolvimento dispe da tecnologia que precisa em termos de software? 4. Caso a tecnologia de software no esteja disponvel, ela pode ser adquirida ou desenvolvida? Comentrios: 0 0 0 1 1 1 2 2 2 3 3 3 4 4 4
8. Existncia de Mo de Obra
Definio: Caracterstica que avalia se existe na instalao a mo de obra necessria para o desenvolvimento. Processo de Avaliao: Valores Existe a mo de obra para construir o software? 0 1 2 3 4
183
Comentrios:
9. Disponibilidade de Mo de Obra
Definio: Caracterstica que avalia se esto disponveis os recursos humanos com o conhecimento e experincia necessrios para realizar o desenvolvimento e operao do software. Processo de Avaliao: Valores 1. A organizao dispe de mo de obra para o desenvolvimento e 0 1 2 3 4 operao do software em termos de conhecimento e domnio da tecnologia? 2. Caso no disponha de mo de obra, para o desenvolvimento e 0 1 2 3 4 operao possvel adquiri-la por meio de treinamento? 3. Caso no disponha de mo de obra, para o desenvolvimento e operao possvel adquiri-la por meio de contratao de pessoal? Comentrios: 0 1 2 3 4
10. Adequabilidade de Cronograma
Definio: Caracterstica que avalia se o software pode ser construdo no tempo previsto pelo cronograma, considerando possveis ocorrncias de imprevistos e sem descuidar da qualidade definida para o produto. Processo de Avaliao: Valores O software possvel de ser construdo no tempo previsto pelo 0 1 2 3 4 cronograma? Comentrios:
11. Flexibilidade de Cronograma
Definio: Caracterstica que avalia se o cronograma aceito para o desenvolvimento pode atender, na medida do possvel, fatores tais como introduo de atividades no projetadas, contingncias etc.. Processo de Avaliao: Valores Existe flexibilidade de cronograma? 0 1 2 3 4 Comentrios:
Produto: Especificao de Requisitos 12. Aceitabilidade de Engenharia Humana Definio: Caracterstica que avalia se o software que vai ser construdo leva em considerao o grau de satisfao e o desenvolvimento do potencial humano previsto para os usurios. Processo de Avaliao: Valores 1. Poder o software especificado prover uma forma satisfatria para 0 1 2 3 4 que o usurio possa desempenhar a sua funo operacional? 2. Poder o software especificado satisfazer as necessidades humanas 0 1 2 3 4
184
em seus diversos nveis? 3. Poder o software especificado ajudar ao desenvolvimento das capacidades humanas? Comentrios: 0 1 2 3 4
13. Aceitabilidade dos Impactos Sociais
Definio: caracterstica que avalia se o software que vai ser construdo leva em considerao seus impactos sobre o sistema social ao qual dever servir. 0 1 2 3 4 Processo de Avaliao: O software especificado leva em considerao seus impactos sobre o sistema social ao qual dever servir? Comentrios:
185

Tese Fuzzy Belchior

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tese Fuzzy Belchior

Enviado por

Direitos autorais:

Formatos disponíveis

UM MODELO FUZZY PARA AVALIAO DA QUALIDADE DE SOFTWARE

Arnaldo Dias Belchior

Aprovada por: _________________________________________ Profa. Ana Regina Cavalcanti da Rocha, D.Sc.

_________________________________________ Prof. Geraldo Bonorino Xexo, D.Sc.

_________________________________________ Prof. Arndt von Staa, Ph.D.

_________________________________________ Prof. Carlos Alberto Nunes Cosenza, D.Sc.

_________________________________________ Prof. Jos Carlos Maldonado, D.Sc.

_________________________________________ Prof. Jano Moreira de Souza, Ph.D.

Rio de Janeiro, RJ - Brasil

UM MODELO FUZZY PARA AVALIAO DA QUALIDADE DE SOFTWARE

Arnaldo Dias Belchior

Programa: Engenharia de Sistemas e Computao

A FUZZY MODEL TO SOFTWARE QUALITY EVALUATION

Arnaldo Dias Belchior

Department: Computing and Systems Engineering

lineares dos critrios, que participaram do processo de ............... 109

Captulo I Introduo ___________________________________________________________________________

Captulo I Introduo ___________________________________________________________________________

Captulo II QUALIDADE DE SOFTWARE

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.1. Conceitos de Qualidade

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.2 Em Busca da Qualidade

Captulo II Qualidade de Software ___________________________________________________________________________

II.2.1 Qualidade de Processos de Software

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.2.1.2 Bootstrap e Trillium

II.2.1.3 O Projeto SPICE

Captulo II Qualidade de Software ___________________________________________________________________________

Avaliao do Processo leva Melhoria do Processo motiva Capacitao do Processo leva

II.2.2 Qualidade de Produtos de Software

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Tabela II.1: Caractersticas e subcaractersticas de software - ISO/IEC 9126

II.2.2.1 Modelos para Avaliao da Qualidade de Software

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.3 Mtricas de Qualidade de Software

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.3.1 Categorias de mtricas

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.3.2 Caractersticas das Mtricas

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.3.3 A Aplicao de Mtricas

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.3.4 Validao de Mtricas de Software

Captulo II Qualidade de Software ___________________________________________________________________________

Captulo II Qualidade de Software ___________________________________________________________________________

II.4 Tcnicas para Controle da Qualidade

Captulo II Qualidade de Software ___________________________________________________________________________

II.4.1 Walkthrough e Inspees