CHAU SEN SHIA - UNIP.br

UNIVERSIDADE PAULISTA - UNIP

PROGRAMA DE DOUTORADO EM ENGENHARIA DE PRODUÇÃO

MODELO DE APLICAÇÃO COM NEUROFUZZY

PARA APOIO NA TOMADA DE DECISÃO EM

PROJETOS DE SOFTWARE

CHAU SEN SHIA

Tese apresentada ao Programa de Pós-Graduação em Engenharia de Produção da Universidade Paulista – UNIP, para obtenção do título de Doutor em Engenharia de Produção.

.

SÃO PAULO

2013

UNIVERSIDADE PAULISTA - UNIP

PROGRAMA DE DOUTORADO EM ENGENHARIA DE PRODUÇÃO

MODELO DE APLICAÇÃO COM NEUROFUZZY

PARA APOIO NA TOMADA DE DECISÃO EM

PROJETOS DE SOFTWARE

CHAU SEN SHIA

Tese apresentada ao Programa de Pós-Graduação em Engenharia de Produção da Universidade Paulista – UNIP, para obtenção do título de Doutor em Engenharia de Produção. Área de Concentração: Gestão de Sistemas de Operação

Linha de Pesquisa: REDES DE EMPRESAS E PLANEJAMENTO DA PRODUÇÃO

Projeto de Pesquisa: Processos de Desenvolvimento e Operação de Sistemas de Informação. Orientador: Prof. Dr. Ivanir Costa

.

SÃO PAULO

2013

Shia, Chau Sen. Modelo de Aplicação com Neurofuzzy para Apoio na Tomada de Decisão em Projetos de Software. / Chau Sen Shia. – São Paulo, 2012. 200f. : il. color. + CD-ROM. Tese (doutorado) – Apresentada ao Programa de Pós Graduação em Engenharia de Produção da Universidade Paulista, São Paulo, 2012. Área de Concentração: Gestão de Sistemas de Operação. “Orientador: Prof. Ivanir Costa” 1. Qualidade de Serviços. 2. Norma SQuaRE. 3. Medida de Qualidade. 4. Lógica Fuzzy. 5. Redes Neurais I. Título.

AGRADECIMENTOS

Gostaria de agradecer a todos aqueles que me ajudaram nessa caminhada e de alguma

forma contribuíram e me apoiaram no transcorrer deste trabalho. Inicialmente agradeço ao

Prof. Dr. Ivanir Costa, meu orientador pelo empenho, dedicação na orientação deste trabalho e

à minha esposa pela sua paciência e aos meus filhos pela compreensão. Agradeço à UNIP e ao

departamento da Engenharia de Produção e a todos os professores que contribuíram para o

meu crescimento e conhecimento profissional; em especial aos professores: Prof. Dr.

Oduvaldo Vendrametto, Prof. Dr. José Benedito Sacomano , Prof. Dr. Mario Mollo Neto,

Prof. Dr. Pedro Luiz de Oliveira Costa Neto, Prof. Dr. Jair Minoro Abe e Prof. Dr. Ivan Pérsio

de Arruda Campos pela contribuição e transferência de conhecimento e sabedoria.

RESUMO

Com a globalização e o crescimento da demanda por produtos e serviços na área de TI,

as organizações para serem competitivas, tornam-se dependentes de tecnologias para o

desenvolvimento de seus processos produtivos em software e prestação de serviços, além

disso, novas exigências de conhecimentos em técnicas na gestão de qualidade são requeridas.

Um diferencial se apresenta no atendimento aos clientes, todavia as empresas

encontram dificuldades em estabelecer uma métrica ou medida de qualidade de serviços para

abordar de forma mensurável valores qualitativos, que aparecem no estabelecimento das

necessidades de seus clientes, no planejamento dos serviços e projetos de desenvolvimento de

software e na tomada de decisão em seus processos produtivos. Este trabalho propõe o uso da

lógica fuzzy e redes neurais (conhecido como neurofuzzy) para avaliar a qualidade dos

serviços e gestão desses processos, segundo a sua demanda utilizando a metodologia e o

modelo proposto nesta tese (aplicação desenvolvida, “sistema neurofuzzySQuaREBoehm”).

Como medida de qualidade, aplica-se a fundamentação baseada na norma SQuaRE

(medição da qualidade de produtos de software) e o modelo espiral de Boehm (para análise de

risco de projeto). A partir de estudos teóricos apresentados por diversos autores encontrados

na literatura sobre o assunto que envolve a área de gestão de processos e qualidade da

engenharia de software, o trabalho busca analisar e propor um modelo de software e

metodologia para garantir a tomada de decisão perante as incertezas e indecisões que ocorrem

durante um projeto em ambiente de TI. Foi desenvolvido um sistema de software, que

permitiu aos especialistas da área de TI (Tecnologia da Informação), participar do processo de

análise da qualidade de serviços já na fase inicial da solicitação de um pedido para um projeto

de software. A partir da coleta dos dados dos formulários preenchidos (Check-list) pelos

especialistas foi possível criar classificações das informações (utilizando redes perceptron) e

formar uma base de conhecimento para a tomada de decisão com as técnicas da neurofuzzy,

além de estabelecer uma medida de qualidade de serviços com o modelo proposto nesta tese.

Palavras-Chaves: Qualidade de Serviços, Norma SQuaRE, Medida de Qualidade, Lógica

Fuzzy, Redes Neurais.

ABSTRACT

With globalization and the growth in demand for products and services in the IT

(Information Technology) area, organizations to be competitive, they become dependent on

technologies for the development of its productive processes in software and services, in

addition, new knowledge requirements in quality management techniques are required. A

differential in customer service, but the companies encounter difficulties in establishing a

metric or measure of quality of services to address the qualitative values, which appear in the

establishment of the needs of its customers, in the planning of services and software

development projects and in decision-making in their production processes. This paper

proposes the use of fuzzy logic and neural networks (known as neurofuzzy) to assess the

quality of services and management of these processes, according to your demand using the

methodology and the model proposed in this thesis (application developed, "

neurofuzzySQuaREBoehmsystem").

As a measure of quality, applies to state reasons based on SQuaRE (quality

measurement software) and the Boehm spiral model (for project risk analysis). From

theoretical studies presented by several authors found in the literature on the subject that

involves the area of process management and software engineering quality, the work seeks to

analyze and propose a software model and methodology to ensure decision-making in the face

of uncertainty and indecision that occur during a project in the it environment. It was

developed a software system that allowed the specialists in the area of information technology

(it), participate in the process of analysis of the quality of services already in the initial phase

of the request of an application to a software project. From the collection of data from

completed forms (Checklist) by experts it was possible to create classifications of information

(using perceptron networks) and form a knowledge base for decision making with the

techniques of neurofuzzy, in addition to establishing a measure of quality of services with the

model proposed in this thesis.

Keywords: Quality of services, Standard SQuaRE, measure of quality, Fuzzy Logic, Neural

Networks.

LISTA DE FIGURAS

Figura 1- Modelo de economia, adaptado de Dorothy I. Riddle, Service-Led Growth, Praeger,

Nova York, 1989. ..................................................................................................................... 29

Figura 2-Classificação da qualidade através do fluxo de suas variáveis, adaptado de Garvin

(1987). ...................................................................................................................................... 45

Figura 3- Modelo de Gestão da Qualidade, adaptado de Carvalho e Paladini (2006). ............ 46

Figura 4- Função empresarial e processo de negócio, adaptado de Sordi (2005). ................... 51

Figura 5- Análise sistemática dos procedimentos de trabalho de Taylor, adaptado de Sordi

(2005). ...................................................................................................................................... 52

Figura 6- Novas teorias e práticas administrativas, adaptado de Sordi (2005). ....................... 52

Figura 7- Participação das áreas funcionais nos processos de negócios de uma empresa

manufatureira, Lambert (2001)................................................................................................. 54

Figura 8- Detalhes da participação da área funcional nos processos de negócios de uma

empresa manufatureira, Lambert (2001). ................................................................................. 54

Figura 9- Detalhes da participação da área funcional nos processos de negócios de uma

empresa manufatureira, Lambert (2001). ................................................................................. 55

Figura 10- Componente para medição de software (estrutura árvore), adaptado de Koscianski

e Soares (2006). ........................................................................................................................ 59

Figura 11-Classificação dos requisitos não funcionais, adaptado de: Kotonya e Sommerville

(1996) ....................................................................................................................................... 70

Figura 12- Estrutura da organização dos padrões, adaptado de Garcia (2009). ....................... 71

Figura 13- Evolução das normas e sua aplicação, adaptado de Garcia (2009). ....................... 73

Figura 14- Ciclo de vida de qualidade de software, adaptado de Garcia (2009). ..................... 74

Figura 15- Modelo de qualidade SQuaRE, adaptado de Garcia (2009). .................................. 75

Figura 16- Sistemas de Inferência fuzzy, Ludwing Junior (2007). ........................................... 82

Figura 17- Modelo Fuzzy Genérico, Aguiar e Oliveira Junior (2007). .................................... 84

Figura 18- Funções de Pertinência, Ludwing Junior (2007). ................................................... 86

Figura 19- Estratégia de Mandani, Weber (2003). ................................................................... 87

Figura 20- Estratégia de Takagi e Sugeno, Weber e Klein (2003). .......................................... 88

Figura 21- Representação das saídas modelo MANDANI, adaptado de Weber e Klein

(2003). ...................................................................................................................................... 89

Figura 22- Função de ativação, LUDWING e MONTGOMERY (2007). ............................. 112

Figura 23- Funções de transferências, LUDWING e MONTGOMERY (2007). .................. 112

Figura 24- Rede neural artificial x Mapeamento de Ajustes Sinápticos, fonte: autor. ........... 113

Figura 25- Modelo de rede neural artificial, fonte: autor. ...................................................... 114

Figura 26- Rede de neurônios em camadas, Ludwing e Montgomery (2007). ...................... 115

Figura 27- Rede neural perceptron Ludwing e Montgomery (2007). .................................... 116

Figura 28- Estrutura de uma rede perceptron, fonte: autor. ................................................... 117

Figura 29-Função de ativação, Ludwing e Montgomery (2007). ........................................... 117

Figura 30- Função de transferência, Ludwing e Montgomery (2007). .................................. 117

Equação 1- Expressão do processo de aprendizado, Ludwing e Montgomery (2007). ......... 118

Equação 2- Erro de saída do perceptron, Ludwing e Montgomery (2007). ........................... 119

Figura 31- Estrutura da metodologia desta tese (uma visão geral), fonte: autor. ................... 125

Figura 32- Estrutura da metodologia desta tese (parte 01 da estrutura desta tese), fonte:

autor. ....................................................................................................................................... 126

Figura 33- Estrutura da metodologia desta tese (parte 02 da estrutura desta tese), fonte:

autor. ....................................................................................................................................... 127

Figura 34- Formulário Check-List para coleta de dados sobre os níveis de impactos de riscos

de projeto (normaSQuaRE), autor. ......................................................................................... 131

Figura 35-Formulário de análise SQuaRE preenchido e média gerada do projeto imobiliário,

autor. ....................................................................................................................................... 132

Figura 36- Arquitetura básica do modelo proposto Sistema “NeuroFuzzySQuaREBoehm”

visão geral, autor..................................................................................................................... 134

Figura 37- Arquitetura básica do modelo proposto Sistema “NeurofuzzySQuaREBoehm” e

seus sub-componentes, autor. ................................................................................................. 135

Figura 38- Arquitetura básica do modelo proposto Sistema “FuzzyQuaRE” e seus sub-

componentes de links, autor. .................................................................................................. 136

Figura 39-Interface do sistema do “FuzzySQuaRE” ”. ........................................................... 137

Figura 40-Componente Matlab do sistema “NeuroFuzzySQuareBoehm”. ............................ 138

Figura 41-Modelo de interface do “sistema NeurofuzzySQuaREBoehm”, autor. ................. 141

Figura 42-Resultados da Funcionalidade e Níveis de Riscos de projeto, SQuaRE, autor. ..... 142

Figura 43-Resultados da base de dados em Excel para os atributos SQuaRE e níveis de riscos

de projeto, visão gerente, autor. .............................................................................................. 142


de projeto, visão analista, autor. ............................................................................................. 143


de projeto, visão programador, autor. ..................................................................................... 143

Figura 46-Resultados da análise da primeira semana do desenvolvimento do projeto na visão

do gerente de projeto. ............................................................................................................. 144

Figura 47-Análise de risco dos atributos SQuaRE e lógica fuzzy na visão do gerente de

projeto. .................................................................................................................................... 145

Figura 48-Análise de risco dos atributos SQuaRE na visão do gerente de projeto pelo Matlab.

146

Figura 49-Resultado da Análise de risco dos atributos SQuaRE na visão do gerente de projeto

imobiliário pelo Excel ............................................................................................................ 146

Figura 50-Resultado da Análise de risco dos atributos SQuaRE na visão do gerente de projeto

imobiliário pela RNA. ............................................................................................................ 147

Figura 51-Resultado da Análise de risco dos atributos SQuaRE na visão geral do projeto

imobiliário, gerado pelo aplicativo “FuzzySQuaRE”. ............................................................ 148

Figura 52-Formulário de análise SQuaRE preenchido e nível de risco gerada do projeto

imobiliário. ............................................................................................................................. 149


Estoque, na visão do gerente. ................................................................................................. 150

Figura 54-Resultado da base de dados da análise de risco dos atributos SQuaRE na visão geral

do gerente, gerado pelo sistema “FuzzySQuaRE”. ................................................................. 151

Figura 55-Resultado da evolução de risco na visão do gerente para o projeto Estoque......... 152

Figura 56-Formulário de análise SQuaRE preenchido e média gerada do projeto estoque

atribuídos pelo analista. .......................................................................................................... 152


serviços em informática. ......................................................................................................... 153

Figura 58-Arquitetura da rede Perceptron (sistema “PerceptronSQuaREBoehm”) do modelo

proposto, autor. ....................................................................................................................... 154

Figura 59- Interface do sistema “PerceptronSQuaREBoehm” do modelo proposto, autor.... 155

Figura 60-Base Excel “FuzzySQuaRE e NeurofuzzySQuaREBoehm”, do modelo proposto,

autor ........................................................................................................................................ 155

Figura 61- Base Excel “FuzzySQuaRE e seus componentes, do modelo proposto, autor ...... 156

Figura 62-Base Excel “NeurofuzzyuzzySQuaREBoehm” e seus componentes, do modelo

proposto, autor ........................................................................................................................ 157

Figura 63- Estrutura do Perceptron Multicamada, autor. ...................................................... 159

Figura 64- Diagrama de classe de análise RNA de uma BCN (Base de Conhecimento

Neuronal), autor. ..................................................................................................................... 160

Figura 65-Estrutura do modelo SQuaRE e a relação com o modelo espiral de Boehm,

autor. ....................................................................................................................................... 161

Figura 66-Base de conhecimento e aprendizado do perceptron Multicamada proposto para a

funcionalidade, autor. ............................................................................................................. 162

Figura 67-Interface do modelo Perceptron Multicamada (sistema

“PerceptronSQuaREBoehm”) proposto, autor. ...................................................................... 163

Figura 68-Base de conhecimento e aprendizado do perceptron Multicamada proposto para a

manutenibilidade, autor. ......................................................................................................... 163

Figura 69-Resultados dos testes do algoritmo de treinamento, autor. .................................... 163

Figura 70- Gráfico comportamental apresentado pelo atributo testabilidade em uma análise de

manutenibilidade, autor. ......................................................................................................... 164

Figura 71- Formulário check-listgerado pelo sistema “FuzzySQuaRE”, com a média

ponderada, visão do “gerente” do projeto controle de “estoque”, autor................................. 166

Figura 72- Formulário check-list gerado pelo sistema “FuzzySQuaRE”, com a média

ponderada, visão do “analista” do projeto controle de “estoque”, autor. ............................... 166

Figura 73- Formulário check-list gerado pelo sistema “FuzzySQuaRE”, com a média

ponderada, visão do “programador” do projeto controle de “estoque”, autor. ....................... 167

Figura 74- Estrutura da base de conhecimento (base Excel “NeurofuzzySQuaREBoehm”) para

o controle de “estoque”, autor. ............................................................................................... 168

Figura 75-Estrutura da base de conhecimento do perceptron (net1 e net2) com a norma

SQuaRE, autor. ....................................................................................................................... 169

Figura 76-Estrutura da base de conhecimento do perceptron (net1 e net2) com impactos dos

níveis de riscos da norma SQuaRE e lógica fuzzy, autor. ....................................................... 169

Figura 77- Parte da estrutura da base de conhecimento (base Excel

“NeurofuzzySQuaREBoehm”), da rede net1, autor. ................................................................ 170

Figura 78- Parte da estrutura da base de conhecimento (base Excel

“NeurofuzzySQuaREBoehm”), da rede net2, autor. ................................................................ 170

Figura 79- Curva de ajuste do aprendizado da rede perceptron para o sistema controle de

“estoque”, visão do gerente, autor. ......................................................................................... 170


“estoque”, visão do analista, autor. ........................................................................................ 171


“estoque”, visão do programador, autor. ................................................................................ 171

Figura 82- Classe de risco para risco “alto” e risco “baixo” para o sistema controle de

“estoque”, visão do gerente, analisado pela rede perceptron, autor. ...................................... 172


“estoque”, visão do analista, analisado pela rede perceptron, autor. ..................................... 173


“estoque”, visão do programador, analisado pela rede perceptron, autor. ............................. 174

Figura 85- Reconhecimento padrão dos atributos SQuaRE em relação à saída do nível de risco

de projeto, autor. ..................................................................................................................... 174

Figura 86-Tabela de transição de estados da maquina abstrata (M), autor. ........................... 176

Figura 87-Diagrama de transição de estados para os atributos SQuaRE e relação com modelo

de risco de projeto de Boehm, autor. ...................................................................................... 176

Figura 88-Diagrama de classe de análise da UML da tela de “Analise de Risco”, autor. ...... 177

Figura 89-Aplicativo da Análise de Risco, Relação do modelo SQuaRE x modelo de Boehm,

avaliação Risco Alto, autor. .................................................................................................... 178

Figura 90-Aplicativo da Análise de Risco, Relação do modelo SQuaRE x modelo de Boehm,

avaliação Risco aceitável, autor.............................................................................................. 179

Figura 91-Tabela de Resultados dos Estudos de Casos Pesquisados “Visão dos Gerentes”,

autor. ....................................................................................................................................... 180

Figura 92-Gráfico de Resultados dos Estudos de Casos Pesquisados “Gerentes de Projeto”,

autor. ....................................................................................................................................... 180

Figura 93-Tabela de Resultados dos Estudos de Casos Pesquisados “Analistas de Projeto”,

autor. ....................................................................................................................................... 181

Figura 94- Gráfico de Resultados dos Estudos de Casos Pesquisados “Analistas de Projeto”,

autor. ....................................................................................................................................... 181

Figura 95-Tabela de Resultados dos Estudos de Casos Pesquisados “Programadores de

Projeto”, autor. ........................................................................................................................ 182

Figura 97-Gráfico de Resultados dos Estudos de Casos Pesquisados “Programadores de

Projeto”, autor. ........................................................................................................................ 182

LISTA DE TABELAS

Tabela 1- Principais funções estratégicas da informação em serviços, adaptado de Porter

(1980). ...................................................................................................................................... 30

Tabela 2- Modelo de Produção, adaptado de Slack (2009). ..................................................... 31

Tabela 3- Processos de administração de produção de Processos de serviços, adaptado de

Chambers (2009). ..................................................................................................................... 31

Tabela 4- Diferença entre produtos e serviços, adaptado de Oliveira Netto (2006). ............... 32

Tabela 5- Categoria de clientes, adaptado de Gordon (1998). ................................................. 32

Tabela 6- Níveis de clientes, adaptado de Gordon (1998). ...................................................... 33

Tabela 7-Resumo sobre definições de Qualidade, adaptado de Costa; Epprechit e Carpinetti,

(2008). ...................................................................................................................................... 33

Tabela 8-Resumo sobre custos, adaptado de, Costa; Epprechit e Carpinetti, (2008). .............. 34

Tabela 9- Atividades Fundamentais de um Processo de Software, adaptado de: Sommerville

(2003). ...................................................................................................................................... 35

Tabela 10- Modelos de Processos, adaptado de Sommerville (2003). ..................................... 36

Tabela 11-Plano de projeto, adaptado de Sommerville (2003). ............................................... 40

Tabela 12- Atividades principais de qualidade de software, adaptado de Sommerville

(2003). ...................................................................................................................................... 41

Tabela 13- Atividade de garantia de qualidade de produto e de processo, adaptado de

Sommerville (2003). ................................................................................................................. 42

Tabela 14- Resumo histórico sobre a qualidade de produtos e serviços, adaptado de Carvalho

e Paladini (2006). ...................................................................................................................... 44

Tabela 15- Classificação de qualidade, adaptado de Garvin (1987). ....................................... 44

Tabela 16- Fatores considerados para serviços de qualidade, adaptado do autor Las Casas

(2007). ...................................................................................................................................... 46

Tabela 17- Resumo sobre custos, adaptado de, Costa; Epprechit e Carpinetti, (2008). ........... 48

Tabela 18- Processos de negócios, adaptado de Hammer e Champy (1994). .......................... 53

Tabela 19- Conflitos de processos, adaptado de Sordi (2005). ................................................ 56

Tabela 20– Vetores da gestão por processos, Laurindo e Rotondaro (2008). .......................... 57

Tabela 21- Estrutura da entidade GQM, adaptado de Koscianski e Soares (2006).................. 58

Tabela 22-Componentes da medição de qualidade do modelo SQuaRE, adaptado de

Koscianski e Soares (2006). ..................................................................................................... 60

Tabela 23-Critérios no modelo SQuaRE na elaboração de métricas, adaptado de Scalet

(1999) ....................................................................................................................................... 61

São estabelecidos de acordo com as necessidades dos ............................................................. 64

Tabela 24- Elementos principais do método GQM, adaptado de Basilis e Weiss (1984). ....... 64

Tabela 25-Tipos de qualidade da norma SQuaRE, adaptado de Koscianski e Soares (2006). 64

Tabela 26- Norma de qualidade SQuaRE, adaptado de Koscianski e Soares (2006). ............. 64

Tabela 27-Caracterização e Medição da norma SQuaRE, adaptado de Koscianski e Soares

(2006). ...................................................................................................................................... 66

Tabela 28-Caracterização e medição de software, adaptado de Koscianski e Soares (2006). . 66

Tabela 29- Modelo Espiral das fases e atividades, adaptado de Boehm (1988). ..................... 67

Tabela 30-Classificação de Risco, adaptado de (IEEE 1044.1, 1995). .................................... 69

Tabela 31-Classificação dos padrões da série ISO / IEC 9126 e 14598, adaptados da norma

ISO/IEC 9126 e 14598. ............................................................................................................ 72

Tabela 32- Qualidade dos produtos de software, adaptado de Weber e Rocha (1999). ........... 76

Tabela 33- Avaliação dos requisitos da qualidade, adaptado de Weber e Rocha (1999). ........ 77

Tabela 34- Vantagens de Sistemas Especialistas, adaptado de Fernandes (2004). .................. 81

Tabela 35- Técnicas da lógica fuzzy, segundo diversos autores da literatura. .......................... 85

Tabela 36- Modelos de Inferência fuzzy, adaptado de Ludwig Junior (2007). ......................... 88

Tabela 37- Função de pertinência, adaptado de Oliveira Junior (2007). .................................. 89

Tabela 38- Regras e operações fuzzy, adaptado de Ludwig Junior (2007). .............................. 90

Tabela 39- Princípios básicos de lógica fuzzy, adaptado de Shaw e Simões (2004). ............... 92

Tabela 40- Resumo da aplicação da lógica fuzzy segundo autores da literatura .................... 107

Tabela 41- Processos de avaliação que podem influenciar de forma negativa, adaptada de

Ludwing Junior (2007). .......................................................................................................... 108

Tabela 42- Fatores negativos gerados durante o processo de avaliação de solicitações de

serviços, adaptado de: Barki (1993) e Jiang (2002). .............................................................. 109

Tabela 43- Relação do modelo SQuaRE com as fases do modelo espiral de Boehm. ........... 161

SUMÁRIO

1. INTRODUÇÃO .............................................................................................................. 19

1.1. Apresentação do Trabalho ............................................................................................ 21

1.2. Motivação do Trabalho ................................................................................................. 22

1.3. Justificativa do Trabalho ............................................................................................... 24

1.4. Objetivos ....................................................................................................................... 25

1.4.1. Objetivo Geral ....................................................................................................... 25

1.4.2. Objetivos Específicos ............................................................................................ 25

1.4.3. Escopo.................................................................................................................... 26

1.4.4. Limitações deste Estudo ........................................................................................ 26

1.4.5. Hipótese ................................................................................................................. 26

1.4.6. Relevância do Trabalho ......................................................................................... 27

1.5. Metodologia da Pesquisa .............................................................................................. 27

1.6. Estrutura da Tese .......................................................................................................... 28

2. GESTÃO DA QUALIDADE E PROCESSOS DE NEGÓCIO .................................. 29

2.1. Serviços e a Administração .......................................................................................... 29

2.1.1. Diferenças entre Produtos e Serviços .................................................................... 31

2.1.2. Clientes e a sua Relação com o Negócio ............................................................... 32

2.1.3. O papel da Qualidade em Produtos e Serviços ...................................................... 33

2.2. Processos de Software .................................................................................................. 34

2.2.1. Dimensão e Fator de Qualidade ............................................................................. 37

2.2.2. Gerenciamento de Custo de Software.................................................................... 40

2.2.3. Desenvolvimento e Gerenciamento de Qualidade de Software ............................ 40

2.3. Gestão da Qualidade ..................................................................................................... 42

2.3.1. Serviços e Estratégias de Qualidade ...................................................................... 45

2.3.2. Valor do serviço e soma ponderada ....................................................................... 48

2.3.3. Escala de Likert ..................................................................................................... 48

2.3.4. Linha Divisória ou Limite de Decisão e Regressão............................................... 50

2.4. Função Empresarial e Processos de Negócios .............................................................. 50

2.4.1. Novas Teorias e Práticas Administrativas ............................................................. 52

2.4.2. Processos e Gestão de Negócios ............................................................................ 55

2.4.3. Gestão por Processos e Investimentos na Área de TI ............................................ 56

2.5. Qualidades de Software ................................................................................................ 57

2.5.1. Questões sobre a Qualidade das métricas .............................................................. 60

2.5.2. Medidas de Software ............................................................................................. 62

2.5.3. Método GQM (Goal-Question-Metric) ................................................................. 63

2.5.4. A NormaSQuaRE na visão de KOSCIANSKI e SOARES (2006) ....................... 64

2.5.5. Classificação de Riscos de Projeto (IEEE 1044.1, 1995) ...................................... 66

2.5.6. Modelo de Desenvolvimento de Software Espiral ................................................ 67

2.5.7. Engenharia de Risco .............................................................................................. 68

2.5.7.1. Classificação dos Riscos não Funcionais ...................................................... 69

2.5.7.2. Requisitos de Software ................................................................................... 70

2.5.8. Norma SQuaRE e as suas características............................................................... 71

2.5.9. Matlab e planilha Excel ......................................................................................... 78

3. TÉCNICAS DA LÓGICA FUZZY E REDES NEURAIS .......................................... 79

3.1. Sobre Inteligência Artificial ......................................................................................... 79

3.1.1. Sistemas Inteligentes ............................................................................................. 79

3.1.2. Sistemas Especialistas ........................................................................................... 80

3.1.3. Lógica Fuzzy ......................................................................................................... 82

3.1.3.1. Relação de Pertinência e Conexão ................................................................. 85

3.1.3.2. Funções de Pertinência .................................................................................. 85

3.1.3.3. Variáveis Linguísticas .................................................................................... 86

3.1.3.4. Inferência Fuzzy ............................................................................................. 86

3.1.3.5. Fuzzificação e Defuzzificação ........................................................................ 87

3.1.3.6. Regras Fuzzy .................................................................................................. 90

3.1.3.7. Lógica Fuzzy e a sua Aplicação em Sistemas Inteligentes ............................. 91

3.1.3.8. Lógica fuzzy e a sua aplicação segundo autores da literatura ...................... 92

3.1.4. Aplicação da Lógica Fuzzy em Sistemas de Informação e Processo de Solicitação

de Serviços ...................................................................................................................... 108

3.2. Redes Neurais Artificiais (RNAs) .............................................................................. 110

3.2.1. Neurofisiologia .................................................................................................... 110

3.2.1.1. Memória de Primeira Ordem ....................................................................... 111

3.2.1.2. Memória de Segunda Ordem ........................................................................ 111

3.2.2. Neurônio Matemático .......................................................................................... 111

3.2.3. Arquitetura da Rede Neural ................................................................................. 115

3.2.4. Perceptron Simples .............................................................................................. 116

3.2.5. Algoritmo de Aprendizado do Perceptron ........................................................... 117

3.2.6. Sistema Neurofuzzy ............................................................................................. 119

3.2.6.1. Controlador Neurofuzzy na forma Takagi e Sugeno .................................... 120

3.2.7. Regressão linear simples e Correlação ................................................................ 121

4. METODOLOGIA DO TRABALHO .......................................................................... 123

4.1. Problemas de Pesquisa ................................................................................................ 127

4.2. Estratégias da Pesquisa ............................................................................................... 129

4.3. Utilização do formulário (check-list) para obtenção dos riscos em projetos .............. 129

4.4. Coleta e Análise de Dados .......................................................................................... 130

4.5. Materiais e Métodos ................................................................................................... 133

5. APLICAÇÃO DA LÓGICA FUZZY E REDES PERCEPTRON ... ........................ 134

5.1. Técnicas da Lógica Fuzzy e Estatística ...................................................................... 134

5.1.1. Aplicação do modelo proposto com as técnicas da lógica fuzzy......................... 140

5.1.2. Teste de avaliação dos especialistas de TI para as técnicas da lógica fuzzy ....... 144

5.1.3. Aplicação da metodologia em outros tipos de projetos ....................................... 149

5.2. Fatores de Risco e Integração do modelo SQuaRE com a Rede Perceptron .............. 153

5.3. Aplicação da rede perceptron multicamada com o modelo SQuaRE ......................... 157

5.4. Integração da rede perceptron multicamada como classificação de Qualidade e análise

de riscos de projetos ........................................................................................................... 160

5.4.1. Conclusão dos testes e avaliação dos especialistas de TI para as técnicas da rede

neural perceptron multicamada ...................................................................................... 164

5.5. Integração da rede perceptron multicamada e análise de risco para controle de

“estoque” ............................................................................................................................ 165

5.6. Aplicação e integração da análise de risco do modelo SQuaRE com modelo de Boehm

através do grafo de estado e estrutura do tipo árvore ......................................................... 175

5.7. Análise dos Resultados dos Estudos de Casos Pesquisados e Avaliação dos

Especialistas da área de TI.................................................................................................. 179

6. APRESENTAÇÃO DOS RESULTADOS .................................................................. 183

6.1. Avaliação da Estrutura para a Análise da Solicitação de Serviços ............................. 183

6.2. Avaliação das Métricas Qualitativas no Controle da Qualidade em Ambientes da

Tecnologia da Informação .................................................................................................. 183

6.3. Avaliação das Questões de Riscos de Projeto ............................................................ 184

6.4. As Relações das Técnicas Fuzzy e Tomada de Decisão ............................................. 184

6.5. A Aplicação da Rede Neural como Base de Aprendizagem ...................................... 185

7. CONSIDERAÇÕES FINAIS ....................................................................................... 186

7.1. Conclusão ................................................................................................................... 187

7.2. Sugestões para Trabalhos Futuros .............................................................................. 188

REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................... 190

19

1. INTRODUÇÃO

A demanda por serviços para empresas de desenvolvimento de software tem se

mostrado crescente e considerável, (LUDWING Jr, 2007). Segundo Santos (2000), a

terceirização é vista como uma estratégia empresarial de concentração dos esforços e

inteligência nas atividades-fim deixando as atividades-meio a cargo dos parceiros

especializados que melhor exerçam suas funções e tragam melhores resultados com ganhos

para ambas as partes. Muitas solicitações de serviços são realizadas frequentemente para

diversas consultorias e muito desses processos de requisições são avaliados de forma

negativa, não satisfazendo a necessidade de seus clientes.

Conforme Ludwing Jr. (2007), alguns dos fatores que refletem de forma negativa na

avaliação das solicitações de serviços e influencia negativamente um processo de avaliação

são classificadas em: a) concorrência, b) variação do nível de detalhe dos documentos, c) não

disponibilidade de profissionais para atendimento ao usuário, d) dificuldade de prever (com

base na limitada quantidade de informação), e) pouco tempo para a emissão da proposta, e)

limitação das ferramentas para medir o tamanho do sistema, f) falta de conhecimento das

características da infraestrutura tecnológica, além das características intangíveis dos tipos de

serviços, tomadas de decisão que são realizadas para parâmetros qualitativos e ambiente

mutável.

Outro fator que deve ser considerado numa proposta de prestação de serviços é o fato

de que uma vez emitida, os termos não poderão ser alterados e os prazos deverão ser

cumpridos (LUDWING Jr., 2007).

Diante dessas dificuldades torna-se necessário não apenas quantificar os esforços para

atender as necessidades do cliente, é preciso identificar os principais fatores de riscos que

podem contribuir para o atraso de projetos e dimensionar os valores qualitativos para

melhorar a elaboração de solicitação das propostas comerciais.

Para Las Casas (2007), serviços são atos, ações e desempenho, pois objetiva todas as

categorias de serviços, quer sejam agregados a um bem ou não. O produto final de um serviço

é sempre um sentimento, pois os clientes ficam satisfeitos ou não conforme suas expectativas,

dessa forma a qualidade de um serviço é variável de acordo com o tipo de pessoa. Já a

qualidade segundo Karl (1992), é a capacidade que uma experiência ou qualquer outro fator

tenha para satisfazer uma necessidade, resolver um problema ou fornecer benefícios a alguém,

20

isto é a capacidade de proporcionar satisfação. A qualidade e o serviço estão relacionados ao

atendimento e na forma de tratar ou solucionar um problema, e isso necessita de atenção,

dedicação, habilidade e treinamento; além da avaliação e atuação sobre os resultados das

análises obtidas para eventuais mudanças ou melhorias na qualidade do atendimento aos

serviços prestados. Pode divergir e ter significados diferentes para as pessoas. Segundo

Carvalho e Paladini (2006), a qualidade é um termo utilizado no cotidiano, mas um

significado é diverso e dificilmente se chegará a um consenso. O uso das técnicas da lógica

fuzzy pode contribuir na eliminação das indecisões na gestão de processos, utilizando-se as

técnicas das variáveis linguísticas. Isso se torna possível devido aos princípios da lógica fuzzy:

− Estão na compreensão da lógica clássica de Aristóteles,

− Na própria lógica fuzzy,

− Nas expressões verbais,

− No raciocínio humano,

− Na função de pertinência,

− Na probabilidade,

− Nos números fuzzy,

− Nas variáveis linguística.

Conforme Braga e Machado (1995), a lógica fuzzy é “uma tentativa de aproximar a

precisão característica da Matemática à inerente imprecisão do mundo real, nascida do desejo

profundo de conhecer melhor os processos mentais do raciocínio”.

Deste trabalho resultou as seguintes fases de atividades: a) desenvolvimento de um

sistema de software (chamado de “NeurofuzzySQuaREBoehm”) para a simulação das técnicas

da lógica fuzzy (auxiliar nas tomadas de decisões durante as indecisões), b) aplicação da

norma SQuaRE (auxiliar na avaliação e medida de qualidade dos serviços), c) utilização das

redes neurais (para a criação de uma base de conhecimento) e d) modelo espiral de Boehm

(para análise de riscos de projeto) para auxiliar os especialistas de TI na tomada de decisão

em um projeto de software, e reduzir o impacto de risco de projeto e gerenciamento do

cronograma de um desenvolvimento de software.

21

1.1. Apresentação do Trabalho

Várias são as tecnologias disponíveis para auxiliar os engenheiros de software no

momento da tomada de decisão durante o ciclo de vida de um produto ou serviços de TI.

Muitas vezes as incertezas e imprecisões estão presentes em cada fase de um projeto de

software, durante o ciclo de vida desse projeto.

Em uma Gestão da Qualidade de um software envolvem conhecimentos e

aprendizados de outras áreas da ciência, assim como: a matemática, a biologia, a engenharia

de produção, a psicologia, entre outras áreas do conhecimento humano. As experiências

práticas dos especialistas de cada área específica (ambientes de TI) podem auxiliar, além de

contribuir nas decisões dos fatos considerados relevantes e devem ser considerados durante a

abordagem na determinação de um processo de software.

A proposta deste trabalho está na criação de um modelo de sistema de software para

auxiliar na tomada de decisão utilizando: a) recursos da lógica fuzzy para auxiliar nas

indecisões, b) norma SQuaRE para controle de serviços, c) neurônios múltipla camada (MLP)

para classificação das características da norma SQuaRE e d) modelo espiral da engenharia de

software para auxiliar na identificação de riscos de projeto de software. Para a fundamentação

da Qualidade de Software na procura da melhoria de qualidade para a criação de produtos ou

serviços de TI, aplica-se também a métrica estabelecida para a medida de qualidade conhecida

como métrica GQM (Goal-Question-Metric), o indicador de qualidade de software, cujo

objetivo é de auxiliar na organização e planejamento de um projeto em um ambiente de TI, e

permitir que seja possível a redução de riscos durante as etapas do ciclo de vida do

desenvolvimento de um software. O modelo proposto nesta tese apresenta a relação do

método GQM com o modelo espiral proposto por Boehm (1988) para a redução de riscos de

projeto, pois neste modelo mostram-se as principais atividades existentes em um ambiente de

TI; além disso, permite auxiliar (os especialistas) no controle dos processos de prestação de

serviços e verificar o que deve ser melhorada. O indicador de qualidade SQuaRE, analisa as

características de qualidade presentes na ISO 9126 (2003), que são classificadas em: a)

funcionalidade, b) manutenibilidade, c) usabilidade, d) confiabilidade, e) eficiência e f)

portabilidade. O modelo neurofuzzy (matemático), utilizado para desenvolver o aplicativo

proposto nesta tese, analisa a aplicação de recursos para execuções simultâneos e paralelos

das avaliações de qualidade de serviços, permitindo análises de problemas e soluções do

mundo real em relação às propostas e serviços prestados em ambientes de TI. Sabe-se que os

22

problemas do mundo real nesse tipo de ambiente são analógicos e de incertezas, desta forma,

muitas vezes as soluções exigem buscas por soluções rápidas nas tomadas de decisões.

Utilizam-se neste trabalho os conceitos sobre a qualidade de software presentes na

ISO/IEC 25000, da norma SQuaRE e de um formulário (Check-List) como fonte de coleta de

dados de entradas para a rede neural perceptron múltiplas camadas (MLP), além dos

conceitos da lógica fuzzy, medida de qualidade GQM (Goal-Question-Metric) e modelo de

Boehm (1988), disponíveis nas literaturas especializadas.

Cria-se um modelo de rede neural e lógica fuzzy (neurofuzzy) com aplicação dos

questionários (GQM) sobre a Qualidade de Software da norma SQuaRE. Em seguida, realiza-

se a coleta das informações das características descritas pela norma SQuaRE para controle de

serviços de software e realiza-se simulações com as técnicas da lógica fuzzy e rede neural

(neurofuzzy). Com a prática dos testes, obtém-se a análise dos resultados e de sua

aplicabilidade representada graficamente através de recursos disponíveis na planilha

eletrônica. Dos resultados obtidos da simulação e do modelo de software desenvolvido, é

possível desenvolver um framework ou infraestrutura de inteligência computacional para

auxiliar na Gestão de Qualidade em desenvolvimento de produtos e serviços de software,

utilizando as técnicas da neurofuzzy.

1.2. Motivação do Trabalho

Segundo pesquisa realizada em 1999 pelo Ministério da Ciência e Tecnologia do

governo federal (http://www.mct.gov.br, 2003), o mercado interno brasileiro de software

estava projetado para US$ 3,2 bilhões para o ano de 2000, com a predominância de micro e

pequenas empresas e a existência de quase 47% de terceirização de serviços de

desenvolvimento e manutenção de software. Já de acordo com Standish Group (STANDISH,

1995), as conclusões obtidas em suas pesquisas revelam que apenas 16,2% dos projetos

terminam no prazo previsto e 31,1% dos projetos são contestados, além de exceder o custo

médio de 189% do que foi estabelecido e o prazo médio da entrega em 222% em relação ao

cronograma estabelecido em seus requisitos propostos. Conforme Paula Filho (2003), com

base de dados de 4.000 projetos: 70% dos projetos de grandes aplicativos sofrem instabilidade

dos requisitos, 50% dos projetos são executados com níveis de produtividade abaixo do

normal, 50% dos produtos feitos por encomenda apresentam níveis de defeitos superiores ao

razoável, 50% dos grandes projetos de software excederam seu orçamento e prazo, 66,66%

23

dos projetos de software muito grandes são cancelados antes do final, 50% do patrimônio de

software das empresas não são usados e atritos com clientes ocorrem, no desenvolvimento de

aplicativos (50% com contratos por administração e 65% por contratos por empreitada).

Nesse contexto de globalização e crescimento da economia influenciado pela

tecnologia da informação, O´Brien (2002), muitos especialistas acreditam que devem ser

criados novos conceitos e maneiras de produzir e fornecer novos produtos e serviços a fim de

se conseguir grandes mudanças em produtividade (LAUDON e LAUDON, 1999). Foram

levantados alguns questionamentos em relação aos problemas que podem ocorrer no

gerenciamento de uma solicitação de serviços de software (que foram agrupadas em:

solicitação de pedido, riscos de projetos, qualidade de serviços, gestão de processos, normas

de avaliação de serviços e medida de serviços de qualidade) tais como:

• Solicitação de serviços de software:

− Quais as consequências da demanda por serviços de software, crescente?

− Por que os processos de requisições são avaliados de forma negativa?

− Por que as tomadas de decisão são realizadas de forma qualitativas se o ambiente

é mutável?

− Como cumprir uma proposta de prestação de serviços, se uma vez emitida, os

termos não poderão ser alterados e os prazos deverão ser cumpridos?

• Riscos de projetos:

− A identificação dos principais fatores de riscos que podem contribuir para o atraso

de projetos e dimensionar os valores qualitativos permitem melhorar a elaboração

de solicitação das propostas comerciais?

− Como eliminar o risco de defeitos o máximo possível em uma solicitação de

serviços de software?

− Quais são os modelos de projeto que podem auxiliar a minimizar os riscos de

desenvolvimento de software?

24

• Qualidade de serviços:

− A qualidade é uma definição que pode divergir e ter significados diferentes para

as pessoas. Como satisfazer as necessidades dos clientes?

− Quais são as principais definições de qualidade e como são as suas propriedades?

• Gestão de processos:

− Como gerenciar indecisões na gestão de processos e tomadas de decisões de

projeto?

− Quais são as técnicas para auxiliar desenvolvedores de software nas fases de

indecisão?

− É possível criar uma base de conhecimento para auxiliar especialistas de TI

durante o ciclo de vida de desenvolvimento de software?

• Normas para avaliar serviços:

− Quais são as consequências da falta de normalização para avaliação e medida de

qualidade dos serviços.

− Quais são as normas que gerenciam serviços de software?

• Medidas de serviços de qualidade:

− Como estimar o tamanho de um projeto de software?

− Como identificar um padrão de unidade de medida para produção e serviços de

qualidade?

− A identificação de uma unidade de medida para a qualidade de serviços permite

criar uma métrica de avaliação?

1.3. Justificativa do Trabalho

Segundo a pesquisa realizada pelo Ministério da Ciência e Tecnologia

(http://www.mct.gov.br, 2002), o desenvolvimento de programas personalizados representa

25

64,8% de desenvolvimentos realizados em 1999. Isso demonstra que esse tipo de serviço tem

sido muito difundido no mercado brasileiro. Apenas 11,8% das empresas brasileiras aplicam a

gestão de riscos de projetos de software dentro de suas organizações. De acordo com a

GARTNER GROUP (2001), inovações tecnológicas têm apresentado um forte crescimento

no segmento de serviços na nova economia (US$ 2 bilhões em 2000 e US$ 10 bilhões em

2001), levando as organizações a buscar um controle de suas atividades estratégicas através

de práticas de gerenciamento de projetos. No entanto observa-se que novos projetos não

incorporam as práticas de gerenciamento de projeto nas organizações, possibilitando o

fracasso nos projetos atuais.

1.4. Objetivos

O objetivo deste trabalho é de propor e desenvolver um modelo de inferência e métrica

que sejam capazes de auxiliar nas tomadas de decisões com base nas técnicas da lógica fuzzy.

Com a rede neural (neurofuzzy), realizar a classificação e analisar o grau de incerteza

na avaliação de solicitações de serviços para desenvolvimento de software segundo os fatores

subjetivos que devem ser valorados em uma proposta comercial e registrar uma base de

conhecimento e aprendizado que auxilie na relação da qualidade de serviço (SQuaRE). E com

o modelo espiral (proposto por BOEHM) reduzir o impacto de risco em gestão de projeto

(utilizada na engenharia de software).

1.4.1. Objetivo Geral

Propor um modelo neurofuzzy com redes neurais do tipo perceptron múltiplas

camadas (MLP – Multilayer Perceptron) e técnicas da lógica fuzzy para auxiliar nas tomadas

de decisões de projetos em ambientes de TI, e estabelecer uma métrica quantitativa a partir de

dados qualitativos e motivar a participação dos especialistas das áreas da organização, desde

as fases iniciais de uma solicitação de serviços de software.

1.4.2. Objetivos Específicos

I. Definir conceitos de serviços, engenharia e qualidade de software, lógica fuzzy e

redes neurais (neurofuzzy).

26

II. Desenvolver modelos e aplicações com técnicas da lógica fuzzy e rede de

neurônios do tipo perceptron múltipla camada (MLP) com a aplicação do controle

da qualidade de serviços de TI da norma SQuaRE. Em seguida, aplicar a relação

da norma SQuaRE com o modelo espiral da engenharia de software, para

apresentar os impactos de riscos de projetos de software.

III. Implantar e analisar o modelo proposto com as ferramentas Matlab e planilha

eletrônica para validar as simulações da proposta deste trabalho.

1.4.3. Escopo

O escopo deste trabalho abrange as organizações de prestação de serviços em

informática, principalmente aquelas que trabalham com a terceirização de serviços de TI na

atualidade.

1.4.4. Limitações deste Estudo

As metodologias e técnicas apresentadas neste trabalho, seguiram autores consagrados

sobre os assuntos propostos na gestão da qualidade, engenharia de software (riscos de

projetos), serviços, processos, lógicas fuzzy e redes neurais.

Entretanto, existem restrições e limitações que devem aparecer no decorrer desse

trabalho. Uma das restrições e limitações são as amostras obtidas nas empresas em relação à

coleta de dados para a análise dos impactos de riscos de um projeto.

Apesar da limitação imposta entende-se que o propósito da pesquisa é de agregar valor

às atividades de controle de qualidade com a aplicação das técnicas de tomadas de decisão

com base nas incertezas, auxiliadas pelas técnicas da lógica fuzzy e redes neurais (neurofuzzy).

1.4.5. Hipótese

Como hipótese, o trabalho propõe: estabelecer uma relação de controle de qualidade

de serviços (medidas qualitativas) e inferência computacional, que seja similar à inteligência

humana para auxiliar nas tomadas de decisões em prestação de serviços de software.

27

Desenvolver uma medida de qualidade em que se aplicam as técnicas da lógica fuzzy e

rede neural artificial, juntamente com as normas SQuaRE (controle de qualidade de serviços)

e modelo espiral de BOEHM, para controle de impacto de risco de projeto. Desenvolver um

sistema para gerenciamento de projeto de software, utilizando os recursos disponíveis da

planilha Excel e Matlab para validar as consistências do modelo proposto nesta tese, através

dos gráficos e textos descritos em seus resultados.

1.4.6. Relevância do Trabalho

Avalia-se que esta tese possui relevância, pois:

I- O estudo relaciona a análise das métricas qualitativas da qualidade de serviços de

software.

II- Criar um modelo que relaciona medidas qualitativas e quantitativas para auxiliar

nas tomadas de decisões durante as fases de indecisão de um projeto.

III- Criar um modelo de classificação de controles de qualidade de serviços e

impactos de riscos de projeto.

1.5. Metodologia da Pesquisa

Aplicou-se a metodologia da pesquisa exploratória, descritiva, explicativa,

quantitativa, qualitativa e bibliográfica para a realização dos objetivos a serem alcançados.

Segundo Souza, Fialho e Otani (2007), uma pesquisa exploratória consiste em explorar o

tema buscando criar familiaridade em relação a um fato ou fenômeno, geralmente feita

através de um levantamento bibliográfico. Uma pesquisa descritiva trata da descrição do fato

ou do fenômeno através de levantamento ou observação. Quanto à pesquisa quantitativa,

considera que tudo pode se quantificado, o que significa traduzir em números opiniões e

informações para classificá-las e analisá-las. Para a pesquisa qualitativa, considera-se que há

uma relação dinâmica ente o mundo real e o sujeito (vínculo indissociável ente o mundo

objetivo e a subjetividade do sujeito que não pode ser traduzido em números). Na pesquisa

bibliográfica, consiste da obtenção de dados através de fontes secundárias, pois utiliza como

fonte de coleta de dados materiais publicados (livros, periódicos científicos, revistas, jornais,

teses ou dissertações).

28

A abordagem deste trabalho foi com base nas pesquisas bibliográficas o “estado da

arte” em gestão da qualidade em serviços de desenvolvimento de software, medidas de

software, normas SQuaRE, modelo de software espiral, técnicas da lógica fuzzy e redes

neurais. Após a análise bibliográfica, foram identificados os fatores de riscos de projetos, os

impactos negativos no processo de avaliação da solicitação de serviços e dificuldades nas

medições de software.

Após a abordagem, foram identificadas as principais características de medição de

qualidade de produto de software proposto pela norma internacional ISO/IEC 25000, o

modelo em espiral proposto por Boehm (1988), para análise de risco de projeto de software,

as técnicas da lógica fuzzy para auxiliar nas tomadas de decisão, utilizando como base a

opiniões dos especialistas, transformando variáveis linguísticas e qualitativas (representante

dos fatores de risco), em dados numéricos, além da rede neural que tem a capacidade de

classificação dos impactos de riscos de projeto (OLIVEIRA JUNIOR, 2007).

1.6. Estrutura da Tese

No primeiro capítulo apresenta-se o trabalho, os objetivos, a hipótese e a relevância do

estudo. O capítulo 2 apresenta os fundamentos da gestão da qualidade e processos de negócio.

O capítulo 3 concentrou-se sobre a lógica fuzzy e redes neurais.

Para o capítulo 4, trata-se da metodologia do trabalho do problema da estratégia e

coleta de dados para a pesquisa. No capítulo 5, aplica-se a lógica fuzzy e redes de percerptron

múltipla camada (MLP – Multilayer Perceptron). No capítulo 6, apresentam-se os resultados

da simulação. Finaliza-se com o capítulo 7 e as considerações finais desta tese.

29

2. GESTÃO DA QUALIDADE E PROCESSOS DE NEGÓCIO

Este capítulo apresenta a fundamentação teórica sobre a gestão da qualidade, já na

construção foi desenvolvida a partir da revisão bibliográfica sobre os principais autores de

Gestão da Qualidade.

2.1. Serviços e a Administração

Segundo Riddle (1986), o fluxo das atividades dos principais setores da economia é:

extrativista (mineração e agricultura), o manufatureiro e de serviços. Os serviços dividem-se

em subgrupos, tais como: empresariais (consultoria, finanças, bancos), comerciais (varejo,

manutenção, consertos), infraestrutura (comunicação, transporte), sociais/pessoas

(restaurantes, saúde) e administração pública (educação, governo). Na figura 1, representam-

se os principais componentes de um modelo de economia onde envolvendo os principais

setores da economia que são: empresas, serviços, extração, infraestrutura, pessoas,

administração e manufatura, tanto de órgão públicos ou privados e o principal objetivo é o

atendimento e a satisfação ao cliente.

Figura 1- Modelo de economia, adaptado de Dorothy I. Riddle, Service-Led Growth, Praeger, Nova York, 1989.

O setor de serviços não só facilita como torna possível a realização das atividades de

produção de bens, tanto do setor extrativista como manufatureiro. Os serviços são a força vital

para a atual mudança rumo à economia globalizada, (FITZSIMMONS, 2003). Quanto à

Serviços de Infraestrutura

Serviços Empresariais

Serviços Sociais / Pessoais

Serviços Comerciais

Setor Extrativista

Setor Manufatureiro

Administração Pública

Cliente C

lient

e

30

classificação dos serviços, Schmenner (1986) propõe uma matriz de processos de serviços

para demonstrar que os problemas gerenciais similares entre as diversas indústrias de serviços

(em termos de grau de intensidade da mão de obra e grau de interação e personalização). As

dificuldades de identificação de produtos de serviços estão na sua natureza de intangibilidade.

Segundo Porter (1980), existem três estratégias competitivas genéricas (liderança

global em custo, diferenciação e focalização). Na tabela 1, descrevem-se as principais

estratégia e funções, com o foco principal no cliente, a padronização de serviços, redução de

custos e riscos, a satisfação do cliente com a qualidade de atendimento de produtos e serviços.

Estratégias Descrição

1-Liderança global em custo.

1.1-Procura por Clientes de Baixo Custo. 1.2-Padronização de um Serviço Personalizado. 1.3-Redução da Interação no Atendimento em Serviços. 1.4-Redução dos Custos de Rede (de prestadores de serviços). 1.5-Operação de Serviço off-line.

2-Diferenciação.

2.1-Tornar Tangível em Intangível. 2.2-Personalização do Produto-Padrão. 2.3-Redução do Risco Percebido. 2.4-Valorização do Treinamento de Pessoal. 2.5-Controle de Qualidade.

3-Focalização. 3.1-Satisfação de um mercado-alvo particular e as necessidades específicas

de seus clientes. Tabela 1- Principais funções estratégicas da informação em serviços, adaptado de Porter (1980).

Para Batalha (2008), a qualidade do serviço pode ser resultante da percepção que o

cliente teve do serviço confrontado com o serviço esperado.

Quanto às produções dos bens, julgarão a qualidade da operação com base nos

próprios bens. Nos serviços, o consumidor (que participa da operação), julga os seus

resultados e também os aspetos de sua produção. A responsabilidade da administração de uma

produção, muitas vezes, depende de como a organização define a sua produção, no entanto

existem atividades que podem ser consideradas genéricas e aplicadas nas organizações

(CHAMBERS, 2009).

Na tabela 2 representam-se as classificações necessárias para estabelecer os recursos

essenciais para o desenvolvimento e atendimento de uma produção de qualidade que são: os

objetivos, as estratégias, o planejamento, projetos e desempenho.

31

Classificação Descrição

Objetivos Entender os objetivos estratégicos da produção

Estratégias Desenvolver estratégias de produção para a organização

Planejamento Planejar e controlar a produção

Projetos Desenhar produtos, serviços e processos de produção

Desempenho Melhorar o desempenho da produção

Tabela 2- Modelo de Produção, adaptado de Slack (2009).

Em uma administração de produção de serviços ou produtos, envolvem muitas

tomadas de decisões, desta forma é importante que os gerentes de produção tenham conjuntos

de princípios e regras para auxliar nas decisões que possam atingir a estratégia da produção. A

priorização dos objetivos de desempenho de uma produção deve estar vinculada às

necessidades dos consumidores e ao comportamento dos concorrentes, que pode ser definido

como estratégia da produção. A administração da produção é o conjunto de atividades que

permite estabelecer um cenário para as outras atividades.

A tabela 3 descreve os principais processos de uma administração da produção de

serviços.

Processos Descrição

Entrada São os recursos que devem ser transformados, materiais, informações, consumidores, instalações, pessoal, recursos de transformação.

Estratégia da Produção Objetivos estratégicos da produção, papel e posição competitiva da produção.

Administração da Produção Projeto, Planejamento e controle, melhoria. Saída Bens e Serviços

Tabela 3- Processos de administração de produção de Processos de serviços, adaptado de Chambers (2009).

Para Chambers (2009), o objetivo da administração da produção está na transformação

de seus recursos de entradas em bens e serviços, que são planejamento e controle, projeto e

melhoria; além disso, analisar se é possível contribuir na competitividade ou na direção

estratégica da organização.

2.1.1. Diferenças entre Produtos e Serviços

Segundo Oliveira Netto (2006), produtos e serviços diferem em número e grau,

dependendo de sua aplicação. Na tabela 4, estão descritas as abordagens relacionadas a

serviços e clientes. A tabela mostra as principais atividades envolvidas em relação aos

serviços e produtos, cujo objetivo é a identificação das necessidades reais para um melhor

32

atendimento ao cliente. A abordagem refere-se aos contatos entre prestadores de serviços e

clientes, a atividade de serviços e também de produtos.

Abordagem Descrição

Contatos entre prestadores de serviços e clientes.

-Diferem-se de acordo com a natureza, pode haver um contato mais estreito entre o prestador de serviço e cliente. -Existe uma tênue linha entre os serviços oferecidos e o consumo. O serviço se confunde com o seu consumo. -Há uma participação mais ativa do cliente na produção. -O serviço não pode ser armazenado. -Está focada na mão de obra.

Atividades de serviços e de produtos.

-A relação é mais distante é uma relação industrial. -Existe uma lacuna entre a produção de um produto e o seu consumo. -O cliente em momento algum tem influência direta no processo de produção. -Os produtos podem ser estocados ou armazenados. -O produto tem característica como insumos, que são utilizados para a composição. -Pode se controlar a quantidade e a qualidade de seus insumos. -Mecanização do processo produtivo. -Administração da produção e operação tem como objeto os conceitos e técnicas de melhor tomada de decisão aos recursos produtivos.

Tabela 4- Diferença entre produtos e serviços, adaptado de Oliveira Netto (2006).

2.1.2. Clientes e a sua Relação com o Negócio

O cliente é o motivo da existência de qualquer negócio ou organização, (OLIVEIRA

NETTO, 2006). Gordon (1998) divide os clientes em cinco categorias e sete níveis.

Na tabela 5, descrevem-se as principais categorias existentes no mercado, numa visão

mais clara do perfil do cliente para oferecer serviços e produtos de qualidade.

Categorias Descrição

1-Prospects São pessoas identificadas dentro da população em geral, cujo perfil combina com o que a empresa está procurando.

2-Experimentadores Os compradores são experimentadores que estão satisfeitos com uma referência inicial e passaram a fazer negócios com a empresa, mas não efetivamente.

3-Eventuais

Satisfeitos com o período em que a empresa preencheu suas necessidades, os compradores padronizam aspectos fundamentais de seus processos de compra e aquisições para incluir essa empresa como um fornecedor principal para as suas necessidades (conquistou o cliente, mas não a sua inteira confiança).

4-Regulares São aqueles que compram de uma empresa há muito tempo e adotam como seus os processos e valores dessa empresa.

5-Defensores A empresa desfruta de clientes regulares tão comprometidos coma organização que somente uma grave violação da confiança poderia prejudicar essa boa vontade.

Tabela 5- Categoria de clientes, adaptado de Gordon (1998).

33

A tabela 6 descreve-se os principais fatores que relacionam os vínculos e compromisso

estabelecidos entre os produtores e consumidores, oferecendo uma infraestrutura de

atendimento e recursos necessários para dar continuidade na relação estabelecida entre o

cliente e a empresa. Os principais níveis de clientes podem ser classificados em níveis,

conforme mostra a tabela.

Níveis (Vínculos) Descrição

1-Estrutural O cliente e a empresa estão operacional e estruturalmente ligados ou integrados ao empregar, frequentemente, tecnologia para facilitar a interação. Precisa de um alinhamento estratégico.

2- Valor de marca Inclui o valor que um cliente obtém ao se relacionar diretamente com o produto (atributos funcionais da marca ou emocionais e não funcionais adquiridos com ela).

3-Comportamental Ocorrem quando os clientes se unem a uma organização em razão de seu profissionalismo, técnica, dedicação ao cliente, valores, cultura e receptividade.

4-Pessoal Acontece quando os clientes gostam de trabalhar com pessoas específicas e fazem isso independente da empresa com a qual trabalha.

5- Informação e controle É aquele em que os clientes se beneficiam dos relatórios e dos outros sistemas de informação que possam ajudá-los na administração operacional e financeira.

6- Valor Ocorre quando os clientes repetidamente obtêm o valor que procuram de seus fornecedores e têm todos os motivos para acreditar que continuarão a receber esse valor durante um longo período.

7- Opções zero É a situação na qual as organizações podem ter pouca escolha, exceto a opção de criá-lo.

Tabela 6- Níveis de clientes, adaptado de Gordon (1998).

2.1.3. O papel da Qualidade em Produtos e Serviços

Existem muitas descrições sobre o conceito de “Qualidade”, conforme Costa,

Epprechit e Carpinetti (2008). A tabela 7, descreve as principais definições (segundo a

literatura) sobre a qualidade de atendimento e produção em que o foco principal é o cliente e a

qualidade oferecida tanto em serviços ou produtos, segundo os autores: JURAN, DEMING,

CROSBY e TAGUCHI.

Autores Definições JURAN (1999) Qualidade é a adequação ao uso. DEMING (2000) Qualidade é atender e, se possível, exceder as expectativas do consumidor. CROSBY (1995) Qualidade é atender às especificações.

TAGUCHI (1999) A produção, o uso e o descarte de um produto sempre acarretam prejuízos para a sociedade.

Tabela 7-Resumo sobre definições de Qualidade, adaptado de Costa; Epprechit e Carpinetti, (2008).

A importância da qualidade e valor do serviço está na medida do grau de satisfação do

cliente em relação aos requisitos de preço, confiabilidade, durabilidade, estética, pontualidade,

sabor, conforto. Quanto ao valor do serviço, pode ser quantificado através da soma ponderada

34

das notas que são atribuídas pelas coletas de dados pelas atribuições de pesos às notas, desta

forma o bem ou o serviço recebe um valor, enquanto a qualidade é estabelecida durante a fase

de projeto. Uma análise para medir o nível de qualidade de uma empresa, nem sempre é

necessária de novas tecnologias. As técnicas matemáticas, tais como a estatística, a

probabilidade entre outras, muitas vezes auxiliam no planejamento para a tomada de decisão,

pois são úteis para a descoberta dos fatores ou parâmetros que afetam a qualidade de seus

produtos ou serviços de uma organização. O controle de qualidade ou processo de software

envolve custo, pois agregam valor ao produto ou serviço. Os custos de qualidade podem ser

classificados em custos de prevenção, avaliação, falhas internas e falhas externas, (COSTA;

EPPRECHIT e CARPINETTI, 2008).

A tabela 8 descreve as principais características relacionadas a custos que podem

afetar no atendimento de qualidade de serviços ou produtos aos clientes.

Custos Definições

Prevenção São custos com as atividades de prevenção contra a ocorrência de não conformidades (treinamento de pessoal ou monitoramento de processos).

Avaliação São custos advindos de atividades estabelecidas com o propósito de avaliar a observância das especificações.

Falhas internas São os custos com itens não conformes descobertos antes de chegarem ao consumidor.

Falhas externas Ocorrem quando da venda de produtos ou serviços não atendem às especificações. Tabela 8-Resumo sobre custos, adaptado de, Costa; Epprechit e Carpinetti, (2008).

2.2. Processos de Software

O processo de software é um conjunto de atividades e resultados associados que levam

à produção de um produto de software. Os processos evoluíram para explorar a capacidade

das pessoas em uma organização, assim como várias características específicas dos sistemas

que estão sendo desenvolvidos (SOMMERVILLE, 2003).

Para Pressman (2011), processo é um conjunto de atividades, ações e tarefas realizadas

na criação de algum produto de trabalho. Existem muitos processos de software onde as

principais atividades fundamentais são aplicáveis durante o ciclo de vida de muitos projetos

de software.

A tabela 9 descreve as principais atividades envolvidas no processo de

desenvolvimento de serviços que podem auxiliar na qualidade de software e satisfação do

cliente.

35

Atividades Descrição

1-Especificação de Software Define a funcionalidade do software e as restrições de suas operações.

2-Projeto e Implementação de Software Produzir o software conforme as especificações que foram determinadas.

3-Validação de Software Validação do software para garantia e satisfação do cliente.

4-Evolução de Software Evolução do software para atender às necessidades do cliente para um ambiente dinâmico do mundo real.

Tabela 9- Atividades Fundamentais de um Processo de Software, adaptado de: Sommerville (2003).

Os processos podem ser melhorados e implementados de diversas formas, e a

padronização de processos pode auxiliar na comunicação, no treinamento e menor custo de

investimento. Para a criação de processo de software, existem alguns modelos genéricos que

podem ser aplicáveis para a descrição dessa estrutura do processo. Um modelo de processo de

software é uma representação abstrata (SOMMERVILLE, 2003). Na tabela 10, representam-

se os principais modelos de processos que podem auxiliar no ciclo de desenvolvimento de

produtos de software, segundo a literatura sobre a engenharia de software. Consideram-se as

especificações, as atividades, os processos, as abordagens principais, as interações, as

definições dos principais componentes. O modelo descreve os principais processos e iterações

de software que são: cascata, evolucionário, formal de sistemas e orientado a reuso para os

processos de software, enquanto para a iteração de processos há: o incremental e

desenvolvimento espiral (utilizado para análise de riscos de projetos nesta tese).

Modelo Descrição Processo de Software

1-Cascata

Considera as atividades de: Especificação, desenvolvimento, validação e evolução. São representadas em fases separadas do processo (especificação de requisitos / projeto de software / implementação / testes). Requer que os clientes de um sistema se comprometam com um conjunto de requisitos específicos, antes do início de um projeto.

2-Desenvolvimento evolucionário

A abordagem intercala as atividades de especificação, desenvolvimento e validação. Desenvolvem-se inicialmente um sistema a partir das especificações abstratas, refinando-se com informações do cliente, para produzir um sistema que satisfaça as suas necessidades. Permite que os requisitos e as decisões de projetos sejam postergados.

3-Desenvolvimento formal de sistemas

A abordagem se baseia na produção de uma especificação formal matemática do sistema e na transformação dessa especificação, utilizando métodos matemáticos, para construir programas. A verificação de componentes do sistema é realizada mediante argumentos matemáticos e devem atender às especificações (matemáticas). Não são amplamente utilizadas.

4-Desenvolvimento orientado a reuso A abordagem tem como base a existência de um número significativo de componentes reutilizável. Concentra-se na integração de componentes reutilizável em um sistema. Reduzir custos e riscos.

36

Iteração de Processo

5-Desenvolvimento incremental

As fase de especificação, projeto e implementação de software são desdobradas em uma série de estágios (que são desenvolvidos). É uma abordagem intermediária que combina as vantagens do modelo em cascata com o evolucionário. Tem como objetivo reduzir o retrabalho, pois permite adiar decisões sobre seus requisitos detalhados. Os clientes identificam as funções principais a serem fornecidas pelo sistema.

6-Desenvolvimento em espiral O desenvolvimento do sistema evolui a partir de um esboço inicial, em direção ao sistema final.

Tabela 10- Modelos de Processos, adaptado de Sommerville (2003).

Proposto por Boehm (1988), o modelo espiral é um modelo de processo de software

evolucionário que acopla a natureza iterativa do protótipo com os aspectos sistemáticos e

controlados do modelo cascata. Fornece potencial para o rápido desenvolvimento de versões

cada vez mais completo do software. As principais características do modelo espiral são:

a) É um gerador de modelos de processos dirigidos a riscos e é utilizado para guiar a

engenharia de sistemas intensivos de software, que ocorre de forma concorrente e

tem múltiplos envolvidos.

b) É uma abordagem cíclica voltada para ampliar, incrementar o grau de definição e

a implementação de um sistema, enquanto diminui seu grau de risco.

c) É uma série de pontos âncora de controle para assegurar o comprometimento de

interessados quanto à busca de soluções de sistemas que sejam mutuamente

satisfatórias e praticáveis.

Conforme Pressman (2011), uma especificação de processo descreve todos os

processos do modelo de fluxo que aparecem no nível final de refinamento. Quanto ao

conteúdo de uma especificação de processo, pode conter um texto narrativo, uma descrição da

linguagem de projeto de programas do algoritmo de processos, equações matemáticas, tabelas

ou diagramas de atividades da UML (Linguagem de Modelagem Unificada). Já um modelo de

projeto pode ser visto como dimensão do processo e da abstração que são apresentados como:

a) Dimensão do processo: Indica uma evolução do modelo de projeto à medida que

as tarefas de projeto são executadas como parte do processo de software.

b) Dimensão da abstração: representa o nível de detalhe à medida que cada elemento

do modelo de análise é transformado em um equivalente de projeto e então

refinado iterativamente.

37

A representação dos elementos do modelo de um projeto permite que se utilizem

vários diagramas da UML para a construção de um modelo de análise. Uma arquitetura é

construída através de muitas decisões e de diversas dimensões que podem ser: pequenas,

médios e grandes. Algumas dessas decisões são tomadas no início do projeto e podem ter um

impacto profundo sobre todas as ações sub-sequentes. Outras são postergadas ao máximo,

eliminando, restrições que levam a implementação inadequada do estilo da arquitetura.

A arquitetura de software de um programa ou sistema computacional é a estrutura ou

estruturas do sistema, abrangendo os componentes de software, as propriedades externamente

visíveis desses componentes e as relações entre eles. Uma arquitetura deve permitir:

a) Analisar a efetividade do projeto no atendimento dos requisitos declarados.

b) Considerar alternativas de arquitetura em um estágio quando realizar mudanças de

projeto.

c) Reduzir os riscos associados à construção do software

2.2.1. Dimensão e Fator de Qualidade

Para Garvin (1987), a qualidade deve ser considerada, utilizando uma visão

multidimensional que começa com uma avaliação da conformidade e termina com uma visão

transcendental (estética). As principais classificações são:

a) Qualidade do desempenho:

- O software deve fornecer todo o conteúdo, funções e recursos que são

especificados como parte do modelo de requisitos de forma a gerar valor ao

usuário final.

b) Qualidade dos recursos:

- O software deve fornecer recursos que surpreendem e encantam usuários finais

que o utilizam pela primeira vez.

c) Confiabilidade:

- O software deve ser possível de ser utilizado com confiança, estar disponível para

os usuários.O software deve fornecer todos os recursos e capacidades sem falhas,

38

estar disponível quando necessário e fornecer funcionalidade sem a ocorrência de

erros.

d) Conformidade:

- O software deve estar de acordo com os padrões de software local e externo

relacionado com a aplicação, Seguir as convenções de projeto e codificação de

fato.

e) Durabilidade:

- O software deve permitir modificações ou correções sem a geração involuntária

de efeitos colaterais indesejados, as mudanças devem fazer com que a taxa de

erros ou a confiabilidade diminuam com o passar do tempo.

f) Facilidade de manutenção:

- O software pode ser mantido, modificado ou corrigido em período de tempo

aceitável e curto. O pessoal de suporte pode obter todas as informações

necessárias para realizar alterações ou correção de defeitos.

g) Estética:

- Deve ter certa elegância.

h) Percepção:

- Deve ter uma percepção de qualidade do produto de software com influências

positivas.

Conforme McCall, Richards e Walters (1977), foi criada uma proposta de

categorização dos fatores que afetam a qualidade de software, e focaliza os principais

aspectos de: 1- Características operacionais, 2- Habilidade de suportar mudanças e 3-

Adaptabilidade e novos ambientes. Quanto aos principais fatores há:

a) Correção: o quanto um programa satisfaz a sua especificação e atende aos

objetivos da missão do cliente. b) Confiabilidade: o que se espera que um

programa realize quanto à função pretendida com a precisão exigida. c)

39

Eficiência: a quantidade de recursos computacionais e código exigido por um

programa para desempenhar sua função. d) Integridade: o quanto o acesso ao

software ou dados por pessoas não autorizadas pode ser controlado. e)

Usabilidade: esforço necessário para aprender, operar, preparar a entrada de dados

e interpretar a saída de um programa. f) Facilidade de manutenção: esforço

necessário para localizar e corrigir um erro em um programa. g) Flexibilidade:

esforço necessário para modificar um programa em operação. h) Testabilidade:

esforço necessário para testar um programa de modo a garantir que ele

desempenhe a função destinada. i) Portabilidade: esforço necessário para

transferir o programa de um ambiente de hardware e/ou software para outro. j)

Reusabilidade: o quanto um programa (ou parte de um programa) pode ser

reutilizado em outras aplicações. k) Interoperabilidade: esforço necessário para

integrar um sistema a outro.

Para a ISO 9126, os atributos fundamentais de qualidade de software podem ser

classificados em:

a) Funcionalidade: é o grau com que o software satisfaz às necessidades declaradas

conforme indicado pelos atributos de: adequabilidade, exatidão,

interoperabilidade, conformidade e segurança. b) Confiabilidade: é a quantidade

de tempo que o software fica disponível para uso conforme indicado pelos

atributos: maturidade, tolerância a falhas, facilidade de recuperação. c)

Usabilidade: é o grau de facilidade de utilização do software conforme indicado

pelos atributos: facilidade de compreensão, de aprendizagem, operabilidade. d)

Eficiência: é o grau de otimização do uso, pelo software, dos recursos do sistema

conforme os atributos: comportamento em relação ao tempo, e em relação aos

recursos. f) Facilidade de Manutenção: é a facilidade com a qual uma correção

pode ser realizada no software conforme os atributos: facilidade de análise, de

realização de mudanças, estabilidade, testabilidade. g) Portabilidade: é a

facilidade com a qual um software pode ser transposto de um ambiente a outro

conforme os atributos: adaptabilidade, facilidade de instalação, conformidade,

facilidade de substituição.

40

Outros fatores necessários para a avaliação de um software é a avaliação de atributos

específicos, que sejam mesuráveis com o uso de uma interface e possíveis de serem

classificados (segundo as definições do dicionário da língua Portuguesa) em:

a) Intuição: ato de ver, percepção clara, imediata, pressentimento.

b) Eficiência: ação, força, eficácia.

c) Robustez: qualidade de robusto, resistente.

d) Riqueza: abundância, classe dos ricos.

2.2.2. Gerenciamento de Custo de Software

Conforme Sommerville (2003), um gerenciamento eficiente em um desenvolvimento

de software necessita de planejamento em que seja possível prever os problemas durante o

ciclo de vida de um projeto. O planejamento deve ser traçado já na fase inicial de um projeto,

pois será a diretriz para a condução e fonte de informação para que seja possível a sua

evolução, existindo diversos tipos de planos de projetos.

Na tabela 11 estão descritas as principais atividades para o desenvolvimento de um

projeto de qualidade que são: os planos de validação, gerenciamento e desenvolvimento de

equipe. Estão definidos os testes, os recursos, as validações, a estrutura e experiências e

participação de todos os especialistas envolvidos no projeto. Os principais planos de projeto

são: de qualidade, de validação de gerenciamento de configuração e de desenvolvimento de

equipe.

Plano de projeto Descrição

1-Plano de qualidade Descreve os procedimentos para teste de qualidade que serão utilizados em um projeto.

2-Plano de validação Descreve a abordagem, os recursos e os métodos utilizados para validação do sistema.

3-Plano de gerenciamento de configuração

Descreve os procedimentos de gerenciamento e as estruturas a serem utilizadas em um projeto.

4-Plano de desenvolvimento de equipe Descreve como as habilidades e as experiências dos membros da equipe de projeto serão desenvolvidas.

Tabela 11-Plano de projeto, adaptado de Sommerville (2003).

2.2.3. Desenvolvimento e Gerenciamento de Qualidade de Software

As descrições e fundamentos teóricos descritos abaixo são adaptados de Sommerville

(2003), em relação a gerenciamento e qualidade de software. A estimativa de projeto e

41

cronograma na execução de um projeto é realizada em conjunto, e uma estimativa de custo

pode ser necessária antes que um cronograma detalhado seja preparado, e se o projeto estiver

em andamento, os custos das estimativas devem ser regularmente atualizadas. Para atingir um

alto nível de qualidade de produto ou serviço é o objetivo da maioria das organizações. A

qualidade de um software é um conceito complexo, pois existem aspectos intangíveis da

qualidade de software que não podem ser incorporadas a padrões. Para o gerenciamento de

qualidade de software existem três atividades principais, conforme mostra a tabela 12.

Na tabela 12, descrevem-se as principais atividades de qualidade no desenvolvimento

de software que são: a garantia, o planejamento e controle de serviços de software, pois

estabelecem os procedimentos, os padrões, a estruturação dos projetos e também processos

para o desenvolvimento de software.

Atividades Descrição

1-Garantia de qualidade Estabelece uma estrutura de procedimentos e de padrões organizacionais, que conduza ao software de alta qualidade.

2-Planejamento de qualidade Seleciona procedimentos e de padrões adequados a partir da estrutura criada e faz a adaptação dessa estrutura para um projeto específico.

3-Controle de qualidade Define e aprova os processos para assegurar que os procedimentos e os padrões de qualidade de projeto sejam seguidos pela equipe de desenvolvimento de software.

Tabela 12- Atividades principais de qualidade de software, adaptado de Sommerville (2003).

O gerenciamento de qualidade deve ser separado do gerenciamento de projeto, para

que a qualidade não seja comprometida quanto ao orçamento e aos prazos de projeto. Um

padrão internacional adotado pelas organizações para gerenciamento de qualidade é a ISO

9000. A ISO 9001 é um modelo genérico de processo de qualidade que descreve vários

aspectos do processo e define os padrões e procedimentos que devem existir dentro de uma

organização. As atividades de garantia de qualidade têm como objetivo definir uma estrutura

que permita atingir a qualidade de um software que é a definição de padrões para que possa

ser aplicado e integrado a um processo de desenvolvimento de software. Conforme

Sommerville (2003), existem dois tipos de padrões estabelecidos como parte do processo de

garantia de qualidade que são: padrões de produto e de processo. Na tabela 13, descrevem-se

as principais atividades de produtos e processo de qualidade aplicada em produtos de software

que são os padrões estabelecidos nos processos e documentações, que são: produto e o

processo.

42

Padrão Descrição

Produto

São padrões que aplicados a produtos de software em desenvolvimento. Fazem parte dos padrões dos documentos: a estrutura dos requisitos, de cabeçalho, comentário, de codificação da linguagem.

Processo

São os padrões que definem os processos que serão seguidos durante o desenvolvimento de software. Podem incluir: definições de especificações, processos de projeto e validações, descrição dos documentos que devem ser gerados durante os processos.

Tabela 13- Atividade de garantia de qualidade de produto e de processo, adaptado de Sommerville (2003).

2.3. Gestão da Qualidade

Conforme Carvalho e Paladini (2006), para um melhor entendimento sobre o conceito

da Gestão da Qualidade, tornam-se necessário o conhecimento de suas origens. Um passeio

pela história ajuda a entender o conceito da gestão da qualidade. A tabela 14 resume os

principais conceitos da evolução da qualidade em relação a produtos e serviços, descrevendo

os principais conceitos de qualidade (de produtos e serviços), considerando-se as diversas

características da evolução e aplicação de satisfação e necessidade do cliente na linha

produtiva segundo a sua época, que são: artesãos, a revolução industrial o modelo de

TAYLOR (administração científica), os gráficos de controles, área de qualidade, qualidade

total, zero defeito, modelo CWQC (Company Wide Quality Control), produção enxuta,

Kaizen, Keiretsu, Poka Yoke, CWCQ, ISO, ISO 9000, gestão da qualidade moderna, Hoshin

Kanriou strategic policy deployment e seis sigma.

Componentes de qualidade Descrição

Artesãos

Pequenos especialistas que tinham o domínio completo de todo o ciclo de produção. Procuravam entender os seus clientes para manter a qualidade de seus serviços prestados, tais como: confiabilidade, conformidade, metrologia, tolerância e especificação. O foco do controle da qualidade era: o produto e não o processo.

Revolução industrial

Trouxe nova ordem produtiva, pois a customização foi substituída pela padronização e a produção em larga escala. A invenção de máquinas foi projetada para obter grande volume de produção, surgindo desta forma uma nova organização do trabalho com produção em grande escala.

Modelo taylorista ou Administração científica.

É o modelo de administração que retirou do trabalhador as etapas de concepção e de planejamento, surgindo nesta época à função do inspetor, que eram responsáveis pela qualidade dos produtos. Foi também a época da grande evolução do conceito de controle da qualidade. Contudo nesse período, deixaram de ser priorizados alguns aspectos importantes da Gestão da Qualidade que eram enfatizados no período artesanal, tais como: conhecimento das necessidades do cliente e a participação do trabalhador.

Gráficos de Controle

Ao fundir os conceitos de estatística à realidade produtiva dentro da empresa de telefonia Bell TelephoneLaboratories. Propôs também o ciclo PDCA (Plain-Do-Check-Act) que direciona as atividades de análise e solução de problema, (WALTER A. e SHEWHART, 1924).

43

Área de Qualidade

Consolida-se nos Estados Unidos (1945), com o surgimento da primeira associação de profissionais da área de qualidade – a SocietyofQualityEnginers. Posteriormente fundada em 1946 a American Society for QualityControl (ASQ). Em 1950 é criada a associação japonesa de cientistas e engenheiros, a JUSE (JapanUnion of Scientists and Engineers), desempenhando papeis importantes na área da qualidade.

Qualidade Total (TQC) TQC (Total QualityControl – Controle da Qualidade Total), influência o modelo proposto pela ISO (International OrganizationofStandardization) e a ISO 9000, no período de 1957.

Zero Defeito No final da década de 1957, Philip B. Crosby lança os elementos que criaram o programa Zero Defeito, que foi utilizado em empresas e também em programas militares.

Modelo CWQC

Modelo japonês CWQC (CompanyWideQualityControl), que foi introduzido no Brasil como Controle da Qualidade por toda a Empresa ou Controle da Qualidade Amplo Empresarial, que traz vários elementos novos para a Gestão da Qualidade associados ao modelo TQC.

Produção enxuta (leanproduction)

TAIICHI ONO, um dos grandes idealizadores do modelo Toyota de produção, contra o desperdício, eliminado a inspeção, desenvolvendo junto aos trabalhadores a responsabilidade pela qualidade do que produzia intervindo em tempo real, evitando assim a produção de peças defeituosas.

Kaizen(termo em Japonês) Conceito de melhoria contínua do modelo japonês, que é a busca da perfeição (kaizen).

Keiretsu (termo em japonês)

Outro elemento importante no modelo japonês com o sistema de parcerias e alianças com fornecedores, pois apresentavam padrões de colaboração e parcerias muito diferenciadas, com o conceito de qualidade assegurada.

PokaYoke (termo em japonês)

Eliminação de desperdícios da qualidade com a proposição de dispositivos à prova de erros, bem como o desperdício de tempos de preparação, com seu modelo de troca rápida de ferramenta (SMED), (SHIGEO SHINGO).

CWCQ CWCQ (Círculos de Controles de Qualidade), difusão das sete ferramentas da qualidade (CCQs), conhecidas como grupos de melhorias, e atualmente ainda em uso em diversas organizações.

ISO ISO (International organization for Standardization), 1987, em meio à expansão da globalização, surge como modelo normativo para a área de Gestão da Qualidade, a série 9000, Sistemas de Garantia da Qualidade.

ISO 9000

Difundiu-se rapidamente, em empresas automobilísticas que criou diretrizes adicionais como: QS 9000, que convergiram para uma especificação técnica ISO TS 16949, em 1999, para todo o setor. Em 2000, foi feita a terceira revisão da série. A ISO 9000:2000 trouxe novos elementos, passando a adotar a visão de Gestão da Qualidade (não mais de garantia), introduzindo elementos da gestão por processos, gestão por diretrizes e foco no cliente. Destaca-se também a norma de Gestão Ambiental ISO 14000 (1996) que tem um relacionamento muito forte com a série ISO 9000.

Gestão da Qualidade Moderna Recupera alguns atributos da época artesanal: proximidade às demandas do cliente, maior customização (em massa e escala).

QFC

QFC (QualityFunction Deployment – Desdobramento da Função Qualidade), no final da década de 1960, MIZUNO e AKAO colaboram no resgate a proximidade com o cliente propondo o método QFC. Também GENICHI TAGUCHI focou nas atividades de projeto, como fundamentais para a satisfação do cliente e para a criação de uma qualidade robusta (robustquality).

HoshinKanriou strategic policy deployment

Considera o resgate da importância dos clientes e a percepção da qualidade como um critério competitivo.

44

Seis Sigma

Considerado o programa mais recente de Gestão da Qualidade, surgiu no final da década de 1980, na Motorola. As principais características são: pensamento estatístico com ênfase no controle da qualidade e análise, como também na solução de problemas. Utiliza o ciclo DMAIC (define-measure-anlyse-improve-control), definir, medir, analisar, melhorar e controlar, o que remete ao ciclo PDCA.

Tabela 14- Resumo histórico sobre a qualidade de produtos e serviços, adaptado de Carvalho e Paladini (2006).

De acordo com Carvalho e Paladini (2006), a qualidade é uma definição que pode

divergir e ter significados diferentes para as pessoas. A qualidade é um termo utilizado no

cotidiano, mas seu significado é diverso e dificilmente haverá um consenso. A tabela 15

resume as principais características sobre o conceito de qualidade que pode ser classificada

com base em: produto, usuário, produção e valor. O objetivo está na definição de uma medida

de qualidade para a satisfação e adequação às necessidades dos clientes, que são: o produto, o

usuário e valor.

Qualidade Descrição Com base no produto É uma variável precisa e mensurável (atributos).

Com base no Usuário É uma variável subjetiva (atender aos desejos do consumidor, satisfação, desejos, necessidades, adequação ao uso).

Com base na produção É uma variável precisa e mensurável (grau de conformidade do planejado com o executado, ênfase a ferramentas estatísticas, controle do processo, conformidade às especificações).

Com base no valor Abordagem de difícil aplicação (mistura os conceitos de excelência e valor, ênfase à Engenharia ou Análise de valor, excelência a um preço aceitável).

Tabela 15- Classificação de qualidade, adaptado de Garvin (1987).

A definição para a atividade, segundo Sordi (2005), é uma unidade lógica de trabalho

executada dentro de um processo ou tarefa. Um fluxo de atividade descreve a sequência de

execução das diversas atividades que compõe, indicando a atividade ou as atividades

possíveis de execução após a conclusão de cada uma das atividades. A figura 2 representa as

divisões das atividades com base nos processos (de produto, usuário, produção e de valor) e

de suas atividades (de medir variáveis, conformidade e graus de excelência), utilizando

diagrama de atividade da UML (Linguagem de Modelagem Unificada – Unified Modeling

Language). Os detalhes de cada classificação estão descritos em suas notações.

45

Figura 2-Classificação da qualidade através do fluxo de suas variáveis, adaptado de Garvin (1987).

2.3.1. Serviços e Estratégias de Qualidade

Os fundamentos descritos, a seguir, são adaptados segundo Las Casas (2007). A

qualidade e o serviço estão relacionados ao atendimento e na forma de tratar ou solucionar um

problema, necessitando de atenção, dedicação, habilidade e treinamento; além da avaliação e

atuação sobre os resultados das análises obtidas para eventuais mudanças ou melhorias na

qualidade do atendimento aos serviços prestados. Serviços possuem dois componentes de

qualidade que devem ser considerados: o serviço propriamente dito e a forma como é

percebido pelo cliente.

Quanto aos aspectos físicos da podem ser classificadas em: similaridade, proximidade

e continuidade. Na similaridade, os objetos similares são percebidos pelas pessoas como parte

de um conjunto; quanto à proximidade, os objetos próximos tendem a ser percebidos como

parte do conjunto; no princípio da continuidade, a pessoa ou indivíduo continua com o

complemento ao associar os conceitos formados. Serviços podem ser classificados em:

intangíveis, inseparáveis, heterogêneos e simultâneos. A intangibilidade significa que os

serviços são abstratos; o aspecto da inseparabilidade dos serviços não permite produzir ou

estocar; a heterogeneidade refere-se à impossibilidade de se manter a qualidade do serviço

constante; a simultaneidade dos serviços está na ocorrência do tempo concorrente (ao mesmo

tempo) da produção e consumo. Os principais fatores que devem ser considerados para

qualquer prestação de serviços. A tabela 16 descreve os principais fatores envolvidos para

atendimento ao cliente considerando a qualidade dos serviços prestados.

46

Fatores Descrição Produtos e Serviços Quais os componentes tangíveis e intangíveis dos produtos e serviços?

Consumidor e Empresa Quais todos os momentos da verdade (momento de contato com os clientes observados, pela característica de inseparabilidade) de um consumidor com a empresa?

Momentos da verdade É a base dos 4P´s do serviço: perfil (ambiente físico), processo, pessoas e procedimentos.

Tabela 16- Fatores considerados para serviços de qualidade, adaptado do autor Las Casas (2007).

A figura 3 mostra o modelo da Gestão da Qualidade em forma de diagrama de

atividade para auxiliar na compreensão da Gestão da Qualidade e seus componentes que

justifiquem melhorias de produtos e serviços de uma empresa, utilizando diagrama de

atividade da UML (Linguagem de Modelagem Unificada – Unified Modeling Language).

Nesse diagrama, estão os principais componentes estratégicos e a relação de qualidade

numa visão de fluxo de informação oferecida numa gestão da qualidade. São definidos

diversos atributos de qualidade e processos para o atendimento ao cliente. As principais

atividades são: o nível estratégico e os componentes de qualidade. E as principais ações para o

nível estratégico são: a dimensão espacial, a dimensão temporal, a qualidade, o fator e a

liderança. Para os componentes de qualidade há: a) a dimensão operacional, b) as ações de

controle e c) o processo produtivo.

Figura 3- Modelo de Gestão da Qualidade, adaptado de Carvalho e Paladini (2006).

47

A visão sobre as estratégias da qualidade deve verificar a existência da transformação

da qualidade em algum valor. É preciso também analisar se a qualidade realmente foi capaz

de minimizar os defeitos, se existe algum diferencial que torne a empresa mais competitiva e

se existe um contínuo crescimento da qualidade de seus produtos ou serviços. Quanto aos

resultados práticos da Gestão da Qualidade em nível operacional, é possível classificá-lo em:

qualidade na indústria e qualidade nas empresas comerciais, (CARVALHO e PALADINI,

2006). Os conceitos de qualidade nas empresas comerciais foram considerados por um

período de tempo de que a qualidade deveria ser aplicada apenas na linha de produção de

produtos para exportação. Durante um bom tempo, houve a impressão de que a qualidade era

restrita às linhas de produção destinadas aos produtos de exportação. No entanto, devido à

concorrência externa e interna, o conceito de qualidade torna-se um fator importante para

aplicação frente a um mercado global e competitivo. Outro fator a considerar devido a

concorrência é a migração dos conceitos da qualidade para empresas de serviços. A qualidade

passa a ter as suas diversificações dentro das organizações produtoras de serviços com

investimentos em tecnologias, pessoas, qualificação e diferenciais de competitividade.

A gestão da qualidade serve como diretriz para uma organização, pois estabelecem

regras que definem as formas de como devem atuar. A gestão da qualidade possui uma

estrutura sólida que deve ser adotada por todas as áreas e setores da empresa, além de definir

todos os procedimentos e os impactos das pessoas dentro da organização. Os principais

conceitos (que muda com o tempo) da qualidade são classificados em: modernos, novos,

atuais ou contemporâneos. Muitos desses conceitos são definidos pelas pessoas ou

organizações e podem ser ultrapassados segundo o contexto inserido. Existe uma dependência

do conceito da qualidade quando se trata de: produção, serviços de TI e competitividade.

Consequentemente, as ações são em função da inovação de produtos e serviços para atender

ao mercado consumidor, (PALADINI, 2008).

A Gestão da Qualidade Total é a “extensão do planejamento do negócio da empresa

que inclui o planejamento da Qualidade” e caracteriza-o como planejamento (Gestão da

Qualidade Total). Enquanto os principais objetivos da Gestão da Qualidade Total são: a

exigência do envolvimento da alta administração da organização, da viabilização das ações

estratégicas, da atribuição das responsabilidades e da disponibilização de recursos para a

produção da qualidade, (JURAN e GRYNA, 2008).

48

2.3.2. Valor do serviço e soma ponderada

A importância da qualidade e valor do serviço está na medida do grau de satisfação do

cliente em relação aos requisitos de: preço, confiabilidade, durabilidade, estética,

pontualidade, sabor, conforto. Quanto ao valor do serviço, ela pode ser quantificada através

da soma ponderada das notas que são atribuídas pelas coletas de dados pelas atribuições de

pesos às notas, dessa forma o bem ou o serviço recebe um valor, enquanto a qualidade é

estabelecida durante a fase de projeto. Uma análise para medir o nível de qualidade de uma

empresa, nem sempre tem necessidade de novas tecnologias. As técnicas matemáticas, tais

como a estatística, a probabilidade entre outras, muitas vezes podem auxiliar no planejamento

para a tomada de decisão, pois podem ser úteis na descoberta dos fatores ou parâmetros que

afetam a qualidade de seus produtos ou serviços de uma organização. O controle de qualidade

ou processo de software envolve custo, pois agrega valor ao produto ou serviço. Os custos de

qualidade podem ser classificados em: custos de prevenção, avaliação, falhas internas e falhas

externas, (COSTA; EPPRECHIT e CARPINETTI, 2008). A tabela 17 define os custos e a sua

adaptação para medida de qualidade oferecida aos clientes que são: a prevenção, a avaliação,

as falhas no ponto de vista interna e externa à organização.

Custos Definições

Prevenção São custos com as atividades de prevenção contra a ocorrência de não conformidades (treinamento de pessoal ou monitoramento de processos).

Avaliação São custos advindos de atividades estabelecidas com o propósito de avaliar a observância das especificações.

Falhas internas São os custos com itens não conformes descobertos antes de chegarem ao consumidor.

Falhas externas Ocorrem quando da venda de produtos ou serviços não atendem às especificações. Tabela 17- Resumo sobre custos, adaptado de, Costa; Epprechit e Carpinetti, (2008).

2.3.3. Escala de Likert

A mensuração baseado em uma escala do tipo Likert, criada em 1932 pelo educador e

psicólogo social americano Rensis Likert (1903-1981) é um instrumento que contempla um

elenco de sentenças para as quais o respondente manifesta seu grau de concordância,

assinalando valores numa escala do tipo: (1) discordo inteiramente, (2) discordo, (3) nem

concordo nem discordo (4) concordo, (5) concordo inteiramente. A escala Likert apresenta

diversas vantagens: a) é de fácil elaboração e aplicação, b) é mais objetiva e c) é mais

homogênea e aumenta a probabilidade de mensuração de atitudes unitárias. Como

desvantagem, a escala acaba por quantificar e padronizar respostas, o que impossibilita a

49

detecção de nuances e sutilezas de atitudes, que por sua vez são percebidas nas entrevistas e

questionários abertos, (SCOLARIS, 2009). Na escala de Likert, as respostas para cada item

variam segundo o grau de intensidade. Essa escala com categorias ordenadas, igualmente

espaçadas e com o mesmo número de categorias em todos os itens, é largamente utilizada em

pesquisas organizacionais que investigam as práticas da GQT (Gestão pela Qualidade Total),

(SARAPH, 1989), (BADRI, 1995), (TAMIMI, 1995) e (ALEXANDRE, 2001).

Um dos pontos centrais em pesquisas empíricas, em especial, quantitativas

organizacionais que investigam a Gestão pela Qualidade Total (GQT), é elaboração do

instrumento de medição (questionário) a ser utilizado para a coleta de informações.

Questionários objetivos baseados na escala de Likert são bastante utilizados nesses tipos de

pesquisa (SARAPH, 1989), (AHIRE, 1996), (BADRI, 1995), (TAMIMI, 1995),

(TERZIOVSKI, 1999) e(ALEXANDRE & FERREIRA, 2001).

Segundo Alexandre, Andrade, Vasconcelos, Araújo e Batista (2003), em geral são

utilizados na escala de Likert quatro ou cinco categorias ordinais. Como ilustrações podem ser

citadas, para quatro categorias, 0- nada importante, 1- pouco importante, 2- importante e 3-

muito importantes, e para cinco categorias, 0- muito baixo, 1- baixo, 2-médio, 3- alto e 4-

muito alto.

Likert (1932) elaborou uma escala em que o consumidor constroi os níveis de

aceitação para medir os níveis de aceitação dos produtos e serviços. Conhecida como escala

de Likert, requer que os entrevistados indiquem seu grau de concordância ou discordância

com declarações relativas à atitude que está sendo medida. Atribuem-se valores numéricos

e/ou sinais às respostas para refletir a força e a direção da reação do entrevistado à declaração.

As declarações de concordância devem receber valores positivos ou altos enquanto as

declarações das quais discordam devem receber valores negativos ou baixos (BAKER, 2005).

As escalas podem ir, por exemplo, de 1 a 5, de 5 a 1, ou de +2 a -2, passando por zero.

As declarações devem da oportunidade ao entrevistado expressar respostas claras em

vez de respostas neutras, ambíguas. Mattar (2001) explica que a cada célula de resposta é

atribuído a nota e as principais vantagens da escala de Likert é a sua simplicidade na

construção, pois permite a inclusão de itens que são coerentes com o resultado esperado, no

entanto a sua desvantagem está na representação na forma ordinal.

50

2.3.4. Linha Divisória ou Limite de Decisão e Regressão

Segundo Tan; Steinbach e Kumar (2006), o limite ente duas regiões fronteiriças de

diferentes classes é conhecido como limite de decisão. A condição de teste envolve apenas um

atributo, os limites de decisão são retilíneos, paralelos aos eixos de coordenadas. Existem

muitas métricas que podem ser usadas para determinar a melhor forma de dividir os registros.

Essas métricas são definidas em termos da distribuição da classe dos registros antes e depois

da divisão. A margem do limite de decisão é dada pela distância entre dois hiperplanos. Com

base na regressão (técnica de modelagem preditiva) a variável alvo pode ser avaliada, pois é

contínua. Uma regressão é a tarefa de aprender uma função alvo f que permite mapear cada

conjunto de atributo x em uma saída de valores contínuos y .

De acordo com Medeiros (2006), se um problema pode ser separado por uma reta,

representando a divisão entre classes, diz se que tal problema é linearmente separável, caso

contrário, é dito linearmente não separável.

2.4. Função Empresarial e Processos de Negócios

A função empresarial e de processo de negócios, segundo Sordi (2005), é bastante

antigo na administração de empresas, sua origem é da década de 1920. Começou com

FREDERICK TAYLOR quando estudou a complexidade dos processos a partir da análise

sistemática dos procedimentos de trabalho, introduziu os conceitos de eficiência,

especialização e medição do processo, conforme mostram as figuras 4 e 5. A figura 4 mostra

uma descrição da função empresarial e a relação existente com processos de negócios: as

atividades de profissionais especializados atuando em funções empresariais. Em processos de

negócios, existem: fluxos de atividades (que geram algo de valor para seus clientes) e as

principais características que contribuem para as áreas funcionais, segundo os papeis

desempenhados pelos profissionais de cada área. Utiliza-se o diagrama de atividade da UML

(Linguagem de Modelagem Unificada – Unified Modeling Language). Nesse diagrama,

mostra-se o fluxo das funções empresariais e processo de negócios dentro de uma nova forma

de administração. Descrevem-se as principais atividades em relação aos processos envolvidos

dentro de uma organização que são: a produção, os recursos humanos, as finanças, a gestão de

materiais, engenharia de produto e vendas. Para os processos de negócios há: os diversos

trabalhos combinados em um, a liberdade de tomada de decisões, as atividades de processos

51

são executadas na sua ordem natural, pode haver múltiplas versões de um processo e os

pontos de controle e reconciliação são minimizados. Além disso, as áreas funcionais são

substituídas por equipes de trabalho, os papeis de cada profissional mudam para múltiplas

tarefas, os gerentes mudam de supervisor para treinador de time e as organizações operam em

estruturas horizontais.

Figura 4- Função empresarial e processo de negócio, adaptado de Sordi (2005).

A figura 5 mostra os processos e as suas ações relacionadas para cada um de seus

processos numa visão de procedimentos e trabalhos segundo TAYLOR, (1920). Descrevem-

se as relações dos processos e os fluxos de informações entre esses processos, numa forma de

estabelecer uma medição para análise de qualidade de processos. Os processos são divididos

em fluxos de análise de eficiência, especialização e de medição do processo.

52

Figura 5- Análise sistemática dos procedimentos de trabalho de Taylor, adaptado de Sordi (2005).

2.4.1. Novas Teorias e Práticas Administrativas

A figura 6 mostra os principais diagramas de componentes (na forma de diagrama de

componentes) da nova teoria e prática administrativa com o processo de negócio (numa visão

de arquitetura).

Figura 6- Novas teorias e práticas administrativas, adaptado de Sordi (2005).

A tabela 18 descreve as principais características de processos de negócios, conforme

os autores Hammer e Champy, (1994). Descrevem como as atividades de qualidade podem

auxiliar internamente uma organização: a combinação de diversos trabalhos, liberdade nas

tomadas de decisões, atuação de equipes de trabalho, múltiplas tarefas e adoção de processos

horizontais. As principais características do processo de negócio são: trabalhos diversos,

53

tomadas de decisões, versões do processo, controle e reconciliação, departamentos funcionais,

foco gerencial e organização.

Características do processo de negócio Descrição Trabalhos diversos Diversos trabalhos são combinados em um.

Tomadas de decisões Os trabalhadores têm liberdade para tomar decisões. Fortalecimento do papel dos funcionários pela organização.

Atividades do processo Os passos ou atividades que compõe o processo são executados na sua ordem natural, com certa coerência.

Versões do processo Pode haver múltiplas versões de um processo que pode levar a um tratamento especializado.

Controle e reconciliação Pontos de controle e reconciliação são minimizados em virtude da maior capacidade e qualidade das pessoas envolvidas.

Departamentos funcionais Áreas e departamentos funcionais são substituídos por equipes de trabalho.

Papéis de cada profissional Os papeis de cada profissional mudam de atividade para múltiplas tarefas, com processo de capacitação amplo.

Foco gerencial Os gerentes têm foco alterado de supervisor para treinador de time.

Organização A organização passa a operar por processos horizontais e não mais verticais.

Tabela 18- Processos de negócios, adaptado de Hammer e Champy (1994).

Os principais componentes de uma empresa manufatureira segundo Lambert (2001)

são: processos de negócios e serviços a clientes. As subáreas dos processos de negócios são

formadas por: administração, produção e estratégia empresariam. A área de serviços aos

clientes são: o gerenciamento de produtos, o transporte e vendas, e dentro da área de vendas

existem as subdivisões que são compostas por gerenciamento de contas de clientes e

processamento de reclamações. Observa-se também o relacionamento de dependência entre as

diversas áreas dentro da organização.

A figura 7 representa (com auxílio do diagrama de componentes da UML), as

principais áreas funcionais e processos envolvidos dentro de uma organização. Com isso

permite que todas as pessoas envolvidas dentro da organização possam ter a participação nas

diversas áreas da empresa. É composto de dois componentes principais que são: componente

de processo de negócio e componente de serviços a clientes. Para o componente de negócio,

os seus subcomponentes são classificados em componentes de administração, de produção e

estratégico empresarial. Para o componente serviço a clientes seus subcomponentes são:

gerenciamento de padrões, de transporte e de vendas (que é composto por: gerenciamento de

contas de clientes e processamento de reclamações).

54

Figura 7- Participação das áreas funcionais nos processos de negócios de uma empresa manufatureira, Lambert

(2001).

A figura 8 mostra a visão dos componentes das principais áreas funcionais de uma

empresa com as descrições das notações sobre a administração, a produção o estratégico

empresarial, adaptado do autor (LAMBERT, 2001).

Figura 8- Detalhes da participação da área funcional nos processos de negócios de uma empresa manufatureira,

Lambert (2001).

55

A figura 9 mostra as principais características do componente de vendas de uma

empresa manufatureira (LAMBERT, 2001).

Figura 9- Detalhes da participação da área funcional nos processos de negócios de uma empresa manufatureira,

Lambert (2001).

2.4.2. Processos e Gestão de Negócios

Dentro das organizações existem diversas áreas que analisam os processos de negócios

tais como: métodos, qualidade, jurídico, informática, estratégia, auditoria, recursos humanos,

controladoria e marketing. Para convergir todas essas informações específicas sobre cada

processo de negócio (diferentes atributos e relacionamentos do processo), requerem que haja

uma visão compartilhada da estrutura para gerar conhecimentos e tomadas de decisões por

parte de seus gestores (SORDI, 2005). A tabela19 classifica os principais problemas na

integração corporativa dos processos. Descreve os principais conflitos que possam aparecer

na empresa, tais como: metodologias, utilização de ferramentas, que não são adaptadas para a

organização, os conceitos utilizados, o compartilhamento de recursos e estruturas, base de

dados e áreas de apoio ao processo não ajustadas.

56

Conflitos de processos Descrição Metodologias aplicadas Todas as áreas possuem metodologias diferentes.

Técnicas utilizadas As técnicas utilizadas dentro da organização são diferentes.

Ferramentas usadas Possuem diversos tipos de ferramentas aplicadas dentro da empresa.

Conceitos sobre os processos As áreas trabalham com abstrações lógicas do processo são diferentes.

Atributos do domínio Diferentes atributos para as mesmas abstrações.

Relacionamentos entre os atributos Diferentes atributos e relacionamentos da lógica do processo.

Compartilhamento da estrutura Não existe visão compartilhada da estrutura. Compartilhamento das idéias e informações As idéias e informações são divergentes. Terminologia utilizada Não existe um padrão de terminologias

Abstração do processo Abstração lógica do processo com denominações diferentes.

Base de dados não compartilhadas Diversos tipos de base de dados.

Escopo diferenciado São visões diferentes do conjunto de atividades, produtos, clientes e demais componentes do processo.

Área de apoio ao processo Trabalha com escopo diferenciado (visões diferentes do conjunto de: atividades, produtos, clientes e demais componentes do processo).

Tabela 19- Conflitos de processos, adaptado de Sordi (2005).

2.4.3. Gestão por Processos e Investimentos na Área de TI

As definições descritas a seguir, são adaptadas dos autores Laurindo e Rotondaro,

(2008). A aplicação da gestão por processos nas empresas tem aumentado a sua

competitividade, e com isso observa-se o crescimento também dos investimentos em

aplicações de TI. A TI tem sido responsável pelo direcionamento e alinhamento estratégico

de negócios das organizações. Segundo os autores, os principais questionamentos

relacionados a TI são: a) pode haver integração da gestão de processos com TI de forma que

possa aumentar a produção de seus produtos ou serviços diante de um mercado competitivo?

b) quais são as estratégias e processos críticos? c) quais são os resultados para justificar os

grandes investimentos na área de TI? d) pode realmente os investimentos de TI trazer grandes

impactos nas estratégias das organizações? Conforme os autores citados acima, existem

muitas dificuldades de alinhamento de melhorias em relação aos objetivos e as necessidades

das empresas com o mercado de tal forma que possa agregar realmente valores a seus

produtos ou serviços; além disso, os projetos estão dissociados à melhoria da qualidade e

produtividade.

A estratégia adotada pelas empresas para melhorar a competitividade está na

atribuição do valor ao cliente. A qualidade significa fazer um bom produto e deve também

promover um bom serviço, além de acompanhar o que o cliente valoriza conforme mostra a

57

formulação: valor= (qualidade x serviços associados) / (custo x tempo de ciclo). Segundo os

autores Laurindo e Rotondaro (2008) alguns destaques em relação do valor do cliente são: a)

fazer com que estabeleça uma expressão de forma quantificável. b) Considerar a qualidade, a

velocidade a pontualidade e custo c) Acompanhar as variações no valor do cliente. Para a

gestão por processos deve-se considerar a interação do cliente, seu ambiente, o atendimento, a

estratégia, os produtos, os serviços, seus fornecedores, as tecnologias, as pessoas, enfim tudo

que possa descobrir o que o cliente valoriza. Identificam três importantes catalisadores e

vetores que analisam o processo de mudança e conteúdo da gestão por processos. A tabela 20

mostra um indicador para medida de qualidade de gestão por processos. Esta tabela permite

analisar o nível de qualidade em termos de aplicação de seus principais componentes

utilizados na administração e dentro de uma organização.

Vetor Sigla Componente Tecnologia da Informação TI Tecnologia Filosofia da Qualidade FQ Conceitual Potencialização e Trabalho em Equipe PTE Pessoas

Tabela 20– Vetores da gestão por processos, Laurindo e Rotondaro (2008). 2.5. Qualidades de Software

A garantia da qualidade de software (SQA – Software Quality Assurance) pode ser

definida segundo IEEE 610.12-1990 como grau para o qual um sistema, componente ou

processo vai ao encontro dos requisitos especificados e com expectativas ou necessidades dos

usuários ou clientes. Os três elementos que compõem e sustentam a SQA são: a gerência de

configuração, de requisitos e teste de software. A gerência de configuração trata da gerência,

controle e registro dos artefatos que compõem o software. A gerência de requisitos trata da

gerência, controle e registro das necessidades do sistema (requisitos) e dos usuários em todos

os níveis. Em testes de software, há a gerência, planejamento, controle e execução dos testes

em todos os níveis, (MOLINARI, 2008). Os gerentes de projeto precisam avaliar os riscos

regularmente para minimizar as chances de fracassos. O objetivo da gestão de riscos na

Engenharia de Software é realizar a prevenção e a mitigação dos riscos, para que o projeto

seja mais previsível e controlável. Para Higuera (1996), a gestão de risco possui as principais

atividades: a) identificação dos riscos, b) análise, c) planejamento, d) monitoração, e) controle

e f) comunicação.

58

Para se medir e estabelecer uma métrica de software, existem algumas características

que devem ser observadas e analisadas: as variedades de seus aspectos e a existência de

muitos elementos que são consideradas intangíveis. Segundo Koscianski e Soares (2006), em

software, as medições podem ser utilizadas antes da existência do produto, pois se determina

durante a análise de requisitos como deverá o sistema funcionar (quanto tempo o programa

poderá demorar em fornecer certa resposta). Com base nessa informação, os projetistas e

programadores definem os algoritmos mais adequados que influenciam no resultado de seus

trabalhos. Além disso, uma métrica permite tratar sobre a qualidade de um produto. Ao

escolher medidas para ser aplicada em um projeto de software, devem-se considerar algumas

características de custo de aplicação dessa medida, além de considerar os objetivos do projeto.

Atualmente, existem diversas medidas diferentes para se analisar a qualidade de um

software, dessa forma a escolha da métrica, do custo e dos objetivos a ser aplicada em um

software torna-se bastante importante na aplicação de um projeto. Conforme Koscianski e

Soares (2006), uma maneira organizada para o planejamento e medição de trabalho é o uso do

método GQM (Goal-Question-Metric), pois organiza o planejamento de medição de software

em etapas, e para cada etapa definem-se elementos em relação aos objetivos, questões,

categorias formulários. A tabela 21 descreve a estrutura do indicador, para medir a qualidade

e controle dos dados para auxiliar na melhoria de produtos e serviços analisados durante a sua

produção.

Atributos Descrição Numero de registro Descreve o controle de registros da entidade.

Objetivos Descrevem-se as funções dos requisitos do software, para controle de custos da avaliação, desta forma torna-se possível a alocação de mais recursos (tempo e quantidade de usuários contratados para teste).

Questões São as questões que são definidas para a realização do trabalho de medição, desta forma as respostas obtidas são as informações que poderão ser úteis para melhorar o produto.

Categorias Permite particionar o conjunto de dados obtidos.

Formulários

Permite conduzir o trabalho dos avaliadores. Desta forma evita que cada avaliador utilize um formato próprio, além de dificultar a tarefa de análise das informações, pois pode induzir a erros (tais como coleta de dados diferentes).

Coleta Obter dados para análise. Análise dos dados obtidos Obter resultados da pesquisa para tomada de decisões.

Tabela 21- Estrutura da entidade GQM, adaptado de Koscianski e Soares (2006).

A Figura 10 mostra as principais questões para avaliação e obtenção de dados

confiáveis para estabelecer medidas e julgamento de software (características de qualidade do

modelo SQuaRE), adaptado de Kosciansky, (2006). Para montagem dessas questões são

59

consideradas as seguintes características: a) qualidade das métricas, b) funcionalidade, c)

manutenibilidade (medidas de tamanho, complexidade estrutural, medidas baseadas no fluxo

de dados, acoplamento e coesão, UML e orientação a objetos, usabilidade, confiabilidade,

eficiência, portabilidade e análise dos resultados). Esses atributos representam o indicador que

são os componentes para a medição de software e estabelece um modelo para a

implementação, utilizando uma rede neural perceptron simples. A estrutura em árvore

descreve os principais componentes de medição de qualidade de software da norma SQuaRE.

Permite, assim, a implementação e eficiência na busca de resultados para auxílio na

tomada de decisão durante o desenvolvimento de um software. Os principais atributos

SQuaRE são: a) indicador (IndicadorSQuaRE ), b) método GQM (o MétodoGQM), c)

qualidade das métricas (QualidadeDaMetrica), d) funcionalidade (Funcionalidade), e)

manutenibilidade (Manutenibilidade) que está subdividida em: d1) tamanho (Tamanho), d2)

estrutura (Estrutura), d3) fluxo de dados (FluxoDeDados), d4) acoplamento e coesão

(Acoplamento & Coesão) e d5) UML e orientado a Objeto (UML&OO).

Há ainda as seguintes classificações: e) usabilidade (Usabilidade), f) confiabilidade

que está subdividida em: f1) disponibilidade (Disponibilidade e f2) falhas (Falhas). E para

concluir temos: g) eficiência (Eficiência), h) portabilidade (Portabilidade) e i) análise dos

resultados (AnaliseDeResultados).

Figura 10- Componente para medição de software (estrutura árvore), adaptado de Koscianski e Soares (2006).

A tabela 22 descreve em detalhes os principais componentes da medição de qualidade

do modelo SQuaRE, adaptado de Koscianski e Soares, (2006). Os principais componentes da

qualidade de desenvolvimento de um software são: o método GQM, a funcionalidade, a

manutenibilidade, a usabilidade, a confiabilidade, a eficiência e a portabilidade.

60

Componentes Descrição método GQM Organiza o planejamento de uma medição de software em etapas.

qualidade das métricas Estão definidas na tabela 22, (Qualidade das métricas).

funcionalidade

Uma parte da avaliação pode ser feita no início do desenvolvimento (fase de projeto da arquitetura). Acrescentar às tarefas de revisão a coleta de dados. As subcaracterísticas de interoperabildiade e acurácia podem ser também avaliadas inicialmente.

manutenibilidade

É classificada em: corretiva (modificações realizadas no software), adaptativa (resposta a modificações dos requisitos em produtos já projetadas e implementadas) e incremental (acréscimo às especificações do produto). Para PRESSMAM (2002), adiciona-se a manutenção preventiva (o produto é modificado de forma a facilitar a realização dos outros três tipos de manutenção).

usabilidade

Tem uma dependência forte de aspectos subjetivos, que são fatores não quantificáveis pelo avaliador em função de características próprias ao software. Segundo KOSCIANSKY e SOARES (2006), A verificação (check-list) é de baixo custo e pode ser muito efetiva.

confiabilidade Medir a confiabilidade significa estimar a probabilidade de ocorrência de falhas, porém é uma característica difícil de quantificar com precisão.

eficiência

A característica de eficiência possui as subcaracterísticas: comportamento temporal (são fáceis de definir) e utilização de recursos (relacionam-se com os elementos físicos que um software utiliza durante sua execução).

portabilidade Indica que um produto será adaptado para uso em uma plataforma diferente.

análise de resultados Sintetiza todo o conjunto de dados obtidos em uma informação única.

Tabela 22-Componentes da medição de qualidade do modelo SQuaRE, adaptado de Koscianski e Soares (2006).

2.5.1. Questões sobre a Qualidade das métricas

Durante os projetos, as métricas são empregadas para auxiliar na definição de tarefas e

alocação de recursos. Podem também ser empregadas para conhecer o desempenho individual

e de toda a equipe, permitindo avaliar estimativas de forma mais seguras dos recursos

alocados para cada projeto. Conforme mostra a tabela 23, alguns critérios mencionados no

modelo SQuaRE, durante a elaboração de novas métricas, pode-se escolher um de seus

componentes, adaptado de Scalet, (1999). Essa tabela descreve os principais critérios da

norma SQuaRE, utilizados para a medida de qualidade de um software.

61

Critérios para métricas Descrição

Significância Os resultados obtidos devem agregar informação útil à avaliação de qualidade.

Custo e complexidade Custo e complexidade de aplicação devem ser compatíveis com a avaliação a ser realizada.

Repetição As métricas devem ser repetíveis.

Reprodução As métricas devem ser reproduzíveis.

Objetiva A opinião das pessoas envolvidas deve ser limitada ou totalmente evitada.

Imparciais As métricas devem ser imparciais (maneira como as avaliações são realizadas).

Evidência As métricas devem prover evidência para sua validação.

Tabela 23-Critérios no modelo SQuaRE na elaboração de métricas, adaptado de Scalet (1999)

Segundo Koscianky e Soares (2006), em um desenvolvimento de software, as

medições podem ser utilizadas, mesmo antes de o produto existir, essas medições podem

também ser determinadas durante a análise de requisitos para auxiliar a conhecer o seu

funcionamento. Descreve-se a seguir alguns questionamentos estabelecidos pelos autores.

1) Quais são os resultados da precisão (da medida) e do custo utilizada para avaliar o

produto?

2) Quais são os critérios adotados segundo o modelo SQuaRE?

3) Os resultados obtidos agregam informação útil à avaliação de qualidade?

4) As métricas possuem custo e complexidade de aplicação compatível com a

avaliação realizada?

5) As métricas são possíveis de serem repetidas e os resultados são sempre os

mesmos e controláveis?

6) Caso as métricas sejam de difícil repetição, o seu tratamento podem ser

estatístico?

− Se a resposta for positiva, pode ser estabelecidas métricas de qualidade.

7) As métricas utilizadas podem ser possíveis de reprodução?

− Os resultados de uma medição devem ser os mesmos para avaliadores diferentes.

62

8) As métricas utilizadas são objetivas?

− É desejável que se utilize algum mecanismo de correção ou controle, ou que a

média estatística faça parte da métrica.

9) As métricas utilizadas são imparciais?

− É um critério que se refere à maneira como as avaliações são realizadas.

10) As métricas proveem evidências para a sua validação?

− É preciso prover informação a respeito do grau de confiabilidade dos valores

apresentados.

11) Existem medidas de comportamento temporal?

− Não é aceitável para sistemas críticos.

O modelo das questões propostas pelos autores Koscianski e Soares (2006) está

representado na figura 34 do item 4.4 capítulo-4. Através do uso desse formulário (check-list),

foram coletados as informações (de acordo com as experiências dos especialistas da área de

TI) das características da norma SQuaRE para análise da Qualidade de serviços prestados em

um ambiente de desenvolvimento de software. O objetivo é para estabelecer o nível de

impacto de risco de projeto a partir da proposta inicial da solicitação do serviço e auxiliar nas

tomadas de decisões dos especialistas de TI durante o ciclo de vida de um projeto de software.

2.5.2. Medidas de Software

Para Toscani e Veloso (2008), existem diversos casos em que as medidas não são

capazes de fornecer informações quantitativas sobre as características (qualitativas) avaliadas.

No ambiente de desenvolvimento de sistemas, as medidas em software são

dependentes da execução do sistema, quando já pronto, conforme os estudos de análise da

complexidade de um algoritmo, (considerado também como um tipo de métrica de qualidade).

A complexidade de um algoritmo reflete o esforço computacional requerido para

executá-lo. A dependência ou não da execução do programa é classificada em termos de uso:

63

estático (efetuada com base na informação a respeito do software) ou dinâmico (obtida a

partir da execução do software na máquina). As medidas da execução desse programa e das

suas características estão muitas vezes associadas aos dados não numéricos ou qualitativos,

fazendo com que a sua análise se torne difícil, exigindo desta forma um mapeamento

qualitativo para quantitativo para que se possa obter um melhor entendimento de sua

dimensão. As medidas dinâmicas são mais sensíveis a ruídos, pois podem afetar as métricas

de processo. Existe outra maneira de tratamento de requisitos qualitativos aplicando-se a

lógica nebulosa (ou lógica fuzzy), que permite lidar também com informações, cujo conteúdo

envolve incerteza (SOMMERVILLE, 2006; PAULA FILHO, 2003; NOGUEIRA, 2009;

NORMA IEEE 1044.1, 1995; PRESSMAN, 2011).

2.5.3. Método GQM (Goal-Question-Metric)

As dificuldades de obter-se as medidas para softwares estão nas variedades dos

aspectos e a presença de muitos elementos intangíveis. Em projetos de softwares, as medições

podem ser utilizadas já na análise de requisitos (fase inicial do desenvolvimento) para

determinar como o software deverá funcionar. Outra forma de medida de software é a

aplicação do método GQM (Goal-Question-Metric), consistindo em organizar o planejamento

de uma medição de software em etapas: a) objetivos que são estabelecidos de acordo com as

necessidades dos stakeholders e devem ser fixados em função dos requisitos de software

(tempo, quantidade de usuários contratados para teste), b) questões que são definidas para

realizar o trabalho de medição e que as perguntas devem trazer informação útil para melhorar

o produto, c) categorias que dividem o conjunto de dados obtidos e d) formulários que

conduzem o trabalho dos avaliadores, (KOSCIANSKI e SOARES, 2006). Conforme Basilis e

Weiss (1984), o método GQM (Goal-Question-Metric) é uma maneira organizada de tratar o

planejamento de trabalho de uma medição. O método organiza o planejamento de uma

medição de software em etapas, sendo que cada etapa define os seguintes elementos: a)

objetivos; b) questões; c) categorias e d) formulários. A tabela 24 descreve os principais

elementos utilizados no método GQM para descrição dos requisitos do software na realização

de medidas e avaliações do desenvolvimento de um software.

64

Elementos Descrição Objetivos São estabelecidos de acordo com as necessidades dos stakeholders. Devem ser

fixados em função dos requisitos do software.

Questões São definidas para realizar o trabalho de medição. São as perguntas que se espera responder com o estudo. As respostas devem trazer informação útil para melhorar o produto.

Categorias Particionam o conjunto de dados obtidos. As perguntas criadas no passo anterior podem trazer à tona diferentes tipos de informação.

Formulários

Conduzem o trabalho dos avaliadores. A vantagem de definir os documentos para anotação dos dados é evitar que cada avaliador utilize um formato próprio, pois pode dificultar a tarefa de análise às informações, além de induzir a erros como coleta de dados diferentes.

Tabela 24- Elementos principais do método GQM, adaptado de Basilis e Weiss (1984).

2.5.4. A NormaSQuaRE na visão de KOSCIANSKI e SOARES (2006)

O modelo SQuaRE baseado na ISO/IEC 25000 define as características de qualidade e

está centrado em um problema específico de medição da qualidade dos produtos de software.

A Tabela 25 descreve os tipos de qualidade relacionados a produtos conforme a descrição da

norma SQuaRE. Essa norma contém vários exemplos de métricas externas e internas que

podem ser utilizadas como ponto de partida para a construção de um sistema de avaliação da

qualidade de software. Nessa tabela são descritas as classificações e tipos das qualidades em

diversas visões.

Tipos de Qualidades Descrição

Qualidade em uso

Corresponde ao ponto de vista de um usuário. Quando se refere a um programa sendo executado, depende de diversos fatores: hardware (utilizado), treinamento (do usuário), condições (do ambiente), tarefa (sendo realizada).

Qualidade externa Considera o produto como caixa preta (verifica a qualidade externa). É uma estimativa da qualidade em uso.

Qualidade interna É avaliada na representação estática do produto (examina a arquitetura interna).

Tabela 25-Tipos de qualidade da norma SQuaRE, adaptado de Koscianski e Soares (2006).

A tabela 26 descreve a hierarquia da norma SQuaRE com as suas classes e também as

subclasses.

Classes Subclasses Funcionalidade Segurança, acurácia, interoperabilidade e adequabilidade. Manutenibilidade Testabilidade, estabilidade, modificabilidade e analisabilidade. Usabilidade Atratividade, compreensibilidade, apreensibilidade e operabilidade. Confiabilidade Maturidade, tolerância a falhas e recuperabilidade. Eficiência Comportamento temporal e utilização de recursos. Portabilidade Adaptabilidade, Instabilidade, Co-existência e Substitubilidade.

Tabela 26- Norma de qualidade SQuaRE, adaptado de Koscianski e Soares (2006).

65

Apresenta-se a seguir as descrições da norma SQuaRE com as características que estão

definidas na ISO/IEC 9126 (modelo de qualidade de software):

• Funcionalidade: Diz respeito àquilo que o software faz quando solicitado pelo

usuário. Refere-se à capacidade para o cumprimento de tarefas. A maneira como a

função é executada é algo que pode ser avaliado em função de suas características.

A ISO/IEC 9126 determina que seja estabelecido um escopo quando se faz a

definição de funcionalidade de um programa. É preciso definir um contexto de

uso para avaliar ou definir a funcionalidade.

• Manutenibilidade: Está relacionada à facilidade de modificação de um produto de

software. As métricas de manutenibilidade são importantes para o gerenciamento

das atividades de prever o esforço para modificar o software ou criar uma base de

dados histórica que acompanha o desenvolvimento.

• Usabilidade: Representa a facilidade do uso de um produto (depende da interface

com o usuário). Envolve a maior carga de fatores subjetivos durante a análise

(provavelmente a característica mais difícil).

• Confiabilidade: Um produto é confiável quando não falha. É a capacidade de

manter o nível de desempenho quando operando em certo contexto (funcionais).

• Eficiência: Todas as medidas de software devem ser feitas em ambiente

controlado.

• Portabilidade: Indica a possibilidade de um código-fonte ser utilizado em

diferentes plataformas de execução (operara em ambientes com características

diferentes).

Segundo Kosciansky e Soares (2006), a norma ISO/IEC 25000 é uma das mais

importantes quanto se trata de caracterização e medição de qualidade de produto de software e

está classificada conforme mostra a Tabela 27, onde são descritas as principais

caracterizações e medição de qualidade da norma SQuaRE que são classificadas em: a)

requisitos, b) modelo, c) gerenciamento, d) medições, e) avaliação. Todas essas características

são partes da aplicação e implementação de um software de qualidade.

66

Caracterização e Medição Descrição

Requisitos de Qualidade Permite estabelecer objetivos de qualidade para um produto (valores-alvo são previamente especificados), pois fazem parte da especificação de requisitos de software.

Modelo de Qualidade

Definem-se os conceitos de qualidade externa, interna e em uso. Além disso, permitem orientar diferentes perspectivas de avaliação. Possui um modelo hierárquico de características de qualidade permitindo que os atores envolvidos (no projeto) esperam de um produto.

Gerenciamento de Qualidade Os documentos são direcionados aos seus usuários (gerentes, programadores, avaliadores e compradores).

Medições

Permite definir o que é medição e descrição dos diversos aspectos relacionados com a tarefa (garantia da precisão dos resultados obtidos). Consiste na proposta de uma série de métricas que podem ser utilizadas ou adaptadas pelos usuários às normas e necessidades específicas.

Avaliação Concretiza na realização de uma avaliação de qualidade a partir de medições, em que os resultados são confrontados com um modelo definido pelo usuário.

Tabela 27-Caracterização e Medição da norma SQuaRE, adaptado de Koscianski e Soares (2006).

Medir a qualidade de software é o foco da série de documentos ISO/IEC 2502, que

estende a norma ISO 15939, classificando a medição de software em: a) tarefas (número total

de tarefas e tempo), b) funções de usuários e c) mensagens (de erros, analisadas pelos usuários

e total de erros). Os métodos de medição possibilitam a construção de novos dados. A análise

desses dados fornece um indicador sobre o produto. Já as descrições sobre os itens

mensuráveis são apresentadas na Tabela 28 (KOSCIANSKY e SOARES, 2006). Nessa tabela,

são descritas as caracterizações e medição de software da qualidade que são: a) tarefas

executadas, b) funções definidas de usuários e c) mensagens. Todas essas caracterizações são

úteis para a interação com o software desenvolvido.

Caracterização e Medição Descrição

Tarefas Número total de tarefas. Tempo para completar a tarefa.

Funções do usuário São as funções solicitadas pelos usuários.

Mensagens Erro: mensagem de erro mal compreendidas. Analisadas: mensagens analisadas pelo usuário. Total de erros: número total de mensagens de erros.

Tabela 28-Caracterização e medição de software, adaptado de Koscianski e Soares (2006).

2.5.5. Classificação de Riscos de Projeto (IEEE 1044.1, 1995)

Um risco de projeto pode ser do tipo quantitativo ou qualitativo e o principal objetivo

de uma análise de riscos está em desenvolver um conjunto de estratégias de prevenção de

riscos (IEEE, 1995). Conforme Paula Filho (2003), entre os fatores de riscos considera-se: a)

riscos legais, b) tecnológicos, c) tamanho, d) complexidade do problema. Todos esses fatores

67

estão relacionados ao pessoal e à aceitação pelo próprio usuário. Os riscos devem ser

estimados e monitorados. A estimativa de riscos envolve as principais tarefas de: a)

identificação (riscos possíveis de projeto), b) análise (avaliação e probabilidade e impacto do

projeto), c) previsão (medidas preventivas) e d) priorização (dos riscos prováveis e o impacto

no projeto).

2.5.6. Modelo de Desenvolvimento de Software Espiral

Proposto por Boehm (1988), o modelo espiral é um processo de software

evolucionário que acopla a natureza iterativa de um protótipo com os aspectos sistemáticos e

controlados do modelo cascata. Fornece potencial para o rápido desenvolvimento de versões

cada vez mais completo do software. As principais características do modelo espiral são

descritas como:

a) É um gerador de modelos de processos dirigidos a riscos e é utilizado para guiar a

engenharia de sistemas intensivos de software, que ocorre de forma concorrente e

tem múltiplos envolvidos.

b) É uma abordagem cíclica voltada para ampliar, incrementalmente, o grau de

definição e a implementação de um sistema, enquanto diminui seu grau de risco.

É uma série de pontos âncora de controle para assegurar o comprometimento de

interessados quanto à busca de soluções de sistemas que sejam mutuamente

satisfatórias e praticáveis.

A tabela 29 descreve o modelo de risco “espiral” de Boehm (1988) e as atividades que

definem as atividades de objetivos, avaliação e redução de risco e o planejamento para análise

de risco de projeto.

Atividades de Projeto Descrição

Definição de Objetivos Revisão. Avaliação e Redução de Riscos Análise de risco, protótipo, simulação, modelos, benchmark.

Desenvolvimento e Validação Requisitos e validação, design, projeto, código, testes, integração, aceitação operação.

Planejamento Requisito, ciclo de vida, desenvolvimento, integração, plano de teste. Tabela 29- Modelo Espiral das fases e atividades, adaptado de Boehm (1988).

68

2.5.7. Engenharia de Risco

Para Nogueira (2009), em um ambiente competitivo e de mudança cada vez mais

complexo, a gestão adequada da informação assume uma importância decisiva no processo de

tomada de decisão nas organizações, e a engenharia e a análise de riscos de software tornam-

se a base para a Gestão da Informação. A engenharia de Software, segundo Pressman (2002) é

definido como: a) estabelecimento e uso de sólidos princípios de engenharia, b) abrange

métodos, ferramentas e procedimentos que auxiliam gerentes nas tomadas de decisões.

Conforme Sommerville (2003), riscos podem ameaçar o projeto, o software que está

sendo desenvolvido ou a organização. Riscos podem ser classificados em: a) riscos de projeto

(afetam a programação ou os recursos do projeto), b) riscos de produto (afetam a qualidade ou

o desempenho do software em desenvolvimento), c) riscos de negócios (afetam a organização

que desenvolve ou adquire o produto). De acordo com Peters e Pedrycz (2001), a Engenharia

de Riscos pode ser classificada em análise e gerenciamento de riscos.

Na análise de riscos há as seguintes classificações: a) identificação, b) estimativa e c)

avaliação. O gerenciamento de risco: a) planejamento, b) controle, c) monitoração d)

direcionamento, e) recrutamento. Um risco de projeto pode ser estimado de forma quantitativa

ou qualitativa, pois o objetivo principal da análise de riscos é desenvolver um conjunto de

estratégias de prevenção de riscos (IEEE, 1995). A tabela 30 mostra a classificação de riscos

segundo a IEEE 1044.1, 1995.

O propósito do processo de gerência de riscos é de identificar, gerenciar e reduzir

continuamente os riscos nos níveis organizacionais tais como, mudanças nas hierarquias

superiores da empresa, de projeto e atrasos de cronogramas. Os riscos do projeto identificados

são documentados (inclui o contexto, condições, consequências para os riscos e partes que

serão afetados). Os riscos encontrados devem ser priorizados, estimados e classificados de

acordo com as categorias além de definição dos seus parâmetros. Em seguida devem ser

desenvolvidos planos para a redução de riscos, incluindo: níveis de riscos e ameaças,

atividades de acompanhamento, análise de custo e benefício, além de incluir responsáveis

(KOSCIANSKY e SOARES, 2006).

A tabela 30 descreve os níveis de impacto de riscos que podem ocorrer em um projeto

de software. A classificação pode ser aplicada com as técnicas da lógica fuzzy (com utilização

69

de variáveis linguísticas e conjunto de pertinência) para auxiliar nas tomadas de decisões em

situações de indecisão durante as fases de um projeto de software.

Classificação Descrição 1-Alto Apresentam risco alto de impacto no projeto. 2-Médio Apresentam risco médio de impacto no projeto. 3-Baixo Apresentam risco baixo de impacto no projeto. 4-Zero Apresentam risco desprezível de impacto no projeto.

Tabela 30-Classificação de Risco, adaptado de (IEEE 1044.1, 1995).

A premissa básica para uma boa governança em TI é o fato de que deve se conhecer o

ambiente interno para uma tomada de decisão acertada, pois o que não se conhece não pode

ser gerenciado. Outro aspecto relevante na análise de risco é a necessidade cada vez mais

exigida pelo mercado: a transparência das informações. Isso pode ser confirmado com o

número crescente de exigências pelos órgãos reguladores, tais como: Sarbanes- Oxley (SOX),

Lahti (2005), acordos de Basiléia I e II Saidenberg (2003), ISO 17799, ABNT (2005), ISO

27001, ISO/IEC (2005) ou a BS-7799, BSI (2001). Para a gestão de segurança da informação,

conforme (PEOTTA e GONDIM, 2008).

Os principais fatores de riscos para Paula Filho (2003) e Sommerville (2003) a serem

monitorados são: a) legais, b) tecnológicos, c) complexidade do produto ou serviço, d)

aceitação do usuário, e) organizacional, f) ferramentas, g) requisitos, h) estimativas

(identificação, análise, previsão e priorização). Um processo de Gestão de Risco possui as

principais atividades em: a) identificação, b) análise, c) planejamento, d) monitoramento.

Quanto aos objetivos da Gestão de Riscos, segundo Pivetta (2002), são baseadas em:

a) prevenção, c) mitigação. As principais atividades da Gestão de Riscos, conforme Higuera

(1996) são definidas em: a) identificação, b) análise, c) planejamento, d) monitoração, e)

controle, f) comunicação.

2.5.7.1. Classificação dos Riscos não Funcionais

Segundo Kotonya e Sommerville (1996), a classificação dos principais requisitos não

funcionais pode ser classificada em: desempenho, interface e interoperabilidade. A figura 11

mostra as principais classificações de requisitos não funcionais e os fluxos que podem ocorrer

entre as atividades de a) desempenho, b) interface e c) interoperabildiade. Esses requisitos

permitem assegurar a qualidade de verificação, portabilidade, recursos, eficiência, qualidade,

robustez, confiabilidade e manutenibilidade de um projeto de software. O desempenho e a

70

qualidade de um software dependem desses atributos, pois permitem que sejam realizadas as

análises de seu desempenho. As principais atividades são classificadas em: a) desempenho, b)

interface e c) interoperabilidade. As principais ações de desempenho são: a verificação, a

portabilidade e os recursos. Na interface há: a eficiência, a qualidade e a segurança. Para a

interoperabilidade: a robustez, a confiabilidade e a manutenibilidade.

Figura 11-Classificação dos requisitos não funcionais, adaptado de: Kotonya e Sommerville (1996)

2.5.7.2. Requisitos de Software

Os requisitos de um software são as descrições sobre seu comportamento, funções e

especificações das operações que devem realizar e especificações sobre suas propriedades ou

atributos. Os requisitos compreendem as funcionalidades presentes no software quando

estiver para ser executado. As áreas em questão para o estudo são: levantamento, análise,

especificação, rastreamento e validação de requisitos. As principais falhas em projetos são

relativas aos requisitos (dificuldades em entender o que o usuário quer e as descrições

incompletas e mudanças não controladas nos requisitos), conforme estudos de STANDISH

GROUP, 1995. Além disso, a realização correta do levantamento e administração de

requisitos é vital para a qualidade do software.

71

2.5.8. Norma SQuaRE e as suas características

A norma SQuaRE (Software Product Quality Requirement and Evaluation –Requisitos

de Qualidade e Avaliação de Produtos de Software), segundo Koscianski e Soares (2006), é

uma evolução de normas ISO/IEC 9126 e ISO/IEC 14598. Para Garcia (2009), a norma

SQuaRE reunifica os processos de qualidade de software (padrão ISO 9126) e a avaliação do

produto (padrão 14598) utilizando como base a medida de qualidade. As vantagens oferecidas

pela SQuaRE são: a) coordenar medidas e a avaliação da qualidade de software, b) oferecer

um guia para a especificação de requisitos de qualidade de software e c) harmonizar a

normativa já existente com respeito à norma ISO / IEC 15939, mediante o modelo de

referência de medida de qualidade pertencente à norma ISO / IEC 25020.

Quanto à organização padrão SQuaRE, existem cinco divisões: a) gestão da qualidade

(2500n), b) modelo de qualidade (2500n), c) medida de qualidade (2500n), d) requisitos de

qualidade (2500n), e) avaliação de qualidade (2500n).

A figura 12 mostra utilizando diagrama de atividades da UML, o fluxo da estrutura e

organização de padrões estabelecidas pela norma SQuaRE para medida de qualidade de

desenvolvimento de software, classificados em divisões que são: os requisitos de qualidade,

os modelos, o gerenciamento, as medidas e a avaliação da qualidade de serviços.

Figura 12- Estrutura da organização dos padrões, adaptado de Garcia (2009).

72

Conforme Garcia (2009), a especificação de requisitos e a avaliação de produtos

fazem parte da normalização. A tabela 31 mostra a classificação dos padrões definida pela

ISO / IEC 9126 e 14598 apresentando: as propriedades, medidas, referências, explicações, o

nivelamento, as avaliações, a escolha dos atributos, a regulamentação dos processos, a

especificação das adaptações e das documentações dos processos.

ISO / IEC Especificação

9126-1 Apresenta as propriedades que deveriam ter as medidas para as comparações.

9126-2 Apresentar as medidas de qualidades externas.

9126-3 Refere às medidas de qualidades internas.

9126-4 Explica as medidas de qualidade em uso.

14598-1 Enumera as medidas aplicáveis na avaliação de software e os requisitos que devem ser cumpridas.

14598-2 Explica como realizar o nivelamento e a gestão da avaliação.

14598-3 Explica como escolher atributos que representam os requisitos de qualidade.

14598-4 Regula o processo entre outras muitas coisas, que proporcionam exemplos de métodos de avaliação.

14598-5 Especifica como adaptar o processo geral de avaliação em torno dos mais específicos.

14598-6 Trata sobre a documentação do processo.

Tabela 31-Classificação dos padrões da série ISO / IEC 9126 e 14598, adaptados da norma ISO/IEC 9126 e 14598.

A figura 13 mostra as principais atividades e fluxos de interação, utilizando diagrama

de atividades da UML, para descrever a evolução das normas de qualidade e as suas

principais aplicações, segundo Garcia (2009) que são: a) recursos e ambiente, b) avaliação dos

processos, c) produtos de software, e) efeito gerado pelos produtos de software na aplicação

da qualidade de serviços. As principais ações definidas pelas normas que são: a) avaliação do

suporte, b) avaliação do processo, c) métricas (internas e externas), d) qualidade na utilização

das métricas e padrões definidos pelas normas.

73

Figura 13- Evolução das normas e sua aplicação, adaptado de Garcia (2009).

A figura 14 representa-se o fluxo de um ciclo de vida de projeto de software

(aplicando o diagrama de atividades da UML) utilizando os conceitos de qualidade e as suas

interações de informações, adaptado de Garcia, (2009). As principais atividades são: a)

processo, b) produto, c) efeito produzido pela aplicação da qualidade de serviços. Na

atividade de processo encontram-se os processos de qualidade, no produto de software,

existem os atributos (interno e externo) do produto de software contém os atributos de

qualidade. As transições entre os estados ocorrem as influências e dependências. Os detalhes

das ações estão descritas e utilizando-se os elementos de notações da UML (Linguagem de

Modelagem Unificada).

74

Figura 14- Ciclo de vida de qualidade de software, adaptado de Garcia (2009).

A figura 15 mostra a estrutura em forma de árvore para a implementação dos atributos

de qualidade de software. Essa estrutura permite estabelecer uma fundamentação para a

aplicação dos conceitos da teoria dos conjuntos e a aplicação dos operadores da teoria dos

conjuntos. Na visão da teoria dos conjuntos há: o conjunto “principal” como: qualidade de

produto de software e de seus subconjuntos que são compostos de: a) características, b)

subcaracterísticas, c) atributos.

75

Figura 15- Modelo de qualidade SQuaRE, adaptado de Garcia (2009).

A tabela 32 descreve as principais características relacionadas à qualidade dos

produtos de software segundo os autores Weber e Rocha, (1999). Nessa tabela descrevem-se

as abordagens utilizadas para avaliar a qualidade de produtos de software: a) características da

qualidade e métricas, b) avaliação dos produtos, c) requisitos de software.

Abordagem Descrição

1-Características da Qualidade e Métricas (ISO/IEC 9126:1991)

1.1-Funcionalidade: � Adequação. � Acurácia. � Interoperabilidade. � Conformidade. � Segurança.

1.2-Confiabilidade: � Maturidade. � Tolerância a falhas. � Recuperabilidade.

1.3-Usabilidade: � Inteligibilidade. � Apreensibilidade. � Operacionalidade.

1.4-Eficiência: � Comportamento no tempo. � Comportamento dos recursos.

1.5-Manutenibilidade: � Analisabilidade. � Modificabilidade. � Estabilidade. � Testabilidade.

76

Tabela 32- Qualidade dos produtos de software, adaptado de Weber e Rocha (1999).

1.6-Portabilidade: � Adaptabilidade. � Instabilidade. � Conformidade a padrões. � Portabilidade. � Substituibilidade.

São apresentadas adaptações das subcaracterísticas da qualidade: � Na eficiência:

� Substituição comportamento dos recursos. � Na portabilidade:

� Inclusão da coexistência. � Na conformidade:

� Inclusão da conformidade em todas as características..

2-Avaliação dos Produtos de Software

2.1-Visão geral (ISO/IEC 14598-1): � Avaliação da qualidade dos produtos de software. � Definição dos termos técnicos utilizados. � Conceito e funcionamento do processo de avaliação da

qualidade de qualquer tipo de software. 2.2-Planejamento e Gerenciamento (ISO/IEC 14598-2):

� A norma contém requisitos e guias para suportar funções de avaliação dos produtos de software.

2.3-Processo para Equipe de Desenvolvimento (ISO/IEC 14598-3):

� Uso durante o processo de desenvolvimento e manutenção de software:

� Critérios para seleção de indicadores de qualidade.

� Guia para avaliar dados de medição. � Guia para melhoria do processo de medição.

2.4-Processo para Adquirentes (ISO/IEC 14598-4): � Estabelece um processo sistemático para avaliação de

produtos de software. 2.5-Processo para Avaliadores (ISO/IEC 14598-5):

� Fornece orientações para implementação prática de avaliação de produto de software.

2.6-Documentação de Módulos de Avaliação (ISO/IEC 14598-6): � Define a estrutura e o conteúdo da documentação a ser

usada na descrição dos módulos de avaliação.

3-Requisitos da Qualidade e Testes em Pacotes de Software (ISO/IEC 12119:1994)

3.1-Descrição do Produto: � Estabelece as propriedades do produto, com o propósito

de orientar potenciais compradores na avaliação da adequabilidade do produto antes de comprá-lo.

3.2-Documentação do Usuário: � O conjunto completo do documento, disponível é

fornecido para a aplicação do produto de software e também como parte integral deste produto.

3.3-Programas e Dados: � O conjunto completo de programas de computador e

dado é fornecido para aplicação do produto de software e também como parte integral deste produto.

77

Segundo Weber e Rocha (1999), o processo de avaliação de software é definido

conforme a tabela 33 (norma ISO/IEC). A tabela 33 descreve os principais aspectos utilizados

em uma avaliação de requisitos de qualidade para um pacote de desenvolvimento de software

classificados em: a) descrição do produto, b) documentação do usuário, c) programas

desenvolvidos, d) dados definidos. A definição de testes de software utilizam-se: a) pré-

requisitos de testes, b) atividades de testes, c) registros e, d) relatórios de testes.

Aspectos de Pacote Descrição

1-Descrição do produto

1.1-Requisitos gerais sobre o conteúdo. 1.2-Identificação e indicações. 1.3-Declarações sobre funcionalidade. 1.4-Declarações sobre confiabilidade. 1.5-Declarações sobre usabilidade. 1.6-Declarações sobre eficiência. 1.7-Declarações sobre manutenibilidade. 1.8-Declarações sobre portabilidade.

2-Documentação do Usuário

2.1-Completitude. 2.2-Correção. 2.3-Consistência. 2,4-Inteligibilidade. 2.5-Visão geral.

3-Programas e Dados

3.1-Funcionalidade. 3.2-Confiabilidade. 3.3-Usabilidade. 3.4-Eficiência. 3.5-Manutenibilidade. 3.6-Portabilidade.

Instruções de teste Descrição

1-Pré-requisito de teste 1.1-Presença dos itens do produto. 1.2-Presença do hardware e software necessários. 1.3-Treinamento.

2-Atividades do teste 2.1-Descrição do produto. 2.2-Documentação do usuário. 2.3-Programas e dados.

3-Registros do teste

4-Relatórios do teste

4.1-Identificação completa do produto de software. 4.2-Configuração do hardware e software utilizada na avaliação dos programas e dados. 4.3-Documentos usados. 4.4-Resultados da avaliação da descrição do produto, da documentação do usuário e dos programas e dados. 4.5-Listar conformidades e não-conformidades quanto a recomendações. 4.6-Listar conformidades e não-conformidades quanto a recomendações. 4.7-Local e data da conclusão da avaliação. 4.8-Nome completo e assinatura do pessoal envolvido na avaliação.

Tabela 33- Avaliação dos requisitos da qualidade, adaptado de Weber e Rocha (1999).

78

2.5.9. Matlab e planilha Excel

MATLAB (MATrix LABoratory – Laboratório de Matrizes), é um programa de

computador de uso específico, otimizado para executar cálculos científicos e de engenharia.

Nasceu como um programa para operações matemáticas sobre matrizes, mas logo se

transformou em um sistema computacional flexível capaz de resolver essencialmente

qualquer problema técnico. Além disso, implementa uma ampla biblioteca de funções pré-

definidas para que a programação técnica se torne mais fácil e eficiente (CHAPMAN, 2011).

Hoje, a capacidade do Matlab se estende muito além do “Laboratório de Matrizes”

original. O Matlab é um sistema interativo e uma linguagem de programação para

computação técnica e científica em geral. Seu elemento de dados básico é uma matriz que não

requer dimensionamento, permitindo solucionar muitos problemas numéricos

(HANSELMAN e LITTLEFIELD, 1997). Uma planilha Excel é um programa que foi

projetado para armazenar, resumir, recuperar e apresentar dados relevantes rapidamente. O

programa possui várias pastas de trabalho pré-definidos que podem ser usadas para tarefas

como: controlar as horas de trabalho, calcular pagamentos de empréstimos, criar e formatar

pastas de trabalho ou criar qualquer pasta de trabalho. (FRYE, 2008).

79

3. TÉCNICAS DA LÓGICA FUZZY E REDES NEURAIS

A fundamentação teórica deste capítulo tem o seu embasamento construído a partir da

revisão bibliográfica sobre autores de Inteligência Artificial, Lógica Fuzzy e Redes Neurais

Artificiais.

3.1. Sobre Inteligência Artificial

Segundo Coppin (2004), a inteligência artificial é o estudo dos sistemas que agem de

um modo que a um observador qualquer pareceria inteligente. Em muitos, casos as técnicas

de Inteligência Artificial são utilizadas para solucionar problemas simples ou complexos e

fazem parte de sistemas mais complexos.

Qualquer aplicação computacional que execute tarefas, consideradas pelos seres

humanos como “inteligentes”, pode ser denominado um sistema baseado em inteligência

artificial (CAMPOS e SAITO, 2004). De acordo com Barr e Feigenbaum (1981), inteligência

artificial é a parte da ciência da computação envolvida no projeto de sistemas que exibem

características que são associadas à inteligência no comportamento humano.

3.1.1. Sistemas Inteligentes

Para Shaw e Simões (2004), sistemas inteligentes são aqueles que fornecem respostas,

solucionam problemas, apropriadas para situações específicas, mesmo que sejam novas ou

inesperadas, e as operações desses sistemas inteligentes associam-se aos sistemas biológicos.

A lógica fuzzy (incerto e impreciso) é a forma como as pessoas pensam e se

comportam de forma dedutiva durante as tomadas de decisões pessoais ou em busca de

alguma solução para os problemas dentro da organização. O raciocínio indutivo permite que o

aprendizado seja generalizado através de exemplos e observações ou através de experiências

de tal forma que se ajuste ao seu ambiente e ao domínio de sua atuação. Ainda para Shaw e

Simões (2004), a lógica fuzzy é uma técnica que incorpora a forma humana de pensar em um

sistema de controle. Já para Branã (2008), o conhecimento necessário para a construção das

regras de inferência pode provir de pessoas especialistas na área, mas também pode ser

extraído de bancos de dados em forma mais automatizada, segundo o caso.

80

3.1.2. Sistemas Especialistas

Um sistema especialista é um sistema que reproduz o conhecimento de um especialista

adquirido ao longo dos anos de trabalho (KANDEL, 1992). Para Schildt (1989) um sistema

especialista são programas que imitam o comportamento de especialistas humanos, pois

utilizam a informação que o usuário oferece para emitir uma opinião sobre certo assunto e faz

perguntas para identificar algo que o leve a respostas. Conforme Nascimento Jr., e Yoneyama

(2004), um sistema especialista permite que conhecimentos possam ser disseminados e

utilizados por um grande número de pessoas, sem necessidade da presença do especialista.

Permite, ainda, que conhecimentos de vários especialistas possam ser amalgamados

em uma só base de dados. De acordo com Campos e Kaku (2004), a estrutura básica de um

sistema especialista é formada pela base de conhecimento e a máquina de inferência. A base

de conhecimento armazena informações específicas juntamente com as suas regras, além do

assunto específico que serão tratadas.

A máquina de inferência, para Schildt (1989), é a parte do sistema especialista que usa

a informação obtida do usuário para encontrar um objeto correspondente que podem ser do

tipo: determinística ou probabilística. A tabela 34 descreve as principais vantagens oferecidas

por um sistema especialista (SE). Um sistema especialista auxilia na tomada de decisão para

solução de problemas complexos e indecisos. As principais vantagens apresentadas por um

sistema especialista são: conhecimento e participação de um especialista do assunto em

questão, o conhecimento interativo estabelecido entre o sistema e de seus usuários, o controle

e a simplicidade de forma transparente, a construção das regras utilizadas, a segurança e

estabilidade do sistema, a não dependência das pessoas, a flexibilidade e a integração homem-

máquina.

81

Vantagens (Sistemas Especialistas) Descrição

Conhecimento específico de especialistas O sistema separa o conhecimento específico do especialista e a metodologia da solução.

Conhecimento interativo A transferência interativa de conhecimento pode diminuir o tempo para transferir o conhecimento do especialista para uma base de conhecimento.

Controle simples e transparente A estratégia de controle pode ser simples e transparente ao usuário.

Construção de regras Permite a construção de regras.

Tomada de decisão sob imprecisão Permite a tomada de decisão sob imprecisão ou ausência de informação.

Determinação de problemas Velocidade na determinação de problemas.

Segurança Exige pequeno número de pessoas para interagir com o sistema.

Estabilidade Utiliza regras no controle e tomadas de decisão. Diminuição de dependência Dependência decrescente de pessoal específico. Flexibilidade Utiliza variáveis linguísticas. Integração Permite a integração de ferramentas.

Tabela 34- Vantagens de Sistemas Especialistas, adaptado de Fernandes (2004).

A figura 16 mostra a arquitetura de um sistema de inferência da lógica fuzzy. A sua

base de conhecimento são compostas de dados e regras, estabelecidas durante o projeto. A sua

unidade lógica estão as decisões e mecanismos responsáveis pela transformação dos valores

da fuzzificação em valores de defuzzificação, além disso, verificam-se, também, as

consistências entre valores das entradas e saídas do sistema.

A estrutura de um sistema de inferência através das técnicas da lógica fuzzy é

composta pelos principais componentes: a fuzzificação, a base de conhecimento em que são

definidas as regras e os dados, além disso, há também a defuzzificação e a unidade de decisão.

Na fuzzificação são utilizadas as variáveis linguísticas para definição do nível de

entrada do problema a ser solucionado, na base de conhecimento estão as regras e a aplicação

dessas regras que foram definidas pelos especialistas da área. Na defuzzificação são recriados

os valores em termos quantitativos para atribuição do nível de pertinência e na unidade lógica

de decisão a definição dos valores que devem ser apresentados na saída para a solução dos

problemas apresentados em sua entrada.

82

Figura 16- Sistemas de Inferência fuzzy, Ludwing Junior (2007).

3.1.3. Lógica Fuzzy

No mundo real existem muitas áreas nebulosas, (SCHILDT, 1989). Para Fernandes

(2004), a lógica fuzzy é uma poderosa técnica para solução de problemas, com vasta

aplicabilidade, especialmente nas áreas de controle e tomada de decisão. Para Nascimento Jr.,

e Yoneyama (2004), a lógica fuzzy permite o tratamento de expressões que envolvem

grandezas descritas de forma não exata. Utiliza conjuntos nebulosos para a formalização de

seu conceito que estende a teoria clássica de conjuntos. Os conjuntos nebulosos são definidos

por A= {x ε X / µA(x)=ξ, 0 ≤ ξ ≤ 1}, onde µA(x): X �[0,1] é a pertinência que expressa o

quanto um dado elemento x pertence ao conjunto A. Ainda de acordo com os autores

Nascimento Jr e Yoneyama (2004), existem domínios de aplicação em que a imprecisão é

parte inerente ao problema analisado. Isso pode ser devido a dados ausentes, a erros nas

medições técnicas ou a relações causa-efeito não determinísticas. A classificação dos

diferentes tipos de imprecisão e seus possíveis tratamentos: imprecisão inerente à linguagem

de representação em que a informação é expressa; informação incompleta; confiabilidade

parcial que se tem na informação; agregação ou sumarização da informação que provêm de

múltiplas fontes. Para Branã (2008), a representação da imprecisão ou ambiguidade de certos

conjuntos e variáveis (conjuntos e variáveis fuzzy) e sua combinação e manipulação

matemática (aritmética fuzzy), e por outro lado, uma forma de inferência lógica (inferência

fuzzy) a partir de regras do tipo (se - então) utilizando os anteriores conjuntos e variáveis e, a

partir dos quais se atingem conclusões que não são, necessariamente, nem verdadeiras nem

falsas, mas podem representam certo conhecimento sobre uma área.

Na teoria de conjuntos nebulosos (ou fuzzy), busca-se traduzir em termos formais a

informação imprecisa que ocorre de maneira natural na representação dos fenômenos naturais,

83

utilizando uma linguagem corriqueira, (NASCIMENTO Jr., e YONEYAMA, 2004). Para

Fernandes (2004), a força da lógica nebulosa deriva da sua habilidade em criar conclusões e

gerar respostas baseadas em informações vagas, ambíguas e, qualitativamente, incompletas ou

imprecisas.

Conforme Branã (2008), Ortega (2001) e Ilanthenral (2007), uma das principais

vantagens da teoria de conjuntos fuzzy em relação a outras abordagens de modelagem

matemática é a facilidade de compreensão de seus conceitos por parte de profissionais, cuja

formação não é na área de ciências exatas. A possibilidade de trabalhar com variáveis

linguísticas, próximas à linguagem natural, faz com que sintam à vontade para expressar o

seu conhecimento. Essas características da lógica fuzzy facilitam o aperfeiçoamento dos

modelos criados (mediante o ajuste da descrição de cada variável e suas relações fruto do

aporte da experiência de distintos especialistas), viabilizando a interdisciplinaridade de

trabalhos com o intuito de abordar problemas complexos em forma mais realista.

Na natureza, muitos sistemas não podem ser caracterizados de uma maneira absoluta,

do tipo verdadeiro ou falso. O conceito de subconjunto fuzzy foi introduzido de forma a evitar

passagens bruscas entre duas classes e permitir que os elementos não pertençam

completamente nem uma, nem outra classe. Permitem que os elementos possam pertencer,

parcialmente, a cada uma delas (MASSA de CAMPOS e SAITO, 2004). As principais

contribuições sobre as técnicas na lógica fuzzy apresentadas nas literaturas pelos diversos

autores em artigos, dissertações e teses são descritas na tabela 35. O modelo da lógica fuzzy,

segundo Aguiar e Oliveira Junior (2007), compreende três etapas: fuzzificação, inferência e

defuzzificação.

A figura 17 mostra a estrutura de um modelo de forma genérica da estrutura da lógica

fuzzy. Mostram-se as representações das formas de ondas geradas e também os seus principais

componentes que geram os seus resultados.

84

Figura 17- Modelo Fuzzy Genérico, Aguiar e Oliveira Junior (2007).

A tabela 35 descreve as técnicas da lógica fuzzy aplicadas durante o projeto de um

aplicativo que trabalha com as questões de incertezas, segundo diversos autores, referente às

técnicas da lógica fuzzy.

Autores Descrições

CORNELISSEN, 2001.

A lógica fuzzy surge como uma alternativa, uma extensão da lógica clássica, para trabalhar as questões vagas, incertas ou mal definidas, presentes no raciocínio humano. Ela difere do tratamento dado pela Estatística, pois enquanto a incerteza nos modelos estatísticos está relacionada à casualidade dos eventos, a incerteza nos modelos fuzzy está relacionada à imprecisão ou vagueza dos conceitos.

A lógica fuzzy trata a incerteza não avaliando se um evento ocorrerá, mas sim o quanto ele ocorre ou ocorrerá.

COSENZA, 2006.

A lógica fuzzy estende a aplicação do conceito de matemática do definido para o indefinido permitindo representar melhor os conceitos vagos e incertos, bem como servir de base para modelagens qualitativas que lidam com variáveis linguísticas compreendendo expressões verbais que sintetizam os pensamentos, os sentimentos e as emoções.

DVORAK, 2003.

A “lógica fuzzy” tem sido utilizada em dois sentidos: num sentido restrito quando se refere a um processo de inferência, ou seja, tal qual a lógica booleana, e num sentido amplo quando se refere a um conjunto de métodos baseados na Teoria dos Conjuntos fuzzy, englobando também lógica fuzzy no sentido restrito.

FERNANDES, 2004.

A força da lógica fuzzy está na habilidade de criar conclusões e gerar respostas com base em informações vagas, ambíguas e qualitativamente incompletas e imprecisas.

A lógica fuzzy deriva da sua habilidade em criar conclusões e gerar respostas baseadas em informações vagas, ambíguas e qualitativas (incompletas ou imprecisas), tem uma habilidade de raciocinar semelhante à dos humanos.

KANDEL, 1992.

A lógica fuzzy é uma técnica poderosa para solução de problemas nas áreas de tomada de decisão.

A lógica fuzzy é uma poderosa técnica para solução de problemas aplicada nas áreas de controle, tomada de decisão, tarefas de gerenciamento das cotações na bolsa de valores e controle de sistemas de metrô.

85

MORAES, 2008.

A lógica fuzzy surge com a finalidade de processar as informações subjetivas, de natureza vaga e incerta, que encontramos na linguagem natural dos seres humanos.

A lógica fuzzy busca modelar as incertezas relacionadas a vagueza, imprecisão e subjetividade dos conceitos da linguagem humana. Essa capacidade dos subconjuntos fuzzy de expressar transições graduais da pertinência a não pertinência e vice-versa tem uma extensa utilidade. Ela provê não somente de uma significante e poderosa representação da medida de incerteza, mas também de uma significante representação de conceitos vagos expressados na linguagem natural.

Questões relacionadas às incertezas podem ser vistas em diversas áreas, desde questões surgidas em relação à questão ambiental, das condições de sobrevivência do homem na Terra, às questões relacionadas aos modelos matemáticos, como a Estatística e a lógica fuzzy.

SILVEIRA, 2005. Utilizando a técnica de lógica difusa é possível a manipulação simultânea de parâmetros numéricos e de informações de linguagem

ZADEH, 1965. A lógica fuzzy é proposta, em 1965, pelo Prof. Lotfi A. Zadeh, da Universidade da Califórnia, em Berkeley e desde então tem sido utilizada em diversas áreas, mas principalmente nas áreas de automação e controle.

Tabela 35- Técnicas da lógica fuzzy, segundo diversos autores da literatura.

3.1.3.1. Relação de Pertinência e Conexão

Conforme DE Maio (2007), a relação de pertinência está associada às relações entre as

memórias de primeira e segunda ordem, pois, quando existe uma relação sináptica entre um

elemento “a” (pode ser um registro sensório de primeira ordem ou registro de segunda

ordem), e um conjunto A, (registros de segunda ordem), conclui-se que existe uma relação de

pertinência (conexão entre “a” e o conjunto A).

3.1.3.2. Funções de Pertinência

Funções de pertinência fuzzy representam os aspectos fundamentais de todas as ações

teóricas e práticas de sistemas fuzzy. Uma função de pertinência é uma função gráfica ou

tabulada que atribuem valores de pertinência fuzzy para valores discretos de uma variável, em

um universo de discurso, (SHAW e SIMÕES, 2004). Os formatos mais utilizados são:

triângulos e trapezoides. Na figura 18, o eixo vertical descreve o conjunto do grau de

pertinência (que varia entre zero e um), o eixo horizontal, os valores do universo de discurso,

além da função de pertinência do tipo triangular ou trapezoidal, que descrevem o nível de

ativação da função. Para Weber e Klein (2003), as funções de pertinência definem o grau de

pertinência de um determinado valor a cada termo linguístico, pois fazem o papel das curvas

de possibilidades da teoria clássica da lógica fuzzy.

86

Figura 18- Funções de Pertinência, Ludwing Junior (2007).

3.1.3.3. Variáveis Linguísticas

Segundo Moraes (2008), as variáveis linguísticas são expressas por termos

linguísticos, interpretados como números fuzzy específicos, definidos, utilizando-se uma

variável base, que em termos clássicos pode ser exemplificada por qualquer fenômeno físico

(temperatura, pressão, velocidade, umidade) ou qualquer variável numérica (idade,

desempenho, salário). Os termos linguísticos representam valores aproximados da variável

base, relativos a uma aplicação particular, que são capturados por números fuzzy apropriados.

Segundo Costa (2011), as variáveis linguísticas podem ser expressas qualitativamente, por

meio dos termos linguísticos e quantitativamente pela função de pertinência. Todas as

variáveis linguísticas têm um conjunto fuzzy, conhecidos como termos primários que é o

conjunto de valores que a variável pode ter. Uma variável lingüística é usada para caracterizar

aproximadamente tanto os valores das variáveis como as suas relações (CURY, 2007).

3.1.3.4. Inferência Fuzzy

Para Moraes (2008), a inferência pode ser definida como uma operação intelectual por

meio da qual se afirma a verdade de uma proposição em decorrência de sua ligação com

outras já reconhecidas como verdadeiras ou ainda, deduzir por meio de raciocínio, tirar por

conclusão ou consequência. Pode também, relacionada à estatística, ser considerada uma

operação que consiste em, tomando por base amostras estatísticas, efetuar generalizações. Os

processos de inferência fuzzy são compostos basicamente de três elementos: as entradas, ou

inputs, ou ainda antecedentes, as saídas, ou outputs, ou ainda consequentes, e as regras de

inferência. Segundo Weber e Klein (2003), as regras em um sistema de controle fuzzy,

representam o conhecimento do sistema, pois uma vez conhecido os valores das variáveis

linguísticas, as regras definidas são responsáveis por determinar a ação que deve ser tomada.

87

3.1.3.5. Fuzzificação e Defuzzificação

Segundo Shaw e Simões (2004), a fuzzificação é um mapeamento do domínio de

números reais para o domínio fuzzy, representa a existência de atribuição de valores

linguísticos. Para Oliveira Junior (2007), fuzzificar significa usar uma variável lingüística

(transformação de valores numéricos em palavras), para descrever o comportamento de uma

variável real. Na defuzzificação o valor, da variável lingüística de saída inferida pelas regras

fuzzy será traduzido num valor discreto, pois obtém um único valor numérico discreto que

melhor represente os valores fuzzy inferidos da variável lingüística de saída (distribuição de

possibilidades) que as estratégias adotadas pelos autores: Mandani, Takagi e Sugeno. A figura

19, representa a estratégia de Mandani, utilizando os operadores de inferência MAX-MIN. Na

inferência MIN, o grau de pertinência de saída é cortado a uma altura que corresponde ao grau

de verdade computado pela regra de premissa (lógica fuzzy AND), (WEBER e KLEIN, 2003).

A MAX ou SOMA, segundo Weber e Klein (2003), representa uma relação de

composição, pois todos os subconjuntos fuzzy associados a cada variável de saída são

combinados para formar um único subconjunto fuzzy para cada variável de saída. Na

composição de MAX, o subconjunto fuzzy de saída combinado é construído pegando-se o

ponto máximo em cima de todos os subconjuntos fuzzy associados às variáveis pela regra de

inferência (lógica OR).

Figura 19- Estratégia de Mandani, Weber (2003).

A figura 20 mostra a aplicação da estratégia de Takagi e Sugeno. Este método de

raciocínio fuzzy, está baseado em uma descrição de modelo distinta, pois suas variáveis de

controle são caracterizadas pelas funções das variáveis de condição do processo que são

descritas por um conjunto de equações, (WEBER e KLEIN, 2003).

88

Figura 20- Estratégia de Takagi e Sugeno, Weber e Klein (2003).

A tabela 36 descreve os principais modelos aplicados na análise de pertinência durante

o processo de fuzzificação e defuzzificação, conforme as regras descritas e analisadas por:

Mamdani, Takagi e Sugeno, (1985).

Modelos Descrição

1-MAMDANI

A regra é: se x é A e y é B (A e B são conjuntos fuzzy), então z é C (C é conjunto fuzzy). O processo de defuzzificação visa obter um resultado não - fuzzy na saída do sistema de inferência. A defuzzificação pode ser feita pelo método do centróide, média dos máximos ou outros.

2-TAKAGI-SUGENO A regra é: Se x é A e y é B, então, z=f(x,y) onde A e B são conjuntos fuzzy e f é uma função real de x e y.

Tabela 36- Modelos de Inferência fuzzy, adaptado de Ludwig Junior (2007).

A figura 21 mostra o resultado de uma amostra da representação das saídas do modelo

MANDANI, utilizando a ferramenta matlab. Segundo Weber e Klein (2003), o método de

raciocínio fuzzy de MANDANI é baseado em operadores de inferência MAX-MIN. A

simulação foi realizada utilizando valores de entradas com valores de 0,924 para um universo

de discurso de valor entre 0 e 3. Para os valores atribuídos na entrada, o método com base nos

operadores de MAX-MIN gerou como valor de saída de 1,31. Ainda de acordo com Weber e

Klein (2003), o termo MIN é qualquer produto (operação E ou intersecção) de n variáveis

booleanas distintas. Enquanto o termo MAX é qualquer soma (operação de OU, ou união) de

“n” variáveis booleanas distintas. É demonstrada na figura 18 a utilização do método de

raciocínio Mandani, com base em operadores de inferência MAX-MIN, que são operadores

do tipo AND (interseção) e OR (união). Essas são as técnicas de raciocínio aplicadas na

proposta desta tese para auxiliar nas tomadas de decisões do sistema proposto

(NeurofuzzySQuaREBoehm).

89

Figura 21- Representação das saídas modelo MANDANI, adaptado de Weber e Klein (2003).

A tabela 37 resume as funções de pertinência para modelo triangular e trapezoidal

segundo os conceitos descritos pelo autor Oliveira Junior, (2007). As funções do modelo

matemático mais utilizado na lógica fuzzy são: a triangular e a trapezoidal. Para o

desenvolvimento da aplicação do sistema proposto “FuzzySQuaRE”, foi utilizada a função

triangular (como base), para a representação das saídas geradas pelo sistema.

Função (Modelos matemáticos) Descrição

1-Triangular

<<≤

<≤−−<≤−−

<

cbastrição

xc

cxbbcxc

bxaabax

x

cbaxf

:Re

;0

));/()(

);/()(

0;0

),,;(

A base dos números fuzzy triangulares é denominadasuporte do conjunto fuzzy, onde: a = valor pessimista. b = valor mais provável. c = valor otimista.

2-Trapezoidal

<≤<≥

<<−−≤≤

≤<−−<

dcbastrição

dx

dxccdxd

cxb

baabax

ax

cbaxf

:Re

,0

),/()(

,1

),/()(

,0

),,;(

Está totalmente definido pela quádrupla: (a, b, c, d) sendo a < b <= c < d constantes.

Tabela 37- Função de pertinência, adaptado de Oliveira Junior (2007).

A tabela 38 descreve as principais regras e operações fuzzy, conforme a descrição feita

pelo autor (LUDWIG JUNIOR, 2007). Com base nessas informações, torna-se possível

90

estabelecer regras e definições para a construção dos gráficos de pertinência e solução para os

problemas de tomadas de decisão. As regras obedecem aos conceitos de aplicação do tipo:

antecedente, da operação e do consequente.

Regras Descrição

Antecedente Faz parte da regra.

Operação

1-Conjunção: P=(x é A) Q=(y é B) p ^ q = MIN (µA(x); µB(y) ), onde A e B são conjuntos fuzzy. 2-Disjunção: P=(x é A) Q=(y é B) p v q = MAX (µA(x); µB(y) ), onde A e B são conjuntos fuzzy 3-Implicação: P=(x é A) Q=(y é B) p � q = MIN (1; 1- µA(x); µB(y) ), onde A e B são conjuntos fuzzy

Consequente Faz parte da regra. Tabela 38- Regras e operações fuzzy, adaptado de Ludwig Junior (2007).

3.1.3.6. Regras Fuzzy

Para Oliveira Junior (2007), toda regra tem um antecedente e um consequente. Para

uma regra, na lógica clássica, uma afirmativa pode ser verdadeira ou falsa, na lógica nebulosa

pode assumir graus de verdade. Conhecida como operação de composição, pode-se a partir de

duas proposições p e q unidas por conectivos lógicos definir as operações de:

1) Conjunção

xp (= é )A

yq (= é )B

)),();(min( yxqp BA µµ=∧ onde A e B são conjuntos Fuzzy.

2) Disjunção

xp (= é )A

yq (= é )B

91

)),();(max( yxqp BA µµ=∧ onde A e B são conjuntos fuzzy.

3) Implicação

xp (= é )A

yq (= é )B

))()(1;1min( yxqp BA µµ +−=→ , onde A e B são conjuntos fuzzy.

Conclui-se, que uma base de regras fuzzy é um conjunto de várias regras.

3.1.3.7. Lógica Fuzzy e a sua Aplicação em Sistemas Inteligentes

Para uma melhor compreensão sobre um controlador fuzzy, é necessário entender

sobre como as imprecisões e incertezas ocorrem em processos e plantas industriais, além de

saber como a aplicação usual da teoria de controle moderno permite a aferição e

confiabilidade dos resultados, que são obtidos através da aplicação da teoria da lógica fuzzy. A

lógica fuzzy possibilita o manuseio de informações imprecisas, prevendo métodos que

traduzem expressões verbais, imprecisas e qualitativas em valores quantitativos, (SHAW e

SIMÕES, 2004). O presente trabalho tem como enfoque converter a experiência humana em

valores numéricos compreensíveis pelo computador e auxiliar nas tomadas de decisões em

soluções de problemas complexos.

A teoria da lógica fuzzy permite também ser aplicada juntamente com as redes neurais,

conhecida como sistemas neurofuzzy, pois aumenta a capacidade de aprendizado através de

seus dados numéricos, possibilitando formar uma base de conhecimento. Um sistema

inteligente é capaz de fornecer respostas que solucionam problemas, apropriadas às situações

específicas. A lógica fuzzy é uma técnica que incorpora a forma humana de pensar, aplica-se o

raciocínio dedutivo e indutivo, possibilitando a aplicação da generalização e o aprendizado

em sistemas de controle inteligente. Tais recursos permitem que estes sistemas possam

aprender com a experiência e ser adaptativos em ambientes dentro do contexto de sua atuação,

(SHAW e SIMÕES, 2004). A tabela 39 descreve alguns princípios básicos de lógica fuzzy,

que são: o método heurístico, a bivalência e multivalência, o número fuzzy, as regras de

inferência, a fuzzificação, a defuzzificação, a pertinência, a função de pertinência e variáveis

linguísticas.

92

Princípios Descrição

Método heurístico

Consiste em realizar uma tarefa de acordo com a experiência prévia, com regras e estratégias que são freqüentemente utilizadas. Possibilita a construção de uma função de entradas x saídas, não matemáticas.

Bivalência x Multivalência

O atributo da bivalência utiliza dois valores que são: verdadeiro ou falso (não nada entre ambas, o meio é excluído). Já a multivalência utiliza os valores compreendidos entre [0,1].

Número fuzzy São representados pelo conjunto dos números reais, próximos de um número.

Implicação lógica e Regras de inferência

Implicação lógica: é a formulação de uma conexão entre causa e efeito. Já regras de inferência implicam em seguir um procedimento de tomadas de decisão do tipo SE... ENTÃO.

Fuzzificação

É o mapeamento do domínio de números reais (discretos) para domínio fuzzy. São a atribuição de valores linguísticos, descrições vagas ou qualitativas, definidas por funções de pertinência às variáveis de entrada.

Defuzzificação O valor da variável lingüística de saída inferida pelas regras fuzzy será traduzido num valor discreto.

Pertinência de um elemento Quando um elemento x pertence a um conjunto A.

Função de pertinência (µA(x))

Quando o valor indica se o elemento x pertence ou não ao conjunto A. Se µA(x) =1, então x pertence ao conjunto A, senão µA(x) = 0. A propriedade fundamental da lógica fuzzy é que a função de pertinência µA(x), tem todos os valores dentro do intervalo [0, 1]. É uma função numérica gráfica ou tabulada que atribuem valores de pertinência fuzzy para valores discretos de uma variável.

Variáveis linguísticas

Uma variável lingüística,u no universo de discurso U é definida em um conjunto de termos, nomes ou rótulos, T(u), com cada valor sendo um número fuzzy definido em U. T(velocidade) = {baixa, média, alta}, sobre o universo de discurso U = [0, 100].

Tabela 39- Princípios básicos de lógica fuzzy, adaptado de Shaw e Simões (2004).

A lógica fuzzy é uma poderosa técnica para solução de problemas, nas áreas de

controle e tomada de decisão. Permite criar conclusões e gerar respostas baseadas em

informações vagas, ambíguas e qualitativamente incompletas ou imprecisas, (FERNANDES,

2004).

3.1.3.8. Lógica fuzzy e a sua aplicação segundo autores da literatura

A tabela 40 descreve os principais trabalhos e aplicações das técnicas da lógica fuzzy,

segundo os principais autores da literatura apresentados em artigos, dissertações e teses. Os

trabalhos apresentados formam a base para a pesquisa e estudos da tese e a proposta da

aplicação da lógica fuzzy e redes neurais para auxiliar na avaliação do grau de incerteza na

93

solicitação de desenvolvimento de software, além de apresentar um modelo para avaliar

métricas qualitativas e quantitativas de análise da qualidade de serviços. São descritas também

as relações dos fundamentos apresentados pelos autores para a contribuição e realização desta

tese.

Autores Aplicação da Lógica fuzzy, segundo autores da literatura, (Tema, Trabalho, Proposta, Objetivo e Metodologias)

ALLEMÃO, Marco Antonio Freire, 2009.

Tema: Modelos não-lineares e Lineares para Previsão do Fluxo de reserva Bancária de um Banco Comercial; Rio de Janeiro-RJ; 2009 Trabalho: A realização do planejamento exige estudos e modelos de projeções das variáveis financeiras envolvidas, a fim de calcular os valores movimentados o mais próximo do realizado. Proposta: Avaliar as séries financeiras envolvidas na movimentação de um banco comercial brasileiro. Objetivo: Procura desenvolver um modelo neural que prediga o montante de recursos a serem transacionados em d + 2 (onde d representa o dia vigente) visando auxiliares os executivos no planejamento financeiro. Relação com a proposta desta tese: Os conceitos dos modelos lineares e não lineares utilizados na realização do planejamento e projeções das variáveis, foram aplicadas na implementação da base de conhecimento com a lógica fuzzy para calcular e transformar os valores discretizadas utilizando os mecanismos de fuzzificação e defuzzificação da lógica fuzzy.

APARECIDO DE OLIVEIRA, Mauri e AVILA MONTINI, Alessandra de., 2009.

Tema: Uma Abordagem para Análise de Projetos de Investimento Utilizando Método Financeiro com a Lógica Fuzzy. Trabalho: Analisa uma abordagem que considera diferentes tipos e efeitos de riscos sobre os critérios de decisão de um investidor. Proposta: Considerar o modelo de formação de preços de ativos de capital (CAPM – capital assetpricingmodel), identificação e mapeamento dos tipos de riscos de um projeto empresarial, aplicação de opções reais e lógicas fuzzy para gerenciar e avaliar os riscos e análise de rating de créditos dos diferentes tipos de riscos. Objetivo: Procurar sempre uma estrutura de capital ótima, de tal forma que sejam minimizados ao mesmo tempo os custos e os riscos. Relação com a proposta desta tese: A proposta na identificação e mapeamento dos tipos de riscos foi aplicada utilizando o modelo espiral de BOEHM da engenharia de software para análise de riscos de projeto de software.

94

BARBOSA DE MORAES, Odair, 2009.

Tema: Método de Análise de Dados para Avaliação de Áreas Urbanas Recuperadas – Uma Abordagem – Utilizando a Lógica Fuzzy; São Paulo – SP; 2008. Trabalho: Analisar as ações atuais, destacando-se as urbanizações de favelas, pouco se sabe sobre o seu desempenho. Proposta: Acrescenta-se à preocupação de avaliar estas ações, a necessidade de agregar, neste processo, a opinião dos moradores sobre o habitat recuperado. A Avaliação Pós-Ocupação (APO) e os sistemas indicadores têm sido utilizados como importantes ferramentas para o provimento de informações sobre o ambiente construído em diferentes escalas. Objetivo: Aliar as técnicas utilizadas para Avaliação Pós-Ocupação (APO) e sistemas indicadores com a lógica fuzzy para desenvolver ferramentas de análise, representando formalmente as informações vagas ou mal definidas presentes neste tipo de avaliação. Relação com a proposta desta tese: Os conceitos do método de avaliação e agregação de valores forma aplicadas na implementação da lógica fuzzy para a medida de qualidade e níveis de riscos de projeto, onde as informações qualitativas foram construídas e transformadas em valores quantitativas. Desta forma, foi possível a construção das representações na forma gráfica.

BARROS, Ana Claudia, 2009.

Tema: “Detecção e Classificação de Faltas de Alta Impedância em Sistemas Elétricos de Potência Usando Lógica Fuzzy”; Ilha – Solteira - SP; 2009. Trabalho: Apresentar uma metodologia, para detecção e classificação de faltas de curto-circuito, direcionada para os eventos de alta impedância em subestações de energia elétrica. Proposta: Usa dados oscilográficos que são processados de modo que a detecção e classificação das faltas para estimar um conjunto de características e extrair sinais de correntes.E a partir do conjunto de característica classificar utilizando a lógica nebulosa, com isso sua saída indicar o tipo da falta. Objetivo: Obtidos através de simulações de um modelo do alimentador radial no software ATP os diagnósticos de faltas. Relação com a proposta desta tese: Foram observadas e analisadas as formas de simulação para o desenvolvimento da classificação das redes neurais para as fases do impacto de risco de projeto.

BOREM, Bianca Ferreira,2008.

Tema: Aplicação de ferramentas de lógica nebulosa à predição de séries temporais; Rio de Janeiro - RJ, 2008. Trabalho: Modelar uma série temporal e prever um dado futuro é útil, pois torna possível a tomada de decisões e ações antecipadamente.

95

Proposta: Identificação dos parâmetros de um modelo nebuloso para sistemas não-lineares é um problema complexo, sendo comumente resolvido por tentativa e erro. Objetivo: Trabalho é o estudo de fundamentos teóricos para análise, desenvolvimento e implementação de ferramentas utilizadas na modelagem de dados de sistemas dinâmicos complexos e séries temporais com a finalidade de reprodução de suas saídas e predição. Relação com a proposta desta tese: A partir dos estudos realizados na forma como a ferramenta foi utilizada para a modelagem dinâmica em relação à predição das saídas, Aproveitou-se deste trabalho, o estudo de apresentar uma estrutura dinâmica utilizar os conceitos de árvore e grafos para estabelecer o ajuste dos pesos da rede neural como algoritmo de aprendizagem dinâmica como proposta de trabalho futuro.

CHAMOVITZ, Ilan e COSENZA, Carlos Alberto Nune, 2006..

Tema: Inovação em Educação com Internet: à distância, com o uso de Webquests e da Lógica Nebulosa; Engenharia de Produção da UFRJ; Rio de Janeiro-RJ; 2006. Trabalho: Oferecendo novas possibilidades na educação. Proposta: Uma técnica de Webquests(WQ). Objetivo: Despertar interesses por educadores e professores representar uma organização sistêmica, dos principais elementos que compõem este tipo de trabalho. Relação com a proposta desta tese: A relação da proposta desta TSE é de oferecer uma nova forma de política e padronização sistemática de prestação de serviços como uma nova forma de composição de trabalho entre equipes de diversas áreas.

CORRÊA DA SILVA, Frederico, 2008.

Tema: Um estudo sobre algoritmos genéticos, lógica fuzzy e técnicas para segmentação e classificação em imagens médicas; Pelotas; 2008. Trabalho: Desenvolver um ambiente computacional integrador de técnicas tradicionais de segmentação e classificação de imagens médicas com operadores baseados em algoritmos genéticos que possam permitir utilizar ferramentas mais versáteis e com precisão apropriada ao tipo de aplicação pretendida. Proposta: Integração de algoritmos genéticos e lógica fuzzy para a segmentação de imagens médicas. Objetivo: Servir como ponto de partida para um trabalho mais aprofundado de proposta da integração de algoritmos genéticos e lógica fuzzy para a segmentação de imagens médicas.

96

Relação com a proposta desta tese: A aplicação dos recursos de algoritmos genéticos e lógica fuzzy, é uma proposta para trabalhos futuros, que já está presente nesta tese, quando se estabelece as estruturas e cadeias definidas no modelo que pode ser observado na definição da relação da norma SQuaRE com o modelo espiral de BOEHM, apresentada no trabalho.

COSTA, Danielly Cristina de Souza, 2011.

Tema: Tomada de Decisão Baseada em Lógica Fuzzye na Distribuição Espacial da Mortalidade por Acidentes de Trânsito na Cidade de João Pessoa – PB; João Pessoa-PB; 2011. Trabalho: Estudar os acidentes de transito na cidade de João Pessoa, a partir da distribuição espacial e lógica fuzzy para a tomada de decisão das áreas prioritárias e não prioritárias. Proposta: Propor um modelo de decisão baseado em lógica fuzzy. Objetivo: Identificar as áreas prioritárias e não-prioritárias dos acidentes de transito na cidade de João Pessoa. Relação com a proposta desta tese: Com base no modelo de classificação de áreas, aplicou se este conceito na classificação de impactos de riscos de projetos de software, através da linha divisória onde determina o grau de pertinência de riscos com as técnicas da lógica fuzzy. Aplicam-se também os recursos das variáveis linguísticas e universo de domínio para apresentar graficamente os riscos de projetos que devem ser melhoradas.

COSTA, Maria Amélia e NOGUEIRA, Saraiva, 2010.

Tema: Metodologia de Avaliação da Qualidade do Ruído nos Postos de Trabalhos Industriais Baseada em Lógica Fuzzy; Belém-PA; 2010. Trabalho: Sobre o ruído que ocupa o terceiro lugar entre os agentes insalubres que mais afetam a saúde do homem. Proposta: A aplicabilidade da lógica fuzzy na avaliação da qualidade do ruído em postos de trabalho industriais, observando as variáveis: nível de ruído e a quantidade de horas trabalhadas. Objetivo: Através de a prevenção minimizar ou até mesmo eliminar problemas de saúde auditivos e não auditivos nos empregados que na atualidade são muito frequentes. Relação com a proposta desta tese: A metodologia da avaliação da qualidade do ruído, foi aplicado no modelo proposto para análise e avaliação da qualidade de serviços na prestação de serviços de software.

CURY, Marcus Vinicius Quintella, 2007.

Tema: Método para avaliar a percepção do usuário sobre a qualidade de sistemas de transporte urbano sobre trilhos com utilização da tecnologia neurofuzzy; Rio de Janeiro - RJ; 2007.

97

Trabalho: Avaliar e classificar a qualidade e o desempenho de sistemas de transporte urbano sobre trilhos - TUST, segundo a percepção de seus próprios usuários. Proposta: Apresenta um método heurístico alternativo, eminentemente qualitativo, baseado na tecnologia neurofuzzy. Objetivo: Comprovar a tecnologia neurofuzzy ser adequada no tratamento do conhecimento heurístico para imitar o raciocínio humano e pareceu ser de fácil entendimento, além de apresentar boa flexibilidade de utilização com dados vagos, incertos e subjetivos. Relação com a proposta desta tese: Os conceitos de avaliação, classificação e desempenho foram aplicados na ferramenta utilizando a norma SQuaRE e o modelo espiral de Boehm (1988). Utilizou-se também a aplicação da neurofuzzy para ajuste dos pesos ou ajuste do aprendizado.

FASCIONI, Lígia Cristina, 2003.

Tema: Indicadores para Avaliação da Imagem Corporativa das Empresas de Base Tecnológica Instaladas na Grande Florianópolis Baseados nas Análises das Percepções Gráfica e Verbal Utilizando Lógica Difusa; Florianópolis; 2003. Trabalho: Quantificar a diferença entre a identidade e a imagem corporativas por meio de um índice, aqui denominadas IFIC (Índice de Fidelidade à Identidade Corporativa). Proposta: Desenvolveu-se um método que compara os níveis de adequação de uma empresa a um conjunto de dez adjetivos avaliados sob o ponto de vista de seus gestores (identidade) e do ponto de vista de observadores internos e externos (imagem). Objetivo: Contemplar as incertezas oriundas do uso da linguagem natural, empregada para quantificar a adequação da empresa ao adjetivo, através da lógica difusa. Relação com a proposta desta tese: A proposta dos indicadores para quantificar a diferença entre as imagens foram utilizadas na criação de um identificador para avaliação das métricas qualitativas na avaliação e coleta de dados do formulário do tipo check-list e implementado na ferramenta proposta de controle de gestão na análise de riscos de projeto.

FERREIRA, Marcela Seixas; CABRAL LEITE, Jandecy e LAGO NETO, João Caldas do., 2010.

Tema: Produtividade: Desenvolvimento Computacional de Lógica Fuzzy Orientado na Produção Enxuta, Um Estudo de Caso em uma Empresa Eletro - Eletrônica do Pólo Industrial de Manaus– PIM; SIMPEP; Bauru-SP; 2010. Trabalho: O desenvolvimento de uma modelagem computacional: Fuzzy, para aumento de produtividade de aparelhos de 32´´ de LCD´s em uma fábrica do Pólo Industrial de Manaus onde foram identificados vários parâmetros baseados para produção enxuta. Proposta: Reduzir custos e aumento de lucros na organização.

98

Objetivo: Desenvolver um modelo computacional de Lógica Fuzzy para análise da produtividade de um processo industrial de fabricação de LCD (LiquidCrystal Display – Tela de Cristal Líquido), demonstrando variáveis que podem influenciar no alcance das metas estabelecidas pela organização e utilizando uma metodologia de investigação baseada no lean manufacturing. Relação com a proposta desta tese: A técnica de produtividade adotada com o uso da lógica fuzzy para análise da produtividade, foi implementada com a ferramenta proposta para análise da qualidade de serviços e participação da equipe na produtividade de qualidade e padronização de comunicação entre as pessoas envolvidas no desenvolvimento do projeto.

GONÇALVES, Edson Ricardo, 2007.

Tema: “Utilização da Lógica Fuzzy para Projeção dos Indicadores de Desempenho Estratégico”; Rio de Janeiro - RJ; 2007. Trabalho: A prática de elaboração de planos estratégicos para apoio à Gestão e utilizadas em inúmeras empresas e nas mais diversas áreas do conhecimento. Proposta: Traduzir a visão e estratégia em objetivos e medidas de desempenho. Objetivo: Facilitar a tomada de decisão do gestor na adequação das ações necessárias para se alcançar os objetivos estratégicos, utilizando a matemática nebulosa para fazer estas projeções. Relação com a proposta desta tese: Foram aplicadas as técnicas de elaboração das áreas de conhecimento dos especialistas de cada área na avaliação e desempenho da equipe durante a gestão de projetos de software com base na ferramenta proposta pela tese.

GONZALEZ RONDÓN, Rina Graciela, 2009.

Tema: Análise de Atenuação de Sinal em Ambientes INDOOR usando a Lógica Nebulosa; Campinas-SP; 2009. Trabalho: Análise de atenuação de sinais de ambientes Indoor usando a lógica nebulosa. Proposta: Atender à crescente demanda dos serviços sobre redes sem fio e tornar fundamental a importância o planejamento de enlace sem fio. Objetivo: Aplicação da lógica Fuzzy como ferramenta útil para cálculo de parâmetros β do modelo de propagação do sinal de Shadowing e possibilitar a obtenção de valores β que caracterizem com maior especificação a atenuação do ambiente em estudo. Relação com a proposta desta tese: A aplicação da lógica fuzzy na análise para atendimento da demanda dos serviços foi aplicada no planejamento e definição das especificações de requisitos e atendimento no prazo e cumprimento do cronograma na entrega de serviços de desenvolvimento de software segundo a demanda das solicitações.

99

LANDMANN, Raul e ERDMANN, Rolf Hermann, 2011.

Tema: Uma Abordagem Heurística para a Programação da Produção na Indústria de Fundição com Utilização da Lógica Fuzzy; Gestão de Produção; São Carlos – SP; 2011; Trabalho: Descreva a concepção, desenvolvimento e aplicação de uma metodologia para a programação da produção na indústria de fundição. Proposta: Determinar um seqüenciamento adequado de ordens de produção nas linhas de moldagem, combinado peças leves com peças de peso médio e com peças pesadas, de modo a obter uma demanda constante de metal líquido, em equilíbrio com a oferta de metal proveniente do forno. Objetivo: Sistematização do conhecimento e da capacidade de realizar simulações com rapidez e desempenho mais eficiente. Metodologia: Foi adotada a abordagem heurística com a utilização da lógica fuzzy, que oferece mecanismos para a representação e manipulação do conhecimento de especialistas, identificado em uma pesquisa qualitativa. Relação com a proposta desta tese: A abordagem heurística foi aplicada na criação do mecanismo de inferência para a ferramenta de análise de risco de projeto proposto neste trabalho. Desta forma, foi representado o conhecimento dos especialistas para auxiliar nas tomadas de decisões.

LIMA DA SILVA, Vladimir e LOPES DA SILVA, Paulo Afonso, 2004.

Tema: Mensurando a Qualidade dos Serviços de Empresas Aéreas Brasileiras – uma Abordagem Fuzzy; Rio de Transporte; Rio de Janeiro - RJ; 2004. Trabalho: Modelo de avaliação de desempenho que apoie o processo de tomada de decisão inerente à atividade e que sirva também como um modelo comparativo entre as diversas companhias. Proposta: Apresentar a qualidade dos serviços prestados pela empresa aérea quanto ao transporte de passageiros é tratada sob a ótica do usuário do sistema e contempla aspectos como: Acessibilidade, preço, adequação, relação com o cliente e confiabilidade. Objetivo: 1) Fornecer subsídios para o melhor entendimento da percepção da qualidade dos serviços prestados pelas companhias aéreas brasileiras por meio de um modelo de classificação baseado na aplicação de tecnologia Fuzzy; 2) Realizar o ordenamento (“ranking”) das empresas identificando as melhores e aquelas cujo desempenho seja deficiente; 3) Proporcionar rápida implementação computacional e ainda, de baixo custo. Relação com a proposta desta tese: O conceito aplicado na mensuração da qualidade de serviços foi estendido na aplicação e classificação das atividades e definição de fases de projetos segundo o nível de riscos definidos pela lógica fuzzy, através da rede neural MLP (Multilayer perceptron).

100

MALANGE, Fernando Cezar Vieira, 2010.

Tema: “Rede Neuro-Fuzzy-Waveletpara Detecção e Classificação de Anomalias de Tensão em Sistemas Elétricos de Potência”; Ilha Solteira - SP; 2010. Trabalho: Apresentar um sistema eficiente de identificador/classificador automático de distúrbios chamado de Rede neurofuzzy-Wavelet. Proposta: Analisar o desempenho da rede tais como: afundamento de tensão (sag), elevação de tensão (swell), os distúrbios de longo prazo como distorção harmônica, bem como distúrbios múltiplos simultâneos como afundamento de tensão com distorção harmônica e elevação de tensão com distorção harmônica. Objetivo: Analisar e testar o alto desempenho da rede na detecção e classificação correta dos tipos de distúrbios de tensão analisados. Relação com a proposta desta tese: As técnicas de detecção e classificação de tipos de distúrbios foram aplicadas na classificação das fases do modelo espiral em relação às camadas ocultas da rede MLP (Multilayer perceptron), onde os pesos de conexões e função de ativação e propagação diferem das redes neurais mais comuns (CAMPOS e KAKU, 2004).

MENDONCA NETA, Bernadete Maria De. 2005.

Tema: Procedimentos de Lógica Fuzzy na Solução de Problema de Controle de Tensão e Potência Reativa em Sistemas e Subsistemas de Potência; Belo Horizonte - MG; 2005. Trabalho: Aumento da eficiência na solução de um dos mais importantes problemas de engenharia de energia elétrica: o controle coordenado “on-line” de tensão e potência reativa em sistemas e subsistemas de potência, baseando-se no desenvolvimento de modelos, métodos e um sistema de controle (destinado a trabalhar interligado com o sistema SCADA e correspondente Estimador de Estado), integrando técnicas numéricas tradicionais e a tecnologia da teoria dos conjuntos fuzzy (lógica fuzzy). Proposta: Estudos e comparação, de diferentes pontos de vista que refletem as características de qualidade dos modelos fuzzy, os procedimentos de lógica fuzzy associados com diversos esquemas de inferência fuzzy e defuzzyficação. Objetivo: Análise e comparar procedimentos de lógica fuzzy foram baseados na utilização de uma técnica de tomada de decisões em ambiente fuzzy. E avaliar características da qualidade dos modelos fuzzy que reflete sua adequação. Relação com a proposta desta tese: A partir das técnicas analógicas apresentadas e o tratamento desses sinais utilizando os recursos de fuzzificação e defuzzificação, aplicou-se estas técnicas nos estudos relacionados às entradas de avaliação dos especialistas através de um formulário (check-list), onde foi aplicada a fuzzificação para cálculos das medidas qualitativas das avaliações e realizada as suas transformações em valores quantitativas através da defuzzificação. Sem seguida estes valores foram utilizados pela rede neural como sinais de entradas para o registro do aprendizado da rede neural.

101

MERLI, Renato Francisco e WERLE DE ALMEIDA, Lourdes Maria, 2011.

Tema: Nem Tudo é Tão Certo Como Parece Ser: A Matemática Fuzzy Como Linguagem; Apucarana-PR; 2011. Trabalho: Apresentar um ensaio de articulação entre matemática fuzzy e Educação Matemática utilizando como metodologia a revisão bibliográfica. Proposta: Ilustrar ideias e conceitos importantes na matemática fuzzy, apresentaram inicialmente, algumas concepções fundamentais e exemplos ilustrativos. Objetivo: Perspectiva de trazer a discussão sobre a importância da inclusão da linguagem matemática para o âmbito escolar e enunciar algumas possíveis relações com a Educação Matemática. Relação com a proposta desta tese: A aplicação da lógica fuzzy na educação está relacionada com a proposta deste trabalho na aplicação da teoria dos conjuntos fuzzy e determinação do conjunto de pertinência na avaliação do nível de riscos de projeto e definição da linha divisória (média ponderada) na separação e classificação do nível de risco de projeto e impacto de riscos.

MORÉ, Jesús Domech, 2004.

Tema: Aplicação da Lógica Fuzzy na Avaliação da Confiabilidade Humana nos Ensaios não Destrutivos por Ultra – Som, Rio de Janeiro – RJ, 2004. Trabalho: Uma árvore de falhas fuzzy foi construída para o ensaio por ultra-som e utilizada para obter a probabilidade de erro humano durante a execução da inspeção manual ultra-sônica. Proposta: Desenvolve também um modelo fuzzy baseado em 59 fatores que influenciam no desempenho do inspetor criando um padrão de qualidade do ensaio, além disso, uma metodologia fuzzy para avaliação da confiabilidade humana nos ensaios não destrutivos tipo ultra-som. Objetivo: Mostrar que a Teoria dos Conjuntos Fuzzy é uma ferramenta poderosa na avaliação dos atributos de confiabilidade humana e dos eventos durante a execução do procedimento de ultra-som. Relação com a proposta desta tese: A avaliação de confiabilidade está relacionada com a proposta da tese proposta, pois a norma SQuaRE tem como base a avaliação da qualidade de serviços, onde está embasado a proposta deste trabalho.

MOREIRA, Fábio Roque da Silva, 2010.

Tema: Uso de Regras de Associação fuzzy e Técnica de Análise de Exploração Espacial na Mineração dos Dados Sócio-ambientais do Projeto PIATAM, Amazônia Central; Rio de Janeiro - RJ; 2010. Trabalho: Foi desenvolvido na pesquisa um algoritmo em linguagem Python com capacidade de lidar com dados numéricos e categóricos, bem como de relacionar objetos com propriedades geográficas através de ferramentas de análise espacial.

102

Proposta: Propor uma metodologia baseada em regras de associação fuzzy para aquisição de conhecimento, expresso através de regras linguísticas, das informações dos temas ictiofauna e limnologia do Projeto PIATAM. Objetivo: Visualização geográfica dos valores linguísticos do antecedente e consequente à regra, através das suas pertinências e a interpretação mais precisa da força da regra no espaço. Relação com a proposta desta tese: A relação da metodologia baseada em regras de associação fuzzy para aquisição de conhecimento foi aplicada no modelo proposto com a aplicação dos recursos da neurofuzzy, através do processo de amostras de dados.

NOBRE, Gustavo Cattelan, 2006.

Tema: Lógica Fuzzy no Impacto da Usabilidade de WEBSITES na Relação das Empresas de Varejo Eletrônico com seus Clientes: O Caso da Blockbuster; Rio de Janeiro - RJ; 2006. Trabalho: Estudo sobre o uso do comércio eletrônico por empresas de varejo e o crescimento significativamente ao longo dos últimos anos, pois a Internet têm se tornado um atrativo canal de comercialização e relacionamento da empresa com seus clientes. Proposta: Analisar a pesquisa realizada com 1 699clientes únicos da Blockbuster a partir dos quais foram abordados tópicos relacionados à usabilidade de sistemas de acordo com duas abordagens: a primeira, voltada para normas da ISO e ABNT; e outra, específica para Websites. Objetivo: Avaliar a satisfação dos clientes e novos serviços a serem prestados pela empresa com a aplicação da lógica fuzzy. Relação com a proposta desta tese: As técnicas de análise de usabilidade faz parte do trabalho apresentado utilizando a norma SQuaRE na análise de serviços de software.

PARAIZO, Carlos Lopes Brandão, 2007.

Tema: “Uso da Lógica Difusa no Processo de Decisão de Mudanças em TI”; Rio de Janeiro - RJ; 2007. Trabalho: A determinação do risco para implantação da continuidade dos negócios e a sua alocação às respectivas janelas de tempo disponíveis para sua realização dos elementos críticos de gerenciamento. Proposta: O uso da lógica difusa em modelo para classificação quantitativa do risco da implantação de cada mudança no ambiente de TI, com regras criadas a partir do conhecimento de especialistas. Objetivo: Propor um modelo para estabelecimento de um valor quantitativo para o risco da implantação de cada mudança requerida no ambiente de TI, permitindo que os gestores tenham recursos mais flexíveis para alocar as mudanças às janelas de tempo disponíveis de acordo com as tolerâncias a risco que cada um está disposto a admitir de acordo com as características de cada organização.

103

Relação com a proposta desta tese: Com base no modelo de classificação e auxílio no processo de tomada de decisão, utiliza-se esta técnica para a implementação da neurofuzzy, como a transformação de medidas qualitativas em quantitativas para auxílio na tomada de decisão em fases de projetos de software. Já com os recursos de redes neurais a criação de uma base de aprendizado segundo as classificações geradas pela rede de perceptron MLP (Multilayer perceptron), obtida durante o treinamento da rede de neurônios.

PEQUENO, Doroteu Afonso Coêlho, 2004.

Tema: SIMULA – Um Software Educativo de Simulação de Circuitos Pneumáticos com Aplicações de Lógica Fuzzy; Fortaleza-CE; 2004. Trabalho: A simulação computacional como ferramenta auxiliar ao processo ensino-aprendizagem de pneumática. Proposta: Fazer uso das equações da mecânica dos fluidos. Objetivo: Modelar um circuito pneumático básico e, partindo destas equações, usando lógica fuzzy, na qual as variáveis de entrada e saída assumem valores linguísticos, para melhoria no aspecto quantitativo com a introdução de um maior número de variáveis. Relação com a proposta desta tese: A relação do trabalho da simulação computacional foi aplicada na padronização de trabalho e avaliação das técnicas utilizadas por cada especialista de sua área específica durante a prestação de serviços de desenvolvimento de software.

BOENTE, Alfredo Nazareno Pereira, 2009.

Tema: Um Modelo fuzzy para Avaliação da Satisfação dos Gerentes de Projetos de Produtos de Software de uma Fundação Pública Estadual. Trabalho: Desenvolveu uma metodologia fuzzy para avaliação da confiabilidade humana nos ensaios não destrutivos tipo ultrassom. Além disso, desenvolver também um modelo fuzzy baseado em 59 fatores que influenciam no desempenho do inspetor criando um padrão de qualidade do ensaio. Proposta: Ajudar a trazer informações úteis para medir o índice de confiabilidade humana em diferentes ambientes físicos. Uma árvore de falhas fuzzy foi construída para o ensaio por ultrassom e utilizada para obter a probabilidade de erro humano durante a execução da inspeção manual ultrassônica. Objetivo: A Teoria dos Conjuntos Fuzzy mostrou-se uma ferramenta poderosa na avaliação dos atributos de confiabilidade humana e dos eventos durante a execução do procedimento de ultrassom. Relação com a proposta desta tese: Aplicação dos conceitos em relação ao desempenho de avaliação de qualidade de serviços de software.

REJANE DE OLIVEIRA, Kelly, 2002.

Tema: AdeQuaS: Ferramentas Fuzzy para Avaliação da Qualidade de Software; Fortaleza-CE; 2002.

104

Trabalho: A qualidade de software e a importância crescente como fator crucial de competitividade nas organizações Proposta: Avaliar atividade na obtenção e garantia da qualidade tanto no processo de desenvolvimento de software, quanto no produto final para planejar, executar e alcançar a melhoria. Objetivo: Modelar e implementara ferramenta AdeQuaS através das etapas definidas no Modelo Fuzzy de Avaliação de Qualidade de Software e oferecer suporte automático para aplicação de métricas de qualidade, definição do procedimento de avaliação e obtenção do nível de qualidade do objeto avaliado. Relação com a proposta desta tese: A avaliação das atividades na obtenção da qualidade de desenvolvimento de software foi estendida na aplicação da ferramenta proposta, adicionando-se o modelo espiral de BOEHM, no controle de riscos de projetos.

RHEINGANTZ, Paulo Afonso, 2002.

Tema: Lógica Fuzzy e Variáveis Linguísticas Aplicadas na Avaliação de Desempenho de Edifícios de Escritório; Antac; Rio de Janeiro - RJ; 2002. Trabalho: Descreve a construção de um instrumento de avaliação qualitativa do desempenho dos edifícios de escritórios. Proposta: Propor um modelo de análise hierárquica (MAH), fundamentado no pensamento complexo de Edgard Morin, na abordagem fuzzy e no uso das variáveis linguísticas. Objetivo: Indicar as vantagens da abordagem fuzzy na avaliação de desempenho e propor um novo enfoque para a produção e avaliação de desempenho dos edifícios e escritório. Além disso, definir procedimentos para identificar as variáveis utilizadas para mensuração dos atributos. Relação com a proposta desta tese: A aplicação da lógica fuzzy e variáveis linguísticas foram aplicadas na ferramenta da análise da norma SQuaRE proposto neste trabalho, onde determina-se os níveis de riscos e impactos de projeto.

RIBEIRO DE SÁ, Irene Izard, 2007.

Tema: Identificação das Ações Empresariais a Parti da Percepção do Consumidor: Uso da Teoria Fuzzy; Rio de Janeiro - RJ; 2007. Trabalho: Pesquisar e identificar os fatores que apresentam maior importância para os consumidores da empresa IBellaa partir da utilização da teoria dos conjuntos fuzzy, propiciando um importante instrumento de gestão contribuindo para a qualificação do processo decisório e para um melhor aproveitamento dos recursos organizacionais. Proposta: Aplicar uma abordagem quantitativa, um estudo descritivo e uma pesquisa de opinião, na qual se entrevistou uma amostra de 218 consumidores e um especialista no intuito de identificar os principais fatores que influenciam o consumidor na compra dos produtos da IBella.

105

Objetivo: Propor um modelo que permite avaliar o desempenho da empresa na gestão a partir de um índice criado, o IDG – Índice de Desempenho na Gestão, identificar os fatores relevantes para empresa considerando as expectativas do consumidor e indicar os fatores de maior influência através da matriz de influência, possibilitando a aplicação de recursos da empresa de forma otimizada. Relação com a proposta desta tese: A relação da qualificação no processo decisório está relacionada com o modelo proposto nesta tese, quando se aplica as técnicas da lógica fuzzy como recurso de medida quantitativa à partir de informações qualitativas preenchidas pelo formulário (check-list).

RODRIGUES de OLIVEIRA, Carlos Ueslei, 2009.

Tema: Sistema de Suporte a Decisão Baseado em Lógica Fuzzy para outorga de Recursos Hídricos; Cuiabá-MT; 2009. Trabalho: Redimensionar as vazões outorgadas dos usuários existentes, possibilitando assim a inclusão de novos usuários, condicionada a uma minimização dos impactos nos recursos hídricos em quantidade e qualidade e permitindo a geração de cenários que limitam a diminuição de diretos já concedidos aos usuários existentes. Proposta: Desenvolver um módulo de tomada de decisão que utiliza conjuntos difusos e o método AHP (AnalyticHierarchyProcess). Objetivo: Apresentar uma metodologia de suporte a decisão para auxiliar os órgãos gestores de recursos hídricos em locais aonde a demanda já é crítica e nos quais a concessão de outorga de novos usuários tende a incrementar conflitos de seu uso. Relação com a proposta desta tese: Com base neste trabalho, aplicou se as técnicas de tomadas de decisão com base na hierarquia de processos. Aplicou se na proposta desta tese a possibilidade de inserção de comportamentos com base nas características propostas pela norma SQuaRE no modelo proposta e na aplicação do software desenvolvido para a simulação de avaliação de qualidade de serviços de software. É possível com a ferramenta proposta nesta tese, criar uma hierarquia com base no comportamento e resultados esperados através do relacionamento da norma SQuaRE com o modelo espiral de BOEHM.

RONDINA, João Marcelo, 2005.

Tema: Sistema de Controle fuzzy Adaptado ao Fenômeno de Rajadas para Construção de um Modelo de Carga de Trabalho de Serviço WEB; Ilha Solteira - São Paulo; 2005. Trabalho: Planejamento de capacidade de serviços WEB e prover sua qualidade. Proposta: Relatar a abordagem para a construção de modelos de cargas de trabalho adaptados a fenômenos de rajadas e seu impacto na capacidade de serviço. Objetivo: Analisar as cargas de trabalho de dois serviços WEB e os resultados obtidos para comparar as vantagens e desvantagens de cada solução.

106

Relação com a proposta desta tese: Com base nos estudos relacionados ao planejamento de serviços, estabeleceu se o plano para a determinação das principais características definidas pela norma SQuaRE, onde o controle da qualidade de serviços são os seus principais atributos para planejamento e gestão de projetos.

SANTOS, Harvey José; COSENZA, Ribeiro;VILLELA, LAMOUNIERERTHAL; DOMECH, Jesus Moré; CARVALHO, João Batista Brilho de e PALADINI, 2006.

Tema: Aplicação da lógica fuzzy em um Modelo para Hierarquização de Produtos e Serviços – Caso da Polibrasil S.A.; Salvador-BA; 2006. Trabalho: Adaptar o modelo da lógica fuzzy aos conjuntos de fatores condicionantes da demanda, da oferta dos produtos e serviços dos segmentos do mercado de polipropileno no Brasil. Proposta: Apresentar o estudo de caso da Polibrasil S.A que adaptou o modelo COPPETEC/COSENZA, de localização industrial para um modelo multicriterioso de hierarquização de produtos e serviços. Objetivo: Hierarquizações, que apontam oportunidades de negócios para cada segmento do mercado estudado e favorecer o desenvolvimento de um sistema de escolha consistente sobre as melhores alternativas econômicas de transações comerciais. Relação com a proposta desta tese: O trabalho da tese proposta neste trabalho tem como objetivo principal auxiliar na tomada de decisão e qualidade de serviço com base na norma SQuaRE e análise de risco com base no modelo espiral de BOEHM.

SPHAIER, Andrea Alcoforado, 2009.

Tema: Adaptação de um Modelo para Avaliação da Qualidade de Serviços Prestados por uma Empresa de Tecnologia da Informação; Rio de Janeiro - RJ; 2009. Trabalho: Busca medir a qualidade dos serviços prestados utilizando o modelo SERVQUAL como instrumento de medição através da teoria dos conjuntos fuzzy. SERVQUAL é um modelo de medição de qualidade de serviços, proposto por PARASURAMAN, BERRY e ZEITHAML. Proposta: Consiste em aplicar o modelo COPPE/COSENZA para cotejar a demanda proveniente das necessidades dos clientes e a oferta de produtos e serviços disponíveis na empresa. Objetivo: Confirmar a potencialidade do modelo utilizado neste trabalho como ferramenta de gerenciamento de qualidade de serviços. Relação com a proposta desta tese: A partir do método utilizado nas medidas de qualidade de serviço, foi possível estender a aplicação da lógica fuzzy com redes neurais (neurofuzzy) na proposta deste trabalho que é a avaliação de qualidade de serviços com base na norma SQuaRE e modelo cascata proposto por BOEHM (1988), para avaliação de impactos de riscos de projetos de software.

STURN, Wilerson, 2005.

Tema: Avaliação do Potencial de Uso da lógica fuzzy para Identificação de Indicadores de Competência de Currículo Lattes; Curitiba – PR; 2005. Trabalho:

107

Geração de métodos e ferramentas que auxiliem o processo de gestão de projetos como um todo e, em especial, na tarefa de formação de equipes adequadas para execução de projetos. Proposta: Auxiliar nas tarefas de decisão sobre a formação de equipes, fornecendo as bases para o desenvolvimento de programas de computador capazes de gerar indicadores locais que permitam a classificação de indivíduos pertencentes à determinada instituição frente aos requisitos de um projeto. Objetivo: Analisar o potencial de uso da lógica fuzzy para geração de indicadores de competências de indivíduos pertencentes a uma determinada instituição, avaliando como fonte de dados o Currículo Lattes, classificando os potenciais candidatos sob ponto de vista de adequação à composição de equipe para a execução de determinado projeto. Relação com a proposta desta tese: A avaliação da aplicação da lógica fuzzy para auxiliar nas tarefas de decisão foi adicionada à gestão de projetos e equipes de desenvolvedores dentro de um ambiente da Tecnologia da Informação (TI).

VALDONEL DE ALMEIDA, Manoel, 2009.

Tema: Aplicação de Técnicas de Redes Neurais Artificiais na Previsão de Curtíssimo Prazo da Visibilidade e Teto para o Aeroporto de Guarulhos – SP; São Paulo-SP; 2009. Trabalho: Um sistema de previsão de curtíssimo prazo (nowcasting) para previsão de teto de nuvens e visibilidade horizontal no Aeroporto de Guarulhos – SP. Proposta: Desenvolver métodos de previsão de curtíssimo prazo e,posteriormente, métodos que possam efetivamente combinar os prognósticos dados pela previsão de curtíssimo prazo e modelos de previsão numérica de sistemas de mesmo escala. Objetivo: Este trabalho pretende responder as seguintes questões: a) É possível desenvolver um modelo de previsão que possa preencher essa lacuna deixada pelo pela modelagem numérica? b) Esse modelo será capaz de fornecer previsão localizada e em curtíssimo prazo para as faixas de visibilidade que satisfaçam os mínimos operacionais c) De igual forma, para as faixas de teto baixo da mesma tabela? d) E que grau de precisão terá essa previsão? e) Se essa precisão não for satisfatória, há outra opção satisfatória para a problemática da previsão de curtíssimo prazo da visibilidade e teto previsão para o Aeroporto de Guarulhos? f) Havendo essa opção satisfatória, sua implementação operacional será viável? g) E a que custo se dará a operacionalização desse modelo no Aeroporto de Guarulhos? Relação com a proposta desta tese: As técnicas utilizadas na previsão da visibilidade e teto de pouso nos aeroportos, foram implementadas na base de conhecimento e treinamento da rede neural para auxilio na tomada de decisão de projeto de software.

Tabela 40- Resumo da aplicação da lógica fuzzy segundo autores da literatura

108

3.1.4. Aplicação da Lógica Fuzzy em Sistemas de Informação e Processo de Solicitação

de Serviços

Para Ludwing Junior (2007), a contração de serviços para desenvolver sistemas de

software é realizada por documentos descritos de várias formas e todas têm o seu objetivo

específico. A contratação de serviços e as solicitações têm como objetivo principal a seleção

do fornecedor que será responsável pelo desenvolvimento, pois definem os aspectos que

precisam ser atendidos durante a prestação de serviços tais como: regras de negócio, a

integração do sistema, as datas para as entregas, a forma de como o sistema será desenvolvido

e as tecnologias que serão utilizadas. Dentre as solicitações de serviços os principais fatores

que podem influenciar de forma negativa o processo de avaliação estão descritos na tabela 41.

Principiais fatores (negativos) Descrição

1-Níveis de detalhes A variação do nível de detalhe com que os documentos são apresentados.

2-Falta de profissionais A não disponibilidade de profissionais para atendimento às dúvidas da consultoria.

3-Pouca Informação A dificuldade de prever um esforço de trabalho baseado em uma limitada quantidade de informações.

4-Pouco tempo O pouco tempo para emissão da proposta comercial desde a sua solicitação.

5-Ferramentas de medição A limitação das ferramentas que se destinam a medir o tamanho dos sistemas.

6-Falta de conhecimento A falta de conhecimento das características de infraestrutura tecnológica da empresa que está solicitando os serviços.

7-Características intangíveis A própria característica intangível dos tipos de serviços.

8-Ambiente mutável Os responsáveis pela tomada de decisões lidam com ambiente mutável.

9-Prazo de desenvolvimento Difícil decisão a ser tomada quanto ao prazo para desenvolvimento de um sistema a ser considerada em relação às propostas comerciais.

Tabela 41- Processos de avaliação que podem influenciar de forma negativa, adaptada de Ludwing Junior (2007).

A tabela 42 descreve os principais fatores de riscos que contribuem para atraso de

projeto, segundo pesquisas realizadas de diversos autores que desenvolvem serviços de

desenvolvimento de serviços.

Fatores de avaliação Descrição

1-Aquisição tecnológicas. Necessidades de novos equipamentos, novos programas, etc.

2-Tamanho da aplicação. Grande número de pessoas na equipe, áreas diferentes envolvidas, tamanho de projeto, número de usuários, níveis hierárquicos, etc.

3-Falta de experiência geral da equipe. Habilidade para trabalhar com objetivos incertos, com gerência, com a equipe, entender as implicações humanas do novo sistema, cumprir tarefas efetivamente, etc.

109

4-Falta de experiência da equipe com a tarefa.

Conhecimento da funcionalidade do departamento do usuário, das operações organizacionais, experiência e qualificação administrativa, das operações organizacionais, familiaridade com os tipos de aplicação, etc.

5-Falta de suporte ao usuário.

Usuários têm uma opinião negativa sobre a relação dos sistemas com suas necessidades, não estão entusiasmados com o projeto, não estão disponíveis para responder às questões, não estão preparados para aceitar as mudanças que ocorrerão, respondem vagarosamente aos questionamentos da equipe de desenvolvimento, têm atitudes negativas que repudiam o uso de computadores no trabalho, etc.

6-Intensidade de conflito. Boa intensidade de conflitos entre os membros da equipe, conflito entre os usuários e os membros da equipe, etc.

7-Extensão da aquisição de mudanças. O sistema requer um grande número de usuários-tarefa a ser modificado, o sistema direcionará para mudanças maiores na empresa, etc.

8-Insuficiência de recursos. O número de pessoas para desenvolver e implantar o sistema no prazo agendado é insuficiente, o orçamento previsto é insuficiente, etc.

9-Falta de clareza na definição das regras.

As regras de cada membro da equipe não estão claramente definidas, as regras de cada pessoa envolvida no projeto não estão claramente definidas, as comunicações entre vários envolvidos no projeto são desagradáveis, etc.

10-Complexidade da aplicação. Complexidade técnica, hardware, software, banco de dados, grande numero de links com sistemas existentes e com sistemas futuros, etc.

11-Falta de experiência do usuário.

Excessivas especificações de requerimentos, usuários não estão muito familiarizados com as tarefas de desenvolvimento de sistemas, usuários têm pouca experiência em atividades que serão suportadas por sistemas futuros, não estão familiarizados com os tipos de aplicações, não estão cientes da importância das regras no sucesso completo do projeto, não estão familiarizados com o processamento de dados como uma ferramenta de trabalho, etc.

Fatores que não podem ser identificados (durante a cotação)

Descrição

1-Identificação do usuário. Como identificar se os usuários participaram na definição dos requerimentos contidos na solicitação?

2-Identificação do sistema. Como identificar se o sistema vai requere um grande número de tarefas a serem modificadas?

3-Conflitos entre usuários e membros da equipe.

Com especular se existirá ou não intensidade de conflitos entre usuários e os membros da equipe, sem muitas vezes conhecer os usuários e nem mesmo os próprios membros da equipe que vão compor o projeto?

4-Mudanças e contribuições do usuário.

Como imaginar se os usuários estarão ou não preparados para aceitar as mudanças que ocorrerão no seu dia-a-dia de trabalho? Se eles conhecem ou não as tarefas que acontecem durante o fluxo de desenvolvimento? Se os usuários estão ou não dispostos a atender prontamente às dúvidas da equipe técnica durante o desenvolvimento?

5-Participação do usuário na definição dos requisitos.

Como imaginar se a consultoria tem o conhecimento de que durante o processo de cotação um dos usuários não participou ativamente da definição dos requerimentos?

Tabela 42- Fatores negativos gerados durante o processo de avaliação de solicitações de serviços, adaptado de: Barki (1993) e Jiang (2002).

110

3.2. Redes Neurais Artificiais (RNAs)

A capacidade dos computadores baseados na arquitetura de Von Neumann, a qual é

composta por unidades centrais de processamento que executam sequências de instruções não

são capazes de perceber e raciocinar da forma como os multiprocessadores da mente humana,

(BROOKSHEAR, 2005). Desta forma, muitos pesquisadores concentram suas pesquisas

aplicando teorias de RNAs (Redes Neurais Artificiais). A construção das RNAs é construída

utilizando muitos processadores individuais conhecidas como unidades de processamento.

Seu funcionamento básico é semelhante à rede de sistemas biológicos, composto por:

uma célula, dendrites que são responsáveis pelas entradas das informações e axônio que são

as saídas das informações geradas. Para Palma Neto e Nicoletti (2005), Redes Neurais é um

método geral e prático para o aprendizado de aproximações de funções de exemplos. Pode ser

caracterizada como: a) processadores básicos chamados de neurônios; b) pela função de

ativação (representa o estado do neurônio); c) pelo padrão de conexão existente entre os

neurônios; d) por seu algoritmo de treinamento (ou algoritmo de aprendizado). Segundo

Nunes da Silva, Spatti e Flauzino (2010), a estratégia de treinamento supervisionado consiste

em se ter disponível, considerando cada amostra dos sinais de entrada, as respectivas saídas

desejadas, em que cada amostra de treinamento é composta pelos sinais de entradas e suas

correspondentes saídas. Os pesos sinápticos e limiares são, então, continuamente ajustados

mediante aplicação de ações comparativas, executadas pelo próprio algoritmo de

aprendizagem, que supervisionam a defasagem entre as respostas produzidas pela rede em

relação àquelas desejadas, sendo essa diferença usada no procedimento de ajuste.

3.2.1. Neurofisiologia

Os fundamentos descritos a seguir estão baseados em De Maio, (2007). As interações

do cérebro humano são realizadas através dos receptores sensoriais (órgãos dos sentidos). Os

receptores estão adaptados às interconexões que estão relacionados com o seu ambiente (ou

meio) e estão divididos em grupos: a) fotoceptores (que são os olhos), b) mecanoceptores

(audição, tato e vestibulares), c) quimioceptores (olfato e gustação). Para cada receptor

sensório há, no cérebro, uma região que recebe os estímulos gerados por esses receptores

(memórias sensórias de curta duração), que são memórias temporárias ou de transferência e

podem durar de alguns milissegundos até minutos. Somente aqueles registros, estímulos, que

111

despertam a atenção ou interesse ou por repetição, são transferidos para memórias sensórias

de longa duração (memórias permanentes ou de memória de segunda ordem) onde são criadas

as sinapses (aquisição do conhecimento).

3.2.1.1. Memória de Primeira Ordem

Memórias de primeira ordem, sensórias ou memórias perceptuais é toda a rede de

registros obtidos por meio de órgãos sensoriais, onde formam o Banco de Dados inicial do

indivíduo, pois através dele são formadas as demais memórias, a linguagem para a

comunicação e as demais memórias, e também a linguagem para comunicação e as demais

operações executadas pelo cérebro. Todos os registros sensoriais de primeira ordem possuem

uma propriedade em comum. Na Matemática, os registros de primeira ordem são os

elementos (DE MAIO, 2007).

3.2.1.2. Memória de Segunda Ordem

Segundo DE Maio (2007), memória de segunda ordem, conjuntos, classes ou

categorias, são grupos de elementos com propriedades comuns e gera, cria um novo registro

formado a partir dos registros sensórios, memória de primeira ordem. Esses registros

correspondem às classes de equivalência das relações binárias da Matemática e correspondem

aos substantivos coletivos ou abstratos. O conjunto é uma memória de segunda ordem. Na

Matemática, o registro sensório de segunda ordem são os conjuntos.

3.2.2. Neurônio Matemático

Segundo Ludwing e Montgomery (2007), um neurônio matemático recebe um ou mais

sinais de entrada e devolve um único sinal de saída, e pode ser distribuído como sinal de saída

da rede, ou como sinal de entrada para um ou vários outros neurônios da camada posterior. Os

sinais de entrada chegam de forma simultânea aos neurônios. Os dendritos e axônios são

representados, matematicamente, pelas sinapses e a intensidade da ligação é representada pelo

peso sináptico. O neurônio totaliza as multiplicações das entradas com os seus respectivos

pesos sinápticos gerando as entradas ponderadas (v1.w1, v2.w2,..., xn .wn) e a totalização de

todos os produtos é o resultado do somatório (v), conforme mostra a figura 22.

112

∑=

=n

iii xwv

0

Figura 22- Função de ativação, LUDWING e MONTGOMERY (2007).

A função de ativação é comparada com função de transferência, que tem a finalidade

de evitar o acréscimo progressivo dos valores de saída ao longo da camada da rede,

(LUDWING e MONTGOMERY, 2007). As principais funções de transferência utilizadas são

do tipo sigmóide, gaussiana e tangente hiperbólica, conforme mostra a figura 23

Figura 23- Funções de transferências, LUDWING e MONTGOMERY (2007).

Muitas vezes é incluída, no modelo neuronal, uma polarização (bias) de entrada, que é

incluída ao somatório com a finalidade de ativação da função, com a finalidade de aumentar o

grau de liberdade da função com a capacidade de aproximação da rede e o seu ajuste é da

forma como são ajustados os pesos sinápticos. A polarização (bias) permite que um neurônio

apresente uma saída não nula, mesmo quando as suas entradas sejam nulas. As entradas são

representadas por {x1, x2,... x(n)}, os pesos por {w1, w2,... w(n)}, a somatória pelo símbolo

(Σ), que representa a soma ponderada das entradas, a função de ativação representada por f(.)

e a saída pela letra y. A relação entre as entradas e os pesos é a multiplicação entre cada

entrada por cada peso da matriz. Segundo Braga, Carvalho e Ludermir (2007), no modelo

MCP, Mc Culloch e Pitts [MP43], a ativação do neurônio é obtida através da aplicação de

uma função de ativação, que ativa ou não a saída, dependendo do valor da soma ponderada

das suas entradas. A função de ativação é responsável por gerar a saída y do neurônio a partir

dos valores de peso w=(w1, w2,..., wn) e de entrada x=(x1,, x2,..., xn).

113

A figura 24 mostra uma representação de um neurônio numa visão de matriz, em que é

possível mapear as entradas e gerar as correspondentes saídas, aplicando-se os recursos

matemáticos. Na diagonal principal da matriz quadrada (estrutura do neurônio), são

calculados os pesos sinápticos (entradas x pesos) juntamente com os ajustes de bias

(multiplicando-se os valores de entradas com os seus respectivos pesos). Em seguida, é

calculada a somatória e segundo a função de ativação selecionada é gerada a saída, segundo

os valores desejados pelo especialista, que pode ser valor 1 (um) ou 0 (zero).Proposta de

mapeamento de um neurônio simples.

Figura 24- Rede neural artificial x Mapeamento de Ajustes Sinápticos, fonte: autor.

Uma rede neural MLP (Multilayer Perceptron), usa um conjunto de dados

correspondente a uma amostra de sinais para entrada e saída do sistema, conforme mostra a

figura 22. Para esse treinamento, a rede utiliza algoritmo de aprendizado, (SHAW e SIMÕES,

2004). A camada de entrada da figura é composta pelos valores x={x1, x2,..., xn}, pelo

conjunto de neurônios n={n1, n2,..., nn} e pela camada de saída y={y1, y2,..., yn}. De acordo

com Ludwig Jr. e Montgomery (2007), o perceptron de multicamadas (MLP) é uma rede de

neurônio com uma camada sensorial ou camada de entrada, que possui tantos nós de entrada

quantos forem os sinais de entrada, uma ou mais camadas ocultas de neurônios e uma camada

de saída com um número de neurônios igual ao número de sinais de saída. O MLP (Multilayer

Perceptron) é uma generalização da rede de perceptron, entretanto é treinada de forma

supervisionada, através da regra de aprendizagem que minimiza o erro. Conforme Coppin

(2004), a maioria dos problemas do mundo real não é linearmente separável, dessa forma,

uma rede neuronal com um único perceptron, não é capaz de modelar funções mais

complexas. Já uma rede multicamada é capaz de modelar uma função que não seja

linearmente separável. Para Campos e Saito (2004), a rede de neurônios multicamadas é um

sistema artificial [ROSENBLATT, 1962] composto de células elementares, chamadas de

neurônios, organizadas em camadas sucessivas que são conectadas entre elas. Desta forma, as

redes neurais implementam uma interconexão massiva de células computacionais chamadas

114

de neurônios artificiais ou unidade de processamento. Portanto o conhecimento é adquirido

pela rede através de um processo de aprendizagem e as forças de conexões entre os neurônios

(pesos sinápticos) é utilizada para armazenar o conhecimento. A topologia de uma rede neural

pode ser definida como sendo as diferentes formas de composições estruturais que esta pode

assumir. O treinamento de uma arquitetura específica consiste na aplicação de um conjunto de

passos ordenados com o intuito de ajustar os pesos e os limiares de seus neurônios,

conhecidos como algoritmo de aprendizado, visando sintonizar a rede para que as respostas

estejam próximas dos valores desejados, (NUNES da Silva, SPATTI e FLAUZINO, 2010). A

figura 25 representa um modelo de neurônio utilizando uma representação de fluxo de

informações com a sua camada de entrada, camada de mapeamento sináptico e a camada de

saída. Os valores de entradas são mapeados aplicando-se os recursos da diagonal principal da

matriz e transfere para a camada de saída os valores correspondentes. Proposta de um modelo

de mapeamento de um neurônio simples.

Figura 25- Modelo de rede neural artificial, fonte: autor.

Neurônios podem ser combinados em camadas, tais neurônios podem estar

interligados através de suas sinapses, formando assim uma rede neural artificial (RNA).

115

Descrevem-se abaixo as principais características de rede neural artificial, adaptado de

(LUDWING e MONTGOMERY, 2007).

− Uma RNA deve possuir uma camada de entrada ou distribuição, no entanto não

possui nenhum neurônio, apenas um número de nós (node) com o mesmo número

de sinais de entrada da rede. Não é realizada nenhuma computação nessa camada.

− Deve conter uma camada, nenhuma ou várias camadas ocultas e são constituídas

de um ou mais neurônios ocultos. Essas camadas permitem a rede extrair

estatísticas e representar os problemas que não sejam linearmente separáveis.

− Deve conter uma camada que possui um número de neurônios igual a número de

sinais de saída da rede.

− Deve permitir o ajuste dos valores de seus pesos sinápticos, pois dessa forma a

rede é capaz de memorizar as relações entre os dados de entrada com a saída,

representados assim uma memória associativa.

A figura 26 mostra um modelo de rede de neurônios ligados em cadeias de RNAs com

as suas respectivas entradas e saídas com as suas camadas ocultas, conhecida como MLP

(Multilayer Perceptron). Descrevem-se as camadas de entradas, as camadas ocultas e também

a camada de saída (LUDWING e MONTGOMERY, 2007).

Figura 26- Rede de neurônios em camadas, Ludwing e Montgomery (2007).

3.2.3. Arquitetura da Rede Neural

Independentemente da função de ativação escolhida, neurônios individuais possuem

capacidade computacional limitada. No entanto, um conjunto de neurônios artificiais

116

conectados na forma de uma rede é capaz de resolver problemas de complexidade elevada,

(CARVALHO e LUDERMIR, 2007).

3.2.4. Perceptron Simples

Para Ludwing e Montgomery (2007), o perceptron é um tipo de rede neural com

arquitetura simples, pois possui apenas um conjunto de neurônios de entrada e um conjunto

de neurônio de saída (não possui camadas de neurônios intermediárias). A sua estrutura

permitem somente tomadas de decisões simples. Os neurônios da rede neural perceptron

possuem uma função de ativação (faz a soma ponderada dos sinais de entrada) e outra de

transferência (determina a saída do neurônio, em função da soma ponderada). Todos os

neurônios da camada de saída são formados por um número de neurônios igual ao número de

sinais de saída. A figura 27 mostra o conjunto de entrada, o conjunto de pesos, a somatória, a

função de ativação e os ajustes finos (bias), além do conjunto de saída do neurônio.

Figura 27- Rede neural perceptron Ludwing e Montgomery (2007).

Os pesos sinápticos são os valores wij que fazem as ligações entre os neurônios, as

entradas são os elementos xi, enquanto as saídas são os elementos yj. O elemento v representa

a função de ativação, φ é a função de transferência.

A figura 28 representa a estrutura de uma rede perceptron MCP (Multilayer

perceptron), modelado utilizando os recursos da matriz. Aplica-se o mapeamento para uma

rede perceptron utilizando os recursos de matriz, que além de calcular as entradas

multiplicando-se os seus respectivos pesos (x1*w1+,..., +x3*w3) faz também o mapeamento

das camadas de redes de neurônios (RNA1, ... , RNA3), gerando as suas respectivas saídas

desejadas (y1, ..., y3). Proposta de mapeamento de uma rede multicamada.

117

Figura 28- Estrutura de uma rede perceptron, fonte: autor.

A figura 29 representa a função de ativação, e a figura 30 representa a função de

transferência (função degrau, onde φ pode assumir dois valores).

Figura 29-Função de ativação, Ludwing e Montgomery (2007).

Figura 30- Função de transferência, Ludwing e Montgomery (2007).

3.2.5. Algoritmo de Aprendizado do Perceptron

A rede neural possui tipicamente duas fases de processamento: a de aprendizado e de

utilização. Esses dois momentos de operação são distintos e aplicados em períodos diferentes.

O aprendizado é um processo de ajuste dos pesos das conexões em resposta ao

estímulo apresentado à rede (são as propriedades de modificação em função da necessidade de

aprender a informação apresentada). O processo de utilização é a maneira pela qual a rede

responde a um estímulo de entrada sem que ocorram modificações na sua estrutura. Os

modelos de redes neurais artificiais manipulam informações pela interação de um grande

número de unidades básicas de processamento, (AGUIAR e OLIVEIRA JUNIOR, 2007). A

arquitetura de uma rede neural artificial define a forma como os diversos neurônios são

arranjados, uns em relação aos outros. Esses arranjos são essencialmente estruturados, através

do direcionamento das conexões sinápticas dos neurônios, (NUNES da SIVA, SPATTI e

FLAUZINO, 2010).

Em uma rede neural, os pesos sinápticos são ajustados para que um dado conjunto de

sinais de entrada possa ser processado pelos seus neurônios e apresentar um conjunto de

sinais de saída desde que seu nível de erro seja aceitável. O ajuste é feito através de um

algoritmo de aprendizado do tipo regra delta para a rede perceptron, conforme mostra a

118

equação 1. A metodologia aplicada para esse tipo de rede neural é realizada como a descrição

abaixo:

a) Atribuir aos pesos valores aleatórios.

b) Inserir um conjunto de sinais de entrada.

c) Calcular os valores conforme o treinamento supervisionado.

d) Compara os valores calculados com os valores desejados.

e) Se o erro obtido não for aceitável, ajustar os pesos conforme a proporção do erro e

ao valor do sinal de entrada correspondente (quanto maior o erro, mais correção

deverá ser feito para os pesos).

Equação 1- Expressão do processo de aprendizado, Ludwing e Montgomery (2007).

O erro E(j)é a diferença entre o sinal de saída (desejado) para o neurônio j,

representado por d(j). Enquanto y(j) representa o sinal de saída calculado pela rede para

aquele neurônio, conforme mostra a equação 2. Para o erro médio de todos os neurônios da

camada de saída na interação T é: , onde n é igual ao número de neurônio da

camada de saída. O erro médio para todo o conjunto de treinamento será: .

O valor do erro médio pode ser usado como referência para encerramento do

treinamento e avaliação para ajuste de precisão da rede.

119

; ;

Equação 2- Erro de saída do perceptron, Ludwing e Montgomery (2007).

Segundo Aguiar e Oliveira Junior (2007), os tipos de treinamento podem ser

supervisionado ou não supervisionados. O treinamento é supervisionado quando o ajuste de

parâmetros é feito com base na apresentação de um conjunto de pares de entradas e saídas

padrão. Nesse processo, uma entrada padrão é apresentada à rede e uma saída é calculada. Já

no aprendizado não supervisionado o conjunto de padrões de treinamento possui somente

entradas. Nesse processo, não existe saída padrão, não é mostrado à rede um padrão

conhecido. Segundo Nunes da Silva, Spatti e Fauzino (2010), o processo de treinamento de

uma rede neural consiste da aplicação de passos ordenados que sejam necessários para

sincronização dos pesos sinápticos e limiares de seus neurônios, tendo como objetivo final a

generalização de soluções a serem produzidas pelas suas saídas, cujas respostas são

representativas do sistema físico em que estão mapeando e denominado de algoritmo de

aprendizagem.

3.2.6. Sistema Neurofuzzy

As definições dos fundamentos descritos a seguir, são adaptadas segundo Campos e

Saito, (2004). O sistema neurofuzzy é um sistema fuzzy que utiliza um algoritmo de

aprendizado com base na teoria de redes neurais, em que determina os parâmetros através de

processamento de amostra de dados. Os parâmetros são as regras e subconjunto fuzzy. As

regras fuzzy permitem que o comportamento de um sistema seja descrito utilizando as relações

“se... então”, utilizando-se todo o conhecimento de um especialista no processo de otimização

e desempenho de forma direta e rápida. No entanto, em aplicações práticas, o comportamento

do sistema está restrito a um conjunto de dados experimentais.

Uma rede neural pela sua capacidade de aprendizagem a partir de dados de

treinamento permite oferecer um conjunto de dados experimentais contendo informações

necessárias de um sistema. Pode, ser implementada na forma de um neurofuzzy. As principais

características de uma abordagem do tipo neurofuzzy são descritas a seguir, adaptadas de

Campos e Saito, (2009):

120

a) Uma estrutura neurofuzzy é baseada em um sistema fuzzy que é treinada por um

algoritmo de aprendizado numa uma rede neural, utilizando apenas das

informações locais.

b) Um sistema neurofuzzy é uma rede de várias camadas.

c) Um sistema neurofuzzy pode ser interpretado como um conjunto de regras fuzzy

durante todas as etapas de sua aprendizagem.

d) Um sistema neurofuzzy aproxima uma função n-dimensional que é, parcialmente,

definida por seus dados de treinamento. As regras fuzzy, que são codificadas

dentro do sistema representam os dados de treinamento.

Em um controlador do tipo neurofuzzy, combinam a capacidade de aprendizagem de

uma rede neural com a capacidade de raciocínio de um sistema fuzzy.

3.2.6.1. Controlador Neurofuzzy na forma Takagi e Sugeno

Será descrito a seguir fundamentos de um controlador neurofuzzy multicamada com

base no sistema fuzzy na forma de Takagi –Sugeno. Para um controlador com variáveis de

entradas X={x1,x2,..., xm} e saidas Y={y1,y2, ..., yp}. A base de conhecimento Fuzzy do

controlador é um conjunto de regras (na forma de Takagi e Sugeno) descrito a seguir:

Regra “j”:

Se {x1 é A1j} e {x 2 é A1j} e {x m é Amj} então

{y1 é jf1 } e... e {yp é jpf }

Onde:

( jlf = m

jml

jl

jl xwxww ..... 110 +++ )

jml

jl

jl www ,, 10 , são os coeficientes polinomiais (peso) que conectam linearmente as

variáveis de entrada à função consequentejlf .

mjijlj AAA ,...,,... , são os termos ou valores linguísticos dos subconjuntos fuzzy do

espaço de entradas associados à j-ésima regra R(j).

121

Cada termo ijA é associado a uma função de pertinência, que pode ser do tipo

gaussiano

−−=

)(2

)(exp

2

2

ij

ijiAij

mx

σµ

Onde ijm e ijσ são o centro e o desvio padrão da função de pertinência gaussiana,

respectivamente. A ativação de cada regra (j) é obtida pelo operador produto do tipo:

)(),...,( 11 xxx Aijmj µµ = x ... x )( mAmj xµ Dessa forma, em sistemas fuzzy de Takagi e

Sugeno, cada regra define uma região do espaço de entrada, e a saída desejada é uma

combinação linear das variáveis de entrada.

Dado um vetor de entrada X, o k-ésimo componente de saída )( ky do sistema fuzzy pode ser

inferido como:

∑

∑

=

==n

jj

n

j

kjj

k

f

y

1

1

.

µ

µ A saída yk é obtida pelo método da média ponderada (decodificação).

3.2.7. Regressão linear simples e Correlação

Com frequência, existem vários problemas (na prática), que envolvem conjunto de

variáveis de uma relação entre as suas variáveis. Em uma relação há as variáveis dependentes

e as variáveis independentes (ou regressores). Uma forma de relação entre a resposta (Y) e o

regressor x é a relação linear Y=α + βx, onde α é o intercepto e β é a inclinação. Se a relação

for exata então é uma relação determinística, caso contrário ela é não determinística (o que

ocorre com frequência no mundo real), isso ocorre quando um dado x nem sempre fornece o

mesmo valor para Y. A maioria dos problemas é probabilística. O conceito de análise de

regressão procura encontrar a melhor relação entre Y e x, quantificando a força de suas

relações, utilizando métodos que permitam prever os valores das respostas para os valores

fornecidos pelo regressor (variáveis independentes) x. No entanto, na prática, existem mais de

um regressor. Em uma regressão linear simples se lida com uma única variável regressor

(WALPOLE; MYERS; MYERS e YE, 2009).

122

Segundo Kosciansky (2006), análise de regressão é outra utilização possível para

valores medidos em um software conhecido como predição, pois a partir dos dados coletados,

espera-se estimar aquilo que não se conhece. Tecnicamente, a predição pode ser realizada por

meio da análise de regressão.

123

4. METODOLOGIA DO TRABALHO

Esta tese busca identificar as causas da incerteza nas tomadas de decisões

empresariais, diante de uma situação de análise e aceitação de propostas de requisitos para

solicitação de serviços de software segundo a sua demanda.

A pesquisa procura compreender os processos e gestão da qualidade no atendimento a

serviços em ambientes de TI, a aplicação de técnicas da neurofuzzy, o modelo de risco para

análise do impacto de risco de projeto de software, o processo de tomada de decisão e a

aplicação da medida de qualidade de serviços. Para o controle da qualidade de serviços

utiliza-se a norma SQuaRE, enquanto na determinação das fases e controle de riscos de

projetos aplica-se o modelo espiral da engenharia proposto por Boehm (1988). Para o

processo de aprendizado e classificação dos riscos de projeto aplicam-se as técnicas da rede

neural artificial MLP (Multilayer Perceptron). Define-se, dessa forma, um sistema neurofuzzy

(conhecido como “NeurofuzzySQuaREBoehm”) para auxiliar na tomada de decisão e

acompanhamento da qualidade do desenvolvimento de software em ambientes de TI.

Na metodologia do trabalho, desenvolvem-se as seguintes etapas: a) definição da

estratégia de negócios, b) definição dos formulários para a coleta de informações durante a

classificação do tipo da organização, c) estudo e a compreensão da qualidade de serviços e

processos de serviços, d) tratamento dos problemas da incerteza na tomada de decisão durante

as fases de desenvolvimento de software. Definem-se também: a) as técnicas da lógica fuzzy,

b) o modelo de rede (de neurônios artificiais), c) as regras de inferências para tomada de

decisão (fuzzy e rede neural artificial), d) a forma de armazenamento do aprendizado, e) as

normas de qualidade de serviços, f) os modelos da engenharia de software para gestão, g)

controle de riscos de projetos.

A figura 31 mostra a arquitetura da metodologia adotada na estrutura desta tese. A

metodologia está dividida em seis fases. Na primeira fase, encontram-se as seguintes etapas:

a) revisão da literatura sobre os assuntos de qualidade e medidas de software, b) levantamento

de requisitos para serviços (desenvolvimento de software), c) normas de qualidade de

serviços, d) aplicação de técnicas da lógica fuzzy para auxiliar na tomada de decisão nas

incertezas, e) envolvimento de especialistas na área de TI nas fases iniciais de um

desenvolvimento de software, f) estabelecer uma medida padrão de referência para análise de

nível de risco de projeto de software. A segunda fase foi definida: a) estudos sobre a norma

124

SQuaRE, b) as regras da lógica fuzzy, c) os conceitos principais sobre a utilização de médias

ponderadas como padrão e unidade de referência de medida, d) foram feitas a elaboração do

formulário check-list para serem preenchidos pelos especialistas com a aplicação dos atributos

da norma SQuaRE, e) a realização da coleta de dados, f) a descrição dos atributos da norma

SQuaRE para serem utilizadas na fase 3 (desenvolvimento do sistema “FuzzySQuaRE”) e

também na fase 5 (no desenvolvimento da estrutura do RNA - Rede Neural Artificial). Na

terceira fase inicia-se o desenvolvimento do aplicativo (chamado de “FuzzySQuaRE”) que são

preenchidos com os dados coletados (que tem como base de funcionamento as informações

geradas da fase 2: a) a norma SQuaRE, b) as regras fuzzy, c) os valores da média ponderada.

Na fase 4, são inseridos os resultados gerados pela fase 3: a) cálculo da média

ponderada gerado pelo aplicativo “FuzzySQuaRE” da planilha Excel, b) do Matlab, c) do

RNA simples. E todos esses resultados são apresentados na interface do usuário pelo

aplicativo “FuzzySQuaRE”, dessa forma esses dados são também transferido para a fase 5

para o desenvolvimento do aplicativo “NeurofuzzySQuaREBoehm”. Na fase 5 desenvolve-se

a estrutura o neurônio RNA, o mecanismo de mapeamento da norma SQuaRE com o modelo

de Boehm para a análise de risco de projeto. Esse mapeamento permite fazer a relação e a

cardinalidade entre a norma SQuaRE com o modelo de BOEHM. Para o desenvolvimento da

estrutura do RNA foi necessária a inserção das informações sobre: a) as fases do projeto

espiral de Boehm, b) as regras do RNA simples, c) as informações dos especialistas da área de

TI, d) o treinamento da rede que são estabelecidos e unidos com a fase 6. Para o

desenvolvimento do mapeamento foram necessárias também as inserções das informações

estabelecidos na fase 6, isto é, as experiências definidas pelos especialistas de TI. No

desenvolvimento do aplicativo “PerceptronSQuaREBoehm”, foram inseridos os dados

recebidos do treinamento da rede RNA e das informações sobre o mapeamento do tipo

relação entre “SQuaRE x Boehm”. O resultado gerado pelo aplicativo

“PerceptronSQuaREBoehm” na fase 5 é transferido para a apresentação aos especialistas que

são: a) resultados gerado pelo aplicativo “SQuaREBoehm”, b) apresentação do nível de

impacto de risco de projeto do modelo espiral de BOEHM, que faz parte da fase 6 da proposta

desta tese.

125

Figura 31- Estrutura da metodologia desta tese (uma visão geral), fonte: autor.

A figura 32 mostra de forma ampliada a estrutura da metodologia que são compostas

pela primeira, segunda e a terceira fase da metodologia. Nessas fases, as principais atividades

envolvem: a) a revisão da literatura, b) a participação dos especialistas de TI, c) a definição

das normas de serviços, d) as regras de tomadas de decisão, e) o cálculo da média ponderada

(como limite de impacto de risco), f) a criação do formulário da avaliação de risco de projeto

(check-list), g) a forma como foram realizadas a coleta de dados.

126

Figura 32- Estrutura da metodologia desta tese (parte 01 da estrutura desta tese), fonte: autor.

A figura 33 mostra, de forma ampliada, a estrutura da metodologia que são compostas

pela quarta, quinta e a sexta fase da proposta desta tese. Nessas fases, as principais atividades

envolvem a forma como as informações foram geradas (pelo aplicativo “FuzzySQuaRE”, pela

planilha Excel, pelo Matlab e pela Rede Neural Artificial simples) e também de como elas

devem ser utilizadas. Além disso, estabelece-se a forma como deve ser a estrutura do

perceptron multicamada, o mapeamento (da norma SQuaRE com o modelo espiral) ) e como

o sistema “PerceptronSQuaREBoehm” deve seguir para que sejam realizadas o treinamento

da rede perceptron. Em seguida, define-se a forma da apresentação das informações dos

resultados obtidos das normas SQuaRE, da participação dos especialistas de TI, do

treinamento da rede perceptron e da análise de impactos de riscos de projeto.

127

Figura 33- Estrutura da metodologia desta tese (parte 02 da estrutura desta tese), fonte: autor.

4.1. Problemas de Pesquisa

O problema da pesquisa desta tese é o grau de incerteza na avaliação de solicitações de

desenvolvimento de software devido aos fatores subjetivos que devem ser valorados em uma

proposta comercial.

Para apoio ao processo de decisão é proposta uma metodologia adequada para a

aplicação da lógica e da incerteza em sistemas de software e a transformação desses valores

qualitativos em valores quantitativos, tendo como base as técnicas da lógica fuzzy.

Segundo Chambers (2009), em uma administração de produção de produtos ou

serviços, envolvem-se muitas tomadas de decisões, dessa forma é importante que os gerentes

de produção tenham conjuntos de princípios e regras que o auxilie nas decisões que possam

atingir a estratégia da produção. A priorização dos objetivos de desempenho de uma produção

deve estar vinculada às necessidades dos consumidores e ao comportamento dos concorrentes,

que pode ser definido como estratégia da produção, pois a qualidade é uma definição que

128

pode divergir e ter significados diferentes para as pessoas. De acordo com Carvalho e Paladini

(2006), a qualidade é um termo utilizado no cotidiano, mas seu significado é diverso e

dificilmente haverá um consenso. Para Oliveira Netto (2006), o cliente é o motivo da

existência de qualquer negócio ou organização.

Para atingir um alto nível de qualidade de produto ou serviço, que é o objetivo da

maioria das organizações, existem dois tipos de padrões estabelecidos como parte do processo

de garantia de qualidade que são: Padrões de produto e de processo, (SOMMERVILLE,

2003). A qualidade em serviços, Karl (1992), é a capacidade que uma experiência ou qualquer

outro fator tenha para satisfazer uma necessidade, resolver um problema ou fornecer

benefícios a alguém, é a capacidade de proporcionar satisfação. Para a busca dessa

metodologia/modelo foram formuladas algumas questões (segundo os autores da qualidade de

serviços e produtos citados acima) relacionadas à solicitação de serviços em ambientes de

desenvolvimento de TI, que são descritas a seguir:

• Qual é o maior problema encontrado durante a fase inicial de uma produção de

software?

• Como atender a demanda de pedidos e atender a satisfação dos clientes?

• Como envolver os especialistas da área nas fases iniciais de um projeto de

produção de software?

• Existe alguma ferramenta que possa padronizar um processo de produção de

serviços na fase inicial do projeto e auxiliar no levantamento de requisitos?

• Como a qualidade total em serviços pode ser aplicada em um ambiente de

desenvolvimento de software?

• Como os conceitos e teorias da gestão da qualidade em serviços podem contribuir

na prática?

• Existe alguma norma para auxiliar no controle da qualidade de serviços?

• Qual é o modelo da engenharia que auxilia na gestão de análise de risco de

projetos de software?

129

No atendimento dessas questões, o desejo é melhorar a qualidade das aplicações de

softwares em ambientes de desenvolvimento de TI. Busca-se contribuir na redução dos riscos

de investimento e melhoria no aprimoramento da metodologia de desenvolvimento de

software para as empresas que atuam na área de prestação de serviços de TI.

4.2. Estratégias da Pesquisa

A pesquisa foi direcionada ao atendimento da demanda de serviços com o foco na

satisfação do cliente e a aplicação dos conceitos de qualidade. Buscaram-se nas teorias de

gestão de processos e qualidade total, recursos de modelos que demonstrem fundamentos

matemáticos para lidar com métricas qualitativas e quantitativas, além de oferecer soluções

computacionais na forma humana de pensar e de tomar decisões (KOSCIANSKI, 2006;

OLIVEIRA NETTO, 2006; PORTY, 2008; CHAMBERS, 2009; PALADINI, 2006; IEEE,

1995; SOMMERVILLE, 2003; KARL, 1999). A proposta é desenvolver um modelo de

software ou metodologia que auxilie nas tomadas de decisões de projetos e permita envolver

os especialistas da área no processo produtivo de software e seja aplicado desde a fase inicial

da solicitação dos serviços através dos requisitos e pedidos.

4.3. Utilização do formulário (check-list) para obtenção dos riscos em projetos

Aplicou-se nesta tese, uma lista de questões com os atributos de qualidade

apresentadas pelo modelo SQuaRE que são: funcionalidade, manutenibilidade, usabilidade,

confiabilidade, eficiência e portabilidade. A coleta de dados foi realizada utilizando-se as

experiências dos especialistas da área de desenvolvimento formados por um gerente de

projeto, um analista de sistema e um programador de software. O questionário foi também

aplicado em outros tipos de projetos como: Controle de Estoque, Imobiliário, Prestação de

Serviços, Pesos e Medidas, Call Center e Diagnóstico Médico. Para isso, foram desenvolvidos

aplicativos de análises e simulações dos dados coletados pelos especialistas de TI e em

seguida foram utilizados para testes, simulações e validações que ocorreram durante todas as

fases dos desenvolvimentos de software. Os principais componentes do modelo de sistema

proposto são: as regras da lógica fuzzy, redes neurais, a norma SQuaRE (para avaliação da

qualidade de serviços) e o modelo de Boehm para análise de risco de projeto. Segundo

Kosciansky e Soares (2006), o analista pode propor um questionário para obter informações.

130

De acordo com sua experiência dos especialistas da área de TI, o analista conduz os

questionamentos em uma sequência lógica e com as respostas obtidas conseguir abstrair quais

são as reais necessidades dos stakeholders.

4.4. Coleta e Análise de Dados

Para a inserção dos dados coletados, foram utilizados formulários automatizados (para

aceitar as entradas dos dados coletados) desenvolvidos no aplicativo proposto (conhecido

como sistema “NeurofuzzySQuaREBoehm”), utilizando os conceitos apresentados pelos

autores da gestão da qualidade e gestão por processos (CARVALHO; PALADINI;

KOSCIANSKI E SOARES; LAS CASAS; PALADINNI; SORDI; SPHAINER, entre outros).

As análises e validações da consistência dos formulários e da metodologia proposta

foram feitas através das ferramentas Matlab (análise gráfica, probabilística, fuzzy, estatística,

entre outros), planilha eletrônica e pelos programas desenvolvidos pelos autores para a

simulação desses dados.

As informações coletadas por meio das métricas de qualidade de serviços SQuaRE (ou

projetos anteriores) e dos projetos em andamento (Imobiliário, Prestação de serviços, Controle

de Estoque, Pesos e Medidas, Call Center e Diagnóstico Médico) foram obtidas pela equipe

de desenvolvimento que contribuíram para exercer controle sobre os trabalhos realizados. A

base de dados foi extremamente útil no momento de planejar um novo trabalho, pois permitiu

estabelecer cronogramas mais realísticos e buscar maior competitividade em relação aos

orçamentos. O propósito da coleta de dados teve como objetivo aprimorar estimativas de

prazos e custos, a melhoria de gerenciamento dos projetos, a identificação das necessidades de

treinamentos e fornecer dados mais realistas. Dessa forma, evitar as justificativas e as

dificuldades, (KOSCIANSKY e SOARES, 2006).

A aplicação da pesquisa foi realizada com os especialistas da área de desenvolvimento

de software de empresas de pequeno porte (aplicadas em segmentos de diversas áreas). Foram

analisados os periódicos nacionais e internacionais para melhor entender as técnicas de

pesquisas descritivas e exploratórias. Foram aplicadas no início desta tese, entrevistas com os

especialistas na área de desenvolvimento de softwares (programadores, analistas de sistemas e

gerentes de projetos). Em seguida foram preenchidos os formulários (Check-List), por certo

período de tempo (durante um mês). Utilizou-se a escala Likert como medição (atribuição de

notas entre 1 e 5), conforme as perguntas da figura 31. Os principais atributos de medida da

131

qualidade de serviços da norma SQuaRE são sobre: a funcionalidade, a manutenibilidade, a

usabilidade, a confiabilidade, a eficiência e a portabilidade.

− A funcionalidade possui como subcaracterísticass: a adequabilidade, a acurácia, a

interoperabilidade e a segurança.

− A manutenibilidade possui como subcaracterística: a testabilidade, a estabilidade,

a modificabilidade

− A usabilidade possui como subcaracterísticas: a atratividade, a

compreensibilidade, a apreensibilidade, e a operabilidade.

− A confiabilidade possui como subcaracterísticas: a maturidade, a tolerância a

falhas e a recuperabilidade.

− A eficiência possui como subcaracterísticas: comportamento temporal e utilização

de recursos.

− A portabilidade possui como subcaracterísticas: a adaptabilidade, a instabilidade,

a co-existência e a substitubilidade.

O formulário check-list (da figura 34) é composto também dos valores de atribuição de

“notas” utilizando a escala likert, com 5 notas referentes ao nível de impacto de risco de

projeto. Os especialistas atribuíram os níveis de riscos do projeto (de forma qualitativa)

durante o ciclo de vida do projeto. São descritos (no check-list) o departamento

correspondente pela coleta e os especialistas da área responsáveis pela avaliação. O campo da

média ponderada e da linha divisória foram calculados pelo sistema “FuzzySQuaRE”

(próxima etapa descrito a seguir).

Figura 34- Formulário Check-List para coleta de dados sobre os níveis de impactos de riscos de projeto

(normaSQuaRE), autor.

132

O formulário, da figura 35, foi utilizado desde a solicitação de serviços com a

participação da equipe de TI e durante as fases de construção do software. As sequencias de

preenchimento dos formulários foram: semana1 (2 formulários), semana 2 (3 formulários),

semana 3 (2 formulários) e semana 4 (2 formulários). A marcação dos impactos de riscos foi

totalizada conforme as notas e médias ponderadas.

Figura 35-Formulário de análise SQuaRE preenchido e média gerada do projeto imobiliário, autor.

O resultado da coleta apresentado na figura 35 (aplicada em uma empresa Imobiliária),

tem os seus valores computados em relação aos itens de riscos do modelo SQuaRE, onde tem

as suas médias ponderadas apresentadas nas suas respectivas linhas e colunas. O resultado da

média ponderada (de todos os atributos) está descrito no campo “linha divisória”,

representando uma visão geral do risco de projeto com o valor de 2,35 (abaixo do nível médio

do impacto de risco que foi estabelecido em um valor de 2,5 pelos especialistas conforme a

escala likert).

Conforme Peotta e Gondim (2008), o processo de gestão de risco é continuo e deve ser

sempre reavaliado em busca de inconsistências. Pode-se dividir o processo de condução de

uma análise de risco em seis partes: a) planejamento e estratégia: planejar ações e criar

estratégias de avaliação; b) identificação: criar procedimentos para uma correta identificação

dos riscos; c) qualificação: Introduzir uma qualificação decorrente de uma vulnerabilidade; d)

quantificação: possibilitar uma pontuação do nível de risco; e) impactos e respostas: criar

procedimentos para se determinar o impacto sujeito e qual resposta deverá ser utilizado; f)

monitoramento e controle: determinar procedimentos para um constante acompanhamento

para ações.

133

4.5. Materiais e Métodos

Para o treinamento da rede neural e avaliação do risco de projeto de software em

ambientes de TI, foram realizadas coletas de dados através de formulários do tipo check-list e

atributos que qualificam as medidas de qualidade de serviços obtidos da norma SQuaRE

(Software Product Quality Requirements and Evaluation). Para a avaliação do risco de projeto

utilizou-se o modelo espiral proposto por Boehm, (1988). Foram aplicadas técnicas da lógica

fuzzy e seus mecanismos de inferências como recurso para tomada de decisão nas incertezas

durante as fases do projeto de software para atender aos requisitos e solicitações de serviços

em ambientes de TI. Foi desenvolvido um aplicativo com a utilização de planilha eletrônica

(Microsoft Excel) responsável pela interface entre o usuário e os especialistas da área para

análise e gerenciamento dos projetos de software. Os principais componentes das técnicas da

lógica fuzzy e redes neurais são descritas e mostradas no capítulo 5. Nessa etapa, a

metodologia desse trabalho é dividida em duas fases. A primeira fase está relacionada à

aplicação das técnicas da lógica fuzzy, na segunda fase, as técnicas das redes neurais e a

integração com a neurofuzzy. Nessa primeira fase, define-se: a) a arquitetura básica do modelo

proposto para este trabalho que é composta pela interface, controles, base de dados e de

conhecimento, utilizando o diagrama de contexto da UML, apresentados no capítulo 5. b)

aplicam-se os mecanismos da lógica fuzzy (defuzzificação, definição dos conjuntos de regras,

inferências e armazenamento das informações). c) descrevem-se as variáveis dos níveis de

impactos de riscos de projeto e seus termos linguísticos, a variação do universo de discurso e

os termos linguísticos para as variáveis de saídas. As principais ferramentas utilizadas foram:

a linguagem de programação orientada a objetos, uma planilha Excel e o Matlab, para o

desenvolvimento da aplicação “NeuroFuzzySQuaREBoehm”. O aplicativo proposto mostra

em seus resultados a apresentação das tabelas, gráficos e testes durante a validação dos dados

coletados. Após o desenvolvimento da aplicação foram inseridos os valores das notas de

níveis de riscos que foram preenchidos pelos especialistas de TI utilizando o formulário

check-list conforme a norma SQuaRE (1-funcionalidade, 2-manutenibilidade, 3-usabilidade,

4-confiabilidade, 5-eficiência, 6-portabilidade).

134

5. APLICAÇÃO DA LÓGICA FUZZY E REDES PERCEPTRON

5.1. Técnicas da Lógica Fuzzy e Estatística

Descreve-se, em seguida, um modelo com aplicação da lógica fuzzy para análise do

nível de impacto de risco de projeto de software. A arquitetura é composta dos elementos

principais do modelo SQuaRE e a norma SQuaRE que tratam de qualidade de produto de

software. SQuaRE significa Software Product Quality Requirement and Evaluation

(Requisitos de Qualidade e Avaliação de Produtos de Software). Aplicam-se, também, os

recursos da estatística para análise dos resultados da lógica fuzzy.

A figura 36 mostra a arquitetura do modelo “Sistema NeuroFuzzySQuaREBoehm”

proposto, utilizando diagrama de distribuição da UML (Linguagem de Modelagem Unificada)

e os principais componentes são: sistema operacional, FuzzySQuaRE,

NeuroFuzzySQuaREBoehm, Fuzzy, Modelo BOEHM, Rede Perceptron, Excel e Matlab. O

mecanismo básico para a conexão da norma SQuaRE com a rede perceptron é a estrutura de

árvore binária e grafo de estados para a análise comportamental.

Figura 36- Arquitetura básica do modelo proposto Sistema “NeuroFuzzySQuaREBoehm” visão geral, autor.

A figura 37 mostra a arquitetura de componentes do modelo do sistema proposto

“NeurofuzzySQuaREBoehm”, instalado em uma máquina do tipo PC (Personal Computer),

executado em um sistema operacional do tipo Windows, numa visão mais completa. Os

principais sistemas propostos nesta tese são: o componente principal

135

“NeurofuzzySQuaREBoehm” (responsável pela interação com o usuário e o sistema e

subsistemas), o componente “FuzzySQuaRE” (responsável pela análise e inferência da lógica

fuzzy e definição das regras fuzzy) e o componente “PerceptronSQuaREBoehm” (responsável

pela base de conhecimento e aprendizagem da rede de neurônio artificial).

O componente “FuzzySQuaRE” tem como subcomponente o formulário em que estão

definidos os atributos da norma SQuaRE, os subcomponentes do Matlab e Excel, além do

subcomponente de uma RNA (Rede Neural Artificial) simples. O componente

“PerceptronSQuaREBoehm”, possuem como subcomponentes: RNA Perceptron, a base

Excel, o modelo de Boehm e o componente de análise de risco de projeto.

Figura 37- Arquitetura básica do modelo proposto Sistema “NeurofuzzySQuaREBoehm” e seus sub-

componentes, autor.

A figura 38 mostra a forma como os dados são inseridos no sistema “FuzzySQuaRE”,

através do formulário (check-list) para análise de impacto de risco. Uma vez inseridos os

dados (valores de atribuição das notas do nível de risco de projeto pelos especialistas), o

sistema calcula a média ponderada para estabelecer e comparar a média do nível de risco com

o padrão (valor de 2,5 estabelecido pelos especialistas de TI), para mostrar os resultados na

forma gráfica (representação através dos recursos da planilha Excel, Matlab e de uma Rede

Neural Artificial simples) para permitir a interação com os seus usuários. Além disso, é criada

uma base de conhecimento e armazenado na planilha Excel.

136

Figura 38- Arquitetura básica do modelo proposto Sistema “FuzzyQuaRE” e seus sub-componentes de links,

autor.

A figura 39 mostra as interfaces do componente “Aplicativo NeuroFuzzy” (composta

de subsistemas “FuzzySQuaRE” e “NeuroFuzzySQuaREBoehm”) responsáveis por gerar as

telas de entradas, saídas e processamento dos valores inseridos das coletas de dados realizadas

pelos especialistas da área de TI. A figura “A” representa o componente do aplicativo

“FuzzySQuaRE”, controlando o funcionamento das outras telas que estabelecem a

comunicação com os seus usuários. A tela “B” é responsável pela entrada dos dados após as

coletas de dados gerados pelo formulário, representado pela figura 35 (resultado das coletas

do formulário individual mostrada na figura 34).

137

Figura 39-Interface do sistema do “FuzzySQuaRE” ”.

A figura 40 mostra as interfaces geradas pelo sistema FuzzySQuaRE geradas após as

inserções dos dados coletados pelos formulários check-list, armazenadas na base Excel para

serem utilizadas na próxima fase e criação de uma nova base de conhecimento gerado pelo

aplicativo “sistema NeurofuzzySQuaREBoehm”.

A figura “A1” representa o formulário para inserção de informações (atribuição de

notas de impacto de risco de projeto) atribuídas pelos especialistas da área de TI. A figura

“A2” mostra uma aplicação da simulação da opção funcionalidade, a linha divisória (com o

universo de discurso dos atributos do modelo SQuaRE) e os seus níveis de riscos conforme os

valores atribuídos (de 1 a 5) pelos especialistas (gerente de projeto, analista de sistemas e

programador). A figura “A3” mostra detalhes dos atributos SQuaRE com as suas

subcaracterísticas. A figura “A4” representa os resultados da análise da primeira semana do

desenvolvimento do projeto da empresa imobiliária na visão do gerente. A figura “A5” mostra

a análise dos atributos da norma SQuaRE, utilizando a ferramenta Matlab.

138

Figura 40-Componente Matlab do sistema “NeuroFuzzySQuareBoehm”.

O software proposto consiste em coletar os dados dos especialistas de cada área de

desenvolvimento de TI utilizando o formulário (check-list) e transferir ao computador as

informações obtidas, segundo as visões e experiências de cada um dos especialistas (gerente

de projeto, analista de sistema e programador) durante as atividades e fases do projeto em

questão. As próximas etapas a serem executadas são: a fuzzificação (onde as informações são

transformadas), o processo de inferência fuzzy e o armazenamento da informação na base de

conhecimento. Ocorre, também, a defuzzificação e a apresentação dos resultados em formas

gráficas ou em relatórios. O controle de RNAs (Redes Neurais Artificiais) estende os recursos

da aplicação do software proposto para uma aplicação de neurofuzzy que é também o objetivo

deste trabalho.

Foi realizada a coleta de dados para análise e verificação dos resultados gerenciados

pelo controle de relatório. O controle fuzzy trata, especificamente, da análise dos dados e a

fuzzificação (transformação dos dados numéricos em informação fuzzy) em busca das regras

estabelecidas na base de conhecimento. Em seguida, o controlador fuzzy procura na base de

dados onde estão as regras estabelecidas dos controles de riscos. O controle de RNA é

responsável pelo aprendizado da base de conhecimento. O controlador de relatórios retira as

informações da base de conhecimento e analisa as informações que foram transferidas pelo

139

controle de defuzzificação e gera o relatório, além de interagir com a interface. Para o impacto

de risco foram definidos os conjuntos ou termos linguísticos que representam as variáveis dos

níveis de impactos de riscos de projetos. As variáveis de impacto do projeto de software

(definidos pelos especialistas de TI), podem variar de 0 até 5 que representam os termos

linguísticos da proposição fuzzy e classificados em 7 conjuntos que são definidos conforme as

descrições a seguir:

1) (MB) Impacto de Projeto Muito Baixo

2) (B) Impacto de Projeto Baixo

3) (PB) Impacto de Projeto Pouco baixo

4) (M) Impacto de Projeto Médio

5) (PA) Impacto de Projeto Pouco Alto

6) (A) Impacto de Projeto Alto

7) (MA) Impacto de Projeto Muito Alto

As variáveis de variação do universo de discurso que representam as variações de

riscos de projeto e podem estar entre -8 até 8 unidades são definidas utilizando-se um total de

10 conjuntos, conforme as descrições apresentadas a seguir:

1) (negMA) Variação de risco de projeto muito alto negativo.

2) (negA) Variação de risco de projeto Alto negativo.

3) (negM) Variação de risco de projeto Médio negativo.

4) (negB) Variação de risco de projeto negativo Baixo.

5) (negMB) Variação de risco de projeto negativo Muito Baixo.

6) (posMB) Variação de risco de projeto Positivo Muito Baixo.

7) (posB) Variação de risco de projeto Positivo Baixo.

8) (posM) Variação de risco de Positivo Médio.

9) (posA) Variação de risco de projeto Alto.

10) (posMA) Variação de risco de projeto Positivo Muito Alto.

140

Os termos linguísticos que representam as proposições fuzzy para as variáveis de saída

são:

1) (Smb) Riscos de Projeto saída Muito Baixo.

2) (Sb) Riscos de Projeto saída Baixo.

3) (Sm) Riscos de Projeto saída Média.

4) (Sa) Riscos de Projeto saída Alta.

5) (Sma) Riscos de Projeto saída Muito Alta.

5.1.1. Aplicação do modelo proposto com as técnicas da lógica fuzzy

O uso da ferramenta do modelo proposto neste trabalho, para a coleta, análise,

simulação e geração de resultados estão descritas e representadas na forma gráfica para

auxiliar no acompanhamento da proposta e aplicação das técnicas da lógica fuzzy com o

modelo SQuaRE. Os resultados apresentados são também descritos, utilizando-se valores

quantitativos (conjunto de pertinência) e a utilização das variáveis linguísticas da lógica fuzzy.

A aplicação da ferramenta foi utilizada (como experiência e teste inicial) pelo autor

em um desenvolvimento de sistema imobiliário de pequeno porte, aplicando-se o modelo de

desenvolvimento espiral proposto por Boehm (1988) durante o ciclo de vida do projeto. O

participante do projeto envolvido foi o autor, desempenhando os papeis de gerente, analista e

de programador, com a finalidade de testar o modelo proposto para esta tese.

A figura 41 mostra a interface do aplicativo na figura 41 do sistema “FuzzySQuaRE”

utilizado para a coleta das notas atribuídas pelos especialistas. Nesta figura (figura 41)

apresentam-se também os resultados de impactos de riscos de projeto, as suas variáveis

linguísticas de riscos e graus de pertinência. Mostra, também, o especialista responsável pela

atribuição das notas, o nome do projeto e as datas de início e término do projeto em

desenvolvimento. Durante a utilização da aplicação foram inseridos os dados coletados

(representada pela figura 34) e registrada durante as etapas do desenvolvimento do projeto

imobiliário.

141

Figura 41-Modelo de interface do “sistema NeurofuzzySQuaREBoehm”, autor.

A figura 42 mostra uma aplicação e simulação da opção funcionalidade com a linha

divisória entre o nível de risco do projeto e seus valores atribuídos (de 1 a 5) pelos

especialistas (gerente de projeto, analista de sistemas e programador). No universo de

discurso (linha horizontal do gráfico), descrevem-se os valores das notas atribuídas para os

atributos SQuaRE e a quantidade dessas atribuições. A linha vertical do gráfico representa os

níveis de risco do projeto e a linha divisória representa a classificação de riscos, segundo as

atribuições dos especialistas.

A funcionalidade avalia (no modelo SQuaRE) as subclasses que são: adequabilidade,

acurácia, interoperabilidade e segurança de um projeto de software. Para a figura 42, o projeto

analisado em termos de funcionalidade está equilibrado, pois o grau de risco está

compreendido entre 2 e 3 (considerando a média de 2,5), há em média 50% de nível de risco

acima da média e 50% de risco abaixo da média para risco de projeto (linha divisória). Para a

nota 1: três atribuições, nota 2: 1 atribuição, nota 3: 3 atribuições, nota 4: 2 atribuições e nota

5: nenhuma atribuição.

142

Figura 42-Resultados da Funcionalidade e Níveis de Riscos de projeto, SQuaRE, autor.

As próximas simulações relacionadas às opções de manutenibilidade, usabilidade,

confiabilidade, eficiência e portabilidade estão representadas e descritas no anexo. A figura

43, 44 e 45, mostram os dados inseridos pelo gerente do projeto imobiliário durante as 4

semanas, utilizando a ferramenta representada pela figura 41.

Figura 43-Resultados da base de dados em Excel para os atributos SQuaRE e níveis de riscos de projeto, visão

gerente, autor.

143

Figura 44-Resultados da base de dados em Excel para os atributos SQuaRE e níveis de riscos de projeto, visão analista, autor.

Figura 45-Resultados da base de dados em Excel para os atributos SQuaRE e níveis de riscos de projeto, visão programador, autor.

144

5.1.2. Teste de avaliação dos especialistas de TI para as técnicas da lógica fuzzy

A aplicação do sistema “FuzzySQuaRE” (parte do modelo proposto), representada na

figura 46, permitiu também avaliar os resultados através dos gráficos gerados, mostrando a

análise do risco semanal na visão do gerente, analista e programador. Os gráficos mostram os

níveis de riscos de projeto (em risco alto e risco baixo) para cada atributo do modelo SQuaRE,

além do nível de pertinência de risco deste projeto. A ferramenta proposta com os recursos

apresentados que são: as técnicas da lógica fuzzy, a representação gráfica, descrições dos

valores quantitativos dos níveis de riscos em porcentagem e pertinência de riscos, foi o fator

principal no auxílio nas tomadas de decisões e gestão do projeto imobiliário. Os resultados

conforme mostra a figura 43, são: risco baixo para os atributos de funcionalidade,

manutenibilidade, usabilidade, confiabilidade, eficiência e portabilidade, nessa fase inicial (1ª.

semana) do projeto na visão do gerente. Os resultados do risco em valores percentuais são:

nível de risco alto igual a 4,5% e risco baixo 95,5%, observados também esses resultados em

relação aos níveis de pertinência (compreendidos entre o e 1).

Figura 46-Resultados da análise da primeira semana do desenvolvimento do projeto na visão do gerente de projeto.

As próximas simulações relacionadas às semanas de desenvolvimento do projeto

aplicado pelos especialistas estão representadas e descritas no anexo. A figura 47 mostra os

resultados apresentados da avaliação dos atributos SQuaRE, utilizando a planilha Excel, onde

se observa a composição dos resultados dos riscos de projeto (risco alto e risco baixo) em

145

relação aos valores das notas atribuídas durante a primeira semana do projeto. As outras

simulações referentes às outras semanas pelos especialistas estão descritas e representadas no

anexo A (gravado na mídia eletrônica anexo nesta tese).

Figura 47-Análise de risco dos atributos SQuaRE e lógica fuzzy na visão do gerente de projeto.

A figura 48 mostra os resultados da análise dos atributos SQuaRE, na visão do gerente

para o projeto imobiliário (na primeira semana), utilizando os recursos do Matlab. Mostra-se a

relação do nível de risco de projeto em relação à pertinência e a evolução dos ajustes

conforme mostram as curvas de risco (risco baixo e risco alto) e representam os ajustes

realizados pelos especialistas de TI durante o ciclo de vida do projeto.

As outras simulações relacionadas aos riscos de projeto, pertinência e ajustes de risco

para o desenvolvimento do projeto com a participação dos especialistas estão representadas e

descritas no anexo A. Foi desenvolvido, nesta etapa, um programa em linguagem C com as

técnicas da lógica fuzzy (aplicado com a ferramenta Matlab) para validar os dados gerados

pelo sistema desenvolvido “FuzzySQuaRE”, proposto nesta tese.

146

.

Figura 48-Análise de risco dos atributos SQuaRE na visão do gerente de projeto pelo Matlab.

Os resultados da utilização da aplicação do sistema “FuzzySQuaRE” na avaliação do

projeto imobiliário dos atributos SQuaRE e os níveis de riscos de projeto utilizando os

recursos da planilha Excel está representado na figura 49. Os resultados mostram que os testes

realizados para os atributos SQuaRE (todos os atributos) resultam em uma média de 2,39, o

que corresponde a um nível de risco aceitável, e a média de risco é de 2,5 (conforme os

especialistas da área de TI).

Figura 49-Resultado da Análise de risco dos atributos SQuaRE na visão do gerente de projeto imobiliário pelo

Excel

147

Os resultados de um padrão de classificação utilizando uma RNA para registrar a

classe risco do projeto (risco alto e risco baixo), na visão geral do gerente para o projeto

imobiliário, estão representados na figura 50, incluindo a sua linha de classificação. As

figuras “circulares” desenhadas abaixo da linha de risco descrevem os níveis de risco alto, já

as figuras com sinal de “adição” representam os níveis de riscos baixos. A razão dos níveis de

riscos (alto e baixo), apresentam na razão de 1 (risco alto) para 2 (risco baixo), o que

corresponde a 50% o que é um nível de risco aceitável na visão do neurônio perceptron. Foi

desenvolvido, nesta etapa, um programa em linguagem C de um neurônio do tipo perceptron,

aplicado com ferramenta Matlab para validar os dados gerados pelo sistema desenvolvido

“FuzzySQuaRE”, proposto nesta tese.

Figura 50-Resultado da Análise de risco dos atributos SQuaRE na visão do gerente de projeto imobiliário pela

RNA.

Os resultados das simulações da norma SQuaRE, na aplicação das técnicas da lógica

fuzzy do “Sistema FuzzySQuaRE” (modelo e metodologia proposta), que foram realizados

pelos especialistas na área de TI e seus valores de riscos de projeto (descritos em

porcentagens) estão representados na figura 51. Os primeiros resultados gerados comparam os

valores em relação aos atributos SQuaRE utilizando técnica da lógica fuzzy (visão geral), em

que os riscos altos estão em torno de 53% e riscos baixos em torno de 47%, para o projeto

imobiliário. Em seguida, são apresentados os valores atribuídos pelos especialistas (gerente,

analista e programador) que foram gerados, semanalmente, e resultam em: risco alto de 23% e

148

risco baixo de 77%, na visão geral do gerente. Risco alto de 65,58% e risco baixo de 34,42%

para o analista e risco alto de 45,46% e risco baixo de 54,55% na visão do programador. Esses

resultados foram realizados a princípio como base e diretriz para integração de pessoas e

recursos iniciais existentes. O resultado da tabela (figura 51) foi calculada com base nos

resultados gerados pelas simulações do aplicativo “FuzzySQuaRE”, que estão demonstradas

no anexo A (multimídia eletrônica). Nesta etapa, os formulários foram inseridos por semana

pelos especialistas de cada área.

Figura 51-Resultado da Análise de risco dos atributos SQuaRE na visão geral do projeto imobiliário, gerado pelo

aplicativo “FuzzySQuaRE”.

A figura 52 mostra o resultado da coleta dos dados realizado pelo gerente de TI para o

sistema “Imobiliário”, que foram realizados apenas pelo gerente de projeto imobiliário para a

validação em relação aos testes anteriores. Os resultados (para cada atributo) mostram que

após as correções e ajustes realizadas no projeto do sistema “imobiliário” (com base no

aplicativo “FuzzySQuaRE”), os valores para risco alto foi para 46,13%, e risco baixo para

53,87%. Segundo a visão do gerente, esses valores estão mais próximos da realidade em

relação ao projeto imobiliário desenvolvido. Nessa etapa, foram inseridos os dados coletados

após cada ajuste dos atributos SQuaRE, para adequar às fases do desenvolvimento do projeto

149

que gerou o formulário (figura- 52), como uma representação geral de todos os dados

coletados (atributos SQuaRE em relação aos níveis de riscos do projeto).

Figura 52-Formulário de análise SQuaRE preenchido e nível de risco gerada do projeto imobiliário.

5.1.3. Aplicação da metodologia em outros tipos de projetos

Nessa fase do desenvolvimento serão apresentados diversos estudos de casos

(analisados com mais detalhes com a aplicação de mais recursos de análise), com a aplicação

da metodologia, as técnicas da lógica fuzzy e o uso do aplicativo “Sistema FuzzySQuaRE” em

outras áreas, tais como: prestadora de serviços em informática, controle de estoque, controle

de pesos e medidas, diagnóstico médico especialista e controle de call center. Os resultados

das simulações são descritos conforme o exemplo da figura 53 (controle do projeto

“Estoque”), em que são avaliados os atributos SQuaRE, as notas para níveis de riscos, o

projeto, a média de risco e os especialistas envolvidos na avaliação dos projetos. O nível de

risco gerado pelo “Sistema FuzzySQuaRE” para o projeto “Estoque” na visão do gerente foi

de: risco alto com valor de 46,13% e risco baixo de 53,87%, para todos os atributos SQuaRE,

o que corresponde a um nível de risco aceitável para uma média de 2,35 (2,0 <= Grau de Risco

< 3,0), e a média de risco padrão o valor é de 2,5. A visão do analista, o risco do projeto está

compreendido entre 43,75% de risco alto e baixo risco de 54,27% (2,0 <= Grau de Risco < 3,0).

No entanto para o programador o grau de risco alto está compreendido entre 53,38%

para risco alto e 49,62% para risco baixo (2,0 <= Grau de Risco < 3,0), demonstrando que o

risco para esse projeto está aceitável, conforme a análise realizada pelos especialistas da área

de TI. As outras demonstrações estão descrita no anexo A (multimídia eletrônica).

150

Figura 53-Resultado da Análise de risco dos atributos SQuaRE na visão geral do projeto Estoque, na visão do

gerente.

A figura 54 mostra a base de registro na planilha Excel gerado pelo sistema

“FuzzySQuaRE”, segundo a análise do gerente de desenvolvimento para o sistema “Estoque”

com as técnicas da lógica fuzzy. O resultado do “risco alto” fica em torno de 44,22%,

enquanto o valor para “risco baixo” de 55,78% o que é considerado bom, pois com a

utilização do aplicativo desenvolvido como ferramenta de apoio para a tomada de decisão,

estabelece-se uma métrica para avaliação de qualidade de software. O nível de risco na

variável lingüística fica compreendido entre: “2<= grau de risco <=3,0”. Para esse projeto

“Estoque”, a entrega final do produto foi dentro do prazo estabelecido no cronograma.

151

Figura 54-Resultado da base de dados da análise de risco dos atributos SQuaRE na visão geral do gerente, gerado

pelo sistema “FuzzySQuaRE”.

A figura 55 mostra a evolução dos ajustes da análise de risco durante as etapas do

projeto de software para o sistema “Estoque” desenvolvido. A linha “azul” representa a linha

que representa o nível de “risco baixo” que inicia o valor de 0,02 e “risco alto” com valor de

0,98. Foram realizados ajustes durante o desenvolvimento do projeto para que ambos os

gráficos (risco alto e risco baixo) se ajustem para um nível aceitável sendo como referência a

linha padrão estabelecido em um valor compreendido em 2,5 (com base na escala likert). Na

linha do universo de “risco alto” são estabelecidos 10 testes para cada atributo SQuaRE,

enquanto que na linha da pertinência os valores que compreendem de 0 a 1 (que

correspondendo em porcentagens de 0% à 100%). O resultado apresentado tem como os

recursos do Matlab inserido no sistema “FuzzySQuaRE”.

152

Figura 55-Resultado da evolução de risco na visão do gerente para o projeto Estoque.

A figura 56 mostra o formulário check-List preenchido pelo sistema “FuzzySQuaRE”,

durante as simulações e testes da ferramenta para o projeto de “estoque”. Após o

preenchimento dos formulários check-List (figura 34), os dados coletados foram inseridos no

aplicativo “FuzzySQuaRE” (figura 39), a ferramenta gera, então, os resultados da base de

conhecimento (conforme mostra a figura 56), com as médias ponderadas para cada atributo

resultando em um cálculo com valor de 2,41. Sendo a média (padrão) de 2,5, isso demonstra

que, para esse projeto, na visão geral do desenvolvimento (gerente de projeto), o risco do

projeto está um pouco abaixo do nível de risco (variável lingüística= 2<= grau de risco

<=3,0).

Figura 56-Formulário de análise SQuaRE preenchido e média gerada do projeto estoque atribuídos pelo analista.

153

A figura 57 mostra os resultados gerados pelo “Sistema FuzzySQuaRE” para o projeto

“prestação de serviços em informática”, após as inserções dos valores das notas coletadas. Os

resultados dos níveis de riscos numa visão geral dos especialistas estão representados da

seguinte forma: para o gerente do projeto corresponde a 47,77% de risco alto e risco baixo

igual a 52,23%. O nível de risco está equilibrado conforme mostra a média com o valor de

2,51, e a linha divisória de risco é igual a 2,5. Para o analista o alto risco o valor é de 43,62%

e baixo risco de 56,38% o que representa um equilíbrio do projeto, conforme mostra o valor

de 2,57 que foi gerada pelo aplicativo proposto. E em seguida há a visão do programador para

quem o risco alto é de 45,68% e baixo risco, o valor de 54,32, coerente com o valor da média

de 2,52 gerada pelo aplicativo.

Figura 57-Resultado da Análise de risco dos atributos SQuaRE na visão geral do projeto serviços em

informática.

As aplicações de outros estudos de casos (controle de pesos e medidas, diagnóstico

médico especialista e controle de call center) estão descritas e apresentadas no anexo A,

disponível na mídia eletrônica).

5.2. Fatores de Risco e Integração do modelo SQuaRE com a Rede Perceptron

Para apoio ao processo de decisão a metodologia proposta é a aplicação do modelo

perceptron de múltipla camada (tem como base de conhecimento e aprendizado aplicado em

sistemas de software) para a análise de risco de projeto (fazer uma relação entre o modelo

154

SQuaRE com o modelo de risco de projeto de Boehm) com o objetivo de propor uma métrica

de qualidade de software (transformação de valores qualitativos em valores

quantitativos).Apresenta-se em seguida a arquitetura do modelo proposto da rede perceptron

conforme mostra a figura 58.

Figura 58-Arquitetura da rede Perceptron (sistema “PerceptronSQuaREBoehm”) do modelo proposto, autor.

A figura 59 mostra a interface do sistema “PerceptronSQuaREBoehm” responsável

pela interação com os especialistas de TI e subdividido em duas outras interfaces: sistema

“Análise de Risco de Projeto” e sistema “PerceptronSQuaREBoehm”.

155

Figura 59- Interface do sistema “PerceptronSQuaREBoehm” do modelo proposto, autor.

A figura 60 mostra a estrutura da base em planilha Excel, onde são inseridas as regras

(lógica fuzzy e neuronal) e as informações registradas (em forma de tabelas e gráficos), além

das estruturas da lógica fuzzy e da RNA (rede neural artificial). Em seguida são apresentados

(nas figuras) os resultados gerados pelos aplicativos: sistema “FuzzySQuaRE” (capitulo 5.2) e

sistema “PerceptronSQuaREBoehm” (no capítulo 5.3).

Figura 60-Base Excel “FuzzySQuaRE e NeurofuzzySQuaREBoehm”, do modelo proposto, autor

156

A figura 61 mostra-se uma visão geral de todos os principais componentes gerados a

partir do formulário check-list (figura 34), da base Excel “FuzzySQuaRE” que são: formulário

do cálculo da média ponderada (linha divisória) com a definição da media padrão de nível de

risco de projeto (escala likert), figura “B”. A figura “C” mostra o gráfico da quantidade de

notas atribuídas segundo o tipo do atributo. A figura “D” mostra a tabela do nível de risco em

relação aos atributos SQuaRE. A figura “D” mostra a representação gráfica dos níveis de

riscos gerados pelos atributos SQuaRE por semana. A figura “F”, é o resultado gerado pelo

conjunto dos atributos SQuaRE e o nível de risco (risco “alto” e risco “baixo”) numa

representação gráfica. Em seguida, há a representação da evolução dos ajustes dos níveis de

riscos realizada durante a fase de desenvolvimento do projeto pelos especialistas na figura

“G”. A figura “H” representa o resultado de cada atributo SQuaRE em relação ao nível de

risco (média ponderada). A figura “I” mostra a classificação do nível de risco numa visão de

um neurônio simples. A figura “J” mostra a relação da análise dos atributos SQuaRE em

relação às regras da lógica fuzzy. A figura “K” mostra os resultados da relação dos atributos

SQuaRE com os níveis de riscos, segundo as regras da lógica fuzzy. Finaliza-se com a tabela

“base de informação” gerada do modelo SQuaRE com as regras da lógica fuzzy (formação da

base de ligação para a base de conhecimento neuronal).

Figura 61- Base Excel “FuzzySQuaRE e seus componentes, do modelo proposto, autor

157

A figura 62 mostra uma visão geral de todos os principais componentes gerados a

partir do formulário da “média ponderada” (check-list figuras 34 e 35) gerada pelo aplicativo

“FuzzySQuaRE” (figura 36) da base Excel “NeuroFuzzySQuaREBoehm”,(figura-60).

Figura 62-Base Excel “NeurofuzzyuzzySQuaREBoehm” e seus componentes, do modelo proposto, autor

A figura “A” representa a estrutura do perceptron multicamada (figura 63). A figura

“B”, mostra a estrutura do modelo SQuaRE e a relação com o modelo espiral de Boehm

(figura 65). A figura “C” mostra a curva do ajuste de aprendizado da rede perceptron (figura

80). A figura “D” mostra a classe de risco de projeto (figura 83). Na figura “E” há a descrição

da base de conhecimento e aprendizado do perceptron multicamada (figura 69). A figura “F”

mostra o gráfico comportamental apresentado pelos atributos SQuaRE de um perceptron

(figura 71). E na figura “G” mostra o reconhecimento padrão dos atributos SQuaRE em

relação à saída do nível de projeto (figura 86).

5.3. Aplicação da rede perceptron multicamada com o modelo SQuaRE

A figura 63 mostra a estrutura da rede perceptron multicamada utilizada para a

inserção dos atributos que definem o modelo SQuaRE para avaliação da qualidade de

serviços. Os atributos de entradas são: funcionalidade (000000), manutenibilidade (000001),

usabilidade (000010), confiabilidade (000011), eficiência (000100) e portabilidade (000101),

as quais possuem seus valores binários correspondentes. Conforme Medeiros (2006), em um

modelo perceptron multicamada podem conter várias camadas internas, além das camadas de

entrada e saída. São atribuídos valores de pesos, bias, e referências para ajustes e limiares de

158

disparos das funções de transferências dos neurônios conforme os valores das somas

ponderadas. As funções utilizadas para os limiares de disparos são do tipo degrau:

( )

≥<−

==0,1

0,1

x

xxfy .

Uma rede neural artificial é uma combinação de neurônios artificiais, suas conexões e

algoritmo de aprendizado usado para treinamento. O emprego de redes neurais na solução de

problemas é função de sua capacidade de aprender. O aprendizado da rede consiste no ajuste

de seus parâmetros, de forma que esta produza o resultado esperado, dada a apresentação de

um conjunto de padrões de treinamento (são informações que se deseja que a rede aprenda)

específicos. Os parâmetros de ajuste são os pesos das conexões que interligam os neurônios,

que podem ser caracterizados pela utilização de diferentes técnicas de treinamento

(supervisionado ou não supervisionado), (AGUIAR e OLIVEIRA JUNIOR, 2007). Para a

figura 60 foi utilizado técnica de treinamento supervisionado. Conforme Nunes da Silva,

Spatti e Fauzino (2010), normalmente, o conjunto total das amostras disponíveis sobre o

comportamento do sistema é dividido em dois subconjuntos que são de treinamento (cerca de

60% a 90%) e de teste (10% e 40%). Do conjunto total das amostras, o subconjunto de teste

será utilizado para verificar se os aspectos referentes à generalização de soluções estão em

patamares aceitáveis em relação à topologia assumida.

A estrutura da figura 63 possui os principais atributos do modelo SQuaRE para análise

da qualidade de serviços de um desenvolvimento de software que são: 1-funcionalidade, 2-

manutenibilidade, 3-usabilidade, 4-confiabilidade, 5-eficiência e 6-portabilidade. Todos esses

atributos permitem estabelecer uma base da medida qualitativa (especificado pelos

especialistas de desenvolvimento de software) e da experiência de cada profissional da área de

TI. Uma vez definido os padrões especificado pelo modelo SQuaRE, define-se a estruturação

interna dessas entradas (atributos SQuaRE), os valores binários correspondentes a cada um

desses atributos. Aplicam-se os conceitos das redes neurais em camada de entrada, pesos

sinápticos, camada oculta e camada de saída, além dos ajustes (bias) e referências para o

treinamento do neurônio artificial (conforme mostra a figura 63). Mostra-se, em seguida, na

figura 64, uma nova forma de estruturar uma rede de neurônio (diagrama de classe de análise

da UML), aplicando se os elementos da UML (linguagem de Modelagem Unificada), como

proposta de modelo em modelagem de RNA.

159

Figura 63- Estrutura do Perceptron Multicamada, autor.

A figura 64 mostra uma proposta de modelagem e implementação de uma RNA,

utilizando um novo conceito de implementação de uma base de conhecimento para

aprendizagem de uma rede de neurônio. A estrutura é composta de camadas de interface,

camada de controle da base de conhecimento e da camada de entidades (com os registros das

informações e conhecimentos adquiridos durante a aprendizagem). Nessa camada da entidade,

registram-se novas aprendizagens que são adquiridas conforme a interação com o seu

ambiente, além disso, são armazenadas também as regras e gramáticas da base de

conhecimento que são inseridas pelos especialistas e ajustadas durante o aprendizado. Enfim

há a camada de controle das saídas, em que são feitas as classificações e distribuições dos

resultados esperados pelos especialistas, conforme os ajustes dos parâmetros em suas bases de

conhecimento (BaseFuzzySQuaRE e BaseNeurofuzzySQuaREBoehm).A apresentação e

detalhamento dessa nova forma de configuração de uma base de conhecimento neuronal é

uma proposta para próximos trabalhos e publicações.

160

Figura 64- Diagrama de classe de análise RNA de uma BCN (Base de Conhecimento Neuronal), autor.

5.4. Integração da rede perceptron multicamada como classificação de Qualidade e

análise de riscos de projetos

A figura 65 descreve a estrutura interna de um perceptron, com os seus respectivos

valores binários e as suas relações entre os modelo SQuaRE e o modelo espiral (para análise

de riscos de projetos) utilizados na engenharia de software. Nessa fase, são estruturadas as

relações (estabelecidos conforme estudos entre os dois modelos e as suas principais

características) existentes entre as suas classes e subclasses do modelo SQuaRE com o modelo

proposto por Boehm (1988), segundo as fases e riscos de projeto. Estabeleceu-se a relação das

classes dos atributos do modelo SQuaRE com as suas subclasses para atribuir os seus valores

binários correspondentes. Em seguida, foram atribuídos também os valores binários para as

fases do modelo espiral de BOEHM, para então descrever a relação entre os dois modelos

utilizando a estrutura binária. Os atributos da estrutura do neurônio perceptron para o sistema

“PerceptronSQuaREBoehm” formados por: SQuaRE, binário, atributos, pesos, fases (fase1,

fase2, fase3 e fase4), e para as relações com o modelo espiral de Boehm (rf1, rf2, rf3 e rf4). A

ligação do atributo SQuaRE com as suas subcaracterísticas são feitas através dos atributos

“binário”. O campo pesos são reservados para armazenar os valores dos pesos sinápticos o

que são inseridos durante a fase de aprendizado, já a ligação das características e

subcaracterísticas da norma SQuaRE são realizadas com os números binários das fases (f1, f2,

f3, e f4). E por fim, a relação entre as normas SQuaRE e modelo espiral de Boehm são

161

finalizadas na junção dos números binários (do SQuaRE com as fases) formando assim o

número binário da relação “SQuaRE x Modelo Espiral”.

Figura 65-Estrutura do modelo SQuaRE e a relação com o modelo espiral de Boehm, autor.

A figura 66 mostra a interface da relação dos modelos SQuaRE com o modelo espiral.

Através dessa interface, é possivel estabelecer o aprendizado da rede, ajustando-se os pesos da

relação do modelo SQuaRe (e seus atributos) com as fases do modelo espiral de Boehm,

segundo os riscos de projeto. A estrutura dessa relação está apresentada na tabela 43,

mostrando de forma resumida a relação dos modelos SQuaRE com o espiral. A interface

permite inserir valores dos pesos, bias e referências para ajustes das conexões e treinamento

da rede, conforme os atributos escolhidos do modelo SQuaRE, que podem ser:

funcionalidade, manutenibilidade, usabilidade, confiabilidade, eficiência e portabilidade,

juntamente com descrição de sua subclasse. É estabelecido em sua saída o seu valor em

relação à respectiva fase especificada. Uma vez confirmada os valores, registra-se então na

base de conhecimento da rede.

Tabela 43- Relação do modelo SQuaRE com as fases do modelo espiral de Boehm.

Na figura 66, mostra-se parte da base de conhecimento já inserida conforme os ajustes

dos pesos sinápticos e o relacionamento do modelo SQuaRE com as fase de riscos de projeto

162

do modelo de Boehm, para a funcionalidade e de suas subclasses: adequabilidade, acurácia,

interoperabilidade e segurança. Descrevem-se também os valores de ajustes de pesos, bias,

somatórios e referências, com os seus respectivos valores de saídas intermediárias (d11, d12,

d21, d22) e saídas da rede (y1 e y2). A estrutura da base de conhecimento mostra os valores e

a população dos valores adquiridos durante a fase de aprendizado. Foram ajustados os valores

dos pesos e as suas saídas, para o atributo “funcionalidade” da norma SQuaRE com as suas

respectivas subcaracterísticas (adequabilidade, acurácia, interoperabilidade e segurança) em

relação às fases (fase 2, fase3 e fase 4) que representam uma situação de impacto de risco de

projeto específica da relação (SQuaRE x Modelo espiral de Boehm) durante a fase de

aprendizado.

Figura 66-Base de conhecimento e aprendizado do perceptron Multicamada proposto para a funcionalidade,

autor.

A figura 67 mostra o sistema “PerceptronSQuaREBoehm” para treinamento da rede

perceptron. Esse aplicativo contém a interface de interação dos atributos SQuaRE, os seus

respectivos ajustes de pesos com as fases do modelo de Boehm para correção dos impactos de

riscos de projeto. Através da interface do sistema “PerceptronSQuaREBoehm”, inserem os

valores dos ajustes dos pesos para as saídas desejadas segundo as fases previstas pelos

especialistas de TI. Caso as saídas estejam de acordo com os valores pré-estabelecidos

confirmam-se os valores e dessa forma são registradas na base de conhecimento, caso

contrário, os valores devem ser rejeitados.

163

Figura 67-Interface do modelo Perceptron Multicamada (sistema “PerceptronSQuaREBoehm”) proposto, autor.

Na figura 68, mostra-se parte da base de conhecimento já inserida conforme os ajustes

dos pesos sinápticos e o relacionamento do modelo SQuaRE(com as fase de riscos de projeto

do modelo de Boehm), para a manutenibilidade e das suas subclasses: testabilidade,

estabilidade, modificabilidade e analisabilidade. Descrevem-se, também, os valores de ajustes

de pesos, bias, somatórios e referências, com os seus respectivos valores de saídas

intermediárias (d11, d12, d21, d22) e saídas da rede (y1 e y2), conforme mostra a figura 66.

Figura 68-Base de conhecimento e aprendizado do perceptron Multicamada proposto para a manutenibilidade,

autor.

A figura 69 mostra os resultados obtidos para a “manutenibilidade” com as suas

subcaracterísticas para a fase 1, após o aprendizado com os seus respectivos valores de pesos

sinápticos, ajustados na aprendizagem.

Figura 69-Resultados dos testes do algoritmo de treinamento, autor.

164

A figura 70 mostra o comportamento de uma análise sobre a manutenibilidade em

relação à “testabilidade” da fase 1 do projeto. Os valores dos pesos, bias, somatórios e

referências são estabelecidos para os valores de saída da rede que são: y1=0 e y2=0. As

variações ocorrem para valores de pesos w21=-3, w22=-1, w02=0, bias2=0, soma2=0,

ref21=0, ref22=0 e saídas intermediárias, cujos valores são: d21=0, d22=-12. Nessas

condições, o aprendizado da rede é registrado conforme a relação de saída estabelecida em

y1=0 e y2=0 (em relação à fase1 do modelo espiral) pelo especialista da área de TI. As outras

fases de ajustes (do comportamento) para o neurônio perceptron em relação aos atributos do

modelo SQuaRE e as fases do impacto de risco do modelo de Boehm estão representadas no

anexo “B”.

Figura 70- Gráfico comportamental apresentado pelo atributo testabilidade em uma análise de manutenibilidade,

autor.

5.4.1. Conclusão dos testes e avaliação dos especialistas de TI para as técnicas da rede

neural perceptron multicamada

Nesta fase do trabalho, desenvolve-se uma aplicação para controle e gestão de

desenvolvimento de software. Realiza-se um estudo para implementar as técnicas de redes

neurais perceptron múltipla camada e da norma de controle de serviços para gestão de

qualidade de software, modelo SQuaRE. De acordo com os estudos, obtêm-se os conceitos

para implantar as regras e normas em uma aplicação de software capaz de auxiliar na tomada

de decisão e criação de uma base de conhecimento para medidas qualitativas e quantitativas.

Viabilizam o desempenho da equipe de desenvolvedores, tomadores de decisão na

165

padronização e participação de todos os especialistas de cada área durante o ciclo de vida de

desenvolvimento de um produto de software.

A metodologia aplicada para este trabalho tem como base as regras de redes neurais do

tipo perceptron múltipla camada. Destaca-se a aplicação da norma SQuaRE para controle de

serviços de qualidade para prestação de serviços em ambientes de desenvolvimento de

software. O controle estabelecido pela ferramenta proposta apresentou resultados positivos em

relação ao desempenho, padronização de comunicação e cumprimento quanto ao prazo de

entrega do produto de software desenvolvido.

Para a próxima etapa deste trabalho, sugere-se o desenvolvimento da lógica fuzzy com

redes neurais (neurofuzzy), que permitam não somente facilitar a interação do homem –

máquina para auxiliar nas tomadas de decisões, bem como criar uma base de conhecimento

para estender os recursos da aplicação em gestão de serviços e de manufatura.

5.5. Integração da rede perceptron multicamada e análise de risco para controle de

“estoque”

Será desenvolvida nesta etapa a integração do sistema controle de “estoque”,

utilizando os dados coletados pelos especialistas da área de TI: gerente, analista e

programadores responsáveis de pelo projeto, desenvolvimento e implementação do sistema de

software. As figuras 71, 72 e 73, mostram os resultados das médias geradas pelo sistema

“FuzzySQuaRE”. Com base nessas informações, a rede perceptron recebe os valores de

entrada através do aplicativo “NeurofuzzySQuareBoehm”, mais especificamente pelo sistema

“PerceptronSQuaREBoehm”. É realizada a fase de aprendizagem do neurônio perceptron

segundo as informações de entradas inseridas e saídas esperadas pelo supervisor responsável

pelo treinamento da rede perceptron.

A figura 71 mostra o resultado e os dados gerados pelo sistema “FuzzySQuaRE”,

segundo a visão do gerente de projeto “Estoque” e os valores das médias ponderadas para

cada atributo do modelo SQuaREcom a sua linha “limite” do impacto de risco geral (valor de

2,35) do projeto (ocorrido num período de 1 mês).

166

Figura 71- Formulário check-listgerado pelo sistema “FuzzySQuaRE”, com a média ponderada, visão do

“gerente” do projeto controle de “estoque”, autor.


segundo a visão do analista de projeto “Estoque” e os valores das médias ponderadas para

cada atributo do modelo SQuaRE com a sua linha “limite” do impacto de risco geral (valor de

2,38) do projeto (ocorrido num período de 1 mês).

Figura 72- Formulário check-list gerado pelo sistema “FuzzySQuaRE”, com a média ponderada, visão do “analista” do

projeto controle de “estoque”, autor.


segundo a visão do programador de projeto “Estoque” e os valores das médias ponderadas

para cada atributo do modelo SQuaRE com a sua linha “limite” do impacto de risco geral

(valor de 2,68) do projeto (ocorrido num período de 1 mês).

167

Figura 73- Formulário check-list gerado pelo sistema “FuzzySQuaRE”, com a média ponderada, visão do

“programador” do projeto controle de “estoque”, autor.

As figuras 74 mostra a estrutura geral da rede perceptron em camadas (com os seus

pesos sinápticos, referências (bias), as suas saídas, as médias ponderadas, os riscos, os

especialistas, o projeto e as variáveis linguísticas), A estrutura registra a base de

conhecimento a partir das informações geradas pelo sistema “FuzzySQuaRE” e pelos

especialistas de TI. A figura 75 descreve os detalhes da estrutura (primeira camada “net1” e

segunda camada “net2” da rede).

Nessa etapa, é realizado o treinamento e ajustes dos pesos sinápticos da rede

perceptron para o sistema controle de “estoque”. São realizados também as ligações (links)

dos atributos do modelo SQuaRE com os níveis de impactos de riscos do modelo de Boehm

(realizado pelo aplicativo “PerceptronSQuaREBoehm”).

168

Figura 74- Estrutura da base de conhecimento (base Excel “NeurofuzzySQuaREBoehm”) para o controle de

“estoque”, autor.

A figura 75 mostra de forma ampliada parte da estrutura do perceptron do sistema

“PerceptronSQuaREBoehm”. A camada de entrada recebe os valores dos atributos SQuaRE

(funcionalidade, manutenibilidade, usabilidade, confiabilidade, eficiência e portabilidade). A

“primeira” camada oculta (net1), composta de três neurônios, recebe os valores (somatória)

das relações de entradas com os pesos recebidos durante as fases de ajustes desses pesos

(aprendizado da rede). Em seguida, os resultados são transferidos para a “segunda” camada

oculta, em que são computados os valores com os seus respectivos pesos sinápticos e

transferidos para a camada de saída da rede perceptron segundo os níveis de risco da lógica

fuzzy, gerado pelo sistema “FuzzySQuaRE”, estabelecido pelos especialistas de TI. A estrutura

do perceptron mostra os valores de simulação para as entradas, os pesos e a tabela de análise

de nível de risco da lógica fuzzy.

169

Figura 75-Estrutura da base de conhecimento do perceptron (net1 e net2) com a norma SQuaRE, autor.

A figura 76 mostra a outra parte da estrutura do conhecimento com a descrição das

saídas do neurônio perceptron, os valores de níveis de riscos de projetos com base nas

informações das variáveis linguísticas da lógica fuzzy e os ajustes dos pesos sinápticos do

neurônio.

Figura 76-Estrutura da base de conhecimento do perceptron (net1 e net2) com impactos dos níveis de riscos da

norma SQuaRE e lógica fuzzy, autor.

170

A figura 77 e 78, mostram partes da estrutura da base de conhecimento (base Excel

“NeurofuzzySQuaREBoehm”) para controle de estoque. Descrevem em detalhes as partes

internas da base de conhecimento durante o aprendizado da rede perceptron. A figura 77

mostra detalhes do neurônio da primeira camada (net1). A estrutura interna é composta de:

pesos (w1, w2, w3, w01), ajustes finos (bias1), a somatória (soma1, soma2) as saídas da

primeira camada (d11, d12, d13) e as referências de ajustes (ref11, ref12, ref13).

Figura 77- Parte da estrutura da base de conhecimento (base Excel “NeurofuzzySQuaREBoehm”), da rede net1,

autor.

A figura 78 mostra detalhes do neurônio da segunda camada (net2) .

Figura 78- Parte da estrutura da base de conhecimento (base Excel “NeurofuzzySQuaREBoehm”), da rede net2,

autor.

A figura 79 mostra os níveis de comportamento interno da rede perceptron (ocorrido

durante o treinamento) e os ajustes de seus valores, segundo a visão do gerente de projeto para

“controle de estoque”.

Figura 79- Curva de ajuste do aprendizado da rede perceptron para o sistema controle de “estoque”, visão do

gerente, autor.

171


durante o treinamento) e os ajustes de seus valores, segundo a visão do analista de projeto

para “controle de estoque”.


analista, autor.


durante o treinamento) e os ajustes de seus valores, segundo a visão do programador de

projeto para “controle de estoque”.


programador, autor.

A figura 82 mostra o comportamento da rede perceptron e a classe de risco numa

visão de alto “risco” e baixo “risco”. Os níveis de risco “alto” concentram-se entre os valores

[0.3, 0.8], enquanto que o nível de risco “baixo” concentra se entre o valor “1”, na visão do

gerente do projeto controle de “estoque”. Foram desenvolvidos com a ferramenta Matlab e

linguagem de programação C, um neurônio artificial para análise dos dados gerados pelos

172

treinamentos do sistema “PerceptronSQuaREBoehm”, para comparação desses resultados,

numa visão de classificação de padrões.

Figura 82- Classe de risco para risco “alto” e risco “baixo” para o sistema controle de “estoque”, visão do

gerente, analisado pela rede perceptron, autor.


visão de alto “risco” e baixo “risco”, Os níveis de risco “alto” concentram-se entre os valores

[0.3, 0.7], enquanto o nível de risco “baixo” concentra se entre o valor “1”, podendo também

ocorrer riscos “altos”, numa razão de 1/2 (50% de risco alto), na visão do analista do projeto

controle de “estoque”.

173

Figura 83- Classe de risco para risco “alto” e risco “baixo” para o sistema controle de “estoque”, visão do

analista, analisado pela rede perceptron, autor.


visão de alto “risco” e baixo “risco”, Os níveis de risco “alto” concentram-se entre o 0.7,

enquanto o nível de risco “baixo” concentra-se entre os valores [0.4, 0.9], podendo também

ocorrer riscos “altos”, numa razão de 2/3 (66,6% de risco alto), na visão do programador do

projeto controle de “estoque”.

174

Figura 84- Classe de risco para risco “alto” e risco “baixo” para o sistema controle de “estoque”, visão do programador,

analisado pela rede perceptron, autor.

Foram realizados mais testes e ajustes de treinamento da rede perceptron para outros

tipos de sistemas de diversas outras áreas, descritos no anexo “A”, multimídia eletrônica.

A figura 85 mostra o resultado do reconhecimento padrão de todos os atributos do

modelo SQuaRE (níveis de riscos de cada atributo em relação à média de risco padrão de

valor “2.5”) e os níveis binários de saída registrado conforme os valores atribuídos pelos

especialistas: risco muito baixo=00; risco baixo=01; risco médio=01 e risco alto=11. Outros

teste e ajustes estão descritos no anexo “A”, multimídia eletrônica.

Figura 85- Reconhecimento padrão dos atributos SQuaRE em relação à saída do nível de risco de projeto, autor.

175

5.6. Aplicação e integração da análise de risco do modelo SQuaRE com modelo de

Boehm através do grafo de estado e estrutura do tipo árvore

Um grafo é um objeto matemático (estrutura matemática) formado por dois conjuntos

(de vértices “V” e arestas “E”). Se dois vértices v e w de V estão relacionados é dito que entre

eles existe uma aresta pertencente a E, chamado de (v, w). Uma árvore é um grafo conexo e

sem ciclos. È uma estrutura que serve para modelar diversas situações, tais como:

organograma de uma empresa e árvore de decisão, (BOAVENTURA NETTO e

JURKIEWICS, 2009). Conforme Ziviani (2007), a árvore de pesquisa é uma estrutura de

dados muito eficiente para armazenar informação. É adequada quando existe necessidade de

considerar todos ou alguma combinação de requisitos tais como: a) acesso direto e sequencial

eficientes, b) facilidade de inserção e retirada de registros, c) boa taxa de utilização de

memória, d) utilização de memória primária e secundária.

Será descrito nesta fase do trabalho, a estrutura para o desenvolvimento do aplicativo

relacionado à “análise de risco de projeto de software” utilizando os recursos e técnicas da

neurofuzzy. A “estrutura” faz parte da ligação (link), do sistema “FuzzySQuaRE” com o

sistema “PerceptronSQuaREBoehm” da figura 56, para auxiliar na gestão de projeto e

tomadas de decisões com base na ferramenta sistema “NeurofuzzySQuaREBoehm”.

Para a relação entre o modelo SQuaRE e modelo de risco de Boehm há: a) conjunto

dos atributos do modelo SQuaRE como: {S1, S2, S2, S4, S5, S6}, representado os estados dos

atributos SQuaRE. B) conjunto das fases de riscos de projeto de Boehm como: {F1, F2, F3,

F4}, representando os estados das fases do projeto. c) relação SQuaRE x Boehm como: {(S1,

F1), (S1, F1), ... , (S5, F4)}, conforme a figura 86, na forma de estrutura em “tabela” e a

relação da linha e coluna de uma matriz m x n representam as transições do estado SQuaRE

(atual) para o próximo estado (novo estado).

As regras da relação estão representadas na figura 87, sendo o término válido e

reconhecido pela máquina abstrata (M), caso finalize como estado final o estado S6.

A máquina abstrata (M), define as transições de estados (δ) dos conjuntos de estados

dos atributos SQuaRE e fases do modelo de risco de Boehm para projeto de software,

conforme mostra a figura 86.

176

SQuaRE \ Boehm (δ) F1 F2 F3 F4

S1 S2 S3 S4 S5

S2 S1 S4

S3 S1 S4 S4

S4 S1 S4 S4

S5 S1 S5 S5 S5

S6 S1 S6 S6

Figura 86-Tabela de transição de estados da maquina abstrata (M), autor.

A figura 87 mostra o diagrama de transição de estados para os estados dos atributos da

norma SQuaRE e o relacionamento entre os estados do modelo de risco (fases do projeto) de

Boehm. Um estado é uma especificação de certos aspectos da realidade relevante para o

problema, corresponde a um conjunto de estados do universo, pois diferentes ações causam

modificações no estado do sistema (LINDEN, 2006). O objetivo da construção, utilizando

grafo de estados, está na possibilidade de análise de todos os estados e relacionamento na

busca de uma solução de análise, utilizando uma busca dinâmica sem alterar a estrutura do

algoritmo de busca. Dessa forma, reduz as tomadas de decisões do tipo (se... então). Para um

algoritmo clássico, nessa situação, seriam necessários de pelo menos 6! x 4! (fatorial), o que

corresponderiam a um total de 17.280 tomadas de decisões, para que seja possível prever

todas as possibilidades de soluções. O diagrama de transição de estados possui as seguintes

características para a transição do atributo “1-funcionalidade”: as transições de estados

possíveis são formadas pelos grafos de transições ={T1, T2, T3, T4}, onde T1={(S1,S2,F1)};

T2={(S2,S3,F2)}; T3={(S3,S5,F4)} e T4={(S4,S5,F4)}. O primeiro parâmetro da função de

transição corresponde aos estados iniciais, o segundo parâmetro corresponde ao próximo

estado, já o terceiro parâmetro corresponde à transição da fase para o estado seguinte.

Figura 87-Diagrama de transição de estados para os atributos SQuaRE e relação com modelo de risco de projeto

de Boehm, autor.

177

A figura 88 mostra a estrutura da tela para a “análise de risco” (utilizando diagrama de

classe de análise da UML – Linguagem de Modelagem Unificada) para auxiliar nas tomadas

de decisões pelos especialistas da área de desenvolvimento de software. O diagrama é

composto pelas camadas de interface, de controle e de entidades.

Figura 88-Diagrama de classe de análise da UML da tela de “Analise de Risco”, autor.

A figura 89 representa a interface dos resultados da análise de risco do projeto de

software de uma avaliação de risco (projeto “imobiliário”), mostrando o nível de risco acima

da média padrão (valor de 2,5) dos atributos SQuaRE e as principais fases do projeto

(segundo o modelo de risco de projeto de Boehm), que devem ser reavaliados para ajustes que

estejam próximos do nível aceitável. A interface (análise de risco de projeto) mostra as

principais fases do risco de projeto (do modelo de Boehm) que são: fase 1 (avaliar

alternativas; identificar e resolver riscos), fase 2 (desenvolver e verificar o produto no nível

seguinte), fase 3 (planejar a próxima fase) e fase 4 (determinar: objetivos, alternativas e

restrições). Mostra-se também a mensagem de que o nível de risco de projeto está acima do

limite aceitável.

178

Figura 89-Aplicativo da Análise de Risco, Relação do modelo SQuaRE x modelo de Boehm, avaliação Risco

Alto, autor.

Na figura 90 mostra-se os resultados de uma análise gerada pelo aplicativo

“NeurofuzzySQuaREBoehm” para uma situação onde os níveis de risco de projeto estão

aceitáveis (valor de risco abaixo de 2.5), segundo as definições estabelecidas nas regras pelos

especialistas da área de TI. O item especificado do atributo SQuaRE é a manutenibilidade,

onde o valor de risco é de 2,38 e as fases de riscos principais de análise do modelo de Boehm

correspondentes são: fase 1 (analisar alternativas e identificar e reconhecer riscos) e fase 4

(determinar: objetivos, alternativas e restrições). Mostra, também, a mensagem de que o nível

de risco de projeto está dentro do limite aceitável.

179

Figura 90-Aplicativo da Análise de Risco, Relação do modelo SQuaRE x modelo de Boehm, avaliação Risco

aceitável, autor.

5.7. Análise dos Resultados dos Estudos de Casos Pesquisados e Avaliação dos

Especialistas da área de TI

A figura 91 mostra os resultados numa visão geral das empresas pesquisadas, segundo

os estudos de casos. Descreve uma comparação da aplicação dos atributos SQuaRE apenas na

visão dos gerentes do projeto. Para o desenvolvimento do sistema de “Diagnóstico Médico”,

houve uma defasagem maior na utilização da metodologia para gerenciamento do projeto de

software, pois segundo o gerente do projeto, a falta de experiência em desenvolvimento de

sistemas na área médica fez com que a avaliação (como especialista da área de TI)

representasse um valor acima da média estimada de valor = 2,5. No entanto, os recursos do

sistema NeurofuzzySQuaREBoehm”, permitiram o gerenciamento e o controle do cronograma

durantes as fases de decisões críticas do desenvolvimento do software “Diagnóstico Médico”.

Para os outros tipos de desenvolvimento de software o resultado geral das médias de riscos de

projetos forma em torno do valor = 2,5 (média de risco segundo os especialistas da área de

TI).

180

Figura 91-Tabela de Resultados dos Estudos de Casos Pesquisados “Visão dos Gerentes”, autor.

A figura 92 mostra os resultados (dos atributos SQuaRE) analisados por todos os

gerentes de projeto para os seus respectivos estudo de caso (Imobiliário, Estoque, Serviços,

Pesos e Medidas, Call Center e Diagnóstico Médico), numa visão gráfica com os resultados

numéricos e médias ponderadas.

Figura 92-Gráfico de Resultados dos Estudos de Casos Pesquisados “Gerentes de Projeto”, autor.

A figura 93 mostra os resultados (dos atributos SQuaRE) analisados por todos os

analistas de projeto para os seus respectivos estudo de caso (Imobiliário, Estoque, Serviços,

Pesos e Medidas, Call Center e Diagnóstico Médico), com os resultados numéricos e com a

suas médias ponderadas.

181

Figura 93-Tabela de Resultados dos Estudos de Casos Pesquisados “Analistas de Projeto”, autor.

A figura 94 mostra os resultados (dos atributos SQuaRE) que foram analisados por

todos os analistas de projeto para os seus respectivos estudo de caso (Imobiliário, Estoque,

Serviços, Pesos e Medidas, Call Center e Diagnóstico Médico), numa visão gráfica com os

resultados numéricos e médias ponderadas.

Figura 94- Gráfico de Resultados dos Estudos de Casos Pesquisados “Analistas de Projeto”, autor.

A figura 95 mostra os resultados de todas as empresas pesquisadas, utilizando o

sistema de apoio a tomadas de decisão, durante o desenvolvimento dos projetos de software.

As coletas de dados, testes e simulações estão no anexo A e B, multimídia eletrônica.

182

Figura 95-Tabela de Resultados dos Estudos de Casos Pesquisados “Programadores de Projeto”, autor.

Na figura 96 estão representadas as formas gráficas dos resultados da aplicação do

sistema de auxílio para gestão de projetos de software utilizando a planilha Excel.

Figura 97-Gráfico de Resultados dos Estudos de Casos Pesquisados “Programadores de Projeto”, autor.

183

6. APRESENTAÇÃO DOS RESULTADOS

6.1. Avaliação da Estrutura para a Análise da Solicitação de Serviços

A estrutura desenvolvida para a análise da solicitação de serviços (questionário do tipo

check-list) representada pelas figuras 34 e 35 foi criada com base nos conceitos e nas normas

SQuaRE (Software Product Quality Requirement and Evaluation –Requisitos de Qualidade e

Avaliação de Produtos de Software), método GQM (Goal-Question-Metric), conceitos de

Likert e cálculo de média ponderada como referência padrão para análise de nível de impacto

de risco de projeto.

A norma SQuaRE permitiu com isso: a) coordenar medidas e a avaliação da qualidade

de software, b) oferecer um guia para a especificação de requisitos de qualidade de software e

c) harmonizar a normativa já existente com respeito à norma ISO / IEC 15939, mediante o

modelo de referência de medida de qualidade pertencente à norma ISO / IEC 25020.

O método GQM permitiu organizar o planejamento de uma medição de software em

etapas, elaboração e definição de questões para a realização do trabalho de medição

(perguntas que trazem informações úteis para melhorar o produto) e criar categorias que se

dividem em conjunto de dados obtidos, além de elaborar formulários (check-list) que

conduziu o trabalho dos avaliadores.

A escala Likert e a sua simplicidade de construção permitiram que a inclusão de

valores sejam coerentes com o resultado esperado, apesar da desvantagem apresentada na sua

representação na forma ordinal.

6.2. Avaliação das Métricas Qualitativas no Controle da Qualidade em Ambientes da

Tecnologia da Informação

A avaliação oferecida pela métrica ou medida qualitativa para o controle da qualidade

foi realizada utilizando a identificação de atributos, especificação de requisitos e técnicas da

lógica fuzzy. A métrica qualitativa utilizada para análise de serviços foi a norma SQuaRE

(Requisitos de Qualidade e Avaliação de Produtos de Software) com a aplicação dos os

atributos de: funcionalidade, manutenibilidade, usabilidade, confiabilidade, eficiência e

portabilidade. Houve desta forma, a avaliação dos níveis de serviços e estabelecimento de um

184

padrão de qualidade de serviço durante todas as fases do desenvolvimento de projetos de

software.

A especificação de requisitos permitiu o gerenciamento ao longo de todo o ciclo de

vida do desenvolvimento do projeto, pois os requisitos de software podem mudar e devem ser

gerenciados. Segundo Crosby (1992), a qualidade é estar em conformidade com os requisitos.

A lógica fuzzy demonstrou que é possível lidar com os requisitos qualitativos, pois

permitiu que fossem tratadas as informações cujo conteúdo envolvesse a incerteza e tomadas

de decisões durante as fases do projeto de software.

6.3. Avaliação das Questões de Riscos de Projeto

As questões estabelecidas para a análise de riscos de projeto foram baseadas no

modelo de Boehm (1988). Na análise, foram avaliadas as quatro fases do ciclo de vida de um

projeto e a sua forma espiral auxiliou na análise e avaliação de resultados de um projeto de

software. Conforme Kosciansky e Soares, (2006), o propósito do processo de gerência de

riscos é de: identificar, gerenciar e reduzir continuamente os riscos nos níveis organizacionais

tais como: mudanças nas hierarquias superiores da empresa, de projeto e atrasos de

cronogramas.

Os riscos do projeto foram identificados, documentados, priorizados, estimados e

classificados de acordo com as categorias e definição de parâmetros. Foram desenvolvidos

planos para a redução de riscos tais como: redução de níveis de riscos e ameaças, atividades

de acompanhamento, análise de custo, benefício e atribuição de responsabilidades para os

responsáveis do projeto.

6.4. As Relações das Técnicas Fuzzy e Tomada de Decisão

Com base nas relações das técnicas da lógica fuzzy para a tomada de decisão, foi

possível oferecer uma nova forma de avaliação dos atributos qualitativos da norma SQuaRE

(Requisitos de Qualidade e Avaliação de Produtos de Software).

Os resultados gerados com a aplicação do formulário (check-list) no sistema

NeurofuzzySQuaREBoehm permitiram avaliar os níveis de impactos de riscos de projeto, além

de estabelecer uma ligação (link) com o modelo de risco de projeto de Boehm. Com isso as

185

tomadas de decisões foram beneficiadas e o cronograma estabelecido (nas fases iniciais do

projeto), foi praticamente cumprido dentro do prazo estabelecido.

6.5. A Aplicação da Rede Neural como Base de Aprendizagem

A aplicação da rede neural permitiu estabelecer uma nova forma de avaliação de

projeto com base no aprendizado da rede perceptron e classificação de padrões de qualidade

de serviços (SQuaRE) com os níveis de impactos de riscos de projetos de software. Após a

fase de aprendizado da rede e estruturação da rede perceptron, foi possível treinar a rede de

neurônio para avaliar e analisar situações de riscos não previstos durante a evolução do ciclo

de vida do projeto.

186

7. CONSIDERAÇÕES FINAIS

Esta tese procurou contemplar a importância das medidas de qualidade de serviços em

desenvolvimento de software destacando algumas questões direcionadas: às normas de

qualidade de serviços (SQuaRE), tomadas de decisões nas incertezas (lógica fuzzy), modelo de

riscos de projeto espiral (proposto por Boehm) e a capacidade de aprendizado de um sistema

computacional (utilizando rede artificial de neurônio tipo perceptron).

A primeira consideração está na importância da inserção de especialistas da área de TI,

além de outras áreas como a saúde, economia, física e matemática, como um trabalho

multidisciplinar e integrado à Engenharia de Produção, em nível de mestrado e doutorado.

Partindo-se do pressuposto de que serviços aplicados em desenvolvimento de software

também estão relacionados com a produção de produtos (de software), além disso, existe

também a necessidade de tomadas de decisões durante as diversas fases de um projeto.

Questiona-se, então, sobre a aplicação de métricas ou medidas para a avaliação da

qualidade de serviços prestados para solicitação pedidos de desenvolvimento de software.

Após os estudos realizados sobre o assunto, fica claro que existe a necessidade de

integração de diversas áreas do conhecimento e participação de especialistas de áreas

específicas como: ciências da computação, engenharias da produção, eletrônica, matemática,

física, financeira, médica ou administração.

Consideram-se, então, as questões de: norma de qualidade de serviço, tomada de

decisão, aprendizado computacional, relação das medidas qualitativas e quantitativas, além de

estabelecer a análise de impactos de riscos de projetos. No entanto, que existe uma relação

direta entre essas considerações, além de certa dificuldade na integração desses conceitos e

mudar uma política social ou cultural já existente dentro de uma organização.

A apresentação dos conceitos sobre a qualidade abrangeu: a) gestão da qualidade de

um software, b) as normas de controle de serviços (SQuaRE), c) os recurso da lógica fuzzy

para auxiliar nas tomadas de decisões, d) métricas para medida de qualidade (GQM – Goal

Question Métric), e) identificação de risco de projeto (Modelo espiral de Boehm). O

levantamento de dados sobre os assuntos citados permitiram a elaboração da proposta desta

tese: a) propor uma aplicação (sistema de software), que permita avaliar e medir a qualidade

de serviços de desenvolvimento de software, utilizando as técnicas da neurofuzzy. Para isso

187

apoiou-se em conceitos e fundamentação da lógica fuzzy e rede neural artificial, o que implica

em estabelecer uma relação das duas técnicas e registro de informações em uma base de

conhecimento, b) estabelecer um modelo e método de aprendizado com base nas experiências

adquiridas pelos especialistas de TI, c) desenvolver um sistema de apresentação e interação de

forma gráfica com os usuários, utilizando recursos computacionais, d) aplicação de recursos

disponíveis e tecnologia das ferramentas existentes no mercado (planilha Excel e Matlab),

para auxiliar no desempenho e exatidão do sistema proposto.

A apresentação da norma SQuaRE, do método GQM e o modelo de risco de projeto

proposto pelos autores relevantes como Kosciansy e Soares (2006) e Boehm (1988),

permitiram fundamentar a proposta desta tese, além de estabelecer a estrutura do objeto de

estudo que é a aplicação da métrica qualitativa para ambientes de prestação de serviços e

produção de software. Além disso, as normas SQuaRE, o modelo da lógica fuzzy apresentado

pelo autor Zadeh(1965), instrumento de mensuração com base na escala do tipo Likert, criada

pelo autor Likert (1932), modelo de neurônio MCP apresentado por, McCulloch e Pitts (1943)

e pelo modelo de perceptron multicamada apresentado por Rosenblatt (1962), permitiram

entender a fundamentação proposta e limitar as restrições apresentadas na metodologia desta

tese.

7.1. Conclusão

Durante a escrita desta tese, foi definida como importante: a) a qualidade de serviços

de desenvolvimento de software, b) a necessidade de uma medida dessa qualidade de forma

computadorizada para auxiliar especialista e gestores de TI durante o ciclo de vida de um

projeto de software. Estabelece, assim, a concepção de envolvimento de pessoas e tecnologia

dentro de um ambiente de qualidade, produção e serviços, a qualidade, no sentido de medir os

resultados qualitativos, enquanto a produção, os valores quantitativos gerados, já para

serviços a execução dentro do tempo ou cronograma estabelecido.

Foi definida uma metodologia empregando: a) a norma de medida de qualidade de

serviços (norma SQuaRE), b) técnicas de tomada de decisão nas indecisões (lógica fuzzy), c)

instrumento de mensuração qualitativa (escala Likert), d) padrão para análise de risco de

projeto (Modelo de Boehm), e) aplicação das técnicas de aprendizado de forma

computacional (Algoritmo de aprendizado perceptron de Rosenblatt), além da utilização de

ferramentas que auxiliem na estruturação das informações, armazenamento e apresentação de

188

resultados de forma confiável (planilha Excel e Matlab). Os resultados foram demonstrados

através do aplicativo (“NeurofuzzySQuaREBoehm”) e desenvolvidos com a determinação de

apresentar os seus resultados.

De modo a responder às principais questões levantadas na introdução desta tese

(através das experiências realizadas) são as seguintes conclusões: a) os resultados obtidos a

partir do desenvolvimento do sistema “NeurofuzzySQuaREBoehm”, que tem como

subsistemas “FuzzySQuaRE” e “PerceptronSQuaREBoehm”, mostraram que os mecanismos

adotados com a utilização da inteligência computacional, melhoraram a forma como os

especialistas da área de TI; b) perceber que o sistema “FuzzySQuaRE”, contém os

mecanismos da lógica fuzzy, as normas SQuaRE (avaliação de qualidade de serviços), os

recursos da planilha Excel, Matlab, c) a medida de qualidade GQM (indicador de qualidade

de software) a norma ISO/IEC 9126 e 14598, a classificação de risco IEEE 1044.1 1995), a

escala do tipo likert, a soma ponderada (medida de serviço) e a linha divisória (métrica de

distribuição das classes de registro), são os elementos responsáveis nas soluções de: a)

requisição de pedidos de serviços de software, b) nas avaliações dos processos de requisições,

c) nas tomadas de decisões mutáveis do ambiente, d) no cumprimento das propostas de

prestação de serviços (quanto ao cronograma e prazos de entregas), e) a qualidade de serviços

(satisfação ao atendimento na necessidade do cliente), f) na gestão de processos (auxiliar no

gerenciamento das indecisões), g) no estabelecimento das normas (normalização na avaliação

e medida da qualidade de serviços), h) na análise de risco de projeto (identificação de fatores

de impacto de risco do projeto) para minimizar e propor soluções que reduzam os riscos de

projeto. O sistema “PerceptronSQuaREBoehm”, procura propor um modelo de solução para

minimizar os riscos de desenvolvimento de software: na eliminação dos riscos possíveis em

uma solicitação de serviços de software, e na identificação dos principais fatores de riscos de

projeto, c) auxiliar nas gestões de projetos. Tudo isso foi realizado com a base de

conhecimento obtido através das experiências dos especialistas, coletados, durante todas as

fases do aprendizado da rede perceptron.

7.2. Sugestões para Trabalhos Futuros

O algoritmo genético, (são técnicas de buscas probabilísticas), é a área da pesquisa que

procura aplicar o entendimento da evolução natural em resoluções de problemas do mundo

real. A abordagem mistura as melhores de uma coleção de soluções propostas para a geração

189

que represente um aperfeiçoamento em relação à coleção original, simulando o processo

evolucionário aplicando a tarefa de desenvolvimento de programação evolucionária

(BROOKSHEAR, 2005). Conforme Linden (2006), algoritmos genéticos possuem as

seguintes características: a) paralela, b) global, c) não totalmente aleatória, d) não afetada por

descontinuidade na função, e) capaz de lidar com funções discretas e contínuas.

Com a finalidade de contribuir no assunto abordado desta tese e o conhecimento

adquirido sobre algoritmos genéticos e das suas aplicabilidades (ocorrida durante os estudos

desta tese), seguem para desenvolvimento de pesquisas futuras algumas sugestões: a) manter

uma população das melhores soluções de projetos propostos (classificados segundo áreas de

aplicação); b) permitir a construção de sequências de situações de impactos de riscos de

projeto para aplicação de determinadas estratégias e encontrar as melhores soluções; c)

capacidade em selecionar as melhores estratégias para lidar com impactos de riscos de

projetos acima do nível de risco permitido; d) melhorar a simulação dos impactos de riscos de

projeto; e) realizar mutações dentro de uma estratégia para gerar outras estratégias,

relacionadas a riscos de projetos em ambientes de TI.

190

REFERÊNCIAS BIBLIOGRÁFICAS

ABNT. NBR ISO 9000:2000 Sistemas de Gestão da Qualidade. Fundamentos e Vocabulário, Rio de Janeiro – RJ Dezembro de 2000.

ABNT. NBR ISO 9001:2000 Sistemas de Gestão da Qualidade. Requisitos, Rio de Janeiro – RJ Dezembro de 2000.

AGUIAR e OLIVEIRA Jr. Inteligência Computacional aplicada à administração, economia e engenharia em Matlab. São Paulo: Thomson Learning, 2007.

ALLEMÃO, M. A. F. Modelos não-lineares e Lineares para Previsão do Fluxo de reserva Bancária de um Banco Comercial, Rio de Janeiro – RJ, 2009.

ALMEIDA, M. V. de Aplicação de Técnicas de Redes Neurais Artificiais na Previsão de Curtíssimo Prazo da Visibilidade e Teto para o Aeroporto de Guarulhos – SP, São Paulo-SP, 2009.

ARTERO, A. O. Inteligência Artificial Teórica e Prática; Editora Livraria da Física, São Paulo-SP, 2008.

BARROS, A. N. “Detecção e Classificação de Faltas de Alta Impedância em Sistemas Elétricos de Potência Usando Lógica Fuzzy”, Ilha – Solteira – SP, 2009.

BASILI, VR, WEISS, D. A Methodology for Collection Valid Software Engineering Data. IEEE Trans. SoftwareEng 10: 728-738, 1984.

BATALHA, M. B.; SILVA, A. L da. Gerenciamento de Sistemas Agroindustriais: definições e correntes metodológicas. In: BATALHA, Mário Otávio (Coord). Gestão Agroindustrial: GEPAI (Grupo de Estudos e Pesquisas Agroindustriais). Volume 1,2. ed. São Paulo: Atlas, 2001.

BATALHA, M. O. Introdução à Engenharia de Produção / Organizador Mário Otávio Batalha - Rio de Janeiro: Elsevier, 2008.

BOAVENTURA NETTO, Paulo Oswaldo e JURKIEWICS, Samuel Grafos: Introdução e Prática, São Paulo – SP, Editora EDGARD BLÜCHER LTDA, 2009.

BOEHM, BARRY W. Software Risk Management: Principles and Practices. In: IEEE Software Jan 1991.

191

BOEHM, Barry W.A Spiral Model of Software Development and Enhancement, IEEE, May, 1988.

BOENTE; A. N. P e MORÉ; J. D Um Modelo Fuzzy para Avaliação da Satisfação dos Gerentes de Projetos de Produtos de Software de uma Fundação Pública Estadual, Rio de Janeiro – R, 2009.

BRAGA, A. de P; CARVALHO, A. P. de LEON F e LUDERMIR, T. B; Redes Neurais Artificiais Teoria e Aplicação, Rio de Janeiro - RJ, Editora LTC, 2007

BRAGA, MARIO J. F.; BARRETO, J.M.; MACHADO, M.A.S. Conceitos da Matemática Nebulosa na Análise de Risco. Ed. Artes & Rabiscus, 1995.

BRANÃ, J. P. Processo de Tomada de Decisão em Projetos de Exploração e Produção de Petróleo: Uma Abordagem Sistêmica com Aplicação da Teoria da Lógica Fuzzy, 2008.

BROOKSHEAR J. G; Ciência da Computação uma Visão Abrangente, Porto Alegre, Editora Bookman, 2005.

CAMPOS, Mario Massa de; SAITO, Kaku. Sistemas inteligentes em controle e automação de processos. Rio de janeiro: editora ciência moderna, 2004.

CAMPOS, Vicente Falconi. TQC-Controle da qualidade total (no estilo japonês): Belo Horizonte, 1992,1996.

CARVALHO , M. M.; e PALADINI, E. P. Gestão da Qualidade Teoria e Casos. Rio de Janeiro: Eliesevier Editora Ltda, 2006.

CHAMOVITZ, I. e COSENZA, A. N.; Inovação em Educação com Internet: a distância, com o uso de Webquests e da Lógica Nebulosa,Engenharia de Produção da UFRJ, Rio de Janeiro – RJ, 2006.

CHAPMAN, J. Stephen Programação em MATLAB para Engenheiros, São Paulo – SP, Cengage Learning, 2011.

COPPIN, Ben Inteligência Artificial , LTC – Livros Técnicos e Científicos Editora S.A., Rio de Janeiro – RJ, 2004.

COSENZA, H. J. S. R. ;MORÉ, V. D. e CARVALHO , J. B. B. de C. Aplicação da Lógica Fuzzy em um Modelo para Hierarquização de Produtos e Serviços – Caso da Polibrasil S.A., Salvador-BA. 2006.

192

COSTA, A. F B.; EPPRECHIT E. K. e CARPINETTI, L. C. R; Controle Estatístico de Qualidade; São Paulo,Editora Atlas S.A, 2008.

COSTA, D. C de S.; Tomada de Decisão Baseada em Lógica Fuzzy e na Distribuição Espacial da Mortalidade por Acidentes de Trânsito na Cidade de João Pessoa – PB, João Pessoa-PB, 2011.

CROSBY, PB. Quality is Free: The art of Making Quality Certain. Dever: Mentor Books, 1992.

CURY, M. V. Q. Método para avaliar a percepção do usuário sobre a qualidade de sistemas de transporte urbano sobre trilhos com utilização da tecnologia neuro - fuzzy; Rio de Janeiro – RJ, 2007.

DE MAIO, Waldemar. Fundamentos da Matemática: Álgebra Espaços Métricos e Topológicos, LTC – Livros Técnicos e Científicos Editora Ltda, Rio de Janeiro – RJ, 2010.

DEMING, William Edward. Qualidade: a revolução da administração. Rio de Janeiro: Marques-Saraiva, 1990.

ELISEI, J. L. OSTELLINO, R. Um Sistema Especialista em Orçamento para uma Empresa de Fundição de Aço, 2003.

FASCIONI, L. C. Indicadores para Avaliação da Imagem Corporativa das Empresas de Base Tecnológica Instaladas na Grande Florianópolis Baseados nas Análises das Percepções Gráfica e Verbal Utilizando Lógica Difusa, Florianópolis, 2003

FERNANDES, A. M. da R. Inteligência artificial: noções gerais. Florianópolis:

FERNANDES, Ana Maria da Rocha. Inteligência artificial: noções gerais. Santa Catarina, Visual Books, 2003.

FERREIRA, B. B. Aplicação de ferramentas de lógica nebulosa à predição de séries temporais, Rio de Janeiro - RJ, 2008.

FERREIRA, M. S.; LEITE, J. C. e NETO, J. C. do L.; Produtividade: Desenvolvimento Computacional de Lógica Fuzzy Orientado na Produção Enxuta, Um Estudo de Caso em uma Empresa Eletro - Eletrônica do Pólo Industrial de Manaus – PIM; SIMPEP, Bauru-SP, 2010.

193

FITZSIMMONS, J. A. e FITZSIMMONS, M. J.; Administração de Serviços Operações, Estratégia e Tecnologia da Informação, Porto Alegre – RS, Editora Bookman, 2003.

FRYE, Curtis Office Excel 2007 rápido e fácil, Porto Alegre – RS, Bookman, 2008.

GARCIA, Oscar Gomes SQuaRE: Uma Unificação de Normas para a Especificação de Requisitos e a Avaliação da Qualidade, Universidade de Castilha da mancha, Madri – Espanha, 2009.

GARCIA, Oscar Gomes, SQuaRE, uma unificação de normas para a especificação de requisitos e a avaliação da qualidade Universidade de Castilla da Mancha, Madrid-Espanha, 2009.

GARDNER, Group. Private Company, 2001.

GARVIN, D. A. Gerenciando a qualidade: a visão estratégica e competitiva. Rio de Janeiro: Qualitymark, 1992.

GARVIN, David A. Managing quality: The strategic and competitive edge. EUA, New York: Harvard Business School, 1988.

GONÇALVES, E. R. “Utilização da Lógica Fuzzy para Projeção dos Indicadores de Desempenho Estratégico”; Rio de Janeiro - RJ; 2007.

GONZÁLEZ, R. G. R.; Análise de Atenuação de Sinal em Ambientes INDOOR usando a Lógica Nebulosa, Campinas-SP, 2009.

HAMMER, M., CHAMPY, J.. Reengenharia. Rio de Janeiro, Editora Campus, 1994.

HANSELMAN, Duane e LITTLEFIELD, Bruce MATLAB Versão do Estudante Guia do Usuário, São Paulo – SP, MAKRON Books do Brasil Editora Ltda., 1997.

HIGUERA, R. P.; HAIMES, Y. Y. Software risk management technical report MU/SEI 96 TR 012. SEI Carnegie Mellon University, 1996.

IEEE 1044.1-1995, IEEE Standard Glossary of Software Engineering Terminology,IEEE,1995.

IEEE 610.12 – 1990: IEEE Standard Glossary of Software Engineering Terminology. Institute of Electrical and Electronics Engineers, May 1990.

194

ILANTHENRAL, K., KANDASAMY, W.B.V. eSMARANDACHE, F., Elementary fuzzy matrix theory and fuzzy models for social scientists, Automaton, Los Angeles, 2007.

ISHIKAWA, Kaoru. Controle de qualidade total à maneira japonesa. 6 ed. Rio de Janeiro: Campus, 1997.

ISO/IEC 14598-1:1999, Information technology - Software product evaluation - part 1: General overview. Technical report, International Organization for Standardization, Geneva, Switzerland, 1999.

ISO/IEC 25000:2005 http://iso.org./iso/catalogue detail?csnumber=35683 acessado em 10/09/2012.

ISO/IEC 9126-1:2001, Software engineering - Product quality - Part 1: Quality model. Technical report, International Organization for Standardization, Geneva, Switzerland, 2001.

JANÉ, D. A. Uma Introdução ao Estudo da Lógica Fuzzy, 2004.

JURAN, J. M.; GRYNA, Frank M. Controle da qualidade-handbook. 4 ed. vol. III. São Paulo: Makron Books & McGraw-Hill, 1992.

KANDEL, E.R. & HAWKINS, R.D. (1992). The biological basis of learning and individuality. Scientific American, 267, 78-87.

KARL Albrecht e BRADFORD, Lawrence J. Serviços com qualidade-a vantagem competitiva. São Paulo: Makron Books, 1992.

KOSCIANSKI, A. e SOARES M. dos SANTOS Qualidade de software: Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software, São Paulo, editora NovatecLtda, 2006.

KOTONYA, G e SOMMERVILLE, I Requirements Engineering with Viewpoints, SoftwareEng Journal 11 (1): 5-11, 1996.

LAMBERT, D.M. Supply chain management: what does it involve? Supply Chain & Logistics Journal, 2001.

LANDMANN, R e ERDMANN, R. L. Uma Abordagem Heurística para a Programação da Produção na Indústria de Fundição com Utilização da Lógica Fuzzy Gestão de Produção, São Carlos – SP, 2011.

195

LAS CASAS, ALEXANDRE L. Qualidade Total em Serviços, São Paulo, Editora Atlas, 2007.

LAUDON, K. C. e LAUDON, J. P. Sistemas de informação. Rio de Janeiro: LTC, 1999.

LAURINDO. F.J.B.; ROTONDARO, Roberto Gilioli. Gestão integrada de processos e da tecnologia da informação. 1. ed. São Paulo: Atlas, 2008.

LIKERT, Rensis; LIKERT, Jane Gibson. Administração de conflitos: novas abordagens. São Paulo: Mcgraw-Hill, 1979.

LIPSCHULTZ, Seymour e LIPSON, Marclars Matemática Discreta, Porto Alegre – RS, ARTMED Editora S.A, 2004.

LUDWING Jr., O. e MONTGOMERY E., Redes Neurais Fundamentos e Aplicações com Programas em C, Rio de Janeiro – RJ, Editora Ciência Moderna Ltda, 2007.

MALANGE, F. C. V. “Rede Neuro-Fuzzy-Wavelet para Detecção e Classificação de Anomalias de Tensão em Sistemas Elétricos de Potência”, Ilha Solteira – SP, 2010.

MAMDANI, E. H.; ASSILAN, S. A. An experiment in linguistic synthesis with a fuzzy logic controller. Int. J. Man - machine Studies, 7. 1975. p1-13.

McCULLOCH, W. S. e PITTS, W. A logical calculus of the ideas immanent in nervous activity, Bulletin of Mathematical Biophysics, vol. 5, (pp.115-133), 1943.

MEDEIROS, S.; MELLO, R.; FILHO, P. C. Análise de Projetos para Unidades de Conservação, Usando Lógica Fuzzy, 2007.

MERLI, R. F e ALMEIDA de, L. M. W.; Nem Tudo é Tão Certo Como Parece Ser: A Matemática Fuzzy Como Linguagem, Apucarana-PR, 2011.

MOLINARI, Leonardo. Testes Funcionais de Software, Editora Visual Books, Florianópolis – SC, 2008.

MORAES, O. B. Método de Análise de Dados para Avaliação de Áreas Urbanas Recuperadas – Uma Abordagem – Utilizando a Lógica Fuzzy, São Paulo – SP, 2008.

MORÉ, J. D. Aplicação da Lógica Fuzzy na Avaliação da Confiabilidade Humana nos Ensaios não Destrutivos por Ultra – Som, Rio de Janeiro – RJ, 2004.

196

MOREIRA, F. R. da S.; Uso de Regras de Associação Fuzzy e Técnica de Análise de Exploração Espacial na Mineração dos Dados Sócio-ambientais do Projeto PIATAM, Amazônia Central, Rio de Janeiro – RJ, 2010.

NASCIMENTO Jr., C. L., YONEYAMA, T. (2000). Inteligência Artificial em Controle e Automação, São Paulo – SP, Editora Edgard Blücher, 2004.

NETA, B. M.; Procedimentos de Lógica Fuzzy na Solução de Problema de Controle de Tensão e Potência Reativa em Sistemas e Subsistemas de Potência, Belo Horizonte – MG, 2005.

NOBRE, G. C. Lógica Fuzzy no Impacto da Usabilidade de WEBSITES na Relação das Empresas de Varejo Eletrônico com seus Clientes: O Caso da Blockbuster, Rio de Janeiro – RJ, 2006.

NOGUEIRA, M. A. C. S. Metodologia de Avaliação da Qualidade do Ruído nos Postos de Trabalhos Industriais Baseada em Lógica Fuzzy, Belém-PA, 2010

O’BRIEN, James A. Sistemas de Informação. e as Decisões Gerenciais na era da Internet: 1ª Edição Ed. Saraiva, 2002.

OLIVEIRA Jr, W. Estudo comparativo entre modelos lineares e redes neurais artificiais como tecnologias geradoras de previsões de valores financeiros. 2007. Dissertação (Mestrado em Gestão do Conhecimento e Tecnologia da Informação) – UCB, Brasília.

OLIVEIRA JR., HIME A., CALDEIRA, ANDRÉ M., MACHADO, MARIA A. S., SOUZA, REINALDO, TANSCHEIT, RICARDO. Inteligência Computacional Aplicada à Administração, Economia e Engenharia em Matlab. Rio de Janeiro, Thompson, 2007.

OLIVEIRA NETTO, A. A. de A. Introdução à Engenharia de Produção, Florianópolis, - SC, Editora Visual Books, 2006.

OLIVEIRA, C. U. R.; Sistema de Suporte a Decisão Baseado em Lógica Fuzzy para outorga de Recursos Hídricos, Cuiabá-MT, 2009.

OLIVEIRA, K. R. de; AdeQuaS: Ferramentas Fuzzy para Avaliação da Qualidade de Software, Fortaleza-CE, 2002.

OLIVEIRA, M. A. de e MONTINI, A. de A. M.; Uma Abordagem para Análise de Projetos de Investimento Utilizando Métodos Financeiros e Lógica Fuzzy, Revista de Administração UNIMEP, 2009.

197

ORTEGA, N.R.S. Aplicação da Teoria da Lógica Fuzzy a Problemas de Biomedicina, tese de doutorado, Universidade de São Paulo, São Paulo, 2001.

PALADINI E. P; Gestão Estratégica da Qualidade Princípios, Métodos e Processos; Editora Atlas S.A; São Paulo – SP, 2008.

PALADINI, Edson P. Gestão da Qualidade: teoria e prática. São Paulo: Atlas, 2000.

PARAIZO, C. L. B, Uso da Lógica Difusa no Processo de Decisão de Mudanças de TI, 2007.

PAULA FILHO, W.P., Engenharia de Software: Fundamentos, Métodos e Padrões, LTC Editora, 2ª edição, 2003.

PEDRYCZ, W. GOMIDE, F. An introduction to fuzzy sets: analysis and design, MIT Press, 2000.

PEQUENO, D. A. C.SIMULA – Um Software Educativo de Simulação de Circuitos Pneumáticos com Aplicações de Lógica Fuzzy, Fortaleza-CE, 2004.

PORTER, M. E. “Generic Competitive Strategies”, Free Press New York, 1980.

PORTER, Michael. A hora da estratégia. Revista HSM Management. São Paulo: ano 1, nº 5, p. 6-10, nov/dez 1997.

PRESSMAN, R. S. “Engenharia de software”. 5 ed. São Paulo: McGraw Hill, 2002.

PRESSMAN, R.S. Engenharia de software. 10 ed. São Paulo: McGraw-Hill, 2011.

RHEINGANTZ, P. A.; Lógica Fuzzy e Variáveis Linguísticas Aplicadas na Avaliação de Desempenho de Edifícios de Escritório,Antac, Rio de Janeiro – RJ, 2002.

RIBEIRO, A. I J. T. Representações Neurais e Fuzzy de Controle de Admissão de Chamadas para Redes UMTS, Belo Horizonte – BH, 2010.

RIDDLE, D. I. Service Led Growth. Praeger, Nova York, 1986, FITZSIMMONS M. J. Administração de Serviços: operações, estratégia e tecnologia. Porto Alegre: Bookman, 2 000.

198

ROCHA FERNANDES A. M. da Inteligência Artificial Aplicada à Saúde, Florianópolis – SC, Visual Books Editora, 2004.

RONDINA, J. M.; Sistema de Controle Fuzzy Adaptado ao Fenômeno de Rajadas para Construção de um Modelo de Carga de Trabalho de Serviço WEB; Ilha Solteira - São Paulo; 2005.

ROSENBLATT, F. Principles of Neurodynamics: Perceptrons and the Theory of, 1961.

SÁ, I. I. T. de; Identificação das Ações Empresariais a Parti da Percepção do Consumidor: Uso da Teoria Fuzzy, Rio de Janeiro – RJ, 2007.

SANTOS, Fernando C. A. Estratégia de recursos humanos: dimensões competitivas: São Paulo: Atlas, 1999.

SANTOS, Joel J. Análise de custos: Remodelando com ênfase para custo marginal, relatórios e estudos de casos. 3. ed. São Paulo: Atlas, 2000.

SANTOS, M. S. Construção de um nariz artificial usando redes Neurais, Tese de Doutorado, Centro de Informática, UFPE, 2000.

SCALET, D et al. Guia para Utilização das Normas sobre Avaliação de Qualidade de Produto de Software – ISO/IEC 9126 e ISO/IEC 14598. ABNT, 1999.

SCHILDT, H., Inteligência Artificial Utilizando Linguagem C – Tradução de Cláudio Gaiger Silveira, São Paulo – SP, Editora McGraw – Hill, São Paulo – SP, 1989.

SCHMENNER, Roger W. How can service business survive and prosper. Sloan Management Review, vol. 27, n. 3, p. 21-32, 1986.

SCOARIS, Raquel Carmen de Oliveira; PEREIRA BENEVIDES, Ana Maria Teresa e SANTIN, Filho Ourides, Elaboração e validação de um instrumento de avaliação de atitudes frente ao uso de história da ciência no ensino de ciências, Revista Electrónica de Enseñanza de las Ciencias, Vol.8 Nº3 , 2009.

SHAW I. S. e SIMÕES, M. G. Controle e Modelagem Fuzzy, São Paulo – SP, Blücher Ltda, 2004.

SHEWHART, Walter A.: http://www.asq.org/about-asq/who-we-are/bio shewhart.html.

199

SILVA, F. C. da S. Um estudo sobre algoritmos genéticos, lógica fuzzy e técnicas para segmentação e classificação em imagens médicas, Pelotas, 2008.

SILVA, V L. e SILVA, P. A L. da Mensurando a Qualidade dos Serviços de Empresas Aéreas Brasileiras – uma Abordagem Fuzzy, Rio de Transporte, Rio de Janeiro – RJ, 2004.

SLACK, N; CHAMBERS, S.; HARLAND, C.; HARRISON, A. e JOHNSTON, R. Administração da Produção, São Paulo – SP Editora Atlas, 2009.

SOMMERVILLE, I. Engenharia de Software, São Paulo – SP, Editora Pearson Education do Brasil, 2006.

SORDI, J. O. Gestão por Processos uma abordagem da moderna administração, São Paulo – SP, Editora Saraiva, 2005.

SOUZA, A. C.; FIALHO, F. A. P.; OTANI, N. TCC Métodos e Técnicas. 1ª Ed. Florianópolis: Visual books, 2007.

SPHAIER, A. A. Adaptação de um Modelo para Avaliação da Qualidade de Serviços Prestados por uma Empresa de Tecnologia da Informação, Rio de Janeiro – RJ, 2009.

STANDISH Group Report, Standish the CHAOS report, and science, 1995.

STANDISH GROUP, CHAOS Report, DENNIS, MA 02638, USA, 1995

STURM, W. Avaliação do Potencial de Uso da Lógica Fuzzy para Identificação de Indicadores de Competência de Currículo Lattes; Curitiba – PR, 2005.

TAYLOR, Frederick W., Principio da Administração Científica, UAS, Pensilvânia, 1911.

TOSCANI, Laira Vieira e VELOSO, Paulo A. S. Complexidade de Algoritmos, ARTMED Editora S.A, Porto Alegre – RS, 2008.

WEBER, K. C. e ROCHA, A. R. C. Qualidade e Produtividade em Software, São Paulo – SP, MAKRON Books do Brasil Editora Ltda.1999.

WEBER, L.; KLEIN, P.A.T., Aplicação da lógica fuzzy em software e hardware. 1.ed, Canoas: Ulbra, 2003.

200

ZADEH, L.A. Fuzzy Sets. Information and control . v.8. 1965. p. 338-353.

ZIVIANI, Nivio Projeto de Algoritmos, São Paulo – SP, Thonson Learning, 2007.

CHAU SEN SHIA - UNIP.br

Documents

Transcript of CHAU SEN SHIA - UNIP.br